Technical Details of OGSI Specification

     

The last section provides us with the basic concepts of grid service, the terminologies used, relationships with distributed technologies, and how we can align grid services and Web services. Let us now explore the core technical underpinnings of the OGSI specification with more elaborate samples and explanations . This discussion helps grid services developers, and tool vendors , to get detailed information on the OGSI usage model. We recommend referring to the OGSI specification for more clarification on these concepts. We will start with the OGSI extensions on WSDL.

OGSI and Its Use of WSDL

OGSI is based on Web services and it uses WSDL as a mechanism to describe the public interfaces of the grid service. There are two core requirements for describing Web services based on the OGSI:

• The ability to describe interface inheritance

• The ability to describe additional information elements (state data/attributes/properties) with the interface definitions

Similar to most Web services, OGSI services use WSDL as a service description mechanism, but the current WSDL 1.1 ^[4] specification lacks the above two capabilities in its definition of portType. The WSDL 1.2 ^[5] working group has agreed to support these features through portType (now called "interface" in WSDL 1.2) inheritance and an open content model for portTypes. As an interim solution, OGSI developed a new schema for portType definition (extended from normal WSDL 1.1 schema portType Type) under a new namespace definition, GWSDL .

This being one of the most important and challenging parts of the OGSI specification, we need to spend some time analyzing the GWSDL schema and its relation to WSDL.

Listing 9.1. The WSDL PortType definition schema in the GWSDL namespace.

 ... <schema targetNamespace =   http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions xmlns:gwsdl       = http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ... <import namespace="http://schemas.xmlsoap.org/wsdl/"/> <element name="portType" type="gwsdl:portTypeType"/> <complexType name="portTypeType">    <complexContent>       <extension base="wsdl:portTypeType">          <sequence>             <any namespace="##other"                  minOccurs="0" maxOccurs="unbounded"/>          </sequence>          <attribute name="extends" use="optional">             <simpleType>                <list itemType="QName"/>             </simpleType>          </attribute>          <anyAttribute namespace="##other"/>       </extension>    </complexContent> </complexType> </schema> 

Listing 9.1 shows the WSDL schema definition in the GWSDL namespace. The important information conveyed by this schema definition includes:

• An XML element "portType" is defined in the GWSDL namespace ("gwsdl:portType").

• The XML element "portType" is extending (XML schema extension) the "wsdl:portTypeType," which is defined by WSDL 1.1 schema.

• An open content element model for port type content from any other namespace using <any namespace="##other" />. This enables us to embed any XML elements from namespaces other than "gwsdl" inside the gwsdl:portType element.

• This new element adds an optional attribute called "extends," which takes the QName list. Note that these QNames must be either a wsdl:portType or gwsdl:portType name.

• An open content attribute model by using <anyAttribute />. This provides us with the flexibility of adding any attributes to "gwsdl:portType."

Based on the previous discussion regarding the GWSDL portType declaration, let's create a sample GWSDL port type definition.

Listing 9.2. A sample GWSDL portType.

 <gwsdl:portType name="OperatingSystem" extends="crm:BaseManageableResource ogsi:GridService"> <wsdl:operation name="reboot"/> <wsdl:operation name="shutdown"/> <sd:serviceData name="lifecycleModel"  ..... /> <sd:serviceData name="serviceGroupType"  ..... /> </gwsdl:portType> 

In Listing 9.2, we are utilizing the "gwsdl:portType" with the name "OperatingSystem" and it extends two other port types, crm:BaseManageableResource and ogsi:GridService, respectively. The open content model of the gwsdl:portType now allows new elements into the portType definition from other namespaces such as "sd:serviceData," as shown in the listing.

Significance of Transforming GWSDL to WSDL Definition

It is, however, a known fact that none of the WSDL 1.1 tools can handle these extensions. Most of them will fail on WSDL validation. The current WSDL 1.1 manipulation tools are used to create native language interfaces, stubs, and proxies from WSDL, and for the converse process of creating WSDL from the services implemented in native language. These functions have to be intelligent in order to handle these extensions. Basically, GWSDL extensions are to be transformed to WSDL 1.1 artifacts. This includes:

• All the "extends" port types, and their operations, which are brought down to a single most derived portType. This process is called "flattening" of the interface hierarchy to the most derived type.

• All the service data elements and GWSDL extensions are retained for the reverse transformation process.

Some work has been accomplished in the GGF OGSI WG to define a normal process of defining the above transformation process. ^[6] Let us explore and illustrate this transformation process through the following discussion and example illustration.

Figure 9.3 shows a simple transformation process (i.e., port type flattening), where the GWSDL portType OperatingSystem extends the BaseManageableResource and GridService declarations. These declarations are subsequently flattened to a WSDL portType OperatingSystem, with all operations from its parent. It is worthy to note that the WSDL 1.1 tools can all work on this newly emerged portType definition.

Figure 9.3. The WSDL 2 WSDL transformation process.

Operator Overloading Support in OGSI Port Type

Another important aspect of the OGSI is the naming convention adopted for the portType operations, and the lack of support for operator overloading. In these situations, the OGSI follows the same conventions as described in the suggested WSDL 1.2 specification. This now becomes rather complex across several different dimensions, especially in the context of interface inheritance, and the process of transformation to a single inheritance model as previously described. In these kinds of situations, we have to adhere to the OGSI recommendation.

The OGSI recommends that if two or more port type operation components have the same value for their name and target namespace, then the component model (i.e., the semantic and operation signature) for these operations must be identical. Furthermore, if the port type operation components are equivalent, then they can be considered as candidates to collapse into a single operation.

Port Type Operation Considerations Are Key

There is a consensus among OGSI work group members to follow the WSDL 1.2 specification in all respects. This agreement may eliminate the new schema and namespace (GWSDL) introduced by the OGSI when WSDL 1.2 reaches the recommendation stage.

Therefore, related to current utilization and for backward compatibility, developers of tools and applications should consider the use of the GWSDL extensions. In addition to the WSDL 1.2 recommendation, one should become familiar with the Web Services-Interoperability (WS-I) basic profile best practices guidelines for interoperable Web services and grid services.

Let us now explore one of the most interesting concepts of a somewhat common approach to describe the publicly available state information of a service and its architectural model.