WebSphere Commerce BOD command framework
The Business Object Document (BOD) command framework encapsulates the business logic layer of WebSphere Commerce. In Version 9, it is largely superseded by the Java Persistence API (JPA).
The WebSphere 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. The interaction between the business objects and persistence layer is isolated in an object called the Business Object Mediator. Business object document (BOD) commands interact with the Business Object Mediator to handle the interaction with the logical objects and how they are persisted. The key differences between the prior WebSphere Commerce architecture (on the left side of the diagram) and the WebSphere Commerce BOD command framework (on the right side of the diagram) are:
- 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 WebSphere 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 WebSphere Commerce or customized commands. This approach is known as Service-Oriented Integration (SOI). It is appropriate to use this approach when the business logic we 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 a WebSphere 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, WebSphere 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.
- Business logic layer design patterns
- BOD versions in WebSphere Commerce
- Service module configuration
- Error handling in the BOD command framework
- Cache invalidation in the BOD command framework
- SOI and BOD service modules