HCL 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.
- 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 HCL Commerce
| 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 |
HCL 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, HCL Commerce enables service-oriented integration (SOI) scenarios that are focused on back-office integration. HCL 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).
- Incorporate HCL 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 HCL Commerce processes and services to fit their business.
You can read more about SOA, SOI, and the back-office integration scenarios that are enabled in SOA Logical Architecture and HCL Commerce back-office integration.
HCL Commerce web services
As part of the HCL Commerce transition to SOA, there is an effort to decouple components to allow reuse of HCL Commerce business services in other environments besides the HCL 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.
- Member
- Order
- Catalog
- Contract
Customization guidelines
When you are developing web services, follow these guidelines:- When you are customizing an existing service module, use the same programming model that the service module uses. For example, if the service module is SOI, your customizations in that component must be SOI.
- When you 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 HCL 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 HCL Commerce Version 6 Feature Pack 3.0.1, HCL 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 HCL Commerce, but in HCL Commerce Version 6 Feature Packs 3.0.1, the entire command framework is tailored to using BODs.
In prior versions of HCL 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.
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.