WebSphere Commerce BOD command framework

Starting in WebSphere Commerce Version 6 Feature Pack 3.0.1, WebSphere Commerce introduces the Business Object Document (BOD) command framework. The BOD command framework is a command framework for the business logic layer, used in WebSphere Commerce Version 6 Feature Pack 3.0.1 and WebSphere Commerce Version 7. The concept of a BOD has been used in prior versions of WebSphere Commerce, but starting in WebSphere Commerce Version 6 Feature Pack 3.0.1 and WebSphere Commerce Version 7, the entire command framework is tailored to using BODs.

In prior versions of WebSphere Commerce, there are implementation dependencies between the presentation layer, business logic layer and persistence layer. 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.

BOD programming model layers

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 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.

The BOD command framework processing patterns are:

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 1.1, and the data service layer.

On the left side of the diagram, WebSphere Commerce name-value pair processing commands use EJB 1.1 for persistence. This is the approach used by all WebSphere Commerce commands before WebSphere Commerce Version 6 Feature Pack 3, and 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 within WebSphere Commerce Version 6 Feature Pack 3 and WebSphere Commerce Version 7, 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 1.1) is not supported.