Notes
Slide Show
Outline
1
Review of OGSI ServiceData
  • June 9, 2003
  • sggraham@us.ibm.com
  • Global Grid Forum
2
Agenda
  • Motivation/Requirements
  • Associating ServiceData with portTypes
  • Modeling ServiceData “like” XSD:element
  • Operations on ServiceData
3
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
4
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.
5
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

6
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>
7
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>
8
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
9
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
10
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

11
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”/>
12
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>
13
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


14
Operations on SDEs
  • GridService portType defines several operations:
    • findServiceData(expression)
      • queryByServiceDataNames expression
    • setServiceData(expression)
      • setByServiceDataNames expression
      • deleteByServiceDataNames expression
      • Modifies only SDEs where modifiable=“true”
15
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>
16
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

17
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

18
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


19
Backups
20
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
21
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)