Configuration Components

Developing a gCube service is far more than writing code to define its runtime behaviour. The developer is expected to produce a rich set of configuration elements and declarative specifications that complement and ultimately govern the code. Virtually all aspects of service development have some associated form of configuration:

• we need to describe the service, its dependencies, and its components so that it can be managed by the infrastructure;

• we need to declare its public interface so that it can be called by clients;

• we need to specify the parameters that we do not wish to embed in the code;

• we need to customise the general processes that we use to build services;

• we need to declare the properties that govern its deployment in a gHN.

Unfortunately, there is not a single approach to configuration and different forms of configuration rely on different configuration technologies.

Profiles, JNDIs & Descriptors

[coming soon]

JNDIs

Each context can be configured with a JNDI section automatically loaded by gCore. Following the stack of contexts, we can configure:

• the GHN Context
• the Service Context
• the port-type Context

While the first one is global for each node and its configuration is under the GHN manager responsibility, the others are service-specific and MUST be taken into consideration when developing a new gCore compliant service. Per each service, there are:

• one and only one ServiceContext
• several port-type Contexts, depending on the service architecture and needs

Both the Service Context and the port-type Contexts can be configured with a dedicated service element in the file called deploy-jndi-config.xml and placed in the etc folder under the service location.

Configuring the ServiceContext

The ServiceContext models the configuration of the service instance as a whole. The context configuration MUST be placed in the deploy-jndi-config.xml in the etc folder under the service location as a service element. The minimal configuration requires the declaration of the service configuration folder as follows:

<?xml version="1.0" encoding="UTF-8"?>
<jndiConfig xmlns="http://wsrf.globus.org/jndi/config">
	<service name="acme/sample">
		<environment 
		name="configDir" 
	 	value="@config.dir@" 
	 	type="java.lang.String"
	 	override="false" />
	</service>
</jndiConfig>

The name assigned to the service element MUST be returned by the getJNDIName() method of the class extending the GCUBEServiceContext. The @config.dir@ is a placeholder replaced by the Axis facilities at deployment time with etc folder under the target service location. Other optional parameters of the service configuration managed by gCore are:

• securityManagerClass: configure the security manager for the service
• ...
• ...

In addition, service-specific parameters can be added as needed. In this case, they can be read with the method getProperty(String name) exposed by the class extending the GCUBEServiceContext

The ServiceContext is initialised by a special port-type: the GCUBEStartupPortType. In order to allow the ServiceContext (and then the service) initialisation, gCore requires that a service MUST:

• implement one port-type class that extends the GCUBEStartupPortType
• the related port-type has to be declared with the parameter <parameter name="loadOnStartup" value="true"/> in the deploy-server.wsdd file in the etc folder under the service location.

gCore recommends that only one port-type extends the GCUBEStartupPortType. If two (or more) port-types extend the GCUBEStartupPortType, you have to be aware that your service context is initialised twice. This is an overhead but not an issue for the gCore initialisation procedure. However, it could be a problem if a service performs specific initialisation actions in the service context events (like the onReady() or onInitialisation() callback methods) that are supposed to be executed only once.