Menu

Introducing WS-I and the Basic Profile

March 4, 2003

Rich Salz

Political History

WS-I, the Web Services Interoperability Organization, was announced last February in a press release from IBM and Microsoft. The release actually had a byline of Armonk and Redmond, which are of course the corporate headquarters of the two companies. While there were nine founders, the shared byline reinforces the conventional wisdom identifying the original catalysts.

Sun's absence was both notable and frequently noted. In May it was revealed that Sun's absence reflected a deliberate choice; court documents show that Microsoft's commitment to WS-I was contingent on Sun not being one of the prime movers. While this made those involved look disappointingly petty and churlish, we developers should take it as a hard lesson that the technology we get to use (or make) is often determined by politics. Developers who like laws, sausages, or standards should watch none of them being made.

Common sense eventually prevailed and Sun joined WS-I. After all, how credible can a web services standards body be if the owner of Java is no more than a second-class citizen? Sun's price was an increase of the size of the WS-I board, so that it could presumably coast through an election to claim the seat it felt it deserved. In October, WS-I members approved the board expansion, with elections to be held this month. In one of those funny coincidences, the announcement is one of only two files on the WS-I press page available in the proprietary Microsoft Word format.

Recently, a number of smaller companies have vigorously protested their exclusion from the board. Their point isn't without merit: smaller companies routinely get bleeding edge technology out faster, albeit to a smaller audience, than larger companies do. WS-I would benefit from having early-adopter first-hand knowledge of what works in the field.

The elections are soon. It will be interesting to see what happens.

Meanwhile...

While all the political games have been playing out, real work was also going on. The organization had its first meeting last April and announced the creation of three working groups (WGs):

  • Basic Web Services Profile: to profile the core specifications (XML Schema, SOAP, WSDL, UDDI).
  • Sample Applications: to illustrate some best practices for application development, in multiple languages using multiple tools.
  • Test Materials and Tools Development: to develop conformance tests for the Basic Web Services Profile.

It announced a fairly aggressive Fall release target for the first set of deliverables. But "deliverable" was left undefined, so it could mean anything from a first committee draft to a final, organization-approved specification.

Grammarians and other pedants who read the WG list carefully might have objected to the word "profile" being used as a verb. Standards are often written as frameworks, defining "slots" for particular algorithms or identifiers to be inserted. For example, SSL/TLS can use RSA, DSA, or various Diffie-Helman algorithms to exchange an encryption key. The actual encryption options include DES, AES, RC4, and so on. With no specific configuration, for example, openssl supports more than 25 combinations, which doesn't count some parameters such as the RSA key size (512, 1024, and 2048 bits are the most common) -- we really have over a hundred possibilities.

With so many options, ensuring interoperability across platforms can be difficult, if not impossible. In SSL/TLS, two vendors could each implement a couple dozen choices and still have nothing in common. Or a group of interested participants could get together and profile SSL/TLS, resulting in an "SSL profile" that specifies a common subset that everyone will support.

In a word, that's what WS-I is doing. The announced goal is not to define new standards, but to look at the existing ones, see what works, and identify the required subset so that different platforms can work together. In October WS-I released the first public draft of the Basic profile.

The Basic Profile

I've been reading a draft of the Basic profile lately. It is, frankly, an amazing document. Web service developers who are concerned about interoperability should get a copy, read it, and send in feedback. Do this soon: the WG wants to release one more draft this month and rapidly drive to completion.

The Basic profile is intended to ensure that web services can communicate. It does not define application semantics or enterprise policy (security integration, for example). It does cover the lowest levels needed for a consumer to find and successfully exchange simple messages with a provider:

  • Message description: how to use WSDL to define the messages that can be exchanged.
  • Discovery: how to use UDDI to register and locate service providers.
  • Messaging: how to use SOAP and HTTP to exchange messages.
  • Security: how to use HTTPS to guarantee the privacy and integrity of the messages being exchanged.

The Basic profile doesn't require that these facilities be used. It takes, instead, a prescriptive approach: if you use UDDI, here is how to do it, including a list of requirements to be met. If your application meets the requirements, it is conformant. Conformant applications should be able to exchange messages.

This is a very pragmatic approach, and it becomes easy to test an implementation for conformance. For example,

R1114: An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if the request method was not "POST".

It is trivial to write tests for this. Requirements often have a rationale. For example, in Processing SOAP Headers, I explained the importance of the mustUnderstand header, and how it can change the semantics of an operation. The Basic profile defines this requirement:

R1024: A RECEIVER MUST handle messages in such a way that it appears that all checking of mandatory headers is performed before any actual processing.

It then goes on to explain that "this guarantees that no undesirable side-effects will occur as a result of noticing a mandatory header AFTER processing other parts of the message," which is exactly what was discussed back in July.

Web services often use HTTP Cookies (see RFC 2965) to maintain state across a series of interactions. But this is generally a bad idea: it ties application information to the HTTP transport rather than using a SOAP header, it doesn't work with multi-hop messages, and so on. Nevertheless, because of integration with legacy servers and the ease of use, "SOAP and cookie" messages are often used. The Basic profile has the following to say about this:

  • They may be used but should not be required
  • They should conform to RFC 2965
  • The consumer must not have to know about the value

This is expressed as four requirements (R1120 through R1123) and each one is individually and easily testable.

The largest part of the Basic profile is devoted to WSDL. Approximately half of the 54-page document specifies requirements for conformant WSDL use. Which isn't very surprising. As we saw in Examing WSDL, the WSDL 1.1 specification is a somewhat sloppy effort.

Some of the WSDL requirements are clarifications, such as requirement 2713, which says that an empty soapAction attribute is the same as a non-existent attribute. Some of the requirements are requirements imposed on application developers, such as 2705:

A wsdl:binding in a description MUST use the same value, either "rpc" or "document," for the style attribute for all of its soapbind:operation's.

In other words, you can't mix and match RPC and document style in the same binding. This separation of programming style -- no doubt because one or more "WSDL wizards" allow only a global setting -- seems like a good thing to me. While there are a great many similarities between the two styles, keeping the separation between document and automatic data-binding makes sense architecturally.

One of the most interesting parts of the Basic profile is that it defines WSDL extensions such that an application can claim conformance in a machine-readable way. Claims can be attached to WSDL port, binding, portType, operation, and message elements. Claims on the higher-level elements (say, port) are inherited by the lower-level elements.

For example,

<wsdl:service name="StockService">

  <wsdl:port name="StockPort" binding="tns:StockBinding">

   <wsdl:documentation>

     <Claim xmlns="http://ws-i.org/schemas/conformanceClaim/"

            conformsTo="[TO BE SPECIFIED]"/>

   </wsdl:documentation>

   <soap:address location="http://example.org/Stock/"/>

  </wsdl:port>

</wsdl:service>

Among other things, this will allow developer tools to optimize code generation and analysis. Machine-readable annotations for standards conformance is a pretty exciting idea. I hope it lives up to its potential.

Feedback loops

There is, unsurprisingly, a large degree of overlap between the memberships of WS-I and the W3C's web services committees. In many cases the same people are involved. This can lead to some tight feedback loops. For example, requirement 2706 of the Basic profile requires literal, as opposed to encoded style, as specified in the use attribute of the various SOAP elements. In a February message to the SOAP working group, it was explained that since WS-I was doing this, WSDL 1.2 was going to drop support for encoded altogether.

At first glance, this is a simplification: the schema which appears in a WSDL file must exactly describe the message being sent. Unfortunately, this simplification means that SOAP RPC encoding is no longer directly supported. Remember what I said about hard lessons up above? Here's a follow-on: sometimes we do it to ourselves.