Download (direct link):
J2EE Architecture Considerations 333
(Servlets, jSp Pages, HTML, XML)
(RDBMS, ERP, Legacy Applications)
Figure 37.4 J2EE tiers (new).
Copyright 2002 Sun Microsystems, Inc. Reprinted with permission. Sun, Sun Microsystems, the Sun Logo, JSP, JNDI, and JavaMail are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
But the original solution was a J2EE solution, what became known as the "Web tier" by Sun. Figure 37.4 is a diagram representing the new vision that Sun has for different containers for the tier of solution needed.
As to whether the original specification intended to have the flexibility of providing simply Web tier solutions, it was not readily apparent from the initial blueprints. This is why Sun separated them—to clarify that all solutions did not need to center on EJB. This caused a lot of frustration on my team's part (and I know that we were not alone judging from the backlash against EJB I have read).
Figure 37.5 illustrates the various containers that the Java platform envisions. The handheld clients are not shown but are not really relevant relative to the server-side technologies. Note the distinction between the Web container and the EJB container. Also note how the Web container can serve as a facade for the EJB container.
334 Item 37
Figure 37.5 Java containers.
So how do we tell if the EJB tier (container) is necessary in our application? This boils down to looking at what EJB provides:
Scalability. Everyone wants scalability, but how scalable? Essentially, we want all of our apps to scale immensely and forever, because something in our system design mentality says, "It can handle anything." However, bigger is not always better, and benchmarks from 2000 show servlets having peak performance on the order of 400 requests per second. Now, you would want to look into your own benchmarking studies, especially concerning the specific vendor solutions you want, but it is not safe to assume that if you want a highly scalable system, you must use EJB.
Transactions. Transactions are a strong capability of EJB containers. This is probably a major selling point when you are dealing with distributed or complex transaction scenarios (multiple systems, phased transactions). However, a great
Design Strategies for Eliminating Network Bottleneck Pitfalls 335
number of developers use transactions to ensure that a series of SQL statements execute together in the same RDBMS. If this is the level of complexity required, then the JDBC transaction capability is probably more than sufficient.
Security. If you have complex, role-based security or complicated access control lists, this is probably a good place for the EJB container. While the filtering mechanisms in the new servlet specification are very helpful for building good user authentication, it is pretty transparent in EJB.
Reliability. A lot of people define reliability as whether their system ever crashes. In fact, there are a number of semantic debates over reliability versus fault tolerance versus redundancy, but what we are talking about is how well the system responds to something going wrong. As previously mentioned, entity beans were designed around the old data processing nightmare, so if this is a major concern to you, then EJB is probably a good idea.
Componentization. J2EE revolves around the idea of being able to build and reuse components, allowing for the classic build versus buy engineering equation to be introduced into enterprise applications. It is easy to assume that the market for EJB container components is more vibrant than Web container components, but it is quite the opposite. There are tremendous numbers of Web container components available, including some very good open-source ones. A classic example is the Jakarta Taglibs or Struts framework (http://jakarta.apache.org/).
Clustering, Load Balancing, Failover. These are classic examples of the need for the EJB tier. When your applications need to be spread over several containers in a transparent way to support things like clustering (multiple cooperating instances to improve performance), load balancing (assigning requests to different instances to level the load among all instances), and failover (when one instance fails, another is able to pick up on it quickly).
Because it was the first cross-platform enterprise component architecture, J2EE has gained a tremendous amount of attention. While the attention caused a great amount of hype as well, it is wrong to assume J2EE is a technology without merit. J2EE is a collection of technologies, so it is almost always inappropriate to suggest it is a bad solution for any enterprise scenario, despite the care that must be taken in determining whether EJB is a helpful technology to your enterprise solution.