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).
J2EE Essentials - Vendor Independence (Page 3 of 7 )
Sun Microsystems—the company that created the Java platform and plays a central role in Java technologies including the J2EE specification—has promoted the Java platform as a solid strategy for building applications that aren’t locked into a single platform. In the same way, the architects of J2EE have created it as an open specification that can be implemented by anyone. To date, there are scores of J2EE-based “application servers” that provide a platform for building and deploying scaleable n-tier applications. Any application server that bills itself as J2EE compliant must provide the same suite of services using the interfaces and specifications that Sun has made part of J2EE.
This provides the application developer with a number of choices when implementing a project, and down the road as more applications are added to an organization’s suite of solutions. Building an application atop the J2EE architecture provides substantial decoupling between the application logic that you write, and the “other stuff”—transaction support, security, database access—all the distributed computing infrastructure software of the J2EE server that supplies the plumbing and wiring that makes multi-tier applications tick. Remember that all J2EE servers have to support the same interfaces defined in the J2EE specification—that means you can design your application on one server implementation and deploy it on a different one. You can decide later that you want to change which J2EE server you use in your production environment. Moving your application over to the new production environment can be almost trivial.
The vendor and platform independence is something that you can take advantage of in your development. I find myself away from the office quite a bit, and will often use my notebook computer running Windows to do development. It’s pretty easy to use that configuration to build, test, and debug (J2EE has great support for pool-side computing). When I am back in the office and happy with a particular component, I can deploy it to the Linux-based servers with little effort, despite the fact that those servers are running a different operating system and different J2EE implementation (after gratuitous testing, of course!).
Bear in mind that each J2EE vendor provides some added value to its particular J2EE implementation. After all, if there weren’t market differentiators, there’d be no competition. The J2EE specification covers a lot, but there is also a lot that is not specified in J2EE. Performance, reliability, and scaleability are just a few of the areas that aren’t part of the J2EE spec but are areas where vendors have focused a great deal of time and attention. That added value may be ease of use in its deployment tools, highly optimized performance, support for server clustering (which makes a group of servers able to serve application clients as if it were a single super-fast, super-big server), and so on. The key point here is to keep two issues in mind: first, your production applications can potentially benefit from capabilities not supported in the Sun J2EE reference implementation. Just because your application’s performance stinks on the reference implementation running on your laptop doesn’t mean that J2EE is inherently slow. The second issue is that any vendor-specific capabilities that you take advantage of in your production applications may impact the vendor-independence of your application.
Defining throughput and performance requirements is a vital step in requirements definition. Even the best of us get caught off-guard sometimes, though. Things can happen down the road—unanticipated numbers of users that will use a system at the same time, increased loading on hardware, unsatisfactory availability in the event of server failure, and so on—that can throw a monkey wrench into the works.
The J2EE architecture provides a lot of flexibility to accommodate changes as the requirements for throughput, performance, and capacity change. The n-tier application architecture allows software developers to apply additional computing power where it’s needed. Partitioning applications into tiers also enables refactoring of specific pain points without impacting adjacent application components.
Clustering, connection pooling, and failover will become familiar terms to you as you build J2EE applications. Several providers of J2EE application servers have worked diligently to come up with innovative ways to improve application performance, throughput, and availability—each with its own special approach within the J2EE framework.
Features and Concepts in J2EE
Getting your arms around the whole of J2EE will take some time, study, and patience. There are a lot of concepts that you’ll need to get started, and these concepts will be the foundation of more concepts to follow. The journey through J2EE will be a bit of an alphabet soup of acronyms, but hang tough—you’ll catch on, and we’ll do our best on our end to help you make sense of it.
Up to this point, I’ve been using terms like “client” and “server” fairly loosely and liberally. These terms represent fairly specific concepts in the world of distributed computing and J2EE.
A J2EE client can be a console (text) application written in Java, or a GUI application written using JFC/Swing or AWT. These types of clients are often called “fat” clients because they tend to have a fair amount of supporting code for the user interface.
It would be an oversimplification to describe the application logic called by the J2EE clients as the “server.” While it is true that from the perspective of the developer of the client-side code, that illusion is in no small way the magic of what the J2EE platform provides. In fact, the J2EE application server is the actual “server” that connects the client application to the business logic.
The server-side components created by the application developer can be in the form of web components and business components. Web components come in the form of JavaServer Pages (JSPs) or servlets. Business components, in the world of J2EE, are Enterprise JavaBeans (EJBs).
These server-side components, of course, rely on the J2EE framework. J2EE provides support for the server-side components in the form of “containers.”
Containers are a central theme in the J2EE architecture. Earlier in this chapter I talked about application infrastructure in terms of the plumbing and electricity that a house provides for its inhabitants. Containers are where those infrastructure services interface with, and provide a host for, application logic.
In the same way that application developers can partition application logic into tiers of specific functionality, the designers of J2EE have partitioned the infrastructure logic into logical tiers. They have done the work of writing the application support infrastructure—things that you’d otherwise have to build yourself. These include things like security, transaction handling, naming, and resource location, and of course the guts of network communications that connect the client to the server. J2EE provides a set of interfaces that allow you to plug your application logic into that infrastructure and access those services. Those interface layers are the J2EE containers.
Think of containers as playing a role much like a video gaming console that you plug game cartridges into. The gaming console provides a point of interface for the game, a suite of services that lets the game be accessed by the user and allows the game to interact with the user. The game cartridge itself needs only be concerned with itself—it doesn’t need to concern itself with how the game is displayed to the user, nor what sort of controller is being used, or even if the household electricity is 120VAC or 220VAC—the console provides a container that abstracts all of that stuff out for the game, allowing the game programmer to focus solely on the game and not the infrastructure:
If you’ve ever created an applet, you’re already familiar with the concept of containers. Most web browsers provide a container for applet components. The browser’s container for applets provides a defined site for your application component in the form of the java.applet.Applet class interface. That site provides services through the AppletContext interface. When you develop applets, you are relieved of the burden of interfacing with a web browser and are free to spend your time and effort on the applet logic—not the issues associated with making your application appear to be an integral part of the web browsers.
J2EE provides server-side containers in the same vein: they provide a well-defined interface, along with a host of services that allow application developers to focus on the business problems they’re trying to solve, and alleviating the need to worry about the plumbing and electricity. Containers handle all of the monkey motion involved with starting up services on the server side, activating your application logic, and cleaning up after you.
J2EE and the Java platform provide containers for web components and business components. These containers—like the gaming console—provide an interface site for components that conform to the container’s established interfaces. The containers defined in J2EE include a container for EJBs, JavaServer Pages, servlets, and J2EE clients.