Invoke Services More Easily Using Service Gateway

A service gateway provides more flexibility and makes it easier for service requesters to invoke services from other applications. The service gateway provides a single point of access, and it simplifies capabilities such as routing, monitoring, logging, versioning, and system-wide security. With WebSphere® Integration Developer V6.2, you can quickly implement the Service Gateway integration pattern. This article describes the functions and benefits of a service gateway, and then shows you how to create one.

Share:

Richard Gregory (gregoryr@ca.ibm.com), Software Developer , IBM  

Richard Gregory is a Software Developer at the IBM Toronto Laboratory. He is currently working on the WebSphere Studio Application Developer Integration Edition Development Team. Richard Gregory joined IBM part-time in 1997 and worked in the Centre for Advanced studies on various software re-engineering and distributed systems projects. He joined full-time in 2000 and has contributed to two releases of VisualAge for Java Enterprise Access Builder. He received his B. Sc. in Computer Science from the University of Toronto in 1999 and his MASc. in Electrical and Computer Engineering from the University of Waterloo in 2001.



Shu Tan (shutan@ca.ibm.com), Staff Software Developer, IBM  

Shu Tan is a staff software developer at IBM Toronto Laboratory in the Toronto, Ontario. She works on the debugger for Websphere Message Broker.



Janette Wong, Senior Technical Staff Member, IBM  

Janette Wong is a Senior Technical Staff Member at IBM. She leads patterns work in the BPM area. Currently she focuses on process patterns and collaborates with other subject matter experts in patterns areas such as connectivity and integration.



Grace Wong (gwong@ca.ibm.com), Software Engineer, IBM  

Grace Wong is a Software Engineer on the IBM Integration Bus Development Team at the IBM Software Lab in Toronto. You can contact Grace at gwong@ca.ibm.com.



David Van (davidvan@ca.ibm.com), Staff Software Engineer, IBM

David Van was the SVT architect for WebSphere Integration Developer where he was responsible for leading a number of system verification scenarios. He currently works with the IBM WebSphere Integration Developer and IBM WebSphere Message Broker Toolkit usability team. You can contact David at davidvan@ca.ibm.com.



22 July 2009

Also available in Spanish

Introduction

Using WebSphere Integration Developer V6.2, you can quickly start building applications by using templates that represent pattern solutions. One of the patterns that is available in WebSphere Integration Developer V6.2 is the Service Gateway, shown in Figure 1.

Figure 1: A service gateway in an enterprise service bus
service gateway in an enterprise

The following correspond to the numbers in Figure 1 and describe the functions and benefits of a service gateway.

  1. Give service requesters a simplified single point of access

    Simplified access is achieved by providing a mediation flow with a generic service gateway interface to mediate messages from different service requesters. All one-way operations that come through the gateway are mediated by the requestOnly flow of the service gateway interface; all request-response operations that come through the gateway are mediated by the requestResponse flow as shown in Figure 1.

    To suit different requesters, the service gateway supports the following protocols: Web service, HTTP, JMS, and MQ. When a service request enters the service gateway, it is converted into a protocol-specific business object by the protocol-specific data binding or data handler of the gateway. For example, a SOAP request is wrapped in a TextBody business object, which is then placed inside the Service Message Object (SMO) body. The protocol-specific function selector of the gateway determines if the request will be mediated by the requestOnly or requestResponse flow. For more information about the data conversion and function selector, see the Service Gateway Support paper in the Resources section of this article.

  2. Perform common processing on all request and response messages

    The service gateway supports message logging, either writing the messages to a database, emitting the messages as events to an event server, or processing the messages using custom Java code. Furthermore, you can add capabilities to perform such actions as security checks and validation.

  3. Route requests to service providers

    The mediation flow processes the requests that the service gateway receives. After common processing is performed on the request, it is routed to a service provider. The protocol-specific data binding or data handler converts the request from the protocol-specific business object format back into the original message format. Using the example earlier, the request is converted from TextBody back into SOAP. The service provider endpoint address can either be selected dynamically at run time, or defined at development time. For a SOAP request, routing information can be in the SOAP header, which usually contains enough information for the service gateway to determine the appropriate service provider, or it can be in the SOAPAction attribute, in the URL, or in WS-Addressing section of the request.

If the service provider endpoint is determined at run time, the service gateway is known as a dynamicservice gateway (shown in Figure 2), which means that different ways of looking up the service provider endpoint at run time are supported, such as retrieving the endpoint address from WebSphere Service Registry and Repository or from a database. A dynamic service gateway typically routes the requests to the selected service provider as-is.

Figure 2: A dynamic service gateway
dynamic service

If the service provider endpoint is determined at development time, the service gateway is known as a staticservice gateway (shown in Figure 3). Each callout node represents a service provider whose endpoint address is defined in the corresponding import in the assembly diagram. The gateway transforms the request from the protocol-specific format to the format defined by the service provider interface. Optionally, the service gateway can enrich the transformed request before routing it to the service provider.

Figure 3: A static service gateway
static service

To decide whether you need a dynamic service gateway or a static service gateway, determine whether you want to enrich or transform your request message before routing it to the service provider and whether more service providers might have to be added after the gateway has been deployed. To enrich your request message, you must use a static service gateway. To add service providers after the gateway is deployed, use a dynamic service gateway because you can add service providers without updating and re-deploying the gateway. If you use a static service gateway and want to add service providers, you have to update it with the additional service provider interfaces and re-deploy it. Notice that common processing such as logging is available regardless of which type of gateway you choose.


Summary

The following list shows the benefits of a service gateway:

  • It provides a single simple point of access to various service providers by making a single generic service gateway interface (ServiceGateway.wsdl) available.
  • It centralizes common processing such as logging and validation for all the request and response messages, eliminating the need to repeat the development of such processing between every requester and provider.
  • It provides flexibility in the routing of requests to different service providers.

The following table summarizes and contrasts the key characteristics and functions of the dynamic and static service gateways

Table 1: Comparison between dynamic and static service gateway
Details Dynamic service gateway Static service gateway
Common processing Yes
Number of callout nodes 1 (generic gateway interface) 1 or more specific service provider interfaces
Need to transform the message body No Yes
What the gateway does A mediation primitive, for example an Endpoint Lookup or a Database Lookup primitive, uses the information in the header to look up the endpoint address to which to route the message at run time, and places it in /headers/SMOHeader/Target/address of the SMO. A Message Filter primitive uses the information in the header to determine which path to route the request message to. A data handler primitive transforms the message from the wrapped form, for example TextBody, to a business object format that is defined by the service provider interface. Optionally, an XSLT primitive can be used to enrich the message before it is sent to the service provider.

Now that you have an overview of a service gateway, let’s go through how you would configure the gateway to provide the functions described previously.


Configuring a service gateway

To create a service gateway module in your workspace that can run on WebSphere Enterprise Service Bus or WebSphere Process Server, click New > Service Gateway (shown in Figure 4) or New > From Patterns (shown in Figure 5).

Figure 4: Selecting Service Gateway from the menu
Selecting Service Gateway from the menu
Figure 5: Selecting the service gateway pattern
Selecting the service gateway or pattern

After you click Next, you provide a name for the service gateway module that will be created in your workspace. On the next page, you choose to create either a dynamic service gateway or a static service gateway.

Figure 6: Selecting a dynamic or static gateway
Selecting a dynamic or static gateway

The next two sections describe configuration options for a static service gateway and a dynamic service gateway respectively. The type of gateway you choose, static or dynamic, determines what information you will need to provide in the New Service Gateway wizard.


Static service gateway

Figure 7 shows the second wizard page you see when you select static as the type of service gateway.

Figure 7: Creating a static gateway
Creating a static gateway

To add service provider interfaces, click Add. You can select any service provider interfaces that are in libraries. The New Service Gateway wizard automatically adds a dependency from the service gateway module to the library of each interface that you added.

In the same wizard, you can also log the messages or emit them as events by selecting Log messages in a database, Log messages using custom Java, or Emit messages as common base events to a CEI server (shown in Figure 7).

Selecting the service gateway protocol for static service gateway

Figure 8 shows each of the service gateway transport protocols that you can select. When you create a static gateway, you also need to select the protocol-specific data format of the request, such as XML for the Web Services protocol. Given this protocol-specific data format information, the service gateway data binding or data handler can wrap the request body as a business object, such as TextBody. For more details about protocol-specific data format, refer to the Service Gateway Support paper in the Resources section of this article.

Figure 8: Selecting the gateway transport protocol
Selecting the gateway transport protocol

When you click Finish, the static service gateway module is generated.


Dynamic service gateway

To prevent a service gateway from having to be associated with a fixed set of service interfaces, you can build it independently of services that might be accessed through it now or in the future. When the gateway is running on a server, you can look up what service should be called based on the service request. For example, you might publish an external Web service address URL as

http://mycompany.com:9080/GatewayWeb/sca/GatewayModule?targetService=InsQuote

where the service name is a parameter, but the actual address is

http://internal.mycompany.com:9080/InsuranceQuoteService/InsuranceQuoteHttpService

When a service request arrives at the gateway, the lookup for InsQuote can be done using a database or WebSphere Service Registry and Repository to determine what the actual address is. If the actual address changes, then it is necessary to update the database or repository only. You will see an example of needing to only update a database in the exercise section of this article, where the gateway uses the actual address to route the service call.

Figure 9: Selecting dynamic gateway logic
Selecting dynamic gateway logic

Figure 9 shows the second page of the New Service Gateway wizard when a dynamic gateway was chosen on the first page. Comparing this second page with the second page in Figure 7, notice that you don’t associate specific service interfaces with the service gateway.

Let’s take a quick look at what will be created for each choice of how the service provider is selected at run time.

Selecting Query a WebSphere Service Registry and Repository (WSRR) creates an Endpoint Lookup primitive that must be configured to connect to WebSphere Service Registry and Repository to look up the endpoint address. The retrieved endpoint address is stored in the SMO value /headers/SMOHeader/Target/address.

Selecting Retrieve from database creates a Database Lookup primitive that needs to be configured to connect to a database to look up the endpoint address. The retrieved endpoint address will be stored in /headers/SMOHeader/Target/address.

If you want your own way of selecting a service, choose Write my own logic. This creates a custom mediation primitive in which you can write Java code or use visual Java to set the endpoint address so that routing will happen dynamically.

Finally, selecting Use an element from the request message creates a Message Element Setter primitive in the mediation flow. In the example shown in Figure 10, the Message Element Setter primitive named RouteMessage copies everything after ?targetService=in the Web service address URL to the endpoint address in SMO header.

For example, a client might send a request to the gateway using the URL http://localhost:9080/DynamicGatewayModuleWeb/sca/DynamicGatewayModuleExport?targetService= http://localhost:9080/InsuranceQuoteService/InsuranceQuoteHttpService. The RouteMessage node would copy http://localhost:9080/InsuranceQuoteService/InsuranceQuoteHttpService to the SMO target address.

In this case, the callout node in the mediation uses the target address to invoke the service.

Figure 10: Using a Message Element Setter primitive to set the endpoint address in a dynamic service gateway
Using a Message Element Setter primitive to set the endpoint address in a dynamic service gateway

Selecting the service gateway protocol for dynamic service gateway

The next step is to select the service gateway protocol. The wizard page (Figure 11) is very similar to Figure 8 but without the choice of protocol-specific data format. A dynamic service gateway is not expected to access or modify the message body because the routing relies only on the request header; therefore, a choice of protocol-specific data format is not necessary.

Figure 11: Selecting the gateway transport protocol for dynamic gateway
Selecting the gateway transport protocol for dynamic gateway

When you complete the wizard, the dynamic service gateway module is generated for you.


Putting it all together with an example

Now that you’ve seen the basics of using the Service Gateway pattern, here’s a scenario you can try to create your own service gateway and see it in action. Imagine that you have five Web services and now you want to log each request to the Web services using a service gateway. In the Downloads section of this article, there is a link to a project interchange file that contains five Web services. There is also a link to a business process that is wired to Web service imports. Each import has its endpoint set to the soon-to-be-built service gateway module.

At the beginning of the Dynamic Service Gateway section, we explained how you add the service name as a parameter to the gateway URL. Alternatively, you could pass the service name to the gateway using a SOAP header, which is what we will show in this example. The gateway will use the service name to determine the actual service to call. You will start by deploying the ClipsAndTacks application, which contains the Order Handling process, and the Web service modules to a server. Then you will build the gateway that exposes the modules to the world (but only in the way we want the world to see them).

Here is an overview of the architecture of the scenario and how it works.

  1. The test client issues a request to place an order with the Order Handling process.
  2. The Order Handling process has business logic that uses the Web services illustrated in the right side of the diagram.
  3. A new requirement arises to log each request to the Web services. The gateway interacts with the Order Handling process to dynamically route and map the requests to the Web services.
Figure 12: Overview of the Order Handling process
Overview of the Order Handling

In this scenario, we will build the Order Handling services (that is, the service gateway) part of the diagram. The other parts of the example are provided in the project interchange file that you will import into WebSphere Integration Developer V6.2

  1. Go to the Downloads section of this article and save the OrderHandlingService.zip file to a convenient location.
  2. Import the OrderHandlingService.zip project interchange file into a new WebSphere Integration Developer workspace.
  3. Switch to the Servers view, start WebSphere Process Server, and then deploy the modules that are now in your workspace to the server.

After importing the project interchange file, you will see the modules in your workspace as shown in Figure 13. Note that there is also a Resources library; it contains only those files that will be used to do the routing lookup and for testing.

Figure 13: The workspace after importing the OrderHandlingService project interchange file
workspace after importing the OrderHandlingService project interchange file

The ClipsAndTacksF1 module contains the Order Handling business logic. As you might recognize, the remaining modules represent the Web services mentioned earlier.

You are creating a dynamic service gateway, so you do not need to specify the five interfaces of the services at development time.

  1. In the Business Integration perspective, select File > New > Service Gateway. The New Service Gateway wizard opens.
  2. In the Service gateway name field, type OrderHandlingServices.
Figure 14: Creating a new service gateway
Creating a new service gateway
  1. Click Next.
Figure 15: Selecting a dynamic gateway
Selecting a dynamic gateway

As mentioned earlier, a dynamic gateway means that you need some way to look up the service address at run time. To see how it works, you will write your own custom logic in the gateway that will simulate doing a database or repository lookup.

  1. On the Select the type of gateway page, leave Dynamic selected, and then click Next.
  2. Select Write my own logic. This will create a custom mediation primitive named RouteMessage in the mediation flow. You will write your own logic inside that node shortly.
  3. Select Log messages using Custom Java. When you run the application, a log file named MessageLog.log will be created in the directory defined by the TEMP environment variable. You can determine this directory in Microsoft Windows by typing set temp at a command prompt).
Figure 16: Selecting service providers
Selecting service providers
  1. Click Next. Select Web Service (SOAP 1.2/HTTP).
Figure 17: Selecting the transport protocol
Selecting the transport protocol
  1. Click Finish.

A mediation module named OrderHandlingServices is created, as shown in Figure 18. The next steps will complete the service gateway logic.

Figure 18: The service gateway module in the workspace
service gateway module in the workspace
  1. In the assembly diagram, double-click OrderHandlingServices to open it in the Mediation Flow editor.
  2. Click the requestResponse source operation because, in this example, all messages are request-response messages.
Figure 19: The OrderHandlingServices mediation flow
OrderHandlingServices mediation flow

Figure 19 shows the service gateway mediation module that you created by completing the wizard. The LogMessage node is there because you chose to log messages using custom Java (see Figure 16). Notice the TODO note in Figure 19, which indicates that you need to provide Java or visual code in the custom mediation primitive to set the target endpoint in the XPath /headers/SMOHeader/Target/address. Perform the following steps to complete that task:

  1. Double-click the RouteMessage custom mediation node to open the Properties view for it.
  2. Click the Java Imports tab and copy the following lines:
import commonj.sdo.DataObject;
import com.ibm.websphere.sibx.smobo.TargetAddressType;
import com.ibm.websphere.sibx.smobo.ServiceMessageObjectFactory;
import com.ibm.websphere.sibx.smobo.SOAPHeaderType;
import java.io.File;
import java.util.Scanner;
import java.io.FileNotFoundException

The imports are added so that type names in the RouteMessage Java code do not require qualifiers.

Figure 20: Adding the Java imports
Adding the Java imports
  1. Click the Details tab and, in place of the line below the generated comment, out.fire(smo), paste the following Java code :
	//
	// Get the requested service name from the SOAP header in the
	// message sent to this service gateway.
	//
	SOAPHeaderType soapHeaderType = 
		(SOAPHeaderType)smo.getHeaders().getSOAPHeader().get(0);
	DataObject soapHeaderValue = (DataObject)soapHeaderType.getValue();
	String reqServiceName = soapHeaderValue.getString("targetService");
	System.out.println("->Gateway service request for: " + reqServiceName);
	//
	// Read the text file to determine the mapping between 
	// endpoints and service names.
	//
	// NOTE: Modify the file name depending on the 
	// actual file location.
	//
	File dbFile = new File("D:\\ServicesDB.txt");
	Scanner fileScanner;
	try {
	 fileScanner = new Scanner(dbFile);
	} catch (FileNotFoundException e) {
	 e.printStackTrace();
	 return;
	}
	try {
	 while (fileScanner.hasNextLine()) {
	  // 
	  // Read each line in the file to get the mapping between
	  // the requested service name and the actual endpoint.
	  // The lines are in the format <service name>=<service URL>
	  //
	  String nameUrlLine = fileScanner.nextLine();
	  Scanner nameUrlScanner = new Scanner(nameUrlLine);
	  nameUrlScanner.useDelimiter("=");
	  if (nameUrlScanner.hasNext()) {
	   String serviceName = nameUrlScanner.next();
	   String serviceURL = nameUrlScanner.next();
	   if (serviceName.equals(reqServiceName)) {
	    //
	    // We found the matching requested service name in
	    // the text file. Set the actual endpoint address.
	    //
	    System.out.println("Routing " + reqServiceName + " to "
	      + serviceURL);
	    TargetAddressType targetAddress = 
	      ServiceMessageObjectFactory.eINSTANCE
	      .createTargetAddressType();
	    targetAddress.setAddress(serviceURL);
	    smo.getHeaders().getSMOHeader().setTarget(targetAddress);
	   }
	  }
	  nameUrlScanner.close();
	 }
	} finally {
	 fileScanner.close();
	}
	//
	// Propagate the service message object to the 
	// primitive that is wired to the 'out' terminal.
	//
	out.fire(smo);
  1. Save all the editors in the workspace

For this code to route service requests, it needs a database (in our case, this is a text file) that determines the correct service to call for each incoming request. This sample code expects the file contents to be in D:\ServicesDB.txt, although you can change that if you want to put it elsewhere (such as if you are running on Linux) and modify step 2 below accordingly.

  1. In the file system, browse to the Resources project that was imported with the project interchange file and locate the ServicesDB.txt file.
  2. Copy ServicesDB.txt to the root of your D: drive or to whichever location you specified in your code.

Note: The port 9080 is used in all the Web service import and export bindings and in the URLs in ServicesDB.txt. Your server might not use 9080 as the http port number. To check the http port that your server uses, browse to the WID62_ROOT\pf\wps\logs\AboutThisProfile.txt file. If the http port is not 9080, perform the following steps to redirect the Web service requests from 9080 to your http port.

In the Servers view, right-click the server and select Monitoring > Properties.

Click Add.

Select the line in the table with the http server port number that you determined from the WID62_ROOT\pf\wps\logs\AboutThisProfile.txt file.

For Monitor port, change the value to 9080, and then click OK. This will redirect requests to port 9080 to the http port that your server uses.

Select the monitor in the table and click Start.

Recall that the service name will be passed to the gateway using a SOAP header. The next steps provide a definition for the header so that the service gateway mediation module will understand it.

  1. In the Resources library, under the Data Types folder, locate the TargetServiceHeaderType business object.
  2. Copy TargetServiceHeaderType to the OrderHandlingServices module. TargetServiceHeaderType will be listed under Data Types in that module.
  3. Deploy the OrderHandlingServices module to the server.

You have built the service gateway. As you add or remove services, or change the service endpoints, just change the database or repository or, such as in this example, the ServicesDB.txt file. The OrderHandlingServices module will not require changes.

You are now ready to test your application.

  1. In the Business Integration view, right-click ClipsAndTacksF1 and select Test > Test Module. The integration test client opens.
  2. Select the Configurations tab, right-click Human Task Emulators, and then select Add > Human Task Emulator. There is a human task that implements the Ship Order to Customer activity in the business process. Therefore, you can use the human task emulator to claim and complete the task using the integration test client.
  3. Click Next, click Select All, and then click Finish to create the human task emulator.
  4. In the integration test client, select the Events tab. For the component, select OrderHanding and in the Value column in the CustomerNumber row, type 123.
  5. To begin running the test, press Ctrl-R. If the User Login window opens, enter your server user ID and password, and then click OK.
  6. Wait for the Claim (OrderHandling.ShipOrdertoCustomer_InputCriterion) event to be displayed. Remember that you have set up the human task emulator; therefore, when this event is displayed for the Ship Order to Customer activity, you want to simulate the data that the human task returned. To do that, under Input parameters, right-click Order and select Copy Value. Scroll down if necessary to Output parameters, right-click Order and select Paste Value.
  7. To continue running the test, press Ctrl-R, and then wait for the application to complete.

Figure 21 shows the completed run of the application. This test is set up to take a particular path through the business process, but the focus of this exercise is on the outbound calls from the business process to the service gateway. The outbound calls from the Order Handling process are to the Web service imports we mentioned at the beginning of the exercise. If you switch to the Server Logs view, you will see log entries from the gateway where it routed each call to a specific service.

Figure 21: Testing the service gateway
Testing the service gateway

You chose to log messages that pass through the service gateway. Therefore, a quick check of the <TEMP location>/MessageLog.log file will show entries, such as in Figure 22.

Figure 22: Contents in the service gateway log file
Contents in the service gateway log file

Testing only the service gateway module

You just completed testing your application that called its services through the service gateway. This final section will show you how you can unit test the gateway by itself. In this case, you will send a message directly to the service gateway, which will cause the service gateway to route the message to one of the Web services.

  1. In the Business Integration view, right-click the OrderHandlingServices module and select Test > Test Module.
  2. For the component, select OrderHandlingServicesExport and for the operation, select requestResponse, as shown in Figure 23.
Figure 23: Unit testing the service gateway
Unit testing the service gateway
  1. Select the Message tab and select XML Editor.
  2. Click Import Message, browse to the Resources project in the workspace, select Input_CheckOrderHandlingPolicyForAutomaticApproval.xml, and then click Open. The XML editor contents are displayed, as shown in Figure 24.
Figure 24: Importing the SOAP message to test the service gateway
Importing the SOAP message to test
  1. To run the test, press Ctrl-R. The gateway will route the single request and create an entry in the server log, as shown in Figure 25.
Figure 25: Complete unit test of the service gateway
Complete unit test of the service

Summary

Here’s what you accomplished in this tutorial:

  • You imported five Web services and an Order Handling process into your workspace and deployed them to a WebSphere Process Server unit test environment.
  • Using the Service Gateway Pattern wizard, you created a dynamic service gateway (called OrderHandlingServices), which routes requests from the Order Handling process to all of the Web services. Because the OrderHandlingServices gateway is dynamic, you did not need to specify the interfaces of the Web services when you created the gateway. Additionally, the gateway performs the following actions:
    • Selects which Web service to invoke by using custom logic. The custom logic uses the requested service name in the SOAP header to look up the actual endpoint address in a file. The /headers/SMOHeader/Target/address field is then set with the actual endpoint address.
    • Logs all requests to the Web services.
  • You tested the service gateway by testing the Order Handling process component, and the service gateway directly using the CheckOrderHandlingPolicyForAutomaticApproval SOAP message.

Conclusion

In this article, you learned about the functions and benefits of a service gateway and created and tested a dynamic service gateway to invoke a set of Web services from a business process. The gateway serves as a single entry point to the services for the business process, as well as any other client that must access the same set of services. The gateway also provides common processing for the request and response messages and routes each request to the appropriate service provider. Remember, what you create with the service gateway wizard is just a starting point; it determines what will initially exist in the mediation module that you create using the New Service Gateway wizard. After you have completed the wizard, you can customize the mediation flow (specifically, the functions of the service gateway) to do just about anything.


Download

DescriptionNameSize
Code sampleOrderHandlingService.zip312 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=407239
ArticleTitle= Invoke Services More Easily Using Service Gateway
publish-date=07222009