0
At the most generic level, a business's information systems are
collections of data, otherwise known as databases. A database might
reside on one computer (with another computer able to transparently
take its place in the event of a catastrophe). Sometimes, you'll hear
this part referred to as the back-end or the Enterprise Information
System (EIS). This is where database management systems -- such as
Oracle 8, Microsoft SQL Server 2000, and other commercial, broadly
adaptable solutions -- provide persistent data storage. They also
provide access to that data via some variation of Structured Query
Language (SQL).
Having established its base of stored data, an enterprise information
system's next goal is to extract meaningful data (i.e., information)
from the databases. This represents the business-logic layer, or
business tier. To provide an over-simple example, Java classes at the
business level might be tasked with figuring out daily profit or loss.
These classes would reach into the database, extract the day's sales
and expenditure figures, and subtract. They could then present the
result -- the profit or loss -- to any authorized asker.
In the simplest case, the next level is the client application. The
client tier represents the piece of processing power that someone or
something is actually using to do useful work. It might be some sort of
reporting program that presents profit and loss figures to a manager.
This piece of the puzzle refers to processing components on the
business level for most of the values it needs (i.e., it does
relatively little processing on its own), and so can be pretty simple.
Because the client doesn't have to do much processing on its own, it
can be "thin," meaning it requires relatively few computing resources.
In the extreme case, a client can be something like a dumb terminal or
a network-connected personal digital assistant (PDA).
What's the advantage of architecture like this? Well, the use of thin
clients is a big advantage, because it frees computing resources at the
client end for other uses (or obviates the need to buy and maintain
those extra resources in the first place). This architecture also is
scalable, meaning that you can just write, in the example above, your
profit calculation class once and use it in a variety of client
applications (the reporting tool, the accounting suite, the Web-
accessible monitoring tool for store managers, and so on).
All of these pieces talking to one another in a coordinated way is the
J2EE architecture's biggest challenge, and it's a big part of what J2EE
is about. We'll discuss that in coming columns.
