WebSphere Commerce framework overview

In WebSphere Commerce, the server runtime defines the framework for handling system and user requests, and performs the appropriate business logic to process the requests. The framework is built using an MVC design pattern and provides an environment that hosts business logic and handles persistence. It performs such tasks as transaction management and session management.

WebSphere Commerce and WebSphere support a variety of security mechanisms that can be used to protect access to data and other assets of the server. The access control framework in WebSphere Commerce prevents users for executing particular business logic. Not only does this access control framework provide a fine gain control on business logic, it also provides the flexibility to restrict access on what data the user is allow to view and modify. Access control allows you to group commands by access groups, assign different customer commands to different owners, assign access to all owners, assign global site administrator access. By exploiting WebSphere global security, access to Web resources such as servlets, JSP files, and Enterprise JavaBeans (EJB) methods can be controlled for an additional layer of security.

The command framework, an architectural component of the WebSphere Commerce server runtime, provides the ability to execute commands which represent different business processes in the system. The command framework defines Java interfaces and abstract implementation that business logic extends and implements. Also provided is a set of base classes that commands can extend to simplify implementation.

The interactions between WebSphere Commerce components are shown in the following diagram.

Servlet engine

The servlet engine is the part of the WAS runtime environment that acts as a request dispatcher for inbound URL requests. The servlet engine is only used for Web applications. The servlet engine manages a pool of threads to handle requests. Each inbound request is executed on a separate thread. WebSphere Commerce commands can be invoked from various devices. Examples of devices that can invoke commands include:

  • Typical Internet browsers

  • Mobile phones using Internet browsers

  • Procurement systems sending requests using XML over HTTP

A protocol listener is a runtime component that receives inbound requests from transports and then dispatches the requests to the appropriate adapters, based upon the protocol used. The protocol listener includes a Request servlet.

When the request servlet receives a URL request from the servlet engine, it passes the request to the adapter manager. The adapter manager returns the associated adapter for the request. Once the specific adapter is determined, the request is processed. The associated adapter is used for device specific session management for response formatting.

The list of adapters is initialized when the server is initialized. Each Web module can have their own customized list of supported adapters.

 

Presentation layer

Controller

The controller plays a role in enforcing the programming model for the commerce application. For example, the programming model defines the types of commands that an application should write. Each type of command serves a specific purpose. Business logic must be implemented in controller commands. The controller expects the controller command to return a view name.

For HTTP requests, the controller performs the following tasks:

  • Begins the transaction using the UserTransaction interface from the javax.transaction package.

  • Gets session data from the adapter.

  • Determines whether the user must be logged on before invoking the command. If required, it redirects the user's browser to a logon URL.

  • Checks if secure HTTPS is required for the URL. If it is required but the current request is not using HTTPS, it redirects the Web browser to an HTTPS URL.

  • Invokes the controller command and passes it the command context and input properties objects.

  • If a transaction rollback exception occurs and the controller command can be retried, it retries the controller command.

  • A controller command normally returns a view name when there is a display page to be sent back to the client. The controller invokes the appropriate view for the corresponding page to be displayed. There are a number of ways to form a response view. These include redirecting to a different URL, forwarding to a JSP page, or writing an HTML document to the response object.

  • Commits the session data.

  • Commits the current transaction if it is successful.

  • Rolls back the current transaction in case of failure (depending upon circumstances).

Adapter framework and adapters

The adapter framework determines which adapter is capable of handling the request and associates the adapter with that request for response building and session management.

WebSphere Commerce adapters are device-specific components that perform processing functions before passing a request to the Web controller. Examples of processing tasks performed by an adapter include:

  • Instructing the Web controller to process the request in a manner specific to the type of device. For example, a pervasive computing (PvC) device adapter can instruct the Web controller to ignore HTTPS checking in the original request.

  • Transforming the message format of the inbound request into a set of properties that WebSphere Commerce commands can parse.

  • Providing device-specific session persistence.

The following diagram shows the implementation class hierarchy for the WebSphere Commerce adapter framework.

As displayed in the preceding diagram, all adapters implement the DeviceFormatAdapter interface. The following are the adapters that are used by the WebSphere Commerce runtime environment:

HTTP browser adapter

The HTTP browser adapter provides support for requests to invoke WebSphere Commerce commands that are received from HTTP browsers.

HTTP PvC adapter

This is an abstract adapter class that can be used to develop specific PvC device adapters. For example, if you needed to develop an adapter for a particular cellular phone application, you would extend from this adapter.

HTTP Program adapter

The program adapter provides support for remote programs invoking WebSphere Commerce commands. The program adapter receives requests and uses a message mapper to convert the request into a CommandProperty object. After the conversion, the program adapter uses the CommandProperty object and executes the request.

If required, the adapter framework can be extended in the following two ways:

  • Create an adapter for a specific PvC device (for example, create an HttpIModePVCAdapterImpl class to provide support for i-mode devices). An adapter of this type must extend the AbstractHttpPVCAdapter class.

  • Create a new adapter that connects to a new protocol listener. This new adapter must implement the DeviceFormatAdapter interface.

Data bean manager and data beans

WebSphere Commerce data beans inserted into JSP pages allow for the inclusion of dynamic content in the page. The recommended way of activating the data beans within a JSP page is by means of the WebSphere Commerce useBean tag. Alternatively, the data bean manager can be used. Access control is enforced by invoking data beans using the data bean manager.

The data bean manager activates the data bean so that its values are populated when the following line of code is inserted into the page: 

com.ibm.commerce.beans.DataBeanManager.activate(data_bean, request, response)

where data_bean is the data bean to be activated, request is an HTTPServletRequest object, and response is an HTTPServletResponse object.

Data beans are Java beans that are primarily used by Web designers. Most commonly, they provide access to a WebSphere Commerce entity. A Web designer can place these beans on a JSP page, allowing dynamic information to be populated on the page at display time. The Web designer need only understand what data the bean can provide and what data the bean requires as input. Consistent with the theme of separating display from business logic, there is no need for the Web designer to understand how the bean works.

Display pages

JSP pages are specialized servlets that are typically used for display purposes. Upon completion of a URL request, the Web controller invokes a view command that invokes a JSP page. A client can also invoke a JSP page directly from the browser without an associated command. In this case, the URL for the JSP page must include the request servlet in its path, so that all of the data beans required by a JSP page can be activated within a single transaction. The request servlet can forward a URL request to a JSP page and execute the JSP page within a single transaction.

The data bean manager rejects any URL for a JSP page that does not include the request servlet in its path.

 

WebSphere Commerce command model layer

WebSphere Commerce commands are Java beans that contain the programming logic associated with handling a particular request. The main commands types are controller commands, and task commands.

 

Persistence layer

Entity beans are the persistent, transactional commerce objects provided by WebSphere Commerce. If you are familiar with the commerce domain, entity beans represent WebSphere Commerce data in an intuitive way. That is, rather than having to understand the whole the database schema, you can access data from an entity bean which more closely models concepts and objects in the commerce domain. You can extend existing entity beans. In addition, for your own application-specific business requirements, you can deploy entirely new entity beans.

Entity beans are implemented according to the EJB component model.

Related concepts

WebSphere Commerce application layers
WebSphere Commerce common architecture
Command types
WebSphere Commerce enterprise beans
WebSphere Commerce data beans
WebSphere Commerce useBean tag