The Mobius Project, OSU Department of Biomedical Informatics, Multiscale Computing Laboratory

Mobius Application Programming Interfaces (APIs) (common to all Mobius services)

The Mobius API consists of a hierarchy of well defined interfaces that provide application developers access to perform operations on Mobius Grid Services. GridServiceFactory implementations are the foundation of the Mobius API. Given a Grid Service Identifier (serviceId), a GridServiceFactory will create an handle to an instance of the proper implementation of the GridService interface. The handle to the GridService can then be used to perform operations on a Grid Service.

Factories are a key component to the Mobius API. They provide an abstraction between the client interfaces and the implementation, thus allowing multiple implementations on the client side. As the Grid evolves or application requirements change, implementations that use different communication layers or meet different performance requirements can be swapped in, without changing application code.

For more details on creating and using factories, see the GridServiceFactory section below.

The GridServiceResolver provides a method for managing factories, such that multiple factories may be used within an application. It is also used to get handles to Grid Services. Handles to grid services are obtained by providing the service identifier of the service. Handles to grid services are represented by the GridService object. The GridService object contains accessors for common grid service operations. The GridService object can be casted to a specific GridService object (e.g., XMLDataService) which would provide accessors to operations for that type of Grid Service. Below we show code for getting a handle to a Grid Service:

GridServiceResolver resolver = GridServiceResolver.getInstance();
GridService gs = resolver.getGridService("MAKO://localhost");
XMLDataService xds = (XMLDataService)gs;
List cols = xds.getCollection();

The GridServiceResolver resolves grid services by using GridServiceFactory objects. By default, the GridServiceResolver uses the default factory to resolve a grid service identifier; however, this requires that the default factory be set. Set the default factory as follows:

GridServiceResolver resolver = GridServiceResolver.getInstance();
resolver.setDefaultFactory(new NetworkServiceFactory());

Although using a default factory is often sufficient, there are cases where using the default factory is inadequate—if you have multiple Grid services that are interacted with through different implementations of client interfaces or if clients have varying configurations. To support the above case, the GridServiceFactory employs associations. That is, the GridServiceResolver allows you to associate a factory with a group and it allows you to associate Grid Service identifiers with that group. The code snippet below illustrates this:

GridServiceResolver resolver = GridServiceResolver.getInstance();
resolver.setDefaultFactory(new NetworkServiceFactory());
resolver.associateFactory(new SpecialFactory(),"SpecialGroup");
resolver.associateService("SPECIAL://localhost","SpecialGroup");

In the above code we set the default factory as well as create an association for a special group of services. Given the above configuration of the GridServiceResolver, if one wishes to get an instance of the service SPECIAL://localhost, the grid service resolver will use the SpecialFactory to resolve the service. If one requests an instance of the grid service MAKO://localhost, the GridServiceResolver would still use the default factory, however.

GridServiceFactories

As discussed above, Grid Service Factories provide an abstraction between the API and interaction with the Grid Services. In other words, they provide an abstraction between the client interfaces and implementation of those interfaces. Grid Service Factories are created by extending the abstract class, GridServiceFactory, and by implementing the resolveGridService() method.

Grid service factories can be configured through arguments, which can be defined by the implementer of the GridServiceFactory. Upon requesting a grid service, Grid Service Factories are validated to ensure that required arguments were specified. Below we show an example implementation of a GridServiceFactory class:

public class MyFactory extends GridServiceFactory {
  public MyFactory() {
    ArgumentDefinition protocol = 
      new ArgumentDefinition("PROTOCOL","The communication protocol",true,1,1);
    this.addArgumentDefinition(protocol);
  }
  protected GridService resolveGridService(String serviceId)
    throws MobiusException {
    String protocol = (String)this.getArgument("PROTOCOL").getValue();
    return new MyHandle(serviceId, protocol);
  }
}

The above code shows the implementation of a GridServiceFactory, MyFactory. You will notice in the constructor that an ArgumentDefinition is created for the communication protocol and that protocol is a required argument that must have only one value. In other words, the instantiator of MyFactory must specify one and only one protocol argument. The other area to note is the resolveGridService() method. It takes the value of the protocol argument and the service id specified by the caller to create an instance of MyHandle, which is assumed to implement the GridService interface. Next we will illustrate how one would instantiate and use MyFactory:

GridServiceFactory factory = new MyFactory();
Argument arg = new Argument("PROTOCOL","TCP");
factory.addArgument(arg);
GridService service = factory.getGridService("MY_GRID_SERVICE");

In the above code we create an instance of MyFactory, create the protocol argument, and add it to the factory. We then request a handle to a Grid service, which, assuming the factory can be validated, creates and returns a handle.