Review of OGSI ServiceData
June 9, 2003
sggraham@us.ibm.com
Global Grid Forum

Agenda
Motivation/Requirements
Associating ServiceData with portTypes
Modeling ServiceData “like” XSD:element
Operations on ServiceData

Motivation
In Grid computing (particularly infrastructure)
Modeling stateful Web service instances (with identity)
Certain services have complex state
Dozens (perhaps many dozens) of state elements
Many of these state elements need to be publicly accessible
get, set, query, subscribe for state change notification
These motivations are shared in other systems management contexts that may use Web services

Accessing Publicly Available State
We would like service requestors (for example management applications) to be able to:
Access publicly available state data from Web services
We would like service providers to:
Declare which elements of their state are publicly accessible
Modeled at the interface level
Which elements are readable, writeable, subscribable
Declare operations that allow get, set, query across multiple elements, and subscribe
Declare “dynamic state data elements”
e.g. elements of state that are available only because of a particular service life cycle value.

Motivating Examples
For all the instances of “diskDrive” interface
Find me all the ones where
percentFull < 80% and contiguousAvailableSpace > 100 MB
For the “manageableResource” interface
If the lifecycleState = “crashed”
Access the “stackTrace” state element
“stackTrace” is not a part of the service’s state in most circumstances

Associating ServiceData with PortTypes
Modeled state elements as “serviceData elements”
SDE is an extension and restriction of XSD:element
SDEs are declared within a WSDL interface
 <gwsdl:portType name="NCName"> *
      <wsdl:documentation .... /> ?
      <wsdl:operation name="NCName"> *
      <sd:serviceData name="NCName" … /> *
      <sd:staticServiceDataValues>?
         <some element>*
      </sd:staticServiceDataValues>
   </gwsdl:portType>

Example PortType with SDEs
<wsdl:definitions xmlns:tns=”xxx” targetNamespace=”xxx”>
   <gwsdl:portType name="exampleSDUse"> *
      <wsdl:operation name=…>
      <sd:serviceData name="sd1" type=”xsd:String”
                        mutability=”static”/>
      <sd:serviceData name="sd2" type=”tns:SomeComplexType”/>
      <sd:staticServiceDataValues>
         <tns:sdl>initValue</tns:sd1>
      </sd:staticServiceDataValues>
   </gwsdl:portType>
</wsdl:definitions>

What this means
When a portType contains SD declarations
any service that implements this portType will include an element with that name and type
as part of its publicly available state
The requestor can view the service as “providing” an XML document that models its state
Root of the document is “serviceDataValues”
Content is like xsd:all of the SD declarations in all of the service’s portTypes

SD Declarations and PortTypes
OGSI models portType inheritance using gwsdl:portType
Modeled like W3C proposal for interface inheritance
GGF commits to moving to WSDL 1.2 when W3C is finished
SDs are inherited down a gwsdl:portType inheritance hierarchy
Overloading is handled like operations
SDEs are namespace qualified
Duplicate SDEs are elided
Values can be associated with (certain) SD Declarations
Only SDEs where mutability=“static”
These are like “class constants”
Values are aggregated down a portType inheritance hierarchy

Declaring ServiceData
ServiceData is a lot like xsd:element
ServiceData is a restriction of xsd:element
annotation;
name; type; minOccurs; maxOccurs; nillable; and anyAttribute
ServiceData is an extension of xsd:element
open content
modifiable
can this SDE be changed by requestor
mutability
how can requestor reason about how the SDE values change
static, constant, extendable, mutable

Example SD Declarations
 <sd:serviceData name=”interface” type=”xsd:QName”
        minOccurs=”1” maxOccurs=”unbounded”
        mutability=”constant”/>
<sd:serviceData name=”serviceDataName” type=”xsd:QName”
        minOccurs=”0” maxOccurs=”unbounded”
        mutability=”mutable” nillable=”false”/>
<sd:serviceData name=”factoryHandle”
        type=”ogsi:HandleType”
        minOccurs=”1” maxOccurs=”1”
        mutability=”constant” nillable=”true”/>

Example ServiceDataValues
<sd:serviceDataValues>
   <ogsi:interface>crm:GenericOSPT</ogsi:interface>
   <ogsi:interface>ogsi:GridService</ogsi:interface>
   <ogsi:serviceDataName>ogsi:interface
   </ogsi:serviceDataName>
   <ogsi:serviceDataName>ogsi:serviceDataName
   </ogsi:serviceDataName>
   <ogsi:serviceDataName>ogsi:factoryHandle
   </ogsi:serviceDataName>
<sd:serviceDataValues>

Other SDE Aspects
Dynamic ServiceData
SDEs can be dynamically “added” to the set of SDEs
This is done by the service implementation extending the SDE named “ServiceDataName”
Defined in GridService portType
Time-related attributes
goodFrom
goodUntil
availableUntil

Operations on SDEs
GridService portType defines several operations:
findServiceData(expression)
queryByServiceDataNames expression
setServiceData(expression)
setByServiceDataNames expression
deleteByServiceDataNames expression
Modifies only SDEs where modifiable=“true”

FindServiceData Example
List of valid expressions for findServiceData
findServiceDataExtensibility SDE
A findServiceData operation with the following argument:
<ogsi:queryByServiceDataNames>
   <name>ogsi:findServiceDataExtensibility</name>
   <name>ogsi:setServiceDataExtensibility</name>
</ogsi:queryByServiceDataNames>
Would return:
<sd:serviceDataValues>
   <ogsi:findServiceDataExtensibility
         inputElement=”ogsi:queryByServiceDataNames”/>
   <ogsi:setServiceDataExtensibility
         inputElement=”ogsi:setByServiceDataNames”/>
   <ogsi:setServiceDataExtensibility>
         inputElement=”ogsi:deleteByServiceDataNames”/>
</sd:serviceDataValues>

SetServiceData example
List of valid expressions for setServiceData
setServiceDataExtensibility SDE
A setServiceData operation with the following argument:
<ogsi:setByServiceDataNames>
   <tns:sde1>someValue</tns:sde1>
   <tns:sde1>someOtherValue</tns:sde1>
   <tns:sde2>someValue</tns:sde2>
</ogsi:setByServiceDataNames>
Result is dependent on the mutability of the SDE
“static” and “constant” cannot be set
“extendable” results in “append” semantics
“mutable” results in “replace” semantics
Cardinality rules must be obeyed
For those SDEs that (for whatever reason) fail to be updated
Their values appear in the result output

SetServiceData example - Delete
A setServiceData operation with the following argument:
<ogsi:deleteByServiceDataNames>
   <name>tns:sd1</name>
   <name>tns:sd2</name>
</ogsi:queryByServiceDataNames>
Result is dependent on the mutability of the SDE
“static” and “constant” and “extendable” cannot be deleted
“mutable” results in deletion of all values of that SDE
Cardinality rules must be obeyed
For those SDEs that (for whatever reason) fail to be deleted
Their values appear in the result output

Operations related to StateChange
NotificationSource portType
NotifiableServiceDataName SDE
List of SDE names that support state change notification
subscribeExtensibility SDE
List of subscription expressions supported
subscribe(expression)
subscribeByServiceDataNames expression

Backups

Option 1 – model as operations
Use getters/setters to access “attributes”
Similar to JavaBeans pattern
no new concepts
explosion of # messages, parts and operations in the interface
Relies on programmer adhering to a convention
No simple multi-attribute query
At best only hard coded queries
No notion of “dynamic” state elements

Option 2 – Model as First Class Concept
Introduce an “Attribute” concept to wsdl:interface
Similar to attribute in CORBA IDL
Core idea:
Elements of publicly available state are  modeled using XML Schema element
State of a Web service instance is modeled “logically” as an XML instance document
Define operations: get, set, query, [subscribe]
Elements of state are modeled with the interface definition as attributes
Use attributes to convey state and meta-data of the service
Client proxy generators can still generate type-specific getters/setters (if they want)