1
|
- June 9, 2003
- sggraham@us.ibm.com
- Global Grid Forum
|
2
|
- Motivation/Requirements
- Associating ServiceData with portTypes
- Modeling ServiceData “like” XSD:element
- Operations on ServiceData
|
3
|
- 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
|
- 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
|
- 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
|
- 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
|
- <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
|
- 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
|
- 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
|
- 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
|
- <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
|
- <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
|
- 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
|
- GridService portType defines several operations:
- findServiceData(expression)
- queryByServiceDataNames expression
- setServiceData(expression)
- setByServiceDataNames expression
- deleteByServiceDataNames expression
- Modifies only SDEs where modifiable=“true”
|
15
|
- 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
|
- 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
|
- 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
|
- 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
|
|
20
|
- 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
|
- 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)
|