Intermediaries are entities positioned between a client and service provider that provide additional functionality and value-added services. Web-based intermediaries are widely in use, offering functions like customization, personalization, caching, filtering, and transcoding by modifying and enhancing data as it flows between a Web client and server. Intermediaries work by intercepting messages, performing their functions, and forwarding the altered message to the ultimate receiver. There can be many intermediaries between client and service, wherein messages are forwarded from one intermediary to another until they reach their ultimate destination.

Intermediaries offer a nonintrusive way to extend the functionality of the client and the server. They offer flexibility as well, since they can be dynamically added and removed. Intermediaries are widely used in the real world; see the sidebar below for an example. In this article, we'll offer an introduction to the details of SOAP intermediaries, with a particularly close look at one way in which a message's SOAP headers can determine the path that message takes through various intermediaries. We'll also take a brief look at some of the ways you can make use of SOAP intermediaries in your projects.

Adding extensibility with SOAP

Intermediaries make a lot of sense in the Web services world. Web services protocols (in particular SOAP) provide clean, decentralized, and modular support for intermediaries. Intermediaries themselves can be implemented as SOAP services. Extensibility has always been one of SOAP's major design goals, and intermediaries are supported by using the SOAP extensibility model. SOAP's extensibility stems from its header, in particular the actor and the mustUnderstand attribute. Some argue that, because SOAP can take advantage of HTTP extensibility, it does not need to define its own extensibility mechanism. This argument does not make much sense, however, in light of the design of the Web services stack and the layers in which SOAP and HTTP are defined.

In Figure 1 (taken from IBM's Web Services Conceptual Architecture white paper; see Resources for a link), you can see that HTTP is a transport-level protocols and SOAP is a messaging-layer protocol. SOAP can be used in combination with a variety of transport protocols -- including SMTP, JMS, and other protocols in addition to HTTP -- and does not depend on any particular network protocol. Although HTTP is a widely used protocol for SOAP, SOAP toolkit vendors have also started providing support for other protocols, like SMTP. And even though SOAP can take advantage of transport-layer extensibility mechanisms like HTTP's, we should not forget that SOAP messages may travel across several different transport-layer protocols before they reach their ultimate destination. In such cases, using the HTTP extension framework is not desirable.

The purpose of a SOAP intermediary is to provide a mechanism that allows SOAP applications to provide and access value-added services and functions. SOAP intermediaries can process the messages intended for them and then forward those messages to their next destination. These intermediaries can be placed along the path that SOAP messages take between the service client and service provider (see Figure 2).

SOAP intermediaries are included along the SOAP message path using the SOAP header. The attributes of the SOAP header entry -- actor and mustUnderstand -- determine who should process the header and whether the processing should be mandatory or not.

The SOAP actor attribute plays the key role in identifying which part of the SOAP header entry is intended for the receiver. The receiver could be an intermediary or the ultimate destination of the SOAP message. Both the intermediaries and the ultimate destination are identified by a URI. When the actor attribute is not present, then the SOAP processor for the header entry is the ultimate destination of the SOAP message.

The SOAP mustUnderstand attribute is used to indicate whether a header entry is mandatory or optional. The value of this attribute can either be 1 or 0. 1 indicates that the header entry must be processed by the actor indicated in the header and 0 indicates that such processing is optional. Leaving mustUnderstand out of the header is equivalent to setting its value to 0.

SOAP intermediaries (or SOAP processing nodes) should follow the processing model laid out by the SOAP specification for processing header entries. The processing model states that:

• An intermediary can only process the header entry of the SOAP message intended for it.
• Before forwarding the message to the next receiver, the intermediary should remove the header entry intended for it.
• An intermediary can add new intermediaries to the message's path by adding new actor and mustUnderstand entries in the header.
• A fault message should be generated whenever a failure occurs at an intermediary. The SOAP Fault element generated must contain a faultactor element, whose value indicates the intermediary where the failure happened.

Back to top

Implementing SOAP-based intermediaries

So far, we've learned that SOAP intermediaries are SOAP processing nodes along the SOAP message path, which can process and forward SOAP messages. Now let's take a look at some the technical issues involved in implementing this functionality, including:

• Routing
• Security
• Knowledge of intermediaries supported by service provider

Routing

Routing is the process of delivering a SOAP message through a series of SOAP intermediaries. SOAP specifies a mechanism for targeting SOAP messages, but does not specify a mechanism for routing them.

For example, let us consider a SOAP message going from a service client to a service provider through Intermediaries A and B (see Figure 2). The SOAP message sent from the service client targets one part of the SOAP message for Intermediary A and another part for Intermediary B using the SOAP actor attribute, but it doesn't contain the routing information for the SOAP message. In other words, it doesn't say which intermediary should come first in the message path.

As a SOAP message is bound to transport protocols like SMTP and HTTP, you can say that the message path model of these protocols can be used to define the SOAP message path. But these protocols lack a mapping to the SOAP targeting model. So the message path defined by these protocols can be used to describe only a single hop within the SOAP message path and is not sufficient to describe the SOAP message path from service client to service provider as illustrated in Figure 2.

WS-Routing
The proposed WS-Routing specification defines a message path model that is fully compatible with the SOAP message model and which makes it possible to describe the complete exchange of a SOAP message from service client to service provider. WS-Routing also uses the SOAP extensibility model to describe the SOAP message path. This specification defines a single SOAP header entry, which describes a forward -- and, optionally, a reverse -- message path for a SOAP message for the purpose of exchanging messages along the SOAP message path. By defining an optional reverse path, WS-Routing enables two-way message exchange patterns, such as a request/response pattern.

WS-Routing describes the SOAP message initiator, where the message starts, as the initial WS-Routing sender. As noted, WS-Routing uses a header entry for describing the message path. The WS-Routing header entry indicates the ultimate WS-Routing receiver and zero or more WS-Routing intermediaries in the forward message path. The ultimate WS-Routing receiver is the final destination of the message sent by the initial WS-Routing sender. Using the appropriate header entry, you can define an optional reverse message path, indicating a possible path for messages to be sent back to the initial WS-Routing sender. On the return trip, the reverse path becomes the forward message path. The rules for the exchange of messages remain the same for both forward and reverse message paths. This means that the initiator of the message is always the initial WS-Routing sender and the ultimate destination is always the ultimate WS-Routing receiver.

WS-Routing defines a certain set of rules to describe the message path from the WS-Routing sender to the WS-Routing receiver.

• The initial WS-Routing sender must generate a WS-Routing path header to indicate the WS-Routing message path. The intermediaries in the message path should be indicated using a via element. This element should be present as a subelement of the fwd or rev element. fwd describes the forward message path and rev describes the reverse message path; the latter is optional. If the rev element is present, the reverse message path is built dynamically when the message travels along the forward message path. The ultimate destination of the WS-Routing message may be indicated using a to element. If the to element is not present inside the path header entry, then the ultimate destination is designated by the last via element. The to and via elements identify the receiver and intermediaries by means of a URI.
• The WS-Routing receiver should inspect the path element upon receiving the message in order to verify that it is in fact the intended recipient of the message. If there are no via subelements in the fwd element, or no fwd element at all, then the to element should be inspected to find this information. A WS-Routing fault should be generated when the to element is empty or identifies a different receiver. If a fwd element that contains one or more via elements is present, the receiver should remove and inspect the top via subelement of fwd and verify that it is the intended recipient of the message. If it is not, the receiver should generate a fault. This receiver will become the ultimate destination when (1) there are no via elements listed in the fwd element after the removal of the top via element, and (2) there is no to element.
• The WS-Routing intermediary should inspect the fwd element for via elements. If they are present, the intermediary should forward the WS-Routing message to the next intermediary in the message path, the identity of which can be obtained from the via element. If no via elements are present, then the message should be forwarded to the ultimate destination, identified by the to element. If a rev element is present, then the intermediary should add a via element as the first subelement of that rev element. The value of this via element should indicate the reverse path. A fault should be generated when the forwarding process fails or the reverse path information cannot be provided.
• If the reverse message path of a WS-Routing message is to be used for sending another message, the ordered list of via elements in the rev element is used as the list of via elements in the fwd element.
• Only an initial WS-Routing sender may insert a rev element for describing the reverse message path.

The WS-Routing message is transferred in the same manner that SOAP messages are delivered. It is delivered to the first WS-Routing receiver in the forward message path over the underlying protocol. If this receiver is an intermediary, then the message is forwarded to the next receiver in the forward message path, which could be the another intermediary or the ultimate destination.

The simple example in Listings 1 and 2 below shows how to specify the forward message path using WS-Routing. Figure 3 illustrates the process: The WS-Routing service client is the initial WS-Routing sender and the WS-Routing service provider is the ultimate WS-Routing receiver. The message passes through a WS-Routing intermediary.

		

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <mp:path xmlns:mp="http://schemas.xmlsoap.org/rp/" 
      SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="1">
      <mp:action>http://www.ibm.com/quotes</mp:action>
      <mp:to>http://www.ibm.com/quotesservice</mp:to>
      <mp:fwd>
         <mp:via>http://www.compress.com/compress</mp:via>
      </mp:fwd>
      <mp:rev>
         <mp:via/>
      </mp:rev>
      <mp:from/>
         <mp:id>uuid:AS2324S4-CE2A-F9DC-BCB7-AS42B16F61E1</mp:id>
    </mp:path>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
        ...
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

	

The via subelement of the rev element contains an empty value. This indicates an implicit reverse path, which will be provided by the underlying protocol. The message defines some elements apart from those we've already discussed. An action element is used to indicate the intent of the message; a from element is used to indicate the sender of the message; and an id element represents the unique identifier of the message and should be generated only by the initial WS-Routing sender.

		

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <mp:path xmlns:mp="http://schemas.xmlsoap.org/rp/"
       SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="1">
      <mp:action>http://www.ibm.com/quotes</mp:action>
      <mp:to>http://www.ibm.com/quotesservice</mp:to>
      <mp:fwd/>
      <mp:rev>
        <mp:via/>
      </mp:rev>
      <mp:from/>
      <mp:id>uuid:AS2324S4-CE2A-F9DC-BCB7-AS42B16F61E1</mp:id>
    </mp:path>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
        ...
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

	

Because you can describe an entire message path with WS-Routing, a SOAP message does not require a binding to a transport-layer protocol (like HTTP) for describing the message path.

Security

SOAP messages travel from their originator to their ultimate destination, potentially by passing through a set of intermediaries along the message path. SOAP intermediaries are by definition men in the middle and are prone to attacks. Security breaches on systems that run intermediaries can result in serious security problems, like loss of secure information and message integrity, which will raise questions of trust. Currently, the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols are used to provide transport-level security for Web services. Although the security of SOAP messages that do not pass through intermediaries can be assured by SSL/TLS, security breaches at the intermediaries will lead to nonsecure end-to-end communication. To improve this situation developers need to introduce application-level security to the Web services world. In addition, there are potential security risks when SOAP messages are transferred across different protocols. A security breach may result when the indication of the authenticity of the message's originator needs to be translated from one secure transport protocol to another.

Integrating security functionality into the application to secure end-to-end communication and avoiding security breaches in transferring security information from one secure protocol to another is not an easy task. These security issues should be addressed at the SOAP layer in conjunction with existing secure transport mechanisms like SSL to provide the strongest protection.

WS-Security
The Web services security model, proposed by IBM and Microsoft, supports the use of existing secure transport mechanisms like SSL/TLS in conjunction with the WS-Security specification and other specifications to provide message integrity and confidentially across multiple transports, intermediaries, and transmission protocols. The WS-Security specification defines the core facilities for protecting the integrity and confidentiality of a message, as well as mechanisms for associating security-related claims with a message. (See the Resources section below for more on WS-Security.)

Knowledge of intermediaries supported by service provider

A service client should know about the intermediaries supported by a service provider. Specifically, the service client should know which intermediaries are processing the request in a message's path before it reaches its ultimate destination; the client should trust all of these intermediaries. There should be a standard way of querying and inspecting the service provider to get the information on the intermediaries that it supports. This is another area where developers need to improve the appropriate standards in order to encourage the use of intermediaries.

Back to top

Potential real-world SOAP-based intermediary services

As Web services evolve, we expect a lot of applications based on SOAP intermediaries. Now that you understand how SOAP intermediaries work, let's take a quick look at some possible ways that Web services architects will be using them.

Service-level agreements

In the future, Web services will require service-level agreements (SLAs) to be set up between the service client and service provider. (For more on Web services and service-level agreements, see the Resources section below.) These SLAs will include quality of service (QoS) guarantees (setting guaranteed levels of response time, reliability, etc.), exception rules, and penalties for violation of guarantees. Third-party intermediaries can provide important SLA-related services: negotiating and validating an SLA, checking for SLA conformance, and gathering customer satisfaction metrics. As Web services evolve, we might see the evolution of a new breed of companies called SLA authorities, similar to the certification authorities who currently provide digital certificates. These trusted SLA authorities will use SOAP intermediaries to provide the above mentioned SLA services.

SOAP compression

SOAP uses XML as its payload. Since XML is verbose, data stored in an XML document usually occupies substantially more memory than the same data in binary form. This increase in message size effectively results in an increase in data transmission time. SOAP intermediary nodes can be used to compress and forward the SOAP messages. At the receiving end, there should be another intermediary node that can decompress and forward the message to its ultimate destination. These intermediaries can be kept at the Web service gateways.

QoS intermediaries

In some Web service usage scenarios, users will require high-performance, reliable, and secure ways to transfer service requests and receive responses. This might involve a lot of infrastructure requirements, as with the use of a VPN; such heavy requirements are undesirable for some businesses. These services can be provided by an intermediary through which interested businesses can route their messages on demand. These intermediaries can provide reliable services using private networks, message queues, and publish/subscribe systems. They can also provide value-added services like caching, logging, etc.

Back to top

Conclusion

In this article, we saw how SOAP and XML provide a clean and modular approach for supporting intermediaries. Also, we looked into the potential value-added services that can make the intermediary model, and some of the issues which needs further work. As Web services evolve, we expect these issues to be addressed (for example, by WS-Routing and WS-Referral). Businesses can utilize the intermediary model outlined above to provide value-added services. Web services architects could design their systems to take advantage of this model, which provides a neat way to route service requests and responses via the outsourced, value-added services provided by third parties.

Resources

• Check out IBM Research's work on Web intermediaries.
  
  
• IBM's WebSphere Transcoding Publisher also makes use of Web intermediaries.
  
  
• Learn more details about SOAP headers by reading the SOAP specification.
  
  
• To learn more about the big picture that SOAP intermediaries fit into, check out the IBM Web Services Conceptual Architecture. (Document is in PDF format.)
  
  
• "Guarantee your Web service with an SLA" by Judith Myerson (developerWorks, April 2002) describes service-level agreements and the way they might fit into a Web services environment.
  
  
• Microsoft's site has more on the WS-Routing protocol.
  
  
• "Security in a Web services world" is a white paper published by IBM and Microsoft that describes some of the security challenges facing Web services developers.
  
  
• Take a look at the WS-Security specification.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Adding extensibility with SOAP
• Implementing SOAP-based intermediaries
• Potential real-world SOAP-based intermediary services
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.

---

• Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
• Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
• Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
• Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
• Buy: IBM WebSphere Portal Express

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers