An enterprise application is expected to be used simultaneously by more than one user. In fact, such applications are often expected to be accessed simultaneously by hundreds or even thousands of users.

This adds complexity as you now need to apportion system resources across these users. In addition, you must also ensure that one user does not interfere with the operations of another, even if they happen to be working on the same data.

An enterprise application is one where there is usually significant potential for loss if its users are unable to access and use it in a predictable manner. This encompasses the concepts of availability, reliability, and scalability.

An online banking application has to be available when the customer needs it, irrespective of the time of day. It has to function reliably when used by that customer and should be able to handle higher peak loads over certain periods such as major holidays like Christmas or the periods when paychecks are deposited by employers.

A failure on any one of these criteria results in a loss of customers, a loss of revenue, or both.

While these characteristics are equally important to non-enterprise applications, the impacts of failure are often much less dramatic as such applications are generally designed to be used either by a single user, or by a very small set of users.

A typical enterprise application has very little control over its destiny. Most often it is cobbled together from various collaborating systems, many of which have been in operation for a number of years (or decades).

An enterprise typically already has a significant investment in terms of software, hardware, staffing, and infrastructure in its existing legacy systems. By necessity, any new development needs to play nice with these. This may include software systems (such as Enterprise Resource Planning systems, Custom Relationship Management products, and mainframe systems), operating systems, data sources (such as IMS, Oracle, and SQL Server), application servers (such as WebSphere, WebLogic, and JBoss), communication protocols, and data formats. An ability to integrate nicely with these disparate technologies is the hallmark of an enterprise application.

A point of note is that one of the most significant investments that an enterprise makes is in its data. Most of the time this investment is locked within silos throughout the enterprise, making the task of turning it into useful information a very daunting one. Most enterprise applications have, as their central focus, the ability to access this shared data, freeing it from the grips of traditional systems.

On the other hand, non-enterprise applications are fairly standalone entities. For instance, installations of Microsoft Money never need to deal with the issues of application or system integration, or with the issues of integrating data from multiple data stores.

The only real complexity often arises from data transfer format requirements. For example, personal finance software will typically download transaction data from financial institutions using either the Open Financial Exchange (OFX) or the Web Connect (QFX) formats.

An enterprise application rarely runs on a single computer host. This is almost always necessitated because of performance and scalability, as there is a practical limit on how much work can be assigned to a particular computer; as well as of heterogeneity, since the collaborating systems may run on their own dedicated hardware.

As a result, when describing your enterprise application, you tend to speak in terms of server farms, clusters, load balancers, DMZs, firewalls, and so on.

A corollary of this fact is that portions of the enterprise application itself may be distributed across multiple hosts. For instance, the logic that determines what is rendered to the user can be separated into its own tier from that of the logic that defines the business rules for the application, and there can be yet another tier that houses the persistent data store used by the application.

It is important to note that these tiers can either be logical (when all these tiers run on the same physical machine, possibly within the same Java Virtual Machine) or physical (when each of these tiers runs on a dedicated physical machine.)

On the other hand, the typical vanilla application runs on a single workstation and is designed to serve a single user. You will be hard pressed to find a distributed implementation of either Money or Quicken.

To summarize, there are very valid reasons as to why enterprise application development is crucial to a corporation's survival - it serves as the best way to leverage your existing technology investments.

The Java EE platform is a superset of the Java SE platform. As a result, it inherits its basic advantages, such as the ability to run Java applications on diverse operating systems, its mature and flexible object-oriented programming model, its ability to work well across a network (including over the Internet), its automatic garbage collection mechanism, and its inherent multithreaded nature, all of which make for a very compelling package.

A key aspect of enterprise application development is the need to work and integrate with a variety of disparate systems. Learning the individual APIs of each of these diverse systems can be an insurmountable task. Java EE provides a solution for this problem—by separating the vendor-agnostic aspect of an interaction, the API, from the vendor-implementation aspect, termed the Service Provider Interface (SPI).

This design provides for an astonishing decrease in the level of complexity that developers need to contend with during enterprise development.

As an example, consider the Java Naming and Directory Interface API. The published API is generic enough to be used against any particular vendor implementation, whether LDAP, the RMI Registry, or even just the file system.

As a developer, all you need is to be aware of the vendor-agnostic API. You will also supply some configuration information that is appropriate for your choice of vendor such as the URL at which to access the service, authentication credentials, and the factory class for the initial context.

A service provider implements not only the SPI that defines the core service implementation, but also any abstract classes and interfaces that are left undefined in the API itself. Service providers may be linked into the Java EE platform server either statically (through configuration files or deployment descriptors) or dynamically at runtime. When multiple providers implement the same functionality, an application may choose, at runtime, which particular provider's implementation to use.

As an application programmer, you will typically use a factory method to interact with the service provider, which will return to you the appropriate instance, which implements an interface within the Java EE API. Your application interacts with this generic interface using the functions defined by the API and is completely oblivious to the specific implementation class.

This basic theme is repeated over and over again within the Java EE.

The Java EE platform is designed around a containment hierarchy, where an application server hosts containers, each of which in turn hosts components.

A container is responsible for configuring its components based on the deployment descriptor, allowing component behavior to be controlled using configuration rather than code. For example, a deployment descriptor may specify that a particular Enterprise JavaBeans method may not be invoked unless the user belongs to a given security role.

It is also responsible for managing the life cycle of its components. For instance, a servlet container will load the servlet class, instantiate it, call its initialization method, will repeatedly call its service method as requests come in, and will finally call its destruction method when it is being taken out of service.

The container is also the gateway through which its components may access their runtime environment. It is also the intercessor when one component needs to communicate with another Java EE component. This intercession allows the container to add value by transparently propagating transactions, implementing security checks, and so on.

This container-based architecture provides an effective way of providing a separation of concerns. The deployed components can now focus on the business problem being solved, whereas the container can provide the plumbing and infrastructure required to make everything work.

Each platform vendor must implement these containers so as to maintain the contract with its components as specified in the appropriate API specification. While this does not stop the vendor from providing additional services through the container, it does ensure that each component can be guaranteed to find a baseline set of services, irrespective of the particular vendor implementation that it is deployed into.

The Java EE specification defines four types of containers.

An application client container provides the runtime environment for Java programs (either graphical user interface based or command line) that execute on a client workstation. Application clients are the same as standard Java SE applications, so no special life cycle calls are made by this container.

An applet container contains applets that typically execute natively within a browser or through the Java Plug-in product.

A servlet container hosts Servlet API and JavaServer Pages API components, which are used to service HTTP requests from web clients.

Finally, an Enterprise JavaBeans (EJB) container hosts EJB components, which houses the business logic that is usually found in the middle tier of a Java EE application.

A typical servlet container (such as Apache Tomcat) will, among other things, allow a developer to package a web application as per the Servlet specification. It will load the appropriate servlets as necessary, will invoke a servlet's lifecycle and service methods, and will provide the servlet instance with access to information about its operating context.

Similarly, an EJB container will provide its contained components (Enterprise JavaBeans) with services for security, transactions, instance pooling, and so on.

A container is usually controlled through configuration files, such as Tomcat's server.xml file.

This figure summarizes the concepts that we've introduced so far—the distinction between the API and the SPI, the Java EE containers, and the component model. The specification of the platform is comprised of the specifications for multiple containers. Each container is responsible for hosting its own component model. The components for each container expect certain services to be provided by their container.

The face that services expose to components is defined by the service's API. The vendor implements each service by providing code that implements the SPI, the abstract classes, and interfaces that are defined by the API.

Finally, a deployment descriptor may be used to configure the container's services and runtime environment, as well as to define how the components are deployed into that service.

The Technology Compatibility Kit (TCK) is a set of tests that allow you to validate the compliance of a container implementation with its specification.

The Java EE platform uses a component-based development model. This is different from a class-based model as a component typically consists of more than one class cooperating to achieve some reusable unit of functionality.

A Java EE application is built by assembling multiple such standalone components and deploying them with their configurations into their associated containers.

The power of Java EE comes from the fact that components can be independently developed, tested, assembled, and deployed into any Java EE compliant vendor's server implementation.

Each container can deploy its own unique set of components. The application client container can contain application client components, which are standard Java programs. The applet container contains applet components. The web container contains web components, such as JSP, Servlet, Filter, and event listener components, whereas the EJB container contains enterprise bean components.

Application logic typically resides in the components, and business logic usually resides in the enterprise bean components.

In this book, we will primarily focus on the servlet container and web components.

The Service APIs serve to simplify your programming tasks by providing standard APIs to access diverse systems or alternative implementations.

The key APIs that are defined by the Java EE platform include: