Geronimo is the Apache Software Foundation's open source J2EE 1.4 server, born in 2003. Part 1 of this two-part series described Geronimo from a system-design standpoint, examined its architecture, probed some key structural concepts, and introduced basic user terminology. Now continue the Geronimo tour and explore the server's deployment, configuration, and management capabilities in some detail.

You'll discover what this versatile container can do for you in your daily J2EE development activities. Starting with a nontrivial enterprise application example, you'll use Geronimo's deployment tool to deploy, and control the lifecycle of, many standard J2EE deployable modules. You'll test Geronimo with Java ServerPages (JSPs), servlets, and a tag library in a Web archive (WAR); a session EJB in an enterprise archive (EAR); a Java Database Connectivity (JDBC) connector in a resources archive (RAR); and a container-managed persistence (CMP2) entity bean that uses EJB Query Language (EJB-QL) packaged in an EAR. You'll discover the classloader hierarchy in Geronimo and how it intimately relates to configurations. Last, but not least, you'll see Geronimo's support for manageability in action. Using a Java Management Extensions (JMX) console, you'll look inside Geronimo and see the Web components you've deployed.

My sincere thanks to Geir Magnusson, Jr., Jeremy Boynes, David Jencks, and Alan D. Cabrera from the Geronimo team for their valuable comments on drafts of this article series.

Slicing the Geronimo onion

From the architectural discussion in Part 1, you know that Geronimo acts as a container for other open source containers (such as Jetty, Tomcat, and OpenEJB) that provide configuration, management, deployment, and other essential services.

Figure 1 illustrates Geronimo's onion-like container nesting. First, Geronimo itself is a container that wraps a service such as Jetty or Tomcat. Next, Jetty wraps the Web application components that you deploy (servlets, JSPs, tag libraries, and so on). The important thing to note here is that metadata, or deployment-descriptor (XML file) information, is required at every container boundary, as illustrated in Figure 1:

In Figure 1, the j2ee-server-plan.xml deployment plan tells Geronimo how to deploy and configure the Jetty service. Peeling through to the next layer, the jetty-web.xml deployment descriptor tells the Jetty service contained inside Geronimo how to deploy and configure your Web application components.

Of course, the standard container-independent deployment descriptors, specified in the J2EE 1.4 specification, are also required. They include web.xml for Web applications, ejb-ear.xml for EJB archives, and application.xml for EAR files.

In this article, I'll focus on the configuration and deployment of J2EE deployable modules only. Configuration and deployment of system components, such as Jetty and Tomcat, is out of the article's scope, although the mechanism is similar.

Back to top

Deployment and lifecycle control

Table 1 details the different deployable archives, their deployment descriptors, and the associated Geronimo deployment plans.

All the J2EE-specified descriptors (the second column in Table 1), must be embedded within the archive. The J2EE specification (see Resources), specifies each resource's location, as illustrated in Figure 2 (which shows only the server-side archives). The location of the Geronimo deployment plans, however, is somewhat flexible; one potential location is indicated by the dashed-line boxes in Figure 2:

If you cross-reference Figure 2 with Table 1, you can identify the Geronimo deployment plan in each type of archive file. Geronimo lets you choose where to place these deployment plans:

• Inside the archive, together with the associated deployment descriptor, as shown by the dotted square in Figure 2
  
  
• Outside the archive, as an independent XML file, and specified as input when you use the deployment tool to deploy the archive

If you locate the deployment plans outside of the archive, you don't need to use the name specified in the third column of Table 1; you can use any filename for the plan. Taking the deployment plans out of the archive has several advantages:

• The archive files themselves remain generic J2EE archives, capable of being deployed on any compliant server.
  
  
• Changes are easy to make, without the need to extract, modify, and rearchive the deployment plans.
  
  
• You can make changes graphically using a tool that in turn edits the file. This can be a JSR-88 compliant deployment tool or even an automated system-management agent.

One minor disadvantage of having external deployment plans is that until automated tools become available, they require manual tracking to keep alongside the related archive files.

For a glimpse at what happens inside Geronimo when you deploy a J2EE module, see Deployment plans, configurations, and builders.

Back to top

The Really Big Pet Store example

Now that you understand the relationship between deployment descriptors and Geronimo deployment plans, you're ready to deploy a Web application to Geronimo. The example I'll use throughout this article is called the Really Big Pet Store. It's a part of an e-commerce application, and it displays a catalog and handles a simple shopping cart. The store isn't big; in fact, it's very small. However, the store sells really big pets. See Figure 3 for a sample of the store's inventory:

You'll work through three versions of this example, each one successively more complex and each using a different J2EE package for deployment:

• A self-contained Web application. It includes servlets, JSPs, and a JSP tag library but doesn't use any external resources. This version is archived in a WAR.
  
  
• A modification of the first version that accesses an EJB for its product-category information. The EJB is a session bean, and it has a local view. This archive is bundled in an EAR file.
  
  
• A further evolution of the second version, in which the session EJB becomes a facade for an entity EJB. The entity EJB is an EJB2-complaint entity bean that uses CMP to access a relational database. The application is bundled in an EAR file. However, it needs to make use of a resource adapter -- a JDBC connector -- archived in a RAR file. See Downloads for the Really Big Pet Store source code.

Deploying a WAR

The first version of the example is archived in reallybigpet.war, which you can find in the war_only\dist directory of the code distribution. Table 2 shows the components in this version of the application. All of these components are also used in later versions, with changes noted where applicable.

Using Table 2 as your guide, you can examine the various source code files in the distribution to see how things work. Your main interest here is to deploy and run this application on Geronimo. Figure 4 shows what happens when the application is deployed:

In Figure 4, Geronimo's deployer tool is used to deploy the module, perhaps together with a Geronimo deployment plan, to the target server. The server saves the metadata to a configuration store and the executable code to a binary repository. This lets the server restart with the same configuration, should it be terminated for any reason.

Start Geronimo by going into the Geronimo installation directory and entering the command:

java -jar bin\server.jar

You can also add the name of a configuration at the end of the command to start a specified configuration (see Part 1 for the definition of configuration). The default system configuration is adequate for the purpose of this example. You can list all the modules that are running in this configuration by using the command:

java -jar bin\deployer.jar list-modules

The tool prompts you for username and password. Use system for user and manager for password. Note that the deployment tool itself is used to list the modules. A batch file, called lm.bat, is supplied with the distribution to reduce tedious typing.

To deploy the reallybigpet.war archive, first copy the Web application to the Geronimo home directory, and then issue the command:

java -jar bin\deployer.jar deploy reallybigpet.war

You can also use the dp.bat batch file to save some typing. After a little while, the deployment tool should return and report that deployment is successful. Note that it is not necessary to use a separate geronimo-jetty.xml deployment plan in this case. The default plan for WAR files provided with Geronimo works fine here. If you execute the list-module command again, you'll see the module running. The default name is reallybigpet, the same name as the JAR file.

You can try out the application using the URL http://localhost:8080/reallybigpet/store.cgi.

Controlling the deployed module's lifecycle

You'll recall from Part 1 that GBeans can optionally have their lifecycle controlled by Geronimo. You can use this feature to control the Web application's behavior. To stop the application, use the command:

java -jar bin\deployer.jar stop reallybigpet

If you try accessing the store URL after the application is stopped, Geronimo will not respond. To start it again, use the command:

java -jar bin\deployer.jar start reallybigpet

To completely remove the binaries and the metadata for this module from Geronimo, use the undeploy command:

java -jar bin\deployer.jar undeploy reallybigpet

Once you have undeployed the module, you must deploy it again before it becomes available. If you are updating an already deployed module, you can use the redeploy command. It effectively undeploys the existing version and deploys the new one you specify -- in one step.

Deploying an EAR

The second version of the example application adds a stateless session EJB into the mix. The controller servlet accesses this EJB to obtain the list of categories to display. If you want to examine the source code, look under the ejb directory:

• CategoriesHomeLocal.java is the home interface.
• CategoriesLocal.java is the object interface.
• CategoriesBean.java is the EJB's implementation

You can see the description of the new session bean in the ejb-jar.xml deployment descriptor, shown in Listing 1:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 
'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
  <enterprise-beans>
      <session>
          <display-name>Categories Stateless Session Bean Local Interfaces</display-name>
          <ejb-name>CategoriesEJB</ejb-name>
          <local-home>com.ibm.dw.reallybigpet.ejb.CategoriesHomeLocal</local-home>
          <local>com.ibm.dw.reallybigpet.ejb.CategoriesLocal</local>
          <ejb-class>com.ibm.dw.reallybigpet.ejb.CategoriesBean</ejb-class>
          <session-type>Stateless</session-type>
          <transaction-type>Container</transaction-type>
      </session>
  </enterprise-beans>

</ejb-jar>

The StoreController calls the getCats() method from the ReallyBigPetStore class to obtain the categories and set the cats attribute, as shown in Listing 2. This attribute is used by bigpetstore.jsp to display the categories.

package com.ibm.dw.reallybigpet;
...

public class StoreController extends HttpServlet {
    
   ....
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
          throws ServletException, IOException {
        ...       
        ArrayList cats = ReallyBigPetStore.getCats();
        session.setAttribute("cats", cats);
        ...
        }   
        ...    
    }

Instead of generating its own data, ReallyBigPetStore now accesses the session bean to obtain the categories information. Listing 3 shows the code that accesses the EJB:

package com.ibm.dw.reallybigpet;
import java.util.*;

import com.ibm.dw.reallybigpet.ejb.CategoriesHomeLocal;
import com.ibm.dw.reallybigpet.ejb.CategoriesLocal;
import  javax.naming.InitialContext;
import javax.naming.Context;

public class ReallyBigPetStore {
    public ReallyBigPetStore() {
    }
    public static ArrayList getCats() {
    CategoriesLocal cl = null;
    try {
      Context ic = new InitialContext();
      Object o = ic.lookup("java:comp/env/CatEJB");  
      CategoriesHomeLocal ejbhome = (CategoriesHomeLocal) o;
        cl = ejbhome.create();
    } catch (Exception ex) {
      ex.printStackTrace();
      }
    
   return cl.getCats(); 
    }
  }

The deployment descriptor for the WAR archive now needs to reference the session EJB. The new web.xml is shown in Listing 4, with the additional <ejb-local-ref> element.

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
      http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">
    ...   
    <ejb-local-ref>
        <ejb-ref-name>CatEJB</ejb-ref-name>
        <ejb-ref-type>Session</ejb-ref-type>
        <local-home>
        com.ibm.dw.reallybigpet.ejb.CategoriesHomeLocal
        </local-home>
        <local>com.ibm.dw.reallybigpet.ejb.CategoriesLocal</local>
   </ejb-local-ref>
</web-app>

The application.xml deployment descriptor for the EAR, shown in Listing 5, specifies the archives within the EAR and provides a context root for the application:

<application 
       xmlns="http://java.sun.com/xml/ns/j2ee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
       http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"
       version="1.4">
    <module>
        <ejb>bigpetstore-ejbs.jar</ejb>
    </module>
    <module>
        <web>
            <web-uri>reallybigpet.war</web-uri>
            <context-root>/ReallyBigPetStore</context-root>
        </web>
    </module>
</application>

You can now deploy reallybigpet.ear (from the dist directory, but make sure you have undeployed the previous example first).

Surprisingly, even though the archive contains EJBs external to the WAR, you don't need to create an additional geronimo-application.xml deployment plan for the module to work. The reason is that Geronimo will try its best to facilitate deployment. It actually matches up the EJB by examining the home and object interfaces when resolving the reference.

Deploying the TranQL connector in a RAR

The final version of the application involves another EJB. This time it's an entity EJB that uses CMP2 and EJB-QL to access relational database data. This external dependency makes setup significantly more complicated.

You need to set up a relational database with the appropriate data. The addtab.sql script can be adapted to your RDBMS. The script, shown in Listing 6, works for MySQL Server:

drop table petcats;
create table petcats (
  id varchar(20) NOT NULL,
  name varchar(50) NOT NULL,
  PRIMARY KEY (id)

  )               ;
INSERT INTO petcats VALUES( '1', 'New');
INSERT INTO petcats VALUES( '2', 'Clearance');

Next, you need to find the JDBC driver for your RDBMS and copy it to a subdirectory under Geronimo's repository directory. For example, you copy the MySQL driver in this example into repository\mysql\jars directory.

To deploy a JDBC connector, you'll use the connector from TranQL, which is part of Geronimo. The connector provides connection pooling and loads the JDBC driver you specify. To configure this connector, you need a Geronimo-specific deployment plan, because there's no way Geronimo can guess which JDBC driver you want to use. Take a look at the geronimo-ra.xml file under the ddcmp directory. Listing 7 shows part of this file:

<?xml version="1.0"?>
<connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector"
   version="1.5" configId="PetsDB" parentId="org/apache/geronimo/Server">

  <dependency>
    <uri>mysql/jars/mysqldriver.jar</uri>
  </dependency>
  <resourceadapter>
    <outbound-resourceadapter>
      <connection-definition>
        <connectionfactory-interface>
          javax.sql.DataSource
        </connectionfactory-interface>
        <connectiondefinition-instance>
          <name>PetsDataSource</name>
     ...
  </resourceadapter>

</connector>

In geronimo-ra.xml, you must edit the entry and configure the connector to your JDBC driver requirements. Note the use of the configuration ID of PetsDB in this case.

Now you can deploy the resource adapter. Use the command:

java -jar bin\deployer deploy repository\tranql\rars\tranql-connector-1.0-M4.rar  
  geronimo-ra.xml

You need to look in the repository\tranql\rars directory to see the exact name to use, because it will vary between the most recent milestone and the latest build. (See Geronimo's milestone builds and Getting the latest Geronimo build for more information.) After successful deployment, you can perform the list-module command and see that the PetsDB configuration (module) is now running.

The Geronimo system starts an instance of a Derby RDBMS (see Resources) as the system default data source. You can use this database instance for this example. See the README.TXT included with the source code distribution for more information.

Geronimo configurations and classloaders

When you include a Geronimo deployment plan, as in the resource-adapter example, you can specify a configuration ID (the configId attribute) and a parent configuration ID (the parentId attribute). This lets you establish a classloader hierarchy, enabling you to share code between separately deployed modules. Figure 5 illustrates a configuration hierarchy:

In Figure 5, configuration A is the parent of configuration B, and Configuration B is an EAR module that contains a WAR file. The white circles represent Geronimo classloaders (actually a URLClassloader). In this case, configuration B's classloader is a child of configuration A's classloader, allowing code in configuration A to be accessed by configuration B. A WAR file always has its own classloader, preventing other code in the same EAR from accessing the classes inside the WAR.

Deploying a CMP2 EJB in an EAR

The last version of the Really Big Pet Store example uses an entity EJB to obtain its categories information. The session bean now accesses the new entity EJB for categories information. The source code for the entity EJB is in the ejbcmp directory:

• CategoryHome is the home interface.
• CategoryRemote is the remote interface.
• CategoryBean is the EJB's implementation.

The key to mapping a CMP2 EJB is in the ejb-jar.xml deployment descriptor shown in Listing 8:

<?xml version="1.0" encoding="US-ASCII"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
    http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"
    version="2.1">
    ...
    <enterprise-beans>
 
        <entity>
       ....
            <ejb-name>CategoryBean</ejb-name>
            <home>com.ibm.dw.reallybigpet.ejb.cmp.CategoryHome</home>
            <remote>com.ibm.dw.reallybigpet.ejb.cmp.CategoryRemote</remote>
            <ejb-class>com.ibm.dw.reallybigpet.ejb.cmp.CategoryBean</ejb-class>
            <persistence-type>Container</persistence-type>
            <prim-key-class>java.lang.String</prim-key-class>
            <reentrant>false</reentrant>
            <cmp-version>2.x</cmp-version>
            <abstract-schema-name>CategoryBean</abstract-schema-name>
            <cmp-field><field-name>id</field-name></cmp-field>
            <cmp-field><field-name>name</field-name></cmp-field>
            <primkey-field>id</primkey-field>
            <resource-ref>
                <description>
                    This is a reference to a JDBC database.
                </description>
                <res-ref-name>jdbc/basic/entityDatabase</res-ref-name>
                <res-type>javax.sql.DataSource</res-type>
                <res-auth>Container</res-auth>
            </resource-ref>
            ...
            <query>
                <query-method>
                    <method-name>findAll</method-name>
                    <method-params/>
                </query-method>
                <ejb-ql>
                <![CDATA[SELECT OBJECT(a) FROM CategoryBean AS a]]>
                </ejb-ql>
            </query>

        </entity>

     </enterprise-beans>
</ejb-jar>

In Listing 8, you can see the specification of the entity bean's persistent fields. Also, the findAll() method is specified to fetch all the categories from the backing RDBMS, using EJB-QL.

To properly deploy the entity bean, you need to create a Geronimo deployment plan -- an openejb-jar.xml file, shown in Listing 9:

<?xml version="1.0"?>
<openejb-jar
    xmlns="http://www.openejb.org/xml/ns/openejb-jar"
    configId="com/ibm/dw/ReallyBigPet"
    parentId="PetsDB">
    <cmp-connection-factory>
        <application>null</application>
        <module>PetsDB</module>
        <name>PetsDataSource</name>
    </cmp-connection-factory>
    <enterprise-beans>
        <entity>
            <ejb-name>CategoryBean</ejb-name>
            <jndi-name>CategoryBean</jndi-name>
            <table-name>petcats</table-name>
            <cmp-field-mapping>
                <cmp-field-name>id</cmp-field-name>
                <table-column>id</table-column>
            </cmp-field-mapping>
            <cmp-field-mapping>
                <cmp-field-name>name</cmp-field-name>
                <table-column>name</table-column>
            </cmp-field-mapping>
            <resource-ref>
                <ref-name>jdbc/basic/entityDatabase</ref-name>
                <application>null</application>
                <module>PetsDB</module>
                <name>PetsDBPool</name>
            </resource-ref>
        </entity>
    </enterprise-beans>
</openejb-jar>

Listing 9 makes the reference to the deployed PetsDB connector and specifies the exact table and field mapping. Note that this file is part of an EJB JAR inside the EAR file. It is archived together with the JAR for convenience.

You can now deploy this last version of the reallybigpet.ear application. Upon successful deployment, you can try out the application (using the URL http://localhost:8080/ReallyBigPetStore/store.cgi) and see the categories being fetched from the RDBMS.

To see the effect of updating the database table underlying the CategoryBean entity EJB, sign on to the database's command-line interface and enter the following SQL statement:

INSERT INTO petcats VALUES( '3', 'Promotional');

Now, refresh your browser and try the application again. You should see the new Promotional category becoming available immediately on the selection presented by the JSP.

Back to top

Peek inside Geronimo's JMX structure using MC4J

For a grand finale, download and install MC4J JMX console (see Resources) and see the attributes and operations exposed by your deployed Web application.

MC4J already has support for Geronimo connecting via the RMI registry. Select Create Server Connection... from the Management menu. Choose Geronimo for Server Connection Type, and enter the value system for Principle and manager for Credentials. Figure 6 shows how the Really Big Pet Store application looks through the JMX management console:

Geronimo manages deployed components as GBeans inside the container (see Part 1). In addition to having its lifecycle managed by Geronimo, a GBean can also expose attributes and operations that are manageable via JMX. These attributes and operations are exposed via JMX MBeans. Figure 7 shows how application attributes are exposed through this JMX connection:

Back to top

Conclusion

Geronimo isn't the first open source J2EE 1.4 container, and it probably won't be the last. But its unique "come and play" invitation, its elegant design, and the extensive industrial-grade, field-tested Apache codebase it can freely draw from -- combined with an enthusiastic reception by the global development community -- all differentiate Geronimo from the rest of the pack. Like the famous Apache Web server project, Geronimo will grow in time to fulfill its destiny. The project is an important symbolic statement that open source Java development has finally matured.

Back to top

Download

Information about download methods

Resources

• Read Part 1 of this series, "The J2EE 1.4 engine that could," for an introduction to and conceptual overview of Geronimo.
  
  
• Gluecode Software CTO and principal Geronimo contributor Jeremy Boynes shares his perspective on Geronimo, the direction of Java programming, and the state of open source software in this recent interview from developerWorks.
  
  
• The official site for the Geronimo project has the latest source code and binaries, and an active community on the mailing lists and wiki.
  
  
• To try out a JMX connection to your Geronimo server, download the latest version of MC4J, an open source JMX management console that works with a variety of servers.
  
  
• The Apache Software Foundation, where you can read the detailed text of the latest Apache License, is the home of Geronimo.
  
  
• For the text of alternative open source software licenses, see the Lesser General Public License and the General Public License from the GNU Project.
  
  
• Learn more about Jetty, the default servlet and JSP container integrated with Geronimo, from the project site.
  
  
• Discover Tomcat, the alternate servlet and JSP container for Geronimo.
  
  
• Explore the capabilities of OpenEJB, the EJB container in Geronimo.
  
  
• Derby is the default relational database service and JDBC provider for Geronimo. Visit the Derby project Web site for manuals, source code, and an active user community on the mailing lists.
  
  
• Geronimo uses Apache Scout to implement JAXR for Web services compatibility.
  
  
• Geronimo integrates Axis, a versatile Web services stack, to achieve compliance with the WS-I Basic Profile.
  
  
• One of Geronimo's goals is to use the same substrate to implement both EJB and lighter-weight POJO persistence. The solution is the TranQL project.
  
  
• The Geronimo team works closely with the folks at ObjectWeb for transaction support. HOWL and JOTM are the key ObjectWeb projects relevant to Geronimo.
  
  
• To handle manageability requirements, Geronimo uses the MX4J library for its JMX implementation.
  
  
• The excellent cglib code-generation library is used throughout Geronimo's interception stack, as well as for inter-GBean references.
  
  
• Geronimo uses Apache Maven to manage multiproject code builds and Apache Ant for individual project builds. Version control for most projects is managed using Subversion.
  
  
• To learn more about the Java Management Extensions (JMX), check out Sing Li's From black boxes to enterprises: JMX 1.1 series (developerWorks, Fall 2002).
  
  
• For more information on the Inversion of Control pattern and dependency injection in general, see the Spring framework.
  
  
• You can learn about an alternative open source J2EE 1.4 certified server, available under an LGPL license, at the Java Open Application Server (JOnAS) Web site.
  
  
• For the set of detailed J2EE 1.4 specifications, visit the J2EE specifications page.
  
  
• Java technology managers, architects, and developers can get a window into J2EE technologies from the J2EE pathfinder series by Kyle Gabhart.
  
  
• Read "Java liberation: An interview with Jason Hunter" (developerWorks, April 2002) to learn about the history of open source projects' participation in the Java Community Process.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• You'll find articles about every aspect of Java programming in the developerWorks Java technology zone.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Sing Li is a consultant and freelance writer. He has contributed to Beginning JavaServer Pages, Professional Apache Tomcat 5, Pro JSP - Third Edition, Early Adopter JXTA, Professional Jini, Beginning J2ME: From Novice to Professional, Third Edition, and numerous other books. He is also a regular contributor to technical magazines and an active evangelist of the VON and P2P evolutions. You can reach Sing at westmakaha@yahoo.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Slicing the Geronimo onion
• Deployment and lifecycle control
• The Really Big Pet Store example
• Peek inside Geronimo's JMX structure using MC4J
• Conclusion
• Download
• Resources
• About the author
• 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 Java on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers