Using a Faade Pattern to Hide EJB

Using Servlets and Java Server Pages with EJB

Two of the technologies that are included with the J2EE suite are Java servlets and Java Server Pages (JSP). Although you can program your presentation tier with just about any technology that you want, these two are very complementary to EJB ”complementary in the sense that both are component technologies, both use the Java language, both can communicate using the RMI protocol, and both share the same specifications for low-level services such as security.

JSPs and servlets are arguably the most common technology being used as the presentation tier solution when using EJB in the application tier. As we stated earlier, there are many other technologies that you can use, including Active Server Pages (ASP) from Microsoft, applets, a Swing GUI, and many other languages. If you wanted to, you could create a Visual Basic application that used COM objects to interact with the proxy object from Listing 19.2. The possibilities are unlimited, and many development organizations have had a certain amount of success with these and many more types of presentation tier technologies.

Obviously, we can't cover JSPs and servlets in any depth within this book.

Note

If you are not familiar with JSPs and servlets, you can pick up the book Special Edition Using Java Server Pages and Servlets by Mark Wutka, published by Que.

If you are going to be using JSPs and servlets as your presentation tier solution, you need to take the time to understand how best to separate the actual presentation of the HTML data from the acquisition and processing of that data. We'll provide a brief description of one of the more popular ways of separating these functions by using a well-known pattern called Model-View-Controller (MVC).

You might also hear JSP and servlet developers talking about this presentation design as a Model 2 approach. The early JSP specifications referred to a Model 1 and a Model 2 design. The two types differed in where the bulk of processing took place. With Model 1, all the request processing took place directly inside the JSP pages. Model 2 was a hybrid approach that used servlets to process the requests and JSP pages to display the presentation.

Although many developers don't refer to Model 1 and Model 2 much anymore, some still use these terms to describe the overall design approach.

The Model-View-Controller Pattern

One thing you should understand is that the MVC pattern can mean many different things to many different developers. In some ways, the pattern is incorrectly used. The pattern is really made up of several other smaller patterns.

The approach to the MVC pattern in this chapter is more of a conceptual one than an actual pattern definition. When the MVC pattern is related to JSPs and servlets, it's really just talking about separating the presentation tier into three distinct areas: the model (JavaBeans or data returned from the application tier), view (JSP pages used just for displaying the HTML and dynamic output), and the controller (which normally is a servlet and a set of helper classes).

The first part is the model. If we were talking about a two-tier application, the model would be the business objects that represent the domain for the application. However, because we are dealing with a remote model, we need some way of representing the model or a portion of that model on the presentation tier. As Chapter 17, "Addressing Performance," points out, accessing entity beans from a remote client can be a performance problem and should be avoided by always going through session beans to achieve a larger granularity.

One of the most common approaches to creating a model for the presentation tier is to allow the session beans to return very simple view objects back to the presentation tier from a remote method call. These view objects are just simple JavaBeans or regular Java classes with attributes and no real business logic. The presentation tier uses these view objects to get the data that will be used to display dynamically in the JSP pages along with the static HTML. Listing 19.3 shows an example of a BidView class that is built and returned by a session bean. This view represents a piece of the model for a user 's auction bid.

Listing 19.3 The BidView Class Used by the Presentation Tier

 package com.que.ejb20.auction.view;  /**   * Title:        BidView<p>   * Description:  Value object for an auction bid<p>   */  import java.io.Serializable;  import java.sql.Timestamp;  public class BidView implements Serializable {   private Integer auctionId;    private Integer bidderId;    private Timestamp dateTimeSubmitted;    private String transactionId;    private Double amount;    public BidView(Integer newAuctionId, Integer newBidderId,     Timestamp newDateTimeSubmitted, Double newAmount, String newTransactionId){     setAuctionId(newAuctionId);      setBidderId(newBidderId);      setDateTimeSubmitted(newDateTimeSubmitted);      setAmount(newAmount);      setTransactionId(newTransactionId);    }    public Integer getAuctionId() {     return auctionId;    }    public void setAuctionId(Integer newAuctionId) {     auctionId = newAuctionId;    }    public Integer getBidderId() {     return bidderId;    }    public void setBidderId(Integer newBidderId) {     bidderId = newBidderId;    }    public Timestamp getDateTimeSubmitted() {     return dateTimeSubmitted;    }    public void setDateTimeSubmitted(Timestamp newDateTimeSubmitted) {     dateTimeSubmitted = newDateTimeSubmitted;    }    public Double getAmount() {     return amount;    }    public void setAmount(Double newAmount) {     amount = newAmount;    }    public String getTransactionId() {     return transactionId;    }    public void setTransactionId(String newTransactionId) {     transactionId = newTransactionId;    }  } 

The BidView class in Listing 19.3 implements the Serializable interface so that it can be sent across the network to the presentation tier. It's also possible that the view classes can be used in both directions; that is, the presentation tier might create an instance of a BidView to send to the EJB application when a user submits a new bid. In that case, one or more attributes might not be used for both directions. The session bean can get only the attributes in which it's interested. By reusing the same view class rather than creating a brand new one, you can save on the number of classes that have to be designed.

The view part of our MVC discussion is the dynamic output displayed to the user. In the case of our discussion here, it's the HTML pages that are eventually displayed in the browser. Before the user can see these HTML pages, however, the Web server and servlet engine will need to generate them using some combination of style sheets, JSP templates, JSP tag libraries, and static HTML. Although you probably would find many JSP developers and applications that are using business logic in the JSP pages, you should really try to avoid this. You should strive to keep the presentation tier thin and keep the business logic as far back toward the application tier as possible. It's typical to have presentation logic that needs to go in the JSP pages, but this logic deals exclusively with how the output is being displayed to the user. Listing 19.4 shows an extremely basic JSP page that uses the BidView class from Listing 19.3 to display the bid data for an auction.

Listing 19.4 The JSP Page That Displays a Single Bid for a User

 <html>  <head>  <title>Auction Bid View</title>  </head>  <body bgcolor="#FFFFFF" text="#000000">  <jsp:useBean id="bidView"  class="com.que.ejb20.auction.view.BidView" scope="request"/>  Bidder Id: <jsp:getProperty name="bidView" property="bidderId"/>  Auction Id: <jsp:getProperty name="bidView" property="auctionId"/>  Transaction Id: <jsp:getProperty name="bidView" property="transactionId"/>  Bid Amount: <jsp:getProperty name="bidView" property="amount"/>  Date/Time: <jsp:getProperty name="bidView" property="dateTimeSubmitted"/>  </body>  </html> 

Listing 19.4 is not meant to do anything significant, but it should show you how the model can be used inside the JSP page. One thing to remember is that there should be very little logic inside the model or view at the presentation layer. If there is any logic, it should be strictly presentation related.

Caution

You must be careful when using a view class that doesn't have an empty constructor. If the JSP page can't find an instance of the class specified in the useBean tag, it will attempt to create an instance. If there isn't a default constructor that takes no arguments, it will cause an error.

The final piece to our conceptual MVC approach is the controller piece. The controller in our approach is responsible for receiving a request from the end user, calling some business logic back to the application tier, getting some data back in the form of one or more view instances, and then deciding which page should be displayed to the user. One common way to build the controller functionality is to have a single servlet, sometimes referred to as a "command" or "controller" servlet, receive a "command" from the user and process the command. The command normally is just a string that has some inherit meaning to the command servlet.

The command could be something like viewAuctions , submitBid , or viewBid . The command servlet typically has a set of mappings that maps a command name to an action that can be carried out. For example, a viewBid command might cause the controller, or possibly another class on behalf of the controller, to call the auction proxy class from Listing 19.2 to request a particular BidView object. The result of this command is then sent on to display some output to the user in the form of an auction bid page or some error page, if the operation fails.

With some designs, the controller servlet might decide which JSP page to call next based on the result of the call to the server. A better approach is to allow some type of workflow engine to determine which page to call next . It might do this by taking into account many different pieces of information, such as who the user is, which page the user is currently at, and what the result of the action was.

The main point to understand here is that the logic of what to do next should not be contained within the JSP page; it's within the controller servlet or some delegate working for it. Figure 19.3 shows a simplified version of how the MVC might work in a typical JSP/Servlet application.

Figure 19.3. A simplified version of a presentation tier architecture using the MVC conceptual pattern.