1 / 60

Steve Graham sggraham@us.ibm

WS-ResourceFramework Technical Overview. OASIS Tutorial Sunday, April 26th, 2004. Steve Graham sggraham@us.ibm.com. Agenda. Introduction, Motivation and Core concepts Overview of the WS-ResourceFramework specifications Resource Properties Resource Lifetime ServiceGroup BaseFaults

matthew-mendoza
Download Presentation

Steve Graham sggraham@us.ibm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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. 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. 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. 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. 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. 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. Invoking a Web service using WS-Addressing Endpoint Reference Run-time environment message Interface Web Service message address

  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. Contents of EndpointReference

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

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

  14. The WS-Resource Qualified Endpoint Reference • An endpoint reference containing a WS-Resource identifier is a WS-Resource-qualified endpoint reference.

  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. id address Creating/Locating a WS-Resource Endpoint Reference Run-time environment Endpoint Reference resource message Interface Web Service message address

  17. WS2 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 B WS1

  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. Agenda • Introduction, Motivation and Core concepts • Overview of the WS-ResourceFramework specifications • Resource Properties • Resource Lifetime • ServiceGroup • BaseFaults • Demo • WS-Notification discussion • Conclusions

  20. WS-Resource Properties WS-Resource Lifetime WS-Notification Modeling Stateful Resources with Web Services WS-Service Groups WS-Base Faults 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

  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. Agenda • Introduction, Motivation and Core concepts • Overview of the WS-ResourceFramework specifications • Resource Properties • Resource Lifetime • ServiceGroup • BaseFaults • Demo • WS-Notification discussion • Conclusions

  23. WS-ResourceProperties • 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

  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 • <process:ProcessProperties> <process:csName> xclock </process:csName> <process:executionState> Suspended Ready </ …> <process:handle> 2824 </process:handle>… <wsrl:CurrentTime> 23 Apr 2004 19:45:29 GMT </ … > <wsrl:TerminationTime xsi:nil=“true” /></process:ProcessProperties> • XSD:ref is used to “combine” Resource Properties from various definitions

  25. <!-- RPDoc declaration for Process --> <xsd:element name="ProcessProperties" type="process:ProcessPropertiesType"/> <xsd:complexType name="ProcessPropertiesType"> <xsd:sequence> <xsd:element ref="process:Name"/> <xsd:element ref="process:CSName"/> <xsd:element ref="process:OSName"/> <xsd:element ref="process:Handle"/> <xsd:element ref="process:Priority"/> <xsd:element ref="process:ExecutionState"/> <xsd:element ref="process:CreationDate"/> <xsd:element ref="process:TerminationDate"/> <xsd:element ref="process:KernelModeTime"/> <xsd:element ref="process:WorkingSetSize"/> <xsd:element maxOccurs="1" minOccurs="1" ref="process:resourceID"/> <xsd:element maxOccurs="1" minOccurs="1" ref="wsrl:CurrentTime"/> <xsd:element maxOccurs="1" minOccurs="1" ref="wsrl:TerminationTime"/> …

  26. ResourceProperties Document and WSDL • ResourceProperties document is associated with the wsdl portType: • <wsdl:portType name="Process" wsrp:ResourceProperties="process:ProcessProperties"> <wsdl:operation name="findHostingOperatingSystem"> … <wsdl:operation name="GetResourceProperty"> … <wsdl:operation name="QueryResourceProperties"> … <wsdl:operation name="Destroy"> … </wsdl:portType> • @ResourceProperties provides meta-data to assist developers and value-add tooling

  27. WS-ResourceProperties Operations <wsrp:GetResourceProperty> QName </wsrp:GetResourceProperty> • GetResourceProperty • Simple single resource property element getter • Required • <wsrp:GetResourceProperty> process:handle</wsrp:GetResourceProperty> • <wsrp:GetResourcePropertyResponse> <process:handle>1577 </process:handle></wsrp:GetResourceProperty>

  28. WS-ResourceProperties Operations • Get Multiple Resource Properties • More sophisticated multiple property value retrieval • Optional • <wsrp:GetMultipleResourceProperties> <wsrp:ResourceProperty>process:handle </ …> <wsrp:ResourceProperty>process:executionState <wsrp:ResourceProperty>process:csName </…></wsrp:GetMultipleResourceProperties> • <wsrp:GetMultipleResourcePropertiesResponse> <process:handle>2824 </process:handle> <process:executionState>Suspended Ready </… <process:csName> xclock </process:csName></wsrp:GetMultipleResourcePropertiesResponse> <wsrp:GetMultipleResourceProperties> <wsrp:ResourceProperty>QName </wsrp:ResourceProperty>* </wsrp:GetMultipleResourceProperties>

  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 <wsrp:QueryResourceProperties> <wsrp:QueryExpression dialect=”URI”> xsd:any </wsrp:QueryExpression> </wsrp:QueryResourceProperties>

  30. WS-ResourceProperties • Set Resource Properties • Modify a resource property document • optional <wsrp:SetResourceProperties> { <wsrp:Insert > xsd:any* </wsrp:Insert> | <wsrp:Update > xsd:any * </wsrp:Update> | <wsrp:Delete ResourceProperty=”QName” /> }+ </wsrp:SetResourceProperties>

  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. 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. WS-ResourceLifetime • Immediate Destruction • Scheduled Destruction • Resource Properties • Current Time • Termination Time <wsrl:Destroy /> <wsrl:SetTermination> <wsrl:RequestedTerminationTime> xsd:dateTime </wsrl:RequestedTerminationTime> </wsrl:SetTerminationTime>

  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. 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. ServiceGroup Model

  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. 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. 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. Agenda • Introduction, Motivation and Core concepts • Overview of the WS-ResourceFramework specifications • Resource Properties • Resource Lifetime • ServiceGroup • BaseFaults • Demo • WS-Notification discussion • Conclusions

  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. BaseFault Element <BaseFault> <-- type=BaseFaultType --> <Timestamp>xsd:dateTime</Timestamp> <OriginatorReference> wsa:EndpointReferenceType </OriginatorReference> ? <ErrorCode dialect="anyURI">xsd:string</ErrorCode> ? <Description>xsd:string</Description> * <FaultCause>wsbf:BaseFault</FaultCause> * </BaseFault>

  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. Using BaseFaultType • For each distinct fault on WSDL operation • Define XSD complexType that extends BaseFaultType • Represents the fault’s distinct type • May not define any additional fields • Define XSD element with this extended fault type • Define WSDL message using this fault element • Define WSDL operation fault element using this messag

  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. Agenda • Introduction, Motivation and Core concepts • Overview of the WS-ResourceFramework specifications • Resource Properties • Resource Lifetime • ServiceGroup • BaseFaults • Demo • WS-Notification discussion • Conclusions

  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. WebSphere OS Operating System Service Handlers Pegasus CIMOM Process Service Process

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

  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. Agenda • Introduction, Motivation and Core concepts • Overview of the WS-ResourceFramework specifications • Resource Properties • Resource Lifetime • ServiceGroup • BaseFaults • Demo • WS-Notification discussion • Conclusions

More Related