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 and WebSphere support 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 you 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 WebSphere Commerce 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
- 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 by 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.
- 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 by 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 that are 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 that is 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 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 Enterprise JavaBeans (EJB) component model.