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 WebSphere Application Server (not the Transaction 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 about the command framework, see the Command class topic.

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 WebSphere Application Server commands and the only condition placed on the implementation is that it follows the command pattern. No additional knowledge of WebSphere Commerce implementation or interfaces is required. For business task commands, the command only needs to extend the 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" for the fetch task or an "Access Profile" for compose tasks. 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 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 tasks
Creating the service command
Creating a WebSphere Commerce service module
Testing a WebSphere Commerce service with a unit test case