Something odd seems to be going on in the upper layers of the Web Services stack, in that band of specifications that are either immature standards, or not yet at the standards stage. I’m talking about WS-* specifications, that include WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Security and more.

While there was relatively rapid consensus on the value of tried-and-tested standards at the lower end of the web services stack, where the likes of XML, SOAP and WSDL can get people on the road to a web services development approach, at the more abstracted WS-* level there still seems to be a lot of wrangling going on.

Some of the WS-* specifications have been described as overly complex for the requirements of the typical user, while others seem to dragging their heels in becoming true standards.

My colleague Tony Baer noted in a story for sister publication ComputerWire today that IBM will next week propose a new Web Services Interoperability profile for dealing with asynchronous business-to-business messages, which could represent a new direction for the organization to go higher up the web services technology stack.

As Tony put it: “After a somewhat stormy birth four years ago, WS-I has become one of the success stories in the web services standards world. Its role is devising profiles, or test cases, for determining if web services middleware from different vendors are truly interoperable… IBM is expected to propose the Reliable Asynchronous Messaging Profile, RAMP, at this year’s first major WS-I gathering.”

“RAMP will consist of snippets of three recent or pending web services standards,” Tony continued, “WS-Addressing, for specifying how an address is represented in the header of a SOAP message; WS-ReliableMessaging, which covers whether a message was received only once and, if applicable, whether it was received in the right sequence; and WS-SecureConversation, which authenticates the series of messages that occur in an exchange between two or more parties.”

You can read the entire article here (a fee may be required depending on your subscription status).

Meanwhile a little birdie tells me that at least one of the remaining specifications, WS-Policy, is to be handed to a standards body to begin ratification as a standard “any day now”.

The news was confirmed by one of the authors of the specification, though they asked not to be named in this article. The authors of the WS-Policy specification are IBM, BEA Systems, Microsoft, SAP, Sonic Software and VeriSign.

My source would not be drawn as to which standards body WS-Policy is about to be handed to, but the most likely candidates would appear to be either the World Wide Web Consortium (W3C) or the Organization for the Advancement of Structured Information (OASIS). Both have already taken the job of turning other WS* specifications into standards, with W3C taking WS-Addressing and OASIS doing WS-Security.

These WS-* specifications – some of which are closer to changing from a specification created by a group of vendors into a true standard than others – are seen by many as critical to the underpinnings of not only web services but also service-oriented architecture, or SOA.

While many of the web services standards are well tested and relatively mature — such as XML, HTTP, SOAP and WSDL — key capabilities that many would consider vital for mission critical applications, such as WS-Reliable Messaging, WS-Security and WS-Policy, are either relatively immature standards or have not progressed beyond the specification stage.

WS-Policy is designed to provide a general purpose model and syntax to describe and communicate the policies of a web service. It should provide a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML web services-based system, according to its authors.

WS-Policy defines a framework and a model for the expression of these properties as policies. It’s rather vital as it will handle how a particular web service deals with the likes of security, privacy, application priorities, user account priorities and traffic control in a web services environment.

From where I’m standing, some of the WS-* specifications are almost as important to building mission critical applications in an SOA manner as existing standards like XML and HTTP. For the good of the industry it behoves all parties involved to turn the remaining WS-* specifications into usable standards as quickly as humanly possible. Oh, and if they manage to find the balance between capability and complexity a little better than they did with UDDI, that would be no bad thing either.