The New Nation - Internet Edition

Azizur Rahman

WS-Security provides the standards on how to apply security to messages, but it does not specify what security measures should be applied. WS-SecurityPolicy, which uses the WS-Policy language, allows for allows for the owner of a service to describe their security policy. Service owners can specify acceptable algorithms for encryption, formats for security tokens, and other information on how and when to apply security.

WS-Security can protect single SOAP messages, but it does not address how to protect a series of related SOAP messages. In a typical web service, it is common to exchange a series of messages with a consumer during the course of an interaction. WS-SecureConversation builds upon WS-Trust, WS-SecurityPolicy and WS-Security to provide a way of protecting a series of messages that fall under the same security context.

WS-Federation provides a language and set of procedures to broker trust relationships between disparate security domains. Businesses can use it to interact with external partners without the need to maintain authentication and authorization information for each employee of an external organization. In oversimplified terms, WS-Federation is like a single sign-on solution for Web Services. Using WS-Federation, a consumer of a new Web Service could automatically pass the relevant authentication information without the need to set up an account with that service provider.

Messaging

Getting a Web Service message from point A to point B is not always a simple task. A Web Service needs to assure receipt of the correct number of messages at the correct endpoint. SOAP does not contain inherent support for advanced messaging features needed by enterprise services.

WS-Addressing addresses the limitations of how to delivery and address SOAP. There is no addressing information given in the SOAP header and therefore addressing information is normally the URL of the Web Service. This places restrictions on advanced types of routing and configuration of Web Services. For example, it does not allow a Web Service to reply-to an address different from the one that invoked it. WS-Addressing specifies a means to identify the intended recipient, a reply-to address and a message ID. It also provides a mechanism to specify addressing errors. Many of the other WS-* standards use WS-Addressing.

WS-ReliableMessaging assures the reliable delivery of a sequence of messages. It contains a great deal of flexible in defining delivery assurances. A service owner can require the consumer receives messages in order, at least once, only once or at least once. Additionally, it can tailor the sending of acknowledgements. A service can require acknowledgments for each message or a series of messages. It can also specify whether it wants acknowledgement of delivery or only notification of failure.

Additional standards define advanced messaging patterns, such as the publish/subscribe message pattern. A publish/subscribe message pattern is familiar to anyone who has ever subscribed to a newsletter, newspaper or magazine. A typical situation involves a producer of information publishing a new message. A subscriber chooses which messages to receive by having subscriptions to messages of interest. Often there is an intermediary, called a notification broker, who keeps track of subscriptions. This alleviates producers of information from needing to handle the complexities of managing subscriptions and delivering information to all subscribers.

WS-Notification and WS-Eventing are two competing standards that implement publish/subscribe messaging. There are some technical differences between these standards, but not enough to provide meaningful differences. In the end, a user will likely choose which standard to use based upon which standard gains more implementation.

Policy

The WSDL describes Web Service operations and bindings, but it is insufficient to describe non-functional constraints such as security and quality of service. WS-Policy provides a general framework for describing Web Service policies. Other WS-* standards such as WS-Security and WS-ReliableMessaging define policy documents relating to their requirements. Likewise, organizations can define their own, non-standard policy documents using the WS-Policy framework. By using the WS-Policy, Web Services can advertise mandatory and discretionary requirements of binding to their service.

Orchestration

A Web Service is not usually a complete application, but is a part of a larger application. In many respects, it is useful to think of a Web Service as a single subroutine in a larger program. In order to provide a useful function, something needs to compose multiple Web Services to perform complex tasks. A developer can use typical programming languages to compose Web Services or use a Web Services orchestration language.

The Web Services Business Process Execution Language (WS-BPEL) is a XML-based language that composes Web Services into complex tasks. Think of a BPEL as a scripting language, but designed with Web Services in mind. A developer creates a BPEL script and executes that script in an orchestration engine. The BPEL script should be independent of vendor implementation and therefore portable across orchestration engines.

Another advantage of WS-BPEL is that there exist multiple graphical modeling tools to facilitate the creation of BPEL scripts. Business analysts with minimal technical knowledge can use these tools to model business processes and actually create executable code from these models. In the future, these tools may be sophisticated enough to allow business analysts to create new applications without the technical knowledge.

The Enterprise Service Bus

The Enterprise Service Bus (ESB) is a concept that goes beyond the realm of Web Services. It is not a set of standards, but rather a term that covers a wide-range of technological implementations. The fundamental concept behind the ESB involves integrating disparate distributed applications using mediation and routing. ESBs often add commonly needed functions. Common services include support for WS-* standards, load balancing, advanced message routing, transformation between transport layer protocols, message filtering, business process management, logging, auditing and advanced error handling.

Next Steps

A quick and simple way to get started with Web Services is to start experimenting. The open source software described above provides a great opportunity to pilot Web Service technology without a large upfront investment. Developers can create example Web Services from scratch or remote-enable existing software by wrapping them with Web Services. This approach quickly demonstrates the value of Web Services without introducing a great deal of risk.

Ultimately, Web Services can provide organizations with many benefits. Web Services can expose legacy application logic across networks enabling otherwise isolated applications to share their data. Web Services enable reuse of resource by sharing commonly needed functions and data across an organization. Each organization will need to determine how best to use Web Services within their infrastructure in order to realize these benefits.