Model Plain Java & EJB in Java

Paint ECC200 in Java Model Plain Java & EJB

View JSP & Plain Java (View Helpers)

Figure 3.5 Model-view-controller simplifies interfaces by delegating the responsibility for business logic, user interface, and data marshaling to different components. Each view queries the model independently, and all updates to the model go through the controller, yielding an application that s easier to build and maintain.

Of course, modern restaurants funnel orders and complaints to the kitchen through a waiter. A Session Fa ade fills that role for us, providing a thin (hence fa ade), coarse-grained layer over your fine-grained, in-process classes. You use Session Fa ades primarily for remote invocations; they are a kind of gateway or adaptor from remote clients to the fine-grained local methods. Going back to our trip booking service example, take the client in figure 3.6 that accesses trip booking information. It s not practical for a remote client to request each field of a Booking instance individually, making multiple round trips to the server. Alternatively, the client accesses a method in the Session Fa ade and completes its work in a single trip. Such methods are typically referred to as bulk accessors. Likewise, methods that group data modifications are referred to as bulk mutators. Session Fa ade interfaces should be grouped to reflect use cases that are similar to one another. As the implementation for the fa ade method is typically simple, catering to many use cases in a single fa ade implementation is not usually a maintainability issue. However, having too many Session Fa ades does create questions about maintenance. If you have too many fa ades, the client will spend too much time and effort dealing with lookups and home interfaces. In general, your application should have few fa ades. One is often sufficient. Don t treat this rule as an absolute. Your fa ades are simply stateless libraries, and you (the library developer) and your customers (the library clients) need to be able to navigate and organize them efficiently. Just understand that each fa ade has associated overhead, and plan them wisely.

getBookingData()

getDate() getUser()

getAttendees()

Figure 3.6 This customer gets booking data through the booking agent. The booking agent serves as a Session Fa ade. The fa ade tends to implement individual use cases, and serves as the point of access to the objects in the model. From an interface standpoint, it simplifies our implementation, and isolates the client from the business model.

The methods in a Session Fa ade should not contain domain logic. This includes data validation. Such logic should be incorporated into the domain layer where it can be reused. As with all object-oriented development, you should try to separate and encapsulate concerns. Separation of concerns is one of the philosophies that drove development of JSP. A designer can create JSP in a scripting language with little support from a dedicated programmer. In our case, we want to separate and encapsulate all logic pertaining to remote access in the Session Fa ade implementation and no more. I typically implement the Session Fa ade using a stateless session bean. If we find ourselves needing to maintain some client-specific state, we usually try our damnedest to refactor some logic to the client side and simply pass the state back to the server each time. As it can get monotonous passing the same data to the server over and over with each method call, we like to abstract out these state arguments as part of a Business Delegate, a design pattern we ll discuss shortly. Choosing a stateless over a stateful implementation is more about scalability than performance. Passing the state back and forth may have overhead, but storing state in the server has substantially finite limitations. First, you have memory. For thousands of concurrent users, the server must maintain thousands of instances of the state information until the user explicitly leaves or their session times out in which case the server automatically destroys the state (in our case a stateful session bean instance). Second, you have failover. If you want to support failover with stateful session beans, the server has to replicate the state to a backup server. In this case the stateful session bean instance must be serialized and transferred to another server at the end of each invocation. The client might as well provide the state itself each time, especially if the client is on the same network as the cluster. With a stateless session bean, the client holds on to the state information and can simply fail over to any other machine in the cluster.