WebSphere Commerce as a service provider

When you enable business operations in WebSphere Commerce as Web services that can be accessed by external systems, WebSphere Commerce becomes the service provider.

The deployment model for Web services is to have a central server with published WSDL that defines the services it supports. From there, clients, whether they are external systems, Web applications, or rich client applications, will connect to the central server and invoke services that are defined by the publicly available WSDL.

Diagram summarizing the components and flow associated with WebSphere Commerce as a service provider detailed in this section.

Processing the request

The WebSphere Commerce Web service framework uses the approach of mapping the XML (SOAP body) request into the name-value-pair parameters passed to the service command that will be executed.

In terms of overall Web service request handling, the WebSphere Application Server Web service engine is responsible for delegating the request to the WebSphere Commerce Web service framework, and the framework is responsible for processing the request and generating the response. Processing the request consists of resolving credentials to associate with the request, converting the SOAP body into name-value pairs, mapping to a controller command, executing the command, and using the JSP composition service to create the response.

From the high-level perspective, success and application exceptions are handled in a similar fashion. The only difference is the JSP page used to compose the response: when an exception occurs, the error view will be used to determine the JSP page composing the response. For example, taking the OAGIS approach, the resulting document for the request would contain the status of the operation. This means that if an application exception occurs (that is, command execution results in an error), the resulting business object document would still be created but will indicate failure. A Web service fault will be returned only if an external error, such as an exception or a SOAP fault returned by the JSP page, occurs when preparing the request for processing. See the Faults and error response section below for further details.

Note: Standard OAGIS messages are not supported. Although the OAGIS style of interaction is used, only the OAGIS message envelope and verbs have been adopted by WebSphere Commerce. Simplified nouns which better represent the structure of how the business objects are modeled in WebSphere Commerce have been provided.

Exposing WebSphere Commerce web services

It is recommended that you use the WebSphere Commerce BOD command framework to expose WebSphere Commerce business functions as web services. That is, using WebSphere Commerce as a service provider.

For more information about this approach, see WebSphere Commerce BOD command framework.

For detailed information about creating a web service module from scratch using the WebSphere Commerce BOD command framework, see Tutorial: Creating a BOD service module.

For detailed information about creating a web service module that maps to existing controller commands and data beans, see ../../tutorials/concepts/cwvstoresoitree.html.

If you have a specific business need to use JSP pages to compose web services responses in any of the default web services, see ../../tutorials/tutorial/twvinboundws_2a.html. However, this approach is not recommended, as WebSphere Commerce no longer uses this approach by default.

WSDL format

The WSDL format promoted by WebSphere Commerce is document/literal wrapped. There are many benefits for using this format, including validation and WS-I compliance. For more information about the different WSDL formats, see Which style of WSDL should I use?.