WebSphere Commerce and service-oriented architecture (SOA)

IBM describes service-oriented architecture as a process, lifecycle and a set of tools to enable agile business transformation. It is this particular practice of deriving the IT implementation of the system from the business requirements that is known as IBM SOA. In the industry, there are many instances where one may find that SOA is equated with Web services. The IBM perspective on SOA is not solely about technology; hence, there is no SOA platform that one deploys their solution on. Instead, IBM SOA defines an architecture which allows clients to build a solution that has a tight coupling between the business requirements and the IT implementation. Changes in one can be quickly be reflected in the other, allowing for agile business transformation.

In IBM SOA there is a lifecycle defined which flows from gathering the business requirements to maintaining the system. This lifecycle guides one in building an SOA architecture. The lifecycle begins with the business analyst producing a business design that captures the business processes of the organization. The business analyst then works with the IT architect, to model the appropriate artifacts. These models are then transformed in to IT assets that are then assembled. The assets are subsequently deployed, and then the day-to-day operations are monitored and managed. This simple flow is what is known as the IBM SOA lifecycle of Model, Assemble, Deploy, and Manage. Tools are provided to aid in activities performed at the stage of the lifecycle; these tools are known as the IBM SOA Foundation tools.

A key concept in SOA is that of Services. Services are repeatable tasks found within business processes. Service-orientation is a way of integrating your business as a set of linked services. A service-oriented architecture, then, exploits the principles of service-orientation to achieve a tighter relationship between the business and the information systems that support the business. Implementing IBM SOA can help your company realize the following benefits:

See IBM's SOA Foundation - An Architectural Introduction and Overview for exhaustive coverage of IBM's SOA architecture and vision.

One of the diagrams you will see repeatedly referenced from the IBM's SOA Foundation whitepaper is the following diagram, which shows services communicating through the enterprise service bus (ESB).

 

SOA Adoption and service-oriented integration in WebSphere Commerce

IBM describes four phases for SOA adoption, as described in the following table:

Phase Name Description
1 Implementing individual Web services Create services from tasks contained in new or existing applications
2 service-oriented integration of business functions Integrating services across multiple applications inside and outside the enterprise for a business objective
3 Enterprise-wide IT transformation An architected implementation enabling integration across business functions throughout an enterprise
4 On Demand Business Transformation Broad transformation of existing business models or the deployment of new business models

WebSphere Commerce Enhancements for version 6 addresses phase 2 adoption, which is known as service-oriented integration (SOI). Unlike phase 1 where a set of services are provided in a more ad-hoc basis to enable applications to communicate, phase 2 is more focused on enabling scenarios. Hence, while an adoption at phase 1 may enable an external system to update the inventory in the application via the exposure of an UpdateInventory service or get the price by using a PriceCheck service, phase 2 would expose a related set of inventory services on the application. This enables the application to delegate inventory responsibilities to an external system.

As part of service-oriented integration of business functions, WebSphere Commerce has enabled service-oriented integration (SOI) scenarios specifically focused on back-office integration. WebSphere Commerce is defining connections from its Business Application Services to Access Services (these are defined further in IBM's SOA Foundation - An Architectural Introduction and Overview). The two scenarios of focus are with external order management systems (OMS) and with enterprise resource planning systems (ERP). Reference implementations for OMS and ERP scenarios based on common software found in these systems are available when you obtain WebSphere Commerce Enhancements for version 6. This stage of SOA adoption allows you to:

You can read more about SOA, SOI, and the back-office integration scenarios enabled in SOA Logical Architecture and WebSphere Commerce back-office integration.

 

WebSphere Commerce services

As part of the WebSphere Commerce transition to SOA, there is an effort to decouple components to allow re-use of WebSphere Commerce business services in other environments besides the WebSphere Commerce application. In order to support this decoupling, the core infrastructure is the first piece that needs to run independently so it can be leveraged in other environments as well. The request handling has changed to create a lightweight runtime environment that new and existing components can use. This lightweight runtime focuses on the processing of business object documents (BODs). This new architecture paves the road to SOA adoption by standardizing on how clients will talk with SOA components. WebSphere Commerce now provides 4 SOI service modules -- logical groupings of business objects that have been grouped to standardize communication. These service modules are:

You can read more about the new components and services in WebSphere Commerce services.

 

WebSphere Commerce Portal integration

WebSphere Portal integration provides the interaction services in the diagram above. These interaction services provide the presentation layer to support the business services communicating over the ESB. Portals allow for aggregation and interaction of different services provided by different systems, and enables sharing contextual information across different services, for example, authentication information. For example, by using WebSphere Commerce Portal integration, you can provide a presentation for business application services provided by WebSphere Commerce and other service providers, and enable interactions between these service providers.

You can read more about WebSphere Commerce Portal integration in the WebSphere Commerce integration with WebSphere Portal topic.

 

Business object document 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 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 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. For more information on the BOD command framework introduced in WebSphere Commerce Feature Pack 3.0.1, see WebSphere Commerce BOD command framework.

 

Data service layer

The data service layer (DSL), introduced in WebSphere Commerce Feature Pack 3.0.1, provides a layer for data access that is independent of the physical schema. The purpose of the data service layer is to provide a consistent interface (called the data service facade) for accessing data, independent of the object-relational mapping framework (such as EJB, DAS, or JPA). In its turn, the abstracted mapping framework is used to transform the data retrieved from the database into a collection of Java objects. These objects are implemented as physical service data objects (SDOs).

To read more about the data service layer introduced in WebSphere Commerce Feature Pack 3.0.1, see Data service layer.

Related concepts

SOA Logical Architecture and WebSphere Commerce back-office integration
WebSphere Commerce Web services with JSP pages
WebSphere Commerce as a service provider
WebSphere Commerce as a service consumer

Related tasks

Enabling WebSphere Commerce as a service provider
Enabling WebSphere Commerce as a service consumer

Related reference

Outbound service interfaces
Additional information about Web services