IBM WebSphere Developer Technical Journal: Exploring the new features of the WebSphere Web Services Gateway

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

Greg Flurry (flurry@us.ibm.com), Senior Technical Staff Member, IBM Enterprise Integration Solutions

17 Mar 2004

The WebSphere Web Services Gateway is a feature in WebSphere Application Server Network Deployment Version 5 that lets you make your internal Web services available externally, and external Web services available to your internal systems. This article discusses the new gateway features available in Version 5.1 that support improved performance, standard mechanisms for mediation of Web services messages, and improved flexibility.

Introduction

The WebSphere® Web Services Gateway allows an enterprise to safely expose internal business processes as Web services to external users, or to safely use external Web services from internal business processes. The latest release of the gateway, available in WebSphere Application Server Network Deployment Version 5.1, adds new features that support improved performance, standard mechanisms for mediation of Web services messages, and improved flexibility.

This article describes these new features, discusses their impact on gateway users, and the administration required to engage these features.

Back to top

Web Services Gateway overview

The gateway is used primarily as an intermediary between a Web service requestor and a Web service provider. To make any service provider available to service requestors, a gateway administrator creates a gateway service. When configuring a gateway service, an administrator must identify one or more service providers, called target services. All target services associated with a gateway service must be described by a Web Services Description Language (WSDL) document with identical WSDL portTypes. A gateway service thus logically represents a real service provider of a specific portType..

Administrators can expose gateway services on one or more gateway channels, each representing a particular data format and protocol used to access the gateway service; for example, SOAP/HTTP. The gateway can provide WSDL for configured gateway services and, if so configured, can publish the WSDL for gateway services into one or more UDDI registries. Finally, the administrator can define gateway filters that act as mediators, meaning they can manipulate requests and responses, and route among the target services configured for a gateway service.

The main function and some of the internal structure of the gateway are shown in Figure 1. (See Resources for additional detail.)

Here is a high level overiew of basic gateway operation:

• The service requestor uses the WSDL for the gateway service to determine how to send a request to a gateway service on a particular channel.
• The channel sends the request to the gateway core.
• The gateway core runs the set of filters configured to process the gateway service request, one of which may route the request to a specific target service.
• The gateway core calls the Web Services Invocation Framework (WSIF) to send the request to the selected target service using the appropriate data format and protocol (determined by the WSDL document describing the target service).
• The target service returns a response.
• The WSIF returns the response to the gateway core.
• The gateway core runs the set of filters configured to process the gateway service request.
• The gateway core returns the response to the channel.
• The channel returns the response to the requestor using the data format and protocol for that channel.

The basic internal gateway components, mentioned above, are:

• Channel
  The channel defines a protocol/format you can use to access the gateway services. A gateway administrator can configure one or more channels into the gateway, and a gateway service can be exposed on one or more channels. Internally, a channel contains a Web services engine responsible for receiving inbound Web service requests directed to a WSDL portType, represented by that gateway service in that protocol/format, and then calling the channel-specific channel provider. The channel provider generally translates the request into an internal canonical data representation and then sends the request to the gateway core.
• Gateway core
  The gateway core is responsible for running the filters associated with a gateway service and for calling a service provider to respond to the request. Custom logic for filters is provided by users. Filters allow a request to be logged, or manipulated in some manner. In addition, a filter can route requests to one of potentially many different target services implementing the WSDL portType exposed by the gateway service. After filtering the request, the gateway core uses WSIF to communicate with the selected target service using the appropriate protocol/format.
• WSIF
  Internally, WSIF contains one or more protocol/format-specific WSIF providers used to access target services in that particular protocol/format. Some WSIF providers, like the SOAP/HTTP provider, use an outbound Web services engine to communicate with service providers.

The response from the service provider flows along the exact same path back to the original requestor. The set of filters that processes the response can be different than those that process the request.

Considering this description of gateway internals, a more comprehensive description of gateway operation follows (the SOAP/HTTP Web services engine specifically is described in both the channel and WSIF):

• The service requestor sends a request to a gateway service.
• The inbound engine in the SOAP/HTTP channel of the gateway parses the entire request.
• The engine calls the channel provider with the parsed request.
• The channel provider transforms the request to an internal data format.
• The channel provider calls the gateway core, sending the internal form of the request for further processing.
• The gateway core runs any request filters configured for the gateway service (filters operate on the internal data format).
• The gateway core calls the WSIF provider which transforms the internal form to a form applicable to the outbound Web services engine; in this case, SOAP.
• The engine serializes the original request for use in the request message sent to the target service.
• The client engine receives and parses the response.
• The client engine gives the parsed response to the WSIF provider, which transforms the response to the internal form.
• The WSIF provider returns the response to the gateway core, which runs the response filters configured for the gateway service.
• The gateway core returns the response to the channel provider.
• The channel provider transforms the response to a form applicable to the inbound Web services engine, in this case SOAP.
• The channel provider returns the response to the engine.
• The engine serializes the response and uses it in the response message returned to the original requestor.

Back to top

Enhancements in Version 5.1

The fundamental purpose and capabilities of the Web Services Gateway in Version 5.1 have not changed. Version 5.1 enhancements add to its capabilities, broaden its applicability, and fall into three broad categories: performance, mediation, and flexibility.

Performance

There are two forms of performance enhancements. The gateway core is implemented as an EJB. A channel provider must normally use a remote protocol to call the core. The first enhancement enables a channel provider to access the gateway core using local EJB mechanisms rather than the standard remote access mechanisms. This is represented in Figure 2 (notice the line rather than the arrow between the channel provider and the gateway core). Local EJB access avoids the overhead of the Java™ serialization of parameters and return values as well as that of remote communication.

There is a caveat associated with the use of local EJBs in the gateway. The instance of WebSphere Application Server in which the gateway runs must be configured to run in "single class loader" mode, eliminating the class-loader isolation between applications running in that instance of WebSphere, a sometimes undesirable characteristic. The gateway automatically uses local EJB mechanisms when WebSphere is so configured. There is no fundamental difference in the functional characteristics of the gateway when using local EJB access, just a performance improvement.

The second enhancement allows the gateway to leverage the selective parsing capability built into the WebSphere Application Server V5.1 J2EE-compliant Web services engine. Selective parsing means that the body of a SOAP message is not parsed unless necessary. Selective parsing is currently available only in the SOAP channels. With selective parsing engaged, a request is processed by the gateway as follows (again, the SOAP/HTTP engines are described):

• The service requestor sends a request to a gateway service.
• The inbound engine in the channel does not parse the body of the request, but does parse the headers.
• The engine calls the channel provider with the request with the unparsed body.
• The channel provider transforms any request headers to an internal data format, but does nothing with the unparsed body.
• The channel provider calls the gateway core, sending the internal form of the request headers and the unparsed body for further processing.
• The gateway core runs any request filters configured for the gateway service; as long as the filters do not attempt to process the request body, it remains unparsed.
• The gateway core calls the WSIF provider,which transforms the internal form to a form applicable to the outbound Web services engine; this applies only to the header; the unparsed body is left untouched.
• The engine inserts the unparsed request in the request message sent to the target service.
• The client engine receives but does not parse the response body.
• The client engine gives the response, with the unparsed body, to the WSIF provider, which transforms only the response headers to the internal form.
• The WSIF provider returns the response to the gateway core, which runs the response filters configured for the gateway service; again, if the filters do not process the body, it is left unparsed.
• The gateway core returns the response with the unparsed body to the channel provider.
• The channel provider transforms the response headers to a form applicable to the inbound Web services engine.
• The channel provider returns the response, including the unparsed body, to the engine.
• The engine serializes the response headers and inserts the unparsed body in the response message returned to the original requestor.

You can see that the use of selective parsing can dramatically reduce the amount of processing associated with a request and the corresponding response. The benefit increases as the size and complexity of the request or response messages increase.

There is a caveat associated with selective parsing. If any component associated with the gateway, such as a filter, attempts to use the body, it is automatically parsed, losing the performance benefit. In addition, parsing may require additional class files, used when mapping from XML types to Java classes, that are not available to the Web services engine (see Resources for details); therefore, parsing can cause exceptions that terminate message processing. Given this behavior, it is very important that a message body not be processed when selective parsing is engaged.

One should also understand that selective parsing cannot be used unless local EJB mechanisms are enabled. As mentioned above, this implies that the WebSphere Application Server in which the gateway is running be configured in single class loader mode.

Mediation

Version 5.1 of the gateway adds the ability to configure J2EE Web services (JAX-RPC) compliant handlers associated with gateway services or target services, when supported in the channel or WSIF provider; e.g. by the inbound and outbound Web services engines supporting SOAP. (J2EE Web services are defined by JSR-101 & JSR-109 specifications. JAX-RPC handlers can only be used within a SOAP channel or outbound SOAP invocation as they only apply to SOAP messages.)

Figure 3 shows the architecture of handlers with respect to the gateway.

Handlers can process Web services requests and responses, adding, deleting, or modifying SOAP headers, and even modifying the body, within the limits outlined by JSR-109. Thus, handlers offer the ability to perform many of the same functions that filters can perform. However, handler programming interfaces are standards compliant (but limited to processing SOAP messages), while filter programming interfaces are proprietary to the gateway (but can process all types of messages in the gateway).

The gateway supports inbound handlers that run in the inbound Web services engine in a channel for each gateway service/channel combination, and outbound handlers that run in the outbound Web services engine in the WSIF provider per port for each target service. Multiple inbound and outbound handlers can be configured. Multiple handlers can be ordered in what is commonly called a handler chain.

When inbound handlers are configured for a gateway service, and outbound handlers are configured for a target service, the gateway processes requests as follows (again, the SOAP/HTTP engines are described):

• The service requestor sends a request to a gateway service.
• The inbound engine in the SOAP/HTTP channel of the gateway parses the entire request.
• The engine calls the inbound handlers configured into the handler chain for the gateway service in sequence, calling the handleRequest method on each handler.
• The engine calls the channel provider with the parsed request.
• The sequence, as described above for the parsed case, continues and, eventually, the outbound engine calls the outbound handlers configured into the handler chain for the target service's port in order, calling the handleRequest method on each handler.
• The engine serializes the original request for use in the request message sent to the target service.
• The engine receives and parses the response.
• The engine calls the outbound handlers configured into the handler chain for the target service's port in reverse order, calling the handleResponse method on each handler.
• The sequence continues, and eventually, the inbound engine calls the inbound handlers configured into the handler chain for the channel and gateway service in reverse order, calling the handleResponse method on each handler.
• The engine serializes the response and uses it in the response message returned to the original requestor.

The above scenario assumes full parsing of the request. The configuration and run time processing of the handler is independent of selective parsing and local EJB access. It is important to note, however, that if selective parsing is enabled, a request or response body will be parsed if a handler processes the body, and so handlers are subject to the same restriction as filters when selective parsing is engaged.

Flexibility

The configuration of handlers in the gateway is modelled after that defined for J2EE, in that handler chains must be configured per service/port. This enables the utmost configurability and customization capability, but also places a greater burden on administrators for some interesting intermediary uses, such as a proxy. The final enhancement adds flexibility to the gateway to enable that type of intermediary, including a more efficient configuration.

The gateway supports a so-called "proxy service" mode for a gateway service. The mode implements a gateway service that is "WSDL portType agnostic," meaning that it can accept requests and return responses for any portType. Equally important, the proxy configuration means that it is possible to configure a single handler chain and have it run by the gateway for requests directed at service providers with many different portTypes. Further, that means it is not necessary to configure target services for the proxy gateway service; the gateway has a built-in default WSDL document with a portType definition that enables the portType-agnostic behavior.

The proxy service mode is primarily useful in situations where the same handler chain is used for a large number of target services of different portTypes. The handler chain might include functions such as security, logging, and so on. Proxy mode greatly reduces the amount of configuration necessary in this situation. Proxy mode is also useful for situations where the set of needed target service portTypes is unknown; since the proxy mode service is portType agnostic, it is unnecessary to configure new target services and gateway services into the gateway when adding new target services.

There are several dependencies associated with proxy service mode. First, selective parsing must be enabled; this eliminates the need for defining (internal to the gateway) a potentially large number of custom serializers and deserializers. Second, the WebSphere Application Server hosting the gateway must be configured to run with a single class loader, since selective parsing requires it. Finally, since there are no real target services defined for the proxy service, the gateway cannot automatically choose a target service, and a filter cannot use the normal routing mechanism to select a target service. Thus, the gateway requires at least one handler, or one filter, configured for the proxy service that can determine the real target service endpoint address and tell the gateway. This is done by setting the target service's endpoint address URI in the request message context as the value of the transport.url property. To aid this function, the gateway places a property named inbound.url in the request message context that contains the full URI used by a service requestor to invoke the proxy service. A handler or filter can use the information in the URI (for example, HTTP parameters) to determine the actual target service invoked by the gateway to respond to a request. The WSIF provider uses the value of transport.url to configure the outbound Web services engine to send the outgoing message to the right service provider.

Some possible selection mechanisms for determining the value of transport.url:

• Include the actual service provider URL as an HTTP parameter on the request URL so that the handler or filter simply extracts the URL from the inbound.url property and puts that URL in the transport.url property.
• Include something that identifies the WSDL portType of the target service as an HTTP parameter on the request URL; the handler must identify one or more service providers that implement that portType (possibly by performing a lookup against a UDDI registry) and choose one of them to process the request, and place the endpoint address URL for that service provider in the transport.url property.
• Include in a header(s) information that allows the handler to identify the endpoint address URL and put that URL in the transport.url property.

When proxy mode is configured for a gateway service, the gateway operation is as follows (again, the SOAP/HTTP engines specifically are described):

• The service requestor sends a request to the proxy service.
• The inbound engine in the channel the does not parse the body of the request, but does parse the headers.
• The engine calls the handlers configured into the handler chain for the gateway service in order, calling the handleRequest method on each handler. A handler on the chain must set the transport.url property value in the SOAP message context, possibly using information derived from inbound.url, or from other sources, such as the SOAP header (it is also possible for a filter to examine or set the properties; this is beyond the scope of this article).
• The engine calls the channel provider with the request, with the unparsed body.
• The sequence described above for the unparsed body continues, then the WSIF provider sets the endpoint address for the target service from the value of the transport.url property in the context and calls the outbound engine.
• The outbound engine calls the handlers configured into the handler chain for the target service in order, calling the handleRequest method on each handler.
• The engine uses the unparsed request in the request message sent to the target service.
• The client engine receives the request, but does not parse the response body.
• The engine calls the handlers configured into the handler chain for the target service in reverse order, calling the handleResponse method on each handler.
• The sequence described above for the unparsed body continues so that the response is returned to the requestor.

The following code shows an example of a handler that performs routing. Assume that a gateway service named ProxyService is deployed in a channel named wsgwsoaphttp1. Further assume that the mechanism to do routing is a simple HTTP parameter that is used by the routing handler. The URL used to access the proxy service is something like the following (note that the URL can be found by examining the WSDL for the proxy service):

http://localhost:9080/wsgwsoaphttp1/soaphttpengine/urn:ibmwsgw#ProxyService?3

This is set as the value of the inbound.url property that the handler can examine.

public class RoutingHandler extends GenericHandler {
  
    private static final String targets = {
        "http://server:9080/Test/Service1",
        "http://server:9080/Test/Service2",
        "http://server:9080/Test/Service3",
        "http://server:9080/Test/Service4" }

    public boolean handleRequest(MessageContext msgContext) {
       String inURL = (String) msgContext.getProperty("inbound.url");
       int q = inURL.indexOf("?");
       int id = Integer.parseInt(inURL.substring(q+1));
       String targetUrl = targets[id];
       msgContext.setProperty("transport.url", targetUrl);
       return true;
    }
}

This very simple example implements a static routing mechanism. The handleRequest method first extracts the value of the inbound.url property. It then finds the HTTP parameter, which in this case is the simple value 3. The handler then looks up the actual address in a static table and sets the transport.url property. It is, of course, possible to devise much more sophisticated routing mechanisms that might require multiple HTTP parameters to identify portType or even to look up potential portType implementers in a UDDI registry.

Back to top

Administration of gateway enhancements

We will now examine gateway administration scenarios for these enhancments. Of course, you must first install WebSphere Application Server Network Deployment Version 5.1. Installation of the gateway is optional, however, so you must explicitly choose to install it. After WebSphere Application Server has been installed with the gateway, start the application server. You can then start the Gateway Admin Tool by entering http://localhost:9080/wsgw/admin/index.html into a browser (replace localhost with the hostname for the computer on which the gateway is installed if it is different than the one on which you are running the browser). You will see the welcome page of the admin tool, as shown in Figure 4.

The gateway main menu displays on the left. The only addition for the enhancements in the main menu is the Handlers area. Support for locals EJBs requires no additional gateway administration, and support for the other enhancements appears as part of the Services/Deploy pages.

Back to top

Administering JAX-RPC handlers

As with other components within gateway administration, you can:

• Deploy handlers into a gateway configuration. You can then use the handlers in gateway or target service handler chains.
• Remove handlers from the configuration (and handler chains in which they might be configured).
• List the handlers currently in the configuration; from the list of handlers you can modify the configuration of a specific handler.

Deploying a JAX-RPC handler

To deploy a handler in the gateway, select Handlers/Deploy from the main menu. You will see the Deploy JAX-RPC Handler page, shown in Figure 5.

The first two fields in the handler configuration, the Handler Name and Handler Class, are required. Handler Name can be anything that does not contain spaces, but generally should be something meaningful to the administrator, perhaps a succinct description of the handler function. The Handler Class is the fully qualified name of the Java class for the handler implementation. The class must be visible to the gateway and channel class loaders. If the application server 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 the default Multiple Classloader mode, however, a JAR file containing the handler must be placed in either <WAS_install>/lib or <WAS_install>/lib/ext directories, where <WAS_install> refers to the directory where WebSphere Application Server is installed, or the JAR file containing the handler must be in a WebSphere shared library associated with the channel and gateway applications. See Figure 6 for an example.

The rest of the information on the page is optional, and is the handler configuration information defined by JSR-109 (see Resources for more about the use of the configuration information in handlers). The Init Parameter name/value pairs allow more or less free form information to be passed to a handler instance; both the name and value are given to the handler as a java.lang.String. As you can see in Figures 5 and 6, you can describe up to three initialization parameters in the deploy handler page. You can add others later, as decribed below.

The SOAP header QName identifies, by namespace qualifed name, the SOAP headers in a SOAP message that the handler is supposed to process (either produce or consume). This field requires a very specific form to identify headers. Generically, the form is {namespace_URI}local_name, where namespace_URI is the namespace URI of the namespace qualified name and local_name is the local name of the namespace qualified name. .

The SOAP role identifies the SOAP roles in a SOAP message that a handler is supposed to fulfill (see the Resources for the SOAP specification which provides more detail). This field is generally in the form of a URI.

See Figure 6 for examples of these fields. You can add others later, as decribed below.

Once you have filled in the required fields and all desired optional fields, select OK to deploy the handler. The gateway confirms the handler depolyment by echoing the configuration, and offers you the ability to add to the configuration. See Figure 7.

In general, as you can see in Figure 7, to add a new part to the configuration you can type in the appropriate field and select add next to the field. To delete a part of the configuration, simply select remove next to the field to be deleted. Once you have finished adding and deleting parts of the configuration, select Apply Changes to actually modifiy the handler configuration in the gateway.

In many cases, you may want to reuse the same handler implementation (the same handler class) with the behavior of the handler modified by its configuration. To do so in the gateway, you must deploy a different handler instance for each different configuration. Specifically, you deploy the same handler class using different names and different configuration parameters. For example, you might wish to deploy the com.ibm.wsgw.test.LogHandler class with two different log.where parameter values; you could do so using two handler deploy operations, with the names LogHandler1 and LogHandler2 with the different values for log.where.

Modifying a JAX-RPC handler configuration

If you wish to modify the configuration of a handler after you have finished deploying it and, perhaps, performed other gateway administration operations, you should first select Handlers/List from the main menu. You will see a list of deployed handlers, similar to Figure 8. Click on the handler whose configuration you wish to modify and you will see a description of the current handler configuration, and then be given the opportunity to modify the configuration, similar to that described above in Figure 7.

Until you have included a handler in a gateway service's channel handler chain or target service's port handler chain (see below), you can modify the handler configuration as described above, and have the changes take affect immediately. After you have included a handler in a handler chain, however, you must restart the application aerver instance in which the gateway is running to make the configuration changes take effect.

One caution regarding the handler configuration. With Version 5.1 of the gateway, it is possible to backup and restore a configuration containing handlers (see the main menu in Figure 4). While you cannot deploy a handler if the handler class is not in the classpath (see above), it is possible to back up a configuration containing that handler and then restore a configuration in a new WebSphere Application Server instance, even if the handler class is not in the classpath. The gateway does not generate an error until run time; the Web services engine ignores the "bad" handler and runs the rest of the handler chain without warning. You will, however, find an indication that the handler class was not found in the Application Server's error log.

Removing a JAX-RPC handler

It is sometimes desirable to remove, or undeploy, a handler. To do so, click Handler/Remove on the main menu.You will see a list of deployed handlers, as shown in Figure 9. You will also see an indication of whether a handler is used in a handler chain.

To remove a handler from the configuration, simply check its corresponding checkbox and then click OK. The handler will be removed from all gateway service channel handler chains and all target service port handler chains in which it is configured and undeployed from the gateway configuration. Upon successful completion, the list of deployed handlers will be refreshed. Undeploying a handler takes effect immediately.

Back to top

Administering gateway services

Many of the new enhancements to the gateway are configured via the gateway service. We will first look at deploying a gateway proxy service, then add inbound handlers to the channel for a gateway service, and finally add outbound handlers for a target service's port.

Deploying a gateway proxy service

To deploy a gateway proxy service, click Services/Deploy from the main menu. You will see the gateway service deployment page, partially shown in Figure 10. The red and green boxes in the figure point out the new gateway service configuration options (these boxes do not appear on the actual dialog):.

• The red box shows the two options for enabling selective parsing, controlling what happens if a channel is associated with the gateway service that does not support selective parsing. With the first choice, the body gets parsed into the gateway's internal canonical form, and with the second choice, the body gets parsed into deployed Java classes. These two choices are identical to those available when selective parsing is not used. Forcing the gateway to parse a message body when selective parsing is enabled will generally result in exceptions that terminate processing.
• The choices in the green box allow one to turn on or off the proxy mode for the gateway service. By default, proxy mode is turned off, though in Figure 10 the option is turned on.

There are actually only three valid combinations of choices for these options. The following list shows the valid combinations and the corresponding gateway behavior:

1. Generic classes or Deployed Java classes paired with Do not act as a proxy service (this is the legacy configuration):
   • target service(s) required in configuration
   • gateway service is portType specific, as defined by the first configured target service
   • body always parsed.
2. Selective SOAP Parsing/Generic Classes or Selective SOAP Parsing/Deployed Java Class paired with Do not act as a proxy service:
   • target service(s) required in configuration
   • gateway service is portType specific, as defined by the first configured target service
   • body not parsed unless touched.
3. Selective SOAP Parsing/Generic Classes or Selective SOAP Parsing/Deployed Java Class paired with Act as a proxy service:
   • no Target Service(s) allowed, default provided
   • gateway service is portType agnostic
   • body not parsed unless touched.

Combination 1 is equivalent to the only configuration available in the previous version of the gateway.

Combination 2 is very similar to the first, the only difference being selective parsing.

Combination 3 is the proxy mode we described above.

Figure 10, above, shows the last combination selected, shows a value of ProxyService for the required Gateway Service Name, and shows that the service is to be made available on the only channel deployed in this gateway instance, in this case called SOAPHTTPChannel1. When the proxy mode is turned on, there is no point in publishing the WSDL generated by the gateway into a UDDI registry, so after entering only the name and choosing proxy mode and selective parsing, one should select OK (not shown in figure 10) to complete the initial configuration of the proxy gateway service. As a result, you will see a reminder (Figure 11); the reason for the warning, as described earlier, is that in proxy mode, the gateway cannot determine the actual service endpoint URI without assistance from a handler or filter.

After selecting OK, you will see a confirmation, which is a list of the currently deployed services. In our example, Figure 12 indicates that the ProxyService is the only gateway service in the configuration.

To continue the configuration of the proxy service, select the name of the proxy service, in this case, ProxyService. You will see Gateway Service Properties page, partially shown in Figure 13.

In the case of a proxy mode service, there is nothing that needs further configuration here until you scroll down. The JAX-RPC handler configuration for the channel should be modified, as described next.

Configuring inbound handlers

Figure 14 shows the Channels section of the gateway service configuration. Select Edit JAX-RPC handler configuration for the channel.

Figure 15 shows the JAX-RPC handler configuration page for the gateway service in the SOAP/HTTP channel named SOAPHTTPChannel1. Figure 15 shows that there are currently no handlers deployed for ProxyService. To deploy the first handler, select a handler from the drop-down list (LogHandler is selected in Figure 15) and then click the add button.

Figure 16 shows the refreshed JAX-RPC handler configuration page, indicating that LogHandler is now in the handler chain for ProxyService. At this point, it is possible to add additional handlers to the handler chain either before or after the LogHandler. Remember that for the proxy service, one must add a handler to the chain that sets the transport.url property to affect routing of requests to a real target service, as shown in the simple example of such a handler, above.

Configuring outbound handlers

With a gateway proxy service, there is no target service configured, and thus no outbound handlers. With a non-proxy service, one must configure one or more target services. Each port within a target service can have its own chain of outbound handlers. Since the process of configuring outbound handlers is new, we will describe this process next.

Assume a non-proxy service called MyAddress with a single target service called AddressServiceService is deployed (the process for doing so is the same as with previous versions of the gateway). Figure 17 shows the Target Services section of the initial configuration for MyAddress.

Click on the target service name, AddressServiceService in this case, to show the target service configuration, shown in Figure 18.

The Target Service Ports area displays at the bottom of Figure 18. In this case, you see the AddressService port, and then the link to the page where you can edit the outbound handler chain for the target service's port. Select Edit target service JAX-RPC handler configuration and you will see a page similar to Figure 19. As with the inbound handler chain, the initial configuration contains no handlers. To add the LogHandler to the chain, select LogHandler and add.

Figure 20 shows the resulting handler configuration page after adding the LogHandler. As with inbound handlers, you can add the TimeoutHandler into the chain either before or after the LogHandler.

Back to top

Conclusion

This article examined new features of the Web Services Gateway available with WebSphere Application Server Network Deployment Version 5.1, and how these features benefit users of the gateway. Supporting Local EJBs and selective parsing can significantly improve performance. Enabling JAX-RPC handlers offers a standard way of performing mediation of SOAP requests and responses. Support for the special proxy service configuration also makes it much simpler to configure proxy intermediary behavior. Administration of these new features is straightforward and offers compliance with Web services for J2EE. Taken together, these enhancements make the gateway applicable to a wider range of enterprise solutions.

Back to top

Acknowledgements

The author thanks Simon Holdsworth, the Web Services Gateway team leader, for invaluable assistance with the article content.

Resources

• An introduction to Web Services Gateway: Basic functions of the gateway.
  
  
• Java API for XML-Based RPC (JAX-RPC) [JSR-101]: Web services in Java.
  
  
• WebSphere Application Server, Version 5.1 Information Center: Details on WebSphere Application Server, WebSphere Services Gateway, UDDI registry; the latter two topics are found in the Network Deployment document under Administering => Applications => Web Services.
  
  
• Support for J2EE Web Services in WebSphere Studio Application Developer V5.1 -- Part 3: JAX-RPC Handlers: JAX-RPC handlers
  
  
• Simple Object Access Protocol (SOAP) 1.1: SOAP roles and headers.
  
  
• Ease your Web services testing woes: Integrate Web Services Gateway with WebSphere Studio Application Developer: Testing the gateway in WebSphere Studio Application Developer.
  

About the author

		Greg Flurry is a Senior Technical Staff Member in IBM's Enterprise Integration Solutions. His responsibilities include assisting customers applying IBM's service oriented technologies, and advancing those technologies.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top