4.5. Application Architecture

The architecture for the Homside Lending application consisted of four tiers: client, Webserver, application server, and database.

4.5.1. Client Tier

The Web client uses a standard browser with HTML to make it as accessible and efficient as possible.

4.5.2. Web-Server Tier

A proxy server, which currently runs on a four-processor, HP L-class midrange UNIX server, caches the static home page and some graphics to deliver fast response, as well as to provide an additional layer of security in front of the Web server. All other Web pages that are served are generated through the use of JSPs that are deployed by the Web server.

Performance was a key design criterion. Therefore, with the exception of the home page (which is cached), most pages carry relatively simple graphics to minimize download times. Future plans call for redeploying the Web server on a cluster of smaller HP A-class servers.

The Web tier handles data presentation and validation. It also contains a servlet that manages the JSP pages that are displayed as the consumer moves from page to page on the Web site.

4.5.3. Application-Server Tier

BEA WebLogic Server is deployed on a 14-processor HP V-class server, which accesses a dedicated EMC storage array. In addition, there is an HP T600 server configured as a failover box using the HP high availability product, MC ServiceGuard. (Currently, the database and existing back-office application also run on the same servers. In the future, HomeSide plans to redeploy the Web application on a separate array of servers.)

The application-server tier provides a service layer for the Web-server tier. These services invoke the back-end processing, where the real mortgage processing work is performed. On this tier, the functions of the mortgage application process are handled, including user authentication, all database interaction via JDBC, along with interaction with the underwriting system, powered by Fannie Mae technology.

The application tier divides labors as follows.

• A service layer is provided to the Web tier, which encompasses the ability to order credit reports, underwriting, data persistence, closing cost calculations, and credit card charging. Additional services provide the data that is used to fill in the drop-downs on the data-entry forms on the Web tier.

• The underwriting system makes the loan acceptance decisions.

Currently deployed on the same server as the existing application and database, future plans call for migrating the Java application to its own clustered servers.

4.5.4. Database Tier

The back end includes the twin foundation components: the existing mortgage-loan approval system, which serves as the core business logic, and the Oracle database.

4.5.5. Data Integration

Session beans coordinate the actions of entity beans for all interactions with the back-end Oracle database. These session beans provide a service layer that the Web-server tier uses for all interactions with the database, the underwriting system, and the “legacy” rules-based decision-making applications.

To promote ease of use, the application provides several options for customers to save their data and continue their sessions at a more convenient time. For instance, at several critical points during the data entry process, the Web server calls a service on the application server, requesting that it persist the data the user has entered to that point. By doing this, the customer does not have to reenter data should the browser or Internet connection fail. In addition, the customer has the ability to click a Save and Continue Later button. This option allows the customer to save his or her data at that point and log out. The customer is then free either to return to the Web site at a later time and complete the loan application, or, phone the call center and continue the loan process with the assistance of a loan officer.

All communications initiated by the Web tier involve the creation of Java serializable objects. These objects are used as parameters to the back-end service tier when one of the services is invoked. When responding to the request, the application tier sends back the appropriate information either in the form of a Java serializable object or an XML document. XML documents passed between the Web and application tiers are considerably different in both form and content from XML documents passed between the application server and the underwriting system. These documents have considerable “value added,” provided by other application-tier services, and as such cannot be simply translated using a technology such as XSLT.

The services that communicate with the underwriting system retrieve data either from objects written in the Java language which are passed to them or from the previously persisted data in the database. Using the Apache Xerces XML API, HomeSide builds the XML documents to be transmitted for underwriting. The Document Object Model (DOM) Level 1 API is used for constructing the XML documents sent to underwriting. However when parsing the XML documents, because of their size (sometimes as much as 70K), the Simple API for XML or SAX, version 1.0, is used for parsing the data into compound Java objects. This approach proves more efficient than using DOM for parsing and allows the data to be “grouped” into vectors of objects that can be easily persisted or sent to other services for additional processing. Similarly, XML is also used for other business-to-business transactions, such as getting credit card authorizations for customers paying the standard mortgage application fee.

Based on the underwriting decision, the HomeSide system generates the response—whether the customer can get a mortgage, and under what terms. In most cases, customers may qualify for a choice of mortgage options, with varying terms, rates, and documentation requirements. In many cases, customers may qualify for several dozen options.

Each of the rate and point combinations that underwriting supports for that customer must be augmented with HomeSide's pricing adjustments. These adjustments are made with the assistance of the Art*Enterprise rule engines originally developed for HomeSide's previous origination system.

Once these adjustments are made, the data is converted for a final time into an XML document that is sent back to the Web-server tier to display to the consumer. The Web-tier servlet extracts the relevant data from the XML document using DOM. It then displays to the customer a table of the most attractive loan options, based on the criteria they defined when the request was submitted. If the consumer qualifies, additional loan options may be viewed by clicking buttons that lead to more pages with tables of other loan options.

Consumers are never rejected on the Web site. Should the consumer not meet established underwriting guidelines, they are presented with a page that refers them to HomeSide's call center. Here an experienced loan officer may be able to identify alternative loan solutions to meet the customers' needs.