Home
User Guide
The information contained in this section applies to IBM WebSphere Commerce Version 7.0.0.9 and Feautre Pack 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in new editions.
Developing
The topics in the Developing section describe tasks performed by an application developer.
Presentation layer
WebSphere Commerce uses Java Server Pages (JSP) to implement the view layer of the Model-View-Controller (MVC) design pattern. The view layer is in charge of retrieving data from the database through the use of data beans and formatting it to meet the display requirements. The view layers determines whether the request is sent to a browser or streamed out as XML. JSP files present a clean separation between data content and presentation.
WebSphere Commerce integration with WebSphere Portal
You can integrate WebSphere Commerce, a Business Application Service with WebSphere Portal, an Interaction Service. The Interaction Service provides core portal services (WebSphere Portal) that aggregate applications and content and deliver them as role-based applications. The Enterprise Service Bus (ESB) pattern is used for communication, mediation, transformation and integration with external systems. Using an ESB to integrate the Web services exposed from WebSphere Commerce to the WebSphere Portal promotes a loosely coupled design where the ESB manages the interactions styles between the WebSphere Commerce services and the presentation layer. You do not need to alter your presentation layer to support the protocol and format used by the WebSphere Commerce services. Instead, you rely on the ESB to perform tasks such as message transformation and protocol mediation. Neither WebSphere Commerce nor WebSphere Portal needs to change in order to communicate with one another. The ESB is used to act as an interpreter between the two systems and will translate the messages into a format the receiving system understands.
Customizing WebSphere Commerce Portal integration
There are two main approaches to Customizing WebSphere Commerce Portal integration. Using the provided WebSphere Commerce MVCPortlet class (MVC style), and Using WebSphere Portal general programming techniques (Web service style).
Using the provided WebSphere Commerce MVCPortlet class (MVC style)
The WebSphere Commerce Portlet, MVCPortlet, is a generic implementation of the MVC pattern. It allows you to set up one or more portlets, each with its own configuration, to call various WebSphere Commerce services. The goal of this MVCPortlet is to cleanly separate the model (application logic that interacts with a database) from the view (HTML pages that are presented to the client) and the controller (instance that passes information between view and model). This programming pattern greatly reduces code redundancy and maintains a consistent behavior across all WebSphere Commerce portlet actions.
WebSphere Commerce Portal integration event handlers
The MVCPortlet framework is designed in a flexible way so that each portlet request can be handled differently using an event handler. For each action event and render event, it is possible to define a corresponding event handler in the portlet MVC configuration file.
WebSphere Commerce portlet action handler
This WebSphere Commerce portlet action handler invokes the logic for handling this portlet action request.

WebSphere Commerce portlet action handler

This WebSphere Commerce portlet action handler invokes the logic for handling this portlet action request. It retrieves several properties, clientLibrary, clientMethod, renderName, and session, from the MVC configuration registry. It then calls into the client library method provided using Java reflection, passing a parameter map which is composed based on the name-value pairs given in the action request.

When a response is returned by the client library, this handler will take the response name-value pair map (which can either be a map of String[] or a map of String) returned from the client library, and then set to the response object as a render parameter so that the context and core business data will not be lost in an event of a page refresh. Note that a page refresh issued from the portlet container does not involve performAction().

To create a new customized version of the WebSphere Commerce Portlet action handler, the new code must implement the com.ibm.commerce.foundation.client.portal.handlers.PortletActionHandler interface. A generic portlet action request handler, com.ibm.commerce.foundation.client.portal.handlers.MVCPortletActionHandler, is provided to simplify the task of calling the WebSphere Commerce service client library, which is the recommended programming pattern. See com.ibm.commerce.foundation.client.portal.handlers.MVCPortletActionHandler for more information.

When coding a new WebSphere Commerce portlet action request handler, you need to be aware of a number of things. There is additional runtime information that needs to be gathered for use with the WebSphere Commerce service client library. When calling a client library, two mandatory objects are required - a business context object and the authentication callback handler. See com.ibm.commerce.foundation.client.portal.callbacks.AuthenticationCallbackHandler for more information.