Web Services and Stateful Resources - Aspects of State
(Page 2 of 5 )
State is essentially any piece of information, outside the contents of a Web services request message, that a Web service needs in order to properly process the request. The information that forms the state is often bundled together into a "bag of state" called a stateful resource.
Several aspects of stateful resources are of interest to applications that wish to reason about state. These include:
How a stateful resource is identified and referenced by other components in the system
How messages can be sent to the stateful resource in order to act upon or query its state values
How the stateful resource is created, either by an explicit Factory pattern operation (createResource) or an operation within the application such as doSubmission from the purchase order application
How the stateful resource is terminated
How the elements of the resource's state can be modified
All of these aspects are addressed by various aspects of the WS-Resource Framework.
SkatesTown ScenarioWe'll examine the WS-Resource Framework in the context of an example from SkatesTown. Recall that in Chapter 4, "Describing Web Services," we described two services: StockAvailableNotification and POSubmission. These services manipulated stateful resources (purchase orders), although they did so in a very SkatesTown- proprietary fashion. The proprietary nature of SkatesTown's implementation meant that all of SkatesTown's business partners needed to build custom application interfaces to deal just with SkatesTown. Consider the case of one of SkatesTown's customers, the SkateBoard Warehouse. If this company uses Web services to deal with all of its suppliers, not just SkatesTown, it will likely end up with proprietary interfaces to each of its suppliers. This increases the integration costs of using Web services—although the systems are still cheaper to integrate using Web services than at the platform or programming-language level.
However, when SkatesTown updates its purchase order system to take advantage of the industry standards proposed by the WS-Resource Framework, it suddenly uses much more common approaches to many facets of its purchase order system. By adopting these common approaches, SkatesTown can take advantage of middleware and tooling products; but, more importantly, SkatesTown and its business partners can integrate their systems in a more standards-based and therefore cost-effective fashion.
The following list outlines the changes that SkatesTown needs to make to its existing Web services–based purchase order system. These changes are detailed in the remainder of this chapter:
The doSubmission operation of the POSubmission portType is updated to create a PurchaseOrder stateful resource (as you'll see in the next section, these are called WS-Resources) and return a WS-Addressing endpoint reference to "point to" the newly created PurchaseOrder resource and the Web service that allows requestors to manipulate it.
A POPortType is introduced to model the operations that can be executed on a PurchaseOrder resource. This PurchaseOrder service replaces the functionality that was available in the StockAvailableNotification service.
The notifications that used to be available via registering with the StockAvailableNotification are replaced by the way WS-Notification is used.
WS-ResourceLifetime is used to allow requestors to cancel PurchaseOrders and to receive notifications when a PurchaseOrder expires.
WS-ResourceProperties is used to allow requestors to read the details on the PurchaseOrder and update certain properties of the PurchaseOrder.
WS-ResourcesAt the heart of the WS-Resource Framework is the way that stateful resources are related to Web services. As mentioned earlier, Web services and the stateful resources they act upon are separate entities. We've described many things about Web services, including how to send messages to them (using SOAP), how to describe them (using WSDL), and how to discover them (using UDDI, for example). However, we haven't described how a Web service relates to stateful resources.
A WS-Resource is the combination of a Web service and a stateful resource. The Web service provides a platform and programming-language-neutral means of sending messages to the stateful resource; the stateful resource represents an identifiable unit of state information.
The WS-Resource Framework doesn't dictate exactly how the stateful resource is implemented; as is typical with Web services technologies, this sort of implementation detail is hidden. The stateful resource associated with a Web service could be implemented as a file in the filesystem, an XML document within an XML-enabled database, or a private communication channel between the Web service and the native implementation of a stateful resource in an operating system.
History: Open Grid Services Infrastructure (OGSI) 1.0 - There was one other attempt to model the association between Web services and state. The Open Grid Services Infrastructure (OGSI) was developed by the Global Grid Forum (GGF) between 2002 and 2004. The OGSI standard represented a set of conventions on Web services, particularly WSDL and a collection of portTypes to define the notion of stateful resources.
OGSI was developed as a result of the Grid community's desire to adopt and exploit the emerging phenomenon of Web services. Back in 2002, Web services was very early in its evolution, and many facilities needed by Grid computing (such as the ability to represent a system resource and reason about its properties and lifetime) were missing from Web services.
OGSI introduced the notion of a Grid Service as a variant on the Web service concept. The Grid Service was an attempt at a component model for Web services, defining a standard set of operations that can be performed on any Grid Service. This is analogous to an Object class in object-oriented languages.
OGSI introduced many concepts that appear in WS-Resource Framework and WS-Notification:
ServiceData—The means to represent state data and mega data
GWSDL—An extension to WSDL 1.1 to allow for portType inheritance
Grid Service References (GSRS)—A referencing mechanism similar to WS-Addressing
Notification—A simple point-to-point asynchronous messaging mechanism
ServiceGroups—A grouping mechanism for services
OGSI, however, had some significant short comings that impeded more widespread adoption. Chief among them was the aggressive use of WSDL and XML. GWSDL extended WSDL and therefore didn't allow generic WSDL tooling to be exploited to build OGSI systems. Furthermore, the service data concept used facilities from XML Schema that were beyond the current state of the art of most XML tools.
Another concern was that OGSI blurred the notion between stateless Web services and stateful resources. Although with proper use of URL encoding of resource identity this distinction is immaterial, many in the industry continued to be confused by this point, and with their confusion came the refusal to adopt OGSI.
In addition, the OGSI specification defined too many concepts in a single specification. It's more typical in the Web services community to define smaller specifications and then propose composability between those specifications.
WS-Resource Framework was introduced to provide solutions to the requirements addressed by OGSI in a fashion that was a much better fit with the broader Web services community.
Next: Stateful Resources >>
More Web Services Articles
More By Sams Publishing
|
 This article is excerpted from chapter 8 of the book Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418). Check it out today at your favorite bookstore. Buy this book now.
|
|
