Level: Introductory Chandra Venkatapathy (chandrav@us.ibm.com), Market Manager, IBM
Simon Holdsworth (Simon_Holdsworth@uk.ibm.com), Development Team Leader, IBM
01 May 2002 Web services can be accessed from applications and processes both within the corporate firewall and beyond it. Fundamental to this is how the service, deep inside your enterprise network, is exposed to external users. This article looks at the issues involved in this approach and how IBM's Web Services Gateway addresses these issues.
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.
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.
 |
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.
Listing 2. Gateway StockQuote service implementation WSDL
<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).
Listing 3. Gateway Web service URL
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.
Figure 1. Inbound request through the Gateway
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.
Figure 2. Outbound request through the Gateway
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.
Figure 3. Protocol transformation
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.
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.
|
Rate this page
| 
