Learn the basics of designing J2EE applications — from one handy guide
Sun’s recent release of the Java 2 Enterprise Edition reference implementation, or J2EE RI (see Resources for downloading information), provides an implementation of all the J2EE functionality, including technologies such as Enterprise JavaBeans (EJB), CORBA, XML, servlets, and JavaServer Pages (JSP). Along with the libraries and examples in the reference implementation package comes a new whitepaper from Sun describing its vision of how Java applications should be designed and built.
(As a side note, Sun has outsourced part of the reference implementation for the Servlet and JSP APIs by releasing it under an open source license to the Apache project. The Tomcat server, from the Apache Jakarta group [see Resources] provides the reference implementation in a freely usable form. Combined with the Apache Web server, the Tomcat server should help accelerate the adoption of J2EE by providing a high-quality, cross-platform implementation of these two APIs.)
Normally a whitepaper from a big company isn’t headline news, but at 266 pages, the “J2EE Application Programming Model” (APM) isn’t your typical whitepaper. The APM is a summary (if a long one) of Sun’s view of how to build an enterprise Java application and where Java fits into the software development landscape. For developers who already know how to build distributed applications using Java or other technologies like CORBA or DCOM, only the details of the APM present anything new. For developers who haven’t looked extensively at J2EE or for developers unfamiliar with distributed systems, the APM provides a good, if verbose, introduction.
As part of the official J2EE launch in December, the APM has been renamed the “Sun BluePrints Design Guidelines for J2EE.” The new name reflects its inclusion in Sun’s BluePrints best-practices series of articles and whitepapers. But because “Sun BluePrints Design Guidelines for J2EE” is too long to write over and over, I’ll continue to refer to the document as the APM. The final version of the J2EE BluePrint document will be published by Addison-Wesley sometime this year.
Before going into the details of the APM, I should warn you that if you download the APM and start reading it, you’re probably going to skip over quite a bit. The APM goes from very high-level views of distributed systems, talking about things such as the multitier distribution model, to very low-level details such as the types of transaction handling supported by EJBs. Much of this highly detailed information is lifted from other sources such as the EJB documentation and other previously published J2EE specifications, but you can rest assured that if you actually print all 266 pages, you’ll probably get good use of the document over time, as you won’t also have to print out the whitepapers for EJB, JSP, and so on.
What’s in the APM?
The APM sets the stage for Sun’s guidelines by describing the needs of “enterprise computing” — that is, the needs of those who create systems that manage information inside businesses. These systems enable activities such as information sharing, information warehousing and management, and, most important in today’s Internet economy, ecommerce.
The new middle tier
Most, if not all, J2EE applications are expected to be distributed applications. This term includes the classic two-tier computing model (the application is broken into a client, which interfaces to the user, and a server, which performs data-storage duties) as well as the three-tier and multitier models. In the multitier model, the client and server are separated by one or more systems that each do some sort of processing on the data.
What’s interesting about the APM is how it defines the middle tier, which it says “typically refers to an environment under the close control of an enterprise’s IT department.” That is a departure from many traditional definitions of the term. In most descriptions of the middle tier, the middle is identified by its role in the application (that is, what part in the application’s overall purpose it plays) or by where the hardware physically exists. The APM definition is quite different: it defines the middle role according to its place in the organization. This definition is immensely liberating: by admitting that the front-end client machine and the back-end database server are out of the typical IT department’s direct control, developers can start thinking about novel ways to deliver applications within those restrictions.
Take a typical bank. Not every enterprise is a bank, but most businesses have similar characteristics when it comes to managing important data and processes. In most banks the really important data, like account balances and transaction history, reside on a mainframe. In computer years, the mainframe has existed since the beginning of time and it’s unlikely that anyone wants to risk losing critical data by doing anything new with it. Most of the client machines in the bank are similarly fixed. A bank might have thousands of slightly out-of-date PCs sitting on the desks of tellers and managers. Those machines are difficult to upgrade and install new applications on. While the bank’s IT department may have control of those systems on paper, it probably can’t really do anything to them — they are not under the IT department’s close control. So what can the IT department control and use to deploy new applications and functionality? Middle-tier machines running things such as Web servers, application servers, and distributed component containers. IT departments can deliver Web-enabled applications to allow users to access new functionality without installing additional software on their machines.
Containers
The idea of containers is another important idea in J2EE and the APM. As the document states, “A major goal of the APM is to minimize programming.” J2EE accomplishes this by viewing an application as an assembly of independent parts, or components. The difference between this and the standard JavaBean component model is that the J2EE components rarely, if ever, interact with each other directly. They deal with each other at arm’s length, through interfaces such as Remote Method Invocation (RMI) and by interacting not with each other but with their containers.
If you’ve ever used EJBs, then you’re probably familiar with the J2EE container concept. An EJB manages certain pieces of information and has some methods that can be invoked, but things such as instance pooling, multithreaded behavior, and transactional behavior are outside the scope of the bean itself. These issues are, instead, managed by the enterprise bean’s container, which is part of the application server.
This concept has been extended to servlets as well. Now instead of viewing servlets as a way of extending a Web server, you can instead view the Web server as a lightweight container that simply funnels HTTP requests to the appropriate servlet component, which takes care of handling the request. The Web server creates and pools instances of the servlet classes and handles multiple threads and socket connections. The parameters to control these aspects of a component’s behavior are set at deployment, not during development. In addition, they are not necessarily set by the developer of the component. By eliminating the number of items the developer has to worry about, this component-based development model reduces the overall amount of code required for the component. To be fair, however, that is accomplished by shifting the code from the component into the container. The onus is on the container author (typically a commercial vendor) to make sure that items such as multithreaded behavior and instance management are handled correctly.
EJBs, Servlets, and JSPs are the three component technologies in J2EE. The other technologies, Java Messaging Service (JMS), Java Transaction Service (JTS), CORBA, JDBC, XML, and Java Naming and Directory Interface (JNDI), serve as supporting infrastructure for the component technologies.
How the APM changes your development
So, given the APM’s definition of middle tier, how does the APM suggest developers and information technologists change the way they develop distributed software?
Web-based thin clients versus thick clients
The biggest change is in how applications are deployed. The APM suggests moving away from a thick-client model and, where possible, moving toward Web-based, or thin, clients. I’m sure that is nothing new to most developers — you’d have to be dead to have missed all the buzz about Web clients, Web applications, Web architecture, Web this, and Web that. The APM goes beyond just rehashing this idea, thankfully, by showing how the various pieces of the J2EE platform can be put together to build maintainable, robust, scalable Web applications.
It’s only fair to also note that the prominence of Web-based applications in the J2EE APM is fairly self-serving on Sun’s part. Is it just an amazing coincidence that a company whose primary business is selling enterprise servers is pushing an application architecture centered on that very same hardware platform? Of course not. So while we can’t dismiss the many real advantages of Web-based applications out of hand, I think they should be taken with a grain of salt.
Thankfully the APM doesn’t degenerate into pushing a Web-based model at the exclusion of all others. There are still many legitimate uses for thick, application-based clients, and the APM does discuss them when appropriate. Application clients have more flexible user interfaces, are able to distribute the computational workload between the client and the server, and can handle complex data models that simply aren’t feasible for Web-based clients.
The primary disadvantages to using an application client in an enterprise environment are the greater complexity (of the application) and the distribution requirements. I think that these issues are manageable, however. First of all, I don’t think application clients are any more or less complex than Web-based clients. Writing servlet-based code or JSPs is different from, but not fundamentally harder than, writing a Swing-based application. Second, distribution, while difficult, can be managed. Many organizations manage systems that automatically distribute incredibly large, complex software, like Microsoft Office, to hundreds or thousands of client machines.
While these solutions may be expensive (they may also be quite cheap), the cost of distribution may be less than the cost of shoehorning an application that isn’t suited to it into a Web-based model. Additionally, these systems have low incremental costs: they may be expensive to set up, but once in place there is little extra cost to distribute additional applications. Of course, the true power of Web-based applications isn’t so much their low cost of distribution, but the ease at which they scale to supporting huge number of users, not just throughout an enterprise but across the Internet as well. Nevertheless, the application client will remain valuable for certain applications that don’t have this requirement.
What about XML?
Besides Web-based apps, the hottest fashion in the software development world is XML. While you may not completely understand how XML works or what it does, you’ve probably heard someone tell you that XML is going to change your life. Unlike Web-based apps, however, XML doesn’t have a specific section in the APM. Nonetheless, XML is tucked into the APM all over the place: developers can find out how to use J2EE technologies to create and distribute XML-based data and see how XML is used in a supporting role by the various J2EE APIs.
For example, deployment descriptors for EJBs are now described using XML instead of serialized object instances. That makes it immensely easier for both tool vendors and users who deploy EJBs, as the descriptors are now human readable. Both servlets and JSPs are capable of handling XML-based data (instead of just HTML). The APM talks about XML as a data-exchange format for business-to-business ecommerce applications. But nowhere does XML take the front seat. It’s seen as complementary and synergistic to the various J2EE technologies, but in and of itself it doesn’t stand out as a major component in building an distributed application.
Conclusion
In summary, you may have seen various parts of the “Sun BluePrints Design Guidelines for J2EE” before. You’ve probably heard about new development idioms such as Web-based applications or XML. You may have read about or used one of the J2EE technologies, such as servlets or EJBs. The APM brings it all together though, painting a coherent picture of how Java enables the development of applications that are increasingly viewed as critical to almost every type of business. Whether or not you agree with its view of the distributed, Web-centric, Java-enabled world, it’s definitely worth a read.
