Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
But first, an advisory: we won't be looking at source code or how-to topics this month. This article isn't a tutorial; rather it's an architectural overview. EJB covers a lot of territory, and without first understanding the basic concepts involved, code snippets and programming tricks are meaningless. If there's interest on the part of JavaWorld's readers, future articles may cover the specifics of using the Enterprise JavaBeans API to create your own Enterprise JavaBeans.
In order to understand why EJB is so attractive to developers, we need some historical background. First, we'll look at the history of client/server systems, and at the current state of affairs. Then, we'll discuss the various parts of an EJB system: EJB components -- which live on an EJB container running inside an EJB server -- and EJB objects, which the client uses as a kind of "remote control" of EJB components. We'll go over the two types of EJBs: session and entity objects. You'll also read about home and remote interfaces, which create EJB instances and provide access to the EJB's business methods, respectively. By the end of the article, you'll have an idea of how extensible servers can be built using Enterprise JavaBeans. But first, a look back in time.
In the beginning, there was the mainframe computer. And it was good. (Or as good as it got, anyway.) The state of the art in information processing through the 1960s consisted primarily of big, expensive machines used by large organizations to support their daily business operations. Minicomputers and timesharing in the 1970s increased the accessibility of computing power, but information and processing were still centralized on individual machines. The first personal computers in the 1980s quickly cluttered the corporate landscape with thousands of tiny islands of information, all tirelessly churning out reports of variable quality, losing critical data when they crashed, and quickly becoming inconsistent with each other.
Client/server to the rescue
The client/server architecture is one of the most common solutions to the conundrum of how to handle the need for both centralized data control and widespread data accessibility. In client/server systems, information is kept relatively centralized (or is partitioned and/or replicated among distributed servers), which facilitates control and consistency of data, while still providing access to the data users need.