Design pattern for Get service implementation
The design pattern for Get services is the basic design pattern to be used for retrieving and displaying information from Web services.
The following class diagram demonstrates the classes involved to create a Get service. One master controller command is created for each Get service for each noun. This command, using the com.ibm.commerce.foundation.server.util.oagis.SelectionCriteriaMapper utility class, extracts the Get information from the request BOD and breaks the work into two tasks, delegating to the command framework to run a Fetch command and a Compose command. The Fetch command fetches the data, while the Compose command composes the response.
Fetch
The Fetch command returns a list of data beans that matches the expression. Extensions of this Fetch command are associated with a particular XPath expression and only need to implement the search expression to return the appropriate list of data beans that matches the expression.
The command framework has the ability to use the XPath expression and Fetch task command to resolve the Get request to a particular implementation using the existing WebSphere Commerce command registry (CMDREG) data. Instead of having one implementation for a Fetch business task, the command framework uses the XPath as the selector to resolve the implementation. If a specific implementation is not defined for the given XPath, then a default Fetch is used.
The main principle behind this design pattern is customization. This pattern promotes reuse of the Fetch command, so supporting a new search expression is a matter of implementing a new Fetch command to return a list of populated databases that represent that new expression. By using the XPath and command configuration, you can associate one XPath expression with one command implementation, or multiple XPath expressions with the same command implementation. You do not need to modify the Compose tasks just to support a new search expression.
The member subsystem uses a slightly different approach where the master controller command always delegates to a single default Fetch command. The fetch command parses the XPath expression directly and selects the necessary data.
Compose
The Get command then takes that list and for each data bean, it calls a Compose task to transform the data bean into the appropriate logical model (noun).
Access profile
An access profile can be used to scope the response data. For example, to return a specific view of the data (for example a search view of a catalog entry), or to return the data in all languages for authoring purposes. As an extension to the XPath syntax, the access profile name-value pair should be prepended to the XPath expression in curly brackets ({}). You must always specify the access profile.
{ibmwcf.ap=$accessProfile$}/CatalogGroup[Name='MyCatalogGroupName']
When the Get command calls the Compose command, it uses the access profile of the request as the key to select the appropriate Compose implementation. Because the access profile is just a superset of another access profile, the Compose commands delegates to the parent access profile to first populate the logic model and add any required information. This results in a chain of Compose commands being called for the data bean, each populating a set of the logical model.
To customize the amount and type of data returned in the response, use different Compose tasks without changing the Fetch task, simply by using a different access profile as the key. Supporting a new access profile consists of creating a new Compose command for that access profile and registering the implementation. Also, this chaining pattern ensures that customization of the compose command at a particular access profile is reflected in all dependent access profiles. If the customization adds additional data at the summary access profile, then all child access profiles also include this summary data. If you override one command, all dependent code gets this new behavior.
Access profile names prefixed with IBM_ are reserved for IBM predefined access profiles. This prevents naming collisions between access profiles defined by WebSphere Commerce components and your custom access profiles.
To achieve consistency across different service modules, the IBM_Summary and IBM_Details profile names are used when retrieving summary and detail level information on the entity object.
The recommended way to support Get operations is to use the existing WebSphere Commerce data beans, in order to reuse the existing business logic and access control policies.
Related Concepts
WebSphere Commerce services
Component facade interfaces
Design pattern for Process, Change and Sync service implementation
Related tasks
Create the component facade
Create the service command
Create a new search expression
Related Reference
WebSphere Commerce extended XPath notation