Difference between revisions of "Configuration Components"

Revision as of 09:56, 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 uniformity, 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.

Profile, WSDL definitions, security decriptors, JNDI configuration, and deployment descriptor are all part of the software artifact that is deployed on a gHN. After service deployment, its 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]