| This is a critical area in distributed systems where a service may undergo changes, including the publicly available interface and/or implementation, over some specified period of time. Let us now explore how these changes are handled in OGSI Grid services, and what best practices one should adhere to when dealing with such dynamics. One should contend with the semantics of grid services as follows : -
The semantic of a grid service instance must be well defined by its interface definition; a combination of portTypes, operations, messages, types, and service data declarations. -
The implementation semantics must be consistent with the interface semantics; otherwise , it may confuse the client and may result in wayward behavior. Based on the previous observations, here are some important best practices to consider: -
Service interfaces and implementations should agree on the semantics of the service. -
If there is a change to the interface (e.g., syntax and/or semantics) it is recommended to provide a new interface to the client, as opposed to changing the existing interface. -
All the elements of a grid service element must be immutable. This means that the QName of the portType, operation, message, service data declaration, and associated types are immutable. Any changes in any of these should result in a new interface portType. -
New interfaces should always be created using a new portType QName (i.e., a local name and a namespace combination). Grid Service Interface Change Management Based on the above best practices, the port Type designs (i.e., the grid service public interfaces) are to be accomplished by taking into account that once a service interface is published to the customers, one cannot change it; instead, one can only provide a new interface with a new name. This is one of many best practices identified in this chapter. |
Grid Service Instance Handles, References, and Usage Models Every grid service implemented utilizing the OGSI specification should adhere to certain practices, which are important to the overall integrity of the service. One or more GSHs must be unique. This is key due to the fact that these handles uniquely identify a grid service instance that is valid for the entire life of a service. However, handles do not carry enough information to allow a client to communicate directly with the service instance. The service's GSH is based on a URI scheme [7] (e.g., http://) and the specific information (e.g, abc.com/myInstance). A client must resolve the GSH information to a service specific to the GSR discussed in the next section, in one of three ways: by itself, by using the mechanisms provided from the service provider (e.g., a HandleResolver service, which implements a Handle-Resolver portType), or by delegating to a third-party handle resolving service (e.g. www.handle.net ). One or more GSRs are key to access integrity. A client can access a grid service through the use of a GSR, which can be treated as a pointer to a specific grid service instance. A GSR is a remote service "reference" and contains all the information to access the service. The format of a GSR is specific to the binding mechanism used by the client to communicate with the service. Some examples of these binding formats include the following: A grid service instance may have one or more GSRs available to it. The GSRs are associated with a lifecycle that is different from the service lifecycle. When the GSR is no longer valid, the client should get a reference to the service using an available GSH. It is important to note that the specification recommends a WSDL encoding of a GSR for a service. Thus, we may find that most of the grid service implementers will support WSDL encoding as the default encoding, and based upon the performance and quality, can switch to other encoding. Listing 9.7. OGSI schema definition for GSR. targetNamespace = "http://www.gridforum.org/namespaces/2003/03/OGSI" <xsd:element name="reference" type="ogsi:ReferenceType"/> <xsd:complexType name="ReferenceType" abstract="true"> <xsd:attribute ref="ogsi:goodFrom" use="optional"/> <xsd:attribute ref="ogsi:goodUntil" use="optional"/> </xsd:complexType> Listing 9.7 shows the schema definition for the GSR. The optional lifetime attributes defined by the GSR schema provide the validity of that specific GSR. Recommended GSR Encoding in WSDL As of today, most of the accomplishments on binding are performed around the WSDL encoding of a GSR. This fact is of interest to the developers now faced with the construction of grid services. A discussion on WSDL encoding of a GSR with some samples is important. Listing 9.8 depicts this point of interest. Listing 9.8. XML schema for WSDL encoding of a GSR. targetNamespace = http://www.gridforum.org/namespaces/2003/03/OGSI" <xsd:complexType name="WSDLReferenceType"> <xsd:complexContent> <xsd:extension base="ogsi:ReferenceType"> <xsd:sequence> <xsd:any namespace="http://schemas.xmlsoap.org/wsdl/" minOccurs="1" maxOccurs="1" processContents="lax"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> Listing 9.8 depicts the XML schema for WSDL encoding of a GSR. The best practices on this encoding scheme are: -
The GSR reference must contain a WSDL definition element (i.e., with one service) as the child element. -
The WSDL definition element must contain only one WSDL service element, and may contain other elements from the "wsdl" namespace. -
The XML processing is set to "lax," which means XML parser validation is completed on this content element, based upon the availability of the "wsdl" definition schema; otherwise, no validation will be performed. This is accomplished by a runtime parser configuration, or by including "schemaLocation" for WSDL's XSD definition along with the XML message. Listing 9.9. A sample WSDL encoding schema of a GSR. <ogsi:reference xsi:type="ogsi:WSDLReferenceType"> < wsdl:definitions name="OperatingSystemDefinition" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> ........................................................ <wsdl:service name="OperatingSystemService"> < wsdl:port..........................</ wsdl:port> </ wsdl:service> </wsdl:definitions> </ogsi:reference> As the developer of the grid service, one should be aware of another helpful practice defined by the specification called service locator . This is a grid service locator class with zero or more GSHs, GSRs, and portTypes (identified by portType QName) implemented by the service. All of the GSHs and GSRs must refer to the same grid service, and the service must implement all of the defined port types. This logical grouping helps client devices have a unique view of any given service instance. Life Cycle of a Grid Service Instance The hosting environment manages the lifecycle of a grid service by determining how and when a service is created, and how and when a service is destroyed . It is important to understand that the OGSI specification does not direct that behavior. For example, a grid service based on an Enterprise Java Bean (EJB) has the same lifecycle properties and manageability interfaces and policies as defined by that EJB specification. The following describes lifecycle service creation patterns, as defined by the OGSI, to assist the clients of a grid service: -
A common grid service creation pattern is defined through the grid service factory interface (as discussed in the next sections) and through a createService operation. The service can decide whether or not to support this behavior, based upon the respective policies defined for the service. -
Two destruction mechanisms are defined: -
Calling an explicit destruction operation (i.e., destroy the operation on a specific GridService portType) -
Using a service-supported soft-state mechanism, based on the termination time attribute of a service Service Lifecycle Management Using a Soft-State Approach The soft-state lifetime management approach is a recommended method in the grid service lifecycle management process. Every grid service has a termination time set by the service creator or factory. A client device with appropriate authorization can use this termination time information to check the availability (i.e., lease period) of the service, and can request to extend the current lease time by sending a keep- alive message to the service with a new termination time. If the service accepts this request, the lease time can be extended to the new termination time requested by the client. This soft-state lifecycle is controlled by appropriate security and policy decisions of the service, and the service has the authority to control this behavior. For example, a service can arbitrarily terminate a service, or a service can extend its termination time, even while the client holds a service reference. Another point to keep in mind is whether or not to actually destroy a service, or just to make it unavailable. This is a service hosting environment decision. Some of the behaviors that we can infer from the specification are: -
A grid service can send lifetime event notifications using the standard grid service notification process. -
A grid service's support for the lifetime is implementation dependent, and one must consult the service documentation for the details on this behavior. -
A Client with proper authority can request for an early termination of a grid service. -
A grid service can extend the service termination time, or terminate itself, at any time during its lifecycle. Service Operation Extensibility Features of Grid Services Another interesting feature introduced by the specification is the concept of extensible operations through the use of untyped parameters using the XML schema xsd:any construct. This feature allows grid service operations maximum flexibility by allowing "any" parameters (i.e., XML fragments ) for that operation. However, this feature introduces confusion on the client side regarding the kind of parameters it can pass to the service. To avoid that confusion, the specification provides the client base with a mechanism (i.e., query capabilities) to ask the service about the supported extensible parameter and its type (XML schema) information. This example will make the preceding idea clearer. We have already discussed that we can use findServiceData of GridService to query the service data of a service instance. A service can support different types of queries, including query by service data names and query by XPath. The specification defines the input parameter of findServiceData as extensible, utilizing ogsi:ExtensibilityType. In this example, one can retrieve all the possible queries supported by the service instance from the SDE values of the service's "findserviceDataExtensibility" service data element. By default, a service provides a static query type value called "queryByServiceDataNames" defined by utilizing the staticServiceDataValue. These static SDE values are defined for GridService portType in the ogsi. gwsdl . We will see more details on the operation extensibility features when we discuss the grid service portTypes. Service Fault Handling in OGSI A <wsdl:operation> can define a fault message in the case of an operation failure. In many cases, a service developer decides on the message format and the contents. The OGSI defines a common fault message type to simplify the problem of different fault message types being defined. The OGSI defines a base XSD fault type (ogsi:faultType) that every grid service must return. Listing 9.10 explains the usage model of this fault type. Listing 9.10. Fault definitions in OGSI. <definitions name="OperatingSystem" ....> <types> <element name="targetInvalidFault" type="TargetInvalidFaultType"/> <complexType name="TargetInvalidFaultType"> <complexContent> <extension base="ogsi:FaultType"/> </complexContent> </complexType> ............................................... </types> <message name="TargetInvalidFaultMessage"> <part name="fault" element="targetInvalidFault"/> </message> ..................... <gwsdl:portType name="OperatingSystem"> <operation name="reboot"> <input...> <output...> <fault name=" TargetInvalidFaultMessage " message="TargetInvalidFaultMessage "/> <fault name="Fault" message="ogsi:faultMessage"/> </operation> </gwsdl:portType> ........................... <definitions> Here our reboot operation returns a fault message of the type TargetInvalidFaultType, which is of the OGSI-defined common fault type ogsi:FaultType. This provides applications to define and process a common model for all the fault messages. It is a mandatory recommendation that all grid service in addition to the operation-specific fault messages must return a "ogsi:faultMessage." This fault message is to return all the faults that are not defined by the service developer. Listing 9.10 above shows these requirements. Grid Service Interfaces The grid service interfaces and their associated behaviors are described by the OGSI specification. The UML interface hierarchy diagram, as shown in Figure 9.4, describes the OGSI-defined interfaces. Let us now explore the basic and essential information pertaining to service interface behaviors, message exchanges, and interface descriptions. Figure 9.4. OGSI-defined portTypes.  We can classify OGSI interfaces into three sets of interfaces based upon their functionality. These are the OGSI core , notification, and service groups. Table 9.4 describes the interface name, description, and service data defined for these interfaces, as well as the predefined static service data elements. As noted in the interfaces in Table 9.4, all grid services are required to implement the GridService portType and its respective behaviors. This interface and its associated service data set provide service-specific meta-data and information that one can use for dynamic service introspection, and being the core component of the OGSI specification, this interface warrants more attention. Table 9.4. portTypes That Support Grid Service Behaviors, Service Data Elements, and Static Service Data Values | PortType Name | Interface Description and Operations | Service Data Elements Defined by This portType | Default Service Data (static) Values | | GridService (required) | All Grid services implement this interface and provides these operations and behaviors. Operations: -
findServiceData -
setServiceData -
requestTerminationTimeAfter -
requestTerminationTimeBefore -
destroy | 1. interfaces 2. serviceDataName 3. factoryLocator 4. GridServiceHandle 5. GridServiceReference 6. findServiceDataExtensibility 7. setServiceDataExtensibility 8. terminationTime | <ogsi: findServiceDataExtensibility inputElement="queryByServiceDataNames" /> <ogsi: setServiceDataExtensibility inputElement="setByServiceDataNames" /> <ogsi: setServiceDataExtensibility inputElement="deleteByServiceDataNames" /> | | Factory (optional) | To create a new grid service. Operations: -
createService | 1. createServiceExtensibility | None | | HandleResolver (optional) | A service-provided mechanism to resolve a GSH to a GSR. Operations: -
FindByHandle | 1. handleResolverScheme | None | Inside the GridService portType The UML notations in Figure 9.5 show the details of this interface. Figure 9.5. The UML representation of GridService PortType.  As shown in Figure 9.5, this interface provides a number of service state attributes, and a number of operations common to all grid services. Focusing attention on the above interface definition, one can infer that the "findServiceData" and "setServiceData" are both extensible operations. They also provide the basic capability of passing any input parameters and returning any output parameter from the service. We will see the specific semantics in the following sections. Grid Service “Provided Service Data Query Capabilities: Syntax and Semantics The OGSI is provided as a common approach for discovering the state information from a grid service. Every grid service implements the GridService portType, and thereby a client can use the "findServiceData" operation on a grid service passing a query expression. The format and semantics of the query expression parameter is based upon the query support provided by the service. By default, every grid service must support the "queryByServiceDataName" query expression. This is a simple query, utilized by "findServiceData" by passing the QName of the service data element of interest to get the service data element values for that SDE. A grid service may support other query expressions, including XPath/XQuery. All query types including the predefined query types are stored in the "findServiceDataExtensibility" and "setServiceDataExtensibility" service data element values. Table 9.5 lists the predefined static extensibility types ("queryByServiceDataNames," "setByServiceDataNames," and "deleteByServiceDataNames"). The grid service implementation team must provide both the semantic and message formats of the extended query expressions. Consult the service and interface documentation to find out the specific details on this additional query support. Based on the previous discussion, let us now examine some examples of using the find operation. Let us first find all the supported query expressions from a service (a read-only query). The query syntax for this operation is as follows: findServiceData (ExtensibilityType queryByServiceDataNames), where the extensibility type contains the input message as shown in Listing 9.11. Listing 9.11. A query by a service data input message. <ogsi:queryByServiceDataNames> <name>ogsi:findServiceDataExtensibility</name> <! name of the service data element - -> </ogsi:queryByServiceDataNames> As described in Listing 9.11, note that the example is passing a known type of query expression "queryByServiceDataNames" and the service data name of interest in this query. In this case, the example is utilizing the "findServiceDataExtensibility" serviceData name, which is the holder of the read-only queryExpressions type supported by this specific service. The above operation may return an output message as shown in Listing 9.12: Listing 9.12. A query by service data output message. <sd:serviceDataValues> <ogsi:findServiceDataExtensibility inputElement="ogsi:queryByServiceDataNames"/> <!this is a mandatory return - -> <ogsi:findServiceDataExtensibility inputElement="ogsi:queryByXPath"/> <!may present - -> </sd:serviceDataValues> Listing 9.12 suggests that the service supports the default "queryByServiceDataNames" and a service-specific additional query expression "queryByXPath." It is also possible to dynamically determine all of the interfaces exposed by the grid services. The query syntax for this operation is utilizing findServiceData (ExtensibilityType interfaceSD) , where extensibility type contains the input message; this is shown in Listing 9.13. Listing 9.13. A query by service data input message. <ogsi:queryByServiceDataNames> <name>ogsi:interface</name> </ogsi:queryByServiceDataNames> The above operation may result in an output message as shown in Listing 9.14. Listing 9.14. The result of a find query for all support interfaces. <sd:serviceDataValues> <ogsi:interface> ogsi:GridService <!always will be present - -> cmm:BaseManageableResource cmm:OperatingSystem </ogsi:interface> ......................................................... </sd:serviceDataValues> Listing 9.14 suggests that this service implements interfaces, including the ogsi:GridService, cmm:BaseManageableResource, and the cmm:OperatingSystem. Grid Service “Provided Service Data Update Capabilities: Syntax and Semantics The previous section explains the "read-only" behavior of the service state. Some state information in a grid service is updateable or changeable by the client. This is similar to using set operations to update object properties in Java Beans or other language objects. As discussed earlier in this book, an OGSI service can specify whether a state data value is changeable by explicitly setting the modifiable attribute to "true." Every grid service must support the "setServiceData" operation with the "updateExpression" extensibility type parameter. The format and semantics of the update expression parameter are based on the update feature support provided by the service. For example, a service can provide simple state data, update data, or a complex XUpdate [8] update expression. We have noted that by default, every grid service provides two update expressions of type "setByServiceDataNames," and "deleteByServiceDataNames." Let us now explore some additional utilization examples. Let us find all the update expressions supported by the service. The query syntax is findServiceData (ExtensibilityType queryByServiceDataNames) , where the extensibility type contains the input message as shown in Listing 9.15: Listing 9.15. A query by service data input message. <ogsi:queryByServiceDataNames> <name>ogsi:setServiceDataExtensibility</name> <!this is a mandatory update expression type for all service - -> </ogsi:queryByServiceDataNames> The above operation may result in an ExtensibilityType, with an output message as shown in Listing 9.16: Listing 9.16. Supported update expressions. <sd:serviceDataValues> <ogsi:setServiceDataExtensibility inputElement="ogsi:setByServiceDataNames"/> <ogsi:setServiceDataExtensibility inputElement="ogsi:deleteByServiceDataNames"/> </sd:serviceDataValues> As shown in Listing 9.16, this service supports two types of updates, "setByServiceDataNames" and "deleteByServiceDataNames." Let us now apply a set operation on service data, with a "mutable" attribute of "true," using the supported "updateExpression" retrieved from the above step. The query syntax is setServiceData (ExtensibilityType updateByServiceDataNames) , where the extensibility type contains the input message as shown in Listing 9.17: Listing 9.17. An input message for the set operation. <ogsi:setByServiceDataNames> < someServiceDataElement NameTag > new SDE value(s) </ someServiceDataElement NameTag > </ogsi:setByServiceDataNames> The service handling of the set operation on service data is based upon a number of rules defined by OGSI. These rules include: -
The serviceData must be modifiable; the SDE-modifiable attribute must be "true." -
The serviceData mutability attribute should not be "static" or "constant." -
If the serviceData mutability attribute is "extendable," the set operation must append the new SDE values to the existing SDE values. -
If the serviceData mutability attribute is "mutable," the set operation must replace the existing SDE values with the new SDE values. -
The SDE values, "append" and "replace", must adhere to the minOccurs and maxOccurs attributes on SDE values. The partial failure on update and delete operations involving service data elements may be common due to the distributed nature of grid services and lack of concurrency in the distributed model. Therefore, the grid service provides partial failure indication faults and the client should be aware of dealing with that. This fault type extends "ogsi:FaultType" and must contain all the service data elements that cannot be updated with the one or more fault cause information schemas. Grid Service Factory Concepts This is an abstract concept or pattern that can be utilized to create a service instance by the client. This is an optional interface and provides an operation called "createService." Figure 9.6 illustrates the basic service creation pattern for a grid service instance. Once the creation process has been successfully executed, the factory returns the grid service locator (GSH and GSR) information, which can then be utilized by the client to locate the service. Figure 9.6. The grid service factory usage pattern.  The pattern does not mandate the creation of the instance; in the case of lazy creation, it may just return a GSH for the service; however, it will postpone the creation of the actual service instance. Another point to note regarding creation semantics is the dependency on the hosting environments; the specification does not mandate any implementation semantics. For example, we can infer that if the grid service instance is an EJB entity, the factory may correspond to the EJB home, which is responsible for the creation of an EJB entity bean. Grid Service Handle Resolution Concepts Handle resolving is a standard mechanism to resolve a GSH into a GSR. This is an optional feature based on the HandleResolver portType. A grid service instance that implements the HandleResolver portType is called a "handle resolver." This handle resolution process is implementation dependent and may be tied to the hosting environment. For example, in a J2EE environment, this handle resolution can be tied to the J2EE JNDI lookup, and hence, a JNDI server can be a HandleResolver service. Another example may be a global handle resolution service provider that can resolve the handle to any services registered with it. In some cases, a client can perform the resolution of service instance handle to a service reference. Figure 9.7 shows a simple handle resolution process. These resolving services may contain a cache of handles and GSRs and are capable of collaborating with other " resolvers " in order to resolve the handle. Once the handle is resolved, it returns a GSR for the service instance. Figure 9.7. A simple handle resolution process.  OGSI-Defined Grid Service Notification Framework Let us now explore some of the asynchronous messaging capabilities provided by the grid services. Notification is required in the process of sending asynchronous one-way messages from a service to the interested client. The OGSI defined a set of standard mechanisms for sending notification messages. This specification defines a rich set of concepts. OGSI Message Notification Concepts Are Robust A notification source is a grid service instance that implements the NotificationSource portType and is the source of the notification. A notification sink is a grid service instance that receives the notification messages from any number of sources. A sink must implement the Notification sink portType. A notification message is an XML element sent from the source to sink and the type of this element is based on the subscription expression. A subscription expression is an XML element that describes what messages should be sent from the notification source to the sink and when the message was sent. A subscription grid service is created on a subscription request and helps the clients manage the lifetime of the subscription. These subscription services are created on subscription and these services should implement NotificationSubscription portType. |
This form of messaging is key in Grid Computing discipline, and is described in Table 9.5. Table 9.5. portTypes That Support Grid Service Notification Framework, Service Data Elements, and Static Service Data Values | PortType Name | Interface Description and Operations | Service Data Elements Defined by This portType | Default Service Data (Static) Values | | NotificationSource (optional) | This enables a client to subscribe for notification based on a service data value change. Operations: -
subscribe | notifiableServiceDataName subscribeExtensibility | <ogsi: subscribeExtensibility inputElement="subscribeByServiceDataNames" /> | | NotificationSink (optional) | Implementing this interface enables a grid service instance to receive notification messages based on a subscription. Operations: -
deliverNotification | None | None | | NotificationSubscription (optional) | Calling a subscription of a Notification Source results in the creation of a subscription grid service. Operations: None defined | SubscriptionExpression sinkLocator | None | The OGSI-defined notification portTypes and their associated service data are shown in Table 9.5. Figure 9.8 depicts the notification flow. Figure 9.8. The simple sequence notification flow.  A sample notification process, as illustrated in Figure 9.8, involves the client creating a sink object to receive notification. This sink object is implementing the NotificationSink interface. The client discovers the available subscription types supported by the notification source by the query syntax findServiceData (ExtensibilityType subscribeByServiceDataNames), where the extensibility type contains the input message as shown in the following XML fragment. Listing 9.18. A query by service data input message. <ogsi:queryByServiceDataNames> <name>ogsi:subscribeExtensibility</name> </ogsi:queryByServiceDataNames> The operation in Listing 9.18 may result in an ExtensibilityType response message, with an XML message as shown in Listing 9.19: Listing 9.19. Subscription expressions. <sd:serviceDataValues> <ogsi:subscribeExtensibility inputElement="ogsi:subscribeByServiceDataName"/> </sd:serviceDataValues> As shown in Listing 9.18, this service supports a "subscribeByServiceDataName" subscription type. SubscribeByServiceDataName Subscription This subscription results in notification messages being sent whenever any of the named service data elements change. This subscription results in messages being sent based on two important attributes of this subscription, minInterval and maxInterval. As shown in this example, the message sent contains all the service data element values. |
Let us now explore where the client calls the service to subscribe for the service data name to pass the subscription expression of the type "subscribeByServiceDataName" with the associated interval properties and the GSH to where the messages must deliver the value. The service receiving this "subscribe" operation initiates the following actions: Whenever there is a service data change, and the criteria set for minimum and maximum interval meets acceptance, the source delivers an XML message to the sink after formatting the message based on the subscription criteria. Finally, when the client operation is completed with the service, it can kill the subscriptions by calling destroy on the subscription service. The behavior of this operation, such as removing the subscription, is a service implementation specific. Service Grouping Concepts in OGSI The third set of portTypes provides the grouping concepts for grid services. The grid services can be grouped based on certain classification schemes, or they can utilize simple aggregation mechanisms. Some example of grouping includes: -
Simple registries or index services where there is no specific classification scheme but are aggregated collections of services for discovery purposes. -
A federated service group to solve some specific problems including weather prediction, distributed load balancing, service cluster, and so on. Table 9.6 lists the OGSI-defined service group related to port types, operations, and service data elements. Table 9.6. portTypes That Support the Grid Service Grouping Behavior, Service Data Elements, Static Service Data Values | PortType Name | Interface Description and Operations | Service Data Elements Defined by This portType | Default Service Data (Static) Values | | ServiceGroup (optional) | An abstract interface to represent a grouping of zero or more services. This interface extends the GridService portType. Operations: No operations are defined but can use operations defined in a GridService portType. | MembershipContentRule entry | None | | ServiceGroupRegistration (optional) | This interface extends the ServiceGroup interface and provides operations to manage a ServiceGroup including add/delete a service to/from a group. Operations: -
add -
remove | addExtensibility removeExtensibility | <ogsi: removeExtensibility inputElement="matchByLocatorEquivalence" /> | | ServiceGroupEntry (optional) | This is a representation of an individual entry of a ServiceGroup and is created on ServiceGroupRegistration "add." Each entry contains a service locator to a member grid service, and information about the member service as defined by the service group membership rule (content). Operations: None defined | memberServiceLocator content | | The service group concepts introduced by OGSI are useful to build registries for grid services. Table 9.6 lists the OGSI-defined interfaces associated with this grouping. Based upon the observation on OGSI interfaces, and their service data, there can be two types of registries. These registries are locally managed registries and grid managed registries. Locally managed registries are created for internal use inside a grid system. These registries are derived from serviceGroup portType, and the registry entries (grid services) are created at start-up. The entries are added through configuration or using custom APIs. This grouping is "local" because no external grid operations are exposed from ServiceGroup portType. One typical use of such a registry is for the creation of a registry with a collection of service factories. Grid managed registries are derived from the ServiceGroupRegistration portType. This interface provides external operations to add and delete group entries into the registry. This portType is derived from ServiceGroup, and hence provides a private registry to hold the group contents. Figure 9.9 illustrates this concept. The ServiceGroupRegistrion is derived from ServiceGroup and the broken line indicates a logical operation. Figure 9.9. A sequence diagram showing the service group in action.  The best practice is applied for the registries to be externally managed, to create a service group deriving from ServiceGroupRegistration, and for all other cases (i.e., private, static, and internal) to create registries derived from ServiceGroup. Let us now explore the internal concepts introduced by the service group, including membership rules, service entries, and management. Membership Rules for a Service Group Deriving a service from the ServiceGroup portType, and utilizing the "MembershipContentRule" service data for the classification mechanisms can create a grouping concept similar to a registry. This "rule" (MembershipContentRule) service data is used to restrict the membership of a grid service in the group. This rule specifies the following: -
A list of interfaces that the member grid services must implement. -
Zero or more contents, identifiable through QName, that are needed to become a part of this group. The contents of QName are listed with the ServiceGroupEntry utilizing the "content" service data element. -
This service data has a mutability value of "constant," and hence these rules are created by the runtime on ServiceGroup service startup (i.e., in most of the cases). What follows is a sample rule definition with two rules: Listing 9.20. A service group membership rule sample. <memberShipContentRule> <memberInterface> crm:OperatingSystemFactory </memberInterface> <content> ogsi:CreateServiceExtensibilityType </content> </memberShipContentRule> < memberShipContentRule> <memberInterface> crm:OperatingSystem<memberInterface> <content> ogsi:CreateServiceExtensibilityType </content> </memberShipContentRule> Based upon the above rules, this service group contains grid services that implement either OperatingSystemFactory or OperatingSystem interfaces. In addition, the above rules specify a content rule, which states that the corresponding ServiceGroupEntry, created for each service in the group, must define the content with QName "ogsi:CreateServiceExtensibilityType." We will later explore this content information. The specific as to exactly how this rule is validated is an implementation decision. For example, using runtime type checking on the service can test the interface validity. Service Entries in a Service Group Another very important construct in the registry is the storage for the collection of services. The ServiceGroup provides a service data element called "entry," which provides a structure for the constituent members of the ServiceGroup. Each of these SDE values contains: -
A locator pointer to the serviceGroupEntry grid service instance that manages the constituent grid service instance ”a proxy to the real service instance -
A locator pointer to the member grid service instance -
The contents of the entry An example of such an entry is shown in Listing 9.21. Listing 9.21. A ServiceGroupEntry sample. <ogsi:EntryType> <serviceGroupEntryLocator> <ogsi:handle> http://localhost/ogsi/ServiceGroupEntry/osEntry </ogsi:handle> </serviceGroupEntryLocator> <memberServiceLocator> <ogsi:handle> http://localhost/ogsi/crm/OperatingSystemFactory </ogsi:handle> </memberServiceLocator> <content> <ogsi:CreateServiceExtensibilityType> <createsInterface>OperatingSystemFactory</createsInterface> </ogsi:CreateServiceExtensibilityType> </content> </ogsi:EntryType> ServiceGroupEntry This portType defines the interface through which the individual entries in ServiceGroup can be effectively managed. Every service in the group contains a corresponding ServiceGroupEntry instance. In fact, this can be treated as a "proxy" of a sort to the service instance. In the UML diagram shown earlier, a service client using a ServiceGroupRegistration service creates this proxy, and then adds the proxy to the ServiceGroup collection. A Simple Registry Utilizing the OGSI Service Group Concepts Let us now explore how a simple private registry holds factories responsible for the creation of grid services in a container. This is a locally managed registry for the factories of the services running in a container. An example is simply constructed , based upon the OperatingSystemFactory service, which is responsible for OperatingSystem creation. This registry implements the ServiceGroup portType. The meta-data in the registry comes from ogsi:Factory portType, where the service data specifies all the services that a factory can create. The following discussion is focused on creating this grouping service. Since most of the meta-data for the factory registry is well defined and quite static in nature, the data can be defined in a GWSDL description as static service data values. Listing 9.22. A service group containing grid service factories. <gwsdl:portType name="factoryServiceGroup" extends="ServiceGroup"/> <sd:staticServiceDataValues> <ogsi:EntryType> <serviceGroupEntryLocator nil="true"/> <memberServiceLocator> <ogsi:handle> http://localhost/ogsi/crm/OperatingSystemFactory </ogsi:handle> </memberServiceLocator> <content> <ogsi:CreateServiceExtensibilityType> <createsInterface>OperatingSystem</createsInterface> <createsInterface>GridService</createsInterface> </ogsi:CreateServiceExtensibilityType> </content> </ogsi:EntryType> <ogsi:EntryType> <serviceGroupEntryLocator nil="true"/> <memberServiceLocator> <ogsi:handle> http://localhost/ogsi/policy/PolicyEnforcementFactory </ogsi:handle> </memberServiceLocator> <content> <ogsi:CreateServiceExtensibilityType> <createsInterface>PolicyService</createsInterface> <createsInterface>GridService</createsInterface> </ogsi:CreateServiceExtensibilityType> </content> </ogsi:EntryType> <sd:staticServiceDataValues> The important information we can derive from the above listing is: -
Since these services are managed locally, the serviceGroupEntryLocator is not utilized. -
The memberLocator rule provides the handle to the factory instance, where we have two factories registered with this registry. -
The content rule states what type of services each factory can create. These services must conform to the interfaces identified in the logic. This registry, upon startup, loads this information and updates ServiceGroup's "membership-Rules" and "entry" service data fields. The client can utilize the standard grid service calls to discover the factory instances that can be utilized for creating the "operating system" services. The client can query the registry for all the ServiceGroup entries using the "findServiceData" operation, and passing the query expression as shown in Listing 9.23. Listing 9.23. A query to the registry. <ogsi:queryByServiceDataNames> <name> ogsi:entry </name> <ogsi:queryByServiceDataNames> The preceding query may result in the following result: Listing 9.24. Service group query results. <sd:serviceDataValues> <ogsi:EntryType> <serviceGroupEntryLocator nil="true"/> <memberServiceLocator> <ogsi:handle> http://localhost/ogsi/crm/OperatingSystemFactory </ogsi:handle> </memberServiceLocator> <content> <ogsi:CreateServiceExtensibilityType> <createsInterface>OperatingSystem</createsInterface> <createsInterface>GridService</createsInterface> </ogsi:CreateServiceExtensibilityType> </content> </ogsi:EntryType> </sd:serviceDataValues> The clients can now run an XPath query on the above results to find out the factory that can be used to create an "OperatingSystem" service using the XPath expression in the following logic: //ogsi:EntryType[content/ogsi:CreateServiceExtensibilityType/createInstance="OperatingSystem"]. This results in a list of EntryTypes that will create an operating system service. Again, to obtain the specific handle to the factory execution, this XPath query is: //ogsi:handle. The client can utilize this GSH to the factory, obtained by execution of the above step, in order to create the operating system service. We can now reduce the number of client-side XPath operations if the service supports a query by the XPath "operationExtensibility" type. In these cases, the client can issue the "findServiceData" call with the XPath information, and can then directly obtain the factory handle. Grid Services and Client Programming Models As presented in previous discussions, the details surrounding the concepts of OGSI are rich and robust across several dimensions. Let us now focus on exactly how to define the client-side programming patterns that interact with an OGSI-defined grid service. Earlier discussions were focused on how the OGSI is based upon Web services concepts, and how the core direction of this standardization process is on the interoperability between grid services and Web services. This interoperability can be achieved by using the OGSI standards-driven XML messages and the exchange patterns. The OGSI is not defining a new programming model, rather the OGSI is grounding itself upon the existing Web service programming model. At the same time, the OGSA provides some standard interaction pattern including conversion of the GSH to the GSR. The grid services are uniquely identified by the GSH. A client should convert the GSH (i.e., a permanent network-wide pointer) to a GSR prior to accessing the services. The GSH does not convey tremendous amounts of information; instead, the GSH provides the identity of a service. Once the client retains a GSR, it can access the service. There are two types of clients: Static. These kinds of clients have plurality of a priori knowledge on the runtime binding information. This includes aspects of native host system message mapping capabilities, the language maps, types for marshalling/de-marshalling of messages, creation of service helpers, and proxies. Normally speaking, the client uses the WSDL/GWSDL information to create these artifacts. These kinds of clients are faster, yet less flexible in operations. Any change in service description requires the recreation of the above artifacts. Dynamic. These types of clients are flexible and they are not bound to any predefined artifacts. They start from the service description discovery and runtime creation of interaction artifacts, including binding and type-mapping information. These types of clients are highly flexible, yet may perform with less efficiencies. The locator helper class, as defined by OGSI, provides an abstraction for the service binding process and handle resolution process. Most of the grid toolkits today may generate this artifact to help the client deal with GSHs, GSRs, and interactions between the two entities. The client framework is, in theory, simple, as illustrated in Figure 9.10. Figure 9.10. The client-side framework.  The client always needs to be aware of the GWSDL extension, and should rely on the tools for the transformation of GWSDL portTypes to WSDL portTypes for simplified aspects involving interoperability with existing WSDL 1.1 tools and frameworks. In the next section, we introduce specific implementations of the client-side artifacts from the perspectives of different grid toolkits. Grid Services and Service Programming Model The OGSI specification does not dictate particular service implementation architectures. There are numerous ways by which a developer can achieve this architectural environment, ranging from implementing grid services as operating system services, to the more sophisticated server-side component model as specified by J2EE or COM+. The OGSI services can be hosted in the smaller footprint pervasive devices, all the way up to the more sophisticated mainframe environments. A grid services implementation can provide host service protocol termination, and service behaviors, in the same executable or operating system service environments. Figure 9.11 shows an application providing protocol termination and the grid service implementation. Figure 9.11. A simple grid service implemented as an application.  Grid services can be implemented as components (e.g., Servlets, EJB, etc.) that can be hosted in a container, and the container along with the host environment provides the service protocol termination points and marshalling and de-marshalling of the messages. In this scenario, there may be requirements to adapt to the container behaviors and the models. For example, if a service is implementing itself as an EJB, the service lifecycle may need to be coherent with the EJB lifecycle model. Most of the grid toolkits tend to use this model for their middleware implementation. Figure 9.12 shows such a service implemented in J2EE Web containers. Figure 9.12. A container model for a service implementation.  Some of the key core service implementation requirements are as follows: -
Ability to provide a well-defined service description in GWSDL/WSDL -
Adhere to the XML message formats, as defined in the service description based on the OGSI specification -
Leverage the Web service infrastructure (and standards) for achieving message-level interoperability | 