WebSphere Commerce service commands

The service command is the entry point on the component facade where the Business Object Document (BOD) begins to be processed by the business logic.

The service command is a command that extends the WAS (not the WebSphere Commerce Server) command framework, and only the top-level service controller command needs to extend a specific implementation. The service controller command is an instance BOD command and should extend the abstract BOD commands. The service command breaks down the request into a series of business tasks and call the appropriate commands to complete these tasks. For more information on the WebSphere command framework, see the
Command class topic in the WAS information center.

Ideally the service controller command should not perform any database access. Instead it should call business task commands to perform the required database computation. If any resolution is required which requires database access, this resolution should be part of a validation business task command called in the validate() method. Not only should this validation task validate the specified BOD, it should also perform any database access to resolve the required information associated with the operation.

These business task commands are WAS commands and the only condition placed on the implementation is that it follows the WebSphere command pattern. No additional knowledge of WebSphere Commerce implementation or interfaces is required. For business task commands, the command only needs to extend the WebSphere command classes but uses the com.ibm.commerce.foundation.server.commands.CommandFactory class to instantiate the command implementation.

The command factory is used to create an instance of the command. The command factory determines through configuration the appropriate implementation for a particular command. The implementation instantiated can depend on a variety of information, but at a minimum it depends on the interface of the command to instantiate. Due to the common nature of how the requests are structured, the command factory can be used to abstract these tasks and determine the appropriate implementation.

Although at a minimum the command factory requires the interface name of the command to instantiate, it does support accepting a CommandKey object to instantiate an implementation. The command key is a way to add an additional condition to determine whether the default task implementation should be used or, based on this particular condition, another implementation should be used. The default implementation is always used in the case where the condition does not correspond to an implementation.

For example, to support searching, the Get design pattern recommends separating the logic into a fetch task and a compose task. The implementation of each of these tasks depends not only on the interface name of the task but either an "XPath key" or "Access Profile" for the fetch and compose tasks respectively. This condition allows new search expressions or access profiles to be added with minimal customization. Rather than extending an existing task to add support for this functionality, the condition is used to find the new implementation that is associated with this new behavior.

There are different command keys depending on the type of command to run. For the Fetch command, a Get command key is required to append the XPath expression as part of the key to retrieve the implementation. The same applies for specific action command keys to pick particular implementations based on more than just the command interface.

Related Concepts

WebSphere Commerce services
Component facade interfaces
WebSphere Commerce services functional architecture

Related tasks

Create the service command
Create a WebSphere Commerce service module
Testing a WebSphere Commerce service