Section 18.2. Standardization

18.2. Standardization

Most of the specifications that comprise the Web services platform discussed in this book were created jointly by a small group of software vendors. Several of the lowest-level specifications are now either de jure standards or on the way to becoming such (SOAP, WSDL, WS-Security, WS-Addressing, WS-BPEL).

However, as of this writing, many of the others are not yet undergoing the standardization process. One major reason for the relatively slow rate of submission to standards bodies is the importance of creating a sufficient level of shared technical understanding among author companies, to ensure that the new specification is technically sound and has a reasonably good chance of becoming an industrywide standard. Unlike previous standards approaches, the companies authoring these specifications go through several rounds of interoperability testing and composition of standards on customer business scenarios before submitting to a standards body. Unimplemented and untested specifications have been submitted in the past, leading to poor interoperability or irrelevancy.

If a good specification design process seriously intends to result in a successful standard, it needs to cover the following steps:

• Development of an initial concept, followed by iterative improvement, until the authors feel sufficuently comfortable with its quality to release it for wider public review.

• Release of the proposed specifications to the public, and gathering of feedback from a wide number of interested customers and vendors.

• Testing of initial implementations for multivendor interoperability that will validate the technical soundness of the proposed specification.

• Publication of an updated document, with royalty-free license terms and submission to a de jure standards body as appropriate.

18.2.1. Concerns About the Standardization Process

There has been much industry unease and debate about the delay in getting these specifications to de jure standards bodies such as the W3C and OASIS, which has resulted form the process outlined in the previous section. The following are some of the positives and negatives of the preceding approach.

The main advantage is that by the time it completes, it's likely that the resulting specifications can be successfully implemented, can be integrated with other specifications, solve real business problems, and will actually work. In fact, it is not uncommon for other standards organizations (notably the IETF and OMG) to only standardize specifications after they have been proven in practice. The W3C standardization process also has a specified implementation and validation stage.

Another positive of this process is that it allows for vetting "false start" specifications. An example of such a specification is DIME. [DIME] It was proposed as a higher-performing alternate to SOAP with Attachments [SwA], but was later retracted. It introduced new security concerns, and a much better solution was invented (in the form of MTOM [MTOM] and XOP [XOP]). Because DIME was still in a draft proposal stage, it was retracted more quickly and easily than if it had been submitted to a standards body and a technical committee had been formed to standardize that area.

Publication of specifications, vendor interoperability testing, and early developer kits make technology available to users at an early stage. They provide a forum for feedback about existing business scenarios and new ones that the specification makes available. It also stimulates the definition of additional, complementary technology.

It is also important to recognize that Web services are a single integrated platform supporting incremental adoption. In order for a family of specifications to work together to form such an integrated platform, it is essential for the specification developers to have common underlying objectives and principles. Unfortunately, the principles of simplicity, composeability, and interoperability that govern the Web services platform are all qualitative measures. It's difficult to achieve a consensus with such a large number of contributors and interests.

Finally, it is unrealistic to think that complex specifications, such as those for workflow (WS-BPEL) and transactions (WS-AtomicTransaction and WS-BusinessAgreement), can be developed by a large committee of people, without a strong starting point, in any reasonable length of time. Looking back at the history of the Internet, it is easy to identify many technologies that have been developed by key individuals instead of committees (for example, MIME and HTTP). It is also easy to identify committee-designed specifications that have had very little traction and adoption (for example, OSI and WfMC).

Although a standard needs wide input and participation to succeed, it is important to recognize the value of simple, lightweight specifications that focus on solving the immediate and critical problems well, rather than addressing a conflicting requirement's space identified by a large group of technical experts.

In the end, the biggest advantage of this slow (and sometimes frustrating) process might be its success. The two specifications that anchor Web services today are SOAP 1.1 and WSDL 1.1. Both specifications represent de facto, rather than de jure, standards and were developed jointly by a small group of vendors. Standardization in de jure standards organizations takes a lot of time. If the specifications developed by the aforementioned process result in workable solutions to immediate problems, they're viable technologies to be used until the formal standards are completed.

The authors of this book are confident that in spite of a the industry angst it may have caused, this approach to standardization will prove to be very effective in producing a working, integrated, componentized, and composeable Web services platform.