Advertisement Overview

caGrid provides the service infrastructure necessary to leverage MDS to enable service advertisement. The advertisement is made possible by realizing the conceptual caGrid standard metadata, described in the previous chapter, as ResourceProperties of caGrid services. Each caGrid service is expected to create a singleton Resource to manage its service metadata. Each service metadata item the service wishes to expose, is represented as a separate ResourceProperty of this singleton Resource. For example, a Data Service may expose two metadata items: ServiceMetadata, and DomainModel. Each of these items will be represented as ResourceProperties, contained in the ResourcePropertySet of the singleton Resource of the service.

The caGrid provided implementation of ResourceHome, BaseResourceHome, manages the initial creation and management of the singleton Resource. The caGrid provided implementation of Resource, BaseResource, contains all of the logic necessary to manage the collection of service metadata items, populate them from a file, and advertise them to an Index Service. The ResourceConfiguration class maintains the information needed to configure the advertisement process. Each of these classes and the corresponding configuration files are managed by Introduce. When a service developer adds or removes service metadata in Introduce, these files are edited, using code generation capabilities, to reflect the metadata configuration of the service. Developers not using Introduce to create their services can either: reuse these classes as a starting point, use this design and re-implement it, or use a completely separate process. The only requirement is that the end result is caGrid standard metadata exposed as ResourceProperties of a singleton Resource of their service. The implementation requires that each metadata item be represented as a Java Bean capable of serializing itself to XML and deserializing itself from XML. caGrid provides XML Schemas describing the XML format of its standard metadata items. These XML schemas are used to generate appropriate Java Beans. The BaseResource, when initialized, will read the ResourceConfiguration. This configuration will specify which metadata items are to be instantiated from corresponding XML files, and where those files are located. It then will read each file, and deserialize the metadata instances. Those metadata items that are not populated from file are expected to be instantiated from the service's implementation code. Once the metadata items are instantiated, the BaseResource creates and populates its ResourcePropertySet with all of the appropriate items. These metadata items are then made available as service metadata exposed as ResourceProperties of the service's singleton Resource.

The final process the BaseResource performs on initialization is the registration, or advertisement, of the appropriate metadata items to the Index Service. Again, this process is configured through the ResourceConfiguration. For each metadata item, the configuration specifies whether or not the Index Service should aggregate its value. This enables services to expose some service metadata as ResourceProperties, but not register it with the central Index. Additionally, the configuration specifies the location of a registration configuration file. This file is used to configure the MDS registration process. The file specifies which Index Service to register with, how the Index Service should obtain the values of the metadata being registered (on configuration options of that method), and which metadata items are being registered.

Advertisement Client

To perform the actual advertisement of this service metadata, caGrid leverages a component called the Advertisement Client, which leverages the MDS ServiceGroupRegistrationClient to perform the Index Service registration. It handles the "soft state registration" process, wherein the service periodically renews its registration with the Index Service for the duration of the service's lifetime. The registration with the Index Service is only valid for a short lifetime (several minutes) and if the service fails to renew its registration, the Index Service will purge its corresponding entry. This dynamic process guarantees that Index Service will only contain relevant entries, as expired entries are discarded. It also ensures that the Index Service contains the most recent value of the metadata items, as it periodically gets the latest value using the process specified by the service at registration time. This process ensures that the integrity of the caGrid "yellow and white pages" will survive periodic Index Service failure, registered service failure, and general network failures. It should be noted, however, that there are various delays in this process and the Index Service will always contain slightly stale information, and if the most up to date information is needed, it should be extracted from the service in question directly. The Advertisement Client is essentially just a wrapper for the ServiceGroupRegistrationClient, which adds some features the current MDS client lacks (such as removal of entries at service shutdown). This approach was taken, as it is expected future versions of the MDS client will add these features, and the use of a specialized Advertisement Client, abstracts service developers from these changes. The public API of the Advertisement Client is very simple; it basically provides register() and unregister() methods, where the constructor takes the aforementioned MDS configuration parameters. The register method is a simple pass-thru to the ServiceGroupRegistrationClient, where the unregister method is basically a pass-thru to another new caGrid API called the Termination Client (described shortly). The main novel aspect of the Advertisement Client is that in its constructor, it registers a JVM Shutdown Hook, to be sure unregister is called when the JVM is shutdown to ensure the service is unregistered when its container is shutdown. Additionally, the Advertisement Client registers itself to receive asynchronous status update callbacks from the ServiceGroupRegistrationClient, which is logs appropriately.

The Termination Client is a general API which can be used to unregister a particular EPR from a given (passed into the constructor) Index Service. The Advertisement Client constructs one, passing the Index Service from its configuration, and calls unregister, passing the EPR of the service it registered. The unregister method first locates any registrations in the Index Service which correspond to the given service EPR, and for each, it leverages the WS-ResourceLifetime capability to set the termination time on the resource to 5 seconds in the future. The Index Service then has a background process that looks for registration resources with a termination time in the past, and removes them, thus unregistering the service. This process is slightly complicated, as the Index Service's registration resources don't support immediate termination, nor does the ServiceGroupRegistrationClient return the EPRs to the registration resources (so they must be discovered). The upside to this more complicated process is that any past registrations that may exist and which didn't get removed, are also terminated. The Advertisement Client makes use of this by unregistering the service (using the Termination Client) before it attempts a new registration.

The Termination Client supports the setting of a security descriptor such that authorization on the registration resources could be supported. While caGrid's Index Service currently does not require authentication or authorization, the Advertisement Client allows such a descriptor to be passed in through the MDS configuration, and appropriately passes it along to the Termination Client if it is present.