Enterprise JavaBeans™ in Context
- Enterprise JavaBeans: what are they, and what do they do?
- EJBs in the enterprise
- Why use EJBs?
- The EJB philosophy
- EJB roles
- EJB products
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
This introductory chapter describes the goals and requirements of EJB technology and what you—the developer—can expect to gain by using it. It explains how EJBs t into other distributed programming paradigms (like CORBA), and into the wider 'J2EE' model of application development. The chapter includes an outline of the other services that a J2EE-compliant application server is expected to provide and which EJBs can use (e.g., Java-Mail, JMS). There is a brief discussion of the development philosophy that underlies the EJB Specication, including the roles of the developer, assembler, and deployer, and how the EJB model—appropriately used—can enhance code reuse and improve reliability.
1.1 Enterprise JavaBeans: what are they, and what do they do?
Let's start by examining the answer to this question as provided by the most authoritative source, the EJB Specification itself:
"The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification."
This definition makes a number of important assertions, which are worth considering in more detail.
"...a component architecture..." The distinction between 'component-based' and 'object-oriented' development is not a strict one, and you will see EJBs referred to as 'distributed components' and 'distributed objects.' I take the term 'component' in EJB technology to mean a piece of software that is self-contained, has well-defined functionality, and fits into some kind of application framework. It is this latter point that probably makes the term 'component' more applicable than 'object' in EJB technology.
The application framework is exemplified by the EJB container, a concept about which we will have much more to say later. EJBs depend for their very existence on their container; it regulates all aspects of their lives, including their communication with other EJBs [EJB2.0 6.2]. This is not the restriction that it first appears, because the use of the container has profound advantages, as we shall see.
EJBs can be viewed as simple objects: They expose methods, and these methods can be called. Like ordinary objects, the methods take arguments and can return values. Unlike ordinary objects, EJBs can be distributed across different hosts, and the architecture takes care of the communication. When a client makes a method call on an EJB, it is in fact making that call on the container, which acts as a proxy, as we shall see.
"...distributed business applications..." What is a 'business application' ? This is a very broad term, but we can identify certain characteristics that most business applications will exhibit. First, there is a reliance on data, often in volume, and with strict measures to protect the integrity of that data. Most business applications make use of relational databases. Second, many business applications have large numbers of users, often geographically distant from the application host. Third, business applications often integrate systems of different types, from different vendors. Some of these systems will be 'legacy' systems—that is, based on obsolete software and protocols, but needing to be retained. EJBs can make use of messaging services, connectors, and other techniques for access to legacy systems. The EJB infrastructure has interoperability as one of its core requirements [EJB2.0 19.2]. Applications are 'distributed' when components can be hosted on different servers. The ability to distribute components has important implications for fault tolerance and load sharing, as we shall see.
It is worth pointing out at this point that, under EJB 2.0, not all EJBs have to be capable of distribution. The developer is at liberty to author EJBs such that they are only accessible to calls from other EJBs in the same JVM. This makes access more efficient at the expense of limiting load balancing and fault tolerance. We will have much more to say about this issue later.
"...scalable..." An application is scalable if the system that hosts it can be expanded or upgraded to support a higher client load, without significant modification to the software. Scalable does not necessarily mean 'high performance,' despite a common belief that this is the case. EJB applications support scalability because they lend themselves to distribution; they support high performance because they allow the sharing of resources and minimize overheads, as we shall see.
" transactional..." Where business applications are datacentric, the integrity of the data is of paramount importance. This means that access to the databases, and often to other resources, will be transactional—that is, consist of operations that must succeed or fail as a group. We will have much more to say about this issue in Chapter 9, as transaction management is a key feature of the EJB infrastructure, particularly in a distributed environment [EJB2.0 19.6].
" multi-user secure..." Business applications will need to be able to identify their users, and allow access to the data only to defined users. Information about which users are allowed which operations is often not part of the application, but stored in some sort of user database (e.g., an LDAP directory server). Security is an integrated part of the EJB framework, as described in Chapter 16.
"...written once, and deployed on any server..." With care, EJB applications can be made quite portable (but see below). The use of the Java language ensures portability not merely at the source-code level, but at the binary level. This makes it appealing for vendors to author EJB components that are general-purpose and can be integrated into other applications. A requirement to distribute source code would discourage this. Provided that the EJB author is careful to follow the Specification, the interaction between the EJB and its container should not depend on the container vendor. The EJB architecture is designed to support the use and integration of components from different vendors, by such means as using a standard (XML-based) configuration scheme for components.
In summary, EJBs are Java3 software components that run in a framework that supports distribution, load sharing, fault tolerance, security, and transaction management. To their clients they 'look like' ordinary Java objects, and can be used similarly.
In a more pragmatic sense, EJBs are components built from Java program classes and interfaces. In particular, each EJB has at least one class, which provides the application functionality, and, where direct interaction by clients is allowed, two or four interfaces, which specify which methods are to be exposed to clients. These Java elements are packaged into a standard Java JAR file along with a deployment descriptor, an XML file that provides configuration information to the server. Each JAR file can contain one or more EJBs. In practice, we tend to use graphical tools for building the JAR and XML files.