If you have an existing application that you want to convert to a Business Components for Java application, you will find this topic helpful. Although there is no one recipe for converting an existing application to use business components, there is a logical order in which things can be done.
Your current application is assumed to be a two-tier client-server application, with a thick-client front end accessing a database back end. Legacy client-server applications of this sort are forms-based, meaning that the business logic resides directly in the client forms. Applications of this sort are often created with tools like Developer 2000, PowerBuilder, or Visual Basic. Depending on the language the application is coded in, you may have an easier or harder time converting the application. If it was coded in Java, you will be slightly better off, as the language would have forced the business logic to be created in classes, and not in the user interface.
Business Components for Java puts the business logic on the middle tier. As such, the client forms do not contain the business logic. This change of paradigm is central to the design of business component applications. Your business components application will be structured differently. Even though the final application will use some sort of form, it may be distributed in a number of different ways.
Before you can start building your business components application you must analyze your current application on a form-by-form basis. Each of the client forms in your application contains information that will help you build your business component application. To decipher this information, you need to ask the following questions:
What database tables does this form access?
Take a look at each form and note which database tables this form modifies or uses These tables will correspond one-to-one with entity objects in a business components application.
For example, if you have an Orders form that contains information about salesperson, customer, and item, you can infer that there are at least three database tables that contain this information. These database tables will be represented by entity objects.
When two database tables are linked by a key, this is represented by an association object. An association object links entity objects. To find the associations, you must know or infer the relationships in the underlying tables.
In a forms-based application, validation occurs on the client forms. Event handlers for the individual UI-controls handle validation of their fields. For example, a text field control could have an event called on_change. When the text field changes, the on_change event executes the code related to the event. In this manner, the business logic is validated.
In a business components application, validation is done on the middle tier. Your UI controls will not enforce validation, so you will need to decipher the business logic for each control on every form. You will probably find that many forms use similar validation for their fields, for example, validating a date, which will simplify the process somewhat.
Domain objects are a special kind of business component that declare what kinds of values something may have. For example, you could have a membership domain that allowed only the values Platinum, Gold, and Silver. In your legacy application, this could be implemented by a drop-down list that contains only those discreet values. In a business components application, each of your user-designed types should be represented as a domain object.
Each form in your legacy program represents some view of the data. Ask the following questions:
Does this form contain a subset of the available values; are certain
fields hidden? For example, is this form showing only customers?
When you create your view object, your view object SQL query will be based on the answers to these questions. Each form that represents a unique view of the data can be represented by a view object. You will have as many view objects as there are views of data.
View links connect view objects in the same way that association objects connect entity objects. To define the view links, there are additional questions to be answered:
Is this table linked to other tables?
The answers to these questions will tell you what gets selected from each table. This will help you when you define a view link SQL query.
Generally, you will have one application module per task. If a form contains one task, it will relate one-to-one with an application module. If the form contains multiple tasks, it will contain more than one application module.
If your legacy application uses a non-Oracle database, you can develop your application against it, but there are certain limitations. Also, if your database uses any enhanced datatypes not supported in the SQL92 standard, you will have to design a custom type map. For more information, see the section on Developing Business Components for Foreign Datasources.