WebSphere Commerce as a service provider

When we 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.

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

IBM recommends using 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.htm.

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

• Enable WebSphere Commerce as a service provider
  We can enable a business operation defined by WebSphere Commerce as a Web service. In this scenario, WebSphere Commerce acts as the service provider to external systems.

• Security and the WebSphere Commerce web service framework
  The WS-Security specification (http://www.oasis-open.org/committees/wss/) defines several techniques for implementing web service security.

• Web service caching
  The WebSphere Application Server Web service engine provides caching support, so that a Web service request can be cached and the cached response returned in place of subsequent processing; however, this caching support follows the all-or-nothing approach for both the request and the response.

• Modifying an inbound Web service
  To avoid having customization overwritten by future versions of WebSphere Commerce, we do not recommend that you modify existing inbound services. Instead, create a new version of the inbound service based on existing ones.

• Deploying an inbound Web service
  Deploying a web service to your production environment is treated the same way as deploying other assets -- as updates to the WebSphere Application Server using the WebSphere Application Server Administration Console.

• Configure the Secure Sockets Layer
  The Secure Sockets Layer (SSL) is required by inbound services of WebSphere Commerce to use SOAP/HTTPS.

Related concepts
WebSphere Commerce Web services with JSP pages
Understanding the WebSphere Commerce Web service framework

Related tasks
Enable WebSphere Commerce as a service provider
Configure a Web application

Related reference
Additional information about Web services
Inbound web services provided