Part 1 of this article series develops and tests an integration module in which a Service Component Architecture (SCA) component imports and invokes an Enterprise JavaBean (EJB) component using IBM® WebSphere® Integration Developer and the integrated WebSphere Process Server test environment. Since the publication of this article, readers submitted inquiries asking how to invoke existing Enterprise JavaBeans that are not running in the same application server or Java™ Virtual Machine (JVM) as the calling SCA components. This article discusses the approaches and requirements to address these questions, which are based on very legitimate, real-life scenario situations.
You are encouraged to read Part 1 of this series, Integrate EJB services with WebSphere Process Server, before beginning this article.
An outline of how the solutions appear when deployed in various environments provides you with the big picture of what you'll learn in this article.
The diagram in Figure 1 gives you a clear idea of what was accomplished in Part 1 of this series from a runtime point of view.
Figure 1. Coexisting in the same server
This article shows you how to enhance and deploy the existing application and test it in the two runtime topologies.
Advanced scenario 1
In this scenario, you add an index.jsp to the existing application to facilitate the test. You deploy the solution to a WebSphere Process Server V6 cell that consists of two
existing servers: server1 and server2. You will then deploy the
InvokeEcho SCA module to the servers, while server2 hosts the Echo EJB services.
Figure 2. Coexisting in different servers of the same cell
Advanced scenario 2
In Advanced scenario 2, the Echo EJB service is being moved to another WebSphere cell (WebSphere Application Server V5.1 cell); this is the major difference between Advanced scenario 1 and this scenario.
Figure 3. Existing in different servers of different cells
Enhance the existing applications
Setting up the workspace
- Start WebSphere Integration Developer. Open a new workspace and close the welcome screen.
- Right-click anywhere inside the Business Integration view and choose Import to import the Project Interchange that you downloaded.
Select Project Interchange and click Next.
Figure 4. Import Project Interchange
- Select the downloaded file, $Download_root/importEJB_PI.zip, then click Select All and Finish.
Figure 5. Select the required projects
Examing the existing artifacts
- Once the import completes, switch to the Java perspective. Notice that the following projects imported, see Figure 6.
Figure 6. Imported projects
- Switch to the Business Integration perspective and expand the InvokeEcho project. Select and double-click to open the module, InvokeEcho, in the assembly editor, see Figure 7.
Figure 7. InvokeEcho module detail
- Compare this diagram with the one you used in the previous article. Notice that we added a Stand-alone reference. We did this because we need a way to invoke the SCA module when testing in WebSphere Process Server environment. For details on adding and using a stand-alone reference, please refer to the Resources section of this article.
- Select the Stand-alone References in the diagram. From the Properties view, expand References and select InvokeEchoInterfacePartner to examine the detail. Notice the name of the stand-alone reference has been set to InvokeEchoInterfacePartner. This is the name that is used later in the Java snippet of the client JSP.
Figure 8. Reference detail
- Switch to the J2EE perspective and expand Dynamic Web Projects => InvokeEchoWeb => WebContent. Notice that we also added one index.jsp file.
Figure 9. SCA Invoker JSP
- Double-click index.jsp. When the JSP editor opens, select the Source tab and examine the following code, see Figure 10.
Figure 10. SCA Invoker JSP Detail
Testing the applications
- From the Server view, right-click on WebSphere Process Server V6.0 and select Add and remove projects from the context menu.
- In the following window, add the applications Echo and InvokeEchoApp to the configured projects list and click Finish.
Figure 11. Add the projects
- Right-click on the index.jsp from the context menu and select Run => Run on Server.
- After the page loads, enter any string in the text field, and click Submit. You see the response right below the button. If you see this result, you have successfully finished the round trip call from index.jsp to the InvokeEcho SCA component, which in turn, calls to the Echo EJB.
Figure 12. Testing the module
Modifying the JNDI names
- From the Business Integration perspective, open the InvokeEcho module again in the Assembly diagram, select the EchoEJB component in the Properties view, and select the Binding tab. You should see the same results as in Figure 13.
Figure 13. Original JNDI Name
- Change the JNDI name from ejb/com/ibm/issw/poc/invokeejb/EchoHome to cell/persistent/echo, which is the name we use when we configure the name space binding later.
Figure 14. Modified JNDI Name
- Save the changes and close the Assembly Editor.
Export the applications
Our solution consists of two parts: one for the SCA module, and one for the EJB service.
Exporting the SCA module
To export the SCA module:
- From the Business Integration perspective, select the InvokeEcho module, right-click and select Export from the context menu.
- In the export wizard, make sure to select Integration Module and click Next.
Figure 15. Export Module 1
- Select the InvokeEcho module for deployment on WebSphere Process Server, see Figure 16.
Figure 16. Export Module 2
- Browse to the target directory (see Figure 17). Choose InvokeEchoApp.ear as the target file name.
Figure 17. Export Module 3
Exporting the EJB
- From the J2EE perspective, expand Enterprise Applications, select Echo, and right-click to select Export... => EAR File.
Figure 18. Export EJB 1
- Select the target directory and choose Echo.ear as the target file name. Click Finish.
Figure 19. Export EJB 2
Deploy the applications to Advanced scenario 1
Getting the servers ready
- Start the WebSphere Process Server Deployment Manager and the Node Agent.
- Open the Admin console. This scenario uses: http:/192.168.142.133:9060/ibm/console.
- Login and expand Servers => Application Servers. See figure Figure 20 to check your results.
Figure 20. Two servers in the same cell
In Advanced scenario 1, we have two servers in a WebSphere Process Server cell, refer to Figure 2 for the topology. We will deploy InvokeEchoApp.ear to server1, and Echo.ear will be deployed to server2.
Installing the InvokeEcho Module
- Browse to find the InvokeEchoApp.ear from local file system where you exported to in previous step.
Figure 21. Install Module 1
- Select the target server server1 where this application will be installed and click Apply. Click Finish.
Figure 22. Install Module 2
Installing the Echo EJB
- Use the normal procedure to install the Echo.ear file. Make sure to select server2 as target server.
Figure 23. Install EJB 1
Click Next. Notice that the JNDI name for the EJB is com/ibm/issw/poc/invokeejb/EchoHome.
Figure 24. Install EJB 2
Configuring the Name Space Binding
- From the WebSphere admin console (left navigation), expand Environment => Naming, and click on Name Space Bindings.
Figure 25. Configure Name Space 1
- Select Cell scope and click New.
- Select EJB as the Binding type and click Next.
Figure 26. Configure Name Space 2
- Specify echo in the field Name in Naming Space, which will point to the Echo EJB we deployed to server2. Also notice the full JNDI name is ejb/com/ibm/issw/poc/invokeejb/EchoHome, which matches the EJB JNDI name specified at Installing Echo EJB.
Figure 27. Configure Name Space 3
- Use cell/persistent/echo, which is exactly what we referenced in our EJB import component to define a cell level naming binding echo.
Figure 28. Configure Name Space 4
Testing Advanced scenario 1
You'll need to restart both servers to pick up the name space changes. After the servers come up, point your browser to the index.jsp. This article uses: http:/192.168.142.133:9080/InvokeEchoWeb/index.jsp
Put any string in the test field and click Submit. You should see the output from the browser.
Figure 29. Two servers in one cell test
Here is the output from server1, indicating the InvokeEcho SCA module is running:
Listing 1. Sample output from server1
[3/14/06 0:07:25:438 EST] 00000070 ApplicationMg A WSVR0221I: Application started: InvokeEchoApp [3/14/06 0:07:53:047 EST] 00000060 ServletWrappe A SRVE0242I: [/index.jsp]: Initialization successful. [3/14/06 0:07:53:516 EST] 00000063 WebContainer E SRVE0017W: A WebGroup/Virtual Host to handle /favicon.ico has not been defined. [3/14/06 0:08:08:969 EST] 00000060 SystemOut O Inside SCA Componnent InvokeEchoImpl-->callEcho2() [3/14/06 0:08:10:172 EST] 00000060 SystemOut O Inside SCA Componnet InvokeEchoImpl, EJB response is Hello, Peter
Here is the output from server2, indicating the Echo EJB service has been invoked:
Listing 2. Sample output from server2
[3/14/06 0:07:05:141 EST] 0000003b SibMessage I [:] CWSID0020I: The messaging engine configuration reload is complete. [3/14/06 0:08:10:141 EST] 00000069 SystemOut O Inside EJB EchoBean -->echoSimple()
Deploy the applications to Advanced scenario 2
In this scenario, you move the Echo.ear, install, and test it in WebSphere Application Server V5.1.
Getting the WebSphere Application Server V5.1 environment ready
- Start server1 in a WebSphere Application Server V5.1 installation.
- Open the admin console. For this article, we use: http:/192.168.142.1:9090/admin.
- From the left navigation tree, expand Applications and select Install Application. Follow the normal procedure to install Echo.ear. Make sure to check Deploy EJB, see Figure 30.
Figure 30. Deploy the EJB in WebSphere Application Server V5.1
Configuring the Name Space Binding
Now, you need to configure the name space binding configuration again.
- Open the WebSphere Process Server V6 admin console; this article uses: http:/192.168.142.133:9060/ibm/console.
- From the WebSphere Process Server admin console (left navigation), expand Environment => Naming and click on Name Space Binding. Delete the name space binding that you configured in Advanced scenario 1. You need to do this because Advanced scenario 2 will use the same name space identifier echo.
- After saving the change, click New.
Figure 31. Configure Name Space 1
- Select CORBA as the binding type and Click Next.
Figure 32. Configure Name Space 2
- Specify echo as the Name in Name Space field, but use corbaname:iiop:192.168.142.1:2809/NameServiceServerRoot#ejb/com/ibm/issw/poc/invokeejb/EchoHome in the Corbaname URL field. Here we are pointing to the the EJB running inside a WebSphere V5.1 server. You can actually use this type of connection string to communicate with any application server supporting the corbaname URL.
Figure 33. Configure Name Space 3
- Click Next and Finish in the summary page. You will see the following cell level naming binding echo -- but this time, it is a CORBA type. To access this resource, use cell/persistent/echo, which is exactly what we referenced in our EJB import component.
Figure 34. Configure Name Space 4
Testing Advanced scenario 2
It's time to test once again. Restart the servers and point your browser to the index.jsp file (as you did in Advanced scenario 1). Type any string in. See Figure 35 for the results.
Figure 35. Two cells test
Here is the output from the WebSphere V6 server1, indicating the InvokeEcho SCA module is running:
Listing 3. Sample output from server1 in WebSphere 6
[3/20/06 12:45:39:891 EST] 00000052 ServletWrappe A SRVE0242I: [/index.jsp]: Initialization successful. [3/20/06 12:45:40:141 EST] 00000052 WebContainer E SRVE0017W: A WebGroup/Virtual Host to handle /favicon.ico has not been defined. [3/20/06 12:46:21:969 EST] 00000052 SystemOut O Inside SCA Componnent InvokeEchoImpl-->callEcho2() [3/20/06 12:48:15:938 EST] 00000052 SystemOut O Inside SCA Componnet InvokeEchoImpl, EJB response is Hello, Ayden
Here is the output from the WebSphere V5.1 server1, indicating the Echo EJB service has been invoked:
Listing 4. Sample output from server1 in WebSphere 5.1
[3/20/06 11:50:46:983 EST] 5d1a6e3e WebGroup I SRVE0180I: [adminconsole] [/admin] [Servlet.LOG]: /secure/layouts/customLayout.jsp: init [3/20/06 11:50:47:184 EST] 5d1a6e3e WebGroup I SRVE0180I: [adminconsole] [/admin] [Servlet.LOG]: /com.ibm.ws.console.servermanagement/serverindex/namedEndPoint.jsp: init [3/20/06 12:50:12:791 EST] 73e1ee39 SystemOut O inside echoSimple
Congratulations, you've successfully configured and tested two advanced scenarios for integrating EJB services. As you can see, name space binding is a flexible way to specify the JNDI name, independent of the deployment topology. We used the same JNDI name, cell/persistent/echo, in our EJB import component and did not need to change it when the Echo EJB was deployed first to the WebSphere Process Server V6 server, then to a WebSphere Application Server V5.1 server.
Name space binding and the corbaname URL provide an elegant solution to integrate existing EJB services running on different versions of WebSphere or in third-party application servers.
|code sample||0605_xu-importEJB_PI.zip ( HTTP | FTP )||100KB|
|code sample||0605_xu-echo_invoke_ear.zip ( HTTP | FTP )||72KB|
- Read Part 1 of this series, Integrate EJB services with WebSphere Process Server, before beginning this article.
- WebSphere business integration zone
- WebSphere Process Server and WebSphere Integration Developer resources
- To learn more about Name Space Binding, check out the WebSphere Application Server Information Center.
- WebSphere Process Server forum
- WebSphere Education
- WebSphere technical podcast series
- New to WebSphere Business Integration
- IBM WebSphere Developer Technical Journal
Get products and technologies
- Build your next development project with IBM trial software, available for download directly from developerWorks.