Introduction

The SOAP processing model assumes that messages can be relayed among several intermediate SOAP nodes (the processing chain -- see Resources) while enroute from the initial sender to the ultimate receiver. The general idea is that, within an enterprise or value chain, intermediaries can handle common aspects of SOAP message processing, thereby leaving the initial sender and ultimate receiver to be concerned only with the behavior required for a particular application. Ongoing experience with Web services will help to illuminate a broad set of operations that are best left to intermediaries, but some commonly agreed upon operations today include message routing and message logging.

The WebSphere Web Services Gateway is a Web services infrastructure component that is packaged with the WebSphere Deployment Manager. It is a SOAP processing engine that is focused on the operation of the intermediaries in the SOAP chain. Typically, it does not act as an ultimate receiver or as an initial sender of SOAP messages; rather, it is a waypoint for SOAP messages with the capability to:

1. Alter the destination of a message (routing)
2. Handle custom header tag processing
3. Apply and remove message level security (WS-Security)
4. Perform protocol transformation, for example, submit incoming SOAP/HTTP messages to SOAP/JMS

This article is the first part in a series about the IBM WebSphere Web Services Gateway. It presents an example of how to perform the first two items in this list. Subsequent articles will cover the remaining items.

Back to top

The problem

The scenario depicted in Figure 1 shows several senders and receivers. In each case, the service provider is the same enterprise, but each message is to be handled by a service implementation that is specific to the subscription level of the sender.

Back to top

Candidate solutions

Conventional point-to-point

You can solve the problem depicted in Figure 1 by providing a membership level-specific endpoint to each of the senders. Doing so permits the sender to target the correct service implementation with his messages. This is a brittle solution and difficulties arise when the endpoint must be changed, either because a sender decides to change his service subscription level or the provider moves the Web service. Security issues aside, such a change requires that a different endpoint be given to the sender, and that he be required to alter his client to use the new endpoint.

Bind through a service broker

You can use some more elaborate means to support the binding. For example, requestors could use a common UDDI registry to find the service endpoint for a given service level. By doing so, the client is already assuming that the endpoint must be determined at runtime (late binding) and can include their subscription level in the criteria of the UDDI query.

A service broker approach, however, requires that each sender take some action to ensure that his requests are routed to the appropriate endpoint. It is unlikely that the service provider in such a scenario will want to trust the client to choose the correct endpoint for the service level he has purchased.

Service provider routing intermediary

A better solution to this problem, and the one presented in this article, involves the use of a routing intermediary at the service provider. With this approach, the intermediary examines each request as it arrives and routes it to the appropriate service level provider based on the sender's membership level.

This approach eliminates the need for the customer to change the endpoint he directs messages to, and it lets the provider control the service used based on the sender's subscription level.

It is reasonable that in this case the sender might still use a UDDI registry to bind to the intermediary's endpoint, thereby giving the service provider freedom to move the endpoint without impacting the sender; however, that is beyond the scope of this article.

Back to top

The WebSphere Web Services Gateway

A complete description of the WebSphere Web Services Gateway is available in the article "Introduction to Web Services Gateway" (see Resources).

Review the following important terms related to the WebSphere Web Services Gateway:

Gateway Service: The service endpoint that the Web Services Gateway presents to requestors.

Target Service: The service endpoint that the service provider presents to the Web Services Gateway.

Gateway Channel: A transport implementation for receiving inbound messages. Examples include: Apache SOAP, IBM WebSphere SOAP Engine, and SOAP over JMS.

Gateway architecture

The Web Services Gateway consists of the wsgw.ear enterprise application and one or more channel EAR files, each containing a channel implementation. Included with the gateway are channel implementations for Apache SOAP, the IBM WebSphere SOAP Engine (a JAX-RPC engine), and SOAP over JMS.

Intermediation architecture

Intermediation in the WebSphere Web Services Gateway is performed using JAX-RPC handlers. (Previous versions of the gateway provided intermediation support through the use of Web Services Invocation Framework (WSIF) filters. The use of WSIF Filters is deprecated as of WebSphere Application Server V5.02.) The simplest intermediation consists of a single JAX-RPC handler deployed on a single channel or Target service, performing a single SOAP role.

Intermediation can become arbitrarily complex because each channel deployment of a given service might include a distinct handler chain, the target service gateway configuration might have a handler chain, and both the requestor and provider might have their own handler chains, depending on their implementation (see Figure 3).

Care must be taken to avoid application architectures that rely on the intermediation framework for application-related behavior. Keep in mind that the purpose of intermediaries is to provide a means to isolate infrastructure-related concerns in non-application-specific artifacts.

Types of gateway service deployment

Deploying a service in the WebSphere Web Services Gateway does not alter a service in any way; it simply establishes a means of accessing the service indirectly through the WebSphere Web Services Gateway. There are two ways to deploy a service in the WebSphere Web Services Gateway: Proxy mode deployment and Non-proxy mode deployment.

Proxy mode deployment

A proxy mode deployment should be used when mediation is required to determine the target service for (route) each message received at the WebSphere Web Services Gateway service. It is important to note that proxy mode deployment is only supported for SOAP over HTTP service bindings. Such deployments require that a JAX-RPC handler be provided on the WebSphere Web Services Gateway service whose purpose is to determine the endpoint for each message received. The handler accomplishes this by setting the value of the transport.url property in the SOAPMessageContext of each message to the endpoint URL of the chosen target service. Typically, the handler examines important elements of each incoming message (headers, message type, and so on) and selects a target service endpoint accordingly.

         
  <message name="genericMessage">
    <part name="part" type="xs:anyType"/>
  </message>
  <portType name="ProxyPortType">
    <operation name="requestresponse">
      <input message="tns:genericMessage"/>
      <output message="tns:genericMessage"/>
    </operation>
    <operation name="oneway">
      <input message="tns:genericMessage"/>
    </operation>
  </portType>
         

Strictly speaking, it is not correct to refer to proxy mode services as deployments of existing services; there is no explicit reference to the ultimate receiver when a proxy mode service is set up. A proxy mode service can act as a router for several target services. Underscoring this generic routing behavior is the fact that the default PortType WSDL used to describe the target service to the gateway contains two generic operations, each of which employ a single un-typed message definition implying that they accept any message (see Listing 1).

         
  <binding name="ProxyPortTypeSOAPHTTPBinding" type="tns:ProxyPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="requestresponse">
      <soap:operation soapAction="" style="document"/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
    <operation name="oneway">
      <soap:operation soapAction="" style="document"/>
      <input>
        <soap:body use="literal"/>
      </input>
    </operation>
  </binding>
         

You can customize the default WSDL if necessary. Customization is necessary only if the HTTP binding description in the default WSDL template (see Listing 2) is not adequate to describe the binding for the service. You must restrict changes to the default WSDL to the customization of HTTP binding extension elements only (see Resources). For example, the target service may expect an HTTP GET message rather than a POST, in which case you would add <http:binding verb="GET" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" /> to the binding definition.

Since HTTP is the only supported transport for proxy mode services, you can't change the type of service binding. Also, you may not change the message and PortType elements.

Proxy mode service deployment is also a convenient way to apply a common set of handlers to the messages targeted at several different services. In such a situation, the messages are all sent to the same WebSphere Web Services Gateway proxy mode service, processed in a similar way, and then routed to the appropriate destination.

Non-proxy mode deployment

Non-proxy mode deployment results in the creation of a WebSphere Web Services Gateway service that forwards messages received to a specific target service. When the WebSphere Web Services Gateway is queried for a deployed service's WSDL in this manner, it responds with the target service's WSDL, with the exception that the service endpoint has been altered and points to the WebSphere Web Services Gateway service rather than the target service. This means that requestors never know the specifics of where the target service is located.

There are three important differences between proxy mode and non-proxy mode services:

1. The gateway does not observe changes made to the value of a request's transport.url property unless a service is deployed in proxy mode. Therefore, only proxy mode deployment supports request routing.
2. Proxy mode services do not emit WSDL when ?wsdl is appended to the endpoint for the proxy mode service. Non-proxy mode service deployments emit the WSDL of the target service with the binding and service elements altered to reflect the particulars of the gateway service.
3. Non-proxy mode service deployments have the option of specifying two distinct WS-Security configurations: one for the conversation between the requestor and the gateway and another for the conversation between the gateway and the target service. Proxy mode deployments may not specify a WS-Security configuration for the target service.

Back to top

Mapping the solution for the problem scenario onto the Web Services Gateway

The problem scenario described earlier involves message routing; therefore, a proxy mode deployment is required.

Back to top

Implementing the solution

A note about JAX-RPC handlers

For those familiar with the use of pipes in UNIX, JAX-RPC handlers and handler chains might look familiar. UNIX filters are combined using pipes to perform various operations on the information that flows through the pipe; they perform logging operations, data conversion operations, and so on, on the data stream that moves through them. Similarly, a JAX-RPC handler chain is an ordered collection of objects that implement the javax.xml.rpc.handler.Handler interface, each of which has a particular function that might or might not alter the information passed into the next handler in the chain.

One feature of handlers that is not present with pipes is the ability to target message headers at particular handlers through the use of SOAP roles and header tags. This feature is used in this scenario to indicate that the ServiceToken header is intended to be processed by the routing handler. By doing so, the door is left open for the inclusion of ServiceToken headers that might be intended for some other purpose.

Routing criteria

For the example application, a simple technique involving the use of a membership token in the message header is used to provide routing criteria. The routing handler extracts the token and routes the message based on the membership level it represents. The following header format is used:

         
  <route:ServiceToken xmlns:route="http://test.com" actor=
  "MessageRouter" mustUnderstand="0">
    GoldService
  </route:ServiceToken>
         

This token is not sufficient to properly authorize ServiceLevel entitlement at the service provider. The provider could use digital signatures and secure service tokens (such as X509 certificates) that they have issued to validate the requestor's entitlements. While the token processing in such a case is more involved, the structure of the handlers is quite similar to what is being built in this article.

Handler development and packaging

When routing is based on some header characteristic such as explicit routing information that is carried in a routing header, the service requestor and proxy service implementations are coupled and must be kept up to date as the format of the routing header evolves.

When JAX-RPC clients are used in combination with Web Services Gateway proxy services, it is common to develop the client and service routing handlers simultaneously, thereby ensuring that the header that the client handler embeds is consistent with the expectations of the routing handler in the gateway. The handlers developed here are included in the same utility JAR file for this reason.

Handler behavior in the sample application

The major portion of the solution implementation for this article lies in the handlers that must be used to:

1. Embed a membership token in the service request at the requestor, and
2. Extract the token and route the request when it arrives at the Web Services Gateway.

Two handlers are needed, one for each of the steps listed above.

A client-side JAX-RPC handler to embed the service token

To make this handler generally useful it’s a good idea to avoid hard-coded information that would best be left in the deployment configuration. Table 1 shows information that is assumed to be present in the configuration in this case.

Table 1. Client routing handler configuration values

The JSR-109 specification provides a means to parameterize JAX-RPC handlers in the Web service deployment descriptor for a Web service client or service. Such parameters are made available to the handler instance through the javax.xml.rpc.handler.HandlerInfo instance passed to the handler init(HandlerInfo info) method when the handler is initialized. It is important, therefore, to maintain a reference to the HandlerInfo instance for the handler to use later (see Listing 3).

A general means of dealing with configuration errors is used in the getConfigParm() method to simplify error handling elsewhere in the handler. SOAPFaultException is a subclass of java.lang.RuntimeException, so it is not necessary to declare it in a throws clause.

         private HandlerInfo handlerInfo;
         
         // handler lifecycle method for instance initialization
         public void init(HandlerInfo handlerInfo){
         	setHandlerInfo(handlerInfo);
         }
         private HandlerInfo getHandlerInfo(){
         	return handlerInfo;
         }
         private void setHandlerInfo(HandlerInfo info){
         	handlerInfo = info;
         }
         /** Retrieve the value of a Handler initialization parameter. All parameters are
             considered required. */
         private String getConfigParm(String key) {
         	String result = (String)getHandlerInfo().getHandlerConfig().get(key);
         	if (result == null){
                emitConfigurationMessage(); // put a configuration description in the log
         	throw new SOAPFaultException(new QName("Client"), 
         		"Client routing handler configuration error: " + key, "", null);
         	}
         	return result;
         }
         

This example is only interested in altering the message on the way out of the client. For client-side handlers in JAX-RPC, the method invoked for outgoing requests is the handleRequest(MessageContext mc) method. For this example, the operations that must be performed in the handleRequest method are:

1. Create a message header to contain the requested service level.
2. Insert the new header into the outbound SOAP message.
3. Insert the service level into the new header.

         public boolean handleRequest(MessageContext mc) {
         	SOAPMessageContext smc = (SOAPMessageContext) mc;
         	SOAPEnvelope envelope = smc.getMessage().getSOAPPart().getEnvelope();
         	SOAPHeader header = envelope.getHeader();
         	if (header == null) {
         		header = envelope.addHeader();
         	}
         	SOAPHeaderElement newHeaderElement =
         		header.addHeaderElement(
         			envelope.createName(
         				getConfigParm(HEADER_PARM_NAME),
         				HEADER_PREFIX,
         				getConfigParm(HEADERNS_PARM_NAME)));

         	// place the servicelevel data into the header and set the actor
         	newHeaderElement.setActor(getConfigParm(ACTOR_PARM_NAME));
         	newHeaderElement.addTextNode(getConfigParm(SERVICELEVEL_PARM_NAME));
         	// header processing was successful
         	return true;
         }
         

Note: The necessary exception handling logic has been excluded for clarity in most of the code examples in this article.

A JAX-RPC handler to perform message routing based on the requested service level

The service routing handler will be written to do the following:

1. Locate the routing header in the message.
2. Extract the requested ServiceLevel from the header.
3. Map the ServiceLevel to an endpoint for the message.
4. Set the value of the transport.url property in the SOAPMessageContext to the URL of the endpoint.
5. Remove the routing header from the SOAP Envelope (the SOAP specification requires that processed headers be removed before messages are passed on).

Again, to make this handler generally useful, hard-coded configuration information is avoided. Table 2 shows the configuration parameters for this handler.

Table 2. Client routing handler configuration values

	public boolean handleRequest(MessageContext mc) {
		boolean result = true;
		SOAPMessageContext smc = (SOAPMessageContext) mc;
		try {
			SOAPHeaderElement serviceTokenHeaderElement =
				getServiceTokenHeaderElement(smc);
			// is a service token present?
			if (serviceTokenHeaderElement != null) {
				// map the service level to a service endpoint
				String endpoint =
					mapServiceLevelToEndpoint(
					serviceTokenHeaderElement.getValue());
				// set the endpoint of the message
				smc.setProperty("transport.url", endpoint);
				// remove the processed header
				serviceTokenHeaderElement.detachNode();
			}
			else
				emitRoutingException();
		}
		catch (EndpointMappingException e) {
			e.printStackTrace();
			emitRoutingException();
		}
			catch (HandlerConfigurationException e) {
			e.printStackTrace();
			throw e;
		}
		catch (Exception e) {
			e.printStackTrace();
			throw new SOAPFaultException(new QName("Server"),
				"Server processing failure","",null);
			}
		return result;
	}

Listing 5 shows the handleRequest() method for this handler. The following are some important things to observe about this method:

• It does not assume that there is a routing header in the message.
• If the routing header is not present it emits a SOAPFaultException (through the emitRoutingException() method) to initiate fault processing (Ignoring the absence of the header would result in a routeless message. In such a case, the gateway Proxy service would assume the role of the ultimate receiver and return an empty result (not a fault) to the sender. In most cases, the sender would not be expecting an empty result).
• The namespace and tag name for the header must match what the client side handler inserts, otherwise the header won’t be recognized.
• The routing header is removed once it has been processed.

The purpose of this handler is to route SOAP messages. The approach taken in this example is very simple: find the service level requested in a properties file and use the related property value as the message endpoint.

Here is the code used to map service levels:

	private ResourceBundle endpointMap = null; // references the endpoint properties

	/** recover the endpoint for a given service level */
	private String mapServiceLevelToEndpoint (String serviceLevel) {
		return (String)getEndpointMap().getObject(serviceLevel);
	}

	private synchronized ResourceBundle getEndpointMap(){
		if (endpointMap == null) {
			InputStream is = 
			getClass().getResourceAsStream(getRoutingTablePath());
			setEndpointMap(new PropertyResourceBundle(is));
		}
		return endpointMap;
	}

	private synchronized void setEndpointMap(ResourceBundle bundle) {
		endpointMap = bundle;
	}

The mapping technique used is quite simple and doesn’t scale well. A more scalable solution would likely use a database or other distributed resource to hold the mapping information. This completes the coding that is required for this routing scenario.

Back to top

Deploying the scenario

Table 3. The sample code provided

Software required to test this example

To test this example, you need to have the following software installed. Download links for trial versions of this software are available in the Resources section of this article:

Deploy the EchoService to Application Server

The EchoService Web application is contained in the EchoServiceEAR.ear file. Install this EAR file in the Application Server instance you are using; it has no special configuration requirements. The endpoint for the EchoService Web service is as follows:

http://<hostname>:<port>/EchoServiceWeb/services/EchoService

<hostname> is the name of the host running the application server and <port> is the port number of the HTTP listener for the application server instance on which the service is installed.

To confirm that the application is installed properly, enter the following URL in a Web browser:

http://<hostname>:<port>/EchoServiceWeb/services/EchoService?wsdl

A successfully installed service will respond with its WSDL.

Configure the Web services client deployment descriptor in Application Developer

A client application has been provided in the ServiceClientEAR.ear file. It contains the following:

Import the EAR into Application Developer; do not create a utility project for the WSGWRoutingHandlers JAR file.

Open the Project Navigator view in the J2EE perspective and expand the ServiceClient project as shown in Figure 5. Open the webservicesclient.xml file in the Web services client editor and select the Handlers tab (see Figure 6).

Add a handler to the client configuration. The client handler class for this example is called com.ibm.wsgw.routing.ServiceRoutingClientHandler. Click the Add button and select this class from the list provided. Configure the initial parameters for this handler as follows:

When you are done the handler configuration should look like the one in Figure 7. Save the changes and close the editor.

At this point the client is configured to provide the proper header information to the proxy service. Now it’s time to setup the gateway proxy service.

Set up the proxy mode service in the Web Services Gateway

The administration of the Web Services Gateway is performed using the Gateway Admin Web application. Assuming that the Application Server instance is running the HTTP listener on port 9080 (the default), the admin application can be accessed through the URL: http://<hostname>:9080/wsgw/admin/index.html, where you are presented with the page shown in Figure 8.

Select the Services:Deploy link in the left-hand menu and fill in the following information:

Since this is a proxy mode service, there is no requirement to provide information about the target service. It is assumed that a handler will be added to the service with the responsibility to set the target endpoint on a per message basis. So, with this information entered, you have provided all the necessary deployment information and your deployment configuration should resemble the one shown in Figure 9. Complete the deployment step by clicking the Ok button at the bottom of the form. You should see a message box reminding you that you are required to deploy a JAX-RPC handler whose job is to set the transport.url property for each message to this service.

The remaining steps take care of deploying and configuring the routing handler, a task which breaks down as follows:

1. Install the handler class and dependencies in the application server hosting the gateway.
2. Deploy the handler class in the gateway.
3. Add the handler to the proxy mode service handler chain.

Install the handler class and dependencies in the Gateway Application Server

Before the routing handler can be associated with the proxy mode service, the handler class and its dependencies must be visible to the gateway and channel class loaders. The deployment options available are dependent upon the classloader mode of the application server.

If the application server instance running the gateway is configured in Single classloader mode, the handler class can be in any EAR installed in the application server. If the application server is configured in Multiple classloader mode (the default), the handler must be placed in one of the following locations:

1. Use a JAR file placed in <WAS_install>/lib or <WAS_install>/lib/ext directories, where <WAS_install> refers to the directory where Application Server is installed,
2. Deploy the handler classes to the <WAS_install>/classes directory,
3. Use a JAR file placed in a WebSphere shared library associated with the channel and gateway enterprise applications.

I use the first approach for this example. Place the WSGWRoutingHandlers.jar file into the <WAS_install>/lib/ext directory.

Deploy the handler in the gateway

Select the Deploy link under the Handlers heading of the Gateway Admin Web application. You will be prompted for the details of the handler you wish to deploy (Note: When deploying a handler in the gateway, the handler deployment carries the parameters that will be used each time that handler occurs in a handler chain. If several instances of the same handler class are required, each with different configuration parameters, the handler class may be deployed several times with different names). The parameters to use for this example are as follows:

When you have entered this information, your deployment screen should resemble the one shown in Figure 10. Click the Ok button to complete the deployment and proceed to the next step.

Add the handler to the proxy mode service handler chain

Now that the handler is deployed to the gateway, it is available to be added to the handler chains of any deployed gateway services. Select the List link under the Services sub-menu of the Gateway Admin application; you should see EchoProxyService in the list of available services. Click the EchoProxyService link and scroll down to locate the Channels list for the service (see Figure 11). Select Edit JAX-RPC handler configuration for the SOAPHTTPChannel1 channel.

Find the ServiceRoutingHandler in the Add JAX-RPC Handler list and add it to the handler configuration. At this point the configuration page should appear similar to Figure 12.

Completing the configuration

The routing handler uses a properties file to map service level values to target service endpoints. In the configuration instructions provided above, the RoutingConfig property was assigned the value /routing.properties. With this configuration, place a properties file called routing.properties in the <WAS_install>/properties directory containing information similar to that shown in Listing 7.

   #sample Service Level routing table
   SilverService=http://localhost:9082/EchoServiceWeb/services/EchoService
   GoldService=http://localhost:9083/EchoServiceWeb/services/EchoService

In this case, the two entries cause requests to SilverService and GoldService service levels to be mapped to ports 9082 and 9083 on the server hosting the gateway instance. You should make sure that the URLs are adjusted to reflect the particulars of the service(s) you have deployed.

Testing the gateway proxy service

Once the properties file is created and the foregoing configuration is completed, you can test the service using the ServiceClient project you imported into Application Developer earlier in this article.

The main client class is called test.EchoServiceClient. As provided, this class targets its request at the following endpoint:

http://localhost:9081/wsgwsoaphttp1/soaphttpengine/urn%3Aibmwsgw%23EchoProxyService

This URL assumes that the client is running on the same machine as the server and that the application server HTTP listener is listening on port 9081. If your application server HTTP listener is running on a different port or machine, edit this URL to point to the appropriate location.

Once the URL points to your gateway instance, select the application client class in the Project Navigator of the WebSphere Studio J2EE Perspective (see Figure 13) and select the Run > Run As > WebSphere v5.1 Application Client menu item. This will launch the client and send a request to your proxy service which resembles the following:

    
<?xml version="1.0" encoding="UTF-8"?>

   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
     xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
     xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  

   <soapenv:Header><hns:
   ServiceToken soapenv:actor="MessageRouter" 
     xmlns:hns="http://test.com" 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

      GoldService

   </hns:ServiceToken>

   </soapenv:Header>

   <soapenv:Body>

      <echo xmlns="http://simpleservices.com">

         <echoThis>Hello World</echoThis>

      </echo>

   </soapenv:Body>

</soapenv:Envelope>
    

    
<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

   <soapenv:Body>

      <echoResponse xmlns="http://simpleservices.com">

         <echoReturn>Echo Message received: Hello World</echoReturn>

      </echoResponse>

   </soapenv:Body>

</soapenv:Envelope>
    

Back to top

Summary

This article provided a detailed explanation of how to build and deploy a Web services routing application in the IBM Web Services Gateway. The mapping mechanism employed was quite simple and is not recommended as an industrial strength approach for mapping service level requests to service implementations, as it provides no support for centralized maintenance of the mapping table, and the tokens used are easily spoofed by clients wishing to take advantage of service levels beyond their entitlements.

However, combining the techniques presented here with tokens that are more difficult to forge, such as digital certificates, and with a distributed resource such as an RDBMS to hold mapping information turns the simple mapping example presented here into a much more robust Web services routing solution.

Back to top

Get the tools used in this article

If you are a developerWorks subscriber, you have a single user license to use WebSphere Studio Application Developer, and other DB2®, Lotus®, Rational®, Tivoli®, and WebSphere products -- including the Eclipse-based WebSphere Studio IDE -- to develop, test, evaluate, and demonstrate your applications. If you are not a subscriber, you can subscribe today.

Back to top

Download

Information about download methods

Resources

• You can download the source code used in this article by clicking on the code icon at the top or bottom of this article.
  
  
• Learn more about how intermediate SOAP nodes fit into the SOAP processing model.
  
  
• Get more information on HTTP binding extension elements.
  
  
• Find the installation instructions for WebSphere Application Server V5.1 and for WebSphere Web Services Gateway.
  
  
• Read the following articles for more information on the IBM WebSphere Web Services Gateway:
  • "Employ the IBM WebSphere Web Services Gateway, Part 2" (developerWorks, December 2004)
  • "Introduction to the Web Services Gateway" (developerWorks, May 2002)
  • "Exploring the new Features of the WebSphere Web Services Gateway" (developerWorks, March 2004)
  • Samples for the Web Services Gateway
  • Installing the Web Services Gateway in WebSphere Application Server version 5.0x
  • Installing the Web Services Gateway in WebSphere Application Server version 5.1x
  
  
  
• Examine how JAX-RPC SOAP handlers process SOAP message headers in the article "Process SOAP 1.1 headers with JAX-RPC 1.0 SOAP handlers" (developerWorks, April 2004).
  
  
• Download IBM WebSphere free trial products and fixpacks:
  • Trial download of WebSphere Application Server V5.1
  • WebSphere Application Server V5.1 Fix Pack 1
  • Trial download of WebSphere Studio Application Developer
  
  
  
• Find the following Web Services Specifications on developerWorks:
  • JAX-RPC Specification, version 1.1
  • SOAP specification, version 1.1
  
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• The problem
• Candidate solutions
• The WebSphere Web Services Gateway
• Mapping the solution for the problem scenario onto the Web Services Gateway
• Implementing the solution
• Deploying the scenario
• Summary
• Get the products
• Download
• Resources
• About the author
• Comments

Next steps from IBM

WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
• Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
• Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
• Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers