Mastering J2EE Application Development Series

Step 1 of 12: Slicing and Dicing J2EE

Slicing and Dicing J2EE
by Ted Neward
Understanding your application's needs up front goes a long way toward alleviating J2EE's
complexity
There was a time not too long ago when a Java developer could walk up to a
new enterprise Java development project and know ahead of time which tools
they would use. It was all so simple then: J2EE was new, the HTML browser was
the accepted norm for user interface, and complexity, at least supposedly, was a
thing of the past. Today, it's so... complicated.
"Developers
face a
bewildering
array of
choices."
Developers face a bewildering array of choices, ranging
from the "lightweight containers" such as Spring, NanoContainer, or HiveMind,
to "web frameworks" like WebWork, Tapestry, a JSF-based UI like Oracle's
new Application Development Framework (Oracle ADF), or Velocity. Add to
that selection a whole new array of J2EE specifications themselves or the new
emphasis on "Web services" and the corresponding new buzzword "Service-
Oriented Architecture" via JAXM, SAAJ, JAX-RPC, or JAX, (not to mention the
"WS-*" specifications, tools, and libraries), and it's an outright miracle that Java
developers can get anything done.
Ben Galbraith, a speaker with the No Fluff Just Stuff Software Symposium series, calls this
phenomenon the Java Framework Uncertainty Principle: "No sooner do you pick a framework, than a
new version of some other framework gets released, thus forcing you back into the analysis of
choosing a framework all over again." It doesn't take much to complicate the picture further, either:
Just include the core J2EE and J2SE classes in the mix. After all, wasn't it just yesterday when we
were told that EJB is the "core" of J2EE and that you'd be silly to consider an enterprise Java project
without it? Exactly how do generics change your J2EE coding experience? And who let all that Java
Management Extensions stuff in the door, by the way?
What happened? Why did an industry originally so clearly focused on creating a platform formed of
best-of-breed tools and libraries get so fragmented in such a short period of time? When do we
choose between traditional "J2EE" tools like EJB, as opposed to the new crop of "Web service" tools
like JAXRPC and WS-Security, and, more important, what can we do now to avoid Ben's Java
Framework Uncertainty Principle without losing sight of the vendor-neutral principles that Java
espoused in the first place?
Much of the problem lies in knowing which technology best addresses which needs, and the best
way to do that is to figure out what your application's needs are in the first place. Once that's done,
the appropriate technology choices become more cleanly defined and easily understood.
In this article, I'll take a broad-brush overview of the J2EE state-of-the-art, the surrounding
technologies around it, and some of the architectural challenges a Java developer faces today.
Where are We Trying to Go Today?
A lot of different kinds of Java-coded programs tend to get lumped under the term "enterprise Java,"
and it helps to perhaps distinguish them from other kinds of Java applications before we get too far
with this discussion. If we start from the traditional "3 layer" approach, where we separate out
Presentation, Business Logic, and Data Access concerns into three coherent striations of design,
then we can identify essentially five kinds of "enterprise" Java applications: stovepipes, jewels,
aggregators, integrators, and enterprise apps.
"We can
identify
essentially
five kinds of
"enterprise"
Java
applications:
stovepipes,
jewels,
aggregators,
integrators,
and
enterprise
apps."
Stovepipes A stovepipe application (also called a "silo") is probably the
easiest for developers to recognize, because it's one app we've all done over
and over again: it's the traditional "single database, single UI" application that
currently, in terms of sheer numbers, is the most popular kind of IT application
being built. It usually starts out with a desire by some department manager or
sub-manager looking for some specific tool or application to gather,
manipulate, and display some kind of data that's not currently being gathered,
manipulated, and displayed, so a team (usually a size not larger than three or
four people, and often just one person) is formed to gather requirements, form
use cases, build the database, code the business logic, deploy it to the
machine chosen to act as the production server for this app, and keep an eye
on it from time to time.
The name, of course, derives from the picture you get when you draw the
three boxes representing the logical layers of the systemPresentation,
Business Logic and Data Accesson a whiteboard, since they form a straight
vertical line, reminiscent of the old "stovepipe" that carried smoke from the
wood-burning stove to outside the room. (And, by the way, to those who
would use this term in a derogatory fashion, remember that many of the most
important systems you will ever use in your lifetimesuch as the ATM machine, the package locator
on major shipping company sites, and so onare stovepipe systems.
As amazing as it may seem, the J2EE software stack doesn't serve developers building the simple
stovepipe system well. When only one presentation layer is required, and only one resource is used
to store and retrieve data, the complexity of the J2EE stack, particularly EJB, just seems to "get in
the way." It becomes more tempting to consider the lightweight frameworks, because they don't
focus as much on deployment descriptors, and there's no awkwardness regarding JNDI, JMS, or any
of that other stuff. It's just basic, request/response communication from the web browser, typically
built in something like Struts or similar MVC-style web framework, talking to business logic
centralized in a set of core Plain Old Java Objects, sometimes with both Presentation and Business
Logic layers (if not the database itself) running on a single machine. (You may wonder why the term
"database" doesn't show up here. The simple reason is that while most projects use a database (and
a relational one at that) to store data, frequently the data store is instead a legacy system,
commercial software package, or "broker" technology, a la a CICS mainframe, SAP, or BizTalk.
Using the more generic term "resource" helps reinforce the idea that the back-end implementation is
really irrelevant at this level of discussion.)
Stovepipes also have the advantage that they tend to "stand alone"there are no other players
involved. There's little need to conform to any established standard for security, reliability, or
management, since whatever this application defines will be the standard (at least, for this
application, and that's all that matters at this scope). Developers frequently take advantage of this
fact to build infrastructure that's "just good enough" for this application, thus eliminating the
accusation most frequently leveled at enterprise Java applications: that they're too complex to use
and maintain.
Despite the desire to label it as such, the stovepipe application scenario isn't quite what J2EE was
designed to addresscertainly a J2EE-based application can build this kind application (and there
are thousands out there that stand as testament to that fact), the truth of the matter is, it's somewhat
like using grenades to go fishing. A J2EE-based application enforces a certain separation of layers,
and sometimes this is just overkill to the problem at hand, as in the traditional "10-user" stovepipe
system. The problem, of course, is that the 10-user stovepipe system has this annoying tendency to
morph into one of the other four versions, and this when things start to get hairy. Like the philosopher
who said "no man is an island," we can fairly easily and accurately say, "no system is an island", as
well. At least, not for long. (Of course, if the system fails to accomplish its desired aim, then it
typically doesn't get integrated with anything else and probably won't stay long in production, but we'll
assume that's not a desired aim.)
Jewels No, not in the sense that this is the pride and joy of the IT environment or the "best" of the
five, the jewel style of application is one in which multiple presentation layers kick in (thus its name--a
"jewel" has lots of facets through which one can look). Note, however, that a given presentation layer
may not be something for users to look at at all; one layer that companies are frequently found
discussing these days is a Web-service-based front end to their application, which isn't intended for
human consumption whatsoever. Despite this fact, the Web service still represents a presentation
layer, since it's fundamentally doing the same thing: taking input for and providing output from the
core Business Logic layer underneath it.
Jewel applications present some interesting twists to the traditional programming model, because
suddenly certain assumptions that used to be in place can't be anymore. For example, when
considering a Web service front-end, it's suddenly necessary to define types in some kind of
platform- and language-neutral fashion (XML Schema is the current tool of choice here), and ideally
the Once-and-Only-Once rule--also known as the Don't Repeat Yourself principle--would allow us to
build this directly from the same types the HTML-based Presentation layer uses to talk to the
Business Logic layer. This is where some of the JAX* specifications come to play--the Java API for
XML Binding, for example, helps to define a standard way of doing object-to-XML-and-back-again
transformations in a fairly opaque way, and the Java API for XML RPC (JAX-RPC) defines a way of
building interoperable request-response remote communication layers using WSDL, SOAP and XML.
While nothing stops a developer from using the JAX* specifications from their favorite lightweight
container, the J2EE 1.4 Specification directly incorporates JAXRPC and JAXB into its overall
technology suite, making it possible to expose an EJB stateless session bean as a WSL 1.1/SOAP
1.1 RPC/encoded Web service. (Note that according to the WS-Interoperability Basic Profile
specification, RPC/encoded services are officially deprecated in favor of document/literal ones; this
difference is widely expected to be fixed in the next round of JAX* and J2EE specifications, and
concrete implementations should be hitting the street about the same time that developers actually
figure out the difference between RPC/encoded and document/literal services.) What's more,
commercial application server vendors are taking great pains to ensure their offerings are not only
fully compatible with the J2EE standards, but with the Web service standards as well. This is clearly
an area where "compatible-yet-competitive" describes best the vendors' motivations (including those
of J2EE's principal competitor, from that little-known software company in the Pacific Northwest).
By the way, when looking to build a Web service Presentation facet, it bears pointing out that it's
tempting to expose the Model objects of the system directly as XML types, using JAXB or Oracle's
XML Developer's Kit, and essentially code-generate the entire Web service front end as a large
WSDL document. While this may seem like a good validation of one's Business Logic layer at
firstafter all, if there really aren't any business rules in the Presentation layer, then it shouldn't be a
hardship to take this approachlimitations in the Web services technology stack quickly make this
prospect difficult.
Consider, for example, the relationship of reference-based objects to XML: How should we best
represent a java.util.Date reference whose value is null in XML? Particularly when in .NET a Date
isn't a reference-based object at all, but a "value type,"meaning that it acts much like an int does in
Java? Things get particularly sticky when trying to represent complex cyclic graphs of objects in
XML, which is one reason why RPC/encoded was deprecated in the first place. This is all part of the
ongoing work behind the WS-* suite, but even if a team were to decide to "go their own way" and
build their own XML-over-HTTP system, they're going to face the same core problem. There's some
effort underway to try and incorporate object-XML mappings into core offerings, such as Oracle
Toplink, but as of yet they're still in their initial stages.
Meanwhile, we can't ignore the new trend in Presentation layer approachesthat of the "smart" or
"rich" clientdesigned to fill in that very large hole in traditional browser-based applications, "greater
responsiveness." HTML, for all its goodness, has some fundamental flaws, two of which quickly
come to mind:
G Least-common-denominator perspective. HTML was originally intended to defer
presentation decisions as late as possible, so very few elements in standard HTML actually
offer up guarantees about how the rendering will look on any given system. Attempts to give
page-builders greater control, like CSS, have met with mixed success, particularly across
different browsers.
G Presentation code as well as content must be sent. Because the browser has no inherent
knowledge of the application, the complete set of both presentation code and content must be
sent in every network round-trip to the server. This approach has two negative impacts, one
being lower bandwidth (higher consumption per client means fewer clients for the same
hardware) and the other being compromised availability (if the server or any of the
intervending topology goes down, no more application).
Toward this end, enterprise applications vendors are thinking strongly about putting Presentation
layer code onto the end-user's machine, thus eliminating part or all of two of HTML's principal
disadvantages. This creates some interesting deployment implications, however, so many shops are
looking to do both a thin-client and a rich-client Presentation layer simultaneouslythe rich-client for
use inside the company's firewall, and the thin-client for use outside of it (proving once again that you
can never be too rich or too thin). This approach raises the ugly specter of having to deal with two
separate frameworks, however, and at the very least we'd like to have some unified way of shuffling
data from the user's fingertips and into the back-end repository, and it would be nice if this could
somehow be standardized for both "rich" and "thin" clientshence JSR 227, a common data-binding
framework.
"We'd like
to have
some
unified way
of shuffling
data from
the user's
fingertips
and into the
back-end
repository;
hence JSR
227."
Aggregators Just as a system can offer multiple "entry points," if you will, a
system can also build on top of multiple back-ends, bringing together data from
different resources and presenting it in some coherent and meaningful manner.
(Hence the term "aggregator," since the data presented and manipulated is an
aggregate of multiple resources/databases.) And, about 30 seconds after
starting to create use cases for manipulating and storing this aggregated data,
it becomes clearly apparent that some kind of atomicity is necessary to keep
the two databases in sync with the modifications being pushed on them. This is
the very space that the Java Transaction API was created to cover (and the X/
A specifications before that), and the intersection of transactional processing
and Business Logic is what EJB was created to deal with.
It's more than just transactions, however. Multiple resources covers more than
just two different databasessometimes a system needs a higher reliability
than a single database machine can provide. After all, a single machine
anywhere in the system represents a single point of failure, and frequently, all
"hot-swapping" failover scenarios aside, we just need to take the database down to perform some
scheduled maintenance on itwhich can include new schema changes to accommodate a code
rollout, by the way. The Java Naming and Directory Interface (JNDI) serves as a single API for all
"lookup" operations, providing a layer of indirection from the actual underlying physical database
machine, meaning that if you don't cache JNDI lookup results, an administrator can change a JNDI
entry to point from one machine to a different one, and the J2EE application will simply follow suit,
thus creating a seamless and transparent "switch" to a new database that wouldn't be possible
without that layer of indirection "baked in."
Integrators When the need arises to connect two separately maintained collections of Business
Logic, an integrator system comes into play, and it becomes necessary to start thinking about
interoperability in ways that a stovepipe system never needs. For example, if it's necessary to do
traditional request-response service, how will the request and response be carried out? Frequently,
developers immediately reach for the WS-* set of services, but as mentioned above, sometimes the
WS-* specs are too much (and too under-baked in current implementations) to reliably serve the
integration/interoperability need. Again, the J2EE Specification covers this base, by requiring every
EJB container to be CORBA call-compliant, meaning that any CORBA client can interact with the
Business Logic encapsulated in an EJB container.
Not all integration occurs in a request-response fashion, however. In order to avoid the bottlenecks
implicit in the synchronous nature of RPC and request-response communications, many systems
choose to integrate with one another using a messaging-based approach, which is the province of
the Java Messaging Service specification (and associated implementations, such as Oracle's
Advanced Queueing), and/or the Java API for XML Messaging (JAXM) and its associated SOAP API
for Attachments in Java (SAAJ), for doing "messaging with angle brackets."
The database itself serves as an integration layer as well, though not in the same sense as the
traditional RPC or message-driven system. In many cases, integration and interoperability is just a
matter of getting data from program "A" to program "B," and the database (along with other
resources) frequently serves as a useful-and well-understood lingua franca for different
platforms, most notably J2EE and .NET. While it doesn't address all interoperability needs, for many
systems this approach is just "good enough"which carries its own share of benefits, particularly
when Business Logic is embedded into the database (via a stored procedure). Furthermore there's
no need for .NET to figure out how to call Java code residing in an EJB server, or Java to figure out
how to call .NET code residing in a COM+ ServicedComponent, or how to share a single distributed
transaction ID between them, and so on. Particularly in view of the fact that Oracle has made it easy
to write stored procedures by letting you write them in Java instead of PL/SQL.
Enterprise apps Finally, we get to the "true" enterprise application, which turns out to be an
amalgamation of multiple facets of all three layers: Presentation, Logic, and Data Access. The
traditional enterprise system is one which needs to present data from multiple resources in a variety
of formats using a collection of business rules stretched across multiple applications, languages, or
platforms. This space is the one in which we find the greatest complexity, and it's here that J2EE
really shines. Once here, the apparent "over-complexity" of the J2EE Specification and its associated
technologies becomes more appropriate, because with complexity comes power (and flexibility).
Portals, for example, frequently fall into this category, as they have a tendency to have need for
multiplicity at all three layersPresentation, in that the portal is often bringing
together different web applications from all across the company (or departments, or different
companies, maybe even different mob families), Business Logic, in that sometimes a given "portlet"
will want or need to call functionality exposed by a different portlet's back-end, and Data Access, in
that most portlets have their own database (or set of databases, just to make things more interesting)
against which they need to interact, but more interestingly, often a given user's session needs to
track in-progress information even as the user moves back and forth between the various portlets. In
a lot of ways, the portal and its associated portlets is the epitome of the enterprise application.
"In a lot of
ways, the
portal and
its
associated
portlets is
the epitome
of the
enterprise
application."
Where Does That Leave Us?
This sort of categorization is nice enough in itself, and certainly keeps
technology philosophers occupied for a little while longer, but what, precisely,
does that have to do with building enterprise Java applications today?
First and foremost, it's important for enterprise Java developers to figure out,
as quickly as possible, which of the above five kinds of applications they're
being asked to build. If it's a traditional stovepipe system, the choice of
technology isn't as crucial as it will be for any of the other four. When the Web
services question comes up, recognize it as another Presentation layer
(meaning now you're looking at a jewel app) and not simply as an extension of
your Model objects used between the Struts code and the Business Logic. In
fact, in a lot of ways, the Model-View-Controller pattern is part of the Presentation layer itself, and
isn't something that stretches into the Business Logic layer, since doing an effective "different"
Presentation layer will typically require that we make different choices about how we interact with the
back-end, such as (in the case of Web service) leaving the "object-oriented" nature of the system
behind.
When the question of multiple database or other back-ends come up, think about failure atomicity
and the need for distributed transactions to achieve that atomicity, and the failover implications of
having a good hot-swappable layer of indirection for accessing resources. When integration between
existing systems becomes an issue, remember that there are more options than just Web services
(although the Web service approach is quickly becoming viable and more assumed to be the norm),
and keep in mind messaging-driven systems as well as the possibility of putting Business Logic into
the database itself to make it more accessible to other platforms needing to integrate with the
system.
Remember that J2EE is only a means to an end, and that to be dogmatic about any technology is
usually to miss the point of the technology as a whole. Don't look to use EJB on stovepipe systems,
for example, since EJB's principal focus is on transactional processing (and, in particular two-phase
commit transactional processing, which is expensive but necessary to obtain atomicity across two or
more resources as part of the same transaction), but don't neglect its use when the aggregator
application rears its head at you. Don't try to code everything as a session bean when the
asynchronous nature of JMS (and message-driven beans, when transactional processing is required)
better serves the purpose. And so on.
Second, make sure to always keep in mind precisely what the application's performance and
scalability goals are (see my book Effective Enterprise Java). While this is always important for any
application written in any language, it's even more so in the enterprise Java space, precisely because
of the wide array of technology choices of available to the enterprise Java developer. Does your
system need to deliver sub-second responses on every user action? This goal will be hard for a
browser-based application to meet, particularly across a WAN, since it often takes about a second for
the HTML browser to process an even moderately-complicated HTML page; perhaps a better
approach would be to consider a "rich client" front-end, delivered via JavaWebStart, so as to keep
Next Steps
Bookmark: The Mastering
J2EE Application Development
Series: Join top J2EE experts
over the next 12 weeks as they
present techniques to help you
develop, debug, and deploy
J2EE applications and web
services quickly and easily.
Oracle JDeveloper 10g
Reviewer's Guide: Learn how
to use Oracle JDeveloper 10g
to develop J2EE applications
with this step-by-step guided
tour.
Get started with Oracle
JDeveloper 10g: Use the
resources on this link to get
started with Oracle JDeveloper
10g.
Jump Start your J2EE
deployment with OC4J 10g
(J2EE 1.4 compatible) : Get up
to speed with the new
capabilities available in the
OC4J 10g Developer Preview
Oracle TopLink: Learn how
Toplink provides a highly
flexible and productive
mechanism for storing Java
objects and Enterprise Java
Beans (EJBs) in relational
database tables
Downloads
G Oracle JDeveloper 10g
G Oracle Containers for
J2EE
the amount of data traveling across the wire as small as
possible, and the response time once that data is received as
short as possible (thus avoiding the need to parse the
presentation elements).
Need to reach a forecasted 10 million users all across the
Internet? The user interface definitely needs to change,
thenJava's lack of ubiquity on the average consumer's PC
makes WebStart impractical in such situations, and perhaps an
applet or traditional HTML becomes more appropriate.
However, scaling to this number of users means that
developers need to pay careful attention to the response time
per each request at high loads, and perhaps built the user
interface differently to avoid making frequent round-trips back
to the server. And so on.
Third, keep in mind that the Java developer's toolset is
constantly evolving, and much of the work over the last half-
decade has been in the direction of the J2EE space, looking
for ways to make it simpler and easier to define J2EE
components. This area is one where a large commercial
vendor has an advantage over an open-source project, in that
the vendor can create a complete end-to-end development
experience around their commercial offerings, where an open-
source project has a tendency only to scratch the itch as far as
the development team's experience is concerned, and then
stop. Witness some of the new features coming in Oracle ADF
compared with trying to build a JSF application in Eclipse, for
example. Or look at defining a Web service in JDeveloper
against writing the .wsdd files in Axis. The tools are getting
better, and we can only expect this trend to continue, because
it's in the vendors' best interests to keep it up.
"The tools
are getting
better, and
we can only
expect this
trend to
continue,
because it's
in the
vendors'
best
Last, but not least, keep an eye on this
space for future articles in this series,
which will cover topics ranging from
modeling and design to the art of
debugging to optimizing/profiling your
code (which will be much easier now that
you've defined those performance and
scalability goals).
Most important, relax. Life's too short.
Conclusion
G Oracle TopLink
G Oracle BPEL Process
Manager
G Java Object Cache
G Oracle Workflow for
Java
G Oracle Application
Server Portal
interests to
keep it up."
While the enterprise Java world can
sometimes seem like a bewildering forest
of specifications, implementations, de
facto standards and frameworks that seem to follow flavor-of-
the-month favoritism, take a deep breath and realize that for
any of the five types of applications, any of the available Java/
J2EE technologies can be made to work (and work well).
Ted Neward [ted@neward.net] is a consultant, mentor,
speaker, author and all-around geek who specializes in enterprise Java/J2EE, Web service and .NET
systems, with particular focus on interoperability between J2EE and .NET.
Copyright 2005, Oracle. All Rights Reserved.