Business Object Mediator

The Business Object Mediator (BOM) performs bidirectional transformations between the physical service data objects (SDO) and logical SDOs. By performing this role, it provides a business object persistence interface for the data service layer. The BOM supports create, read, update, delete operations on the logical SDOs so that the business logic layer can work with them rather than the physical schema.

In HCL Commerce Version 6, before Feature Pack 3, business logic deals with Enterprise Java™ Beans (EJB) directly. While these beans are relatively easy to manipulate, the drawback is that these beans are a direct mapping to the physical schema, which complicates extension and customization. Using EJB directly also ties the business logic to the persistence technology. As WebSphere® Commerce moves to SOA and continues to extend its support of Web service clients, a logical model of SDOs was defined for the business logic to use. The objects in this logical model, the logical SDOs, are the data interchange mechanism for inter-component interaction as well as Web service interactions.

There is also a set of service data objects used by the persistence layer, called physical SDOs. Physical SDOs are Java™ objects that represent the physical schema. The Business Object Mediator provides the mapping between these logical SDOs, and their counterparts in the persistence layer, the physical SDOs.

The Business Object Mediator provides access to both physical and logical data.

As part of the transformation process, the BOM uses the services of the Physical Data Container to fetch and save the physical data. The Physical Data Container manages the actual work of interacting with the physical schema. The Physical Data Container manages physical SDOs – it can create them, store arrays of them, and save them to the database.

As shown in the diagram above, there are two ways of persisting data through the data service layer. The most common approach is to call the BOM to transform your logical SDOs to physical SDOs. However, the business logic commands may occasionally need to work with physical objects directly, because they are not mapped to the logical model. For example, tables that are used to keep audit logs or statistics. In such cases, the business logic layer can make use the Physical Data Container to read and write data directly to the database.

Read and change mediators

The Data Service Layer initializes the BOM. These are classes that transform between the logical and physical representations of the domain model. This allows the business logic layer to deal only with the logical representation of the data. Each service module provides its own implementation for the mediators.

Each service module provides its own mediators, and there are two kinds: Read and Change mediators. They are listed in the Business Object Mediator configuration file. Read mediators are used to process the OAGIS Get requests. Change mediators handle the OAGIS Change, Process and Sync requests.

For read operations, the data service layer facade receives a query from the business logic layer. The query consists of an XPath expression and an access profile, which are extracted from the OAGIS GET verb. The data service layer forwards this query to the business object mediator (BOM) who, in turn, passes it to the persistence service. That service looks up the correct SQL template for the query, and uses it to generate one or more SQL statements. It then runs these statements, and maps their result sets into physical SDOs. This mapping, between the database schema (tables and columns) and the SDO classes, is defined by XML called Object-relational metadata. Lastly, the physical SDOs are returned to the BOM. The BOM configuration describes how to instantiate the necessary mediators, which are returned to the business logic layer.

Note: the mediator is returned, not just the SDO. The mediator contains the physical SDO data. It also contains the logic to convert the physical SDO to the logical SDO (which is the Java™ representation of an OAGIS noun).

For change operations (create, update, delete), the data service layer facade receives the OAGIS nouns as input, and passes them to the business object mediation service. This service instantiates the appropriate change mediators. In turn, they fetch the physical representation of the nouns from a service called the physical object mediation service. The BOM then returns the mediators to the business logic layer. The mediators are then called with specific actions to create, update, or delete nouns and noun parts. The logic inside the mediators translates these actions into operations on physical SDOs. For example, a create request will create new physical objects and populate them with noun values. After making all its changes, the business logic layer instructs the change noun mediator to save the updated physical SDOs. The mediator calls a physical object persistence service to update the database.

Note:

Removing objects from the list of physical data objects within a mediator is not supported. That is, call the delete() method on the physical SDO directly to delete it.
If you attempt to delete a parent DataObject after fetching the children of the DataObject in the same data graph, the WebSphere Application Server JDBC mediator will throw an exception. You have to delete the children DataObjects first before deleting the parent. However, if only the parent DataObject is fetched in the graph when the parent data object is deleted, the entries in the child table will be deleted by the database provided database table contains the constraint ON DELETE CASCADE.