Last month JavaWorld published the first article in this two-part series, covering the state of Java middleware. The first article provided an overview of the many features offered and promised by Java middleware; this article focuses specifically on one of those features: Enterprise JavaBeans (EJB).
By now you've probably heard about EJB, read articles about it, and possibly even written a few enterprise beans yourself. However, if you're like many people out there, you might not understand the big picture -- despite the fact that working with EJB is supposed to be extremely simple. Here's a list of questions many developers new to EJB struggle with:
- What are all the features of EJB?
- What tools are available today that support EJB?
- When should I use session beans versus entity beans?
- When to use a stateful session bean versus a statelessone?
- What are the dos and don'ts of EJB development?
- How does EJB relate to JDBC 2.0 (Java Database Connectivity) and the transaction management APIs?
- How does EJB's security work?
- How do complex joins in an existing relational database work with entity bean mapping?
This article addresses these and other common concerns about EJB. It includes examples of how some vendors provide EJB support. Moreover, this article addresses the following key issues:
- Whydo we need EJB?
- Whowill support EJB?
- Whatexactly is EJB?
- Howdo you develop, deploy, and manage EJB?
- Howdo you integrate EJB with existing systems?
- Wheredoes EJB go from here?
In short, this article describes the current state of EJB and the Java middleware (tools) that support it. Rather than focus on in-depth coding examples, I devote attention to the more challenging aspects of working with EJB: the design issues and tools selection. To learn more about nitty-gritty programming with EJB, see the JavaWorld articles in the Resources section below. Furthermore, EJB programming (developing enterprise beans), in my opinion, is the easy part (as Sun intended it to be); design issues and tools selection are the more challenging aspects of working with EJB.
Note that throughout this article I use the terms Java middleware, application servers, and EJB servers somewhat interchangeably. Marketeers, authors of the EJB (or CORBA/DCOM) specification, and niche developers may see many distinctions among these terms, but for the purpose of this article they all mean the same thing.
Note also that this article is jam-packed with information on EJB. While it may seem overwhelming, don't be discouraged: EJB developers typically don't have to deal with all the issues discussed here. In fact, the EJB specifications define several roles and responsibilities that can be handled by either one person or several people, depending on the size of your project. Nevertheless, an understanding of the big picture is essential. And remember, developing enterprise beans is actually extremely simple.
Why do we need EJB?
Ever since the Web began to make the Internet popular and useful for almost everyone (not just the government and students), new Net technologies (Internet, intranet and extranet) have emerged from all directions and organizations. It is now close to impossible to keep up with these technologies at the speed they're being introduced.
So, why should we add EJB to this list of technologies? Well, there are various reasons, but before we look at the reasons for EJB, let's look at several reasons why we need middleware or, more specifically, application servers.
Glue between clients and servers
On the front end, there are many different types of clients (desktops/browsers, PDAs, Web phones, NCs/thin clients, different platforms). On the back end, there are many types of platforms (Unix, Windows, Mac) and data repositories (RDBMS, ODBMS, Mainframe). Java middleware connects the two (see Figure 1). In other words, business logic can be implemented as reusable components in the middle tier, thereby providing access for a variety of clients to all types of data on the back end.
Scalability and standards-based technologies
The original HTML and/or CGI solution isn't scalable and APIs such as Netscape's NSAPI and Microsoft's ISAPI are proprietary. Most app servers provide standards-based technologies that scale well. Additionally, these products typically provide features such as resource pooling, fault-tolerance, security, management, and other built-in bells and whistles.
Many app servers are a one-stop shop, that is, they support all the necessary protocols to provide a complete application development solution. Take for example, BEA's WebLogic application server, which provides support for HTTP, RMI, EJB, Servlets, JNDI, JDBC, and other protocols, or Oracle's Application Server, which supports HTTP, CORBA/IIOP, and more. This frees you from having to run multiple servers (e.g., a Web server, a CORBA ORB, and an RMI server).
Now that we've looked why application servers are needed for Net development, let's look at why there's a need for EJB.
EJB increases productivity for developers because they need not worry about low-level system programming (such as connection pooling, security, transaction management, state management, persistence, number of clients, and multithreading); they simply concentrate on writing the business logic and develop the enterprise bean almost as if it will be used by a single client.
Open server-side component architecture
In the past two or more decades, most server-based products have used the vendor's proprietary APIs, so not many off-the-shelf, plug-and-play components have been available, except from the vendors themselves. EJB changes this by providing portability across platforms and vendors. Because EJB sets a clear path for application vendors, all must provide the same minimal functionality in their server products, opening the flood gates for component builders to build off-the-shelf server-side components, not just client-side GUI components. For example, an off-the-shelf enterprise bean could handle functions such as credit card validation.
Object-oriented programming on the server
Thanks to Java's object-oriented roots and the EJB component model, organizations can more easily create and use reusable components, and thus spend less time writing code. One factor helping this reusability is that the logic and data are packaged together in objects. Additionally, EJB containers can translate relational data into objects automatically. This eliminates the distinction between accessing data from a database versus from any other object.
Java in the middle tier
EJB brings all Java features (such as security, directory services, and serialization) to the middle tier. In general, EJB drives forward Sun's layer-and-leverage philosophy, which calls for portability and leveraging existing enterprise investments.
Support for other languages and CORBA
EJB provides support for other languages and CORBA because the middleware vendor, not the enterprise bean developer, handles the communication protocol issues. For example, the default wire protocol for EJB is RMI; however, the EJB 1.0 specifications also provide mapping to CORBA. Furthermore, a vendor can use any distributed protocol to support many types of clients (COM/DCOM for example).
Who will support EJB?
EJB by itself isn't a product. Rather, it's a specification. One of the key objectives of EJB is portability across platforms and vendor products. Several vendors already support EJB or have announced plans to support it in future versions of existing products; additionally, Sun intends to provide a reference implementation of EJB by the second quarter of this year. Table 1 shows a partial list of vendors that have endorsed EJB:
|BEA Systems||WebLogic Application Server|
|Information Builders||Parlay Application Server|
|Inprise||Inprise Application Server|
|Netscape||Netscape Application Server (Kiva)|
|Oracle||Oracle Application Server|
|Persistence||PowerTier for EJB|
|Secant||Extreme Enterprise Server for EJB|
|Silverstream||Silverstream Application Server|
|Sybase||Enterprise Application Server|
|Wall Data||Cyberprise Server|
Table 1. EJB endorsers
What exactly is EJB?
EJB is part of Sun's Java Platform for the Enterprise (JPE) initiative. JavaBeans introduced a standard way of developing and using Java components on the client side. Similarly, EJB serves as the Java component architecture for the server side.
EJB enables software developers to build server-side, reusable business objects (enterprise beans). However, EJB takes the notion of reusable objects one step further by providing for attribute-based programming to dynamically define lifecycle, transaction, security, and persistence behavior in EJB applications. For example, using attribute-based techniques, the same enterprise bean (in its binary form -- that is, class and/or Java archive [JAR] files) can exhibit different transactional behavior in different applications. Additionally, the method of persisting an enterprise bean can be altered during deployment without ever having to recode the enterprise bean. For example, an entity bean could use a relational database for its persistence or CICS; the enterprise bean developer never needs to know.
To provide a more concrete picture of what EJB is, let's look at the following topics borrowed from the EJB 1.0 specifications:
- Roles and responsibilities
- Programming restrictions
The EJB 1.0 specifications define certain goals for Java middleware vendors who will implement this standard. The following are a few of these goals:
- Standard distributed component architecture for Java
- Portability across platforms and vendors
- Increased productivity via simplicity (developer doesn't worry about state management, multithreading, network connections and protocols, resource pooling, and so on)
- Compatibility with other programming languages and CORBA
- Address development, deployment, and management
- Compatibility with existing enterprise infrastructure and/or platform investments
To fulfill the above goals, EJB provides several features that make this distributed component architecture so appealing. Table 2 provides a snapshot of these features (more details on each feature are provided further in the article).
|Naming and directory service|
|Support for CORBA|
Three enterprise bean types -- which to use?
EJB provides three enterprise bean types: stateless session beans, stateful session beans, and entity beans.
Stateless session beansare intended to be simple and lightweight, that is, easy to develop with low runtime resource requirements on the server for scalability components. Any state, if required, is maintained by the client, thereby making the server highly scalable. Since no state is maintained in this enterprise bean type, stateless session beans aren't tied to any specific client, hence any available instance of a stateless session bean can be used to service a client.
Stateful session beansprovide easy and transparent state management on the server side. Because state is maintained in this enterprise bean type, the app server manages client-bean pairs. In other words, each instance of a given enterprise bean is created on behalf of a client and is intended to be a private resource to that client (although it could be shared across clients using the enterprise bean instance's handle). In essence, a stateful session bean is a logical extension of the client, except some of the client's load is distributed between itself and the enterprise bean on the server. Any conversational state-related data in the object's variables doesn't survive a server shutdown or crash, although a vendor could provide an enhanced implementation to make shutdowns and crashes transparent to the client by maintaining the enterprise bean's state. Stateful session beans can access persistent resources (such as databases and files) on behalf of the client, but unlike entity beans, they don't actually represent the data. For example, a session bean could access data via JDBC or an entity bean.