 | Level: Introductory William B. Zimmerly (bill@zimmerly.com), Freelance Writer and Knowledge Engineer
15 Aug 2006 Ready for your career to take off? Regardless of the types of apps you're developing, Java™ 2 Platform, Enterprise Edition (J2EE) is an important standard that's here to stay. And mastering it can no doubt boost your value as a programmer. This article, beneficial to both new and experienced developers, gives you a primer on the J2EE 1.4 standard, to which Apache Geronimo aspires to conform, and how it relates to Geronimo technology. You'll also review some of the more important container classes defined by J2EE as well as investigate GBean technology and more advanced Geronimo concepts.
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.
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.
 |
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.
|
What is a container class?
A class of objects that contains other objects, a container class can hold objects of
any class. In fact, those objects may be container classes themselves. Simple examples of
container classes from basic Java programming include vectors or sets.
Java programmers operate on container classes by using iterator classes. An iterator
is a tool that gives you access to the objects within a container without violating
encapsulation constraints. Iterators are valuable in that they hide the details of access
from the elements of a container class. Together, container classes and iterator classes
greatly simplify the programming of complex systems.
|
|
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.)
Listing 1. The MessageContext
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.
Listing 2. GBeanLifecycle methods
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.
Listing 3. Metadata
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.
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
Get products and technologies
Discuss
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 page
| |
