For effective components, non-functional aspects must be added to the application functional code. Likewise enterprise middleware and component platforms, in the context of Grids, services must be deployed at execution in the component containers in order to implement those aspects. This work proposes an architecture for defining, configuring, and deploying such Technical Services in a Grid platform.
A technical service is a non-functional requirement that may be dynamically fulfilled at runtime by adapting the configuration of selected resources.
From the programmer point of view, a technical service is a
class that implements the
TechnicalService
interface. This class defines how to configure a node.
package org.objectweb.proactive.core.descriptor.services; public interface TechnicalService { public void init(HashMap argValues); public void apply(Node node); }
From the deployer point of view, a technical service is a set of ”variable-value” tuples, each of them configuring a given aspect of the application environment.
<technical-service id="myService" class="services.Service1"> <arg name="name1" value="value1" /> <arg name="name2" value="value2" /> </technical-service>
The class attribute defines the implementation of the
service, a class which must implement the
TechnicalService
interface.
The configuration parameters of the service are specified by
arg
tags in the deployment descriptor. Those parameters are
passed to the
init
method as a map associating the name of a parameter as a key
and its value. The
apply
method takes as parameter the node on which the service must
be applied. This method is called after the creation or
acquisition of a node, and before the node is used by the
application.
Note | |
---|---|
Two or several technical services could be combined if they touch separate aspects. Indeed, two different technical services, which are conceptually orthogonal, could be incompatible at source code level .
That is why a virtual node can be configured by only
one
technical service. However, combining two technical
services can be done at source code level, by providing
a class extending
|
<ProActiveDescriptor> <componentDefinition> <virtualNodesDefinition> <virtualNode name="master" property="multiple" serviceRefid="ft-master" /> <virtualNode name="slaves" property="multiple" serviceRefid="ft-slaves" /> </virtualNodesDefinition> </componentDefinition> ... <infrastructure> <processes> <processDefinition id="localJVM"> <jvmProcess class="JVMNodeProcess" /> </processDefinition> </processes> <aquisition> <aquisitionDefinition id="p2pservice"> <P2PService nodesAsked="100000"> <peerSet> <peer>rmi://registry1:3000</peer> </peerSet> </P2PService> </acquisitionDefinition> </services> </infrastructure> <technicalServiceDefinitions> <service id="ft-master" class="services.FaultTolerance"> <arg name="proto" value="pml" /> <arg name="server" value="rmi://host/FTServer1" /> <arg name="TTC" value="60" /> </service> <service id="ft-slaves" class="services.FaultTolerance"> <arg name="proto" value="cic" /> <arg name="server" value="rmi://host/FTServer2" /> <arg name="TTC" value="600" /> </service> </technicalServiceDefinitions> </ProActiveDescriptor>
In order to help programmers for implementing their owns technical services, we have added a property system to the nodes. This is useful for configuring technical services.
Get the current node:
Node localNode = NodeFactory.getNode();
Using properties:
String myProperty = localNode.getProperty(myKeyAsString);
localNode.setProperty(myKeyAsString, itsValueAsString);
The seminal paper [ CDD06c ] .
The first presentation of this work is available here .
The work of this paper [ CCDMCompFrame06 ] is based on Technical Services.
© 1997-2008 INRIA Sophia Antipolis All Rights Reserved