View all newsletters
Receive our newsletter - data, insights and analysis delivered to you
  1. Technology
March 24, 2006updated 19 Aug 2016 10:10am

What’s up with the Web Services stack?

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

By Jason Stamper Blog

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

Content from our partners
AI is transforming efficiencies and unlocking value for distributors
Collaboration along the entire F&B supply chain can optimise and enhance business
Inside ransomware's hidden costs

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.

Websites in our network
Select and enter your corporate email address Tech Monitor's research, insight and analysis examines the frontiers of digital transformation to help tech leaders navigate the future. Our Changelog newsletter delivers our best work to your inbox every week.
  • CIO
  • CTO
  • CISO
  • CSO
  • CFO
  • CDO
  • CEO
  • Architect Founder
  • MD
  • Director
  • Manager
  • Other
Visit our privacy policy for more information about our services, how New Statesman Media Group may use, process and share your personal data, including information on your rights in respect of your personal data and how you can unsubscribe from future marketing communications. Our services are intended for corporate subscribers and you warrant that the email address submitted is your corporate email address.