Service-oriented architecture continues to gain momentum as the new architectural model for both enterprise applications and packaged application infrastructures. With product suites supporting SOA development arriving daily and the barrage of SOA standards and information out there, enterprises are on SOA overload.

Whether you're developing custom software for your SOA initiative or purchasing a packaged application, wending your way through the ever-growing maze of Web Services standards is imperative to your success (see "A Guide to Web Services Specs and Standards"). There's a lot to learn. Some standards are necessary for building out a Web Services architecture--WSDL (Web Services Definition Language), SOAP (Simple Object Access Protocol) and WSS (Web Services Security)--but others, such as WS-Routing, aren't and have been superseded by one or more newer standards.

The Groups In Charge

Who's Who in Web Services Click to enlarge in another window

Three organizations are primarily responsible for Web services standards and specifications: Web Services Interoperability Organization (WS-I), World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) (see "Who's Who in Web Services," left). All three formulate standards and specifications through technical committees comprised of representatives from Web Services-based product vendors and industry experts. These organizations are akin to the Internet Engineering Task Force in terms of their influence in the industry. As with the IETF's standards, vendor compliance with standards and specifications by these Web Services organizations isn't required, but it's expected, and encouraged. Even highly competitive vendors, such as Microsoft, IBM, Sun Microsystems and BEA Systems, agree on the importance of complying with these Web Services standards.

Web Services Specs and Standards Click to enlarge in another window

The WS-I (www.ws-i.org) promotes interoperability between Web Services product implementations. WS-I is best known for its work on the WS-I Basic Profile (currently at version 1.1), a guideline of interoperability specifications for the core set of Web services standards: WSDL (Web Services Definition Language), UDDI (Universal Description, Discovery and Integration) and SOAP.

WS-I is also responsible for the WS-I Basic Security Profile which, like its sister guideline, details a set of interoperability guidelines for products implementing the OASIS WSS (Web Services Security) standard. Although compliance with these guidelines is promoted and supported by most Web Services vendors, it's not required. Compliance with the WS-I profile is more of a best practice adopted by vendors and enterprises in the industry.

The W3C (www.w3c.org) is the organization behind WSDL, UDDI and SOAP--the core set of Web services standards. W3C is also responsible for a number of XML-based specifications used to implement OASIS standards. Among them are XML Encryption, XML Signature and utility standards such as XSL (Extensible Stylesheet Language), XSLT (XSL Transformations), XPath and XQuery.

Meanwhile, most standards relating to Web Services--ones that enable specific business or IT functionality--come out of OASIS technical committees. OASIS (www.oasis-open.org) is the most prolific and influential of the three organizations working on Web Services standards. Its standards have given rise to entire markets of products, such as WSS (Web Services Security). OASIS is home to a wide variety of WS-* standards including WSS, WS-Addressing and WS-Reliability. OASIS' standards and specifications cross IT boundaries from transaction support to management. Standards such as WS-Policy are meant to encompass a large number of "subset" standards, such as WS-SecurityPolicy and others to come in the future.

The OASIS specifications are based heavily on object-oriented principles. As with principles of inheritance, they are easily extensible. Elements defined in "child" specifications are specific to the child specification, regardless of their meaning in the parent specification (think polymorphism). WS-* also allows for common use "objects," such as the endpoint reference element, which carries along information about the endpoint (including its address). That's a nice way of saying it's a URI, which necessarily carries along the protocol used to contact the endpoint (such as mailto, HTTP or FTP).

The endpoint reference element is then used to describe endpoints and clients in a variety of specifications: Both WS-Addressing and WS-Policy rely heavily on it, as do derived-domain specific specifications like WS-SecurityPolicy.

Understanding commonly referenced elements, such as the endpoint reference element, will give you a head start when you research a new WS specification. WS-Policy assertions and requirements are consistent across subspecifications, which gives policy engines the flexibility to interpret attributes and elements according to specific domains rather than inventing new protocol definitions to represent domain-specific processing instructions. That means a single, extensible, policy engine can handle multiple specifications, which can reduce the overhead and expense of deploying policy engines on a per-domain basis.