| A grid service is a stateful Web service. Because of this architecture model design fact, the service data concept requires the OGSI to identify a common mechanism to expose the state data of the service instance to the service requestor of the query, the update action itself, and finally enable the change notification to occur. In this case, the OGSI utilized the "service data declaration" as a mechanism for publicly expressing the available state information of a service. This concept, however, is not limited to grid services. The service data concept can be extended to any stateful Web service for declaring its publicly available state information through the service data concepts. Therefore, developers that were exposed to some of the more traditional distributed technologies, and their interface declaration (IDL) approaches, will be familiar with this somewhat similar concept. Some of the object-oriented distributed language interfaces use attributes declaration to indicate the exposed state/properties of the services they describe. The following describes the service data concepts introduced by the OGSI specification: -
Service data declaration (SDD) is a mechanism to expose a publicly available state of a service. -
Service data elements (SDE) are accessible through the common grid service interfaces ("findServiceData" and "setServiceData"). -
The internal state of a service should not be a part of the service data declaration. Provided that we have now discussed the usability of service data, let us now explore the concepts, semantics, and usage model of service data in the context of a grid service. How to Declare Service Data with a portType Listing 9.3. The service data element declaration and some static service data values. <gwsdl:portType name="OperatingSystem" extends="crm:BaseManageableResource ogsi:GridService"> <wsdl:operation name="reboot"> ................................ </wsdl:operation> ......................................... <sd:serviceData name="lifecycleModel" type="crm:lifecycleModelType" minOccurs="1" maxOccurs="1" nillable="true" mutability="static"/> <sd:serviceData name="serviceGroupType" ..... /> .................................................................... <sd:staticServiceDataValues> <crm:lifecycleModel> <lifecycleState name="down"> <subState name="restartable"/> <subState name="recovered"/> </lifecycleState> <crm:lifecycleModel/> ................................................ </sd:staticServiceDataValues> ................................................ </gwsdl:portType> Listing 9.3 shows how we can extend the GWSDL portType (name="OperatingSystem") with the contents of serviceData, which is used to define service data elements (SDE). Static service data values are defined in the WSDL portType and are available to all services that implement this portType. Four Service Data Concepts Service Data Elements (SDE). The publicly accessible service data XML elements that are defined inside gwsdl portTypes are called service data elements, or SDEs (e.g., as shown in the above listing, there are two SDEs, lifecycleModel and serviceGroupType). Service Data Declaration (SDD). The SDEs in the port type are referred to as service data declaration, or SDD (e.g., the above listing indicates that there are two SDDs available in the OperatingSystem portType). Service Data Element Values (SD values). These are values of the service data elements. These values are XML fragments . There may be a schema for the XML element fragment as defined by the SDE "type" attribute. There are two types of SD values based on service data element's mutability attribute value "static" and "dynamic" (e.g., the above listing shows that two service data elements and their values as static service data values, which are declared in the port type using <sd:staticServiceDataValues> element). Service Data Set (SD set). This can be a logical or physical collection of service data elements and their values for a service instance. This set is exposed through GridService portType public interfaces ("findServiceData," "setServiceData"). This is an aggregated collection of SDEs from all the port types in the interface hierarchy, which the service implements. |
Service Data Structure Service data is clearly modeled in the OGSI-defined namespace attribute, which is elaborated in the Web site www.gridforum.org/namespaces/2003/03/serviceData . This new OGSI schema type for service data ("sd:serviceData") contains seven predefined attributes, including name, type, minOccurs, maxOccurs, modifiable, mutability, and nilable. Most of these attributes are standard XSD types, with the exception of the "mutability" attribute. This is further defined by OGSI as an enumerated type, with values of "static," "constant," "extendable," and "mutable." Note that this schema allows us to always add additional attributes of choice. There is another notable, yet often underutilized feature in this instance provided by this type of definition. It is the open content model related to content from any other namespace. This feature may be utilized in the future to expose some policies or meta-data about the service data, including security profiles. Table 9.1 lists these attributes of service data and their default values. Table 9.1. Defines the details of the Service Data Element Attributes | SDE Attributes | Description and Default Values | | Name | This is a required attribute with a uniquely identifiable name of the service data element in the target namespace. | | Type | This is the other required attribute, which defines the XML schema type of the service data value, the SD value. The SD value is based upon this schema and can be defined as simple or complex in a manner related to XSD schema types, and/or one may define this in terms of other complex types. | | maxOccurs | This indicates the maximum number of SDE values that can appear in the service instance's SDE value set, or the portType staticServiceData Values. Default value = 1 | | minOccurs | This indicates the minimum number of SDE values that can appear in the service instance's SDE value set or the portType staticServiceDataValues. If minOccurs = 0, then this SDE is optional. Default value = 1 | | nilable | This indicates whether an SD value can have a nil value. One can declare this SDE as: <sd:serviceData name="lifecycleModel" type="crm:lifecycleModelType" nillable="true"/> Another valid SDE value is: <sd: lifecycleModel xsd:nil="true" />. Default value = false | | modifiable | This is a mechanism to specify a read-only and changeable service data element. If changeable , you can use "setServiceData" operation to change its SDE value based on the other attribute (mutability, min, and max) constraints. This modifiable attribute is applicable to the service requestor only. Internally a service can change its SDE values if other constraints are met. Default value = false (all SDEs are by default "read only") | | mutability | This is an indication of whether and how the values of a service data element can change. Possible values are "static" "constant" "extendable" "mutable" (see Table 9.4 for detailed information). Default value = "extendable" | This attribute set is extensible through the open attribute declaration of the schema's SDE. Therefore, the service can add more semantic information about a service data through attribute extensibility. An example of this extensibility is presented later with life cycle attributes for a service data element. Remembering the default values of these attributes will help us to understand and define a good state management framework for grid services. Based on the SD definition, and as shown in the above table, the required attributes for an SDE are "name" and "type" attributes and the service developer is expected to provide them. The other attributes have default values assigned to them. How Mutability Attributes Affect Service Data One of the most complex concepts of the service data element is its mutability attribute. Table 9.2 below shows the possible mutability attributes and the resulting SDE values. It also shows how we can define and initialize those values. Table 9.2. Service data element mutability attributes | SDE Mutability Attribute Value | Description of SDE Value | How to Define and Initialize This SDE Value | | Static | Analogous to a language class member variable. All portType declarations carry this service data value. | Inside GWSDL portType using <staticServiceDataValues>. We can see this example in the previous listing. | | Constant | This SDE value is constant and must not change. | This SDE value is assigned on the creation of grid service (runtime behavior). | | Extendable | Similar to the notion of appending values. Once added, these values remain with the SDE, while new values are appended. | Programmatically speaking, we can append new SDE values. The new values are appended while the old ones remain. | | Mutable | The SDE values can be removed and others can be added. | Programmatically speaking, we can change these SDE values and add new ones. | Types of Service Data Elements and Service Data Values Every service instance has a collection of service data elements it exposes through public interfaces. These service data elements can be classified into two types of attributes, based upon the creation semantics. These are: -
Static. Declared as part of the service's interface definition (GWSDL portType definition). -
Dynamic. Added to a service instance dynamically. This behavior is implementation specific. The client may know the semantics (type and meaning) of the service data, or can acquire that information from somewhere (service or third party) through meta-data exchange. For example, in order to process the dynamic SDE values, you may need to get the schema type information for the SDE values from a remote location. How to Discover Available Service Data Elements (Static and Dynamic) in a Service To support both types of service data, the client must get the complete list of service data elements in a service during runtime. The client can query a service to get the current list of service data elements using the findServiceData method of the grid service (the service instance keeps a list of SDE elements, both static and dynamic, in its "serviceDataName" service data SDE). We will see the details later when we discuss the GridService portType. |
We have already noted that the initial values of the service data element are specified in WSDL, yet only for SDEs with a mutability value of "static." We can see that in the aforementioned listing example. Service Data Implementation Notes The OGSI specification did not direct how the service data values for an SDE are stored in a service instance. The service implementation can make this decision, based upon the dynamic, persistence, and other constraints of the SD values. For real-time data behavior in a service, one may implement a "pull" mechanism for the respective service data value, whereas caching of SD values in a logical service data set can provide faster response. Even though the specification does direct the need for a prescribed SDE storage mechanism in the service side, it necessitates the need for a logical XML document model with "serviceDataValues" as the root element. This root element may contain service data element values in any encoding format. This is an implementation-specific behavior. |
The GWSDL portType Inheritance Affects the Service Data A grid service can support the portType inheritance model as defined by the GWSDL. We have already discussed this in this interface hierarchy. Let us now explore the causal impacts of how this inheritance model can affect the service data declarations that are associated with each portType in the inheritance chain. Listing 9.4 describes how the portType hierarchy and service data declarations work together. Listing 9.4. A port type hierarchy example to explain the service data aggregation scenarios. <gwsdl:portType name="base"> <sd:serviceData name="base_sd" type="xsd:string" minOccurs="1" maxOccurs="1" mutability="static" /> <!local SDE declaration and not abstract- -> <sd:serviceData name="local_sd" type="xsd:string" minOccurs="0" mutability="static" /> <sd:staticServiceDataValues> < base_sd>base</ base_sd> </sd:staticServiceDataValues> </gwsdl:portType> <gwsdl:portType name="derived_A" extends="base"> <sd:serviceData name="derived_A_sd" type="xsd:string" minOccurs="1" maxOccurs="1" mutability="static" /> <sd:staticServiceDataValues> < derived_A_sd >derived 1</derived_A_sd > </sd:staticServiceDataValues> </gwsdl:portType> <gwsdl:portType name=" derived _B" extends="base"> <sd:serviceData name="derived B_sd" type="xsd:string" minOccurs="1" maxOccurs="1" mutability="static" /> <sd:staticServiceDataValues> < derived B_sd> derived 2</derived B_sd > </sd:staticServiceDataValues> </gwsdl:portType> <gwsdl:portType name="most_derived" extends="derived_A derived_B"> <sd:serviceData name="most_derived_sd" type="xsd:string" minOccurs="1" maxOccurs="1" mutability="static" /> <sd:serviceData name="local_sd" type="xsd:string" mutability="static" /> <sd:staticServiceDataValues> < most_derived_sd >most derived</ most_derived_sd > <local_sd> local value D </local_sd> </sd:staticServiceDataValues> </gwsdl:portType> The service contains a union of all the service data elements defined in the portTypes that it implements. Table 9.3 shows how a service data aggregation occurred, with the inheritance hierarchy based on the above listing. This aggregation is based on the name of the service data element (QName) and, hence, only one service data element with the same QName is present in the service. Table 9.3. Service Data Element Attributes | If a service implements: | The service data set then must contain: | | Base | base_sd, local_sd | | Derived_A | base_sd, derived_A_sd, local_sd | | Derived_B | base_sd, derived_B_sd, local_sd | | most_derived | base_sd, derived_A_sd, derived_A_sd, most_derived_sd, local_sd (with a value of 'local value D') | For example, Listing 9.4 utilizes only one <local_sd> element in the most_derived portType because the base portType's <local_sd> and most_derived portType's <local_sd> has the same local name, and they belong to the same targetNamespace. Another important aspect to pay close attention to is on the static service data value aggregation model in the case of port type inheritance. This process adds the following conclusions: The values of the static elements are aggregated down the interface hierarchy: -
If a portType contains a static SD element, yet does not specify a static service data value, then that portType can be treated as: -
Abstract if the minOccurs is not 0, and we must provide some value in our derived port types. -
If minOccurs is 0, then the static service data will not be initialized . -
The cardinality requirements (i.e., minOccurs and maxOccurs) on service data elements must be preserved. This is especially true in the case of static inheritance. For example, if the maximum service data element values allowed is set to 1, then the derived types must conform to that rule, as it cannot set more than a single value. We should refer to the OGSI specification for more examples, and best practices guidelines, on these cardinality constraints. We can also see information on how to define an abstract portType with the SDE, how the implementation and tools should check for cardinality violation, and so on. Qualifying Service Data Element with Lifetime Attributes In addition to the expressed features of the service data as previously discussed, there is also a "hidden" concept in the specification with respect to the lifetime properties associated with the service data elements. The concept is hidden because it is just a recommendation that the service/client implementation could possibly ignore. However, good designs, programs, and tools should be aware of this feature. The service data element represents the real-time observations of the dynamic state of a service instance. This real-time observation forces the clients to understand the validity and availability of the state representation. That is, certain service data elements, especially within dynamic SDEs, may have a limited lifetime. If there is lifetime information associated with the SDE, it can help the client to make decisions on whether an SDE is available, has validity, and when it is to revalidate the SDE. The most helpful development implementation of this concept may be the client-side service data cache, and an associated revalidation mechanism. Based on the preceding requirements, the specification provides three kinds of lifetime properties: -
The time from which the contents of this element are valid (ogsi:goodFrom) -
The time until which the contents of this element are valid (ogsi:goodUntil) -
The time until which this element itself is available (ogsi:availableUntil) The first two properties are related to the lifetime of the contents, while the third, the availableUntil attribute, defines the availability of the element itself. For example, we may see a dynamic SDE with availability until a specific time, and thereafter, it ceases to exist. This is a good indication for the users of this specific service data element not to use that SDE after that specified time. According to the specification, these values are optional attributes of the SDE element and the SDE values; however, it is always recommended to include the optional attributes in the XML schema design of the types for the service data elements. Listing 9.5 includes a service data declaration (myPortType), its type (myType), and these lifetime attributes, through open content XML schema type attribute declarations (##any). Listing 9.5. An SDE "myPortType" and the SDE type "myType" with the open content attributes (anyAttribute) for a lifetime attribute declaration. <wsdl:types> <xsd:complexType name="myType"> <xsd:sequence> <xsd:element name="myElem" type="xsd:string"/> </xsd: sequence > <anyAttribute namespace="##any" /> </xsd:complexType> </wsdl:types> <gwsdl:portType name ="myPortType"> <sd:serviceData name="mySDE" type="myType" /> .......... </gwsdl:portType> Based on the service data declaration in the above listing, one may assume that an instance of a service data element may contain the following values (Listing 9.6): Listing 9.6. Instantiated service data values for an SDE based on the lifetime service data declaration (in Listing 9.5), and its possible lifetime properties. <sd:serviceDataValues> < mySDE goodFrom="2003-04-01-27T10:20:00.000-06:00" goodUntil="2003-05-20-27T10:20:00.000-06:00" availableUntil="2004-05-01-27T10:20:00.000-06:00"> <myElem goodUntil="2003-04-20-27T10:20:00.000-06:00" > test </ myElem> </ mySDE> </sd:serviceDataValues> Listing 9.6 has instantiated service data values inside of the service instance, for the "mySDE" SDE, grouped under the logical <serviceDataValues> root element. Listing 9.6 shows that the subelements in the SDE values (myElem) can override the goodUntil lifetime property to a new time earlier than that of the parent (mySDE). The attribute extension (anyAttribute) of the SDE element schema and the XML schema type of the SDE (shown in Listing 9.5) values makes this override feature possible. This is a best practice recommendation for service developers and modelers for fine-grain control of lifetime properties of a service data element value. If the service data element and its value do not contain the declaration of these properties, then the goodFrom, goodUntil, and availableUntil properties are unknown. Summary on OGSI-Defined Service Data Concepts To conclude our discussion on service data, we list the core advantages of using this programming model: -
Provides an aggregated view of the service state rather than individual state values or properties -
Gives a document-centric view (XML documents) of the data, thereby avoiding specific methods for state access -
Shows flexibility in supporting dynamic state information and service state introspection -
Provides lifetime and subscription support on the state properties -
Enables dynamic construction of state data information elements and values and the declaration of static values for the state |
