1. WS-Resource Framework Adam Belloum Computer Architecture & Parallel Systems group University of Amsterdam adam@science.uva.nl

2. Grid and Web Services: Convergence? Grid Web However, despite enthusiasm for OGSI, adoption within Web community turned out to be problematic Started far apart in apps & tech OGSI GT2 GT1 HTTP WSDL, WS-* WSDL 2, WSDM Have been converging ? “WS-Resource Framework: Globus Alliance Perspectives” I. Foster

3. Grid and Web Services: Convergence: Yes! Grid Web The definition of WSRF means that Grid and Web communities can move forward on a common base WSRF Started far apart in apps & tech OGSI GT2 GT1 HTTP WSDL, WS-* WSDL 2, WSDM Have been converging “WS-Resource Framework: Globus Alliance Perspectives” I. Foster

4. Web Service and State Web service interfaces frequently provide a user with the ability to access and manipulate state –Message exchanges that Web services implement are frequently intended to enable access to stateful resources. However, the notion of stateful resources acted upon by the Web service implementation is not explicit in the interface definition.

5. Web Service and State It is desirable to define Web service conventions to enable: – the discovery of, introspection on, and interaction with stateful resources in standard and interoperable ways. WS-Resource is approach to modeling state in a Web services context

6. Web Service and State A WS-Resource is defined as the composition of a Web service and a S-Resource –Expressed as an association of an XML document with defined type with a Web services portType –Addressed and accessed according to the implied resource pattern, a conventional use of WS-Addressing endpoint references In the implied resource pattern, a S-Resource identifier is encapsulated in an endpoint reference to identify the S-Resource to be used in the execution of a Web service message exchange.

7. WS-Resource Framework WS-Resource framework allows WS-Resources to be –declared, created, accessed, monitored for change, and destroyed via conventional Web services mechanisms, but –does not require that the WS component of the WS-Resource to be implemented as a stateful message processor.

8. WS-Resource Framework WS-Resource framework, is a set of five technical specifications define in terms of –specific WS message exchanges –and related XML definitions. The specifications allow –WS-Resource to be destroyed, –Type definition of a WS-Resource can be composed from the interface of a WS endpoint reference –Heterogeneous by-reference collections of Web services can be defined –Fault reporting can be made more standardized through use of an XML Schema

9. The five specification composing the WSRF

10. Service Composition Transports Messaging Description Quality of Experience (QoX) HTTP/HTTPS SMTP RMI / IIOP XSD WSDL SOAP XMLWS-Addressing WS-Renewable References WS-Metadata Exchange WS-Policy WS-Service Group WS-Resource Properties JMS WS-Security WS-Reliable MessagingWS-Transaction WS-Resource Lifetime WS-Base Faults WS-Notification BPEL4WS How these proposals relates to other Web services standards:

11. Renewable References The WS-RenewableReferences work defines mechanisms that can be used to renew an endpoint reference that has become invalid. These mechanisms can be applied to any endpoint reference, but are particularly useful –For endpoint reference that refers to a WS-Resource, –as it can provide a persistent and stable reference to the WS-Resource that can allow the same state to be accessed repeatedly over time.

12. Renewable References A WS-Addressing endpoint reference may contain –not only addressing –policy information concerning interactions with the service. Typically, endpoint references are constructed by an authoritative source of the addressing and policy information. An endpoint reference made available to a client represents a copy of that information –at some point, become incoherent due to changes introduced by the authoritative source that effects the endpoint location and/or the policy

13. Service Groups The WS-ServiceGroup specification defines a means of representing and managing heterogeneous by-reference collections of Web services. –organize collections of WS-Resources, for example to build registries –build services that can perform collective operations on a collection of WS-Resources.

14. Service Groups The ServiceGroup specification express ServiceGroup: –membership rules, –Membership constraints –classifications. Groups can be defined. using the resource property model from WS- ResourceProperties as a collection of members that meet the constraints of the group as expressed through resource properties

15. Base Faults The WS-BaseFaults specification defines a base fault type for use when returning faults in a Web services message exchange. Used by all of the other WS-Resource framework specifications to bring consistency to the faults returned by the operations including – consistent reporting of faults relating to WS-Resource definition and use.

16. Notification WS-Notification, defines a general, topic based WS system for (pub/sub) interactions that builds on the WS-Resource framework. From the perspective of WS-Notification –WS-Resource framework provides useful building blocks for representing and structuring notifications. From the perspective of the WS-Resource framework, –WS-Notification specifications extends WS-Resources by allowing requestors to ask to be asynchronously notified of changes to resource property value

17. Modeling Stateful Resources with Web Services

18. Possible association between State and Services A stateless service implements –message exchanges with no access or use of information not contained in the input message A conversational service implements –a series of operations such that the result of one operation depends on a prior operation and/or prepares for a subsequent operation A service that acts upon stateful resources –access to, or manipulates a set of logical stateful resources based on messages it sends and receives.

19. Stateless Implementations, Stateful Interfaces A Service that acts upon stateful resources may be described “stateless” –if it delegates responsibility for the management of the state to another component. The service is responsible for the state of the resource between message exchanges

20. A consequence of statelessness Any dynamic state needed for a given message-exchange execution must be: –provided explicitly within the request message, whether directly by-value indirectly by-reference maintained implicitly within other system components with which the WS can interact.

21. Modeling State in Web Services (WS-Resource) WS-Resource is composed of a Web service and a S-Resource S-Resource is used in the execution of Web service message exchanges WS-Resources can be created and destroyed S-Resource is associated with the interface of a WS to enable: well-formed queries against the state of a WS-Resource

22. Modeling State: Stateful Resources A S-Resource is defined as having: –specific set of state data expressible in XML format –a well-defined lifecycle known to, and acted upon, by one or more Web services.

23. How stateful resource is referred to by Web services? The implied resource pattern refers to the mechanisms used to associate –a S-Resource –with the execution of message exchanges implemented by a Web Service.

24. The Implied Resource Pattern Implied is used because the S-Resource associated with a message exchange is treated as implicit input for the execution of the message request. –The Association of WS and S-Resource is either static or a dynamic. Static if the association is made when the WS is deployed. Dynamic if the association is made at time of message exchange (S-Resource is encapsulated in the WS-Addressing endpoint reference). Pattern indicates that the relationship between WS and S- resources is –codified by a set of conventions on existing WS technologies, in particular XML, WSDL, and WS-Addressing.

25. WS-Addressing WS-Addressing standardizes –The endpoint reference used to represent the address of a WS. –endpoint contain metadata associated with the WS service description information reference properties A WS-Addressing endpoint reference is an XML serialization of a network-wide pointer to a WS

26. WS-Resource and WS- Addressing SW (2) returns an Endpoint reference to the requestor “C” is S-resource created SW (2) represents an explicit WS-Resource factory. The endpoint reference (3) contains –Wsa:Address (4) refers to the network transport-specific address of the WS (URL). same address that would appear within a port element in a WSDL of the WS –wsa:ReferencePropertie contain an XML serialization of a S-Resource identifier.

27. WS-Resource and WS- Addressing S-Resource identifier –is meaningful only to the SW, –used by the WS in an implementation-specific to identify the WS-Resource related S-Resource needed for the execution. –should not be examined or interpreted by the service requestor’s applications –Is represented using a service- specific XML element by XML serialization of the S-Resource

28. WS-Resource and WS- Addressing S-Resource identifier –must identify a unique S- Resource to be used the execution of the request message. –the scope of the S-Resource identifier must be unique within the scope of the WS. –multiple identifiers within the scope of a WS may refer to the same WS-Resource.

29. WS-Resource-qualified endpoint reference the endpoint reference represents a pointer to the WS-Resource service requestor –must understand that the endpoint reference refers to a WS-Resource. –must recognize that the endpoint reference is a WS-Resource qualified endpoint reference.

30. WS-Resource-qualified endpoint reference requestor use the endpoint reference (1) to send messages (2) to the identified SW(3) WS-Resource’s endpoint reference contains a S- Resource identifier in its ReferenceProperties request message directed to the WS using that endpoint reference must include the S-Resource identifier.

31. WS-Resource Relationship Cardinality A WS can execute message exchanges against: – zero –more S-Resources defined as instances of the resource property document. A single WS at a particular endpoint is associated with several individual S-Resources

32. WS-Resource Relationship Cardinality ( At the type level) WSDL 1.1 portType, defining the interface to a WS: –can be associated with at most one S-Resource property document. –S-Resource property document can be associated with many portTypes. –Any WS that implements a portType is by definition a WS associated with a S-Resource

33. WS-Resource Relationship Cardinality At the instance level, a S-Resource can be associated with one or more WS. The one-to-many relationship between a S-Resource instance and a WS is exploited to – allow multiple network protocol or network endpoints to process messages for the WS-Resource, –allow different WS interfaces to categorize and subset messages that act upon the S-Resource.

34. WS-Resource Encapsulation Strict encapsulation guarantees that encapsulated data can only be accessed through well defined operations. Data encapsulation facilitates the use of data without the user having to understand the details of the data implementation The implied resource pattern facilitates varying degrees of WS encapsulation of S-Resources.

35. WS-Resource Lifecycle The lifetime of a WS-Resource is defined as the period between its creation and its destruction. 1.WS-Resource creation using a WS-Resource factory 2.Assignment & use of the S-Resource identifier 3.destruction of a WS-Resource.

36. WS-Resource Creation WS-Resource factory is any WS capable of creating a WS- Resource –creating a new S-Resource –assigning the new S-Resource an identity, –associating the new S-Resource and its WS. The response message of a WS-Resource factory operation contains –WS-Resource-qualified endpoint reference containing a S- Resource identifier that refers to the new S-Resource

37. WS-Resource Identity We describe and contrast the role and use of WS- Resource identity from two perspectives: 1.From the private perspective of the WS-Resource implementation 2.From the public perspective of a service requestor to whom an endpoint reference to a WS-Resource is provided.

38. WS-Resource Identity S-Resource has at least one form of identity that identifies S-Resource component within the WS-Resource composition. To a WS with a S-Resource is associated: –the S-Resource identifier carried within a request message is meaningful.

39. WS-Resource Identity A service requestor that obtains access to a WS-Resource- qualified endpoint reference –should not examine or attempt to interpret the value of the S- Resource identifier. –even comparing the contents of two S-Resource identifiers is considered invalid. From the perspective of the service requestor, the content of the S-Resource identifier within the endpoint reference is opaque.

40. WS-Resource Identity How would a service requestor reason about the public identity of a S-Resource of a WS-Resource? Answer: the semantic meaning of the S-Resource identity, and the means by which it is defined and exposed to requestor, is WS implementation dependent. The identity should be a portable, namespace-scoped value

41. WS-Resource Destruction A requestor that wishes to terminate a WS-Resource uses WS-Resource-qualified endpoint reference to: – Immediate Destruction: send a destroy request message to the WS using by the endpoint reference. –Scheduled Destruction: message exchanges for establishing and renewing scheduled destruction times on WS- Resources

42. WS-Resource Properties WS-Resource has an XML resource property document defined using XML schema. Requestors determine a WS-Resource’s type by retrieving the WSDL portType definition. Requestors use WS message exchanges to read, modify, and query the XML document representing the WS-Resource’s state.

43. WS-Resource Properties resource property to refer to –An individual component of a WS-Resource’s state. –XML document describing the type of a S-Resource within the WS-Resource is a WS-Resource properties document. Each resource property is represented as an XML element within the WS-Resource properties document

44. WS-Resource Properties Document WS-Resource properties document acts as a view on, or projection of, the actual state of the WS-Resource. –the structure upon which requestor-initiated queries and updates can be directed. –Any operation that manipulates a resource property via the WS-Resource properties document must be reflected in the actual implementation of the WS-Resource’s state.

45. WS-Resource Properties Document the state of “C” comprises 3 components, p1, p2, and p3 resource properties document, “ExampleResourcePropert ies,”.

46. WS-Resource Properties Document WS-Resource properties document declaration is associated with the WSDL portType using a standard attribute, resourceProperties

47. WS-Resource Property Composition Web services allow to construct a new interface from several existing interfaces via a process of composition In WSDL 1.1, this composition must be achieved by a copy-and-paste of the operations defined in the constituent portTypes used in the composition

48. WS-Resource Property Composition aggregation of WS-Resource properties of the various constituent portTypes is also possible. WS-Resource properties document composition is obtained by adding additional XML element declarations, using: –xs:ref attribute

49. Accessing WS-Resource Property Values The values of resource properties exposed in the WS- Resource’s resource properties document, can be –read, modified, and queried by using standard WS messages. The base functionality is to retrieve the value of a single resource property using a simple WS message exchange

50. Accessing WS-Resource Property Values Retrieval function allow the retrieval of multiple resource properties with a single message exchange. –The WS responds with a message containing the values of the requested WS-Resource properties message exchange to execute an arbitrary Xpath expression against the resource properties document. –query expression types may be used to support resource discovery based on the values of a WS-Resource’s state.

51. WS-Resource and ACID Properties Atomicity requires that the updates to S-Resources used within the context of a transaction be made in all or nothing fashion. Consistency refers to the ability of a transaction to leave resources in a consistent state. Isolation ensures that partial updates to S-Resources used within the transaction are not visible outside until its end. Durability provides for the permanence of S-Resource updates made under the transaction.

52. WS-Resource and ACID Properties The ability to associate a transactional recovery policy to the execution of a WS message exchange –In the presence of a transactional unit of work, a WS capable of participating in the transactional protocol must abide by the rules of two-phase-commit transaction management. –In the absence of a transaction management policy, the WS is under no obligation to recover the state of the WS-Resource in the event of a failure.

53. WS-Resource and ACID Properties If WS-Resource isolation is needed, –use of a transaction to provide a context within which isolation of updates can be provided. –In the absence of a transactional unit of work, the level of update ACID provided by a WS is implementation dependent. the ability to declare and attach isolation-level policy to the definition of a WS message exchange, whether or not a transactional unit of work, represents a general requirement not met by the current Web service architecture.

54. Association of security policy to WS: –described in the WS-Policy and WS-SecurityPolicy specifications which are part of the WS Security Roadmap.. In the presence of a valid security context associated with a message exchange, –WS capable of participating in the security protocols must implement and enforce the security policies. In the absence of a security policy, –the WS is under no obligation to secure the execution of the message exchange nor the state of the WS-Resource.

55. WS-Resource Security The WS-Resource definition is not prescriptive with respect to policy that governs access permission to a WS-Resource. The definition of specific security policy governing access to the WS-Resource is beyond the scope of the WS-Resource Framework. If WS-Resource access control is required, we suggest the use of the functions defined in the WS-Security specifications to provide a security context for the WS-Resource. In the absence of a valid security context and associated access control policies, the extent to which the WS provides security of the WSResource is implementation dependent