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) |