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 by 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 supports various 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 running particular business logic. The access control framework provides fine grained control on business logic, and flexibility to restrict access on what data the user can view and modify. With access control we can group commands by access groups, assign different customer commands to different owners, and assign access to all owners and global site administrator access. By using WebSphere global security, access to Web resources such as servlets, JavaServer Pages (JSP) files, and Enterprise JavaBeans (EJB) methods can be controlled for an extra layer of security.

The command framework, an architectural component of the Transaction Server runtime, provides the ability to execute commands that 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

• Presentation layer

• WebSphere Commerce command model layer

• Persistence layer

Servlet engine

The servlet engine is the part of the WebSphere Application Server 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 by using Internet browsers

• Procurement systems that send requests by 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, which are based on 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 can 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 the command is invoked. 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 tried again, it tries 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 can handle 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 a request is passed to the Web controller. Examples of processing tasks that are 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 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 that invoke 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 an 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 that are 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 using the WebSphere Commerce useBean tag. Alternatively, the data bean manager can be used. Access control is enforced by invoking data beans by 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 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 needs to understand only 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 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 that are provided by WebSphere Commerce. If we 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, we can access data from an entity bean which more closely models concepts and objects in the commerce domain. We can extend existing entity beans. In addition, for our own application-specific business requirements, we can deploy entirely new entity beans.

JPA entities are implemented according to the JPA component model.

Related concepts
WebSphere Commerce application layers
Design patterns
WebSphere Commerce data beans
WebSphere Commerce framework interaction
WebSphere Commerce common architecture
Command types
WebSphere Commerce enterprise beans
WebSphere Commerce useBean tag

Related reference
JSP programming best practice: Use the StoreErrorDataBean data bean for error handling
JSP programming best practice: Use JSTL in place of Java code
WebSphere Commerce JSP programming best practices
JSP programming best practice: Use the Commerce-specific tag for bean activation