Web services and WebSphere Commerce

A web service is an interface that describes a collection of operations that are accessible through the network by using standardized XML messaging.

A web service is described by using a standard, formal XML notation, called a service description, where:
  • The service description includes all the details necessary to interact with the service, including its message formats (that detail the operations), transport protocols, and location.
  • The interface hides the implementation details of the service, allowing it to be used independently of the hardware or software platform on which it is implemented. The interface can also be used independently of the programming language in which it is written.
  • The foundations for web services are standards such as Simple Object Access Protocol (SOAP), the Web Services Description Language (WSDL), and the Universal Description, Discovery, and Integration (UDDI) registry.

Web services are self-contained, self-describing, modular web applications that can be published, located, and invoked across the web. Web services perform functions that can be invoked, ranging from a simple request to complicated business operations. If a web service is deployed and registered, other applications can discover and invoke it.

Web services allow applications to be integrated more rapidly, easily, and less expensively than ever before. Integration focuses on the XML messages that define the services rather than the protocol used to relay these messages. These characteristics are ideal for connecting business functions across the web, both between multiple enterprises and within a single enterprise. They provide a unifying programming model, so that application integration, both inside and outside the enterprise, can be done with a common approach, by using a common infrastructure. The integration and application of web services can be done in an incremental manner, by using existing languages and platforms and by adopting existing applications.

Topic overview

This topic contains several sections of interest that are related to web services and WebSphere Commerce.

Web services in WebSphere Commerce

WebSphere Commerce is designed to support web services, both as a provider of web services, and as a consumer (client) to other web services.

For example, external web service clients can connect to WebSphere Commerce and use the web services that are provided, as illustrated in the following diagram:
Diagram summarizing the high-level flow that is associated with WebSphere Commerce as a service provider: Web service clients send SOAP requests to and receive SOAP responses from WebSphere Commerce.
Alternatively, WebSphere Commerce can connect to other web service providers and request information, as illustrated in the following diagram:
Diagram summarizing the high-level flow that is associated with WebSphere Commerce as a service consumer: WebSphere Commerce sends SOAP requests to and receives SOAP responses from web service providers.

WebSphere Commerce uses web services to expose its data and business logic to applications that run outside the server, for example a Distributed Order Management (DOM) system. In addition, WebSphere Commerce components interact with each other using these services.

WebSphere Commerce services are designed for applications that access or update small amounts of information at a time. For example, the Management Center. Conversely, the services are not designed to load large amounts of data. The Data Load utility is used to perform this task.

Typical web service architecture

The web service architecture describes three roles: service provider, service consumer, and service broker; and three basic operations: publish, find, and bind. A network component can play any or all of these roles. The service providers publish web services to a service broker. Service consumers find required web services by using a service broker and bind to them.

Diagram summarizing the web service architecture roles and operations that are detailed in this section.

In a typical scenario, a service provider hosts a network-accessible service module, which is an implementation of a web service. The service provider defines a service description for the web service and publishes it to a service consumer or a service registry. The service consumer uses a find operation to retrieve the service description locally or from the service registry hosted by the service broker. The service consumer uses the service description to bind with the service provider and invoke or interact with the web service implementation.

This solution provides runtime support to enable business operations that are defined by WebSphere Commerce as web services.

WebSphere Commerce services functional architecture

The starting point of a WebSphere Commerce service is the definition of the high-level business object that is called the noun. Based on the noun, services are defined based on supported verbs that can act upon that noun. These combinations of verb and noun form the Open Applications Group Integration Specification (OAGIS) messages that represent a WebSphere Commerce service request and the corresponding response. OAGIS provides a consistent message structure and model for messaging by using XML. The functional architecture is structured around the transmission of these OAGIS messages from the client to the WebSphere Commerce Server, and back again.

The following diagram shows how a client such as a portlet can use WebSphere Commerce business logic:

  1. The client uses the client library to create an OAGIS message.
  2. The service binding routes the request.
  3. The service binding handles the serialization and deserialization of the OAGIS message and sends the request to the component facade.
  4. The component facade calls the appropriate WebSphere Commerce commands.
  5. The component facade forms the response.
  6. The service binding routes the response back to the client library.
  7. The client library returns the response message to the client.

How a client such as a portlet can use Comerce business logic

Component facade

A component facade is used to group a set of related business services, such as catalog or order. Component facades are implemented as Java interfaces and their business services are implemented as methods on these interfaces. Each method in a component facade represents the request business object document (input argument to the method) and the corresponding response business object document (result of the method). The method name is the request verb name plus the noun name. For example, a member component facade might implement the Get verb on the Person noun, which results in a getPerson() method on the facade.

The component facade accepts OAGIS messages that contain a combination of verb and noun. It then calls WebSphere Commerce commands to provide the business logic that is associated with different services. WebSphere Commerce component facades accept four types of service requests:

A verb can perform many business tasks. Business tasks correspond to activities, such as a customer who adds a business profile or updates an address. Business tasks usually correspond to controller commands in WebSphere Commerce. To distinguish which business task should be performed when a verb is called on a noun, a parameter that is known as an action is passed in the call to the verb. The possible combinations of verbs and the many actions that are associated with them result in many predefined services. WebSphere Commerce services leverage the existing WebSphere Application Server command framework. All business logic is represented as commands.

Service binding

The service binding resides between the client library and the services. Its responsibility is to provide the transport mechanism to pass data, by using service data objects, between the client and the service. This transport mechanism can be web services or local Java binding.

The service binding can be leveraged with or without the client library.

  • HTML requests use the Struts framework, which calls the client library. The requests are received as name-value pairs and are converted into the appropriate OAGIS messages.
  • JSP requests use the WebSphere Commerce foundation tag library, which calls the client library.
  • SOAP requests already receive XML documents, and in these cases there is no need to use the client library.

By leveraging the service binding, these assets can also be used outside of the WebSphere Commerce application and they still call the component facade.

Client library

The client library provides Java-friendly libraries that build the service requests that the WebSphere Commerce service accepts. Clients of a WebSphere Commerce service are advised (but not required) to use the client library to build the service request. The client library hides all the complexity of web services requests, reducing the cost of development and maintenance of the client. Client libraries provide a mechanism for the client to easily switch between web services and local Java calls depending on the deployment without needing to change the client code.

Clients use this library to build service requests from a Java application or any other web-enabled application. This client composes request Java objects and initiates the service communication.

IBM 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 might 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 that aligns the business world with the world of IT in a way that makes both more effective. Changes in one can quickly be 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 then 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 IBM's SOA architecture and vision.

One of the diagrams you repeatedly see referenced from the IBM's SOA Foundation white paper is the following diagram, which shows services that are communicating through the enterprise service bus (ESB):

services that are communicating through the enterprise service bus (ESB)

SOA adoption and service-oriented integration (SOI) 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 address 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 can 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 would expose a related set of inventory services on your application. This set of services enables your application to delegate inventory responsibilities to an external system.

Inter-connectivity between services

As part of service-oriented integration of business functions, WebSphere Commerce enabled 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 services 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).

This stage of SOA adoption allows you 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 by using a service-oriented integration model.
  • Dynamically adapt WebSphere Commerce processes and services to fit their business.

WebSphere Commerce web services transition to SOA

As part of the WebSphere Commerce transition to SOA, there is an effort to de-couple components to allow reuse of WebSphere Commerce business services in other environments besides the WebSphere Commerce application. In order to support this de-coupling, the core infrastructure is the first piece that must run independently so it can be leveraged in other environments as well. The request handling changes to create a consistent runtime environment that new and existing components can use. This consistent run time focuses on the processing of business object documents (BODs). This architecture paves the road to SOA adoption by standardizing on how clients talk with SOA components.

WebSphere Commerce provides 4 SOI service modules that have logical groupings of business objects that are grouped to standardize communication. These service modules are Member, Order, Catalog, and Contract.
Note: Extending BOD services with Overlays is not supported. Instead, you must extend an SOI service with Overlays. For more information, see ../../tutorials/tutorial/twvoverlaytutorial.html.

Business object document (BOD) command framework

In the current WebSphere Commerce services architecture, the following different layers of the application are used: the presentation layer, the business logic layer, the persistence layer, and the data service layer. WebSphere Commerce also includes a 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 7, the entire command framework is tailored to using BODs.

In prior versions of WebSphere Commerce, there are implementation dependencies between the various layers. The current architecture uses well-defined interfaces to de-couple the implementation of the presentation layer, business logic layer, persistence layer, and data service 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 (DSL)

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

The following diagram shows the different layers of the WebSphere Commerce programming model and how the data service layer fits into the model:
BOD programming model layers

Advantages of implementing SOA and using DSL in WebSphere Commerce

Implementing SOA and using DSL in WebSphere Commerce includes a number of consistency benefits. It provides consistency within the programming model, unifying all actions against the server. That is, SOA and DSL provide a consistent base for how WebSphere Commerce can interact with its own components and data, and with other components and their data.

As integrated features are enabled by using services over time, these services further build upon consistency within the programming model. In short, SOA and DSL are the building blocks for current and future WebSphere Commerce components, where consistency in the programming model can lead to an easier to implement and more reusable platform.

The following WebSphere Commerce components are examples of where SOA and DSL are used, or partially used:
  • Management Center
  • Distributed Order Management (DOM)
  • WebSphere Commerce SOA tutorials, and optionally, your own custom web services
  • Remote widgets
  • WebSphere Commerce search
  • Distributed Order Management (DOM) with Sterling Selling and Fulfillment Suite (SSFS)
  • REST services
  • Location-based services

The advantages of reuse in SOA and DSL provides the same interface, whether in WebSphere Commerce or from external sources. For example, you can code it once, implement it in WebSphere Commerce starter stores, and even in external systems, while all going through the same code path.

Web services entry points in the Information Center

After you become familiar with the overall web services concepts in WebSphere Commerce, you can use the web services task documentation according to each approach.

Web services tasks and related information:
Web services documentation entry points
Entry point Description and usage
Working with WebSphere Commerce SOI services You can develop client libraries, new commands, and business logic. The Java Emitter Template (JET) is provided and documented to assist you with these tasks.

Use this information when you want to work with WebSphere Commerce services using the WebSphere Commerce foundation feature. The WebSphere Commerce foundation feature adds new groups of services to the WebSphere Commerce server. For example, WebSphere Commerce foundation creates new services and updates the existing services that are required to support features.

The services in this task are typically used in the following layers:
  • Business logic layer
  • Persistence layer
Creating WebSphere Commerce services You can set up the development environment, create and extend client libraries, and set an EMF genmodel. The Java Emitter Template (JET) is provided and documented to assist you with these tasks.

Use this information when you create WebSphere Commerce services by using WebSphere Commerce Developer. Best practice tasks are outlined so that you can create your services to adhere to the WebSphere Commerce programming model.

The services in this task are typically used in the following layers:
  • Business logic layer
  • Persistence layer
Developing the business logic layer using the BOD command framework

WebSphere Commerce BOD command framework

You can use 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.

Use this information to develop service modules in WebSphere Commerce. WebSphere Commerce service modules contain the definitions for the nouns, generated code, and other information about the services that are supported. That is, a service module is a collection of related business objects for some business purpose. You can develop BOD Get, Process, Change, and Sync services.

The services in this task are typically used in the following layer:
  • Business logic layer (Business Object Document)
Using the data service layer

Data service layer

You can customize the Data Service Layer (DSL) to suit your business needs.

The DSL consists of 3 pieces: the business object mediation service, the physical persistence service, and the data service façade. The business object mediation service initializes mediators. These are classes that transform between the logical and physical representations of the domain model. This allows the business logic layer to deal only with the logical representation of the data. Each service module provides its own mediators, and there are 2 kinds: Read and Change mediators. They are listed in the BOM configuration file. Read mediators are used to process the OAGIS Get requests. Change mediators handle the OAGIS Change, Process, and Sync requests. The mediators access the physical data through the physical persistence service. This service translates XPath queries to SQL queries.

The services in this task are typically used in the following layers:
  • Data service layer
  • Persistence layer
WebSphere Commerce Web services with JSP pages You can enable WebSphere Commerce to be a service provider by enabling its business functions as web services that can be accessed by external systems. You can also allow WebSphere Commerce to be the service consumer by enabling it to invoke web services that are hosted by external systems.

Use this information when you are working with web services and JSP files. WebSphere Commerce is designed to support web services, both as a provider of web services and as a consumer (client) to other web services. Alternatively, WebSphere Commerce can connect to other web service providers and request information.

The services in this task are typically used in the following layers:
  • Persistence layer
  • Presentation layer
WebSphere Commerce foundation tag library You can use a collection of provided custom tags to support the authoring of WebSphere Commerce JSP files.

Use this information when you are working with web services and JSP files. For example, the <wcf:getData> tag, part of the WebSphere Commerce foundation tag library, allows you to retrieve service data objects from any WebSphere Commerce service and associate them with a newly declared scripting variable with a given ID. This specified ID also associates the SDO objects with a specified scope.

The services in this task are typically used in the following layers:
  • Presentation layer
Workspaces support for BOD service modules You can use the Management Center by using Get services from BOD service modules to retrieve business objects, and along with the business objects, change control metadata included in the response.

The change control metadata is returned to the Management Center, where it is used to determine whether the object can be modified by the current user. You can customize the aspects of the physical and logical layers of a BOD service module that are under change control, by enabling or disabling change control for nouns and noun parts.

Use this information when you are working with BOD service modules in workspaces. The information contains important support notes such as the scope for data service layer tables, nouns and noun parts, and presenting change control information.

The services in this task are typically used in the following layer:
  • Business logic layer (Business Object Documents)
Representational State Transfer (REST) services You can use Representational State Transfer (REST) services to provide a framework that can be used to develop RESTful applications on several platforms. These platforms can include web, mobile, kiosks, third-party and social applications.

Use this information when you are developing RESTful applications on several platforms for WebSphere Commerce. WebSphere Commerce REST services are JAX-RS REST services that are built on top of Apache Wink. The implementation classes contain JAX-RS annotations such as @Path, @Produces, @Consumes, @QueryParam, and @PathParam.

The WebSphere Commerce Storefront REST API is provided to assist you with this task.

The services in this task are typically used in the following layer:
  • Business logic layer
Location-based services You can use location-based services to target customers by using Global Positioning System (GPS) enabled mobile devices.

Use this information when you are working with smartphone and tablet starter stores. Mobile web starter stores and mobile applications can take advantage of location-based marketing activities.

The services in this task are typically used in the following layers:
  • Business logic layer
  • Presentation layer

Web services tutorials

After you become familiar with the overall web services approaches in WebSphere Commerce, you can perform several scenarios by using the web services tutorial documentation.

Web services tutorials introduce the various tasks that are related to creating and customizing web services for WebSphere Commerce applications.

For more information, see Web services tutorials.

Additional information about web services

The following section familiarizes you with the many websites that contain technical information for understanding and using your web services. A wealth of online information is available to complement the product documentation.

For more information about web services and related technologies, see the following websites:

Web services reference information

WebSphere Commerce provides many web services, which are grouped by component. Each component contains one or more nouns. In addition, WebSphere Commerce provides WSDL files that describe its web services.

Articles of interest