Putting Web Services In Context

Network users take communications sessions for granted: Web sites recognize surfers from the time they log on until they click off. The phone system knows when a call begins and ends. But in the SOA world of loosely coupled systems and distributed applications, sessions aren't so simple. Most real-world implementations still depend on lower-level protocols or proprietary technologies, both of which can restrict a service's flexibility and potential for reuse.

Two standards released in April aim to change all this, but there's a catch. Although both come from the same group—OASIS, or the Organization for the Advancement of Structured Information Standards—they're backed by different vendor factions and have some overlapping functionality. However, they can work together, and we see both being necessary in the long term.

The standard most clearly targeted at session management is WS-Context, backed by Red Hat, Oracle, IONA and Arjuna. Its supporters compare it to HTTP cookies, the standard way in which Web sites keep track of visitors by storing small chunks of (usually) encrypted data on client machines. In addition to being used in SOA environments, WS-Context is also likely to be used as a means of sharing data in environments using SCA (Service Component Architecture), a new programming method aimed at making applications from smaller components that can run independently.OASIS also approved WS-Coordination, which is also aimed in part at session management. Backed by IBM, Microsoft and BEA Systems, its adoption is almost assured. However, unlike WS-Context, it isn't a full specification; like so many other Web services standards, it's an extensible framework, intended for users or vendors to add their own XML for session management.

In Session

Strictly speaking, session management hasn't been entirely absent from SOA. For example, support is included as an optional element in WS-Addressing, a more mature standard from the W3C used to route SOAP (Simple Object Access Protocol) messages. However, this ties sessions to particular SOAP addresses and works only for SOAs that actually use WS-Addressing. SOAs based on Web services often don't, as they can use be addressed through URLs instead. WS-Addressing is really needed only for Web services that traverse non-HTTP transports, usually JMS (Java Message Service).

There are alternatives based on lower-level protocols, but these are even less flexible. For example, Web services across the public Internet can use the session management capability built into SSL, but that works only for point-to-point links, not large distributed systems. Embedding session identifiers within XML messages themselves has the opposite problem: Without agreement on what will be used for a session identifier or where it fits into a message, every SOA will implement the spec differently, making interoperability impossible.

WS-Context standardizes the format and placement of session tracking data, giving every SOAP message a "Context" element within its header. Between the Context tags are a "Context-Identifier" element, containing a unique ID for the session, similar to a cookie. Optional elements and attributes specify the authority that generated the ID, how long the ID is valid for and any security that must be applied for the ID to be valid.Participants in a SOA can generate their own session IDs, but in a large distributed system it may be more convenient to centralize the process. WS-Context enables this through the Context Manager, an optional Web service that can set and edit the contents of Context elements. Built on top of WSDL (Web Services Description Language), this also simplifies governance, as the Context Manager by necessity knows about every session within the SOA.

Although intended to be embedded within SOAP headers, WS-Context has already been extended to other applications. The same elements can be used in Web services that use REST (Representational State Transfer), for example, and may also be used within SCA. Intended to apply SOA principles to application development, SCA also requires persistent sessions for communication between components within an application.Transaction Vs. Framework

WS-Context was created by the WS-CAF (Web Services Composite Application Framework) group within OASIS, originally chartered to produce three standards. The other two would have handled coordinating multiple Web services within composite applications and managing individual transactions, but both have now been abandoned. Their functionality is handled partly by BPEL (Business Process Execution Language) and partly by WS-TX (Web Services Transaction)—a rival spec developed within OASIS by a group including IBM and Microsoft, the Web services world's two most powerful players.

Like WS-CAF, the WS-TX group was chartered to develop three standards. All three were approved in April, the same time as WS-Context. WS-Coordination is the base standard, aimed at coordination of metadata. Rather than specifying how Web services can be coordinated, it gives them a framework for transferring information about coordination. Layered on top of WS-Coordination are two options that address the actual coordination: WS-AtomicTransaction and WS-BusinessActivity. The former addresses relatively simple point-to-point services, the latter deals with more complex applications. Both are designed to be extended.

Though intended as a framework, WS-Coordination also includes equivalents to the Context-Identifier element, effectively providing a way to set up sessions. However, it lacks an equivalent to the Context Manager, meaning that all contexts have to be handled by the Web services themselves. As far as sessions are concerned, this will likely limit WS-Coordination to relatively simple applications that don't need to reference a context server elsewhere. The WS-TX standards are also limited to SOAP. The full WS-Context specification will be needed in more complex SOAs, as well as in SCA and Web services using REST. Andy Dornan is Senior Technology Editor for InformationWeek and Network Computing. He can be reached at [email protected].