Introduction

With the arrival of the EJB 2.0 specification, an Enterprise Java Bean can have a local interface, a remote interface, or have both interfaces simultaneously, giving the J2EE developer and architect much flexibility. Implementing both interfaces gives a bean client and the bean itself freedom in deployment scenarios. Depending on where the client is located relative to an EJB, it is possible to set the best way of access to the bean's logic. Local interfaces provide optimized access to an EJB if the client and bean are collocated in the same Java Virtual Machine (JVM), whereas remote interfaces are useful for distributed architectures. Combining both types of interfaces within a single application, supporting both ways of access to the bean, may help relax design constraints.

It would be very interesting to have something tangible, like test results, case studies, or, better, the approach and tools, rather than just the request and promise, to weigh the pros and cons of design decisions. This article is an attempt to provide more information on the use of local and remote interfaces for EJBs based on a sample J2EE application. Using the development and test environment of WebSphere Studio Application Developer, we will implement two topologies of J2EE application architecture, run the application, and, with the help of a simple Java HTTP client, perform testing to get some performance-related answers and numbers to consider.

Back to top

Architecture choices for J2EE Applications

Typically, the simplest topology is one in which everything from the J2EE application is residing within the same WebSphere Application Server, within the same JVM, and within the same node, or machine. In such a case, WebSphere Application Server supplies the servlet container and EJB container (Figure 1). This topology (we will omit firewalls, load balancers, switches, etc.) throughout this article will be referred to as the "All-in-One" topology.

This is a default topology for the WebSphere Test Environment (WTE) in WebSphere Studio Application Developer Version 5.1 (hereafter referred to as Application Developer). However, such a topology can be successfully used in production environments as a part of the site architecture. With the advent of the EJB 2.0 specification, it is possible to use local interfaces to communicate with EJBs residing within the same EJB container, from any Java component of the J2EE application.

Sometimes there is a need to separate the servlet and EJB containers, such as for application security. An Application Architect or Deployer may choose to put a servlet container to a different node, thus making the J2EE application topology more complex, as in Figure 2, which we will refer to as the "Separate Containers" topology. Indeed, WebSphere Application Server may serve as a highly efficient servlet container and EJB container, but to make things easily distinguishable, we will make Tomcat Application Server the servlet container here.

In the Separate Containers topology, the only way for the Web part of the J2EE application to communicate with EJBs is through remote interfaces, typically via Internet Inter-Orb Protocol (IIOP). (In this article we are not discussing the separation of the Web or HTTP server, since it is not our primary focus.)

Deployment architecture decisions often change during development of the J2EE application. Therefore, developers may want to take advantage of using both remote and local interfaces of the EJBs to avoid losing deployment flexibility. It is possible to develop a J2EE application that would accomodate any reasonable deployment topology without changing a line of source code, possibly making changes only to deployment descriptor settings, which could be a great time saver for the developer. It would also be interesting to make performance comparisons between local interface usage vs.remote interfaces. Later, we will create a simple sample J2EE application which would allow us to easily switch from local to remote interface usage by setting the EJB's environment parameters. For the All-in-One topology, we will test the sample application using either local or remote interfaces in a controlled manner, and will refer to them as "All-in-One-All-Local" and "All-in-One-All-Remote," respectively.

Back to top

Artifacts and prerequisites

The sections that follow will describe the development and deployment process for creating a flexibly deployable, multi-tiered, distributed J2EE application, named "Dual", that will demonstrate the usage of both interfaces. The results will include:

• Three J2EE applications (EAR modules) for the described deployment scenarios.
• A Java module containing a Java Bean.
• Two J2EE EJB modules:
  • a stateless session EJB
  • a container-managed entity EJB (CMP).
• J2EE Web application (WAR module) containing:
  • a servlet
  • a JSP page
  • an HTML page.
• Datasource (mapped to a DB2 database).
• Two test servers, each implementing:
  • WebSphere Test Environment (WTE)
  • Tomcat Test Environment.

The architecture used in this application uses the standard Model-View-Controller architecture (MVC, "Model 2"), in which the servlet is used as a controller and the JSP is used as a presentation component. To make things closer to real life, the Data Transfer Object (DTO), or Value Object (VO), design pattern is also used. The servlet DualServlet interacts with session bean DualSession that, in turn, further interacts with the entity bean DualEntity. The entity bean interacts with the datastore with a table, PERSON. The VO is presented by a Serializable Java class, Person. This object is used as a return value for the session bean's method, as well as the Java bean for the JSP page.

The included download ZIP file contains completed EAR modules and the code listings used in this tutorial. With this ready-made solution, you can simply create the database tables and server projects, and then easily run, debug and test the application. The download also contains a simple Java HTTP multithreaded test client to help with running performance tests.

In a real life scenario, each component pictured in Figures 1 and 2 would reside in a separate node (machine). For the purposes of this tutorial, we will put everything, including persistent storage, onto the same machine, running everything on a single developer's workstation. Be aware this configuration is for educational purposes only, yet it will not limit the features of the flexibly deployable application. Every major component of the application can be deployed on separate nodes without code changes by supplying relevant hostnames to the settings of the client, Web and EJB components, and the JDBC driver.

To follow the steps in this tutorial, the following must be installed on your workstation:

• DB2 V8.1 (database)
• WebSphere Studio Application Developer Version 5.1 (integrated development and test environment)
• Tomcat 4.1.29 (servlet container); Download here.

The major steps in the development of our Dual J2EE application are described in the following sections. Naming conventions must be closely adhered to for the success of this exercise.

Important: This tutorial assumes a level of J2EE experience or a working knowledge of Application Developer, and so stresses only main topics, important decisions and paths to follow, rather than provide overly detailed descriptions. For applicable details and helpful background information, refer to the previous "Hello World" articles listed in the References section.

Back to top

Setting up the projects in Application Developer

Step 1. Create data model and persistent storage

The Data Model for the Dual application is the same as in the "Hello World" J2EE application. Log in to DB2 and create a database with the name dualDB, and within that database create a table, PERSON:

CREATE TABLE PERSON
(
  ID        INTEGER NOT NULL PRIMARY KEY,
  FIRSTNAME VARCHAR(40),
  LASTNAME  VARCHAR(40)
)

This script is provided in the Table.ddl in the downloaded ZIP file.

Step 2. Create projects

In this step, we will create a set of projects, each of which will serve a different purpose. For example, we will put entity and session beans into different JARs, since larger J2EE applications are often comprised of several JARs, or projects.

One by one, create the following:

1. Java project: DualJavaModule00.
   Within the project, create package dual.value. We will put a class Person for VO into it.
2. J2EE 1.3 project: DualEARForAllInOne.
   This will be the placeholder for the All-in-One topology.
3. J2EE 1.3 project: DualEARForEJBContainer.
   This is intended for the EJB container only.
4. J2EE 1.3 project: DualEARForWeb.
   This is intended for the servlet container only. Alternatively, we could use DualEARForAllInOne for the same purpose, since the only difference is in project dependencies. However, keeping them separate is a better choice.
5. EJB 2.0 project: DualEJBModule01.
   Associated with DualEARForEJBContainer. Create package dual.ejb (in the ejbModule folder).
6. EJB 2.0 project: DualEJBModule02.
   Associated with DualEARForEJBContainer. Similarly, create package dual.ejb. Make this project depend on DualEJBModule01. (More on dependencies later.)
7. Web Project: DualWebModule03.
   When creating this project, check the Advanced options checkbox and associate it with DualEARForWeb. Create a package dual.servlet within this Web project. Uncheck all the WebProject features since they are not needed for this exercise.

Our initial project structure is complete. The J2EE view of your workspace should look like Figure 3.

You can see all of your created projects in the Project Navigator tabbed view.

Step 3. Create project content

1. Within the DualJavaModule00 project, create a Java bean called dual.value.Person. You may copy this bean from the download. Refresh the project by right clicking on the project name and select Refresh.
2. Within DualEJBModule01, create an entity bean with Container Managed Persistence (CMP). Name it DualEntity (Figure 4), with the key field id of type int, and firstName and lastName as persistent String fields. Check both local and remote client views, as shown in Figure 5. We will be using remote home interface name dual.ejb.DualEntityRemoteHome, and remote interface name dual.ejb.DualEntityRemote, thus changing the default names. The EJB binding name will be ejb/dual/ejb/DualEntityHome.
   Figure 4. DualEntity EJB
   
   
   Figure 5. CMP Fields and Naming Conventions
   
   Alternatively, you can also complete this step by copying the source code from the download file into the project folder, refreshing the project, and then creating the entity bean as described above, using the code as a template (Figure 5). This will also create an ejb-jar.xml and the binding descriptors. After that you may also copy the ejb-jar.xml from the download into the project.
3. Within DualEJBModule02, create a stateless session bean, called DualSession. Again, you can also copy the content of the source code, refresh the project and then create the DualSession session bean using the code as a template. Similar to above, we will need both local and remote interfaces, with remote home interface name dual.ejb.DualSessionRemoteHome, and remote interface name dual.ejb.DualSessionRemote. (Check with the supplied source code for naming conventions.) Copy the ejb-jar.xml from the download. We will do the code analysis later. Upon completion, you will get lots of error messages. Disregard them for now; these will be resolved in the next step, when we resolve project dependencies.
4. Within DualWebModule03 create a servlet named DualServlet. Again, the fastest way to do this is to copy the source, DualServlet.java, from the download. You may also copy web.xml, index.html, and result.jsp into the project folder. Again, you will get a lot of error messages, but now we will resolve them by establishing project dependencies.

Step 4. Resolve project dependencies and EJB to RDB mapping

1. Make the DualEJBModule02 project dependent on DualJavaModule00 and DualEJBModule01 projects by adjusting the Java Build Path in project properties. Errors for this project should go away after you select the OK button.
2. Similarly, make DualWebModule03 dependent on DualEJBModule02 and DualJavaModule00, by again adjusting the Java Build Path in project properties, and also in Web Library Projects settings. You should not have any error messages after this.
3. To map the DualEntity bean to the relational database (RDB) table PERSON, select DualEJBModule01, right click, select Generate... => EJB to RDB Mapping ..., then use the following options:
   • Create a new backend folder.
   • For EJB/RDB Mapping, use the "Meet In The Middle" option.
   • To establish a database connection, select DB name, userID, password, DB2 Universal Database 8.1, and take all defaults for the remaining options.
   • Select the PERSON table for import.
   • Select Match By Name and Type option.
   • First select the bean, then select the table, then right-click and choose Match by Type.
     Figure 6. EJB to RDB mapping
     
     
4. Select Generate... => Deployment and RMIC Code... for DualEJBModule01 and for DualEJBModule02.

Back to top

JNDI bindings and source code analysis

EJB modules

Starting with DualEJBModule01. In the EJB Deployment Descriptor editor panel, select the Beans tab, then DualEntity, and make sure that the JNDI name in the WebSphere Bindings section is set to "ejb/dual/ejb/DualEntityHome". Save any changes.

First, let us review a code snippet from ejb-jar.xml for DualSession EJB in the DualEJBModule02 project:

...
<env-entry>
   <env-entry-name>useLocal</env-entry-name>
   <env-entry-type>java.lang.Boolean</env-entry-type>
   <env-entry-value>true</env-entry-value>
</env-entry>
<env-entry>
   <env-entry-name>doTrace</env-entry-name>
   <env-entry-type>java.lang.Boolean</env-entry-type>
   <env-entry-value>false</env-entry-value>
</env-entry>
<ejb-ref id="EjbRef_02">
   <ejb-ref-name>ejb/DualEntityRemoteHome</ejb-ref-name>
   <ejb-ref-type>Entity</ejb-ref-type>
   <home>dual.ejb.DualEntityRemoteHome</home>
   <remote>dual.ejb.DualEntityRemote</remote>
   <ejb-link>DualEJBModule01.jar#DualEntity</ejb-link>
</ejb-ref>
<ejb-local-ref id="EJBLocalRef_02">
   <ejb-ref-name>ejb/DualEntityLocalHome</ejb-ref-name>
   <ejb-ref-type>Entity</ejb-ref-type>
   <local-home>dual.ejb.DualEntityLocalHome</local-home>
   <local>dual.ejb.DualEntityLocal</local>
   <ejb-link>DualEJBModule01.jar#DualEntity</ejb-link>
</ejb-local-ref>
...

Here, the first env-entry element, with the name "useLocal", is intended to control the usage of the local interfaces of the DualEntity EJB. The second such entry, with the name "doTrace", is intended to be used just for tracing. The tracing capabilities that are implemented are rather rudimentary, but will be sufficient for our purposes.

The corresponding Java code looks like the following:

public class DualSessionBean implements javax.ejb.SessionBean {
   private javax.ejb.SessionContext mySessionCtx;
   private boolean doTrace;
   private boolean useLocal;
   private DualEntityRemoteHome entityRemoteHome;
   private DualEntityLocalHome entityLocalHome;

   public void setSessionContext(javax.ejb.SessionContext ctx) {
      mySessionCtx = ctx;
      try {
         Context initCtx = new InitialContext();
         Boolean option = null;
         option = (Boolean)initCtx.lookup("java:comp/env/useLocal");
         useLocal = option.booleanValue();
         option = (Boolean)initCtx.lookup("java:comp/env/doTrace");
         doTrace = option.booleanValue();
         if (doTrace)
            System.out.println("DualSessionBean#setSessionContext: useLocal="
                  +useLocal);
         Object homeObject = null;
         if (useLocal){
            homeObject = initCtx.lookup("java:comp/env/ejb/DualEntityLocalHome");
            entityLocalHome = (DualEntityLocalHome)homeObject;
         } else {
            homeObject = initCtx.lookup("java:comp/env/ejb/DualEntityRemoteHome");
            entityRemoteHome = (DualEntityRemoteHome)
            javax.rmi.PortableRemoteObject.narrow(homeObject,
                  DualEntityRemoteHome.class);
         }
      } catch(NamingException ne){
         // process exception here...
      }
   }
...

In the Java code, those EJB environment variables are read and stored as the class variables for the lifetime of the stateless session bean object.

The local and remote home interface of DualEntity are accessed via references; this is the preferred way and adheres to the EJB 2.0 specification. Correspondingly, ejb-jar.xml contains ejb-ref and ejb-local-ref elements describing those references.

Open the EJB Deployment Descriptor editor and select the Beans tab. Make sure the JNDI name is set to "ejb/dual/ejb/DualSessionHome". Then, go to the References tab and make sure that both references to DualEntity point to JNDI name "ejb/dual/ejb/DualEntityHome". Correct these values if necessary, and save your changes.

Web module

The standard J2EE Web deployment descriptor for the DualWebModule03project contains two important code fragments. The first one specifies initial parameters for the servlet:

...
   <init-param>			
		<param-name>useLocal</param-name>
		<param-value>true</param-value>
   </init-param>
   <init-param>
		<param-name>doTrace</param-name>
		<param-value>true</param-value>
   </init-param>
   <!--
   <init-param>
      <param-name>jndiProviderURL</param-name>
      <param-value>iiop://localhost:2809</param-value>
   </init-param>
   <init-param>
      <param-name>jndiNameOnServer</param-name>
      <param-value>ejb/dual/ejb/DualSessionHome</param-value>
   </init-param>
   <init-param>
      <param-name>initialCtxFactoryClassName</param-name>
      <param-value>com.ibm.ejs.ns.jndi.CNInitialContextFactory</param-value>
   </init-param>
-->
...

The above code is similar in meaning to the EJB environment parameters, discussed earlier. The Web deployment descriptor section that is commented out will be needed later for the Separate Containers topology. When those three additional parameters are uncommented, the logic related to this architecture will be invoked in the servlet's init() method. (More on that later.)

The second fragment shows the description of the references, which are needed to establish servlet-to-EJB communication:

...
<ejb-ref id="EjbRef_03">
		<ejb-ref-name>ejb/DualSessionRemoteHome</ejb-ref-name>
		<ejb-ref-type>Session</ejb-ref-type>
		<home>dual.ejb.DualSessionRemoteHome</home>
		<remote>dual.ejb.DualSessionRemote</remote>
		<ejb-link>DualEJBModule02.jar#DualSession</ejb-link>
</ejb-ref>
<ejb-local-ref id="EJBLocalRef_03">
		<ejb-ref-name>ejb/DualSessionLocalHome</ejb-ref-name>
		<ejb-ref-type>Session</ejb-ref-type>
		<local-home>dual.ejb.DualSessionLocalHome</local-home>
		<local>dual.ejb.DualSessionLocal</local>
		<ejb-link>DualEJBModule02.jar#DualSession</ejb-link>
</ejb-local-ref>
...

Correspondingly, the source code of DualServlet contains the processing logic in the servlet's init() method. Following is the snippet related to processing the EJB references:

...
final String JNDI_NAME_LOCAL = "java:comp/env/ejb/DualSessionLocalHome";
final String JNDI_NAME_REMOTE = "java:comp/env/ejb/DualSessionRemoteHome";
...
   if (useLocal) {
      initCtx = new InitialContext();
      homeObject = initCtx.lookup(JNDI_NAME_LOCAL);
      sessionLocalHome = (DualSessionLocalHome) homeObject;
   } else {
      homeObject = initCtx.lookup(JNDI_NAME_REMOTE);
      sessionRemoteHome =
         (DualSessionRemoteHome) PortableRemoteObject.narrow(
         homeObject,
         DualSessionRemoteHome.class);
   }
...

(The initial parameters processing logic in the downloaded source code is actually more complex, since it also handles the Separate Containers topology.)

Alternatively, in the Web Deployment Descriptor editor pane for the DualWebModule03 project, check all settings for DualServlet first, including thet Initialization section, then proceed to the References tab, and check both EJB and EJB Local sub-tabs. Both references should point to the JNDI name "ejb/dual/ejb/DualSessionHome" in the WebSphere Bindings section.

Summary of project dependencies

Since we are basically finished with these modules, let us review the dependencies for all projects, including EARs, one more time:

• DualJavaModule00 has no dependencies.
• DualEJBModule01 has no dependencies.
• DualEJBModule02 must have DualJavaModule00, and DualEJBModule01 projects in "Java Build Path", "Java JAR Dependencies" and "Project References".
• DualWebModule03 must have DualJavaModule00 and DualEJBModule02 projects in "Java Build Path", "Java JAR Dependencies", "Project References" and "Web Library Projects" settings.
• DualEARForEJBContainer must have DualJavaModule00, DualEJBModule01, DualEJBModule02 in "Project References"; EAR deployment descriptor must have references to both EJB modules and Java module.
• DualEARForAllInOne must have Project References to all modules including Java, EJB and Web; the same for EAR deployment descriptor.
• DualEARForWeb must have project references pointing to DualJavaModule00, DualEJBModule02, DualWebModule03 modules; same for EAR deployment descriptor.

Back to top

Deploying different architectures

Server Projects

1. Create a Tomcat server project, called "TestServerTomcat". Within this project, select New Server and Server Configuration, enter "ServerTomcat" as the Server name, and Test Environment under "Apache Tomcat version 4.1" as the Server type. On the next panel, specify TOMCAT_HOME as the directory where Tomcat is installed, and the appropriate JDK location settings. See Figure 7.
   Figure 7. Server Tomcat Settings
   
   
2. Create server project "TestServerWAS". Within this project, create server "ServerWAS" and accept all defaults. (Details are in "Hello World" J2EE application article.)

Finally, your workspace should look like this:

We are now ready to add the projects to the servers and test the J2EE application.

Deploy All-in-One-All-Local architecture

To deploy this architecture:

1. Add DualEARForAllInOne to the WebSphere Application Server configuration. Open the server configuration editor to enter the necessary settings; e.g. to set classpath to projects folders. Since we will be performance testing later, it may be a good idea to also change some of the environment settings as well; for instance, set Java VM arguments to -Xms512M -Xmx512M, disable the universal test client, etc.
2. It is also necessary to change some datasource settings. For now, remove "Cloudscape" from the list of providers and add datasource of Version 5.0 for the "Default DB2" provider. Accept all defaults, and specify dualDB as "databaseName" resource property value. On the EJB tab of the server configuration editor, set the default datasource to Data source 1.
3. Go back to DualEJBModule01 EJB deployment descriptor editor. For the DualEntity bean, set the value of "CMP Connection Factory JNDI name" to jdbc/ds1, and "Container authorization type" to Per_Connection_Factory.
4. For initial testing, make sure that "useLocal" and "doTrace" in web.xml and ejb-jar.xml for DualEJBModule02 are set to true.
5. Publish and start ServerWAS.
6. Using a Web browser, navigate to URL http://localhost:9080/DualWebModule03. You should see the index page with the form displayed.
   Figure 9. Index and Result Pages
   
   
7. You can now test the whole J2EE application, and watch the console messages in Application Developer.

Deploy All-in-One-All-Remote architecture

To deploy to this architecture, no project settings need to be changed. However, to switch to remote interfaces within the same deployment (implementing All-in-One-All-Remote), you need to change "useLocal" setting values in web.xml and ejb-jar.xml for DualEJBModule02 to false.

Deploy Separate Containers architecture

To implement this architecture, remove DualEARForAllInOne project from the "ServerWAS" configuration and add DualEARForEJBContainer to it. Then, add the DualWebModule03 project to the "ServerTomcat" configuration.

Instruct the servlet to use a specific URL to locate EJBs by uncommenting the related parameter settings in web.xml. Set "useLocal" to true in ejb-jar.xml to implement the fastest communication within the EJB container on WebSphere Application Server.

Before starting the servers, we have to set the environment for Tomcat. Open the Tomcat server editor, select the Environment tab to set "Class Path":

• Add Variable: ${WAS_50_PLUGINDIR}/properties.
• Add Folders: DualEJBModule02/ejbModule, DualJavaModule00.
• For the Tomcat class loader, we need the Enterprise JavaBeans classes and interfaces usually contained within the javax.ejb package. Putting the standard j2ee.jar into the classpath may create well known incompatibility problems for Tomcat because of the presence of the javax.servlet package in both j2ee.jar and servlet.jar files. One way to avoid this is to create a new j2ee-modified.jar, containing only the necessary EJB related classes (supplied with the download). Add this file under the "External JAR" option.
• Set "Java VM Arguments" to -Xms256M -Xmx256M.

To start the application, you must first start ServerWAS, then ServerTomcat.

Point your browser to http://localhost:8080/DualWebModule03 to see the index page, since Tomcat uses port 8080 as a default port for HTTP.

Back to top

Testing with a simple Java HTTP test client

We will now proceed with some performance testing using a simple Java HTTP test client, supplied with the download. The test client measures average response time and number of successful hits (i.e. hits that get responses) for the duration of the testing. To start the client, a Java application with a simple and self-explanatory GUI, run start.bat. Enter a URL for the POST request, then choose a test time and a number of concurrent threads to run. The URL should be valid for the architecture being tested. Select Set then Start. When the testing is completed, results will display in a colored text area.

The test client spawns the specified number of threads, each supplied with its own URL object. The client generates HTTP GET and POST requests with parameters defined in the init.properties file, supplied in the client.jar file. The id request parameter value is an integer calculated by a random number generator, and firstName and lastName request parameters are created by randomly picking elements from pre-defined String arrays. The client uses GET request to test the URL in "Set" mode, then it uses POST requests for actual performance or load testing. Each thread sends a request, waits for the response to come, then sends another request to the server, and so forth. Test results will be discussed in the next section.

Do not forget to disable tracing in web.xml and ejb-jar.xml before you start testing!

Back to top

Performance testing results and analysis

Test setup

There is nothing special in the test setup in comparison with the typical environment on a developer's machine. The computer we used for the testing had an Intel Pentium III processor with 1 GHz and 1.5GB of RAM, Windows 2000, DB2 V8.1, WebSphere Studio Application Developer Version 5.1, Tomcat 4.1.29 and IBM JDK 1.3.1 with JIT enabled. Thus, for the test setup, all the services and applications were running on the same single processor computer.

The tests we conducted were of two types: single-threaded and multi-threaded, with 100 threads for each of the architectures described above. To get repeatable results, there were series of runs for each test setup on a client. The results of the first run in the series were not considered representative, run to get the JVM and the servers to "warm-up". All the records in the database PERSON table were deleted after each test run. The typical duration of a single test run was usually 10 minutes.

For multithreaded testing for Separate Containers, settings in Tomcat's server.xml were adjusted as follows:

...
<Connector acceptCount="10"
      className="org.apache.coyote.tomcat4.CoyoteConnector" 
      connectionTimeout="20000"
      debug="0" enableLookups="false" 
      maxProcessors="200" minProcessors="200" 
      port="8080" redirectPort="8443" 
      useURIValidationHack="false"/>...

No significant database or server tuning was performed.

Results

Actual test results are shown in the diagrams below. The absolute numbers in themselves are not significant, but the relative numbers are. Generally, performance results for the local and remote interfaces are in good agreement with the prior overview. (Also see Resources.) Multi-threaded throughput was generally slower in our tests, because each JVM had to dispatch multiple threads on the same single processor. Request processing time is small for this sample application, and therefore threads dispatching and scheduling time had a significant share in overall processing time, thus increasing response time.

Back to top

Conclusion

This article has shown the design approach, the implementation and the test results for a sample J2EE application, providing a basic comparison of the local and remote interface usage for Enterprise Java Beans. Exposing local and remote interfaces of the EJBs does not restrict flexibility in J2EE application deployment. These two types of interfaces let you to change deployment scenarios without changing the application source code, and also lets you to take advantage of any deployment architecture you choose. Performance is the best when local interfaces are used within the same JVM. Performance may degrade with container separation. For established J2EE design patterns, we recommend using both interfaces for session, and sometimes for entity beans, by creating code that handles local and remote interfaces for maximum efficiency with little extra effort.

Back to top

Download

Name	Size	Download method
Dual.zip	148 KB	FTP|HTTP

Information about download methods

Resources

• Enterprise JavaBeans Technology 2.0 Specification, Sun Microsystems Inc., 2001
  
  
• Developing and Testing a Complete "Hello World" J2EE Application with WebSphere Studio Application Developer Version 5.0, Elson Yuen, Sheldon Wosnick, IBM WebSphere Developer Technical Journal, June 2003
  
  
• Meet the Experts: Ruth Willenborg on WebSphere Performance, Ruth Willenborg, IBM WebSphere Developer Technical Journal, August 2003
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Architecture choices for J2EE Applications
• Artifacts and prerequisites
• Setting up the projects in Application Developer
• JNDI bindings and source code analysis
• Deploying different architectures
• Testing with a simple Java HTTP test client
• Performance testing results and analysis
• Conclusion
• Download
• 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 WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers