LBi has created a custom designed framework which incorporates a number of key technologies. In the class diagrams for each function the dashed lines indicate processes that are part of the framework.


(LBi Web Application Framework)
The framework supports the separation of logic and processing between front-end display, data storage and business logic processing. This is referred to as the MVC (Model View Controller) design pattern.

Model is the data; this is maintained separately from the actual underlying database structure. The abstraction from the actual database design allows updates to table layouts and optimization of data access methods without impacting the function of the system.

View is the display and update of the pages; keeping this separate from the back end processing allows screens to be customized without affecting the business logic. This also eases the possible future incorporation of a separate display type (e.g. wireless palm OS users).

Controller is the flow of screens and the business logic processing; having this separate keeps the business logic in a single place. This allows for easy updates to business rules without impacting the rest of the system.

Below is an example of how the framework handles requests:

1.	The user wants to submit a new job request for approval
2.	The job request update screen is presented; items such as the drop down list of Departments and the drop down list of Salary Grades are loaded by referencing lists that are maintained system wide. This prevents constant data access and hard coding in the actual page.
3.	When the user has entered the desired description text, they will submit that page.
4.	As with each data screen, the system will automatically collect the information on the form and store it in a form bean. Most pages in the system reference a form bean; sometimes multiple related pages will all reference the same form bean. The purpose of these beans is to collect the screen data and perform basic validation. Items such as checking for valid date entries are done here.
5.	If validation in the form bean fails, the user is presented with their original form along with an error message indicating the error. This is the same type of error screen that will be displayed regardless of where in the framework and entry error is found.
6.	If validation is successful, the system will call an action bean to process the submission. Action beans are similar to the form beans in that most pages in the system will reference one and they are generally in pairs with the associated form bean for the page. The action bean will take the information in the form bean and any other required information about the update and create an event. Each function in the system has its own event. In this case, there is a job request event that will contain the updated description, department and salary information and the fact that the user wishes to submit this for approval.
7.	This event is passed through a central process for the system to a central process in the EJB container. The EJB container allows transaction safe processing and a separate execution environment for the business logic processing.
8.	The central EJB process checks the type of event and passes it to the appropriate handler, that passes this to the correct controller program. In this case, this is the job request controller program that supports submitting new job requests as well as approving, deleting, and viewing them.
9.	The job request controller checks the event and verifies that it meets all business rules. If it does not, it creates an error that is handled the same as in step 5.
10.	If the update is accepted, the controller will use a specific data access program to make the actual database update. In this case, there is a job request specific database access program for saving the updated language.
11.	The controller can then return a response event that will be used to display confirmation to the user.