Invoking cross-cell EJBs using WebSphere Integration Developer V7 or WebSphere Enterprise Service Bus V7

This article shows you how to use WebSphere Integration Developer V7 to invoke an EJB hosted in a WebSphere cell that is outside of a WebSphere Enterprise Service Bus or WebSphere Process Server cell.


Dave A. Krier (, WebSphere Solutions Architect, IBM

Photo of Dave KrierDave Krier is a WebSphere Solutions Architect specializing in WebSphere BPM and ESB technologies. He has over 10 years of experience working with a variety of IBM and non-IBM software products. Currently, he consults on a daily basis with IBM customers in the areas of business process development, implementation, and integration. You can contact Dave at

Satish Mamindla (, Senior Consulting IT Specialist, IBM

Photo of Satish MamindlaSatish Mamindla is a Senior Consulting IT Specialist, providing technical sales support for WebSphere products. He also works on proofs of concept, and teaches classes to demonstrate product features in proof of technology sessions. Satish has worked with customers around the world as a WebSphere consultant on the IBM for Software Services for WebSphere team, helping customers design and develop solutions using WebSphere products and helping them tune their solutions for production. You can contact Satish at

16 February 2011

Also available in Chinese


This article shows you how to make cross-cell EJB invocations using IBM® WebSphere® Integration Developer V7, including how to configure an SCA component of type EJB Import for use with WebSphere Process Server modules or WebSphere Enterprise Service Bus (hereafter called WebSphere ESB) mediation modules. The objective is to demonstrate cross-cell invocation of an EJB, which requires a second server. Since running two application servers at the same time on the same machine requires a significant amount of memory and CPU, you may want to plan for a second machine, unless you have a machine with a 64-bit operating system and lots of memory.

Creating and configuring a new server for use within WebSphere Integration Developer V7

In order to execute the sample application, you must first configure multiple servers for use within WebSphere Integration Developer. If your machine has a 32-bit operating system and at least 3 GB of memory, you should be able to execute this example, though you will probably need to shut down all of your applications before you start both servers. The example was tested on a machine with a 64-bit version of Windows V7 and 8 GB of memory.

To set up your environment for this example, you must first create a new server profile and configure it for use within WebSphere Integration Developer. Then you can then download the sample application, inspect the code, deploy the application to the server, and run a few tests.

Configuring the new profile in WebSphere Integration Developer

First, create a new WebSphere Application Server profile to host the EJB:

  1. Launch the Profile Management Tool from the Windows Start menu:
    Launch profile management tool
    Profile management tool
  2. Select Launch the Profile Management Tool.
  3. Select Create a new profile:
    Create new profile
    Create new profile
  4. Select the type of server you want to create and click Next. For this exercise you will create a new WebSphere Application Server => Application Server:
    Select type of profile to create
    Select type of profile
  5. Select Advanced Profile Creation and then click Next:
    Profile creation options
    Profile creation options
  6. Deselect the Deploy the default application checkbox and click Next:
    Optional application deployment options
    Optional application deployment options
  7. Name the profile AppSvr01, leaving the other fields with their default values, and click Next.
  8. Important: Change the default server name to server02. This server name must be different from the other server name, which is the sole reason you need to pick the advanced profile configuration. If the default value server1 is same as the other server name, then it needs to be changed. If the server names for both servers are the same, the server will run and no obvious errors will occur, but you will not be able to make any cross-cell CORBA calls:
    Modify the server name
    Change the server name
  9. Deselect Enable administrative security and click Next. Security is not needed in this example:
    Administrative security
    Admin security
  10. Leave the defaults and select Next, which will create a new security certificate.
  11. Again, leave the defaults and select Next on the Part 2 screen for the security certificates.
  12. Accept the default values for the ports and select Next. The profile management tool selects ports that are not in conflict with any other profiles. Note the Bootstrap port number, which is the port that you will use in the CORBANAME URL:
    Port value assignment
    Default selected port numbers
  13. Edit the default startup behavior: select Manual in the Startup Field then click Next:
    Windows service definition
    Startup behavior
  14. You will not need a Web server, so click Next to proceed without creating one.
  15. Review the profile creation summary screen for accuracy and click Create to launch the Profile Creation Wizard, which will take some time to complete. If successful, you will see the message The Profile Management Tool created the profile successfully.
  16. Uncheck Launch the First Steps console and click Finish.

Congratulations -- you now have a new WebSphere Application Server profile, which you can use to create a new server within WebSphere Integration Developer. The next section shows you how to configure a new server using this new profile.

Configuring the new profile in WebSphere Integration Developer

You must first configure a new server in WebSphere Integration Development using the new profile you created:

  1. Launch WebSphere Integration Developer and create a new workspace.
  2. In the Servers area on the bottom pane, right-click in the white space to bring up a pop-up menu:
    Define New Server
    New Server pop-up
  3. Select New => Server from the pop-up menu.
    Server pop-up menu
    New server pop-up menu
  4. Select WebSphere Application Server V7.0 from the list of server types. This is the type of profile that you created in the previous section and can now use to create a new server.
  5. Modify the name of the server: WebSphere Application Server 2.
  6. Make sure WebSphere Application Server V7.0 is selected as the server runtime environment and click Next:
    Define new server
    Define new server
  7. Select the profile name from AppSrv01, which is the profile you created above.
  8. Make sure that Security is enabled on this server is not selected and then click Next. Security is not necessary in this example:
    WebSphere Application Server settings
    Server settings
  9. Click Finish. You do not need to deploy any applications to the server at this time. You should now see the newly created server in your list of servers:
    New Server Setup Complete
    Server Setup Complete

Configuring the server for development mode

You must configure the server to run in development mode, so that WebSphere Integration developer can interact with the server. Enabling this option may reduce the startup time of an application server. It may include JVM settings such as disabling bytecode verification and reducing JIT compilation costs. Do not enable this setting on production servers.

  1. Start the server.
  2. Launch the Administrative Console:
    Launch Admin Console
    Launch Admin Console
  3. Once logged in, select Servers, Server Types, and WebSphere Application Servers from the left-hand navigation links.
  4. Click Server02.
  5. Click the check box to put the server in development mode:
    Enable the server to run in development mode
    Putting the server in development mode
  6. Restart the server. The server is now in development mode.

Downloading and importing the sample project into your workspace

How you invoke an EJB depends on the EJB specification version you are working with. This example uses an EJB that conforms to the EJB 3.0 specification. Where appropriate, differences between the EJB 2.1 and EJB 3.0 specifications will be noted.

  1. Download the project interchange file at the bottom of the article.
  2. Within WebSphere Integration Developer, select File => Import => Other => Project Interchange.
  3. Browse to the download location and select
  4. Click Finish.

Four projects should be listed in your workspace, as shown below:

EJB 3.0 sample projects
Project nameProject type
MediationForMySimpleEJB30Deployable mediation module project
MyEJB30EJB30 project
MyEJB30ClientEJB30 client project
MyEJB30EARDeployable EAR project containing the MyEJB30 project.

The next section shows you how to invoke the cross cell EJB within a WebSphere ESB mediation module using an EJB Import SCA component. While the example uses a WebSphere ESB mediation module, you can just as easily use a WebSphere Process Server module to build the example.

Inspect the EJB 3.0 sample project

Now that you have the project loaded, look at the components within the mediation module to gain a better understanding of how it makes the cross-cell call to the EJB:

  1. Within your workspace, select the mediation module MediationForMySimpleEJB30 and open the Assembly Diagram.
  2. There are two EJB Imports already configured. Start by selecting the EJB30_Direct SCA component.
  3. With the SCA component, select the properties tab in the lower half of the workspace and review the properties for the component.
  4. Within the properties pane, click Bindings to review the bindings configuration for this component.
  5. In the JNDI Name field, you can see how you configured the CORBANAME URL to make the cross-cell invocation:
    Properties View
    Properties for the EJB3_Direct component

    This is the only thing you had to configure -- the other fields use default values. The port number used in this example may not match your environment, so note the port number and make modifications as needed.

    Another important thing to note is the backslashes used in the URL. If you understand the EJB3.0 specification, you know that backslashes are not typically seen in the CORBANAME URL. Since we are using a Java-based tool, we need to escape the dot character in our URL, so that it is preserved in the URL that is used when we make the call. This example is calling an EJB that conforms to the EJB 3.0 specification. If the EJB you are invoking was written to the EJB 2.1 specification, the CORBANAME URL would be structured differently. Here is an example of how the EJB 2.1 CORBANAME URL would look:


You now know how to configure the SCA component to make direct calls to the remote EJB without making any configuration changes in your server environment. While this approach will work, it may not be the best approach if you want flexibility. If the EJB is modified or redeployed to a new server, the CORBANAME URL will need to be modified within the SCA component to point to the new location and you will need to redeploy the mediation module as well. The more flexible approach is to leverage JNDI to configure your CORBANAME URL, which requires some additional configuration on the WebSphere ESB server hosting the Mediation Module. As an alternative, you can configure the EJB Import to point to a local JNDI reference, which is configured on the server and can be changed without having to redeploy the Mediation module.

Next, examine the second EJB Import component in the assembly diagram: EJB3_Remote_Using_Local_JNDI.

  1. In your assembly diagram, select the EJB Import EJB3_Remote_Using_Local_JNDI.
  2. In the properties pane, click Bindings to review the bindings configuration for this component:
    Properties view
    Properties for the EJB3_Local component

    Note the JNDI name that points to a local resource. It must be manually configured to point to the CORBANAME URL, which is the same URL you used in the previous example.

You must manually configure this JNDI resource using the WebSphere Admin Console before you can test it:

  1. Click on the Servers tab in the lower pane of your Development Window to show the list of servers.
  2. Right-click on the server named WebSphere ESB Server V7.0 and select Administration => Run administration console, which launches the WebSphere Admin Console in a browser window within WebSphere Integration Developer.
  3. If prompted, log in to the server (the default credentials are User ID = admin and Password = admin).
  4. Select Environment => Naming => Namespace bindings to configure a new local JNDI resource, which will point to the remote EJB.
  5. Select the scope Cell, so that the resource is available at the cell scope.
  6. Click New to create a new JNDI resource.
  7. Specify the binding type as CORBA and click Next.
  8. Set the following properties:
    Property nameValue
    Binding identifierHelloCorba
    Name in name
    Corbaname URLcorbaname:iiop:localhost:2812/NameServiceServerRoot#com\.ibm\.test\.HelloBeanRemote

    The binding identifier can be anything you want as long as it is unique within the Admin Console, because it is only used to identify the binding in the Admin Console. The Corbaname URL,must match the name used in the namespace on the remote server where the EJB is deployed and is relative to the prefix cell/persistent/, which will be added to the name when it is executed. The Corbaname URL contains a port number, which you may need to modify depending on your environment.

  9. Click Save when your done.

You have now completed the JNDI resource configuration and are ready to deploy and test your applications.

Deploying and testing the sample application

You are now ready to deploy your EJB and mediation module to the servers and test the connectivity from the mediation to the remote EJB:

  1. Start WebSphere Application Server V7: select the server in the list and click Start:
    Starting WebSphere Application Server
    Starting the server
  2. Start the WebSphere ESB V7 server: select the server in the list and click Start.
  3. Once both servers are started, right-click WebSphere Application Server and select Add/remove projects:
    Add/remove Projects
    Add/remove projects
  4. Select MyEJB30EAR and click Add and then click Finish:
    Add EJB project
    Adding the EJB project to the Server

    It may take a few moments to deploy the EJB -- let it finish before you go to the next step

  5. Right-click WebSphere ESB V7 Server and click Add/remove projects.
  6. Select the project MediationForMySimpleEJB30 and click Add, and then click Finish. You are now ready to test.
  7. In the Assembly diagram, right-click on the EJB3_Direct component and click Test component:
    Test component
    Input for test

    The EJB you are calling is quite simple. It will echo what you send and append the word Hello, so you can put anything you want in the input field.

  8. Click in the Value field for arg0 and type in your name as input. I used Dave as the value for input in my example.
    Testing input (can be anything you want)
    Input for test
  9. Click the green Play button located in the upper left hand corner to initiate the test.
  10. At the prompt, select WebSphere ESB Server V7 as the target server for the test project. You may be prompted for security credentials, because the test project is being deployed the first time you run the test. It may take a few moments to produce results because of the deployment of the test project.
  11. If successful, the results on the right will show Hello plus whatever you added. In my case, the results show Hello Dave:
    Returning result form EJB
    Returning result

    Click to see larger image

    Returning result form EJB

    Returning result
  12. Repeat Steps 9 through 12 to test the other EJB Import: EJB30_Remote_Using_Local_JNDI_Reference


Code sampleCrossCellEJBExamplePI.zip41 KB



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

ArticleTitle=Invoking cross-cell EJBs using WebSphere Integration Developer V7 or WebSphere Enterprise Service Bus V7