Design pattern for Get service implementation (SOI)
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 that are involved to create a Get service. One master controller command is created for each Get service for each noun. This command, which uses the com.ibm.commerce.foundation.server.util.oagis.SelectionCriteriaMapper utility class, extracts the Get information from the request BOD. It then 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. They must implement the search expression only to return the appropriate list of data beans that matches the expression.
The command framework can use the XPath expression and Fetch task command to resolve the Get request to a particular implementation by 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.
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
It is recommended that an access profile be used to scope the response data. Using an access profile makes it easier to extend the service at a later time, using different profiles to allow different access or data being returned. For example, to return a specific view of the data (such as 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 must be prepended to the XPath expression in curly brackets ({}). For example, to specify the access profile:
{_wcf.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 that are called for the data bean, each populating a set of the logical model.
To customize the amount and type of data that is returned in the response, you can use different Compose tasks without changing the Fetch task, 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 more 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 that are prefixed with IBM_ are reserved
for IBM predefined access profiles. This prevents naming collisions
between access profiles that are defined by WebSphere Commerce components
and your custom access profiles.
Access profile names that are
prefixed with IBM_Admin_ are for services that are
intended to be used by admin/CMC based services calls.
Access
profile names that are prefixed with IBM_Store_ are
for services that are intended to be used by the storefront.
To
achieve consistency across different service modules, the IBM_Admin_Summary and IBM_Admin_Details profile
names are used when retrieving summary and detail level information
about the entity object.
The recommended way to support Get operations is to use the existing WebSphere Commerce data beans to reuse the existing business logic and access control policies.