Understanding Tiers and Components

The 3-tier model splits an application down so that business logic resides in the middle of the 3 tiers. This is often called the middle tier, business tier, or EJB tier. Throughout this section, this tier will be referred to as the business tier. The first tier has the role of providing the interface between the user and the application. Depending on your specific architecture, this can be known as the client tier or presentation tier. Throughout this section, the term presentation tier will be used to define this client-centric tier.

Most of the code written by J2EE application developers resides in the presentation and business tiers. The next two sections explore these tiers. You will see that different types of components are used in each tier to deliver particular application functionality. The components in different tiers should be loosely coupled. In other words, a component should not have dependencies on the client or other components. For example, imagine a business component that processes credit card payments. If the component is self contained, almost any application can pass it payment information and it, in turn, can return an appropriate response. Figure 2.1 shows such a business component communicating with a variety of clients:

As you can see, because this business component encapsulates all the payment process functionality, it is not tied to any component in the presentation tier, so it can serve multiple client types. Code that supports more than one type of client is only one advantage of component architecture; you will learn about some of the other advantages later in this chapter.

The Business Tier

As you have just seen, business components sit in the business tier of a J2EE application. These business components encapsulate business logic and are used by components in the presentation tier that deliver this functionality to users of the application.

Benefits of Business Components

Previously, you saw a simple credit card processing component that provided that service for a number of different clients. This demonstrated just one benefit of component architecture but, in fact, components offer many advantages over a composite architecture:

• Increased efficiency— The division of labor helps a business to roll out applications quickly. The use of components allows presentation developers to develop GUIs, process programmers to focus on business logic, and data access experts to focus on data access.

• Extensibility— You can simply add or remove components to an application so that it can offer further functionality, for example, if you want to expose application functionality through a Web Service. The component architecture allows you to simply add the additional units of functionality the system requires. By the way, if you don't know about Web Services, don't worry. Day 20, “Using RPC-Style Web Services with J2EE,” and Day 21, “Web Service Registries and Message-Style Web Services,” show you how to apply a J2EE application as a Web Service.

• Language independence— A modularized system allows you to write code in one language that communicates with code written in another. For example, you can access the functionality of a J2EE application from a CORBA client by using RMI-IIOP, or from a Microsoft COM client by using the Client Access Services COM Bridge.

• System upgrade— Inevitably, an organization's business processes change, and so too must the application logic. The use of components allows you to change one component without affecting the other components in the system.

This list is not an exhaustive survey of the benefits of components. But it should make it clear that components offer both developers and business an ideal way of providing application functionality.

J2EE defines how various types of components perform specific roles in different tiers. In the presentation tier, different types of components will be applied to provide functionality for different types of client (application components, applet components, servlet components, and JavaServer Page components). The business tier houses different types of business components. In J2EE terms, business components are embodied as Enterprise JavaBeans. The following sections focus on how such components are applied for the most common application architecture currently—namely, a business system with a Web-based user interface.

Components: Enterprise JavaBeans

In a typical business application built on the J2EE platform, business logic will be encapsulated in Enterprise JavaBeans (EJBs). It is possible to use other types of component or plain Java objects to implement business logic, but EJBs provide a convenient way of encapsulating and sharing common business logic, as well as benefiting from the services provided by the EJB container.

Suppose you were tasked with designing and implementing a typical Web-based, e-commerce application. Although the precise analysis of the business problem would be specific to your own environment, you would probably end up with the following flow through your application:

1.	Display your products to the customer.
2.	Allow the customer to select one or more products.
3.	Confirm the order and take shipping details.
4.	Take payment for the items.
5.	Deliver the order to your warehousing and distribution systems.
6.	[optional] Authenticate the user to access previously stored personal information or preferences.
7.	[optional] Generate a report from the items purchased by a particular customer or on a particular day.

All of these steps involve a certain amount of business logic and data manipulation. For example, in step 1, your application will need to send pages of HTML to the customer's browser containing product descriptions and pricing information. To do this, you will need to retrieve this product and pricing information from somewhere. The obvious choice is a database that stores your product catalog information together with pricing information.

As you will see, it would be quite possible to deliver the catalog functionality you require simply by using database access code from a Web component such as a JavaServer Page. However, what if gathering this catalog information was not quite so straightforward?

• The product and pricing information may be spread across multiple databases. Even worse, it may be that some of the information must be extracted from (or delivered to, in the case of submitting an order) a legacy system. This means that the user-interface component would have to know details about data access.

• There may be extra business processes that need to be applied during the creation of the catalog. These could range from custom pricing for a specific group or individual through cross-selling of related products and on to the suggested substitution of alternative products for any that are not in stock. This means that the user interface component must have knowledge of multiple business processes.

• If a customer is to be identified and their preferences reflected, authentication is required. Also, some information about them and their preferences must be maintained against a database somewhere. This means that the user interface component must know about authentication and mapping user identity to stored information.

As you can see, the user interface component rapidly becomes its own version of the monolithic applications you saw yesterday. The business logic associated with all of this processing should be devolved to EJBs in order that the user interface component can concentrate on what it does best, namely generating a compelling user interface and guiding the user through a particular interaction.

What is needed then is for the business logic in the EJB to be made available to other components that may want to use it. The mechanisms involved must be commonly available to the potential clients to impose minimal overhead on those clients. Hence, the EJB model makes use of two mechanisms found in J2SE—namely Remote Method Invocation (RMI) and the Java Naming and Directory Interface (JNDI)—to facilitate interaction between the EJB and its client. When an EJB is written, the functionality it offers to clients is defined as an RMI remote interface. When an EJB is deployed, its location is registered in the naming service.

A client will then use JNDI to look up the location of the EJB. It will interact with a factory object, called the EJB's home, to obtain an instance of the EJB. This is equivalent of using new to create an instance of a local object. When the client has a reference to the EJB, it can use the business functionality offered by the EJB. This sequence is shown in Figure 2.2.

There is a more detailed look at how to use EJBs on Day 4, “Introduction to EJBs.”

Within the required business logic, certain components will be primarily concerned with data and the manipulation of that data, whereas others will focus on the sequencing of business logic and the associated workflow. Equally, components will interact in different ways, depending on the needs of the application. Some interactions will be synchronous in nature; there is no point in performing the next stage of the process until the current one has finished. Other interactions can be handled asynchronously; an appropriate message can be sent to another component and then the originator of the message can carry on to the next stage of the process. This means that clients using asynchronous interactions complete faster, but they may not be suitable for all applications if there must be a guarantee that an operation has completed or if return values are required. This difference between synchronous and asynchronous interactions is shown in Figure 2.3.

Because different business components are called on to behave in different ways, there are multiple types of EJB defined that can be used to encapsulate different parts of an application's business logic.

Components: Session Beans

Session EJBs, often just called session beans, are the simplest and probably most common type of EJB. A session bean is primarily intended to encapsulate a set of common business functions. When capturing the outputs of business analysis using the Unified Modeling Language (UML), Use Cases are identified. A Use Case documents a particular interaction sequence between a user and a system (a common example is withdrawing money from an ATM). Such an interaction typically involves multiple, but related, steps. The business logic associated with the steps from such a Use Case can typically be housed in a session bean. There are various analogies for and examples of session beans on Day 4 and Day 5, “Session EJBs.”

Session beans offer a synchronous interface through which the client can use the business logic. Session beans are not intended to hold essential business data. The session bean will either hold no data on an ongoing basis, or the data it does hold will tend to be temporary (only relevant to the current user session) rather than persistent. If a session bean wants to obtain data from a database, it can use JDBC calls. Such a bean may provide part of solution when providing an e-commerce catalog as described earlier. Alternatively, application data can be obtained through entity EJBs.

Components: Entity Beans

An entity EJB, again often just called an entity bean, is a representation of some business data. During analysis, various business concepts will be discovered, such as “customer” or “account.” These business “objects,” sometimes called “entities,” represent the core data manipulated during the business processes. If such a business object contains dynamic data, has associated functionality, and can be shared between multiple clients at any one time, this business object would probably map to an entity bean.

Entity beans offer a synchronous interface through which the client can access its data and functionality. Entity beans will access underlying data sources (frequently, a database or possibly an ERP system) to collect all the business information they represent. The entity bean will then act as the dynamic representation of this business data—providing methods to update and retrieve it in various ways. As you will see later, entity beans are frequently used together with session beans to provide the business functionality of a system. Entity beans are discussed further on Day 6, “Entity EJBs.”

A message-driven EJB, or just message-driven bean, fulfills a similar purpose to a session bean, but is asynchronous in nature. There are times when it is inefficient to interact synchronously with a component. One example would be if you wanted to log the details of a particular transaction to an underlying data store. In many cases, it is not important that the logging is done immediately, just as long as it is done reliably. This type of operation can quickly become a performance bottleneck if performed synchronously. The same is true of “undoable” operations, such as credit card processing.

Components: Message Beans

Message-driven beans offer an asynchronous interface through which clients can interact with them. The bean is associated with a particular message queue, and any messages arriving on that queue will be delivered to an instance of the message-driven bean. As with session beans, message-driven beans are intended to house business logic rather than data, so they will access any data required through JDBC or entity beans. To use the services of a message-driven bean, a client will send a message to its associated message queue. If a response is required, another message queue will typically be used. Message-driven beans and the Java Message Service with which they interact are discussed further on Day 9, “Java Message Service,” and Day 10, “Message-Driven Beans.”

The Presentation Tier

Given some business logic implemented as EJBs, you must provide clients with access to this functionality. What is needed is some presentation logic coupled with a way of displaying information to the user. The presentation logic will govern which screens are displayed to the user in which order and how the presentation logic will interact with the business logic in the business tier to work through the appropriate business process.

The way in which user input is received and information is displayed will depend on the type of client. The client can range from a WAP phone through to a standalone Java application with Swing interface. Each type of client will require different presentation tier functionality to exchange and display information. The most common type of client for a J2EE application is a Web client, in the shape of a Web browser. In this case, the presentation tier will present a Web-based interface that produces HTML and consumes HTML form-based input.

Components: Web-Centric

To create a Web-based user interface, you need to apply Web-centric components. J2EE provides two types of Web-centric components—JavaServer Pages (JSP) and Java servlets. These components are applied in the presentation tier and provide services to clients that use HTTP as a means of communication. For example, Web-centric components can interact with clients such as the following:

• Standard HTML-oriented browsers, such as Microsoft Internet Explorer and Netscape Navigator

• Java 2 Micro Edition (J2ME) enabled devices, connecting across a wireless network

• Desktop clients using raw HTTP or sockets functionality

• Wireless Markup Language (WML) browsers, such as those found on WAP-enabled mobile phones

Figure 2.4 shows how you would typically use these components.

Figure 2.4 shows a Web-centric client making a request to either a servlet or JSP. The server-side component parses the client's request and then calls the EJB. The EJB contains the application's business logic. When the servlet or JSP receives a response from the EJB, it is responsible for presenting the data it receives. After the servlet or JSP has prepared the response, it passes it back to the client, completing the request-response cycle.

The previous illustration demonstrated a model where the Web-centric component was responsible for presenting data supplied by an EJB. The EJB was responsible for the execution of the business logic. However, you do not have to use EJBs as part of a Web-centric solution. A simpler application can consist of pages of markup—for example, HTML—and servlets, or JSPs, or a combination of JSPs and servlets.

The next section of today's lesson shows you the relationship between JSPs and servlets, so that you are in a position to choose which of these technologies best suit your needs.

JavaServer Pages (JSP)

JSPs allow you to dynamically create pages of markup, such as HTML, in response to a client's request. If you are familiar with other Internet technologies, you can liken JSP to Active Server Pages (ASP) or ColdFusion. But be aware that these technologies are similar to JSP—not the same.

A JSP consists of a combination of JSP tags and scriplets, which contain the executable code, and static markup, such as HTML or XML. The code contained in the JSP is identified and executed by the server, and the resulting page is delivered to the client. This means that the embedded code can generate additional markup dynamically that is delivered to the client alongside the original static markup. The client sees none of this processing, just the result.

The JSP tags delimit sections of executable code and form the basis of any JSP page. Scriplets are delimited sections of script that allow a JSP further processing power. Typically, you can write this script using the Java programming language, but different JSP implementations may support additional languages.

Day 13, “JavaServer Pages,” shows you in detail how to write JSPs and how JSPs interact with other J2EE components. To whet your appetite today will introduce you to how JSPs work and interact with other J2EE components. Figure 2.5 shows a scenario that depicts the typical interactions of client, JSP, and J2EE components.

Figure 2.5 shows a client making a HTTP request for a JSP. The first time a user makes a request the JSP container handles it by converting the JSP into a Java source file and compiling it. In most implementations, this file is a servlet. The servlet forwards the request to a business logic component, such as another servlet, a JavaBean, or an Enterprise JavaBean. The component performs some action, such as accesses a database or processes the client's input, and returns a response to the servlet. The servlet passes this response to a JSP that generates the markup language that the client will display. Finally, the JSP container and the Web Server return the markup to the client.

As you can see, JSPs provide a very powerful method for dynamically creating pages of markup. They also allow Web clients to indirectly access the application logic that other J2EE components contain. Importantly, you have seen the relationship between a JSP and a servlet.

Java Servlets

Servlets add processing power to servers that employ a response-request model. Perhaps the most common of such servers is the Web server. In this instance in the past, CGI scripts would provide this kind of functionality; now you can use servlets. Although servlets are similar to CGI scripts, they are superior in many ways:

• Speed— You deploy servlets as Java class files. The class file consists of Java byte codes, which means that they execute faster than interpreted scripting languages, such as Perl.

• Platform Independence— Servlets are platform-independent classes, so they can be run under different servers on different operating systems.

• Consistency— Servlets use a standard API (the Servlet API), so they enjoy the support of many Web servers.

• Power— Servlets can access any of the Java APIs. For example, a servlet can use JDBC to access a data store, or access remote objects such as EJBs over RMI.

• Support— The Servlet API exposes a number of classes that greatly simplify many of the tasks a server-side programmer must perform. For example, the Servlet API provides direct access to response and request information (you do not have to explicitly parse request data), and it provides support for state management through a Session object and classes to manipulate cookies.

One of the greatest facets of the servlet is its ability to interact with other J2EE components. Servlets can interact with other servlets or EJBs in just the same way as a JSP. For example, Figure 2.6 shows a client calling a servlet and then that servlet accessing an EJB.

Figure 2.6 shows a user completing an HTML form and then initiating a HTTP POST to a servlet on a Web server. The Servlet Container on the Web Server invokes the servlet and passes it an object that represents the client's request. The servlet calls on the services of the EJB to perform the applications logic. Finally, the servlet generates an HTML response, which it returns to the client via a response object. In this instance, the servlet used an EJB, but it could also perform the processing itself or call another servlet or JavaBean.

Evaluation of Web-Centric Components

Now that you've been introduced to JSPs and servlets, you may wonder which component best suits a given scenario. In many instances, you can use JSPs and servlets interchangeably—remember that a servlet underlies a JSP. Both components dynamically create markup, operate on a request-response model, and can interact with other J2EE components.

However, Sun Microsystems provide guidance to help you develop applications using Web-centric components. This guidance takes the form of BluePrints that offer guidelines on the best practice and recommended use of J2EE technologies. The following guidelines derive from these BluePrints.

Generally, the presentation tier should use JSP pages that are presentation-centric, making them ideally suited to the generation of markup. In addition, JSP pages consist of XML tags, which are familiar to Web content providers. This familiarity allows content providers to easily maintain a site's content without altering code. Conversely, you should consider servlets as a programmatic tool that you don't modify frequently. There are two main instances when you should use servlet in preference to JSPs:

• Generating Binary Data— You should use servlets to output binary data, such as images.

• Extending Web Server Functionality— For example, you could use a servlet to do the filtering of mail for a mail service.

As a guide, you should use JSPs in preference to servlets unless you require one of the previously mentioned items of servlet functionality.

The Client Tier

J2EE supports a wide range of clients. These clients range from thin clients, such as a Web browser, to intelligent clients, such as mobile devices that run J2ME Midlets. Both of these clients communicate through HTTP, but other clients may use SOAP, sockets, or even CORBA. The factors that unite these disparate clients are that they all call and subsequently receive a response from J2EE middle tier components. This part of the day looks at a range of J2EE clients and focuses on which components interact with them.

HTTP Clients

Java technologies have a long history of providing a wide range of services to clients that communicate via HTTP. For example, is it possible that someone has never heard of applets? J2EE provides services to Web-based clients by using two components—JSPs and servlets. These technologies may not be as familiar to you as the applet. Previously, this chapter explained what these components are; now, it explains how they integrate with HTTP clients.

Static HTML Client

It's hard to imagine a Web application that relies on static HTML pages, but, believe it or not, some do. Typically, sites that use static pages are small and require very little functionality. The type of functionality they do require includes the processing of user response forms, basic e-commerce capabilities, and automated navigation. In a non-enterprise environment, a developer can use a CGI script to provide this functionality. With J2EE, you can use a servlet. For example, consider a customer feedback form written in HTML.

Figure 2.7 shows that the user completes the HTML Form and then initiates a HTTP POST to the servlet. The servlet parses the POST data; at this point, it could pass the data to another component. However, in this instance, it simply uses classes in the JavaMail API (see Day 11, “JavaMail”) to send the customer an e-mail response.

Dynamic HTML Client

Many Web applications use HTML pages, which they generate when they receive a client request. These dynamic pages typically contain information that is context sensitive. For example, the page may contain a simple time stamp, a banner advertisement, or information retrieved from a database. With J2EE, you can use a JSP to create dynamic HTML pages. Figure 2.8 shows how JSPs relate to a Web client.

The client makes a HTTP request for the page index.jsp. The JSP engine (on the server) interprets the tags within the JSP, calls the EJB, the EJB returns a response, and then the engine returns a page of HTML to the client. The functionality in this model is encapsulated in the EJB.

Java Applet Client

In case you do not know, an applet is a small GUI-based program that typically executes within the context of a Web browser. In the sphere of the Internet, a client requests an HTML page that references a server-side Java class file (the applet). The Web server responds to the client by returning this file. The applet then executes within the Java Virtual Machine (JVM) the client browser supplies.

In some respects, applets are an ideal way of providing remote access to J2EE applications. They are highly portable, run in an environment with strict security controls (the Java 1.0 Sandbox as a minimum), enjoy wide industry support (for example, Netscape and Internet Explorer browsers), and offer a rich GUI. However, browsers do not keep pace with changing specifications; so many browsers only support the deprecated Java 1.0 event model. This may cause you a number of problems, especially when working with AWT, which underwent a major change in its event model between Java 1.0 and Java 1.1. One of the best ways you can control the presentation tier is to deploy applets within a controlled network, such as a corporate intranet. In this instance, you can write code to work to the limitations of known browsers rather than working to the lowest common denominator.

Other HTTP Clients

The three previous clients are very desktop browser centric, but there are many other types of clients that communicate by using HTTP. These clients include mobile devices, such as cellular phones, smart phones, and PDAs. For example, Figure 2.9 shows a WAP device calling a JSP. The component-based architecture means that the only change is to the JSP because WAP devices don't display HTML. All of the logic in business tier remains unaffected.

You can also write an application that uses HTTP to communicate and still communicate with the Web-centric J2EE components.

Standalone Client

The HTTP clients all used a model that in essence was client—presentation tier— business tier—integration tier. However, there are other clients that may assume the responsibilities inherent in some of these tiers. For example, an application can connect to an EJB via its container, rather than route through a JSP in the presentation tier. Figure 2.10 shows such an example.

Figure 2.10 shows a standalone client accessing an EJB via its container. In this example, the client would typically be another EJB. Because the client accesses the business tier, it becomes responsible for the provision of the presentation tier. Consequently, in this example, the client EJB can pass the data to a servlet, which will then generate the appropriate response to its client.

Figure 2.11 shows another scenario where the standalone client bypasses both the presentation tier and business tier to access enterprise information system resources directly. Typically, the client uses JDBC to access the resources.

In this scenario, the client takes responsibility for the presentation tier and business tier. Interestingly, the client may not be another J2EE client: it might be a single application that encapsulates all presentation and business logic. If this is the case, the client will not gain the benefits of enterprise computing, especially scalability, because it is effectively working on the 2-tier client-server model.

Business to Business

The previous clients and scenarios worked on the premise of connecting to a component in a different tier—with the exception of the EJB to EJB example. However, many components do connect to components within the same level tier as themselves. For example, consider a small garage where mechanics order parts from a local catalogue via a hand-held device. Figure 2.12 shows the architecture for the system. As you can see, a JSP handles their orders by accessing a catalogue via JDBC. With each order for a part, the JSP decrements the count for that part. When the part count reaches zero (Just-in-Time stock management), the JSP connects to a JSP at the parts wholesaler and places an order for more parts.

The previous example showed two JSPs communicating, but this could just as easily be two servlets or two EJBs. Another interesting development in peer-to-peer communications such as these is the use of messaging. For instance, the previous example requires both JSPs to be available at the same time to complete an order. However, using the messaging facilities JMS provides, you may create a system where both JSPs can asynchronously send and receive orders. You can learn a little more about JMS later today and a lot more on Day 9, “Java Message Service.”

Non-Java Clients

It is possible to use non-Java clients to access J2EE applications and application components. One obvious solution is that non-Java clients can use HTTP to access the services offered by a servlet or JSP. This is particularly attractive when the servlet or JSP produces and consumes data-oriented information in XML rather than HTML. This could be done in the context of exposing the component as a Web Service, which is discussed in the next section of today's lesson.

In the case of an EJB, things are a little trickier. However, the RMI-IIOP protocol used to communicate with EJBs allows them to interoperate with clients written using the Common Object Request Broker (CORBA) standard. Hence, it is possible to expose an EJB as a CORBA server that can be used by CORBA clients written in C++ or even COBOL.

Another alternative is that EJBs can be accessed from a Microsoft COM client using the J2EE Client Access Services (CAS) COM Bridge or Table Bridge.

Web Services

Web Services are XML-based middleware components that applications access over HTTP and SOAP. They enjoy industry-wide support and are not a proprietary solution. In fact, because Web Services use XML and open communication standards, any client that can understand SOAP messages can consume Web Services. J2EE provides a rich framework that facilitates the building, deployment, and consumption of Web Services. You can learn more about J2EE and Web Services on Days 20 and 21.