Over the past couple of years, several technology vendors have defined a comprehensive set of specifications that, when complete, will provide an infrastructure for enterprise-class Web services interoperability. The names of these specifications generally begin with "WS-", so the group of them is sometimes referred to as WS* (pronounced "WS Splat").

This article identifies the important WS* standards, briefly defines those that have not yet achieved mass-market acceptance, and describes the current state of development for each. At the end, we offer our view of each specification's relative market importance.

We will use Figure 1 to structure the discussion. Note: "Composable" means that items are independent, and can be plugged together (or not) with relative ease. "Composable Service Elements" means that developers can add security, reliable messaging, and transactionality to their Web services in any combination.

1.  Transport Level

• HTTP/HTTPS: Currently at version 1.1.
• SMTP: Far less prevalent for Web services usage than HTTP. Worth considering for specific business applications.

• XML (including XML, XSL, XPath, etc.): Currently at version 1.0, although v1.1 is a Proposed Recommendation.
• SOAP: Currently version 1.1 is most widely deployed, although v1.2 has recently become a W3C Recommendation.
• Attachments for SOAP: There are two important specifications around SOAP Attachments: SOAP with Attachments (SwA) and Message Transmission Optimization Mechanism (MTOM). A third specification, DIME, has recently lost its momentum and is therefore no longer particularly significant.
  - SwA: Currently available for both SOAP 1.1 and 1.2, SwA is by far the leading mechanism for handling attachments in Web services. However, it will likely be supplanted by MTOM.
  - MTOM: Some vendors are going straight to MTOM without supporting SwA. MTOM appears to be the important Attachment specification for the future (late 2004 and beyond).
• WS-Addressing: This specification abstracts WS endpoint references away from the transport and messaging infrastructure, allowing them to be specified independently of the transport system. It is currently still private, and has not yet caught on significantly in the marketplace.

• WSDL: Currently at version 1.1, with v2.0 in progress at W3C.
• UDDI: Very important in the marketplace, although relatively few companies have actually deployed it. This spec is currently at version 2.0. However, v3.0 is already complete at the technical committee level and should supplant v2.0 shortly.
• WS-Inspection: Once a potential complement and/or competitor for UDDI, this private specification appears to have lost steam.
• WS-PolicyFramework (includes WS-PolicyAssertions and WS-PolicyAttachments): Currently a private specification, WS-Policy allows a Web service to specify exactly how it wants to be called. For example, a service might allow either Kerberos or X.509 authentication, but prefer Kerberos. We believe that this specification will become important and widely used over time.
• WS-MetadataExchange: A new, private specification that allows a Web service client to easily get the policy, schema, and WSDL information about another Web service. Likely to grow in importance.

5.  Security

• WS-Security: Already at an advanced stage within OASIS, WS-Security will continue to mature in 2004.
• Other important security specifications: All of these are currently private. All are likely to be important, probably by late 2004.
  - WS-Trust: Using Tokens to establish trust in a conversation
  - WS-SecureConversation: Gives the same security to a long-running conversation that WS-Security gives to a single message
  - WS-Federation: Decentralizes control over trust, authentication, and authorization
  - WS-SecurityPolicy: Allows specification of specific security policies within the WS-Policy framework.

• Multiple competing frameworks: None of these have real market traction yet. One major private initiative is called WS-Transaction. A competing effort is WS-Composite Application Framework, currently in OASIS.
• WS-Transaction: Describes coordination among distributed application components. It is made up of three sub-specifications: WS-Coordination, WS-AtomicTransaction (WS-AT), and WS-BusinessActivity (WS-BA).
  - WS-Coordination: Extensible framework for coordinating actions of distributed applications. This is the basis for transaction management (see next 2 sections).
  WS-AtomicTransaction: For managing tightly linked distributed transaction components using classic two-phase commit protocol.
  - WS-BusinessActivity: For managing transaction coordination between looser-knit components that may not be completely under the coordinator's control.
• WS-Composite Application Framework (WS-CAF): An OASIS-sponsored effort. Its stated purpose is "to propose standard, interoperable mechanisms for managing shared context and ensuring [that] business processes achieve predictable results and recovery from failure." It includes the following:
  - Web Service Context (WS-CTX): Lightweight framework for simple context management
  - Web Service Coordination Framework (WS-CF): Sharable mechanism to manage the life cycle of composite application messages
  - Web Services Transaction Management (WS-TXM): Supports three protocols across transaction managers (two-phase commit, long-running actions, and business process flows)

• WS-BPEL: The de facto standard and state of the art for specifying Web service-based business process orchestration. Currently in OASIS, this specification is likely to emerge as a standard in late 2004.
• Additional work is ongoing in W3C in the Web Services Choreography Working Group, which is drafting a more abstract definition of Web services-based business process components. A requirements document is complete, but this will take a long time to develop into something meaningful in the market.

• The WS-I Basic Profile 1.0 (BP1.0) defines interoperability guidelines for XML, XML Schema, SOAP, WSDL, and UDDI. This standard is critical to the industry. Both Gartner and Forrester/ Giga recently began recommending BP1.0 conformance to most customers seeking Web services guidance.
• BP1.0 is undergoing amendments for attachment processing, allowing multiple technologies.
• WS-I expects to release the Basic Security Profile 1.0 (BSP1.0) in July 2004, which will define proper usage of WS-Security. This will also be an important conformance milestone.
• Additional future WS-I profiles are not yet defined, but they are likely to follow the same prioritization as that described by this article.

10.  Portal
WSRP (Web Services for Remote Portlets) is a recently approved OASIS standard. It defines a framework for portlets based on standard Web services interfaces. The specification seems to have picked up market traction.

WS* Prioritizations
Following is our view of the relative market importance of each of the specifications mentioned here. If you are involved with Web services, we believe that Priority One items are absolutely required now. You should be working on Priority Two implementations, and planning for Priority Three. Priority Four items should be watched with interest.

Priority One

1. HTTP v1.0 and/or v1.1
2. XML (including XML Schema, XSL, XPath, XQuery)
3. SOAP v1.1
4. WSDL v1.1
5. UDDI v2.0
6. WS-I Basic Profile 1.0
7. WS-BPEL

1. SOAP v1.2
2. SOAP Attachments: SwA and/or MTOM
3. WS-I Attachment Profile 1.0
4. WSDL v2.0
5. WS-Security
6. SMTP (as required)

1. UDDI v3.0
2. WS-I Basic Security Profile 1.0
3. WS-Policy
4. WS-ReliableMessaging or WS-Reliability
5. WSDM
6. WSRP

1. WS-Addressing
2. WS-MetadataExchange
3. WS-Trust, WS-SecureConversation, WS-Federation, WS-SecurityPolicy
4. WS-Transaction OR WS-Composite Application Framework
5. WS-Choreography