This article provides a high-level introduction to J2EE. It is taken from chapter one of the book Beginning J2EE 1.4 From Novice to Professional, written by James L. Weaver, Kevin Mukhar, and Jim Crume (Apress, 2004; ISBN: 1590593413).
The word “enterprise” has magical powers in computer programming circles. It can increase the price of a product by an order of magnitude, and double the potential salary of an experienced consultant. Your application may be free of bugs, and cleanly coded using all the latest techniques and tools, but is it enterprise ready? What exactly is the magic ingredient that makes enterprise development qualitatively different from run-of-the-mill development?
Enterprise applications solve business problems. This usually involves the safe storage, retrieval, and manipulation of business data: customer invoices, mortgage applications, flight bookings, and so on. They might have multiple user interfaces: a web interface for consumers, and a GUI application running on computers in the branch offices, for example. They have to deal with communication between remote systems, co-ordination of data in multiple stores, and ensure the system always follows the rules laid down by the business. If any part of the system crashes, the business loses part of its ability to function, and starts to lose money. If the business grows, the application needs to grow with it. All this adds up to what characterizes enterprise applications: robustness in the face of complexity.
When we set out to build a GUI application, we don’t start out by working out how to draw pixels on the screen, and build our own code to track the user’s mouse around the screen; we rely on a GUI library, like Swing, to do that for us. Similarly, when we set out to create the components of a full-scale enterprise solution, we’d be crazy to start from scratch. Enterprise programmers build their applications on top of systems called application servers. Just as GUI toolkits provide services of use to GUI applications, application servers provide services of use to enterprise applications – things like communication facilities to talk to other computers, management of database connections, the ability to serve web pages, and management of transactions.
Just as Java provides a uniform way to program GUI applications on any underlying operating system, nowadays Java can provide a uniform way to program enterprise applications on any underlying application server. The set of libraries developed by Sun Microsystems and the Java Community Process that represent this uniform application server API is what we call the Java 2 Platform, Enterprise Edition, and is the subject of this book.
This chapter provides a high-level introduction to J2EE, and an introduction on how to get the most benefit from this book. After reading this chapter, you will:
Have an understanding of the reasons why the concepts underlying J2EE are compelling and enabling technologies for large-scale applications
Understand how J2EE relates to J2SE
Be introduced to the cornerstone technologies of J2EE
Be introduced to some of the essential architectural patterns that J2EE facilitates
So, without further ado, let’s get started!
What Is J2EE?
Since you’re reading this book you’ve got some interest in J2EE, and probably have some notion of what you’re getting into. For many fledgling J2EE developers, J2EE equates to Enterprise JavaBeans. J2EE is a great deal more than just EJBs, though.
While perhaps an oversimplification, J2EE is a suite of specifications for application programming interfaces, a distributed computing architecture, and definitions for packaging of distributable components for deployment. It’s a collection of standardized components, containers, and services for creating and deploying distributed applications within a well-defined distributed computing architecture.
As its name pretty much spells out, Java 2 Enterprise Edition is targeted at large-scale business systems. Software that functions at that level doesn’t run on a single PC—it requires significantly more computing power and throughput than that. For that reason, the software needs to be partitioned into functional pieces and deployed on the appropriate hardware platforms to provide the necessary computing power. That is the essence of distributed computing. J2EE provides a collection of standardized components that facilitate software deployment, standard interfaces that define how the various software modules interconnect, and standard services that define how the different software modules communicate.
How J2EE Relates to J2SE
J2EE isn’t a replacement for the Java 2 Standard Edition. The J2SE provides the essential language framework that the J2EE builds upon. It is the core upon which J2EE is based. As you’ll see, J2EE consists of several layers, and J2SE is right at the base of that pyramid for each component of J2EE.
As a Java developer, you’ve probably already learned how to build user interfaces with the JFC/Swing and AWT components. You’ll still be using those to build the user interfaces for your J2EE applications, as well as HTML-based user interfaces. Since J2SE is at the core of J2EE, everything that you’ve learned so far remains useful and relevant.
In fact, J2EE provides pretty much nothing in the way of user interfaces. You’ll also see that the J2EE platform provides the most significant benefit in developing the “middle tier” portion of your application—that’s the business logic and the connections to back-end data sources. You’ll use familiar J2SE components and APIs in conjunction with the J2EE components and APIs to build that part of your applications.
J2EE defines a number of services that, to someone developing enterprise-class applications, are as essential as electricity and running water. Life is simple when you simply turn the faucet and water starts running, or flip the switch and lights come on. If you have ever been involved with building a house, you’ll know that there is a great deal of effort, time, and expense in building in that infrastructure of plumbing and wiring that is then so nicely hidden behind freshly painted walls. At the points where that infrastructure is exposed, there are standard interfaces for controlling (water faucets and light switches, for example) and connecting (power sockets, lamp sockets, and hose bibs, for example).
In the same vein, there is a great deal of infrastructure required to write enterprise-class applications. There are a bunch of different system-level capabilities that you need in order to write distributed applications that are scaleable, robust, secure, and maintainable. Some vital pieces of that infrastructure include security, to ensure that a user is who they claim to be, and can only access the parts of the application that they’re entitled to access. Database access is also a fundamental component so that your application can store and retrieve data. Transaction support is required to make sure that the right data is updated at the right time. If you’re not familiar with some of these concepts, don’t worry—you’ll be introduced to them one at a time throughout this book.
Suppose, though, that the wiring and plumbing in your home wasn’t there. You’d need to put in your own plumbing and electricity. Without standard components and interfaces, though, you’d have to fabricate your own pipes, wiring, and so on—it’d be terrifically expensive and an awful lot of work.
Putting in a distributed computing infrastructure—the plumbing and wiring of an architecture that supports enterprise applications—is no simple feat. That’s why J2EE-based architectures are so compelling—the hard system-level infrastructure is already in place. But why not custom build (or pay someone to custom build) an infrastructure that is designed around your particular application? Well, for starters, it would take a fantastic amount of time, money, and effort. And even if you were to build up that infrastructure, it would be different from anyone else’s infrastructure, so you’d not be able to share components or interoperate with anyone else’s distributed computing model. That’s a lot of work for something that sounds like a dead end. Even if you were lucky enough to find a vendor that could sell you a software infrastructure, you should be wary about any solution that would lock you into any single vendor’s implementation that would preclude you from switching vendors at some point in the future.
The good news is, no surprise, that J2EE defines a set of containers, connectors, and components that fill that gap. J2EE not only fills the gap, but it’s based on well-known, published specifications. That means that applications written for J2EE will run on any number of J2EE-compliant implementations. The reference implementation supplied with the J2EE Software Development Kit from Sun (J2SDKEE) provides a working model that we’ll use throughout this book, since it’s the implementation that Sun has built from the specification, and is freely available. In the next chapter you’ll get an introduction to installing and testing the J2SDKEE.
It’s important to note that the reference implementation is a working model but it’s not designed to be used for enterprise-level deployment. It doesn’t provide some of the enterprise-level features that are outside of the scope of the J2EE specification, such as clustering (the ability to have multiple servers handling requests at the same time) or failover (the ability to have a group of servers that can recover when one crashes). Working with the reference implementation, though, ensures that you’ll get exposure to the core J2EE concepts that apply to ALL vendor implementations, and you won’t get bogged down with vendor-specific details.
Building a J2EE application for one J2EE implementation and deploying it on another is cheap, but it’s not free, nor is each vendor’s implementation of J2EE completely free of defects and operational quirks. Although Java and J2EE go a long way towards providing platform independence, that isn’t a guarantee that you can develop on one platform and deploy on another without any hiccups or surprises. Bugs, differences in performance, and other little “gotchas” can seriously delay or derail your project. When you are developing systems that will be deployed in a production environment, it is always a good idea to do your development and staging using the same platforms and technologies that the production environment is based upon. This will help to avoid unnecessary surprises during and after the rollout.