If you have installed the Java EE
Platform, Enterprise Edition, software and gone through the various
Java EE tutorials
available to help you get started, you are probably ready to write
your first multitiered enterprise application for the Java EE platform.
At this point you might be wondering where to start with your
application design and how to decide which Java EE APIs will best meet
your requirements.
Help is available. Designing Enterprise Applications for the Java 2 Platform, Enterprise Edition ISBN 0-201-70277-0, describes the Java EE platform and presents a programming model to help you make the best decisions when you design multitiered enterprise applications for the Java EE platform. To put theory into practice, Chapter 10 presents an example ecommerce pet store application and describes how the programming model guided its design. The book and pet store application taken together are referred to as the Java EE Blueprints.
This article is a digest of the Java EE Blueprints to introduce you to the programming model and help you get started. You can go to the Java EE downloads page for a PostScript or PDF version of the book or to download the example pet store application. The printed book will be available in June 2000.
The fast-moving and demanding world of ecommerce and
information technology has put a pressure on application
developers. Enterprise applications have to be designed, built, and
produced for less money, faster, and with fewer resources than ever
before.
To reduce costs and fast-track enterprise application design and development, the Java EE platform provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The Java EE platform gives you a multitiered distributed application model, the ability to reuse components, a unified security model, and flexible transaction control. Not only can you deliver innovative customer solutions to market faster than ever, but your platform-independent Java EE component-based solutions are not tied to the products and APIs of any one vendor.
The Java EE specification defines the following kinds of components:
A multitiered distributed application model means the application logic is divided into components according to function, and you can install the different application components that make up a Java EE application on the same or different servers. Where an application component is installed depends on which tier in the multitiered Java EE environment the application component belongs to. The tiers are client tier, web tier, business tier, and enterprise information system (EIS) tier.
Java EE applications can be web-based and non-web-based.
In a web-based Java EE application, the user's browser runs in
the client tier and downloads static HTML pages or dynamic
HTML pages generated by JSP pages or servlets in the web tier
from a web server.
In a non-web-based Java EE application, a stand-alone application client, or applets that do not run in an HTML page, but in some other network-based system such as a handheld device or car phone, run in the client tier and access enterprise beans running in the business tier without going through the web tier. The non-web-based client tier might also include a JavaBeans class to manage the user input and send it to enterprise bean classes running in the business tier for processing. JavaBeans classes are not considered components by the Java EE specification.
JavaBeans classes written
for the Java EE platform have instance variables and get and
set
methods for accessing the data in the instance variables. JavaBeans
classes used in this way are typically simple in design and implementation,
but they should conform to the naming and design conventions outlined
in the JavaBeans specification.
Java EE web components can be made up of JSP pages, web-based applets, and servlets that display HTML pages. HTML pages that invoke servlets or JSP pages are bundled with web components during application assembly, but are not considered web components by the Java EE specification. Like the client tier, the web tier might include a JavaBeans class to manage the user input and send it to enterprise bean classes running in the business tier for processing.
Web components running in the client tier rely on containers to support such things as client requests and responses, and enterprise bean lookups.
Business code, which is logic that solves or meets the needs
of a particular business domain such as banking, retail, or finance,
is handled by enterprise beans running in the business tier. An enterprise
bean receives data from client programs, processes it (if necessary),
and sends it to the enterprise information system tier for storage. An enterprise bean also
retrieves data from storage, processes it (if necessary), and
sends it back to the client program.
Enterprise beans running in the business tier rely on containers to provide what would normally be very intricate system-level code for things like transaction, life cycle, and state management; multithreading; security; and resource pooling.
The business tier is often referred to as the Enterprise JavaBeans (EJB) tier. The business and web tiers taken together make up the middle tier in a 3-tiered Java EE application that consists of a client tier, middle tier, and storage or enterprise information system tier.
The enterprise information system tier handles enterprise information system software,
and includes enterprise infrastructure systems such as enterprise
resource planning (ERP), mainframe transaction processing, database
systems, and other legacy information systems. Java EE application components
might need to access enterprise information systems for such things as database access.
Note: A future version of the Java EE platform will support the Connector architecture, which is a standard API for connecting the Java EE platform to enterprise information systems.
Because the components of a Java EE application run separately and often
on different devices, there needs to be a way for client and web tier
code to look up and reference other code and resources. Client and
web tier code use the Java Naming and Directory Interface (JNDI) to
look up user-defined objects such as enterprise beans, environment
entries such as the location of a database driver,
JDBC DataSource objects
for looking up resources in the enterprise information system tier, and message connections.
Application behavior such as security and transaction management can be configured at deployment time on web and enterprise bean components. This feature decouples application logic from configuration settings that might vary with the assembly.
The Java EE security model lets you configure a web or enterprise bean
component so system resources are accessed only by authorized users. For
example, a web component can be configured to prompt for a
user name and password. An enterprise bean component can be
configured so only persons in specific groups can invoke
certain of its methods.
Or, a servlet component might be configured to have some of its methods accessible to everyone and a few methods accessible to only certain privileged persons in an organization. The same servlet component can be configured for another environment to have all methods available to everyone or all methods available to only a select few.
The Java EE transaction model lets you specify at deployment time relationships among methods that make up a single transaction so all methods in one transaction are treated as a single unit. You would want to do this because a transaction is a series of steps that must either all complete or all be backed out.
For example, you might have a series of methods in an enterprise bean that move money from one account to another by debiting the first and crediting the second. You want the entire operation to be treated as one unit so if there is a failure after the debit and before the credit, the debit is rolled back.
Transaction attributes are specified on an application component during assembly. This lets you group methods into transactions across application components, which means you can easily change application components within a Java EE application and reassign the transaction attributes without changing code and recompiling.
When designing application components, keep in mind that while enterprise beans have a mechanism for multiple-step transactions to be started automatically by their containers, applet and application client containers might or might not support this. However, applet and application client containers can always invoke an enterprise bean that does.
Also note that JSP pages and servlets are not designed to be transactional and should usually delegate transactional work to an enterprise bean. However, if transactional work is necessary in a JSP page or servlet, it should be very limited.
Java EE components (applets, application clients, enterprise beans,
JSP pages, and servlets) are bundled into modules and delivered in
Java ARchive (JAR) files. A module consists of the relevant components,
related files, and deployment descriptors that describe how the
components are to be deployed.
For example, during assembly an
HTML page and servlet are bundled into a module that contains the
HTML file, servlet component, and related deployment descriptors and
delivered in a Web ARchive (WAR) file, which is a standard JAR file
with a .war extension. Using
modules makes it possible to assemble a number of
different Java EE applications using some of the same components.
For example, a web version of a Java EE application can have an enterprise bean component coupled with a JSP page component. The same enterprise bean component can be coupled with an application client component to make the non-web version of the same application. No extra coding is needed; it is just a matter of assembly and deployment.
Also, resusable components make it possible to divide the application development and deployment process into distinct roles so different people or companies can perform different parts of the packaging and deployment process. The Java EE platform defines the following roles:
The company that designs and makes available for purchase the Java EE platform, APIs, and other features defined in the Java EE specification.
The company or person who creates web components, enterprise bean components, applets, or application clients for use in Java EE applications. During assembly, application component files, interfaces, and classes are bundled into a JAR file.
The company or person who gets application
component JAR files from component providers and assembles them into
a Java EE application Enterprise ARchive (EAR) file, which is a
standard JAR file with an .ear extension.
Application assemblers provide information related to the application as a whole and use verifier tools to check that the contents of an EAR file are well-formed. Assembly and deployment information is stored in a text-based deployment descriptor that uses XML tags to mark the text. The Assembler can edit the deployment descriptor directly as described in Chapter 7 of Designing Enterprise Applications or use an assembly and deploy tool which will correctly add XML tags according to your interactive selections.
The company or person who deploys the Java EE application. Duties include such things as setting transaction controls, security attributes, and indicating whether an enterprise bean handles its own storage or has the container do it according to instructions supplied by the application component provider.
Deployment involves configuration and installation. During configuration, the deployer follows instructions supplied by the application component provider to resolve external dependencies, specify security settings, and assign transaction attributes. During installation, the deployer moves the application components to the server, and generates the container-specific classes and interfaces.
The person who configures and administers the computing and networking infrastructure where Java EE applications run, and oversees the runtime environment.
The person or company who makes development, assembly, and packaging tools used by component providers, assemblers, and deployers.
When designing the user interface and back end engine for a Java EE application, you
need to decide whether to make the application web-based or non-web-based.
In making this decision, you might want to consider platform
configurations, download speed, security, network traffic, and network services.
For example, an applet with an involved user interface that is accessed frequently by a lot of people might take too long to download and create a frustrating user experience. However, if you know the applet is to run within the controlled environment of a company's Intranet domain, the applet download might have a perfectly acceptable speed under those circumstances.
Another consideration is where the heavy processing should take place. For example, if the client executes in a cell phone or pager, the server should perform as much computation and data processing as possible and the client should only display results. However, a heavy financial analysis system designed to run on a powerful desktop platform should perform its complex computations on the client.
Application client and applet user interfaces are typically created with the Swing API, which is available in the Java 2 Platform, Standard Edition. The Swing API provides a comprehensive set of GUI components (tables, trees, buttons, etc.) that can be used to provide a more interactive experience than you can get with a typical HTML page. Swing also supports HTML text components that you can use to display responses from a server.
Client programs can access the enterprise bean or enterprise information system tiers directly. These programs should be implemented with care and caution. Programs that bypass the EJB tier can use the JDBC API to access a relational database, and should be limited to administration or management tasks such as maintenance on database tables.
Web-based applications are browser based, and if they
run on the Internet, are likely to be accessed by people
from all over the world. When you design a web-based
application, you not only have to decide what to use to handle
your content and application logic (HTML, XML, JSP pages,
servlets), but you should also consider internationalizing
the application.
An internationalized web-based application provides a way for users to select a language and then loads the application text based on the selected language. Application text is stored in an external file and mapped to key words with a separate file for each language supported. The application code uses the key words and selected language to load the correct text. The internationalization API also provides classes for formatting dates and money based on the language selected.
Once you work out the details for internationalizing your application, you can decide what to use to implement it. In general, a web-based application uses HTML to display data, XML to define data so it can be read and processed by another program, and JSP pages and/or servlets to manage the flow of data between the user and the business or storage tier.
There are four general types of web-based applications that you can implement with the Java EE platform. Going from the simplest to the most complex, they are:
When you design a web-based application, you have to decide what to use to build it. Also, if you are starting with a simple application, your design should accommodate growth if you think you will add functionality to the application over time. These next paragraphs compare and contrast JSP pages and servlets to help you make some of these design decisions.
Servlets are a portable, platform- and web server-independent way to deliver dynamic content. JSP pages are a text-based, presentation-centric way to develop servlets. JSP pages offer all the benefits of servlets, and when combined with a JavaBeans class, give you an easy way to keep content and display logic separate.
The advantage to separating content and display logic is the person who updates the look of the page does not have to understand Java code, and the person who updates the JavaBeans class does not have to be proficient at designing web pages. Both JSP pages and servlets are more desirable than Common Gateway Interface (CGI) because CGI is not platform independent, uses more overhead, and does not have an easy way to access parameter data and pass it to a program.
You can use JSP pages with JavaBeans classes to define web templates for building a web site made up of pages with a similar look and feel. The JavaBeans class does the data rendering, so your templates have no Java code, which means they can be maintained by an HTML editor.
In choosing whether to use a servlet or a JSP page, keep in mind that servlets are a programmatic tool best suited for low-level application functions that do not require frequent modifications. JSP pages are a presentation-centric, declarative way to bind dynamic content and logic.
If you have a simple web-based application using a JSP page, you can bind content to application logic using custom tags or scriptlets instead of a JavaBeans class. Custom tags are bundled into tag libraries that are imported into a JSP page. Scriptlets are small Java code segments embedded directly in the JSP page.
With all the flexibility built into the component-based Java EE
platform, the question might be how to organize any application for
streamlined application update and maintenance, and to protect application
data from persons who do not understand program code. The answer is in
using the Model, View, Control (MVC) architecture. An architecture
such as MVC is a design pattern that describes a recurring problem
and its solution
where the solution is never exactly the same for every recurrence.
The MVC design pattern consists of three kinds of objects: The model provides the application business logic (enterprise bean classes), the view is its screen presentation (HTML page, JSP page, Swing GUI), and the controller is a servlet, JavaBean or session bean class that manages what happens when the user interacts with the view. You can think of the controller as sitting between the view and the data to manage how the view interacts with the model.
By making the view completely independent of the controller and model, you can easily substitute front-end clients. Also, by keeping controller and model code out of the view, persons who do not understand this code cannot change things they should not change. Keeping the controller and model separate lets you change the controller without interfering with the model and change the model without interfering with the controller.
For example, if your front end is an HTML page, an HTML expert can update it. If you use a JSP page, move the Controller code to an underlying JavaBean or session bean class or use action tags so the JSP page contains only JSP code.
When you write Java EE applications that manage a specific business
function such as tracking employee data or performing complex
financial calculations, put the business logic for these tasks
in enterprise beans that run in the EJB tier. This way you can focus
your code on solving the business
problem at hand and leverage the enterprise bean container
for supporting low-level services such as state management,
transaction management, thread management, remote access to data,
and security.
Separating business logic from low-level system logic means the container can create and manage the enterprise bean at runtime. Any enterprise bean coded to specification, can be configured for transaction management or security attributes according to how it will be used in a given Java EE application, and deployed to any specification-compliant container. Reusable components makes this all possible without changing and recompiling the enterprise bean's code.
An enterprise bean consists of interfaces and classes. Clients access enterprise bean methods through the enterprise bean's home and remote interfaces. The home interface provides methods for creating, removing, and locating the enterprise bean and the remote interface provides the business methods. At deployment time, the container creates classes from these interfaces that it uses to provide access to clients seeking to create, remove, locate, and call business methods on the enterprise bean. The enterprise bean class provides the implementations for the business methods, create methods, and finder methods; and if the bean manages its own persistence, provides implementations for its life cycle methods as well.
There are two types of Enterprise beans: entity beans and session beans.
Session beans can be stateful or stateless. A stateful session bean
contains conversational state on behalf of the client. The
conversational state is the session bean's instance field values
plus all objects reachable from the session bean's fields.
Stateful session beans do not represent data in a persistent data
store, but they can access and update data on behalf of the client.
Stateless session beans do not have any state information for a specific client. They typically provide server-side behavior that does not maintain any particular state. Stateless session beans require fewer system resources. A business object that provides a generic service or represents a shared view of stored data is a good candidate for a stateless session bean.
Because enterprise beans use significant system resources and
bandwidth, you might want to model some business objects as
data access or value objects instead. Data access objects
do such things as access the database on behalf of the client.
Value objects represent a structure to hold data fields and
provide simple get and set methods
to access the data.
Additionally, you can structure your application to use an enterprise bean to mediate communication between the client and the rest of the EJB tier.
An enterprise bean using container-managed persistence to access a relational database, does not require you to use any JDBC 2.0 APIs for database access because the container handles this for you. However, if you use bean-managed persistence or if you want to access an enterprise information system other than a relational database, you will have to provide the appropriate code to do it.
In the case of an Enterprise bean using bean-managed persistence to access a database, you will have to implement the bean's life cycle methods with JDBC 2.0 API code to handle loading and storing data and maintaining consistency between the runtime and persistent database storage.
An enterprise bean using bean-managed persistence or a web-based
component needing to access an enterprise information system has to provide the
appropriate code. The appropriate code might be JDBC 2.0 APIs
for database access, an enterprise information system API to access a specific
enterprise information system,
an AccessObject for abstracting the complexity and
low-level details of enterprise information system APIs, or a
Connection object for accessing enterprise information
system resources.
While the web tier uses HTTP or HTTPS to transfer data between tiers, the EJB tier uses RMI-IIOP. RMI-IIOP is a full scale distributed computing protocol that gives any client or web tier program accessing an enterprise bean direct access to the services in the EJB tier. These services include JNDI for looking up and referencing enterprise beans, Java Message Service (JMS) for sending and receiving asynchronous messages, and JDBC for relational database access.
Chapter 10 of Designing Enterprise Applications applies
the Java EE application programming model to an example pet store
application. You can download the demo from the
Downloads page
on the java.sun.com web site,
and you will find configuration and installation
instructions in the top-level directory of the download.
In Chapter 10, the application development process is described from its specification and design phase through implementation to assembly and deployment where security and transaction attributes are assigned. The first section of Chapter 10 describes application scenarios, and then goes on to cover architecture, partitioning functionality, assigning functionality to tiers, and decomposing objects within the tiers.
1 As used on this web site, the terms Java virtual machine or Java VM mean a virtual machine for the Java platform.
© 1994-2005 Sun Microsystems, Inc.