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

From GCube System
Jump to: navigation, search
(Changes Related to the Implementation of Services)
(Changes Related to the Implementation of Services)
Line 7: Line 7:
  
 
==== Changes Related to the Implementation of Services ====
 
==== Changes Related to the Implementation of Services ====
 
  
 
:* The interface <code>ISPublisher</code> in <code>org.gcube.common.core.informationsystem.publisher</code> is now extended by <code>ISSyncPublisher</code> and <code>ISASyncPublisher</code> interfaces, in the same package. These are tagging interfaces that implicitly impose synchronous and asynchronous behaviour on their implementations, respectively. The default implementation of <code>ISPublisher</code> is the default implementation of <code>ISAsyncPublisher</code>. This means that existing code retains its current semantics. Interface implementations are obtained though standard means:
 
:* The interface <code>ISPublisher</code> in <code>org.gcube.common.core.informationsystem.publisher</code> is now extended by <code>ISSyncPublisher</code> and <code>ISASyncPublisher</code> interfaces, in the same package. These are tagging interfaces that implicitly impose synchronous and asynchronous behaviour on their implementations, respectively. The default implementation of <code>ISPublisher</code> is the default implementation of <code>ISAsyncPublisher</code>. This means that existing code retains its current semantics. Interface implementations are obtained though standard means:
Line 46: Line 45:
  
 
:: based on this configuration, gCF will instantiate the plugin manager at service startup. Thereafter, the <code>Deployer</code> 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. <code>runninginstance.xsd</code> in <code>$GLOBUS_LOCATION/share/schema/gcube/common/core/profiles</code>).
 
:: based on this configuration, gCF will instantiate the plugin manager at service startup. Thereafter, the <code>Deployer</code> 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. <code>runninginstance.xsd</code> in <code>$GLOBUS_LOCATION/share/schema/gcube/common/core/profiles</code>).
 +
 +
:* '''the method <code>org.gcube.common.core.contexts.GHNContext.getHostName()</code> no longer throws a <code>java.utils.IOException</code>'''.
 +
 +
:* '''<code>org.gcube.common.core.utils.handlers.GCUBEScheduledHandler</code> has changed its parametrisation'''. The old parametrisation was:
 +
 +
<source lang="java">
 +
public GCUBEScheduledHandler extends GCUBEHandler<GCUBEHandler<?>>
 +
</source>
 +
 +
:: it is now:
 +
 +
<source lang="java">
 +
public class GCUBEScheduledHandler<HANDLED> extends GCUBEHandler<HANDLED> ...
 +
</source>
 +
 +
:: Accordingly, a <code>GCUBEScheduledHandler</code>handles arbitrary objects rather than the handlers it schedules. The change allows clients to process scheduled handlers as any other handler. The implication is that the methods <code>setHandled()</code> and <code>getHandled()</code> no longer set and return the scheduled handler. The new methods <code>setScheduled()</code> and <code>getScheduled()</code> can be instead used for this purpose. See the [http://gcore.research-infrastructures.eu/javadoc/ API documentation] for further details.
  
 
==== Changes Related to the Resource Profiles ====
 
==== Changes Related to the Resource Profiles ====

Revision as of 13:32, 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).
  • the method org.gcube.common.core.contexts.GHNContext.getHostName() no longer throws a java.utils.IOException.
  • org.gcube.common.core.utils.handlers.GCUBEScheduledHandler has changed its parametrisation. The old parametrisation was:
public GCUBEScheduledHandler extends GCUBEHandler<GCUBEHandler<?>>
it is now:
public class GCUBEScheduledHandler<HANDLED> extends GCUBEHandler<HANDLED> ...
Accordingly, a GCUBEScheduledHandlerhandles arbitrary objects rather than the handlers it schedules. The change allows clients to process scheduled handlers as any other handler. The implication is that the methods setHandled() and getHandled() no longer set and return the scheduled handler. The new methods setScheduled() and getScheduled() can be instead used for this purpose. See the API documentation for further details.

Changes Related to the Resource Profiles

  • TODO.
TODO.