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)
