Section 18.5. Building on the Core Platform

18.5. Building on the Core Platform

Many specifications are evolving and building on the core Web services platform. An area of much recent interest is support for pub-sub (publish-subscribe). Currently, the Web service model is based on binding and directed messaging, in which service A sends a message to service B. In the publish-subscribe model some services define events that they emit while others subscribe to receive specific events. WS-Eventing [WS-Eventing] provides basic support for pub-sub over the Web services protocols. The WS-Notification family of specifications provides enhanced support for topics, topic trees, filtering, and event brokers. These capabilities more accurately mirror the capabilities provided by existing pub-sub systems such as MQSeries and JMS. The looser, more dynamic coupling that the pub-sub enables will complement SOA's find and bind model.

It is tempting to think of Web services being stateless. This is a bit misleading. Almost all Web services manage some state data. A purchase order service, for example, manages the data in purchase orders. IBM and several other companies define the Web Service Resource Framework (WS-RF) [WSRF] to better support the linking of state data with Web services. WS-RF builds on WS-Addressing, which introduces the concept of an endpoint reference (EPR). In its simplest form, an EPR references a specific Web service through a network address. The EPR might also contain reference properties and reference parameters that refine the reference. The reference properties and parameters might, for instance, identify a specific purchase order on which the Web service should operate. The reference parameters and properties are opaque to calling services, since only the service's implementation is assumed to understand them.

WS-Resource Framework allows the association of an XML Schema complex type with a WSDL portType. The complex type defines the logical shape or structure of the information that the WSDL portType supports. For example, the WSDL service might manage purchase orders, and the associated XML complex type defines the logical structure of the purchase order.

Authors sometimes refer to the associated complex type using the term implied resource pattern. Examining a portType often leads a programmer to infer the existence of the data structure. The portType that manages purchase orders might have an operation supporting adding a line item to a purchase order (PO). This leads the observer to believe that purchase orders contains line items, which is a reasonable deduction. There might be no single in or out message on any of the portTypes operations that clearly defines the XML schema for a PO. The implied resource pattern allows the portType author to formally document a logical model of the data that the service manages.

The XML complex type associated to a portType logically defines the shape (or type) of the instances of data that the service manages. The WS-Addressing EPR logically references or points to instances of this schema type.

Several specifications build on the basic concept of an implied resource. WS-ResourceProperties [WS-ResourceProperties] defines an abstract interface for getting and setting elements from the resource documents. For example, if there is an implied purchase order, WS-ResourceProperties would allow a caller to get or set elements in specific purchase orders. Another specification integrates with WS-Notification to support subscribing to events when specific elements of resources change.

In addition to the implied resource model, WS-ResourceFramework and WS-Addressing also support conversation state. A Web service can maintain state that is independent of long-lived data such as purchase orders, but that is shared across multiple invocations of operations. This supports a model similar to that of Stateful Session Beans in Enterprise Java Beans, or the conversational transaction model in systems such as IBM's Customer Information Control System (CICS) [CICS] and Information Management System (IMS) [IMS].

Management and administration is as important as the enabling of application integration and service interoperability. This motivates a recently evolving set of standards for management using Web services and management of Web services. Management using Web services builds on the basic elements of the Web services platform to support interoperable system and application management solutions. WSDL defines the interfaces to management applications and agents. SOAP, HTTP, and the WS-* specifications provide communication and interoperability between management applications, and between applications and agents. Finally, BPEL4WS provides a language for implementing complex systems management process, such as installing or upgrading software on multiple systems. Management using Web services will be an increasingly common model.

Because Web services support multiparty business solutions, it is important that participants be able to monitor participant business processes and services. Management of Web services defines standard, common portTypes for monitoring and managing services. As time progresses, more and more services will support both a business interface that defines what it does (manage purchase orders) and a control interface that supports systems management (get request status, get average response time, cancel operation).

Web Service Distributed Management (WSDM) [WSDM], a technical committee in OASIS, is defining a model for management using Web services and management of Web services. WSDM focuses on the base management interfaces. Other standards bodies, such as DMTF [DMTF], are defining concrete XML schema and portTypes for specific resources such as computer system or operating system.

The resource modeling and management of Web services is not without standards competition in the form of alternate proposals, WS-Management and WS-Transfer. Some standards convergence will need to occur in this space as well!

Web services also form the basis for interesting solutions to graphical user interface composition. A portal is a Web site that aggregates multiple applications' interfaces into role- and task-specific work spaces. The applications appear as interacting tiles or portlets that are aggregated into a page. These portlets support user interactions with Web services. WS-RemotePortlets supports a model in which the view (rendering) for a portlet occurs at a remote site. Instead of the portal using WSDL/SOAP to call a remote site and retrieve model information, which the portal then renders, WSRP [WSRP] allows the portal to call a remote site and receive HTML (or some other markup language) that it aggregates into a page. In essence, WSRP supports remote procedure call for views instead of for the view controller.

Web services thus has as a model for remote procedure call and messaging between applications, and, with WSRP, also a way of federating UIs. Web services would be incomplete without support for a data-centric model. The Database Access and Integration Services WG [DAIS] in the Global Grid Forum [GGF] defines a set of interfaces for federating and querying data sources using Web services. OGSA/DAI defines a specification to describe data formats, how to create, retrieve, update, and delete (CRUD) data; and how to replicate and transfer data.