Design

The FBS was designed to demonstrate the J2EE and EJB 2.0 features presented in this tutorial series. To do so, OTN developers implemented several J2EE design patterns, including:

• Model-View-Controller
• Session Façade
• Page-by-Page Iterator
• Data Access Object

A software design pattern describes an approach to solving a recurring programming problem or performing a task. These design patterns can improve the performance of J2EE applications over the Internet or an intranet, and make them more flexible and easier to maintain.

Model-View-Controller

The Model-View-Controller (MVC) design pattern describes an approach to an application as a whole. The approach is multi-tiered and modular; it defines a clear separation of application logic, presentation details, business rules and data. As a result, multiple clients, displays, and devices can use the same application and business rules to work with the same data.

The MVC design pattern identifies three entities, each operating in a different logical layer within the application space:

• Model: A back-end representation of enterprise data and business logic, the model also maintains data about the state of the application. In many cases, the model is a logical representation of a real-world process.

• View: The front-end presentation layer that renders the model for end-users. Views also provide user interfaces for accessing the enterprise data represented by the model.

• Controller: The middle tier of the MVC pattern. The controller defines application behavior, selecting views for presentation and capturing a user's interactions with views and routing them as commands to the model.

The following figure shows how model, view, and controller interact.

• The model is implemented by EJBs and other Java classes, many of which represent real-world objects such as customers, stock portfolios, and trades.

• The views are provided by JavaServer Pages (JSPs) rendered in a browser.

• The central controller in the FBS is implemented in ControllerServlet.java. When an end-user interacts with a view (for example, by submitting a form), this HTTP servlet dispatches the action to a sub-controller object which in turn invoke methods on objects in the model.

This is the general design used in the entire application. Following are some details.

• Model: This layer represents the application's business logic, which is distributed among the following functional areas:

  • User Management, implemented using EJBs and Java classes. The source code resides in the ibfbs\src\oracle\otnsamples\ibfbs\usermanagement directory.

• Trade Management, implemented using EJBs and Java classes. The source code resides in the ibfbs\src\oracle\otnsamples\ibfbs\trademanagement directory.

• Administration Functionality, implemented using Session Beans, Message-Driven Beans, Java classes, and Data Access Objects. The source code resides in the ibfbs\src\oracle\otnsamples\ibfbs\admin directory.

• View: The FBS supports PC-based browsers and mobile devices. JSP View pages for browser-based clients reside at ibfbs\src\public_html\jsps\*.jsp. JSP View pages for mobile device clients reside at ibfbs\src\public_html\mobile\*.jsps.

• Controller: ControllerServlet and associated Java files reside in the ibfbs\src\oracle\otnsamples\ibfbs\control directory. Every user action generates an event which may in turn invoke a method in a business class. After the method executes, results may be displayed in a particular view. The relationship between events, methods, classes, and views is defined in the Control.xml file in the \ibfbs\src\public_html\xml directory. Consider a single entry:

  <Event>
    <Name>PROFILECHANGE</Name>
    <Class>oracle.otnsamples.ibfbs.usermanagement.helper.UserManagementHelper</Class>
  
    <Method>updateProfile</Method>
    <Screen>jsps/MyHome.jsp</Screen>
    <Roles>
      <Role>USER</Role>
    </Roles> 
   </Event>

This signifies that the event PROFILECHANGE triggers the method updateProfile in the UserManagementHelper class, and results are displayed using MyHome.jsp. The class RequestProcessor.java helps invoke the method updateProfile in UserManagementHelper class using the Java Reflection API.

Session Façade

The Session Façade design pattern is useful in situations where client objects need to interact with a set of EJBs to perform tasks in a workflow. For example, in the FBS environment, customers submit orders to buy and sell stocks, the orders are verified and executed, and results are returned. In an implementation where client objects interact directly with the underlying EJBs, the following problems can arise:

• When an EJB's interface changes, client objects must also be updated. This situation is analogous to the brittle class problem common in object-oriented programming.
• To carry out a workflow, client objects must make numerous remote calls to access the EJBs, leading to increased network traffic and reduced performance.

A session façade solves such problems by presenting client objects with a unified interface to the underlying EJBs. Client objects interact only with the façade, which resides on the server and invokes the appropriate EJB methods. As a result, dependencies and communication between clients and EJBs is reduced. A session façade can also simplify transaction management: for example, when a database transaction involves multiple method calls, all could be wrapped in one method of the façade and the transaction could be monitored at that level.

The following figures show this client-EJB interaction with and without the session façade, and how the session façade reduces network traffic.

Without Session Façade	With Session Façade

Files that implement the Session Façade for the FBS reside in the directory ibfbs\src\oracle\otnsamples\ibfbs\usermanagement and ibfbs\src\oracle\otnsamples\ibfbs\trademanagement.

Page-by-Page Iterator

The Page-by-Page Iterator design pattern describes how to break a huge list of values into smaller pages and display the results one page at a time. In the FBS, each user account is associated with many trade details and portfolio records. Fetching all the data at once can be inefficient: it can take a long time, increase net work traffic, and the user may only want to see a record or two. The FBS lets users specify a number of records per page, and then only fetches pages on demand.

This design pattern is implemented in PageByPage.java and TradeManagementSessionFacadeBean.java in the ibfbs\src\oracle\otnsamples\ibfbs\trademanagement directory.

Data Access Object

The Data Access Object (DAO) design pattern defines a way to isolate and abstract the details of connecting to and interacting with a data source, enabling developers to keep such code separate from business logic, and making it easy to change data sources without changing code. For example, the FBS uses DAOs and can switch between a relational database, where data is in relational tables, and an XML-enabled database (XML DB), where financial news is stored as XMLType in the database.

The Connection.properties file in ibfbs\etc has parameters that determine which DAO is used to fetch news and stock prices. The DAO pattern is implemented in ibfbs\src\oracle\otnsamples\ibfbs\usermanagement\dao\*.java and ibfbs\src\oracle\otnsamples\ibfbs\trademanagement\dao\*.java.

Other apects of the FBS design are covered in various lessons in this tutorial series.