Introduction

Web services are being adopted in the marketplace as a mechanism for efficient process integration in the enterprise. In creating Web services for your corporate network, you may see the need to to grow the scope of these services beyond the limit of your firewall. You can offer your services to your business partners, customers, and even subscribers, and allow them to become integral parts of your business processes. There are certainly many business issues to be solved before you offer others access to services from your network, but let's focus on the technical issues behind this.

As you start externalizing your Web services beyond the boundaries of your enterprise network, you will be faced with a number of issues that you need to address. These issues include security, reliability, quality of service, communications compatibility, and more. On the issue of communications compatibility -- the scope of this article -- you can run into a myriad of technical issues that network software using different protocols, operating system platforms, or even written in different programming languages need to satisfy to even talk to one another.

Amongst these issues of communications compatibility you need to consider the following:

• Decouple deployment from invocation: Separate the actual implementation of a service from how another service accesses it. These include:
  • Inbound Requests: A Web service is created and deployed within the firewall. How will service requestors from outside firewall make requests without going through some complex deployment and programming issues?
  • Outbound Requests: Similar to the previous entry; how can internal users get access to outside services in a controlled environment?
  • Process Abstraction: How can a higher level of abstraction be provided to identify and link to the service implementation for invocation? The service invocation approach must be flexible enough to cope with events such as switching frequently between external providers of a similar service without requiring changes to the application.
  • Flexibility: As a service provider, you need the flexibility of changing your deployment infrastructure without notifying all the service requestors. Say a Web service is deployed in a machine that later fails during operation. There needs to be a process to route the invocations to an alternate service in your infrastructure.
• Protocol transformation: An enterprise may be using a specific messaging infrastructure within their network to meet the business requirements. However, your partners and customers may be using different protocols to invoke your Web service. You need a mechanism to reconcile the different service invocations to match the needs of the internal infrastructure.

As you see, the above issues span your deployment and operational models. The Web Services Gateway technology is designed to solve the above issues while externalizing your Web services. From a business perspective, it enhances the reuse of your resources as your partners, customers, and subscribers can share your internal Web services.

Back to top

Introducing the Web Services Gateway

The Web Services Gateway is a run-time component that provides configurable mapping based on WSDL documents. It maps any WSDL-defined service to another service on any available transport channel. It is usually deployed at the firewall and has access to internal services. The Web Services Gateway provides the following features:

• Service mapping: The primary function of the Web Services Gateway is to map an existing WSDL-defined Web service to a new service that is offered by the Gateway to others. The Gateway thus acts as the proxy. External services are imported into the Gateway and made available to the enterprise as proxy services internally. Likewise, internal services are imported into the Gateway and made available as proxy services externally. These services are also published to the relevant UDDI directories where required.
• Export mapping: An internal service can be exported for outside consumption. Given the WSDL file, the Gateway will generate a new WSDL file that can be shared to outside requestors. The requestors will use the Gateway as the service end-point.
• Import Services: Similarly, an external service may be imported and made available as an internal service. This will help the internal service requestors to invoke the service as if it is running on the Gateway.
• Transformation: A request for a service may originate on one protocol, but the service may be invoked in some other protocol by using the transformation function. An internal service is available on SOAP over JMS could be invoked using SOAP over HTTP.
• UDDI publication & lookup: The Gateway facilitates working with UDDI registries. As you map a service for external consumption using the Gateway, you can publish the exported WSDL in the UDDI registry. When the services in the Gateway are modified, the UDDI registry is updated with the latest updates.
• Security and management: Provides a single point of control, access, and validation of Web service requests.

Back to top

How the Web Services Gateway works

The Web Services Gateway is configured with a number of transport channels. A transport channel can be defined as the underlying transport mechanism for Web services invocation. These channels provide you with a choice of transports over which to make your Web service available. When you map a service through the Gateway, among other things, you can specify the set of transport channels for use with the service; the location of the service's WSDL; and a name for the service at the Gateway. The Web Services Gateway builds on IBM's Web Services Invocation Framework (WSIF), which allows it pass on Web service invocations to any WSDL-defined Web service, even those in foreign protocols such as CORBA

Scenario 1. Handling inbound requests

Let us assume that you are providing a StockQuote service that is deployed inside the firewall of your enterprise and you want to share the service with your partners and customers.

Step 1. Create the WSDL document
Create the WSDL document that describes and invokes your StockQuote service. Listing 1 shows the sample of the WSDL that describes the StockQuote service. As you see, the soap address location is pointing to myhost that is inside the firewall.

<definitions targetNamespace=...>

  <message name="GetQuoteInput">
    <part name="symbol" type="xsd:string"/>
  </message>

  <message name="GetQuoteOutput">
    <part name="quote" type="xsd:float"/>
  </message>

  <portType name="StockquotePT">
    <operation name="getQuote">
      <input message="tns:GetQuoteInput"/>
      <output message="tns:GetQuoteOutput"/>
    </operation>
  </portType>

  <binding name="SOAPBinding" type="tns:StockquotePT">
    <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="getQuote">
      <soap:operation soapAction="http://example.com/GetTradePrice"/>
      <input>
        <soap:body use="encoded" namespace="urn:xmltoday-delayed-quotes"
              encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
      </input>
      <output>
        <soap:body use="encoded" namespace="urn:xmltoday-delayed-quotes"
                encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
      </output>
    </operation>
  </binding>  
 
  <service name="StockquoteService">
     <documentation>Stock quote service</documentation>
     <port name="SOAPPort" binding="tns:SOAPBinding">
       <soap:address location="http://myhost:8080/soap/servlet/rpcrouter"/>
     </port>
   </service>
</definitions>

Step 2. Import the WSDL document into the Gateway
This simply requires supplying a name for the service to be hosted at the Gateway, selecting the SOAP/HTTP transport channel, and specifying the location of the StockQuote WSDL file. The Gateway will generate a new WSDL file that can be shared with your partners. The main difference between these two files is that the Gateway generated file will have Gateway as the service end-point, and the bindings and the portType are separated into an interface WSDL file. Listing 2 shows the Gateway generated file with the appopriate changes.

<definitions targetNamespace=...>
<import namespace="http://www.ibm.com/namespace/wsif/samples/stockquote"
location="http://gatewayhost:80/wsgw/ServiceInterface?name=StockQuote"/> 
  <service name="StockQuote">
    <port name="StockquotePTApacheSOAPBindingPort"
          binding="interface:StockquotePTApacheSOAPBinding">
      <soap:address location="http://gatewayhost:80/wsgwsoap1/soaprpcrouter"/>
    </port>
  </service>
</definitions>

Step 3. Share the WSDL document to requestors outside the firewall
This can be done in one of three ways:

• Requesting the Gateway to publish the service to UDDI, in which case service requestors may obtain it by using UDDI lookups.
• Using a copy of the WSDL obtained from the Gateway.
• Accessing a supplied URL that dynamically obtains the WSDL from the Gateway (See Listing 3).

http://gatewayhost:gatewayport/wsgw/ServiceDefinition?name=gatewayservicename

Step 4. Service requestors send a SOAP request to the Gateway
The service requestors will send the SOAP request to the Gateway, which will invoke the service inside the firewall as shown in Figure 1.

Scenario 2. Handling outbound requests:

It is the same as the earlier case, except that you import the WSDL document from the provider outside the firewall into the Gateway, which generates a new WSDL document that will be used by internal service requestors. Figure 2 explains the flow of outbound requests.

Scenario 3. Protocol transformation

Let us extend the Scenario 1. Your internal StockQuote service is available on SOAP/JMS and your customers and partners will invoke it on SOAP over HTTP. In this case, you mostly follow the same steps as scenario 1. However, in step 2, you specify in the Gateway that the service will be accessed by SOAP over HTTP. The Gateway will generate the new WSDL to share with your partners. In particular, the interface WSDL file will contain the SOAP/HTTP bindings rather than the original SOAP/JMS ones. Figure 3 shows the flow of inbound requests that gets transformed to SOAP/JMS invocations.

Scenario 4. Access to non-SOAP services

This time the StockQuote service is implemented as a Java object, but you want to make it available to clients using SOAP/HTTP. In this case the WSDL for the service is the same as in Scenario 1 except that the WSDL contains Java bindings as shown in Listing 4.

<definitions ...>

  <binding name="JavaBinding" type="tns:StockquotePT">
    <java:binding/>
    <format:typeMapping encoding="Java" style="Java">
      <format:typeMap typeName="xsd:string" formatType="java.lang.String" />
      <format:typeMap typeName="xsd:float" formatType="java.lang.Float" />
    </format:typeMapping>
    <operation name="getQuote">
      <java:operation methodName="getQuote"/><input/><output/>
    </operation>       
  </binding>

  <service name="StockquoteService">
    <documentation>Stock quote service</documentation>
    <port name="JavaPort" binding="tns:JavaBinding">
      <java:address className="services.stockquote.Stockquote"/>
    </port>
  </service>
</definitions>

When this service is deployed to the Gateway, and the SOAP/HTTP transport channel is selected, the WSDL from the Gateway contains SOAP bindings and a SOAP/HTTP port on which the service is now available.

Back to top

Summary

As the deployment of Web services increases and becomes used with greater frequency both inside and outside the firewall, the traditional non-Web service ways of exposing these applications and processed could lead to problems of maintenance and reliability. The flexible abstracted approach of the Web Services Gateway is designed to provide a solution for these problems and encourage greater use of assets such as applications and processes.

Resources

• Download the WSIF distribution on alphaWorks and try out the easier samples. This give you a first-hand example of the different invocation styles supported by WSIF and its advantages over protocol-specific client APIs.
  
  
• Learn about SOAP, WSDL, and UDDI.
  
  
• If you haven't programmed with Web services before, the Web Services ToolKit is a good starting point.
  
  
• Take a look at WSDL4J, an extensible WSDL parsing framework over which WSIF has been built.
  
  

About the authors

Chandra Venkatapathy is a Market Manager for WebSphere Web services Marketing in the IBM Software Group. He has spent the last year in managing & marketing Web services technologies and products. Currently, Chandra is working on enhancing the middleware and integration portfolio with Web services. Chandra holds an MBA from the Kenan-Flagler Business School, University of North Carolina and master degrees in Electrical Engineering and Computer Sciences. You can contact Chandra at chandrav@us.ibm.com.

Simon Holdsworth is the development team lead and system designer for the WebServices Gateway in IBMs Hursley, UK Labs. His previous experience within IBM includes MQSeries Integrator, Component Broker, DSOM (during which time he was involved in the development of the OMG OTS specification and the IBM reference implementation) and CICS/ESA. He has an MSc in Mathematical Logic and the Theory of Computation from Bristol University, UK. You can contact Simon at Simon_Holdsworth@uk.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Introducing the Web Services Gateway
• How the Web Services Gateway works
• Summary
• Resources
• About the authors
• 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