How Java EE Relates to J2SE ?

Java EE isn’t a replacement for the Java 2 Standard Edition (J2SE). J2SE provides the essential language framework on which Java EE builds. It is the core on which Java EE is based. As you’ll see, Java EE consists of several layers, and J2SE is right at the base of that pyramid for each component of Java EE.
As a Java developer, you’ve probably already learned how to build user interfaces with the Swing or Abstract Window Toolkit (AWT) components. You’ll still be using those to build the user interfaces for your Java EE applications, as well as HTML-based user interfaces. Since J2SE is at the core of Java EE, everything that you’ve learned so far remains useful and relevant.
In addition, Java EE provides another API for creating user interfaces. This API is named JavaServer Faces (JSF) and is one of the newest Java EE technologies. You’ll also see that the Java EE 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 Java EE components and APIs to build that part of your applications.

Why Java EE ?

Java EE 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 know that there is a great deal of effort, time, and expense in building the infrastructure of plumbing and wiring, which 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) to the infrastructure.

Suppose, though, that the wiring and plumbing in your home wasn’t already there. You would need to put in your own plumbing and electricity. Without standard components and interfaces, you would need to fabricate your own pipes, wiring, and so on. It would be terrifically expensive and an awful lot of work.

Similarly, 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 scalable, robust, secure, and maintainable. Some vital pieces of that infrastructure include security, database access, and transaction control. Security ensures that users are who they claim to be and can access only 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.

Putting in a distributed computing infrastructure—the plumbing and wiring of an architecture that supports enterprise applications—is no simple feat. That’s why Java EE-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 wouldn’t 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. And if you were lucky enough to find a vendor that could sell you a software infrastructure, you would need to worry about being locked into that single vendor’s implementation, and not being able to switch vendors at some point in the future.

The good news is, no surprise, that Java EE defines a set of containers, connectors, and components that fill that gap. Java EE not only fills the gap, but it’s based on well-known, published specifications. That means that applications written for Java EE will run on any number of Java EE-compliant implementations. The reference implementation supplied with the Java EE Software Development Kit from Sun (Java EE SDK) 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 Java EE SDK.

Multitier Architecture

One of the recurring themes that you’ll run into with Java EE is the notion of supporting applications that are partitioned into several levels, or tiers. That is an architectural cornerstone of Java EE and merits a little explanation. If you are already familiar with n-tier application architectures, feel free to skip ahead. Otherwise, the overview presented here will be a good introduction or review that will help lay the foundation for understanding the rationale behind much of Java EE’s design and the services it provides.

If you think about a software application composition, you can break it down into three fundamental concerns, or logical layers:


• The first area of concern is displaying stuff to the user and collecting data from the user. That user interface layer is often called the presentation layer, since its job is to present stuff to the user and provide a means for the user to present stuff to the software system. The presentation layer includes the part of the software that creates and controls the user interface and validates the user’s ctions.

• Underlying the presentation layer is the logic that makes the application work and handles the important processing. The process in a payroll application to multiply the hours worked by the salary to determine how much to pay someone is one example of this kind of logic. This logical layer is called the business rules layer, or more informally the middle tier.

• All nontrivial business applications need to read and store data, and the part of the software that is responsible for reading and writing data—from whatever source that might be—forms the data access layer.

Single-Tier Systems

Simple software applications are written to run on a single computer, as illustrated in Figure 1-1. All of the services provided by the application—the user interface, the persistent data access, and the logic that processes the data input by the user and reads from storage—all exist on the same physical machine and are often lumped together into the application. That monolithic architecture is called single tier, because all of the logical application services—the presentation, the business rules, and the data access layers—exist in a single computing layer.



Single-tier systems are relatively easy to manage, and data consistency is simple because data is stored in only one single location. However, they also have some disadvantages. Singletier systems do not scale to handle multiple users, and they do not provide an easy means of sharing data across an enterprise. Think of the word processor on your personal computer: It does an excellent job of helping you to create documents, but the application can be used by only a single person. Also, while you can share documents with other people, only one person can work on the document at a time.

Client/Server (Two-Tier) Architecture

More significant applications may take advantage of a database server and access persistent data by sending SQL commands to a database server to save and retrieve data. In this case, the database runs as a separate process from the application, or even on a different machine than the machine that runs the rest of the program. As illustrated in Figure 1-2, the components for data access are segregated from the rest of the application logic. The rationale for this approach is to centralize data to allow multiple users to simultaneously work with a common database, and to provide the ability for a central database server to share some of the load associated with running the application. This architecture is usually referred to as client/server and includes any architecture where a client communicates with a server, whether that server provides data access or some other service.

It’s convenient and more meaningful to conceptualize the division of the responsibility into layers, or tiers. Figure 1-3 shows the client/server software architecture in two tiers.

One of the disadvantages of two-tier architecture is that the logic that manipulates the data and applies specific application rules concerning the data is lumped into the application itself. This poses a problem when multiple applications use a shared database. Consider, for example, a database that contains customer information that is used for order fulfillment, invoicing, promotions, and general customer resource management. Each one of those applications would need to be built with all of the logic and rules to manipulate and access customer data. For example, there might be a standard policy within a company that any customer whose account is more than 90 days overdue will be subject to a credit hold. It seems simple enough to build that rule into every application that’s accessing customer data, but when the policy changes to reflect a credit hold at 60 days, updating each application becomes a real mess.

You might be tempted to try to solve this problem by building a reusable library that encapsulates the business rules. When the rules change, you can just replace that library, rebuild the application, and redistribute it to the computers running the application. There are some fundamental problems with that strategy, however. First, that strategy assumes that all of the applications have been created using the same programming language, run on the same platform, or at least have some strategy for gluing the library to the application. Next, the applications may need to be recompiled or reassembled with the new library. Moreover, even if the library is a drop-in replacement without requiring recompiling, it’s still going to be a royal pain to make sure that each installation of the application has the right library installed simultaneously (it wouldn’t do to have conflicting business rules being enforced by different applications at the same time).

In order to get out of that mess, the logical thing to do is to physically separate those business rules out from the computers running the applications onto a separate server so that the software that runs the business rules needs to be updated only once, not for each computer that runs the application.

N-Tier Architecture

In this model, all of the business logic is extracted out of the application running at the desktop. The application at the desktop is responsible for presenting the user interface to the end user and for communicating to the business logic tier. It is no longer responsible for enforcing business rules or accessing databases. Its job is solely as the presentation layer.


Typically, in a deployed application, the business logic tier executes on a server apart from the workstation (you’ll see shortly that this isn’t absolutely required, though). The business logic tier provides the logical glue to bind the presentation to the database. Since it’s running on a server, it’s accessible to any number of users on the network running applications that take advantage of its business rules. As the number of users demanding those services increases, and the business logic becomes increasingly complex and processor-intensive, the server canbe scaled up or more servers can be added. Scaling a single server is a lot easier and cheaper than upgrading everyone’s workstations.

One of the really great things that this architecture makes possible is the ability to start to build application models where the classes defined in the business logic tier are taken directly from the application domain. The code in the business logic layer can work with classes that model things in the real world (like a Customers class) rather than working with complex SQL statements. By pushing implementation details into the appropriate layer, and designing applications that work with classes modeled from the real world, applications become much easier to understand and extend.

It’s possible to continue the process of partitioning the application functionality into increasingly thin functional layers, as illustrated in Figure 1-5. There are some very effective application architectures based on n-tier architecture. The application architect is free to partition the application into as many layers as appropriate, based on the capabilities of the computing and network hardware on which the system is deployed. However, you do need to be careful about reaching a point of diminishing returns, since the performance penalty for the network communication between the layers can start to outweigh any gains in performance.


In summary, n-tier application architecture is intended to address a number of problems, including the following:

• The high cost of maintenance when business rules change. N-tier applications have improved maintainability.
• Inconsistent business rule implementation between applications. N-tier applications provide consistency.
• Inability to share data or business rules between applications. N-tier applications offer interoperability.
• Inability to provide web-based front ends to line-of-business applications. N-tier applications are flexible.
• Poor performance and inability to scale applications to meet increased user load. N-tier applications are scalable.
• Inadequate or inconsistent security across applications. N-tier applications can be designed to be secure.

The Java EE architecture is based on the notion of n-tier applications. Java EE makes it very easy to build industrial-strength applications based on two, three, or more application layers, and provides all of the plumbing and wiring to make that possible.

Note that n-tier architecture does not demand that each of the application layers run on a separate machine. It’s certainly possible to write n-tier applications that execute on a standalone machine, as you’ll see. The merit of the application design is that the layers can be split apart and deployed on separate machines, as the application requires.

Vendor Independence

Sun Microsystems—the company that created the Java platform and plays a central role in Java technologies, including the Java EE 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 Java EE have created it as an open specification that can be implemented by anyone.
To date, there are scores of Java EE-based application servers that provide a platform for building and deploying scalable n-tier applications. Any application server that bills itself as Java EEcompliant must provide the same suite of services using the interfaces and specifications that Sun has made part of Java EE.

This provides the application developer with a number of choices when implementing a project, and similar choices down the road as more applications are added to an organization’s suite of solutions. Building an application atop the Java EE architecture provides substantial decoupling between the application logic that you write and the other stuff—security, database access, transaction support, and so on—provided by the Java EE server.

Remember that all Java EE servers must support the same interfaces defined in the Java EE 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 Java EE server you use in your production environment. Moving your application over to the new production environment can be almost trivial.


Platform independence is something that you can take advantage of in your development. For example, you may be away from the office quite a bit, and use your notebook computer running Windows to do development. It’s pretty easy to use that configuration to build, test, and debug (Java EE has great support for pool-side computing). When you’re back in the office and happy with a particular component, you can deploy it to, say, Linux-based servers with little effort, despite the fact that those servers are running a different operating system and different Java EE implementation (after testing, of course!).

Bear in mind that each Java EE vendor provides some added value to its particular Java EE implementation. After all, if there weren’t market differentiators, there would be no competition. The Java EE specification covers a lot, but there is also a lot that is not specified in Java EE. Performance, reliability, and scalability are just a few of the areas that aren’t part of the Java EE specification 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:

• Your production applications can potentially benefit from capabilities not supported in the Sun Java EE reference implementation. Just because your application’s performance stinks on the reference implementation running on your laptop doesn’t mean that Java EE is inherently slow.
• Any vendor-specific capabilities that you take advantage of in your production applications may impact the vendor independence of your application.

Scalability

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—an unanticipated number of users using 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 Java EE 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 Java EE applications. Several providers of Java EE 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 Java EE framework.

Features and Concepts in Java EE

Getting your arms around the whole of Java EE will take some time, study, and patience. You’ll need to understand a lot of concepts to get started, and these concepts will be the foundation of more concepts to follow. The journey through Java EE 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. Here, we’ll provide an overview of some important Java EE features and concepts.

Java EE Clients and Servers

Up to this point, we’ve been using terms like client and server somewhat loosely. These terms represent fairly specific concepts in the world of distributed computing and Java EE.

A Java EE client can be a console (text) application written in Java, or a GUI application written using the Java Foundation Classes (JFC) and 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.

Java EE clients may also be web-based clients; that is, clients that live inside a browser. Because these clients offload much of their processing to supporting servers, they have very little in the way of supporting code. This type of client is often called a thin client. A thin client may be a purely HTML-based interface, a JavaScript-enriched page, or one that contains a fairly simple applet where a slightly richer user interface is needed.

It would be an oversimplification to describe the application logic called by the Java EE clients as the “server,” although it is true that, from the perspective of the developer of the clientside code, that illusion is in no small way the magic of what the Java EE platform provides. In fact, the Java EE 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 JSPs or Servlets. Business components, in the world of Java EE, are EJBs.
These server-side components rely on the Java EE framework. Java EE provides support for the server-side components in the form of containers.

Containers

Containers are a central theme in the Java EE architecture. Earlier in this chapter, we talked about application infrastructure in terms of the plumbing and electricity that a house provides for its inhabitants. Containers are like the rooms in the house. People and things exist in the rooms, and interface with the infrastructure through well-defined interfaces. In an application server, web and business components exist inside containers and interface with the Java EE infrastructure through well-defined interfaces.

In the same way that application developers can partition application logic into tiers of specific functionality, the designers of Java EE have partitioned the infrastructure logic into logical tiers. They have done the work of writing the application support infrastructure—things that you would otherwise need to build yourself. These include security, data access, transaction handling, naming, resource location, and the guts of network communications that connect the client to the server. Java EE provides a set of interfaces that allow you to plug your application logic into that infrastructure and access those services.

Think of containers as playing a role much like a video gaming console into which you plug game cartridges. As shown in next Figure, 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 needs to be concerned only with itself; it doesn’t need to concern itself with how the game is displayed to the user, 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 worry about 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, as illustrated in next Figure. The browser’s container for applets provides an environment for the applet. The browser and the container know how to interact with any applet because all applets implement the java.applet.Applet class 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. You do not need to be concerned with the issues associated with making your application appear to be an integral part of the web browsers.

Java EE provides server-side containers for the same reason: To 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, without worrying about the plumbing and electricity. Containers handle all of the mundane details involved with starting up services on the server side, activating the application logic, and cleaning up the component.

Java EE and the Java platform provide containers for web components and business components. These containers—like the gaming console analogy presented earlier in the chapter—provide an environment and interface for components that conform to the container’s established interfaces. The containers defined in Java EE include a container for Servlets, JSPs, and EJBs.