Tech Road Map: Oasis Takes On Web Services Session Management

WS-Context bypasses lower-level protocols and proprietary technologies to share session data.

Andy Dornan, Contributor

September 7, 2007

3 Min Read
InformationWeek logo in a gray background | InformationWeek

CENTRALIZED PROCESS
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" 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, and any security.

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 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 already has been extended to other applications. The same elements can be used in Web services that use Representational State Transfer, or REST, for example, and may also be used within SCA, which also requires persistent sessions for communication among application components.

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

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.

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 also are 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.

Dueling Specs

WS-Addressing

WS-Context

WS-Coordination

Main backers

IBM, Microsoft

Arjuna, JBoss, Oracle

BEA, IBM, Microsoft

Standards body

W3C

Oasis

Oasis

Designed for

SOAP only

SOAP or REST

SOAP

Session binding

To a fixed reference (URL)

To a service or activity

To a transaction

Status

Required for specifying addresses in SOAP services

Designed specifically for session management

An extensible framework for transaction-based sessions

Read more about:

20072007

About the Author

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights