Difference between revisions of "Configuration Components"

From GCube System
Jump to: navigation, search
Line 1: Line 1:
−
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:
+
Developing a gCube service is far more than writing code. Developers are expected to produce a number of files to configure the service and to describe it from a variety of perspectives and for a variety of purposes. For simplicity, we think of these non-programmatic components of the service implementation as the configuration of the service.
  
−
* we need to describe the service, its dependencies, and its components so that it can be managed by the infrastructure;
+
What does needs configuration, and what for?
  
−
* we need to declare its public interface so that it can be called by clients;
+
*the service as a whole, so that it can be correctly managed by the infrastructure.
 +
:This is a public form of configuration that identifies the service, its requirements, its dependencies, and its implementation components. The result is the [[#Profile|'''profile''']] of the service, a configuration requirement that services share with all the other types of [[Resource Model|gCube resources]].
  
−
* we need to specify the parameters that we do not wish to embed in the code;
+
*the interface of the service, so that the service can be correctly used by clients.
 +
:This is a public form of configuration that describes the operations that can be invoked on the service and how to invoke them. The result is a number of [[#WSDLs|'''WSDL definitions''']], one for each port-type of the service.
  
−
* we need to customise the general processes that we use to build services;
+
*the security requirements of the service, so that the service can be safely used by clients.
 +
:This is a public form of configuration that describes the authentication and authorisation requirements of the service. The result is the [[Security Descriptor|''security descriptor''']] of the service.
  
−
* we need to declare the properties that govern its deployment in a gHN.  
+
*the actual implementation of the service, so that the service will exhibit the required runtime behaviour.
 +
:This is the primary form of local configuration that describes all the choices that were not or could not be made in the code. The result is the [[#JNDIs|''JNDI configuration''']] of the service.
  
−
Unfortunately, there is not a single approach to configuration and different forms of configuration rely on different configuration technologies.  
+
*the process used to build the service, so that the service can be packaged correctly for deployment.
 +
:This is a local form of configuration that customises the process that yields the software artifact required for deployment. The result is the '''build configuration''' of the service. The build configuration is ''not'' part of the service implementation, and thus it is not included in the very artifact it helps to produce. While gCF makes no assumption on the build process, gCore supports a particular build approach and requires a particular configuration file for it. We illustrate these requirements in the [[#The Development Cycle#The Build Properties|Primer]], and do not discusse them further in this Guide.
  
−
== Profiles, JNDIs & Descriptors ==
+
*the process used to deploy the service, so that the service can be correctly managed by the gHN.
 +
:This is a local form of configuration that provides the information required by the gHN to activate the service and dispatch client calls to it. The result is the [[#Deployment Descriptor|'''deployment descriptor''']] of the service.
  
−
[coming soon]
+
The profile, WSDL definitions, security decriptors, JNDI configuration, and deployment descriptor are all part of the software artifact that is deployed on a gHN. As a result of deploying the service, these configuration components are collected in a service-specific directory under <code>$GLOBUS_LOCATION/etc</code>. We call this directory the ''configuration directory'' of the service.
  
−
=== JNDIs ===
+
== Profile ==
−
Each context can be configured with a JNDI section automatically loaded by gCore. Following the stack of contexts, we can configure:
+
The service profile is contained in a file called <code>profile.xml</code> and is governed by the XML Schema in <code>$GLOBUS_LOCATION/share/schema/gcube/common/core/profiles/service.xsd</code>.  
−
* 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.
+
[in progress]
−
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 <code>service</code> element in the file called '''deploy-jndi-config.xml''' and placed in the etc folder under the service location.
+
  
−
==== Configuring the ServiceContext ====
+
== WSDLs ==
−
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 <code>service</code> element. The minimal configuration requires the declaration of the service configuration folder as follows:
+
−
<pre>
+
−
<?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>
+
−
</pre>
+
−
The name assigned to the service element MUST be returned by the <code>getJNDIName()</code> method of the class extending the <code>GCUBEServiceContext</code>.
+
−
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 <code>getProperty(String name)</code> exposed by the class extending the <code>GCUBEServiceContext</code>
+
[in progress]
  
−
The ServiceContext is initialised by a special port-type: the <code>GCUBEStartupPortType</code>. In order to allow the ServiceContext (and then the service) initialisation, gCore requires that a service MUST:
+
== Security Descriptor ==
−
* implement one port-type class that extends the <code>GCUBEStartupPortType</code>
+
−
* the related port-type has to be declared with the parameter <code><parameter name="loadOnStartup" value="true"/></code> in the '''deploy-server.wsdd''' file in the etc folder under the service location.
+
  
−
gCore recommends that only one port-type extends the <code>GCUBEStartupPortType</code>. 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.
+
[in progress]
  
−
==== Configuring the Port-Type Context(s) ====
+
== JNDIs ==
 +
 
 +
[in progress]
 +
 
 +
== Deployment Descriptor ==
 +
 
 +
[in progress]

Revision as of 09:05, 27 April 2009

Developing a gCube service is far more than writing code. Developers are expected to produce a number of files to configure the service and to describe it from a variety of perspectives and for a variety of purposes. For simplicity, we think of these non-programmatic components of the service implementation as the configuration of the service.

What does needs configuration, and what for?

  • the service as a whole, so that it can be correctly managed by the infrastructure.
This is a public form of configuration that identifies the service, its requirements, its dependencies, and its implementation components. The result is the profile of the service, a configuration requirement that services share with all the other types of gCube resources.
  • the interface of the service, so that the service can be correctly used by clients.
This is a public form of configuration that describes the operations that can be invoked on the service and how to invoke them. The result is a number of WSDL definitions, one for each port-type of the service.
  • the security requirements of the service, so that the service can be safely used by clients.
This is a public form of configuration that describes the authentication and authorisation requirements of the service. The result is the security descriptor' of the service.
  • the actual implementation of the service, so that the service will exhibit the required runtime behaviour.
This is the primary form of local configuration that describes all the choices that were not or could not be made in the code. The result is the JNDI configuration' of the service.
  • the process used to build the service, so that the service can be packaged correctly for deployment.
This is a local form of configuration that customises the process that yields the software artifact required for deployment. The result is the build configuration of the service. The build configuration is not part of the service implementation, and thus it is not included in the very artifact it helps to produce. While gCF makes no assumption on the build process, gCore supports a particular build approach and requires a particular configuration file for it. We illustrate these requirements in the Primer, and do not discusse them further in this Guide.
  • the process used to deploy the service, so that the service can be correctly managed by the gHN.
This is a local form of configuration that provides the information required by the gHN to activate the service and dispatch client calls to it. The result is the deployment descriptor of the service.

The profile, WSDL definitions, security decriptors, JNDI configuration, and deployment descriptor are all part of the software artifact that is deployed on a gHN. As a result of deploying the service, these configuration components are collected in a service-specific directory under $GLOBUS_LOCATION/etc. We call this directory the configuration directory of the service.

Profile

The service profile is contained in a file called profile.xml and is governed by the XML Schema in $GLOBUS_LOCATION/share/schema/gcube/common/core/profiles/service.xsd.

[in progress]

WSDLs

[in progress]

Security Descriptor

[in progress]

JNDIs

[in progress]

Deployment Descriptor

[in progress]

Retrieved from "https://gcore.wiki.gcube-system.org/index.php?title=Configuration_Components&oldid=1238"