Difference between revisions of "Developing a Service"
Manuelesimi (Talk | contribs) (→The DL context) |
Manuelesimi (Talk | contribs) (→The DL context) |
||
| Line 70: | Line 70: | ||
== The DL context == | == The DL context == | ||
| − | Understand the DL in which a service is acting on is a fundamental step toward the intergration of such a service in | + | Understand the DL in which a service is acting on is a fundamental step toward the intergration of such a service in DILIGENT. In fact, once deployed, a Running Instance of a service can be shared among multiple DLs and, depending on the current DL, it is able to see different resources and has different access rigths. |
| + | The actual implementation of the Collective Layer supports two scenarios: | ||
| + | * a non secure DL where the RIs are not shared with other DLs | ||
| + | * a secure DL where the RIs can be shared among different DLs | ||
=== Identify your DL === | === Identify your DL === | ||
Revision as of 10:25, 20 March 2007
How to develop a WSRF service that works in DILIGENT
Contents
Preliminary definitions
Service files and rules
A DILIGENT service is primarly a WSRF service runnable on Java WS Core v4.0.4, therefore it must follow the packaging rules to build a GT4 Deployable GAR file. In addition to such rules, others are required by the Collective Layer to correctly manage the services.
WSDD files
A service could be deployed in a secure or a non secure DL. In the latter case, the CL layer deploys the service without the security enabled on its operation. In order to do that, two Web Service Deployment Descriptor (WSDD) files must be provided, one that declares the Security Descriptor and another one without such a declaration. These two files must per placed in the root folder included in the GAR and must be named as follows:
- deploy-server.wsdd (security enabled)
- deploy-server.wsdd_NOSEC (security disabled)
For further details about how to declare the Security Descriptor in the WSDD file, see ...
Service Stubs
The service stub classes have to be placed in a separate JAR file, not included in the GAR file. This is because of the CL layer needs a full controll on the undeploy the stubs by assuring that they are undeployed only if and when they are no longer used by other services.
GAR ID
When a GAR file is deployed on a Java WS Core container, it is labelled with a GAR ID. Such GAR ID is used at undeployment time to remove the package. Since it is not so simple to programmatically detect the assigned ID, the following rule has been fixed: the GAR ID is the gar filename without the .gar extension.
Example: if the GAR filename of my service is org_diligentproject_class_service.gar the GAR ID will be org_diligentproject_class_service
This rule has, of course, an impact on the service code because it has to be taken into account for example when the service tries to access to its etc/gar.id folder.
Service profile
A service profile is an XML file that describes a Service Archive. How to write a service profile is explained in the Profile Specification section of this manual.
Putting all together: the service Archive on ETICS
In order to be registered on the DILIGENT infrastructure, a Service must be packaged in a Service Archive using the ETICS facilities. An appropriate configuration there must package all the packages logically related to a service in a single artifacts and its tarball must be available on the ETICS repository.
Integrating DHN's Collective Layer components
For a service, acting in a DHN meansto interact not only with the local Java WS Core container, but also with part of the Collective Layer software installed on the node. Such software allows to:
- access to the local DHN configuration
- publish/retrieve information in/from the DILIGENT Information Ssytem
- understand the context in which a service is acting
- configure and exploit the authentication mechanisms
To understand how this works, we give in the following a short overview of each module available on the node and the related link to the module documentation. However, the security integration is discussed in the next section.
DIS-HLSClient
The DIS-HLSClient is a Java library that allows to query the DIS in order to retrieve any information handled there (i.e. WS-ResourceProperties and DILIGENT resource profiles). The latest version of the library is composed by a set of Managers, one per each logical section of the information your service wants to query. By requesting the appropriate Manager (like the ones for DHNs data or the WS-ResourceProperties), it is possible to query the a subset of the information available with better performances than the previous versions. However, a generic Manager is also available to perform queries on the whole information available on the DIS. It is of course less efficient w.r.t. the specialized ones since, of course, it queries a bigger set of data.
Another thing to keep in mind when dealing with the DIS-HLSClient is the secure or non secure context. Each method of the library accepts two parameters (in addition to the others): a parameter instance of org.gridforum.jgss.ExtendedGSSCredential and a parameter instance of org.apache.axis.message.addressing.EndpointReferenceType. If a service is acting in a secure DL, then it has to pass to each method of the library the credentials it is actually using to contact other secure services. By analysing such credentials, the DIS-HLSClient is able to understand the DL in which the service is actually acting on and therefore appropriately filters the queries in order to retrieve only the information belonging to that DL. On the other hand, if a service is acting in a non secure DL, it has to pass its current EndPointReference from which the DIS-HLSClient understands the DL and, again, filters the queries by minding on the DL context.
For a complete documentation of the DIS-HLSClient see here.
DIS-IP
DILIGENTProvider
NAL
The Node Access Library is a Java library available on each DHN allowing services to access to the local DHN configuration. Via this library, a DILIGENT service can understand its context. A number of methods here allow to retrieve RI, DHN and DL information. For further details about the NAL libray, see ...
Configure the HNMService
The HNMService is the service in charge of the management of a DHN. This mainly means that it is responsible for the deployment/undeployment operations on the node and for the production of the DHN profile. For the latter activity, HNMService is able to detect most of the characteristics of the node, but, some of them have to be configured manually at DHN installation time.
After the DHN installation, the HNM configuration is located in the $GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/jndi-config.xml under the HNMConfiguration resource. The parameters to configure are:
- country: two letter code of the country (e.g. IT)
- location: a freetext placeholder (e.g. Pisa)
- latitude: the latitude of your DHN to correctly place it on a Google Map
- longitude: the longitude of your DHN to correctly place it on a Google Map
The latter two parameters (latitude and longitude) for the DILIGENT partner DHNs can be found here
Integrating the Security
Obtain valid credentials
The Delegation Service...
The DL context
Understand the DL in which a service is acting on is a fundamental step toward the intergration of such a service in DILIGENT. In fact, once deployed, a Running Instance of a service can be shared among multiple DLs and, depending on the current DL, it is able to see different resources and has different access rigths. The actual implementation of the Collective Layer supports two scenarios:
- a non secure DL where the RIs are not shared with other DLs
- a secure DL where the RIs can be shared among different DLs
Identify your DL
- when the Security is enabled
- when the Security is not enabled
Identify the resource belonging to your DL
Describe the HLSClient and IP segnatures...
How to contact the resource belonging to your DL
Secure and non secure invocations...
