Modeling Elements of Web Service State in WSDL May 12, 2003 Global Grid Forum

2 Situation 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

3 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.

4 Examples For all the instances of diskDrive interface –Find me all the ones where percentFull 100 MB For the manageableResource interface –If the lifecycleState = crashed Access the stackTrace state element –stackTrace is not a part of the services state in most circumstances

5 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

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

7 In OGSI – ServiceData Elements Modeled state elements as serviceData elements –SDE is an extension and restriction of XSD:element –SDEs are declared within a WSDL interface * ? * … * ? * …

8 Example PortType with SDEs * … <sd:serviceData name="sd1" type=xsd:String mutability=static/> … initValue …

9 SDEs in OGSI SDEs are inherited down an interface inheritance hierarchy Operations are defined in the GridService interface (base) –get (findServiceData(expression)) –set (setServiceData(expression)) –subscribe (NotificationSource::subscribe(expression)) –Dynamic service data is supported GridService has a serviceDataName SDE –SDE values are conveyed using a container element

10 Concerns This is ok to model in gwsdl:portType, but: –This facility is useful for more than just Grid applications –Grid community really doesnt want this feature separate from Web services community Interoperability, tooling, runtimes, adoption

11 Proposal W3C Web Services Description Working Group form a task force to examine the concept of modeling elements of publicly available state data in WSDL 1.2 –Concept and requirements –Conceptual model –Syntax –Operations Deliver final conclusions to entire WG –NO LATER THAN Toronto F2F