The purpose of this project is to develop an innovative Business-to-Business (B2B) online service aiding mortgage lenders and brokers in today's highly competitive mortgage market. The Broker Blueprint portal has three main classes of users - Brokers, Lenders (lending institutions), and application administrators. Following is the breakdown of application modules by the user class and a brief description of module functionality:
- Loan Search
This module eases brokers' loan search efforts by letting them enter borrower information just once and presenting eligibility results from participating lending institutions.
- Loan Status Management
This module enables brokers to maintain non-personal loan information and status of their borrowers online. The data maintained in this module is also the source data for the broker business intelligence dashboard.
The dashboard module is the business intelligence presentation layer built on top of a data warehouse. Loan status data entered through the Loan Status Management page is transformed via a backend SQL based Extraction Translation and Loading (ETL) process and loaded into the data wares house.
Besides the business intelligence charts, the dashboard also shows pipeline loan statuses for all the loans a broker has. A mortgage loan typically takes 4-8 weeks from submission to funding. During this time, the loan is said to be in the pipeline, and access to pipeline loan status information is a key supporting feature for broker users. The information entered and maintained in the Loan Status Management area drives the pipeline status charts.
- Website Customization
The Broker Blueprint portal enables brokers to choose a website template from a set of available templates for customization and hosting. The standard templates are stored in XSL format to which a transformation is applied with the customized data in real-time for building the target site.
- Locator Service
This is a Java Messaging System based supporting service run at the application layer which is transparent to users. Any new broker or lender address information inserted into the system or updates to existing address information in the system triggers an asynchronous service call by this service to the Yahoo! geocoder service with the address data. The Yahoo! geocoder service returns the validity of the address along with the latitude and longitude information for the address. The address coordinates are stored in the database and are used to calculate the location of the nearest branch relative to the broker's office location for each lending institution in the loan search results.
- Online Registration and Payment
This module enables brokers to customize the service by picking the packages they are interested in subscribing to, and register themselves via online credit card payment. Addition of subscription packages is also handled by this module. Credit card validation and payments are handled by this module by making an SSL call to the Verisign Payflow service.
- Branch Management
This module enables lending institutions to manage their branch information like location, contact information and address. The Locator Service uses this address data to retrieve and store location coordinates.
- Loan Program Management
Lending institutions use this module to create and update their loan program guideline, pricing, and broker commission data. This data is used during loan search by brokers to display qualifying loan programs for their search criteria.
Purpose of this Project
The purpose of this project is to load test, and fine tune the loan search functionality of the Broker Blueprint web application, an innovative Business-to-Business (B2B) online service aiding mortgage lenders and brokers in today's highly competitive mortgage market.
Broker Blueprint enables brokers to search for suitable mortgage loans across various participating lenders by entering their borrowers' loan parameters on a single page.The Broker Blueprint portal also expands the exposure of lending institutions' loan programs into untapped markets and gives participating lenders an edge over competing institutions
The MVC Pattern
Model-view-controller (MVC) is a software architecture that separates an application's data model, user interface, and control logic into three distinct components so that modifications to one component can be made with minimal impact to the others.
In broad terms, constructing an application using an MVC architecture involves defining three classes of modules.
Model: The domain-specific representation of the information on which the application operates. The model is another name for the domain layer. Domain logic adds meaning to raw data (e.g. calculating the total monthly subscription charges for a broker account based on the packages chosen, calculation of the closest lender's branch relative to a broker office location).
View: Renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the code which gathers dynamic data for the page.
Controller: Responds to events, typically user actions, and invokes changes on the model and perhaps the view.
Java Platform, Enterprise Edition (Java EE) is the industry standard for developing portable, robust, scalable and secure server-side Java applications. Building on the solid foundation of Java SE, Java EE provides web services, component model, management, and communications APIs that make it the industry standard for implementing enterprise class service-oriented architecture (SOA) and Web 2.0 applications.
Some of the reasons why the J2EE platform was chosen over competing technologies are below:
- Choice of OS and Application Server: Implementation of J2EE applications can be done on proven and reliable application servers like JBoss, which do not require license fees. In addition, these application servers can be run on a choice of free operating systems like Linux or Solaris.
- Integrated Development Environments: Development environments like Eclipse or NetBeans are freely available to support development of J2EE applications.
- Connectors: The Java Connector Architecture (JCA) is a standard for connecting to Enterprise Information Systems (EIS). JCA supports access to SAP, IBM CICS, PeopleSoft, Oracle, Siebel, Screens 3270, AS/400, Unisys, ADABAS-C, VSAM, Codasyl, IMS, Tuxedo, etc. Such a level of connectivity options is not available with any other implementation platform.
- Messaging Architecture: The Java Messaging Service (JMS) standard is supported by multiple vendors such as IBM, TibCo, Progress, SpiritSoft, Fiorina, Swift, Open3, JBoss, etc.
- Mature O/R mapping tools: It is best practice in Object Oriented development to decouple business objects from their underlying relational database representation. Java has several mature and robust products that support the mapping of relational databases to objects such as TopLink, CocoBase, Hibernate, OJB, etc.
- Standardized Authentication and Authorization: Java has a standard way of providing Authentication and Authorization (JSSE). The choices in .NET are limited and in fact a well-published bug in the way IE handled digital certificates required a service pack to fix.
- Distributed Caching: There are multiple vendors and open source projects that provide distributed caching (i.e. SpiritCache, Coherence, Gemstone, JCS, Oracle). Such a choice is not available with competing platforms.
Load testing of an application is done after the functionality of the application has been determined to be correct and matching user expectations. Load testing of an application is primarily used to ensure:
- The system responds in a timely way to user requests, and it's performance degrades gracefully with increasing user load
- The system scales to an established number of concurrent users
- The system remains stable under varying load
- Ensuring Service Level Agreements are met for the established number of concurrent users
“OpenSTA User Guide” by OpenSTA Community
“User Experience, not Metrics” by Scott Barber
“Script Control Language Reference” by OpenSTA Community