4.3. Technology Choices

Developing the HomeSide application involved selecting the appropriate technologies for their specific functionality and benefits.

4.3.1. Java Technology

Industry standards played a central role in HomeSide's decision to design the new application using a J2EE architecture. “We could have taken a more modest approach by simply writing HyperText Markup Language clients with Common Gateway Interface scripts,” Reed says. “We saw this as one of our targeted growth businesses for the company. So we decided to design around an industry-standard platform that was stable and forward-looking.”

Therefore, HomeSide chose to develop its new online mortgage application based on the J2EE platform. “Java technology had a lot of momentum going for it in the e-commerce arena,” says Reed. “The J2EE platform was based on proven technology, and it was gaining critical mass adoption. We saw it becoming an industry standard.”

Most important, the emerging J2EE platform standard provided a framework of services, which eliminated the burden of custom development. For instance, the J2EE platform provided ready-made alternatives to the custom, point-to-point socket interfaces that HomeSide had written in its earlier client–server application. With the new application, HomeSide wanted to redirect its development efforts to business functionality rather than infrastructure. “We don't want to be in the business of writing interfaces, component structures, or transaction management. With the J2EE platform, we can focus our efforts where they deliver the best value,” says Brian Higdon, the system architect and a consultant with Enterprise Logic.

4.3.2. XML

XML transactions are used to make the entire application transparent. They encompass many internal interactions, such as checking the rules base to retrieve legal requirements and applicable fee structures that are valid for the state in which the transaction is taking place. XML is also used for all business-to-business transactions in the system, such as interactions with the loan investors or with credit card issuers (for payment of mortgage application fees). HomeSide used the Xerces Project parser for all XML document processing and made use of both the DOM and SAX APIs.

The HomeSide Web application interacted with third-party proprietary underwriting technology using numerous XML transactions. HomeSide worked to define the document type definition (DTD) used by all of the XML documents.

For instance, loan processing includes the following XML transactions.

• Pull-Indicative-Rates Request. This transaction returns current or historical pricing information. The data can be thought of as the “wholesale” pricing that is provided. HomeSide adds its fees to this data to come up with the final rates it offers to the general public.

• Casefile ID Request. This transaction gathers a group of “casefile IDs,” or unique identifiers that HomeSide uses to uniquely refer to a loan throughout its life in the system. One of these numbers is assigned to each loan the system processes.

• Credit Report Request. This transaction initiates a request to retrieve a credit report for one or more borrowers from a third-party consumer reporting agency, which provides the data back to HomeSide for processing.

• Underwriting and Price Request. The outcome of this transaction is the decision to approve the loan for a set of products at specified rate/point combinations, subject to the consumer submitting an application to HomeSide; verification of income, employment, and assets; and providing HomeSide with an acceptable property. If the loan is not approved for any number of reasons, including too much debt, insufficient funds, and so forth, consumers are asked to contact the call center. This provides the call-center representative the opportunity to correct any errors the consumer may have made during data entry and to submit a loan application that would satisfy the requirements of HomeSide and the applicable investor.

• Rate Option/Lock Notification Request. This transaction notifies underwriting that a consumer has chosen to “lock” his or her loan at a given interest rate and point combination. From the Web perspective, this is the last transaction the consumer performs with underwriting.

The following is an example of the XML document used for the Credit Report Request.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ECommerce_Message SYSTEM "E_Commerce_Interfaces_v1.0l.dtd">
<ECommerce_Message>
    <CreditReportRequestInput>
    <RequestHeader BusinessSourceID="HSL" LenderID="2329282-A2"
RequestorSubmissionDateTimeStamp="20010110 08:56:34"
RequestorTypeCode="LT"/>
    <Casefile CasefileID="2232410998"/>
    <ApplicantSummaries>
    <ApplicantSummary ApplicantSSN="999889215" ApplicantTypeCode="0"
CoAppSSN="999889210" FirstName="PENELOPE" LastName="PUBLIC"
MiddleName="A">
    <Location City="LOUISVILLE" State="KY" StreetAddress="2935 AUGUSTA
ST" ZipCode="40219"/>
    </ApplicantSummary>
    <ApplicantSummary ApplicantSSN="999889210" ApplicantTypeCode="1"
CoAppSSN="999889215" FirstName="PETER" LastName="PUBLIC"
MiddleName="E">
    <Location City="LOUISVILLE" State="KY" StreetAddress="2935 AUGUSTA
ST" ZipCode="40219"/>
    </ApplicantSummary>
    </ApplicantSummaries>
    <CreditAgencyInstructions AgencyAccountNumber="239921"
AgencyPassword="292113" MergeTypeCode="1" ReportFormatTypeCode="1"
ServiceProviderName="ir"/>
</CreditReportRequestInput>
</ECommerce_Message>

In most cases, these XML transactions are triggered as customers enter data to the Web-page forms. However, the Pull-Indicative-Rates and Casefile ID Requests are batch transactions in nature and are not initiated by any consumer action. To perform these automated transactions, HomeSide used the time services API of BEA WebLogic.