J2EE is a platform-independent environment designed for developing and deploying Web-based applications for enterprise-wide use. The platform has been likened to a meta language or language superset. But at its core, J2EE is simply the Java programming language and a specific, minimal set of Java classes. (See Resources for a link to the class documentation for J2EE.)

J2EE consists of application program interfaces (APIs), services, and protocols for developing multitiered, Web-based applications. It's a complex standard, and writing an article that proposes to simplify it is a little like writing an article on simplifying the United States tax code -- not an easy task. But by working from first principles to a few implementation details, the journey can be enlightening. Buckle up, and let's get started!

First principles

The client layer of the J2EE multitiered design is represented by the pure HTML protocol -- generated by JavaServer Pages (JSP) and Java servlets -- and potentially deploys Java applets with the transporting protocol being, of course, TCP/IP. Any standard-conforming Web browser should be able to perform just fine as a client of the J2EE system.

The server layer contains Enterprise JavaBeans (EJB) technology in which the platform logic of the enterprise applications is defined. The EJB servers provide functionality for threading, concurrency, memory management, and security and do these things automatically so as not to burden the application programmer with the details. It's here that the power of the J2EE design is realized.

In the lowest layer is the core of the enterprise's precious data where standard database tools, such as IBM® DB2®, Oracle, MySQL, or any number of other Structured Query Language (SQL)-based database engines are accessed through the Java Database Connectivity (JDBC) interface.

J2EE has a large focus on Web services -- a fancy way of saying two or more applications can integrate and exchange data with each other in a standards-based fashion. J2EE is a veritable alphabet soup of technologies, each described by a catchy acronym. There's no need to master all these technologies to enjoy a productive career in a J2EE environment, but programmers can always advance their careers by learning more about them.

Back to top

Quick reference: J2EE technologies

What follows is a quick reference to some of the many J2EE technologies. Programmers who have mastered all these technologies are in great demand in today's job market. The technologies are ordered by what I consider levels of importance and by simplicity of deployment -- purely subjective opinions, of course.

I provide this list both to illustrate the complexity of J2EE and to provide a crude map of the order in which you should proceed in learning these technologies. The important technologies are:

• JSP: Files that are HTML templates with inline Java code compiled into servlets prior to execution.
• EJB: Represents the platform logic of the enterprise Web application. Two types of EJB technology are entity beans and session beans.
• JDBC: An API for connecting to databases from the Java environment. It's the Java programmer's alternative to Open Database Connectivity (ODBC).
• Java API for XML Processing (JAXP): Designed to assist applications in parsing and transforming XML documents.
• Java Naming and Directory Interface (JNDI): Defines methods that perform directory operations, such as searching for objects using their attributes and associating attributes with objects.
• Java API for XML-based Remote Procedure Call (JAX-RPC): Allows developers to create clients and services that the Web Service Description Language (WSDL) describes. WSDL describes services as a set of endpoints operating on messages and is defined in XML.
• Java API for XML-based Web Services (JAX-WS): Similar to JAX-RPC in that it enables developers to implement clients and services described by WSDL, but JAX-WS requires no deployment descriptors because it uses annotations, such as @WebService, to declare Web service endpoints. Using JAX-WS, you can deploy a Web service without using deployment descriptors!
• Java Architecture for XML Binding (JAXB): Provides a binding compiler and a runtime framework to map Java objects to XML documents. This functionality makes it possible to ensure that the system accepts and processes only valid messages. The compiler automatically translates World Wide Web Consortium (W3C) XML schemas into Java classes, keeping you from having to write any complex parsing code.
• Java API for XML Messaging (JAXM): Allows applications to exchange XML business documents over the Internet. Examples include inventory listings, invoices, and countless other business documents necessary for making modern businesses run.
• Java API for XML Registries (JAXR): Provides a standard API for accessing different kinds of XML registries, which are useful for building, deploying, and discovering Web services.
• Java Message Service (JMS): Allows you to write message-based applications with a consistent API that has access to the common features of many messaging system products.
• Java Management Extensions (JMX): A Java standard created specifically for monitoring and managing J2EE application services.

Back to top

Advantages of J2EE

Because J2EE was designed for enterprise-wide applications, the server infrastructure automatically handles numerous tasks for you. Among these tasks are container-managed transactions, scalability, failover management, and security control.

Container-managed relationships support both one-to-one and one-to-many relationships between entity beans. (Entity beans are Java classes that represent business objects in a persistent storage mechanism -- for example, a particular row in a database.) With one-to-many relationships, an entity bean uses a Java collection to represent the many side. The ability to manage such a relationship is similar in concept to relationship modeling in modern relational database technology.

The EJB container is important for maintaining the referential integrity of all entity bean relationships. In one-to-one relationships, the container automatically replaces the old relationship if you change one side of that relationship.

It's impossible to overemphasize the importance of container-managed transactions. Apache Geronimo conforms to the J2EE standard by providing a kernel that manages the container classes that the J2EE standard specifies.

The GBean architecture

The primary container class in the Apache Geronimo design is the GBean. In fact, almost everything in Geronimo is a GBean. In the Apache Geronimo design, the framework manages the life cycle of the GBean class. When you deploy parts into a container, you want to start and stop them. Furthermore, GBeans can have dependencies.

For example, Bean Y must be ready for Bean X to run, as Bean X must use certain services from Bean Y to function properly. In the Geronimo way of doing things, GBeans package everything that the framework must manage, especially the aforementioned dependencies. The heart and soul of Geronimo's power is in providing a framework in which developers can work with the J2EE assets they have.

By wrapping your existing J2EE resources with GBean controls, you can bridge the life cycle requirements of the J2EE standard. At the heart of Geronimo is a kernel defining an Inversion of Control (IoC) framework for GBeans. The IoC framework creates an environment in which the framework can automatically manage dependencies between components.

Assume that Listing 1 is a Web service that you're employing inside Application X. (Don't worry about the details of Application X; just assume that it will load the following class and call the doit() method.)

public class WebService { 
  public WebService(MessageContext msgc) {    
    public void doit() {
      ...
    }
  }
}

Application X has something called MessageContext, which has all the configuration information. Using the MessageContext of this WebService class, Application X can inject the MessageContext if the class has a constructor like XX(MessageContext) or uses a method, such as setMessageContext(MessageContext msgctx).

The typical J2EE container has two significant types of classes: the core services classes, such as EJB containers and Web containers, and the application classes that the core services deploy. With this two-tiered architecture, management of the secondary classes is simplified through automatic processes that the framework provides.

The behavior of GBeans reveals the nature of Geronimo's architecture. Using plans, which are essentially an XML serialization of GBeans, GBeans are loaded, started, and proceed to manage the application classes.

The deployment descriptors define the applications that the framework manages and are typically packaged as J2EE application archives. The Geronimo deployer parses those archives by constructing GBeans from them. The GBeans that the deployer constructs are then started, and viola! -- the application becomes available. Subsequently, GBeans can be serialized and stored as well, preserving state while the engine does other things. This behavior makes those deployed applications available even after you restart the server.

The GBean life cycle

GBeans typically exist in one of three states:

• Stored: The GBean exists in a plan, or configuration store, when it's in the storage state.
• Loaded: The GBean is mapped to a nonpersistent name when loaded, allowing multiple instances of the same GBean to exist.
• Running: The GBean is in the running state, coordinating the application classes that it contains.

In code, the GBean life cycle states are typically implemented as shown in Listing 2.

public class AppFunction implements GBeanLifecycle {
  public void doStart() throws Exception {
  }
  public void doStop() throws Exception {
  }
  public void doFail() {
  }
}

GBeans implement the GBeanLifecycle interface, allowing the Geronimo framework to switch the GBean states on and off and to control where their state data or running context resides at any particular moment.

General tips for writing a GBean

Here are a few tips to keep in mind when you're writing a GBean:

• To get life cycle callbacks, a GBean must implement the optional org.apache.geronimo.gbean.GBeanLifecycle interface.
• GET and SET methods can provide GBeans with attributes.
• The GBean's constructor must not call member functions that you declare in GBeanInfo.
• A GBean must implement a method with the signature:
  public static GBeanInfo getGBeanInfo()

The framework receives important metadata that the GBean uses or exposes from this method. Metadata about operations, references, and basic attributes are initialized in a static block initializer, as shown in Listing 3.

public static final GBeanInfo GBEAN_INFO;

static {
    GBeanInfoBuilder infoBuilder = new GBeanInfoBuilder("AppGbean", AppGbean.class);
    infoBuilder.addAttribute("name", String.class, true);
    infoBuilder.addAttribute("kernel", Kernel.class, false);
    infoBuilder.addOperation("echo", new Class[]{String.class});
    infoBuilder.setConstructor(new String[] {"kernel","Name"});
    GBEAN_INFO = infoBuilder.getBeanInfo();
}

You must follow the standard Java naming conventions when you're naming attributes and references:

• Attributes always begin with a lowercase character.
• References always begin with an uppercase character.

Following these rules makes the configuration of a GBean simple.

Back to top

Conclusion

To effectively program in the Apache Geronimo environment, you must understand GBeans -- Geronimo's way of conforming to the functional requirements of the J2EE standard. Geronimo, Version 1.0 has already passed the J2EE Certification Test Suite and is rapidly becoming the standard in J2EE software technology. It represents the combined efforts of many engineers from several open source projects and individual contributors from around the world. It is truly a technology worth learning.

Resources

Learn

• See Sun Microsystems' J2EE site to learn more about the standard from the company that created it.
  
  
• Check out the Apache Geronimo API to study the machine-generated class documentation comprising the standard. Of particular interest are the org.apache.geronimo.gbean and org.apache.geronimo.gbean.runtime packages.
  
  
• Read Neal Ford's "Dependency injection in Apache Geronimo, Part 1" (developerWorks, February 2006) to learn more about the important principle of dependency injection in the Apache Geronimo design.
  
  
• Read "Dependency injection in Apache Geronimo, Part 2" (developerWorks, February 2006) for further demonstration of dependency injection in Geronimo.
  
  
• Learn how the J2EE standard simplifies the creation of Web services.
  
  
• Check out the Geronimo Wiki to learn more about Geronimo and contribute to the public pool of knowledge about this important technology.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  
• Check out the developerWorks Apache Geronimo project area for articles, tutorials, and other resources to help you get started developing with Geronimo today.
  
  
• Find helpful resources for beginners and experienced users at the Get started now with Apache Geronimo section of developerWorks.
  
  
• Check out the IBM Support for Apache Geronimo offering, which lets you develop Geronimo applications backed by world-class IBM support.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  
• Browse all the Apache articles and free Apache tutorials available in the developerWorks Open source zone.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  

Get products and technologies

• Download Apache Geronimo.
  
  
• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  
• Download your free copy of IBM WebSphere® Application Server Community Edition V1.0 -- a lightweight J2EE application server built on Apache Geronimo open source technology that is designed to help you accelerate your development and deployment efforts.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Stay up to date on Geronimo developments at the Apache Geronimo blog.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the author

Bill Zimmerly is a knowledge engineer, a low-level systems programmer with expertise in various versions of UNIX® and Microsoft® Windows® software, and a free thinker who worships at the altar of logic. Creating new technologies and writing about them are Bill's passions. He resides in rural Hillsboro, Missouri, where the air is fresh, the views are inspiring, and good wineries are all around.

Rate this article

Comments

Back to top

Table of contents

• First principles
• Quick reference: J2EE technologies
• Advantages of J2EE
• The GBean architecture
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
• Buy: Rational Application Developer

Dig deeper into Open source on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

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

Special offers