Difference between revisions of "Migration Guidelines from 0.5.1 to 0.6"

Revision as of 12:25, 28 October 2009

gCore 0.6 requires or supports the following changes to practices and service implementations that are compliant with gCore 0.5.1 (non retro-compatible changes are typeset in bold):

Changes Related to Configuration and Use of the gHN

• debugging and profiling launch scripts.

The are two new scripts in $GLOBUS_LOCATION/bin, gcore-start-container-debug and gcore-start-container-profile, to start the gHN in debugging and profiling mode, respectively. See the Primer for detailed usage instructions.

Changes Related to the Implementation of Services

• The interface ISPublisher in org.gcube.common.core.informationsystem.publisher is now extended by ISSyncPublisher and ISASyncPublisher interfaces, in the same package. These are tagging interfaces that implicitly impose synchronous and asynchronous behaviour on their implementations, respectively. The default implementation of ISPublisher is the default implementation of ISAsyncPublisher. This means that existing code retains its current semantics. Interface implementations are obtained though standard means:

ISSyncPublisher sp = GHNContext.getImplementation(ISSyncPublisher.class); //obtains a publisher for synchronous publication
ISASyncPublisher ap = GHNContext.getImplementation(ISASyncPublisher.class); //obtains a publisher for asynchronous publication
ISPublisher p = GHNContext.getImplementation(ISPublisher.class); //also obtains a publisher for asynchronous publication

• org.gcube.common.core.state.GCUBEWSResource has a new method getPublisher() that returns the implementation of ISPublisher used for the publication of WS-Resources. The method returns the default implementation of ISPublisher, which is an asynchronous publisher (see above). Developers can override it to return the implementations of specific publishers, as shown below:

/**{@inheritDoc}*/
 protected ISPublisher getPublisher() throws Exception {
    return GHNContext.getImplementation(ISSyncPublisher.class); //forces a synchronous publisher
}

• org.gcube.common.core.plugins includes programming abstractions for the design of pluggable services, including:

• GCUBEPluginManager, a partial implementation of service components dedicated to the overall management of service plugins. GCUBEPluginManager predefines behaviour to register and unregister plugins, to validate their contents against general and service-specific requirements, to notify other components of registration and unregistration events, to persist plugin profiles so as to automatically re-register them after container restarts, and to store and expose registered plugins within service implementations. Developers specialise GCUBEPluginManager to link its facilities to their services and to add validation checks that reflect specific service expectations. See the API documentation for further details.

• GCUBEPluginContext, a partial implementation of plugin components that act as entry points to the functionality and information in the plugin. GCUBEPluginContext predefines behaviour to expose the profile of the plugin, its descriptive properties, and the type mappings required by the plugin, if any. Service developers specialise GCUBEPluginContext to link its facilities to their service plugins, to pre-define descriptive properties common to all their plugins, and to add any other property or method that they require from the plugins (typically to identify implementations of service interfaces upon which the service needs to act). Plugin developers then further derive this classes to comply with service requirements and include them in the plugins. See the API documentation for further details.

Plugin managers are identified in the JNDI configuration of the service as exemplified below:

<resource name="pluginManagerProfile" type="org.gcube.common.core.plugins.GCUBEPluginManagerProfile">
   <resourceParams>	
             <parameter><name>factory</name><value>org.globus.wsrf.jndi.BeanFactory</value></parameter>	
            <parameter>
                   <name>className</name>
                   <value>org.acme.myservice.MyPluginManager</value>
             </parameter>                   
   </resourceParams>
</resource>

based on this configuration, gCF will instantiate the plugin manager at service startup. Thereafter, the Deployer will interface them transparently to register service plugins that are available within the infrastructure. The registered plugins are also published in a distinguished section of the profile of the Running Instance (cf. runninginstance.xsd in $GLOBUS_LOCATION/share/schema/gcube/common/core/profiles).

Changes Related to the Resource Profiles

• TODO.

TODO.