Java Reference
In-Depth Information
provided. It is much easier to develop an application when its basic building blocks naturally support the concept
of a service.
Core Component Technologies
J2EE is based around three central component technologies:
Enterprise JavaBeans (EJBs), which are used for the Application Server tier.
JavaServer Pages (JSPs) and servlets, which are Web tier technologies.
The Java components, by definition, require something to act as a host for them, something to control when
they're created and how their methods are called—something to regulate their life within a system. This is the task
of the container.
A container provides the services that a J2EE component requires in order to do its job. Naturally, these services
are different depending on what kind of component technology we're talking about. For the Web tier, for instance,
a fundamental task of the container is translating between Web communications (HTTP requests) and methods
calls on the Java components. For the Application Server, on the other hand, the container manages
communication with EJBs through some protocol layer on top of RMI-IIOP.
Containers provide required services to enterprise components, but they also provide necessary services for the
enterprise application itself. One of the main motivations to develop enterprise systems based on existing
software products like Web servers, application server and databases is to leverage hard-to-code capabilities like
persistence management, security and transaction support. In today's world, there usually isn't enough time to
code these services—by the time a development wrote them, the system would already be obsolete.
J2EE-compliant products provide these services to a J2EE application in a configurable way. Better still, they
separate the services and their use from the components themselves—ultimately improving the reusability of
components in a wider range of application environments. J2EE manages the configuration of the container-based
services through XML documents. The documents provide a way to specify how the containers should handle
security, or persistence on a component-by-component basis.
Communication and the Connector Technologies
Enterprise systems, especially those designed in recent years, tend to bring groups of dissimilar technologies
together. Doing this often means managing communication between very different kinds of applications. It's not
unusual, for instance, to have an enterprise application which needs to communicate with a database, messaging
system, e-mail system and legacy system.
Of course, each technology tends to have its own communication standard, its own way of interacting with the
world. For a given kind of technology, there are often different standard communication methods, in fact. Within
the database arena, for example, nearly every RDBMS tends to have its own API. Historically, this has caused
major integration problems for enterprise systems —a large amount of effort has to be spent just getting
everything to talk together.
The way that J2EE solved the problem was to create generic communication technologies: the connector
technologies. Conceptually, connectors are Java APIs that buffer J2EE applications from the differences between
specific communication models. Java developers write their code to the API specification, which in turn is used to
link to some underlying communication layer. Often, this means that the APIs connect to an adaptor module
which in turn communicates with another application, system or service.
At a minimum, this approach can standardize communication within a technology category - JavaMail for e-mail
services or JDBC for relational database communication. Using this approach, J2EE developers can use the same
Java coding techniques when they write database code, developing implementation-neutral JDBC code. The exact
way that JDBC communicates with an associated RDBMS is handled by the JDBC driver; the API will be the
same for developer regardless of what lies beneath.
Main J2EE Resources
When we work with J2EE as developers, we naturally tend to think about it in terms of its Java technologies—as
a set of APIs that play well together. In addition to the APIs, Sun has developed a number of other standard
resources that comprise what you think of as J2EE:
Search WWH ::




Custom Search