Java Reference
In-Depth Information
programming model. Similarly, many “enterprise programmers” don't work for partic-
ularly large corporations.
What's different about enterprise applications? In general, they're designed to sup-
port multiple simultaneous users. With multiple users, some sort of remote access is
usually required—having 50 users crammed into a single room isn't going to make
anyone happy! Nowadays, remote access almost always means a web frontend.
To store the information associated with these users, enterprise applications usu-
ally persist data. Writing database access code isn't much fun, so persistence providers
supply a nicer set of interfaces to manage the interaction between the application
code and the database.
This is a business application, and so transactions are usually involved—either buy-
ing and selling of goods and services, or some other business agreements. To ensure
these “real” transactions proceed smoothly and consistently, even in the event of a
communications problem, software transactions are used.
With all this going on, these enterprise applications are starting to get pretty com-
plex. They're not going to fit into a single Java class, or a single
JAR
file. It may not
even be practical to run every part on a single server. Distribution allows the code, and
therefore the work, to be spread across multiple servers on a network. Some people
argue that distribution is
the
key feature of what's known as enterprise computing, and
the other elements, like transactions and the web, are merely there to facilitate distri-
bution (like the web) or to handle some of the consequences of distribution on net-
works which aren't necessarily reliable (such as transactions).
Java
EE
provides a fairly comprehensive set of standards designed to fit the scaling
and distribution requirements of these enterprise applications, and is widely used
throughout enterprise application development.
MODULAR JAVA EE—BIGGER ISN'T BETTER
Our enterprise application is now running across multiple servers, with a web fron-
tend, a persistence component, and a transaction component. How all the pieces fit
together may not be known by individual developers when they're writing their code.
Which persistence provider will be used? What about the transaction provider? What
if they change vendors next year? Java
EE
needs modularity for its applications even
more than base Java does. Running on different servers means that the classpath,
available dependencies, and technology implementations are likely to diverge. This
becomes even more likely as the application is spread over more and more systems.
With these interconnected applications, it's much better for developers to avoid
specifying where all their dependencies come from and how they're constructed. Oth-
erwise the parts of the application become so closely coupled to one another that
changing any of them becomes difficult. In the case of a little program, this close cou-
pling would be called spaghetti code (see figure 1.2 again). In large applications, it's
sometimes known as the
big ball of mud
. In any case, the pattern is equally awkward and
the consequences can be just as severe.
