Business Layer

Developing Chemical Information Systems An Object-Oriented Approach Using Enterprise Java, by Fan Li Copyright 2007 John Wiley Sons, Inc. 

Domain Object The design domain objects that are derived from the conceptual model in Chapter 10. 

Data Binder Since we are developing an object-oriented system, if the input is an SD File or an XML File, it must be converted to Java objects for processing efficiency reasons. This conversion is done by the Data Binder objects. 

Application Controller The central controller of the system workflow. Chemistry Intelligence Objects that implement chemistry business rules and salt handling logic. 

Property Calculator Objects that are responsible for calculating chemical and physical properties. 

---

The business layer (or domain layer) is the center of the system that does the real work. It implements all business logic and workflows. In J2EE, EJB can be used to implement the Business layer. However, you can also use Plain Old Java Object (POJO) with an object-relational mapping tool or direct JDBC API to do the job. 

The Business Layer is in the center of CRS where the core business functions reside. Any business application has a workflow—the steps it takes to accomplish one or many tasks or transactions. Clearly analyzing and understanding the workflow is essential to designing the Business Layer correctly. Use case specifications capture workflow from a user s perspective. The System Activity Diagram is an excellent tool to capture system workflow from a system perspective. Figure 12.1 is the System Activity Diagram (CAD) of CRS. 

Each activity in Figure 12.1 involves one to many groups of domain objects. Each of these object groups is a cohesive software component or service. From the above CAD, we come up with the following core components in the Business Layer. 

For the CRS system, we have identified seven core components. Our first task is to design their interfaces and the relationships between the interfaces. Figure 12.3 is the interface diagram of the CRS business layer. 

The Data Persistence Layer can be a thick layer that resides in the application middleware or a thin layer in the application middleware combined with some stored procedures in the database. The former makes the Data Persistence Layer independent of the underline RDBMS that is being used. The latter provides better performance because the number of network calls can be reduced. Either way, a wed-defined interface between the Business Layer and the Data Storage Layer is the key. 

The Data Persistence Layer performs four types of operations in the database on behalf of the Business Layer query, insert, update, and delete. These operations are invoked by the service objects in the Business Layer. In Chapter 12, we presented one type of service—the Registration Service. There are other types of services such as Query Service and Update Service, each of which leverages the Data Persistence Layer to perform database operations. 

In the case of the chemistry database, the situation is more complex. Compound data cannot be queried or updated using standard SQL. The read and write operations are encapsulated in vendor-specific Oracle data cartridges. Therefore, the Data Persistence Layer has another responsibility— hide vendor specifics with a standard interface so that the Business Layer does not care about vendor variations. 

---