Infrastructure Issues and Communicating with All Layers

Figure 10-2 shows the layered architecture that was introduced earlier in the book and then reintroduced in Chapter 9 in the context of databases. Again, these layers are logical and, in some cases, physical as well.

Remember that even though they are individual layers, many may run together on the same machine. At least one of them, Presentation Services, will be on the client in the form of a browser. Figure 10-3 focuses on the layers to be reviewed in this chapter, giving a more in-depth review of the roles that they will serve.

The Presentation Services Layer

The Presentation Services layer will be the most volatile layer in the entire application. The project must be able to take advantage of new technologies that arise. For instance, the client could just as easily be a cell phone or a PDA device. In addition, as time passes the project sponsors will want to see information in different ways that the project must be able to accommodate quickly and easily.

One way to facilitate the ever changing presentation requirements, and to provide a better design for extensibility, is to implement a model-view-controller (MVC) framework. MVC got its start in the SmallTalk world and has been used extensively in many commercial frameworks (Java's Swing architecture for one). Before we finalize the Remulak architecture, some discussion of terminology is in order.

• Model in the MVC framework is the entity class (e.g., Customer, Order). The goal of the model is to keep the framework pure, void of any user interface knowledge. The value classes introduced in Chapter 9 would be a proxy of sorts for the model layer.

• View in the MVC framework is the rendered interface that will be delivered to the client. The view can know about both the controller and the model. In the Remulak system the view is actually two things: the HTML form and the JavaServer Page (JSP).

• Controller in the MVC framework is the service that most often acts as the go-between for the model and the view. Two types of classes will implement the controller in the Remulak system. The first is the servlet. The servlet acts as the user interface controller, a router, that both instantiates and routes messages to the next type of class, the use-case controller. The use-case control classes were discussed in both Chapters 8 and 9. In the non-EJB solution, one JavaBean will play the role of use-case controller for every use-case. In the EJB solution, one session EJB will play the role of use-case controller for every use-case.

One benefit of letting the controller broker requests between the view (screen) and the model (entity class) is that it keeps the user interface light. Although there is nothing to prevent the user interface from calling into the entity classes to retrieve information, by keeping the HTML forms relatively uninformed, we end up with service layers that are highly cohesive and less coupled to other service layers. In addition, as the presentation technology changes over time, the ability to snap off one in favor of another becomes much easier. Today the Web is popular, but we hear more and more about the need to interface wireless clients into applications. Following a sound layering strategy allows the designers to snap on a new front end with little or no change to the business rules packaged in the EJB application server.

Figure 10-4 is a representation of the MVC pattern for the Web client that handles relationship management. It closely resembles Figures 8-7 and 8-8, except that now we have added actual class names. This component diagram shows the components that implement a pathway through the Maintain Relationships use-case.

The dependency relationship between RemulakServlet and the rltnInquiry JSP is on the return trip back to the browser. Note that with a well-designed MVC architecture, simply changing the outbound JSP page to something else, perhaps one that returns Wireless Markup Language (WML) bound for a wireless PDA, would require absolutely no changes to the controller or the model components. They are none the wiser. Their role is simply to return a display-neutral object representing the customer. It is the role of the view to transform that object into something desired by the user.

Notice that there are two types of controllers in our architecture: a user interface controller and a use-case controller. The user interface controller is responsible for dealing with unique interface architecture (e.g., Web, wireless, voice response unit). The use-case controller is responsible for implementing the pathways defined in the use-cases and eventually modeled by sequence diagrams. The use-case controller doesn't care who requests its services or what technology ultimately delivers it.

A key component of the architecture used for Remulak is that there is a one-to-one mapping between a use-case and a use-case control class. Think of a use-case controller as a traffic cop of sorts, a facilitator for the sequence diagrams, which are realizations of the use-cases created. Every use-case will have a unique session bean.

There is also a one-to-one mapping of pathways (happy and alternate) in a use-case to operations in its related JavaBean or EJB session bean. Exception pathways are usually handled in the course of the happy or alternate pathway. This relationship should further reinforce the importance of traceability that was introduced at the beginning of this book. Too often there is no way to trace back from code to the requirement that brought us to a particular point in the project. With this design pattern we have such traceability.

Figure 10-5 provides a context for how we go from a use-case all the way to the JavaBean or EJB session bean that realizes that use-case's pathways. In this diagram we show the use-case controller as a session EJB; in the non-EJB solution, however, our design will implement controllers as just JavaBeans.

As Figure 10-5 shows, there is an order to the progression of mapping to components: (1) From use-cases we find our domain classes (2). (3) From the use-cases we create dynamic models (e.g., sequence/ collaboration) that model our classes now acting as living objects sending messages to one another with the sole purpose of accomplishing the goal of the use-case pathway. (4) For each use-case, a use-case controller will be implemented as either a JavaBean (non-EJB) or a session bean (EJB). This use-case controller bean will contain operations (5) that implement the orchestration logic to carry out an individual sequence diagram. Again, these map directly to the use-case pathways.

The Business Context Services Layer

The Business Context Services layer of the application works very closely with the specific presentation technology. It is responsible for much of the editing that transpires during the user interface interaction. Some of these logical services are split between the actual form-level code (packaged in either HTML or JavaScript) and the business rule component (classes implemented as either JavaBeans or EJBs).

This logical layer focuses on what is happening during a given interaction between the system and the application and in particular on syn tax and context edits. These various edits perform as follows for the application:

• Syntax edits focus on formatting and cleansing information before it ever leaves the user interface. These edits can range from numeric range checks to valid date formatting.

• Context edits focus more on the business aspect of the information. For instance, if someone selects a payment type of finance and has a credit score below 50, approval by a finance officer is required for a sale. Quite often what is a context-type edit should be an operation in one of the entity classes.

Some would argue that we should not have any type of syntax or context editing going on in the form-level code. The reason is that these types of edits would apply whether the user interface was a Java application or a Web-based front end. Some designs actually package the edits as a single method inside of the user interface control class and pass all the screen information to the edit operation to perform the edit. This would allow some level of reusability if the front end changed to a Web-based solution. However, depending on the technology selected for a Web-based front end, something as simple as preventing the entry of a field on the basis of the value entered in another field (context edit) may require a trip all the way back to the Web server for editing. This is clearly a case where purity and performance will butt heads.

The Business Rule Services Layer

Because the industry overuses the term business rule, let's clarify how we will use it. What really resides in the Business Rule Services layer? We have used the term entity class quite a bit in this book, and this layer is where those classes will live. Initially, the implementation constructs of each will mirror the attributes defined in the class diagram. There will also be get and set operations for each attribute because all attributes will be declared as private. The same is true for the rules to be considered a bean. Each entity class will provide certain services, such as a way to request the retrieval of information about itself for eventual use by a particular aspect of the system. The classes will also have to be able to respond to update requests, thereby resulting in some form of persistence.

The logical layer of Business Rule Services actually has a dual spirit. The business rules physically implemented in an entity class are very workflow oriented. Other business rule services deal with the business aspect of data management, which will be implemented in what we referred to in the previous chapter as data access objects (DAOs).

Cooperating Classes: Boundary, Control, and Entity

Let's now map a simple interaction, the retrieval of customer information via the Maintain Relationships use-case, into the layers of the application. This exchange of messages will be initially mapped out at a high level and then will become much more concrete (as to full operation signatures) as you move through your design. Figure 10-6 outlines the UML sequence diagram depicting the interaction.

Let's walk through the messaging. I have placed sequence numbers on the diagram for readability; as stated in Chapter 7, however, they are unnecessary for sequence diagrams because the order flows from top to bottom. I have also left a few classes off of the diagram but will explain where they would be placed in reality.

This interaction is very typical of all the interactions on which Remulak Productions' system will be based. It is a framework that can be applied time and time again.