BOD from 30,000 Feets !

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. 

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.

Found this really nice pictorial description of the various assets and processes involved in the BOD development in the  IBM Red Book (sg247619)