WebSphere Commerce services functional architecture
Start with version 6.0 of WebSphere Commerce, the runtime environment has started to decouple the presentation layer from the business logic layer. With the release of WebSphere Commerce 6.0, a generic facade was placed between the Struts framework and the command layer. This generic facade handles the name-value pair parameters for the WebSphere Commerce commands. In this release, instead of just having a single generic facade, WebSphere Commerce has introduced well-defined facades for various business logic subsystems. These facades take structured objects instead of name-value pair input and follow the OAGIS processing model.
With this new model, regardless of whether the request is to get data or to change data, the request is independent of the presentation layer; the subsystem has the same logic whether the request was from a browser or from Web services.
The starting point of a WebSphere Commerce service is the definition of the high-level business object called the noun. Based on the noun, services are defined based on supported verbs that can act upon that noun. These combinations of verb and noun form the OAGIS messages that represent a WebSphere Commerce service request and the corresponding response. The functional architecture is structured around the transmission of these OAGIS messages from the client (for example, a portlet in a WebSphere Commerce Portal server) to the WebSphere Commerce Server, and back again.
The following diagram shows how a client such as a portlet can use WebSphere Commerce business logic:
- The portlet uses the client library to create an OAGIS message.
- The service binding routes the request.
- The service binding handles the serialization and deserialization of the OAGIS message and sends the request to the component facade.
- The component facade calls the appropriate WebSphere Commerce commands.
- The component facade forms the response.
- The service binding routes the response back to the client library.
- The client library returns the response message to the client.
Component facade
A component facade is used to group a set of related business services, such as catalog or order. Component facades are implemented as Java interfaces and their business services are implemented as methods on these interfaces. Each method in a component facade represents the request business object document (input argument to the method) and the corresponding response business object document (result of the method). The method name is the request verb name plus the noun name. For example, a member component facade might implement the Get verb on the Person noun which results in a getPerson() method on the facade.
The component facade accepts OAGIS messages that contain a combination of verb and noun. It then calls WebSphere Commerce commands to provide the business logic associated with different services. WebSphere Commerce component facades accept four types of service requests:
- Get Request and the Show Response
- Process Request and the Acknowledge Response
- Change Request and the Respond Response
- Sync Request and the ConfirmBOD Response
A verb can perform many business tasks. Business tasks correspond to activities, such as a customer adding a business profile or updating an address. Business tasks usually correspond to controller commands in WebSphere Commerce. To distinguish which business task should be performed when a verb is called on a noun, a parameter known as an action is passed in the call to the verb. The possible combinations of verbs and the many actions associated with them result in many predefined services. WebSphere Commerce services leverage the existing WAS command framework. All business logic is represented as commands.
Service binding
The service binding resides between the client library and the services. Its responsibility is to provide the transport mechanism to pass data, using service data objects, between the client and the service. This transport mechanism can be Web services or local Java binding.
The service binding can be leveraged with or without the client library.
- HTML requests use the Struts framework, which calls the client library. The requests are received as name-value pairs and are converted into the appropriate OAGIS messages.
- JSP requests use the WebSphere Commerce foundation tag library, which calls the client library.
- SOAP requests already receive XML documents, and in these cases there is no need to use the client library.
By leveraging the service binding, these XML handler assets can also be used outside of the WebSphere Commerce application and they still call the component facade.
Client library
The client library provides Java-friendly libraries that build the service requests that the WebSphere Commerce service accepts.
Clients of a WebSphere Commerce service are advised (but not required) to use the client library to build the service request.
Client libraries provide a mechanism for the client to switch between Web services and local Java calls depending on the deployment without needing to change the client code.
Clients use this library to build service requests from a Java application, WebSphere Portal Server, or any other Web-enabled application. This client composes request Java objects and initiates the service communication.
Related concepts
Component facade interfaces
Client library for WebSphere Commerce services
WebSphere Commerce services
OAGIS document processing
6.0.0.1WebSphere Commerce use of Open Applications Group (OAGIS) messaging
Related reference
WebSphere Commerce foundation tag library