430 likes | 512 Views
Modeling Stateful Resources with Web Services. Tiziana.Ferrari@cnaf.infn.it INFN – CNAF Corso di Laurea specialistica in Informatica Anno Acc. 2004/2005 Slide sources: WS-Resource Framework and WS-Notification, Technical Overview, Globus World, Jan 2004, J. Frey et alt. Outline.
E N D
Modeling Stateful Resources with Web Services Tiziana.Ferrari@cnaf.infn.it INFN – CNAF Corso di Laurea specialistica in Informatica Anno Acc. 2004/2005 Slide sources: WS-Resource Framework and WS-Notification, Technical Overview, Globus World, Jan 2004, J. Frey et alt. Modeling stateful resources with Web Services
Outline • PART I: Stateful Resources • PART II: WS-ResourceProperties Specification • PART III: WS-ResourceProperties Operations • References Modeling stateful resources with Web Services
PART IStateful Resources Modeling stateful resources with Web Services
Access and manipulation of “state” STATE: data values that persist across and evolve as a result of WS interactions. Service models with different types of state handling: • Stateless service: implements message exchanges with NO ACCESS or USE of information not contained in the input message. Example: a service that compresses and decompresses documents, where the documents are provided in the message exchanges with the service. • 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. Each message is used in a logical stream of messages. Many interactive Web sites implement this pattern through use of HTTP sessions and cookies. • A service that acts upon stateful resources: provides access to, or manipulates a set of logical resources (documents) based on messages sent/received. The Web Services Resource Framework focuses on this model Modeling stateful resources with Web Services
Access and manipulation of “state” (cont) • A service that acts upon stateful resources is such if its implementation executes against dynamic state, i.e. state for which the service is responsible between message exchanges with its requestors. • On the contrary, a service that acts upon stateful resources can be described as stateless if it delegates responsability for the management of the state to another component such as a database, file system etc. • Stateleness enhances service reliability and scalability as a stateless Web service can be restarted after failure without concern for its history. • Stateleness implies that: • dynamic state must be provided by-value of by-reference explicitly; • state can be provided implicitly with other system components with which the Web service can interact (e.g. databases). • The Web service can maintain internal static state, for example references to system components. Modeling stateful resources with Web Services
Stateful resurces and Web Services • Web Services implementations are stateless as: • an invocation to the Web service has no correlation to prior interactions; • no information from the current activity is saved for future interactions. • However, “state” appears in almost all applications, e.g. • data in a purchase order, • current usage agreement for resources on a grid, • metrics representing the work load on a Web server. • There are many possible ways Web services might model, access and manage state: • depending on where the service endpoints are deployed, the native session support from underlying transport protocols can be used to build a stateful Web service; • the WS-Resource Framework (WSRF) proposes to standardize this capability for Web services Modeling stateful resources with Web Services
What do we mean by Stateful Resource ? • Properties: • a specific set of state data expressible as an XML document that defines the type of the resource; • having a well-defined identity and lifecycle; • known to, and acted upon, by one or more Web services. • Many possible implementations of resources: • files, • database tables, • XML documents, • a resource that is a group of other stateful resources, etc. • Lifecycle expressed in terms of resource creation and destruction • Identity of the resource is assigned at creation time Modeling stateful resources with Web Services
The WS-Resource framework model • WSRF was introduced for the first time in January 2004 • Examples of stateful resources: • Physical entities: • processors, • communication links, • disk drives, etc. • Logical constructs: • agreements, • running tasks, • Subscriptions etc. • Static (long-lived, pre-existing) or dynamic(created and destroyed as needed) • Simple (one) or compound (collection) Modeling stateful resources with Web Services
Why Define WSRF? • Building large-scale systems by composition of many heterogeneous components demands that we extract, and standardize common patterns • Use WS-Addressing for referring to resources, with extensions for stability (WS-RenewableReferences) • Define resource lifetime management interfaces (create and destroy); • Define resource inspection (WS-ResourceProperties) and monitoring (WS-Notification for message subscription and notification) interfaces • Define base fault representation and groups • Specifies how to use XML to describe and access a resource’s properties. Modeling stateful resources with Web Services
From OGSA to WSRF:Refactoring and Evolution Modeling stateful resources with Web Services
Standardization WSRF and the Open Grid Services Architecture Domain-Specific Services Program Execution Data Services Core Services Open Grid Services Infrastructure WS-Resource Framework Web Services Messaging, Security, Etc. Modeling stateful resources with Web Services
PART IIWS-ResourceProperties Specification Modeling stateful resources with Web Services
Example Resource Properties Document Type <wsdl:definitions ... Xmlns:tns=“http://example.com/diskDrive” ...> ... <wsdl:types> <!– Resource property element declarations --> <xsd:schema targetnamespace=“http://example.com/diskDrive” ...> <xsd:element name=“NumberOfBlocks” type=“xsd:integer”/> <xsd:element name=“BlockSize” type=“xsd:integer”/> <xsd:element name=“Manufacturer” type=“xsd:string”/> <!– Resource properties document declaration --> <xsd:element name=“GenericDiskDriveProperties”> <xsd:complexType> <xsd:sequence> <xsd:element ref=“tns:NumberOfBlocks”/> <xsd:element ref=“tns:BlockSize”/> <xsd:element ref=“tns:manifacturer”/> <xsd:any minOccurs=“0” maxOccurs=“unbounded”/> </xsd:sequence> </xsd:compleType></xsd:element></xsd:schema> </wsdl:types> ... <wsdl:portType name=“GenericDiskDrive” wsrp:ResourceProperties=“tns:GenerciDiskDriveProperties”> <operation name=“start” .../> <operation name=“stop” .../> </wsdl:portType> </wsdl:definitions> Resource Property Element WS-Resource Modeling stateful resources with Web Services
WS-Resource • Definition: A WS-Resource is a Web service having an association with a stateful resource, where the stateful resource is defined by: • a resource properties document type; • the association is expressed by annotating a WSDL portType with the type definition of the resource properties document. • WS-Resource Qualified Endpoint Reference: Web Service Stateful resource WS-Resource + WS-Resource Qualified EPR WS EPR Resoure ID + Modeling stateful resources with Web Services
WS-Resource (cont) • WS-Resource Qualified Endpoint Reference: • An End-point Reference used to refer to a WS-Resource composed of a Web service and a stateful resource. The WS-Resource Qualified Endpoint Reference is a sort of pointer to the WS-Resource. • The set of reference properties used to hold the WS-Resource identity within the endpoint reference is referred to as the WS-Resource context. • An endpoint reference containing a WS-Resource contextis a WS-Resource-qualified endpoint reference. • A stateful resource identifier MAY be contained within the ReferenceProperties element of the Endpoint Reference. • the WS-Resource qualified endpoint reference represents the pointer to the Web service that has been further constrained to execute its message exchanges within the context of a specific WS-Resource. WS-Addressing Endpoint Reference (network and transport-specific, e.g. A URL in case of HTTP transport) <wsa:EndpointReference> <wsa:Address> http://someOrg.com/aWebService <wsa:Address> <wsa:ReferenceProperties> <tns:resourceID>C</tns:resourceID> </wsa:ReferenceProperties> </wsa:EndpointReferece> Context indicating the resource ID (as understood by the corresponding Web Service Modeling stateful resources with Web Services
Implied Resource Pattern • A specific kind of relationship between a Web service and a stateful resource. • Used to associate a stateful resource with the execution of message exchanges implemented by a Web service. • The stateful resource associated with a given message exchange is treated as implicit execution context for the message request. • Implied: the requestor does not provide the identity of the resource as an explicit parameter in the body of the request message. • Pattern: the relationship between stateful resources and Web services is codified by a set of conventions on existing Web services technology (XML, WSDL, WS-Addressing). • The context used to designate the implied stateful resource is encapsulated in the WS-Addressing endpoint reference used to address the target Web service at its endpoint (use of EPR Reference Properties). Modeling stateful resources with Web Services
Stateful Resource Identifier • The service requestor should not examine or attempt to interpret the contents of the stateful resource identifier. • The stateful resource identifier is meaningful only to the Web service, and is used by the Web service in an implementation-specific way to identify the WS-Resource related stateful resource need for the execution of the request message. • The scope of the stateful resource identifier mustbe unique within the scope of the Web service and maybe unique beyond the scope of the Web service. • Multiple identifiers within the scope of a Web service may refer to the same WS-Resource. • When the WS-Resource’s endpoint reference contains a stateful resource identifier in its ReferenceProperties component, any request message directed to the service using that endpoint reference must include the stateful resource identifier. • The ReferenceProperties component of a WS-Addressing message areprocessed in a binding-specific way. • WS-Addressing specified thatReferenceProperties elements must appear as SOAP header elements: <soap:Envelope> <soap:Header> <tns:resourceID> C </tns:resourceID> </soap:Header> <soap:Body> ...some message </soap:Body> </soap:Envelope> Modeling stateful resources with Web Services
Stateful Resource Identifier (cont) • Semantic meaning of the stateful resource identity and the means by which it is defined and exposed to a service requestor, is Web service implemenetation dependent. • Identity can be represented by a set of resource properties expressed in the WS-Resource’s resource properties document. In this case service requestors are only allowed read-only access to such properties. Modeling stateful resources with Web Services
General Web Service invocation model Web Service Run-time environment WSDL Interface Web Service Modeling stateful resources with Web Services
General Web Service invocation model Web Service Endpoint Reference Run-time environment message Interface Web Service message address Modeling stateful resources with Web Services
WS-Resource Factory • Definition: any Web service capable of bringing a WS-Resource into existence and assigning the new WS-Resource an identity. • Phases of the creation process: • a new stateful resource instance is created; • the created instance is assigned an identity; • the new stateful resource is assigned to a Web service. • The response message of a WS-Resource factory operation must include a WS-Resource-qualified endpoint reference containing a WS-Resource context that refers to the new WS-Resource • Note also that what we refer to here as a WS-Resource factory is a use pattern for Web services, not a single standard operation. This use pattern may be encoded in a variety of different Web service operations that may, for example, create one or many WS-Resources. For example, the WS-Resource-qualified endpoint reference can be implicitly returned by placing it into a registry for later retrieval. Modeling stateful resources with Web Services
WS-Resource: explicit WS-Resource factory 3 The endpoint reference of WS-Resource instance n.2 is returned. Endpoint reference = wsa:Address + wsa:ReferenceProperties Run-time environment Requestor 3 WS-Resource Qualified EPR Resource 1 1 A request is sent to a Web Service, which controls one resource instance (Resource 1) Interface Web Service 1 request WS-Resource Resource 2 2 The processing of the request results in the creation of a stateful resource (Resource 2). The Web Service is an explicit WS-Resource factory. 2 Creation WS-Resource Modeling stateful resources with Web Services
context The WS-Resource framework model Using a Web service to access a WS-Resource Resource id Address Endpoint Reference Run-time environment id resource message Interface Web Service message address id Modeling stateful resources with Web Services
context The WS-Resource framework model Using a Web service to access another WS-Resource Endpoint Reference Endpoint Reference Run-time environment id resource message Interface Web Service message address id resource Modeling stateful resources with Web Services
WS-Resource Relationship Cardinality • At the instance level: • A Web service can execute message exchanges against zero or more WS-Resources of a given type. The number of instances acted upon can be extremely large (e.g., in case of a Web service interface to a file system, where each file is a distinct WS-Resource). • One stateful resource instance can be associated with one or more Web services, for example to allow access to the instance by means of multiple network protocols and endpoints at the same time. • At the type level: • a WSDL 1.1 portType, defining the interface to a Web service, can be associated with at most one type of WS-Resource (resource property document). • One resource property document can be associated to with multiple Web services at the same time. Web Service M Web Service 1 same resource property document ... ... Stateful resource Instance 1 Stateful resource Instance 2 Stateful resource Instance N Stateful resource Instance K Modeling stateful resources with Web Services
“ACID” Properties • ACID properties generally apply to stateful resources used within the context of a transactional unit of work within a traditional, two-phase commit-enabled transaction system: • Atomicity: requires that the updates to stateful resource used withing the context of a transaction be made in all or nothing fashion. A recovery policy to the execution of a Web service message exchange needs to be adopted for roll back. • Consistency: refers to the ability of a transaction to leave resources in a consistent state, even in the event of failure, in presence of concurrent attempts to read and/or write access to a WS-Resource. • Isolation: ensures that partial updates to stateful resources used within the transaction are not visible outside of the transaction until the end of the control (also called “transactional locking”). • Durability: provides for the permanence of stateful resource updates made under the transactional unit of work. Modeling stateful resources with Web Services
WS-ResourceProperties • Resource property: a piece of information defined as part of the state model of a WS-Resource. It may reflect a part of the resource’s state, meta-data, manageability information, etc. • Resource properties document: XML document representing a logicalcomposition of resource property elements. The resource properties document defines a particular view or projection of the state data implemented by the WS-Resource. The type (e.g. The XML Schema definition of the root element) of a resource properties document is associated with WSDL portType defining the Web service interface. • the complexType defining the resource properties document MUST define a sequence of one or more resource property elements; • the complexType defining the resource properties document MUST define element children onlu; it MUST not define attributes; • child elements MUST be aggregated using wsd:sequence or wsd:all. • Resource property element: the XML representation of a resource property, it has to appear as the immediate child ofthe root element of a resource properties document, and must be a global element definition (GED). It is uniquely identified by its Qualified Name. Modeling stateful resources with Web Services
WS-ResourceProperties (cont) • Comments: • Service requestors may determine a WS-Resource’s type by retrieving the WSDL portType definition via standard means. • Service requestors may use Web services message exchanged to read, modify and query the XML document representing the WS-Resource’s state. • PortType declares association between Web service and resource properties document. Information is available at design time, as part of the interface. Modeling stateful resources with Web Services
Resource Property Document: elements, types, values <wsdl:definitions ... Xmlns:tns=“http://example.com/diskDrive” ...> ... <wsdl:types> <!– Resource property element declarations --> <xsd:schema targetnamespace=“http://example.com/diskDrive” ...> <xsd:element name=“NumberOfBlocks” type=“xsd:integer”/> <xsd:element name=“BlockSize” type=“xsd:integer”/> <xsd:element name=“Manufacturer” type=“xsd:string”/> <!– Resource properties document declaration --> <xsd:element name=“GenericDiskDriveProperties”> <xsd:complexType> <xsd:sequence> <xsd:element ref=“tns:NumberOfBlocks”/> <xsd:element ref=“tns:BlockSize”/> <xsd:element ref=“tns:manifacturer”/> <xsd:any minOccurs=“0” maxOccurs=“unbounded”/> </xsd:sequence> </xsd:compleType></xsd:element></xsd:schema> </wsdl:types> ... <wsdl:portType name=“GenericDiskDrive” wsrp:ResourceProperties=“tns:GenerciDiskDriveProperties”> <operation name=“start” .../> <operation name=“stop” .../> </wsdl:portType> ... </wsdl:definitions> Resource Property Element Root Element Resource Property Document Type Resource Property Document <GenericDiskDriveProperties xmlns:tns="http://example.com/diskDrive" > <tns:NumberOfBlocks>22</tns:NumberOfBlocks> <tns:BlockSize>1024</tns:BlockSize> <tns:Manufacturer>DrivesRUs</tns:Manufacturer> </GenericDiskDriveProperties> Resource Property Value Modeling stateful resources with Web Services
Resource Properties and Interface Aggregation • Web service interface designers MAY define a collection of discrete interfaces (portTypes), each defining a set of message exchange patterns. • Discrete interfaces can then be combined to form a most derived interface. Examples of independently specified interfaces in the WS-Resource framework designed for purposes of aggregation include: • WS-Notification • WS-ResourceLifetime • and many other general purpose/application-specific interfaces • In WSDL 1.1 this composition must be achieved by copy-and-paste. • Composition can be applied to: • Operations: the ones defined in the consituent portTypes have to be copied and pasted. • WS-Resource properties document: additional XML element declarations can be added using the xsd:ref attribute. The resource property document for the most derived Web service interface, consists of ALL of the resource property element declarations for each of the constituente interfaces. Modeling stateful resources with Web Services
Aggregation: an Example <wsdl:definitions ... xmlns:gen=“http://example.com/diskDrive” xmlns:ven=http://vendor.com/diskDrive ...> ... <wsdl:types> <!– Resource property element declarations --> <xsd:element name=“VendorExtension” type=“xsd:string” /> <!– Resource properties document declaration --> <xsd:element name=“VendorDiskDriveProperties”> <xsd:complexType> <xsd:sequence> <!– copy&paste elements from genericDiskDriveProperties--> <xsd:element ref=“gen:NumberOfBlocks”/> <xsd:element ref=“gen:BlockSize”/> <xsd:element ref=“gen:manifacturer”/> <xsd:element ref=“ven:VendorExtension”/> <xsd:any minOccurs=“0” maxOccurs=“unbounded”/> </xsd:sequence> </xsd:compleType></xsd:element></xsd:schema> </wsdl:types> ... <wsdl:portType name=“VendorDiskDrive” wsrp:ResourceProperties=“ven:VendorDiskDriveProperties”> <!– copy&paste oeprations from genericDiskDrive --> <operation name=“start” .../> <operation name=“stop” .../> <!– define Vendor-specific operations --> <operation name=“reset” ... /> ... </wsdl:portType> ... </wsdl:definitions> Modeling stateful resources with Web Services
Definition of Derived portType: Steps • Define the new portType. • Copy all opertaions child elements from the portType being extended (the order of the operations SHOULD be preserved). • Define additional, specific operations as child elements of the new portType. • Define a new resource properties document, as an XML global element declaration. • Copy all of the child elements (using attribute ref or xsd:any) from the resource properties document of the portType being extended. • Define additional new resource property elements that are specific to the newly defined resource properties document type. Modeling stateful resources with Web Services
PART IIIWS-ResourceProperties Operations Modeling stateful resources with Web Services
Operations: GetResourceProperty • Use to retrieve the value of a single resource property of a WS-Resource. • This operation is mandatory. • The format of the request: where/wsrp:GetResourceProperty/QName MUST correspond to the QName of a resource property element defined as a child of the root of the WS-Resource’s resource properties document. • The format of the response is: where /wsrp:GetResourcePropertiesResponse/{any} is a collection of resource property values. • Fault messages: • ResourceUnknownFault • InvalidResourcePropertyQName <wsrp:GetResourcePropertyRequest> QName </wsrp:GetResourcePropertyRequest> <wsrp:GetResourcePropertyResponse> {any}* </wsrp:GetResourcePropertyResponse> Modeling stateful resources with Web Services
Example of SOAP Encoding of the GetResourceProperty Message Exchange <s12:Envelope xmlns:s12=“http://www.w3c.org/2003/05/soap-envelope” xmlns:wsa=“http://schemas.xmlsoap.org/ws/2003/03/addressing” xmlns:wsrp=“http://www.ibm.com/xmlns/stwip/web-services/WS-ResourceProperties” xmlns:ex=“http://example.com/exampleNS” > <s12:Header> <wsa:action> http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties/GetResourceProperty </wsa:action> <wsa:To s12:mustUnderstand=“1”> http://www.provider.org/ProviderEndpoint </wsa:To> <ex:ResourceId> uuid:84decd55-7d3f-65ad-ac44-675d9fce5d22 </ex:ResourceId> </s12:Header> <s12:Body> <wsrp:GetResourceProperty xmlns:tns=“http://example.com/diskDrive”> tns:NumberOfBlocks </wsrp:getResourcePropery> </s12:Body> </s12:Envelope> Modeling stateful resources with Web Services
Operations: GetMultipleResourceProperties • Use to retrieve the values of multiple resource properties of a WS-Resource. • This operation is optional. • The format of the request: Where /wsrp:GetMultipleResourceProperties/wsrp:ResourceProperty+ is such that each ResourceProperty element QName MUST correspond to the QName of a resource property element defined as a child of the root of the WS-Resource’s resource properties document. • The format of the response is: where /wsrp:GetResourcePropertyResponse/{any} is the resource property value, as an XML element, that corresponds to the QName in the GetResourceProperty request. • Fault messages: • ResourceUnknownFault • InvalidResourcePropertyQName <wsrp:GetMultipleResourcePropertiesRequest> <wsrp:ResourceProperty>QName<wsrp:ResourceProperty>+ </wsrp:GetMultipleResourcePropertiesRequest> <wsrp:GetMultipleResourcePropertiesResponse> {any}* </wsrp:GetResourcePropertiesResponse> Modeling stateful resources with Web Services
Operations: SetResourceProperties • Allows the processing of a single request message to make multiple changes to the resource properties document: • Insert: a new resource property element is inserted into the resource properties document; • Update: existing resource property elements are modified; • Delete: existing resource property elements are removed. • This operation is optional. • The format of the request: • The format of the response is: <wsrp:SetResourceProperties> {<wsrp:Insert> {any}* </wsrp:Insert> | <wsrp:Update> {any}* </wsrp:Update> | <wsrp:Delete ResourceProperty=“QName” /> }* </wsrp:SetResourceProperties> <wsrp:SetResourcePropertiesResponse> </wsrp:SetResourcepropertiesResponse> Modeling stateful resources with Web Services
Operations: QueryResourceProperties • Allows a requestor to query the resource properties document of a WS-Resource using a query expression (for example, XPath). • The format of the request MUST be: • The format of the response is: <wsrp:QueryResourceProperties> <wsrp:QueryExpression dialect=“URI”> xsd:any </wsrp:QueryExpression> </wsrp:QueryResourceProperties> <wsrp:QueryResourcePropertiesResponse> {any} </wsrp:QueryResourcepropertiesResponse> Modeling stateful resources with Web Services
WS-ResourceLifetime • Immediate Destruction • Scheduled Destruction • Resource Properties • Current Time • Termination Time • Initial Termination Time <wsrl:DestroyRequest /> <wsrl:SetTerminationTimeRequest> <wsrl:RequestedTerminationTime> xsd:dateTime </wsrl:RequestedTerminationTime> </wsrl:SetTerminationTimeRequest> Modeling stateful resources with Web Services
WS-ResourceLifetime (cont) • Resource Destruction Notification • Suggested Contents <wsnt:topicSpace name="ResourceLifetime" targetNamespace= "http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceLifetime" … > <wsnt:topic name="ResourceTermination"> <wsrl:TerminationNotification> <wsrl:TerminationTime>xsd:dateTime</wsrl:TerminationTime> <wsrl:TerminationReason>xsd:any</wsrl:TerminationReason>? </wsrl:TerminationNotification> Modeling stateful resources with Web Services
WS-Resource and ACID Properties • ATOMIC: transactions happen indivisibly. • In the presence of a transactional unit of work, a Web service capable of participating in the transactional protocol must abide by the rules of two-phase-commit transaction management. However, in the absence of a transaction management policy, the Web service is under no obligation to recover the state of the WS-Resource in the event of a failure. • CONSISTENT: no violation of system invariants • The WS-Resource definition is not prescriptive with respect to policy that governs concurrent read or write access to a WS-Resource through a Web service. The definition of specificpolicy governing concurrent updates, whether or not separate message executions targeting the same WS-Resource may be interleaved, and whether partially completed WS-Resource updates within a given message execution may be observed by other concurrent requests is beyond the scope of the WS-Resource definition. • ISOLATION: no interference between concurrent transactions • If WS-Resource isolation is needed, we suggest the use of a transaction to provide a context within which isolation of WS-Resource updates can be provided • DURABLE: after transaction commits, changes are permanent • In the absence of a transactional unit of work, the level of WS-Resource update atomicity, recovery, isolation and durability provided by a Web service is implementation dependent. Modeling stateful resources with Web Services
WS-Resource Security • In the presence of a valid security context associated with a message exchange, a Web service capable of participating in the expressed security protocols must implement and enforce the security policies implied by the security context • In the absence of such security policy, the Web service is under no obligation to secure the execution of the message exchange nor the state of the WS-Resource designated by the WS-Resource context associated with the message request • The WS-Resource framework is not prescriptive with respect to policy that governs access permission to a WS-Resource through a Web service. The definition of specific security policy governing access to the WS-Resource is beyond the scope of the WS-Resource definition • If WS-Resource access control is required, we suggest the use of the functions such as those 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 Web service provides security of the WS-Resource is implementation dependent. Modeling stateful resources with Web Services
References • Web Services Resource Properties (WS-Resource Properties) – Version 1.1; S. Graham, K. Czajkowski, D.F.Ferguson, et alt.; May 2004. • Modeling Stateful Resources with Web Services – Version 1.1; I.Foster, j.Frey, S.Graham, et alt.; May 2004. • The WS-Resource Framework – Version 1.0; K.Czajkowski, D.F.Ferguson, I.Foster, et alt.; May 1998. Modeling stateful resources with Web Services