Crash Course: Get a Handle on Web Services Specs and Standards

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

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.

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.

Which End Is Up?So which standards and specifications should you concentrate on and which can you ignore?

Many specifications and standards may make it onto the list of those you need to know in Web Services. But for the next year, the three core standards and specifications you should familiarize yourself with, and add to any requirement list for Web Services-based product evaluations, are OASIS' WSS (Web Services Security), WS-Policy and WS-Addressing.

WSS has been approved as an OASIS standard, but WS-Policy and WS-Addressing have not, though both are expected to reach standard status in the near future and have already been widely adopted in a variety of Web Services product suites.

Security is obviously a must-have when dealing with any technology that reaches across departmental and organizational lines. WSS provides support for encryption and decryption of data, authorization and authentication, and the creation and verification of digital signatures. Although HTTP BasicAuth has long been used to secure Web services, it's a tactical rather than strategic solution to the authentication and authorization problem. And it's not practical for managing access to large numbers of services or to large numbers of users, as management costs associated grow exponentially as each piece of the equation grows.WSS, if properly implemented by a security provider such as Data Power, Forum Systems or Reactivity, can alleviate the management burden and provide a boost in performance for CPU-intensive encryption and decryption duties. But you can also place WSS on most enterprise service platforms, including WebLogic, WebSphere and OracleAS. Regardless of where you implement Web services security enforcement, it should be WSS-compliant.

WS-Policy defines a generic SOAP policy format. The specification is more about metadata than an implementation of any given policy, but learning about WS-Policy will let you understand how it will be used to distribute information regarding security, management and future Web services-specific policies as they are developed.

It not only defines how a policy should be formatted, but also how it should be attached or associated with SOAP messages. OASIS' WS-SecurityPolicy specification, for example, defines multiple points within a WSDL where a security policy may be attached--to port types, messages (input, output, fault) and bindings, and so on. WS-Addressing, for example, includes a mechanism for attaching a WS-Policy element to specific address types, such as endpoints.

WS-Policy itself uses "assertions" to instruct processing engines to apply policies within specific domains, such as security, privacy and traffic control. An assertion within the security domain, for instance, could require an element such as a credit card or Social Security number be encrypted. WS-Policy is important to your Web services strategy because it will be used by a variety of other standards and specifications to indicate how specific policies are applied to the data flowing across your network.

WS-Addressing is a replacement specification for WS-Routing. WS-Addressing includes a mechanism for identifying messages (MessageID), specifying the recipient (To) and to whom a reply should be sent (ReplyTo). It is inserted into the SOAP header and extends the input, output and fault messages within a WSDL port-type element with an Action attribute. Its terminology and use is similar to that of SMTP because the message may flow through several intermediaries before arriving at its intended destination.WS-Addressing may seem extraneous--after all, most SOAP messages are sent over HTTP, the sender and receiver are known, and the SOAP action is carried in the HTTP header. But WS-Addressing is important because it removes transport-dependence from SOAP. If the destination endpoint is JMS (Java Messaging Service), for example, the URI can't use HTTP headers to determine which operation to call nor assume the client is necessarily the endpoint to which the service should reply. So you could use JMS headers instead, right? Sure you could, but this breaks the basic premise that SOAP is self-contained and doesn't rely on any given transport.

WS-Addressing removes any reliance on transport headers or parameter mechanisms in order to access a Web service. This is increasingly important in SOA implementations, where services aren't required to be transported over HTTP--though most implementations today take advantage of this ubiquitous protocol.

The Rest of the Story

Several up-and-coming specifications and standards are, or will be, tangentially important to your SOA infrastructure--transaction-based specifications, management, more security and reliable messaging are all in the works now. But starting with WS-Policy, WS-Addressing, and WS-Security should get you up to speed on the most relevant standards necessary for deploying your SOA infrastructure and lay groundwork for the standards yet to come.

Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator, and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected]. 0