HCL Commerce BOD command framework
The Business Object Document (BOD) command framework encapsulates the business logic layer of HCL Commerce. In Version 9, it is largely superseded by the Java Persistence API (JPA).
The HCL Commerce BOD command framework architecture uses well defined interfaces to decouple the implementation of the presentation layer, business logic layer and persistence layer. From the business logic layer perspective, OAGIS messages are used as the interface for making requests to retrieve business data or invoke business logic. The BOD command framework provides the capability to process these BOD requests and responses.
- BOD commands deal with service data objects instead of name-value pairs
- BODs can represent a complex request, that performs multiple actions instead of just one.
- BOD commands deal with a persistence interface called the data service layer using an object called the Business Object Mediator, and are independent of the persistence technology.
The application is divided into the following layers:
- Presentation layer
- The first layer is the presentation layer, which acts as the interaction service that will aggregate the business logic together to form an application. The presentation layer will interact with the business logic through the OAGIS defined services, and does not contain any business logic directly. Retrieving business data or executing any business logic must be done through the OAGIS defined services of a service module. The presentation layer cannot query the database directly to retrieve business data and must interact with the business components. The HCL Commerce Management Center is an example of a presentation layer.
- Business logic layer
- The business logic layer provides services to return data or run business logic. Business logic
in the BOD command framework is organized into service modules (sometimes referred to as
components). These service modules, and the services they contain, are leveraged by the presentation
layer to display data or invoke a business process.
The left side of the preceding diagram shows an approach in which services transform the OAGIS messages (BODs) to name-value pairs for processing by name-value pair commands. This makes for easy integration with existing HCL Commerce or customized commands. This approach is known as Service-Oriented Integration (SOI). It is appropriate to use this approach when the business logic you want to run is already written as a name-value pair command.
The right side of the diagram shows an approach in which services transform the OAGIS messages (BODs) to Java objects called service data objects (SDOs). The BOD commands use these objects as their interface to represent the BOD. The command then uses an object called the Business Object Mediator to accept service data objects and handle the mapping between these objects and how they are persisted. The business logic never needs to deal with the technology used to interact with how the data is persisted. The business logic layer passes SDOs to the persistence mechanism without binding itself to the persistence technology.
Service data objects are part of the IBM SOA programming model. To read more about SDOs, see the following links:The BOD command framework processing patterns are:
- Business Object Document Get processing pattern
- Business Object Document Process processing pattern
- Business Object Document Change processing pattern
- Business Object Document Sync processing pattern
Both business logic implementations, the name-value pair command framework and the BOD command framework, are fully supported, and can coexist in an HCL Commerce site.
- Persistence layer
- The business logic layer interacts with the persistence layer to retrieve and store data. The
persistence layer has two different implementations: EJB, and the data service layer.
On the left side of the diagram, HCL Commerce name-value pair processing commands use EJB for persistence. This is the approach used when integrating using Service-Oriented Integration (SOI).
On the right side of the diagram, commands retrieve and store data through the an object called the Business Object Mediator (BOM). The Business Object Mediator accepts and returns data in the form of logical service data objects. The persistence layer maps these objects to the persistence implementation to perform the data retrieval or updates. All persistence-specific assets, such as SQL queries are isolated within the DSL. The advantage of this approach is that the business logic layer is completely unaware of the persistence implementation and technology.
Both persistence implementations coexist and access the same data. However, a mixed model (for example, name-value pairs using the data service layer, or BOD processing commands using EJB) is not supported.