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 to deploys a solution on. Instead, IBM SOA defines an architecture that aligns the business world with the world of IT in a way that makes both more effective. Changes in one can be quickly reflected in the other, allowing for agile business transformation.
In IBM SOA, there is a lifecycle that is 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 later 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 that are 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 that are found within business processes. Service-orientation is a way of integrating your business as a set of linked services. A service-oriented architecture, then, uses 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:
- Greater alignment of business and IT.
- Loosely coupled components and systems.
- A network-based infrastructure, enabling geographically and technologically, diverse resources to work together.
- Greater code reuse.
- Better process standardization throughout the enterprise.
See IBM's SOA Foundation - An Architectural Introduction and Overview for exhaustive coverage of the IBM SOA architecture and vision.
One of the diagrams that are referenced from the IBM SOA Foundation white paper is the following diagram, which shows how services communicate 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 | Creating services from tasks that are 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 that enables 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 addresses phase 2 adoption, which is known as service-oriented integration (SOI). Unlike phase 1 where a set of services is provided in a more ad hoc basis to enable applications to communicate, phase 2 is more focused on enabling scenarios. While an adoption at phase 1 might enable an external system to update the inventory in your application via the exposure of an UpdateInventory service or get the price by using a PriceCheck service, phase 2 exposes a related set of inventory services on your application. This set of services enables your application to delegate inventory responsibilities to an external system.
As part of service-oriented integration of business functions, WebSphere Commerce enables
service-oriented integration (SOI) scenarios that are focused on back-office
integration. WebSphere Commerce is defining connections from its Business Application
Services to Access Services (these connections 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).
Use this stage
of SOA adoption to:
- Incorporate WebSphere Commerce into an overall SOA Enterprise Architecture as both a producer and consumer of business services.
- Integrate with legacy systems and third-party vendors with a service-oriented integration model.
- Dynamically adapt WebSphere Commerce processes and services to fit their business.
We 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 web services
As part of the WebSphere Commerce transition to SOA, there is an effort to decouple components to allow reuse 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 is changed to create a lightweight runtime environment that new and existing components can use. This lightweight run time focuses on the processing of business object documents (BODs). This new architecture paves the road to SOA adoption by standardizing on how clients interact with SOA components. WebSphere Commerce now provides 4 SOI service modules - logical groupings of business objects that are grouped to standardize communication. These service modules are:
- Member
- Order
- Catalog
- Contract
Customization guidelines
When we are developing web services, follow these guidelines:- When we are customizing an existing service module, use the same programming model that the service module uses. For example, if the service module is SOI, our customizations in that component must be SOI.
- When we are creating a service module (creating a service module usually equates to creating a
Noun), there are two options:
- If you have existing code that uses the classic commerce programming model (EJB, Controller Commands), it is less effort to create an SOI module that reuses that business logic. However, there is an added cost if you choose to reimplement the service module using the Business Object Document (BOD) command framework, later.
- If you do not have existing code for the service module, write the service module using the BOD command framework. BODs are part of the IBM SOA programming model, the strategic direction for WebSphere Commerce.
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 WebSphere Commerce Version 6 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 is used in prior versions of WebSphere Commerce, but in WebSphere Commerce Version 6 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 about the BOD command framework, see: WebSphere Commerce BOD command framework
Data service layer
The data service layer (DSL) 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 that is 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 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
Enable WebSphere Commerce as a service provider
Enable WebSphere Commerce as a service consumer
Related reference
Deprecated feature: Outbound service interfaces
Additional information about Web services