Section 5.1. Addressing Web Services


5.1. Addressing Web Services

In a first approach, one could build a simple solution to the addressing problem by using the mechanisms that the current Web architecture provides to identify and address Web "resources" (that is, Web pages and any other Web-accessible resource). This would essentially mean borrowing the addressing model used by the HyperText Transport Protocol (HTTP). A uniform resource identifier (URI) identifies a Web resource, and the HTTP protocol clearly defines how to use these identifiers to direct requests to the resource. This is a powerful and well-understood mechanism that supports the operation of the Web. Following this model, one could assign a unique URI to each service endpoint and use HTTP headers to encode any additional information required in the course of the interaction. There are, however, important differences between traditional Web interactions and Web services interactions, which render the URI-HTTP addressing and interaction model insufficient as a solution for the Web services addressing problem. Following are some important characteristics of Web services interactions to take into account when considering the addressing problem:

  • Access to services is not limited to a single protocol. SOAP messages might be, and are likely to be, carried over protocols different from HTTP. These protocols can include proprietary messaging protocols. Several different protocols may even be used in the course of a single service interaction.

  • Service interactions are not restricted to simple synchronous request-response exchanges. Typically, they involve asynchronous messages, too, and they are rich in quality of service properties, such as security and transactions.

  • Web services support business interactions that are typically long running and stateful. That is, they comprise several related message exchanges over a potentially long period.

These characteristics are a direct reflection of the kind of real-world problems that Web services intend to address. SOAP messages that one enterprise sends to another are typically carried over different transport protocols along their path. Initially sent by the originating application (possibly using a proprietary protocol), these messages are transmitted over HTTP between the two enterprises and then delivered to the target application, possibly over a third protocol. Similarly, asynchronous interactions (over e-mail or other messaging protocols), are a fact of the day-to-day interaction between businesses and their customers. Existing messaging protocols already define a specific mechanism to support the asynchrony of the interactions. For example, they provide reply-to addresses for follow-up correspondence and allow for the identification of messages so that future responses can be correlated to the original message.

Note also that when business interactions are automated, quality of service guarantees become essential. For example, it is necessary to ensure that transmission errors and application failure situations are appropriately addressed, unauthorized access is prevented, confidentiality of the interaction adequately protected, etc. In short, quality of service guarantees a fundamental aspect of the interaction with a service endpoint, to an extent not found in regular Web interactions.

The stateful character of business interactions is particularly important. Service and business interactions usually comprise several interrelated message exchanges with each of the involved parties. These messages are logically related and are processed within a common context, even if they are not exchanged consecutively. The term used to describe this type of interaction is stateful. Individual applications can manage themselves the stateful character of a service interaction, but a cleaner and more efficient model results if the basic interaction framework directly embeds support for stateful interactions.

URIs and the HTTP protocol have proven their value in supporting today's Web. However, central as they are to the architecture of the Web, they were not designed to support rich, flexible interactions, such as the ones just described. The requirement that can be derived from these characteristics is for an addressing mechanism that is protocol independent, well structured, aware of Web service metadata standards, and compatible with the SOAP messaging model.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net