Site Navigation

Mobius Configuration File Settings (common to all Mobius config files)

The Mobius configuration resource block occurs at the top of every configuration file in Mobius. Among other things, this block defines the Network Service Descriptor the service will use when identifying itself on the Grid, and the handlers for the various protocols in the server. This resource is defined under the element <resource name="mobiusConfig" class="org.projectmobius.services.common.MobiusConfiguration">. (All resources in Mobius are specified in this way; the name attribute is the name the resource will have in the resource manager and the class attribute is the class within Mobius that will be associated with that resource.)

The element <mobius-configuration>, the outermost element of the resource, contains five potential sub-elements. Each is listed here, along with its children. Below this list we have elaborated the purpose of the elements.

  1. MobiusNetworkServiceDescriptor
    • serviceIdentifier
    • ports
    • aliases
  2. handlers
    • handler
  3. gridServiceFactories
    • gridServiceFactory
  4. associations
    • factoryAssociations
    • serviceAssociations
  5. serviceRegistry
<MobiusNetworkServiceDescriptor>
All Mobius services have a Mobius Network Service Descriptor that they use to describe themselves to other services within Mobius. The "serviceType" attribute defines what kind of service this is. In Mobius you can have the following service type descriptors:
  • MAKO
  • GME
  • REGISTRAR
  • DTS
The "hostname" attribute defines the name of the host this service is running on. You may use the fully-qualified domain name or any host name that can be resolved on your local network. The children of the Mobius Network Service Descriptor describe the service:
<serviceIdentifier>
This element describes the service identification string used to uniquely identify a Mobius Service within the Grid.
<ports>
This element describes the ports and protocol the service will use for communication. Currently only TCP communication is supported.
<aliases>
This element defines any aliases for the host of the service. Aliases are needed when a host has more than one physical network connection. An <alias> element takes the attributes "id" and "hostname" that define the identification and the hostname that each network interface maps to. A host might have multiple hostnames if it is part of a cluster and/or has multiple network interface cards installed. If the host does not have any extra network interfaces, it is safe to leave the <aliases> element empty.
<handlers>
The individual handler elements define what classes Mobius should use to handle requests and responses. They map a protocol to an implemenation that can handle that protocol. Out of the box, changing these from the way they are defined in the example files will likely break some functionality and should only be done when you are customizing Mobius or extending it to use other services. The "name" and "class" attributes in each handler will have values that depend on the Mobius component being used. That is, the Mobius configuration resource blocks in the configuration files in the Mako component's /conf directory will have handlers specific to Mako; the Mobius configuration resource blocks in GME config files will have handles specific to GME, etc.
<gridServiceFactories>
Grid Service Factories are responsible for establishing communication with other services on the Grid. A Grid Service Factory abstracts the communication between Grid services—the factory mapping the details of the communication appropriately between the services. The Mobius portion of a configuration file must contain at least one (default) Grid Service Factory.
<gridServiceFactory>
The Mobius config must have at least one of these elements with its "isDefault" parameter set to "true". You can set up an arbitrary number of Grid Service Factories, allowing you to hook up Mobius with any Grid Service for which you write the factory (or for which there is already a factory available within Mobius). Grid Service Factories can take any number of parameters. You can pass parameters to a Grid Service Factory by using the <param ...> sub-element of the <parameters> element. See the localhost-mako-registrar-config.xml configuration file for an example.
<associations>
Associations are responsible for guaranteeing that a specific type of request is handled by an appropriate Grid Service Factory. The Mobius API documentation contains an example of creating an association for handling a request for a user-defined service (called "SPECIAL"). And you can see in the Mako /conf/localhost-mako-registrar-config.xml config file an example that uses the association element to associate requests made from a Mako to a GME with a particular Grid Service Factory, in order to facilitate inter-service communication.
<factoryAssociations>
This element contains any number of <factoryAssociation ...> sub-elements. Each sub-element takes two attributes, "associationName" and "factory". The value of "associationName" is the name of the service type for the Grid Service Factory you are attempting to associate. The "factory" must be set to the value of the "name" attribute of the Grid Service Factory you want to map. For example, if you want to make it so that requests for GME connections get handled by the "default" Grid Service Factory, you would set "factory" to "default" and "associationName" to "GME". (See the Mako /conf/localhost-mako-registrar-config.xml config file for this specific example.)
<serviceAssociations>
This element contains any number of <serviceAssociation ...> sub-elements. Each sub-element takes two attributes, "serviceId" and "associationName". Set the "serviceId" attribute to the service ID of the service you want to handle requests for the service type you specify in the "associationName" attribute. The "associationName" attribute must align with the "associationName" defined in a "factoryAssociation ...> element. (Again, see the Mako /conf/localhost-mako-registrar-config.xml config file for an example.)
<serviceRegistry>
This element defines the service registry your Mobius service will use so that other Grid services can discover it. When the Mobius service is instantiated, it will attempt to register itself with the registry specified in this element. The element is required, even if the Mobius service does not register itself with a remote service registry. In that case, it "registers" itself with itself: the "serviceId" will be "localhost" and the "registryClass" attribute will be set to "org.projectmobius.client.common.DefaultRegistry". To have the Mobius service self-register on instantiation, however, we need to use the <serviceRegistry> element to identify some other Grid service registry (such as that within Globus or OGSA-DAI). A developer can extend Mobius and write a class that implements the service registry class interface (in "org.projectmobius.client.common") to perform registration with some non-Mobius Grid service registry, or she can use the Service Registry that is part of Mobius (registrar). In the latter case, set the "serviceId" attribute to a machine running a Mobius Service Registry instance, e.g., "REGISTRAR://resolvable.machine.name", and set "registryClass" to "org.projectmobius.common.registry.MobiusRegistrar".