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.
Session management
Session information for portlets is kept in the WebSphere Portal Server PortletSession core object. It is at the application scope and not at the portlet scope. This ensures that multiple portlets on a page and across pages can communicate as one client with the WebSphere Commerce Server.

Session management

Session information for portlets is kept in the WebSphere Portal Server PortletSession core object. It is at the application scope and not at the portlet scope. This ensures that multiple portlets on a page and across pages can communicate as one client with the WebSphere Commerce Server.

For more information about the PortletSession, see Core objects.

To communicate with a WebSphere Commerce service, each portlet must have two pieces of information - the authentication callback handler object and the business context object. These objects are stored, as a pair, in the portlet session, and so each portlet can potentially have its own unique session information. A contextKey is introduced to uniquely identify the object pair stored in the portlet session, because the session information is global across all active portlets. It is also possible to configure multiple portlets with similar business behavior, using the same contextKey, to share the same contextual and identity information.

This session information can then be used for downstream components such as WebSphere Commerce service JSP tags. These components rely on the render parameter, contextKey, from the request for retrieving the necessary business context and the authentication callback handler object. This mandatory render parameter is set by the action handler for each portlet request.

For more information about the BusinessContextType and AuthenticationCallbackHandler, see Business context object and Authentication callback handler object.