The Enterprise JavaBeans Architecture

The EJB 2.0 Specification defines Enterprise JavaBeans (EJB) as an architecture for component-based distributed computing. Although this definition works well if you are already familiar with terms such as component-based and distributed computing, the definition doesn't help much if you are brand-new to Enterprise JavaBeans or enterprise application development. It might even be helpful to define what is meant by an enterprise application. Before we do that, however, let's get a picture of what the EJB architecture looks like. This way, you'll have an image in your head as we go through this discussion. Figure 1.1 illustrates the EJB architecture from a high level.

If you were to ask 100 software developers or architects what an enterprise application is, you probably would get 101 different definitions. It's not because software developers can't count, it's because the definition of an enterprise application can be somewhat ambiguous. Each development or business organization might have its own definition of what an enterprise application is. However, it would be nice if we could get a single definition that the majority of software developers could agree on.

Enterprise development did not begin with the advent of EJB, or Java for that matter. In fact, it has been around for many years and was a term that was used often when mainframe development was all the rage. However, it might be a new concept for some of you, who might have been involved only with applications that performed a relatively small business task and that were usually contained within a single address space.

Although companies have been using the Common Object Request Broker Architecture (CORBA) since the early '90s, due to the boom of the Internet and the decentralization of the Information Technology (IT) departments within organizations, more and more applications are being developed that cross the network boundaries and encompass more of the business's day-to-day functionality. At the same time, these applications are being spread out further and further from other components or applications that exist in the enterprise. By enterprise , we are referring to all the software applications or services that an organization has built, bought, and acquired that provide service to an organization. These services might be dealing with inventory management, pricing, or anything else that organizations must manage on a regular basis. Enterprise applications are not bound by the four walls of the data center like they used to be. Now, components and services are being decentralized throughout the organization.

Riding right on the back of this decentralization is an entire posse of new technical challenges and complexities that must be dealt with by the development organization. These new technical challenges must be considered during design and development because of this spreading out of the services over the network. It's no longer true that an organization's data or business processes are located in a single physical location. Most companies must now be global and can no longer assume that customers will be within the same geographical location. Therefore, the applications must be flexible and extensible to accommodate customers and other business partners from around the world and at any time of the day or night. Add to this that, hopefully, new customers and partners are being added every day, and this can have a tremendous effect on the scalability and performance of the application.

As you can start to see, enterprise developers must deal with many complex technological issues that just are not present in many smaller applications. Enterprise applications must support multiple sites that can be geographically separated, deal with customers and partners that can usually access an application at all hours of the day and night, support multiple languages and concurrent user access, and take into account the complex issues that go hand in hand with this wide separation. Other issues, such as interfacing with existing applications in the enterprise, are also very common and must be supported. It's also true that the physical hardware and software applications within the enterprise are very heterogeneous. For example, some enterprise applications might require a Unix operating system to function, while others run only on a Windows platform. This diverse set of constraints only adds to the complexity for the enterprise developers.

Going back to the EJB definition that was provided from the specification and considering a different definition of what enterprise application development is, let's try to come up with our own EJB definition. We need a definition that we can intuitively grasp and understand without a great deal of confusion and be able to communicate it to others. So here is an attempt at a definition that you should be able to understand with a little bit of thought:

"Enterprise JavaBeans are Java components that a Java developer writes and installs into an application server, which provides naming, security, transactional, and other enterprise services for the components.

These installed components can be utilized over a network in a distributed manner."

Although the previous definition contains a few terms that might be new to you, it should take you a little closer to understanding how the EJB architecture helps you build enterprise applications.

Note

The application server that was mentioned in the definition is typically built by a third party and installed into your environment.