Introduction

JAX-RPC is the Java API for XML RPC. It is an interoperable standard API for invoking Web services in the Java 2 Enterprise Edition (J2EE) environment. WebSphere 6.x JAX-RPC 1.1 implementation supports multiple protocols (SOAP/HTTP, SOAP/JMS and RMI/IIOP) through WSDL extensions. You can select a desired port (protocol binding) programmatically during invocation, or you can specify a default port that can be externally configured using the WebSphere Administration Console. You can also specify the target address of the Web service that can override the value in the WSDL file.

Understanding the service consumer and service provider

In an ideal SOA environment, a service consumer and service provider are connected using an Enterprise Service Bus (ESB). An ESB provides service location transparency, protocol conversion, and a number of other functions using standard or custom mediations that are required for a resilient SOA. In a real-world scenario, getting to an ideal SOA with a fully deployed ESB environment takes time. As more and more enterprises embark on the SOA journey, the applications can leverage some of the ESB functionality without a full-fledged ESB in place and be ready to easily migrate to an ESB environment when the ESB and SOA environment is fully deployed in the enterprise.

Figure 1 shows the decoupling of service consumer and service provider. This article describes how to use a WebSphere JAX-RPC implementation to invoke and use the multi-protocol support in WebSphere to expose a service using the three protocols: HTTP, Java™ Messaging Service (JMS), and Remote Method Invocation - Internet Inter-ORB Protocol (RMI/IIOP) (EJB). The service consumer and the service provider are assumed to be WebSphere J2EE applications, and, therefore, they run within WebSphere containers. WebSphere administration configuration is used to achieve service location and protocol transparency to the service consumer. This enables binding the service consumer to a desired instance of the service provider. It also enables selecting a desired protocol without changing the service invocation code. Of course, there are limitations to what this technique can provide. It works in certain scenarios where no mediation functions are required, development and testing environments, and in some cases even production environments where certain service consumer needs to be bound to a specific version of the service provider that is pre-determined before deployment.

NOTE: There are other scenarios where the service consumer could be a standalone J2EE application client, a Java application, or a client from other platforms such as .NET. These cases are not covered in this article. Such a scenario requires the use of a Web services gateway or a full fledged ESB solution that can provide location and protocol transparency.

Back to top

Understanding JAX-RPC

JAX-RPC stands for Java API for XML-based remote procedure calls (RPC). It uses the XML-based protocol SOAP 1.1 specification for exchange of information in a distributed environment. JAX-RPC is designed to interoperate between Java and non-Java platforms and is based on WS Basic Profile 1.0 technologies, such as XML, SOAP 1.1 and WSDL 1.1. JAX-RPC provides synchronous and asynchronous one-way invocations.

For more information on JAX-RPC, refer to the following two articles from developerWorks:

• Developer's Introduction to JAX-RPC, Part 1
• Developer's Introduction to JAX-RPC, Part 2

Note: JAX-WS 2.0 is a follow-on API specification. It addresses some of the shortcomings of JAX-RPC, and it supports additional asynchronous invocation modes. JAX-WS 2.0 uses different package names. However, JAX-RPC continues to be available in the J2EE environment. In fact, J2EE 1.4 mandates JAX-RPC 1.1 implementation.

Back to top

Introducing JAX-RPC client types

JAX-RPC supports three types of clients that differ in the way they invoke the target service, as shown in Figure 2.

• The static stubs use the stubs created during development time. They do not require a copy of the WSDL at run time. The service endpoint address is either hard-coded in the client or read from a property file and set during runtime. The binding to specific port is also pre-determined during development time.
  
  
• The dynamic proxy creates the proxy at runtime and, therefore, provides the flexibility to bind to specific port and endpoint. This style allows for location and protocol transparency and is the focus of this article. WebSphere implementation provides configuration parameters that you can use to externalize the endpoint and port (protocol) decision outside the client program.
  
  
• The Dynamic Invocation Interface (DII) is the least common type of client and is mostly used when the WSDL changes frequently.

For more details on the JAX-RPC client types, refer to one of the IBM Redbooks™ shown in the Resources section.

Back to top

Invoking multiprotocol Web services

WebSphere JAX-RPC multiprotocol implementation support allows invocation of Web services through a number of protocols such as SOAP/HTTP, SOAP/JMS, and RMI/IIIOP while using a common programming model (JAX-RPC). Invocation using SOAP/JMS and RMI/IIOP can offer better performance in some cases, and it can offer higher-level quality of service (QoS) features such as:

• SOAP/JMS
• Offers reliable delivery of messages
• Offers support for broadcast and queued modes of requests
• RMI-IIOP
• Provides for synchronous communication and reliable delivery of requests
• Offers support for propagation of security and transactional contexts

Back to top

Introducing the sample demonstration

This article offers a very simple application to demonstrate this concept. The application consists of an Enterprise Java Bean (EJB) that uses multiple protocols, namely HTTP, JMS, and RMI/IIOP. This article explains how to write a simple client that will invoke the service. The invocation code only deals with the Web service interface and is not concerned about the actual protocol used to communicate to the service provider. The plumbing between the service consumer and service provider is done at deployment time using the WebSphere Administration Console. This late binding provides the flexibility to change the binding and desired protocol—a key benefit documented in this article.

This article uses the Dynamic Proxy Invocation method, as shown in Figure 2. The steps to create the service and the service invoker are shown using the WebSphere Application Server Toolkit (ASTK)) 6.1 Integrated Development Environment (IDE). You can also use similar IDEs, such as Rational Application Developer (RAD) and Rational Application Software Architect (RSA). The sample application is also provided as a project interchange zip file that you can import into your ASTK 6.1 or other Eclipse-based IDE. Deploy the developed sample application to WebSphere Version 6.1. The sample application runs fine on WebSphere 6.0 and later versions.

Back to top

Developing the sample service provider application

Complete the following steps:

1. Open WebSphere ASTK 6.1.
   
   
2. Create a new project using the Create an EJB project wizard.
   
   
3. Provide an EJB Project name, and click Next. As per the J2EE best practice, create an EJB client JAR and specify the Client JAR name, as shown in Figures 3, 4, and 5.
   
   Figure 3. EJB project wizard
   
   
   
   
   Figure 4. EJB project
   
   
   
   
   Figure 5. EJB client jar
   
   
   
4. Right-click the EJB project you just created, and select New.
   
   
5. Click Other, and select the Enterprise Bean creation wizard.
   
   Figure 6. Enterprise bean
   
   
   
6. Select session bean in the enterprise bean creation wizard.
   
   
7. Specify the EJB project you created.
   
   
8. Specify the EJB name and default package, as shown in Figure 6.
   
   
9. Specify the enterprise bean details, as shown in Figure 7. Be sure to select the checkbox to create an EJB service endpoint. Name the service endpoint as MyEJB_SEI.
   
   Figure 7. Enterprise bean details
   
   
   
10. Click Finish to create the Enterprise Java Bean. Notice in Figure 8 that the MyEJBBean class is created in the ejbModule folder. Also, notice that the MyEJBServiceProjectClient project is created in Other Projects. You will add a method in the EJB Bean method and promote the method to the interface classes that are located in MyEJBServiceProjectClient.
    
    Figure 8. EJB file details
    
    
    
11. Add a method in the EJB Bean class, MyEJBBean, as shown in Figure 10.
    
    Figure 9. MyEJBBean method Java code
    
    
    
12. Promote this method to the remote EJB interface and service endpoint interface (SEI) objects by right-clicking the enterprise bean method in the Java editor. Do this by clicking Enterprise Bean > Promote to Remote Interface and Enterprise > Promote to Service Endpoint Interface. The promoted methods are shown in Figure 10.
    
    Figure 10. EJB client interfaces after method promotion
    
    
    
13. Expose the service endpoint interface and create a Web Service Description Language (WSDL) file that describes the interface from which to generate the client stubs. Create a WSDL file that can expose the interface using multiple protocols: HTTP, JMS, and RMI/IIOP. Currently the IDE does not support RMI/IIOP bindings, though you can insert them manually. Use the Java2WSDL available with the WebSphere 6.0 runtime to create the WSDL files. In order to create the WSDL file from the EJB, use the EJB jar file and the client jar files. Export them from your ASTK workspace to a temporary directory.

    Note: The tooling to generate the bindings for HTTP, JMS, and EJB is now available in ASTK 6.1.1 and RAD 7.0. If you use these new IDE enhancements, you can skip Steps #14 to #30 and continue to Developing the sample service client application.

14. Export the EJB client Jar, as shown in Figure 11.
    
    Figure 11. EJB client Jar export
    
    
    
15. Export the EJB Jar file, as shown in Figure 12.
    
    Figure 12. EJB Jar export
    
    
    
16. Change directory to the WebSphere runtime directory from within your WebSphere installation or RAD/RSA 6.0 WebSphere runtime environment in a command line window.
    
    
17. Make sure the bin directory of the WebSphere runtime environment is in your path so that your command line window can find Java2WSDL.bat.
    
    
18. Change to the bin directory, and run setupcmdline.bat.
    
    
19. Change directory to a temporary work directory, and set the CLASSPATH so that the Java2WSDL command picks up the EJB and client Jar files in the classpath.
    
    
20. Set CLASSPATH=MyEJBServiceProject.jar;MyEJBServiceProjectClient.jar;%CLASSPATH%
    
    
21. Run the Java2WSDL command as shown below:

    java2wsdl -bindingTypes http,jms,ejb -style document-implClass testservice.MyEJBBean testservice.MyEJB_SEI

    
    
22. Ignore the warning message. You will edit the WSDL file generated and fix the binding location. A sample screen shot of the commands is shown in Figure 13.
    
    Figure 13. Java2WSDL
    
    
    
23. Inspect the WSDL file that was generated as a result of the previous command. In Figure 14, notice that there are three bindings: SOAP (HTTP), EJB (RMI/IIOP), and JMS. Scroll down to the bottom of the file to notice there are three ports for each of the bindings. Also notice that the address for each of the ports is not defined. You will define these later.
    
    Figure 14. WSDL file: bindings
    
    
    
    
    Figure 15. WSDL file: ports
    
    
    
24. Import the generated WSDL into the MyEJBServiceProject in your ASTK IDE workspace, as shown in Figures 16 and 17.
    
    Figure 16. Importing the WSDL file
    
    
    
    
    
    
    Figure 17. Imported WSDL file
    
    
    
25. Run the WSDL2Java command that generates additional XML files. The webservices.xml and IBM WebSphere container-specific binding files (ibm-*.xml) that describe the Web service are generated.
    
    
26. Run the following command from the temporary directory:

    WSDL2Java -verbose -role develop-server -container ejb-genJava no MyEJB_SEI.wsdl

    
    The generated files are placed in the META-INF directory, as shown in Figure 18.
    
    Figure 18. Web service XML files
    
    
    
27. Import the generated files into the META-INF directory in the EJB project as shown in Figures 19 and 20.
    
    Figure 19. Import Web service XML files
    
    
    
    
    
    Figure 20. Details for importing Web service XML files
    
    
    

    Now the EJB project is Web service enabled. On closer inspection of the webservice.xml file, notice that the <ejb-link> tag needs to be updated with the EJB name, as shown in Figure 21.

    
    
    
    Figure 21. Web service XML file
    
    
    
28. Change the value for the <ejb-link> tag to MyEJB, which is the name of the EJB as defined in the ejb-jar.xml file. You can open the webservices.xml file in an XML editor to edit this value.

    In order to access the EJB service using HTTP and JMS, you need to enable the endpoints. Enable the HTTP endpoint by creating a special HTTP router that front ends the EJB. The JMS endpoint is enabled by creating a message-driven bean that front ends the EJB. The EJB binding uses the normal RMI/IIOP lookup process to find the bean and invoke the appropriate methods on the bean. The three protocol invocation flows are shown in Figure 22.

    
    
    Figure 22. Multi-protocol
    
    
    

    To enable the endpoints for SOAP/HTTP and SOAP/JMS, use the tooling available in the IDE.

29. Right-click the webservices.xml file in the EJB project in the META-INF folder, and select Web Services > Create Router Modules.
    
    
30. Select transports HTTP and JMS. The wizard fills in the other fields, as shown in Figure 23.
    
    Figure 23. Endpoint enabler
    
    
    

    This creates a Web project and EJB MDB projects, as shown in Figure 24. You need to create a queue destination and define a JCA activation spec for enabling the message-driven bean that you will see when you install the sample application.

    
    
    Figure 24. Router projects
    
    
    

Back to top

Developing the sample service client application

In this section, you will develop a simple Web client application that runs in the WebSphere Web container. This client application invokes the Web service that you developed in the previous section. You will use the Dynamic Invocation Proxy method to invoke the Web service.

At the time of the invocation, you will not explicitly specify any port for communication. Instead, you will get a default port associated with the Web service. The default port will be configured in the WebSphere Administration console.

1. Create a Dynamic Web Project in the ASTK IDE, as shown in Figure 25.
   
   Figure 25. Create a dynamic Web project
   
   
   
2. Name the Web project MyEJBServiceWebClient, and select defaults for the next two screens, as shown in Figure 26.
   
   Figure 26. MyEJBServiceWebClient
   
   
   
3. Create a reference to the Web service you created in the previous section. In the MyEJBServiceWebClient project, navigate to the Web.xml file, as shown in Figure 27, and double-click to open the Web deployment descriptor editor.
   
   Figure 27. web.xml - Web deployment descriptor file
   
   
   
4. Select the Reference tab, as shown in Figure 28, and click on Add.
   
   Figure 28. Create service reference
   
   
   
5. Select the Service Reference radio button, and click Next. The dialog box, as shown in Figure 29, lists all the Web services available in the IDE workspace. It lists the MyEJB_SEI.wsdl file that you created in the previous section.
   
   Figure 29. Generated Web service reference files
   
   
   
6. Select the WSDL file, and click Finish. This imports the WSDL file and also creates the interface file and associated stub files in the src directory of the Web project, as shown in Figure 29.

Developing the Web services client bindings

You need to tell the Web deployment descriptor about the Web services referenced in this client.

1. Click the WS Binding tab in the Web services client descriptor editor, as shown in Figure 30.
   
   Figure 30. WS binding
   
   
   
2. Click Add. The Web service references in the project are listed.
   
   
3. Select the service/MyEJB_SEIService, as shown in Figure 31, and click OK.
   
   Figure 31. Select service reference
   
   
   
4. Specify the location of the WSDL file. Note that the endpoint URL information in the WSDL need not be defined at this time. In fact, if you look at your WSDL file, the location addresses for the ports are undefined. You will define the endpoint address for each port after deploying the service client application using the administrator console.
   
   
5. From the WS Binding tab under Service Reference Details, browse to the location of the WSDL file in the project, and select the WSDL file MyEJB_SEI.wsdl, as shown in Figure 32.
   
   Figure 32. Service reference details - WSDL file location
   
   
   

   Define the port-qualified name binding. You have three port definitions: one for each protocol of HTTP, JMS, and EJB.

6. Click Add in the Port Qualified Name Binding section. This brings up a dialog window to specify the namespace and the port name. In RAD/RSA 6.0, these are populated automatically. In ASTK 6.1, you need to enter it manually.
   
   
7. Add the following entries, as shown in Figure 33.
   
   Figure 33. Port-qualified name binding
   
   
   

This concludes your Web service client binding definitions.

Creating a servlet

Next, create a servlet to invoke the service. The Web application has a single JSP that provides multiple servlet URL links to pass parameters to invoke the Web service in different ways.

1. Use the servlet creation wizard to create the servlet class WebServiceInvoker, and name it Invoker.
   
   Figure 34. Invoker servlet
   
   
   

   Remember that your Web service exposes an interface using three different mechanisms: HTTP, JMS, and EJB (RMI/IIOP). They are specified in the WSDL file by three different ports: MyEJB_SEI, MyEJB_SEIEjb, and MyEJB_SEIJMS. When getting a reference to the service using JAX-RPC, use the getPort() method.

2. Specify just the service interface class, or call the method with an additional parameter, which is the fully qualified name of the desired port. Note that if you do not specify a port name, a preferred port can be defined in the WebSphere Administration Console. You will see how to define this during the installation of the sample service client application. See the two invocation styles in Figure 35.
   
   Figure 35. getPort() method
   
   
   

   The rest of the servlet code is pretty simple. You can call the servlet in one of four different ways. Each invocation is provided in the index.jsp as a link. The first link retrieves the Web service reference without specifying a fully qualified port name, as shown in Figure 35. Which resulting port is used for the Web service depends on the configuration of the preferred port in the WebSphere Administration Console. The next three links specify the desired port names that are passed to the getPort() method call.

   
   
   Figure 36. Servlet methods
   
   
   
3. Add the doGet()method, which simply invokes the doPost() method.
   
   
4. Create the doPost() and three additional methods, as shown in Figures 37 through 40.
   
   Figure 37. doPost() method
   
   
   
   
   
   Figure 38. locateServiceMethod method
   
   
   
   
   
   Figure 39. invokeViaJAXRPCDynamicProxy method
   
   
   
   
   
   Figure 40. invokeViaJAXRPCDynamicProxyWithQualifiedPortName method
   
   
   

   The project also uses a utility project, MiscUtils, which contains class HtmUtils that offers a utility method to print a response to the servlet request. While this might not follow the best practice in servlet and JSP development, the intent here is to show the JAX-RPC service invocation. See Downloads for the sample code for this article.

5. Include the index.jsp. The source and preview for index.jsp look like Figure 41.
   
   Figure 41. index.jsp
   
   
   
   
   
   Figure 42. index.jsp preview
   
   
   
6. Create an Enterprise Application Archive project, and add the Web client project and MiscUtils project to the EAR, as shown in Figure 43.
   
   Figure 43. Web client EAR
   
   
   
7. Make sure that the MiscUtils.jar file is included in the MyEJBServiceWebClient project's classpath.
   
   
8. Right-click the MyEJBServiceWebClient project, and select Under J2EE Module Dependencies. Make sure that the MiscUtils.jar is checked, as shown in Figure 44.
   
   Figure 44. J2EE module dependencies
   
   
   

You are ready to deploy the service provider and service client applications to WebSphere Application Server. Note that for this example, you will deploy the service provider and client on to the same application server. But, in a real life scenario, you would likely deploy the applications on different application servers.

For this example, you will first deploy the service provider application. After deployment, obtain the WSDL file that contains the endpoint information that will be used during the client deployment. You will use WebSphere Application Server 6.1.

Back to top

Configuring resources for sample service provider application

Before you deploy the sample service provider application to WebSphere Application Server, create a couple of resources. Use WebSphere Administration Console to create the resources as shown in the following steps. Because your Web service also accepts requests using the JMS, you need to create a bus, two queue destinations for incoming and replies, and an activation spec for the message driven bean (MDB).

Creating a bus

1. From the Administration Console, select Service Integration > Buses, and click on New.
   
   
2. Provide a name for the bus, as shown in Figure 45.
   
   Figure 45. Create bus
   
   
   
3. Click Next > Finish > Save.
   
   
4. Navigate back to the bus, and add server1 to the bus as a bus member, as shown in Figure 46.
   
   Figure 46. Add server1 as a member to the bus
   
   
   

Bus security is enabled by default. This requires enabling application security and creating J2C authentication aliases and so on. For this example, disable bus security by navigating to MyBus resource and clicking on Security.

Back to top

Creating a queue destination

Next, create a queue destination called MyEJBServiceQDestination on the bus for the incoming SOAP requests. Do this by navigating to Service integration > Buses > Destinations and creating queue destinations by clicking New and following the directions appropriately. The resulting destination is shown in Figure 48.

Creating a queue connection factory

Before you can create a queue, you need to create a queue connection factory, following these steps:

1. Navigate to Resources > Queue connection factories, select the scope to the server, and click New.
   
   
2. Select the Default messaging provider.
   
   
3. Fill in the other input fields, as shown in Figure 49.
   
   Figure 49. MyQueueQCF - queue connection factory
   
   
   
4. Click OK and Save. Note that the MDB uses the resource reference name jms/WebServicesReplyQCF that can be mapped to the same queue connection factory.

Creating a queue

Next, create a queue that is mapped to the queue destination you already created. Supply the input as shown in Figure 50. Note the JNDI names for the request queue. This is used in identifying the endpoint URL for the port that uses SOAP/JMS in the WSDL file.

Creating an activation specification

Next, create an activation specification to connect your message-driven bean to the queue destination. In the WebSphere Administration console, navigate to Resources > Activation specification. The JNDI name used for the activation specification is MyEJBServiceProject_ActivationSpecJNDIName. You can inspect this from the EJB deployment descriptor for the message-driven bean that was created in the JMS router project. Ensure that you use the same JNDI name here. The values used in creating the activation specification are shown in Figure 51.

Reviewing the configuration

That was a lot of configuration! This section re-caps all the resources you created so far. All the resources you created are shown in Figure 52.

Back to top

Installing the sample service provider application

Use the WebSphere Administration Console to install the application.

1. Export the MyEJBServiceProjectEAR enterprise archive to a temporary work directory.
   
   
2. In the WebSphere Administration Console, navigate to Applications > Install New Applications, and point to the exported EAR file.
   
   
3. Select the check box to deploy Web services, as shown in Figure 53. This is very important when installing applications.
   
   Figure 53. Check deploy web services
   
   
   
4. Click Next to select the server to deploy. The next screen asks to map the jms/WebServicesReplyQCF resource reference to a queue connection factory, as shown in Figure 54. You can use the same queue connection factory that is used for queue destination for service requests (jms/MyQueueQCF).
   
   Figure 54. Map WebServicesReplyQCF
   
   
   
5. Click Next, and save the installation to the master repository.
   
   
6. Define the EJB and JMS endpoint URL information. Do this by navigating to Enterprise Applications > MyEJBServiceProjectEAR >Provide JMS and EJB endpoint URL information, and entering the values in the format, as shown in Figure 55. The EJB URL Fragment is jndiProviderURL=corbaloc:iiop:<hostname>:2809. The JMS URL Fragment is jms:/queue?destination=jms/MyEJBServiceQ&connectionFactory=jms/MyQueueQCF.
   
   Figure 55. EJB and JMS URL endpoint definition
   
   
   
7. Click OK and Save. Navigate back to the Enterprise Application. On the application page, there is a Publish WSDL link, as shown in Figure 58.
   
   Figure 56. Publish WSDL screen
   
   
   
8. Use the Publish WSDL link to obtain the WSDL files for the Web service application that will contain the endpoints for all the bindings. The WSDL file is provided in zip format. Open the zip file to inspect the WSDL that will include the active endpoints for this Web service application. This file is typically used to determine the endpoints that need to be configured during the service client installation. See the WSDL file in Figure 57 that now shows the complete URL from the fragment URL that you previously defined. Note that Publish WSDL shows two WSDL files, one of which is suffixed with Extended. This Extended WSDL file includes the EJB bindings.
   
   Figure 57. Endpoint URL
   
   
   
9. Start the application from the WebSphere Administration Console. Restarting the server at this point is recommended because of the newly created resources on the server.
   
   
10. Ping the HTTP router URL to see if the Web service is active after the server and the application are started. Type the URL and see if it responds with the page shown in Figure 58.
    
    Figure 58. Ping Web service
    
    
    

So you are done deploying the service provider application. You are ready to install your client application.

Back to top

Installing the sample service client application

1. Export the client application MyEJBServiceWebClientEAR to a temporary work directory.
   
   
2. In the WebSphere Administration Console, navigate to Applications > Install New Application, select the exported EAR for installing, and click Next. Note that you are deploying the client to the same server. In a real-life scenario, you might use different servers.
   
   
3. Accept the defaults in this straightforward installation.
   
   
4. Click Next, and click Finish to complete the service client application installation.

Back to top

Configuring for service location transparency

1. Configure the Web service client bindings after installing to specify the correct endpoint URL address for the target service. Remember that currently your WSDL has an undefined location address. You can obtain the target service endpoint address from the Publish WSDL file that you retrieved after you deployed your service provider application, as shown in Figure 59.
   
   Figure 59. Web service client bindings
   
   
   
2. Navigate to the installed application.
   
   
3. Click the application link, and click Manage Modules.
   
   
4. Click the Web module, and click the Web services client bindings under Web services properties, as shown in Figure 59.
   
   
5. Click Edit under Port Information. This brings up the three ports that you have in your WSDL. Here, you can define the actual endpoint URL address for each of the three ports, as shown in Figure 60. This is a good way to externalize the target service endpoint URL information from the client application. If the target service address changes, you can easily point the client application to the new service endpoint. This external configuration provides location transparency to your client application.
   
   Figure 60. Location transparency
   
   
   
6. Start the application, and type the following URL to access the Web service client Web application: http://<hostname>:9080/MyEJBServiceWebClient
   
   
7. Click on links 3 to 4 to test service invocation using different port names, each of which uses a different protocol. Clicking on link 1 uses a default port, and it might pick one of the protocols. To ensure the desired port protocol is used, configure the preferred port in the Web services client binding configuration in the WebSphere Administration Console. This is described in the next section.

Back to top

Configuring for protocol transparency

1. Navigate to the Web service client bindings page of the Web service client application in the WebSphere Administration Console.
   
   
2. Click Edit under Preferred Port Mapping, as shown in Figure 61.
   
   Figure 61. Protocol (port) transparency
   
   
   This shows the referenced Web service with a drop-down list of ports available for the Web service.
   
   
3. Select the desired port, and click Apply.
   
   
4. Save the changes and re-start the Web client application.
   
   
5. Access the Web client application, and invoke the Web service using the first link. Notice that the invocation occurs with the selected port. This can be verified by the service class name printed with the invocation message.

This concludes your sample application demonstration.

Back to top

Accomplishing location and protocol transparency using WebSphere ESB and WebSphere Service Registry and Repository

Location and transport transparency are part of the built-in features of these two products. Using WebSphere ESB and WebSphere Service Registry and Repository (WSRR) is the preferred mechanism to achieve transparency. Version 6.0.2 of the WebSphere ESB product provides a WSRR mediation primitive to lookup the endpoint address of a target service provider at run time. You can override this endpoint using a custom mediation primitive. Additionally, the administrator can change this endpoint using the administration console. See the Resources section for more details.

WebSphere ESB is a leading Enterprise Service Bus product from IBM. It provides location, protocol, and a number of mediation capabilities. You can easily migrate the techniques shown in this article to a more robust SOA environment using WebSphere ESB.

Back to top

Summary

This article discussed how to decouple the service provider from the service client consumer with late binding and location transparency using a JAX-RPC programming model. It also discussed the multiprotocol support for a WebSphere JAX-RPC implementation, which can provide additional quality of service to service implementations. A sample application was developed and deployed to demonstrate protocol and service location transparency. You can easily migrate the techniques demonstrated to a more robust SOA implementation using an enterprise service bus.

Back to top

Acknowledgment

The authors would like to acknowledge Greg Flurry, IBM SOA Advanced Technology, for taking time from his busy schedule to provide valuable feedback for this article.

Back to top

Downloads

Information about download methods

Resources

Learn

• Refer to the WebSphere ESB documentation for more information about the WebSphere Administration Console.
  
  
• Check out the JAX-RPC specification at JSR 101.
  
  
• See JAX-RPC vs JAX-WS for more information about these programming models.
  
  
• Refer to the WebSphere Information Center to learn about using WSDL EJB bindings.
  
  
• Get more information from WebSphere Version 6 - Web Service Handbook Development and Deployment in the IBM Redbooks series.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Check out a quick Web services on demand demo.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you to get there.
  
  
• Visit the SOA and Web services zone on developerWorks to learn more about SOA.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  
• Collaborate with a community of architects and developers in the SOA and Web services discussion forums.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Understanding the service consumer and service provider
• Understanding JAX-RPC
• Introducing JAX-RPC client types
• Invoking multiprotocol Web services
• Introducing the sample demonstration
• Developing the sample service provider application
• Developing the sample service client application
• Configuring resources for sample service provider application
• Creating a queue destination
• Installing the sample service provider application
• Installing the sample service client application
• Configuring for service location transparency
• Configuring for protocol transparency
• Accomplishing location and protocol transparency using WebSphere ESB and WebSphere Service Registry and Repository
• Summary
• Acknowledgment
• Downloads
• Resources
• About the authors
• Comments

Next steps from IBM

With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
• Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
• Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers