back to API     back to index     prev     next  

XML Deployment Descriptors

Objectives

Parameters tied to the deployment of an application should be totally described in a xml deployment descriptor. Hence within the source code, there are no longer any references to :

A ProActive application can be deployed on different hosts, with different protocols without changing the source code

Principles

Set of methods are provided in org.objectweb.proactive.descriptor.ProActiveDescriptor to manipulate VirtualNodes, to activate several VirtualNodes at the same time .... and in org.objectweb.proactive.core.descriptors.VirtualNode to manipulate and get nodes associated to VirtualNodes.


Different types of VirtualNodes


Different types of JVMs


Validation against XML Schema

To avoid mistake when building XML descriptors, ProActive provides an XML Schema called DescriptorSchema.xsd. Then to validate your file against this schema, the following line must be put at the top of the xml document as it is done for all ProActive examples.

<ProActiveDescriptor xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Location_of_DescriptorSchema.xsd">

Note that this schema is available in the ProActive distribution package under ProActive\descriptor directory. Using descriptors related methods (Proactive.getProactiveDescriptor(file)) triggers automatic and transparent validation of the file using Xerces2_4_0 if the ProActive property schema.validation is set to enable(see configuration file for more details). If a problem occurs during the validation, an error message is displayed otherwise if the validation is successful no message appear. An XML validation tool such as XMLSPY5.0(windows) can also be used to validate XML descriptors.

Complete description and examples

Following XML files examples are used for the C3D application. The first file is read when launching the C3DDispatcher. The second one is read every time a C3DUser is added. Both files contain many features described earlier in this document.

Infrastructure and processes

In the previous example, all defined JVMs will be created using jvmProcess process. This name is abstract like the other ones, it means that it can be changed. This process is totally defined in the infrastructure part. Of course the process name in the creation part must point at an existing defined process in the infrastructure part. For instance if the name in the creation tag is localJVM, there must be a process defined in the infrastructure with the id localJVM

Infrastructure and services

As mentionned previously, instead of creating jvms, ProActive gives the possibility to acquire existing jvms. To do so, as shown in the example below, a service must be referenced in the acquisition tag. At this point two services are implemented: RMIRegistryLookup: this service performs a lookup in an RMIRegistry at the url specified in the service definition to find a ProActiveRuntime(a jvm) with the given name. P2PService service allows when using ProActive's P2P infrastructure to get as many jvms as desired.

<?xml version="1.0" encoding="UTF-8"?>
<ProActiveDescriptor xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="DescriptorSchema.xsd">
 <componentDefinition>
  <virtualNodesDefinition>
   <virtualNode name="VnTest" property="multiple"/>
  </virtualNodesDefinition>
 </componentDefinition>
 <deployment>
  <mapping>
   <map virtualNode="VnTest">
    <jvmSet>
     <vmName value="Jvm1"/>
     <vmName value="Jvm2"/>
    </jvmSet>
   </map>
  </mapping>
  <jvms>
   <jvm name="Jvm1">
    <acquisition>
     <serviceReference refid="lookupRMI"/>
    </acquisition>
   </jvm>
   <jvm name="Jvm2">
    <acquisition>
     <serviceReference refid="lookupP2P"/>
    </acquisition>
   </jvm>
  </jvms>
 </deployment>
 <infrastructure>
  <services>
   <serviceDefinition id="lookupRMI">
    <RMIRegistryLookup url="//localhost:2020/PA_JVM1"/>
   </serviceDefinition>
   <serviceDefinition id="lookupP2P">
    <P2PService nodesAsked="2" acq="rmi" port="2410" NOA="10" TTU="60000" TTL="10">
     <peerSet>
      <peer>rmi://localhost:3000</peer>
     </peerSet>
    </P2PService>
   </serviceDefinition>
  </services>
 </infrastructure>
</ProActiveDescriptor>

The RMIRegistryLookup service needs only an url to perform the lookup. Many options exists for the P2PService service: nodesAsked represents the number of JVMs to acquire, the peer element represents an entry point in the P2P system, many peers can be specified. Elements acq and port represent the communication protocol and the listening port for the P2P Service, if a P2P Service is already running with this configuration the descriptor will use this one else a new one is started. See P2P documentation for more information.
The example above shows a VirtualNode VnTest, that is mapped with two jvms, Jvm1 and Jvm2. Jvm1 represents one jvm that will be acquired using an RMI Lookup, Jvm2 represents two jvms that will be found in the P2P infrastructure, so at the end 3 acquired jvms are expected.

Fault Tolerance can also be defined at the service level. See Fault Tolerance documentation for more information.

Killing the application

ProActive gives the ability to kill all JVMs and Nodes deployed with an XML descriptor with the method: killall(boolean softly) in class ProActiveDescriptor:


ProActiveDescriptor pad = ProActive.getProactiveDescriptor(String xmlFileLocation);
//----------- Returns a ProActiveDescriptor object from the xml file
pad.activateMappings();
--------------------------------------------
--------------------------------------------
--------------------------------------------
pad.killall(false);
//----------- Kills every jvms deployed with the descriptor

If softly is set to false, all jvms created when activating the descriptor are killed abruptely. If true a jvm that originates the creation of a rmi registry waits until registry is empty before dying. To be more precise a thread is created to ask periodically the registry if objects are still registered.

Processes

There is the possiblity to use only the infrastructure part in order to create processes. A Schema called ProcessSchema located in the examples directory allows to validate XML files for processes. ProActive provides also the ability to use all processes defined above without using XML Deployment Descriptor. You can programmatically create such processes.
In order to get familiar on how to create processes programmatically see
Process package



Copyright © 2001-2005 INRIA All Rights Reserved.