Understanding > WebSphere Commerce and service-oriented architecture (SOA) > WebSphere Commerce Web services

Commerce Feature Pack

WebSphere Commerce BOD command framework

In the current WebSphere Commerce architecture, there are three different layers of the application: the presentation layer, the business logic layer, and the persistence layer. In WebSphere Commerce V6 Feature Pack 3.0.1, WebSphere Commerce introduces a new command framework for the business logic layer - the Business Object Document (BOD) command framework. The concept of a BOD has been used in prior versions of WebSphere Commerce, but in WebSphere Commerce V6 Feature Packs 3.0.1, 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 new 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 existing WebSphere Commerce architecture (on the left side of the diagram) and the framework introduced in WebSphere Commerce V6 Feature Pack 3.0.1 (on the right side of the diagram) are:

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:

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

Related concepts

Access control in the BOD command framework

Service module configuration

Data service layer

Related tasks

Work with WebSphere Commerce service modules

Implementing the service commands in the BOD command framework

Implementing access control in the BOD command framework

Add a custom user or error message to a BOD service module

Deploying the client library

Last updated: 25 November 2009