Persistence Layer

The last step of the compound registration workflow persists compound data into the database. This step is accomplished by a RegistrationService object along with a data persistence layer, which will be discussed in the next chapter. 

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. 

There are a few design options for the Data Persistence Layer. Here we use the Data Mapper Pattern (Fowler, 2003b). The reason is that we want to separate the domain layer and the database schema and allow them to evolve independently. 

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. 

The first interface of the Data Persistence Layer is the finder interface— the interface for querying the database. Two types of queries must be supported by a chemical information database one is numeric or text query, and the other is structure query. The first type is the same as any other type of database. The second type is where chemistry databases differ—search the database based on substructure, structure similarity, and structure flexmatch. As such, the finder interface has to support these two types of finder methods. The CompoundFinder interface is as follows ... 

A data model describing the concepts it worked with, implemented as a persistence layer using Spring Roo [14] and Hibernate [15], The data model is an adaptation of the ISA-95... 

A web interface which allowed users to manipulate its internal data model, e.g. to model the manufacturing processes within the firm with it and observe the results produced by the WS below. The web interface was implemented using the above persistence layer. Spring Roo and the Spring MVC framework [16]. 

Persistence layer adaptation of the ISA-95 object model. In order to implement the Estimate production dates WS it was necessary to write a simple scheduler, and the scheduler itself would need a description of the current resources and processes available in the enterprise. Consequently, an appropriate data model had to be developed. 

The persistence layer is based on the object model in ISA-95 part 2, with some changes attempting to reduce the large amount of duplication present in the specification and some omissions. For instance, the idea of a Unit is left in ISA-95 as a single string ( meters ), without regards for the complex issues involving unit-based arithmetic, conversions and comparisons. Likewise, a new Property concept has been added as a base class for all the property classes within the data model. 

Human-oriented interface specification of the manufacturing processes. Having implemented the data model as a persistence layer, the next step for implementing the Estimate production dates WS was specifying the tile rectification resources for the manufacturing firm, and the processes and production capacities involved. 

The WS uses the same persistence layer as the web interface and offers its services through a SOAP WS. Most of the low-level communication details are abstracted away by the Apache CXF framework, which generates the required code from a WSDL interface [20]. After some initial manual testing using the soapUI tool [21], the WS underwent functional testing using the facilities in the Spring framework. 

---