p
  


 
 
 
In prior versions of WebSphere Commerce, there are implementation dependencies between the
presentation layer, business logic layer and persistence layer.c
cc
 
c
cc
 c c c 
c
c  cc
c  cc
ccc
 c ccc
c
ccc cccc
 cc

c ccc
 c c c
c  ccc
c The BOD
command framework provides the capability to process these BOD requests and responses.

c  c c
c

c  c c ccc  ccc  c c

c!
c  c"   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 existing WebSphere Commerce architecture (on the
left side of the diagram) and the framework introduced in WebSphere Commerce Version 6
Feature Pack 3.0.1 (on the right side of the diagram) are:

yc BOD commands deal with service data objects instead of name-value pairs
yc BODs can represent a complex request that performs multiple actions instead of just one.
yc 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 three 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.

Service data objects are part of the IBM SOA programming model. To read more about
SDOs, see the following links:

yc http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-
whitepaper.pdf
yc http://www.ibm.com/developerworks/webservices/library/ws-soa-
progmodel2.html

The BOD command framework processing patterns are:

 yc Business Object Document Get processing pattern
yc Business Object Document Process processing pattern
yc Business Object Document Change processing pattern
yc 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 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 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.

yc  
   
The BOD programming model in WebSphere Commerce Version 6 Feature Pack 3
introduces four advanced BOD processing patterns: Get, Change, Process, and Sync.
These patterns use abstract commands to handle the processing of Business Object
Documents. The patterns also use a common OAGIS processing model that uses the
BODs directly rather than transforming them into name-value pairs.

  


Access control in the BOD command framework
Service module configuration
Data service layer
  
Working with WebSphere Commerce service modules
Implementing the service commands in the BOD command framework
Implementing access control in the BOD command framework
Adding a custom user or error message to a BOD service module
Deploying the client library
Last updated: 23 May 2010
x

http://publib.boulder.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.developer.so
a.doc/concepts/csdsoaprogmodel.htm