Introduction

This article shows you how to implement the new provider endpoint workaround for WS-Security specification-level interoperability problems. The approach involves packaging the J2EE 1.4 provider application with two Web service endpoints: One provides service for J2EE 1.3 consumers, and one provides service for J2EE 1.4 consumers. Implementing this workaround is a basic programming and packaging exercise, requiring no additional middleware infrastructure. This approach scales well when there's a large number of Web service consumer applications.

After you add the new provider endpoint to the Web service application, any number of J2EE 1.3 Web service consumer applications can use it. An important note: This approach is best used when the Web service implementation classes are simple JavaBeans or Enterprise JavaBeans (EJBs). If the Web service implementation logic is contained in a servlet, in a Service Component Architecture (SCA) component, or in an Enterprise Service Bus (ESB) mediation module, then it's more difficult to create the servlet 2.2 (J2EE 1.3) Web project and package it with the Web service provider application.

The effort required to implement this approach is primarily application development work, although this workaround introduces another Web service endpoint that must be secured and managed by the operations team. In addition to application developers, this approach also requires testers and deployment personnel to be involved.

This article assumes that the application developers who will implement this approach have basic J2EE and Web services development skills.

This article describes in detail how to implement the new provider endpoint approach using a fully implemented example that you can deploy in your environment. The Solution overview section describes the approach in detail; the Build the solution section walks you though the implementation tasks showing how the provided sample applications were developed; and the Work with the sample application section describes how to customize and run the sample applications in your runtime environment.

Back to top

Solution overview

Figure 1 shows a detailed runtime view of the new provider endpoint workaround. The J2EE 1.3 client application communicates with the J2EE 1.3 Web service endpoint application using Web services and the WS-Security draft 13 specification. The J2EE 1.4 client application communicates with the J2EE 1.4 Web service endpoint application using Web services and the WS-Security version 1.0 specification. Then the Web service endpoint applications instantiate J2EE 1.4 Web service classes included in the shared library, which in turn makes RMI/IIOP call to the back-end EJB.

In general, we assume that you're trying to add a new J2EE 1.3 client and provider endpoint to your existing J2EE 1.4 provider. The J2EE 1.4 provider application includes an EJB that contains the business logic. In Figure 1, the beige boxes represent existing J2EE 1.4 components, and the pink boxes represent new components, which this article shows how to create and integrate with the J2EE 1.4 provider application EAR file.

Table 1 shows the required tasks and products to create the solution.

The implementation of task 1 involves using the appropriate wizards in Rational Application Developer to create J2EE 1.3 and J2EE 1.4 Web service endpoints and a shared library. (Find a detailed example of this in the following Build the solution section.)

Deployment of the solution (task 7) requires that the following applications be deployed:

• Client applications
• Provider application, which includes the following:
  • The J2EE 1.3 and J2EE 1.4 Web service endpoints
  • The shared library
  • The back-end EJB containing the business logic for the Web service

Back to top

Build the solution

This section describes how to modify a J2EE 1.4 Web service provider application so that it can be used with J2EE 1.3 and J2EE 1.4 clients. The Listing 1 code snippets are taken from the sample applications and are provided so you can see how to apply this approach to your own applications. Table 2 illustrates the tasks required.

Task 1: Create the J2EE 1.3 Web service endpoint and shared library

This section explains the basic steps required to create the J2EE 1.3 and the shared library. (See the Resources section for links to additional information for Web services client-related operations and basic Rational Application Developer wizards to implement the following steps.)

1. Create a new J2EE 1.3 skeleton Java bean Web service from an existing WSDL using the Web Service Wizard. Provide the following on the Service Deployment Configuration panel:
   1. Select 1.3 as the J2EE version.
   2. Provide a new Web project as a service project, and provide a new EAR project.
2. Create a Java project, which is used as a shared library using the Java Project wizard that Rational Application Developer provides.

Task 2: Modify the J2EE 1.3 Web service endpoint

You're ready to perform this step after completing task 1 as shown in the Table 2. This section explains the required updates to the J2EE 1.3 Web service endpoint. (See Resources for links to additional information about basic Rational Application Developer operations to implement the steps below.)

1. Delete the J2EE 1.3 Web service's EAR project from your UTE, because Rational Application Developer automatically deploys the Web service EAR projects to the UTE upon their creation.
2. Remove the J2EE 1.3 Web service's Web project from its EAR file using the following instructions:
   1. In the J2EE 1.3 Web service EAR project, open the META-INF/application.xml file.
   2. Click the Module tab, and click the Modules twisty.
   3. Select the .war file for the J2EE 1.3 Web service's Web project, then click Remove.
   4. Save the application.xml file.
3. Delete the J2EE 1.3 Web service's EAR project from your Rational Application Developer workspace.
4. Add the J2EE 1.3 Web service's Web project to the existing J2EE 1.4 Web service's EAR file by doing the following:
   1. In the existing J2EE 1.4 skeleton Java bean Web service EAR project, open the META-INF/application.xml file.
   2. Click the Module tab, and click the Modules twisty.
   3. Click Add.
   4. Select the Web project for the J2EE 1.3 endpoint, then click Finish.
   5. Save the META-INF/application.xml file.
5. Modify the webservices.xml file, located in the Web project of the J2EE 1.3 Web services, so that the Service endpoint interface on the Port Component tab matches the one specified in the webservices.xml file of the existing J2EE 1.4 Web project. To implement this, do the following:
   1. In the J2EE 1.3 Web services Web project, open the webservices.xml file.
   2. Click the Port Components tab, and click the Port component implementation details twisty.
   3. Update the Service endpoint interface from *_Port to *_PortType.
   4. Save the webservices.xml file.
6. Delete all of the generated Web service classes under the JavaSource directory of the J2EE 1.3 Web project.

Task 3: Wire the shared library to the J2EE 1.3 and J2EE 1.4 Web service endpoints

This section explains the required steps to wire the shared library, which is a Java project, with J2EE 1.3 and J2EE 1.4 Web service endpoints. (See Resources for links to additional information for basic Rational Application Developer operations to implement the steps below.)

1. Add the Java project to the J2EE 1.4 EAR file as a utility library by doing the following:
   1. In the J2EE 1.4 skeleton Java bean Web service EAR project, open the META-INF/application.xml file.
   2. Click the Module tab, and click the Project Utility JARs twisty.
   3. Click Add.
2. The J2EE 1.3 and J2EE 1.4 endpoint applications need to access J2EE 1.4 Web service classes using the shared library. So now you need to move all of the generated Web service code under the JavaSource directory of the J2EE 1.4 Web project to the shared library's Java project. Here's the list of files to be moved:
   • A Java class for each complex data type. Related class name for your sample application is SampleOperationResponse.
   • A serializer, deserializer, and a helper class for each complex data type, *_Ser, *_Deser, and *_Helper, respectively. Related class names for your sample application are SampleOperationResponse_Ser, SampleOperationResponse_Deser and SampleOperationResponse_Helper.
   • A service interface and its implementation, *_PortType and *SOAPImpl, respectively. Related class names for your sample application are SampleService_PortType and SampleServiceSOAPImpl.

   Figure 2 shows the files you relocated for the sample application.

   
   
   Figure 2. Relocated files
   
   
   
3. J2EE 1.3 and J2EE 1.4 endpoint applications need to be aware of the Web service classes in a dependent JAR file. So add the Java project as a JAR dependency to both the J2EE 1.3 and J2EE 1.4 Web projects by doing the following:
   1. In the J2EE 1.4 skeleton Java bean Web service EAR project, open the META-INF/application.xml file.
   2. Click the Module tab, and click the Project Utility JARs twisty.
   3. Click Add, and select the Java project.
   4. Click Finish, and save the application.xml file.
   5. Implement the following instructions for each of the J2EE 1.3 and J2EE 1.4 Web service Web projects:
      • Go to the appropriate Web project, highlight it, and right-click it.
      • Click Properties > Java JAR Dependencies.
      • On Java JAR Dependencies, select the Java project.
      • Click OK.

Task 4: Wire the back-end EJB to the shared library and the J2EE 1.3 and J2EE 1.4 Web service endpoints

This section explains the steps required to wire the back-end EJB with the shared library and the J2EE 1.3 and J2EE 1.4 Web service endpoints.

1. Add the J2EE 1.4 EJB and EJBClient.jar file to the J2EE 1.4 EAR file by doing the following:
   1. In the J2EE 1.4 skeleton Java bean Web service EAR project, open the META-INF/application.xml file.
   2. Click the Module tab, and click the Modules twisty.
   3. Click Add.
   4. Select the EJB project, and click Finish.
   5. If the EJBClient.jar file isn't included in the Project Utility JARs twisty, then follow the instructions below:
      1. Click the Module tab, and click the Project Utility JARs twisty.
      2. Click Add.
      3. Select the EJB client project, and click Finish.
   6. Save the changes you made to the application.xml file.
2. Add the J2EE 1.4 EJBClient.jar file as a JAR dependency to the shared libraries Java project by doing the following:
   1. Go to your Java project, highlight it, and right-click it.
   2. Click Properties > Java JAR Dependencies.
   3. On the Java JAR Dependencies, select the EJB client project.
   4. Check the appropriate JAR/Module, and click OK.
3. Edit the SOAPImpl class of the shared libraries Java project, and add the code necessary to invoke the J2EE 1.4 back-end EJB. The steps below show the use of the EJB Snippets feature, which inserts code to call the back-end EJB:
   1. Go to J2EE perspective.
   2. Open the SampleServiceSOAPImp.java file.
   3. Place the cursor in the file.
   4. Click the Snippets tab on the bottom left.
   5. Expand the EJB drawer.
   6. Double-click Call an EJB create method.
   7. Select an appropriate EJB session bean in the Select EJB Reference Owner panel, then click Next.
   8. Click New EJB Reference in the Select Reference panel.
   9. Select the EJB session bean in the EJB Reference panel.
   10. Choose Local for the Ref Type. If your back-end EJB doesn't contain local interfaces, follow the optional task below to add them into your back-end EJB.
   11. Click Finish on the EJB Reference, then click Finish on the Select Reference panel.
   12. Manually add the necessary code into the generated code to work with your back-end EJB. The code snippet in Listing 1 shows a sample for the generated and manually added code.
       
       Listing 1. Web service implementation class snippet
       

       package com.test; import com.ibm.etools.service.locator.ServiceLocatorManager; import com.test.sessionbean.SampleEJBLocalHome; import com.test.sessionbean.SampleEJBLocal; public class SampleServiceSOAPImpl implements com.test.SampleService_PortType { private final static String STATIC_SampleEJBLocalHome_REF_NAME = "ejb/SampleEJB"; private final static Class STATIC_SampleEJBLocalHome_CLASS = SampleEJBLocalHome.class; public com.test.SampleOperationResponse sampleOperation(java.lang.String sampleOperationRequest) throws java.rmi.RemoteException { SampleEJBLocal aSampleEJBLocal = createSampleEJBLocal(); /********************************************************************************/ /* Begin manually added code to work with the sample back-end EJB */ /********************************************************************************/ SampleOperationResponse sampleOperationResponse = new SampleOperationResponse(); sampleOperationResponse .setServiceResponseString("Request string was: " + sampleOperationRequest); sampleOperationResponse .setServiceUserName("Caller is " + anEJBBBackendLocal.getCallerName()); return sampleOperationResponse; /********************************************************************************/ /* End of manually added code */ /********************************************************************************/ } protected SampleEJBLocal createSampleEJBLocal() { SampleEJBLocalHome aSampleEJBLocalHome = (SampleEJBLocalHome) ServiceLocatorManager .getLocalHome(STATIC_SampleEJBLocalHome_REF_NAME, STATIC_SampleEJBLocalHome_CLASS); try { if (aSampleEJBLocalHome != null) return aSampleEJBLocalHome.create(); } catch (javax.ejb.CreateException ce) { // TODO Auto-generated catch block ce.printStackTrace(); } return null; } }

       
       
4. Follow the instructions below to add the Local home interface and Local interface classes into your EJB client project.
   1. In the back-end EJB project, open the META-INF/ejb-jar.xml file.
   2. Click the Bean tab, and highlight an appropriate bean.
   3. Click the Class and Interface Files twisty, then click Add.
   4. In the Add Client View panel, check Add new local and local interfaces.
   5. Click Finish.
   6. Save the META-INF/ejb-jar.xml file.
   7. Now you can promote the related back-end EJB method into Local.
5. The last step to implement this task is to edit the web.xml file of the J2EE 1.3 and J2EE 1.4 Web projects to add the EJB resource reference used by the *SOAPImpl class located in the shared library:
   1. Open the WEB-INF/web.xml file.
   2. Click the References tab, then click Add.
   3. Select the EJB reference in the Add Reference panel, and click Next.
   4. On the Add String for Web EJB reference panel, find and highlight the session bean.
   5. Make sure that the Ref Type is Local.
   6. Click Finish, and save the web.xml file.

Task 5: Integrate the J2EE 1.3 client application with the new J2EE 1.3 provider endpoint

To implement this step:

• See Part 3 in this series for detailed explanations about how to integrate a Web service client into your client application. The article demonstrates integrating a Web service client into a session bean. You can adopt the same integration technique into your client application.
• See the WebSphere Application Server Information Center and WebSphere Version 6 Web Services Handbook Development and Deployment links in Resources for detailed explanations about implementing this step.

Task 6: Add the security

See the WebSphere Application Server Information Center and WebSphere Version 6 Web Services Handbook Development and Deployment links in Resources for detailed explanations about implementing this step.

Task 7: Deploy and unit test the solution on your runtime environment

See the Rational Application Developer product help link in Resources for detailed explanations to implement this step.

Back to top

Work with the sample application

This section explains how to deploy the fully implemented sample applications into your runtime environment. To deploy the samples, you need WebSphere Application Server V6.0 or later to run the provider application. The runtime environment should be configured to use global security and to use Lightweight Third Party Authentication (LTPA) authentication with the same LTPA key.

The first step for working with the sample application is to download the files provided in Download section. They are:

• SampleProjects.zip, which includes source code of the sample applications.
• SampleService.ear, which is the deployable archive file for the provider application.
• SampleClient.ear, which is the deployable archive file for the J2EE 1.3 client application.

You're ready to take either of the following actions after downloading the provided files:

• Run the client and the provider application on remote WebSphere Application Server systems, as shown in Figure 1. Follow tasks one through six to customize and run the sample applications remotely, as shown in the list below.
• Run the client and the provider application locally on the same WebSphere Application Server system. Skip tasks one through three, and follow tasks four through six, as shown in the list below.

To run the sample applications either locally or remotely, you must perform the following tasks:

1. Import the source code of the sample applications into a Rational Application Developer workspace.
2. Update the necessary source files to reflect the host names of your runtime environment.
3. Package the solution components.
4. Deploy the applications into the runtime environment.
5. Configure the security in WebSphere Application Server.
6. Run the sample applications.

The rest of this section describes these tasks in detail.

Task 1: Import the source code of the sample applications

The source code for the sample applications, which are composed of various artifacts shown in Table 3, is contained in the SampleProjects.zip file (see the Download section). We used the Project Interchange export feature of Rational Application Developer to export the source code of the solution into the SampleProjects.zip file. This feature helps you import the source code into another Rational Application Developer workspace easily; here's how:

1. Click File > Import, and select Project Interchange.
2. Click Next, provide the location of the compressed file, then select the provided projects.

Tasks 2 - 4: Update, package, and deploy the sample solution into the runtime environment

Perform the following steps:

1. The source code of the client application must be customized to reflect the host names of your runtime environment. Provide a host name in two of the files, as shown in the following list. As a convenience, look for the localhost string, and replace it with an appropriate host name.
   • The locater class located in the SampleClient project, com.test.SampleService_ServiceLocator.java
   • The WSDL file located in the META-INF/wsdl directory of the SampleClient project, sampleService.wsdl
2. After customizing the required files, you're ready to create a deployable package for the servlet. Deploy the provided SampleService.ear file for the Web services provider application into WebSphere Application Server, as well as the servlet for the client, SampleClient.ear.

Task 5. Run the sample solution

You're now ready to run the solution by following these steps:

1. Run the J2EE 1.3 servlet, which displays the input page, as shown in Figure 3.
2. When you're challenged to authenticate to the servlet, authenticate using any user ID that's a part of the registry used for global security.
3. Provide an input string in the field displayed on the page, then click the Send button.
   
   Figure 3. Input page
   
   
   

   The servlet calls the J2EE 1.3 Web service endpoint with the input string to be provided to the back-end EJB. It then displays the result returned from the back-end EJB on an output page, as shown in Figure 4:

   
   
   Figure 4. Output page
   
   
   

   The user ID displayed on the output page should be the same one you used to authenticate to the servlet. If this is the case, then you can be confident that the client user identity is being successfully propagated to the provider application using WS-Security.

Back to top

Conclusion

This article walked you through how to use multiple Web service endpoints to deal with the WS-Security specification level interoperability issue and provided examples showing how to deal with some of the pitfalls around working with common Web services classes. As you learned, this method is primarily a straightforward application development exercise. This approach is best suited to sandbox, test, or proof-of-concept situations in which upgrading Web services consumer applications to J2EE 1.4 is not an option, and in which the cost of setting up a middleware proxy is prohibitive.

Back to top

Downloads

Information about download methods

Resources

Learn

• Check out the other articles in this series:
  • "Part 1: Problem overview and four available workarounds" (developerworks, May 2007) introduces some of the common problems caused by incompatibilities between different versions of the WS-Security specification. It also presents some solutions to these problems and compares the benefits and drawbacks of each.
  • "Part 2: Using the WebSphere Web Services Gateway feature" (developerWorks, July 2007) shows you how to use the Web Services Gateway as a secure proxy between a J2EE 1.3 Web service consumer and a J2EE 1.4 Web service provider application.
  • "Part 3: Using the EJB Proxy" (developerWorks, September 2007) provides detailed explanations about how to integrate a Web service client into your client application and demonstrates how to integrate a Web service client into a session bean.
  
  
• Visit the WebSphere Application Server Information Center for information about:
  • EJB concepts.
  • Deployment of EAR files.
  • Web services and security concepts.
  
  
• IBM Redbooks®: WebSphere Version 6 Web Services Handbook Development and Deployment provides a good source of information to Web services application concepts and features.
  
  
• Read Step 2 in the article "Web services security with WebSphere Application Server V6 -- Part 4" (developerWorks, July 2006) for centralized information about how to secure a Web service using the LTPA token.
  
  
• Visit the Rational Application Developer product help, which provides information about the following topics:
  • Java integrated development environment concepts
  • EJB development and concepts
  • Web services development and concepts
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
  • Get started on SOA with WebSphere's proven, flexible entry points
  • Building SOA solutions and managing the service lifecycle
  • SCA/SDO: To drive the next generation of SOA
  • SOA reuse and connectivity
  
  
• Check out the developerWorks SOA development and best practices community space.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.
  
  
• Get an RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Download free trial versions of WebSphere Application Server and Rational Application Developer.
  
  
• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs, including the following SOA and Web services-related blogs:
  • Service Oriented Architecture -- Off the Record with Sandy Carter
  • Best Practices in Service-Oriented Architecture with Ali Arsanjani
  • WebSphere SOA and J2EE in Practice with Bobby Woolf
  • Building SOA applications with patterns with Dr. Eoin Lane
  • Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
  • Service-Oriented Architecture and Business-Level Tooling with Simon Johnston
  • SOA, ESB and Beyond with Sanjay Bose
  • SOA, Innovations, Technologies, Trends...and a little fun with Mark Colan
  
  

About the authors

David Leigh is a Senior Software Engineer in IBM Software Group's Scenario Analysis Lab organization, located in Research Triangle Park, North Carolina. His areas of expertise include IBM WebSphere Process Choreographer, application and server security, high availability, monitoring, IBM AIX®, and Linux®.

Zeynep Latif is a software engineer in IBM Software Group's Scenario Analysis Lab organization, located in Research Triangle Park, NC. Her areas of expertise include portlet and J2EE application development, IBM Rational Application Developer, and IBM Rational Software Architect for application design.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Solution overview
• Build the solution
• Work with the sample application
• Conclusion
• 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.
• Demo: Watch this demo and learn how to configure and use the WebSphere Application Server and the Eclipse IDE with the Web Tool Project Platform.
• Buy: WebSphere Application Server

Dig deeper into Java on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers