1. Steve Graham sggraham@us.ibm.com WS-ResourceFramework Technical Overview OASIS Tutorial Sunday, April 26th, 2004

2. © 2004 IBM Corporation 2 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

3. © 2004 IBM Corporation 3 Motivation  Stateful entities exist in most systems Data in a purchase order Current usage agreement for resources Metrics associated with work load on a server  Hitherto: no standard way to deal with state in Web services context Each system does it in “idiosyncratic way” Integration impediment  Goal: Formalize a mechanism to represent “state” in Web services In order to help unify Grid computing, Systems management and e-business computing

4. © 2004 IBM Corporation 4 Scope of WS-ResourceFramework  How to represent state in a Web services context  How is state referenced and “identified” in Web services  How is state modeled in XML and WSDL  How is state accessed through Web services  How to reason about lifetime of state  How to aggregate/collect stateful resources  How to reason about fault messages

5. © 2004 IBM Corporation 5 Overview of Scenario  At several points we will use examples from the systems management domain  In particular, imagine applications that use Web services to view/manipulate operating systems and processes that run on them

6. © 2004 IBM Corporation 6 What is a Web Service ?  An operation execution component made available at an endpoint address A service is defined in terms of the operations it implements –An operation is defined in terms of a message exchange The supported set of messages exchanges (operations) implemented by a service may be described as a WSDL portType The Web service itself is typically stateless  Accessible through use of a WS-Addressing Endpoint Reference  Lifecycle of a Web service typically described in terms of “deployment”

7. © 2004 IBM Corporation 7 What do we mean by Stateful Resource ?  A specific set of state data expressible as an XML document;  Has a well-defined identity and lifecycle; and  Known to, and acted upon, by one or more Web services.  Many possible implementations Files, Database tables, EJB Entities, XML documents, Composed from multiple data sources, etc.  Lifecycle expressed in terms of resource creation and destruction Multiple independent instances may be created and destroyed Identity is assigned at creation time

8. © 2004 IBM Corporation 8 WS-Addressing: Referencing Web services  Standardizes the representation of the address of a Web service deployed at a given network endpoint  A WS-Addressing endpoint reference is an XML serialization of a network-wide pointer to a Web service  EPRs can be used to pass services to other services by reference  Dynamic generation and customization of service endpoint descriptions  Identification and description of specific service instances that are created as the result of stateful interactions  An EPR contains: Service address (wsa:Address) Metadata associated with the Web service such as service description information (WSDL) Policy information related to the use of the service Reference properties, which can be used to identify specific stateful resource instances associated with the Web service at the endpoint address (wsa: ReferenceProperties)

9. © 2004 IBM Corporation 9 Interface Web Service message address Endpoint Reference Run-time environment Invoking a Web service using WS-Addressing

10. © 2004 IBM Corporation 10 WS-Resource  WS-Resource: Web service + associated resource In other words: – A resource with an associated Web service  A WS-Resource has: Identity: Can be uniquely identified/referenced Lifetime: Often created & destroyed by clients State: Can be projected as an XML document Type: Its Web service interface  An EPR “ points to ” a WS-Resource WS-Resource Qualified Endpoint Reference Implied Resource Pattern

11. © 2004 IBM Corporation 11 Contents of EndpointReference

12. © 2004 IBM Corporation 12 context Interface Web Service message id message id address resource Run-time environment Endpoint Reference Using an EPR to Access a WS-Resource

13. © 2004 IBM Corporation 13 context Interface Web Service message id message id address resource Endpoint Reference Different WS-Resources, Different EPRs Run-time environment

14. © 2004 IBM Corporation 14 The WS-Resource Qualified Endpoint Reference  An endpoint reference containing a WS-Resource identifier is a WS-Resource-qualified endpoint reference.

15. © 2004 IBM Corporation 15 WS-Resource Identifier  The WS-Resource identifier is a “lookup key” the WS- Resource to be used in the execution of the request message The set of reference properties  The content of the WS-Resource identifier is opaque to the service requestor The service requestor’s applications should not examine or attempt to interpret the contents of the WS-Resource identifier The WS-Resource identifier is meaningful only to the Web service  From the point of view of the service requestor: EPR is a pointer to the Web service + WS-Resource In other words, the EPR represents a pointer to a WS-Resource accessible through a Web service

16. © 2004 IBM Corporation 16 Interface Web Service message address Endpoint Reference resource Endpoint Reference address id Creating/Locating a WS-Resource Run-time environment

17. © 2004 IBM Corporation 17 WS-Resource Relationship Cardinality  A Web service can execute message exchanges against zero or more WS-Resources of a given type  One Stateful resource can be “associated” with multiple Web services Different interfaces, or same interface for redundancy  At the type level, a WSDL 1.1 portType, defining the interface to a Web service, can be associated with at most one “kind” or “type” of WS- Resource  One “kind” or “type” of WS-Resource can be associated with many WSDL 1.1 portTypes A C WS1 B WS2

18. © 2004 IBM Corporation 18 WS-Resource Composability  WS-RF is part of the Web services set of technologies  Key to Web services is the notion of composability Web services is a (growing) set of small(ish) specs Systems are built by “composing” these specs in various ways Eg –WS-RF DOES NOT define a security model »Use WS-Security –WS-RF DOES NOT define a reliable messaging model »Use WS-ReliableMessaging –WS-RF DOES NOT define a transactions model »Use WS-AtomicTransaction, etc. –ETC.

19. © 2004 IBM Corporation 19 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

20. © 2004 IBM Corporation 20 WS-ResourceFramework  A family of documents and specifications CA, Fujitsu, Globus, HP, IBM  White papers: Modeling Stateful Resources with Web services –“State Paper” WS-Resource Framework overview OGSI -> WS-RF  Specifications WS-ResourceProperties WS-ResourceLifetime WS-ServiceGroup WS-BaseFaults WS-Service Groups WS-Notification Modeling Stateful Resources with Web Services WS-Base Faults WS-Resource Properties WS-Resource Lifetime

21. © 2004 IBM Corporation 21 Status of WS-ResourceFramework  Specifications announced on January 20, 2004 WS-ResourceProperties, WS-ResourceLifetime, State Paper http://www-106.ibm.com/developerworks/webservices/library/ws-resource/  Co-author feedback session on February 16  Public feedback session February 23  Specifications updated March 5 Added the WS-RF overview paper and OGSI->WSRF paper  OASIS Technical Committee call for participation March 9  WS-BaseFaults and WS-ServiceGroup on March 31 Public feedback April 16  Interoperability “fest” April 20  First meeting of OASIS TC April 28

22. © 2004 IBM Corporation 22 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

23. © 2004 IBM Corporation 23  Defines: How to use XML schema to model elements of resource state How to associate resource’s state model with WSDL portType Standard operations for getting, setting, querying, Standard mechanism to use WS-Notification to subscribe for state value changes  Why: Basis for standard resource inspection, monitoring and state management WS-ResourceProperties

24. © 2004 IBM Corporation 24 How is State Modeled?  XML of course Instance document associated with a WS-Resource The WS-Resource’s “Resource Properties document”  Elements of state are modeled as child elements of the root  xclock Suspended Ready 2824 … 23 Apr 2004 19:45:29 GMT  XSD:ref is used to “combine” Resource Properties from various definitions

25. © 2004 IBM Corporation 25 …

26. © 2004 IBM Corporation 26 ResourceProperties Document and WSDL  ResourceProperties document is associated with the wsdl portType:  <wsdl:portType name="Process" wsrp:ResourceProperties="process:ProcessProperties"> …  @ResourceProperties provides meta-data to assist developers and value-add tooling

27. © 2004 IBM Corporation 27 WS-ResourceProperties Operations  GetResourceProperty Simple single resource property element getter Required process:handle 1577 QName

28. © 2004 IBM Corporation 28 WS-ResourceProperties Operations  Get Multiple Resource Properties More sophisticated multiple property value retrieval Optional process:handle process:executionState process:csName 2824 Suspended Ready xclock QName *

29. © 2004 IBM Corporation 29 WS-ResourceProperties Operations  QueryResourceProperties Execute an expression against the resource properties document Optional QueryExpression defines dialect by URI –XPath 1.0, 2.0 –XQuery –SQL –StevesAmazingQueryExpression xsd:any

30. © 2004 IBM Corporation 30 WS-ResourceProperties  Set Resource Properties Modify a resource property document optional { xsd:any* | xsd:any * | }+

31. © 2004 IBM Corporation 31 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

32. © 2004 IBM Corporation 32 WS-ResourceLifetime  Defines: Immediate, synchronous destruction operation Time-based, scheduled destruction operation –“Soft-state” or “leased” lifetime management –Termination time no required to monotonically increase Resource properties: –CurrentTime: Can be used to determine clock skew –TerminationTime: Current scheduled termination time Notification of resource termination  Why: Define clear means by which WS-Resources can be destroyed

33. © 2004 IBM Corporation 33 WS-ResourceLifetime  Immediate Destruction  Scheduled Destruction  Resource Properties Current Time Termination Time xsd:dateTime

34. © 2004 IBM Corporation 34 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

35. © 2004 IBM Corporation 35 WS-ServiceGroup  Defines: Web service interfaces for representing and managing a by- reference collection of EPRs to Web services or WS- Resources Each entry is member EPR + associated content –WS-RP used for representing the entries –Can have rules to membership and content –Members may be homogenous or heterogenous, depending on the purpose and membership rules of the group Has a registration interface for adding entries –Follows the WS-Resource factory pattern –The entry is represented as a WS-Resource WS-RL used for removing entries  Why: Myriad of reasons for groups: E.g. Registries, collective operations, federated services, etc.

36. © 2004 IBM Corporation 36 ServiceGroup Model

37. © 2004 IBM Corporation 37 ServiceGroup Interfaces  ServiceGroup A collection of Web services and the information that pertains to them. Purpose is application domain specific  ServiceGroupEntry A Web service that represents the member and associated content  ServiceGroupRegistration Message exchange for adding new members to a ServiceGroup Membership may occur in other ways  Member (any Web service)

38. © 2004 IBM Corporation 38 ServiceGroup Characteristics  When a ServiceGroup is destroyed, all of the ServiceGroupEntries are also recommended to be destroyed. However, the members are not affected.  Once a ServiceGroup is destroyed, no assumptions can be made about either the existence of the ServiceGroupEntry or it’s contents.  A member may belong to several ServiceGroups.  A member may belong to the same ServiceGroup more then once.  The member of a ServiceGroup may implement message exchanges from various interfaces.  If a member is destroyed, the ServiceGroup may destroy the corresponding ServiceGroupEntry(s).

39. © 2004 IBM Corporation 39 ServiceGroup Resource Properties  MembershipContentRule These elements specify the constraints on membership of the service group  Entry These elements represent the projection of the aggregation of the resource property documents of the ServiceGroup’s entry resources

40. © 2004 IBM Corporation 40 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

41. © 2004 IBM Corporation 41 WS-BaseFaults  Defines Set of “common” properties of a fault Convention for specializing “common” fault How “common” fault type is used in WSDL  Why? Increases the likelihood that service requestors to automatically (without human intervention) understand and/or adapt to faults requires interface designers to define rich, structured fault messages Standard fault messages encourage tooling that can assist interface designers, service implementers, and client implementers

42. © 2004 IBM Corporation 42 BaseFault Element xsd:dateTime wsa:EndpointReferenceType ? xsd:string ? xsd:string * wsbf:BaseFault *

43. © 2004 IBM Corporation 43 BaseFaultType Information Items  Timestamp (required) Time at which the fault occurred  OriginatorReference (optional) WS-Addressing EndpointReference of the WS that generated the fault Can omit if it is clearly implied Useful particularly with FaultCause  ErrorCode (optional) String error code for supporting legacy fault reporting systems @dialect: URI specifying context of string  Description (0..unbounded) Plain language description(s) of the fault Use with xsi:lang  FaultCause (0..unbounded) BaseFault element(s) that describes the underlying cause of this fault.

44. © 2004 IBM Corporation 44 Using BaseFaultType  For each distinct fault on WSDL operation 1.Define XSD complexType that extends BaseFaultType Represents the fault’s distinct type May not define any additional fields 2.Define XSD element with this extended fault type 3.Define WSDL message using this fault element 4.Define WSDL operation fault element using this messag

45. © 2004 IBM Corporation 45 Binding to SOAP  WS-BaseFaults only specifies what is done at WSDL 1.1 abstract interface (portType) level Intended for defining service/application faults  Binding a fault message to SOAP is the purview of a WSDL binding definition Use standard WSDL 1.1  SOAP 1.1 binding  Issue: Some redundancy between WS-BaseFault information and SOAP 1.2 faults May want some changes to WS-BaseFaults for WSDL 2.0 and its SOAP 1.2 binding

46. © 2004 IBM Corporation 46 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

47. © 2004 IBM Corporation 47 The Demo Services and Scenarios  Ability to find known operating systems represented as services.  Ability to find all processes hosted on a given operating system represented as services.  Monitor and introspect both operating system and process state via resources properties.  Destroy (terminate) a selected process resource via its services interface. Operating System Service Process Service Pegasus CIMOM Handlers Process OS WebSphere

48. © 2004 IBM Corporation 48 Demo Details Pegasus CIMOM ProcessOS Handlers Operating System Service Process Service WebSphere Client Proxies EPRHelpers Handlers Client UI Client Container Web Services Servlets Stateless Session Beans EJB Container EPRHelpers Handlers Web Container Entity Beans

49. © 2004 IBM Corporation 49 Demo  WSAD IE 5.1 on Windows XP Integration Test Server 5.1 –WBI Runtime  Pegasus 2.3.1 on RH 9.0 sblim base providers

50. © 2004 IBM Corporation 50 Agenda  Introduction, Motivation and Core concepts  Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults  Demo  WS-Notification discussion  Conclusions

51. © 2004 IBM Corporation 51 WS-Notification  WS-Notification Brings enterprise quality publish and subscribe messaging to Web services –Loosely coupled, asynchronous messaging in a Web services context WS Notification exploits WS Resource framework and other Web services technologies Direct and Brokered notification Topics and Topic Spaces More on subscribe Use of WS-Notification in WS-RF

52. © 2004 IBM Corporation 52 WS-Notification Family of Documents  WS-Notification is a family of documents: Publish-Subscribe for Web services –Whitepaper describing roles, concepts, terms, etc. Base Notification –Basic interfaces: Producer, Consumer, Subscription Topics –Topics and TopicSpaces model in XML –Topic Expression Dialects Brokered Notification –Mechanisms of Publish and the Broker role  Authored by: CA, Fujitsu, Globus, HP, IBM + Akamai, SAP, Sonic, Tibco

53. © 2004 IBM Corporation 53 Status of WS-Notification  Specification announced on January 20, 2004 http://www-106.ibm.com/developerworks/webservices/library/ws-notification/  Co-author feedback session on February 17  Public feedback session February 24  Specifications updated March 5 Factored into 4 documents (see previous slide)  OASIS Technical Committee call for participation March 9  Interoperability “fest” April 21  First meeting of OASIS TC April 29

54. © 2004 IBM Corporation 54 Consumer Producer Subscriber WS-Notification: Base Notification subscribe S notify EPR  Defines the Basis for the family  Direct notification: Three primary roles  Subscriber deals directly with the producer of the Notifications indicates interest in a particular “Topic” by issuing a “subscribe” request  An EPR to the subscription is returned  Producer is responsible for detecting situation and creating the notification  Subscriptions that match receive the notification

55. © 2004 IBM Corporation 55  Similar roles as in direct, adding ‘Broker’ Role Broker (intermediary) permits decoupling Publisher and Subscriber  Subscriber indicates interest in a particular “Topic” by issuing a “subscribe” request  “Subscriptions” are WS-Resources Various subscriptions are possible  New role: Publisher need NOT be a Web Service  Publisher detects situation: Publishes the Notification to a broker  Broker responsible for disseminating notifications examines current subscriptions for match  Brokers may provide “value add” “Transform” or “interpret” topics Federate to provide scalability Broker Subscriber WS-Notification: Brokered Notification Publisher subscribe SS S notify

56. © 2004 IBM Corporation 56 WS-Notification  More on Subscribe Request  Returns EPR to a Subscription WS-Resource EPR xsd:boolean ? wsrp:QueryExpression ? any ? xsd:dateTime ?

57. © 2004 IBM Corporation 57 WS-Notification  Topics and Topic Spaces Meta-data to help –Organize Notifications –Tell the Subscriber what to subscribe to <wstop:topicSpace name="TopicSpaceExample1" targetNamespace="http://example.org/topicSpace/example1" … >

58. © 2004 IBM Corporation 58 WS-ResourceProperties  Subscription for Value Change  Rules for mapping resource properties to Topics QName of resource property corresponds QName of Topic  To subscribe to changes in process:ExecutionState:  Suggested format of value change message … process:executionState …

59. © 2004 IBM Corporation 59 Shameless Plug for My (upcoming) Book

60. © 2004 IBM Corporation 60 Credits  Most of the material is the result of collaborative effort from: Steve Graham, Jeff Frey, Jay Unger, Steve Tuecke and Tom Maguire.  BaseFaults section derived from material courtesy of Steve Tuecke  ServiceGroup section derived from material courtesy of Tom Maguire  Demo and scenario derived from material courtesy of: Mike Williams, Revathi Subramanian, JaiPaul Antony, Bob Hansen