Crash Course: Get A Grip On Web Services Standards

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