3.6 Designing for Multiple Types of Client
3.6.3 Controller
A controller defines application behavior; it interprets user gestures and maps them into actions to be performed by the model. Each client that exposes different functionality requires a separate controller. For example, the sample application would need separate controllers for shopping and administration clients. There is always some opportunity to reuse code that is part of the application controller framework; however, this is independent of the type of clients accessing the applica- tion.
However, multiple clients that expose similar or identical functionality should be able to share the controller responsible for the functionality. If the clients provide only slightly different functionality, it should still be possible to reuse the controller implementation by using a single class to implement the common behavior and using subclasses to implement the custom behavior. For example, the banking application described earlier has a Web-based interface as well as a
stand-alone desktop client. The difference between the clients is how they present the interface—the view. Therefore they can share the same controller.
Because the controller interacts directly with the view it is not completely insulated from changes in the view implementation. For example, strongly typed references to view objects in the controller make it difficult to redeploy. In order to design the controller to allow a large portion of its implementation to be shared, we need to examine the interactions between the view and the controller and find ways to minimize the effect of those interactions on the controller. The interac- tions are:
• Interpreting user gestures generated through the view • Selecting the view
3.6.3.1 Interpreting User Gestures
The controller accepts user gestures from the view. These depend on the medium that the view uses to present the user interface. For example, in a JFC application, the user gestures could be “button pressed” events or “mouse moved” events, and so on. In a Web interface, the user gestures appear asGETorPOSTrequests for URLs of the application. In a messaging environment, the user gestures take the form of asynchronous messages.
To keep the controller as reusable as possible, the controller must translate these user gestures as soon as possible and turn them into business events—uni- form, view-neutral representations of the actions requested by the user.
The sample application uses RequestToEventTranslator for this purpose. This object takes an HttpServletRequest from the view—a browser in this case—and translates it into an EStoreEvent business event. RequestToEvent- Translatoris discussed in Section 10.6.3 on page 285. The rest of the controller implementation deals only with EStoreEvent and can be reused for different implementations of the view. If we wanted to implement a JFC-based client for the sample application, we could just add another translator that translates JFC events into business events.
Code Example 3.1 shows how RequestToEventTranslator takes a request and translates it into a business event. An object that implements ShoppingCli- entControllerInterface, which provides the core of the controller responsibili- ties, invoked using an EStoreEvent, does not need to change when the client changes.
DESIGNING FOR MULTIPLE TYPES OF CLIENT 71
public class RequestProcessor {
ShoppingClientControllerInterface scc; RequestToEventTranslator eventTranslator;
public void processRequest(HttpServletRequest req) { ...
// translate view specific event into EStoreEvent
EStoreEvent event = eventTranslator.processRequest(req);
if (event != null) {
// invoke the controller with EStoreEvent, instead of // using the view specific HttpServletRequest
Collection updatedModelList = scc.handleEvent(event); mm.notifyListeners(updatedModelList);
} ... } }
Code Example 3.1 Translating View-Dependent Gestures into View-Neutral Business Events
3.6.3.2 Selecting the View
The controller selects which view to display. These depend on the medium that the view uses to present the user interface. For example, in a JFC application, the user views are composed of Swing components such as panels, lists, tables, and so on. In a Web interface, the views are HTML pages that are rendered by a browser.
To keep the controller as reusable as possible the controller needs to express views in a technology-neutral fashion and translate them to technology-specific ren- ditions as late as possible. This would require a layered view selection component that uses objects to represent views (analogous to the business events in the previous section) which are forwarded to specific types of view generators. For example, a product list view would contain all the data needed to represent a list of products. This object could be passed to a view generator, which would render the data in a specific user interface medium. Note that depending on the medium, the view gener- ator may reside on the server (HTML) or on the client (JFC).
3.6.3.3 Example: The Sample Application Controller
The sample applications controller is in two parts: the EJB controller, which inter- acts with enterprise beans and a controller proxy, which interacts with views. In the current release, the proxy is monolithic and specific to Web clients.
If another type of shopping client interface were required, the EJB controller could be shared without modification. However, the proxy portion of the control- ler would have to be rearchitected to support more than one type of view technol- ogy. For example, a JFC-based view selection component would need to register event listeners when the view is created. These listeners would then post or propa- gate the events to the client portion of the controller.
3.7
Summary
This chapter has discussed various types of J2EE clients, as illustrated in Figure 3.1.
Figure 3.1 Client Options
In general, J2EE applications should use Web clients when possible. With the help of technologies such as DHTML and JavaScript, Web browsers can support reasonably powerful and fast user interfaces. Additional capabilities can be pro- vided by using applets. Java applets can be used in conjunction with the browser using HTML or XML over HTTP for additional enhancements. A Java applet can also communicate with the middle tier for further control and flexibility. The Web
SUMMARY 73
browser is a truly universal Web client, so for simple user interfaces, and for Inter- net applications, it is the client of choice.
Application clients should be used when the data model is complex and cannot be expressed through the Web interaction model. Application clients are well-suited for intranet enterprise distribution. They can provide a richer user experience and blend well with the desktop windowing environment. However due to the increased complexity of such clients, there are reasons to avoid them in favor of Web-based applications. What’s more, ongoing enhancements to the Web client speed and functionality will continue to erode the need to deploy stand- alone clients for all but a handful of cases.
The use of application clients on the open Internet is not straightforward because of distribution, deployment, security, and firewall issues. These clients are best suited for the intranets, where they can provide a more featureful user inter- face to the user and provide integrated security. Implementation of stand-alone clients requires more effort.
Special purpose application clients can be used for administrative and man- agement tasks. These clients are not intended to be distributed to every user, and often have a minimal user interface. They perform specific tasks, perhaps invoked automatically by the system, through means external to the J2EE specification.
Use of enterprise information system clients should be limited to simple, well-understood management or administrative tasks.
The Java programming language is preferred for stand-alone clients, although similar capabilities may be possible with languages other than Java.
G
REG MURRAYis an engineer in the J2EE programming model team at Sun Micro- systems. He assisted in the design and implemented much of the Web tier of the portions of Java Pet Store sample application. Prior to joining the J2EE programming model team Greg was a member of Global Products Engineering at Sun. Greg graduated with a B.A. in International Relations with a minor in Japanese from Brigham Young University.75
C H A P T E R
4
The Web Tier
by Greg Murray
U
SERS have benefited significantly from the increasing ability of Web-based applications to generate dynamic content customized to their needs. JavaServer Pages (JSP) and servlets are J2EE technologies that support dynamic content gener- ation in a portable, cross-platform manner. Web-based J2EE applications that use these technologies can be architected in a number of ways. Simple Web-based J2EE applications can use basic JSP pages and servlets or JSP pages with modular com- ponents. More complex transactional J2EE applications use JSP pages and modular components in conjunction with enterprise beans.This chapter begins with a description of Web applications and Web contain- ers. It discusses the use of the Common Gateway Interface, servlets, and JSP tech- nology for providing dynamic and interactive content. It describes what situations require the use of servlets and when to use JSP technology and how to design the interface of a Web-based application with internationalization and localization in mind. Review of various design patterns for Web application will follow. Finally we will discuss migration strategies from Web-centric to EJB-centric applications.