WebSphere Commerce

1. Explain WCS Archetecture

WebSphere Commerce functional architecture

Descriptions:

Controller layer

The conductor of operations for a request. It controls the transaction scope and manages the session related information for the request. The controller first dispatches to a command and then calls the appropriate view processing logic to render the response.

Presentation layer

The presentation layer displays the result of command execution. The presentation layer can use JSP pages, or other rendering technologies.

Business Context Service (BCS)

A service that manages contextual information used by business components. The contexts include such information as globalization and entitlement.

Business logic facade

This generic interface is implemented as a stateless session bean which the controller calls to invoke controller commands.

Controller commands

A controller command business process logic such as OrderProcess. It invokes task commands to accomplish different unit of work in the business process. By default, access control is enabled for controller commands.

Task commands

A task command is an autonomous task that accomplishes a specific unit of application logic such as check inventory. A task command usually works with other task commands to complete processing of a controller command. By default, access control is not enabled for task commands.

Access beans

Access beans are simple persistent objects with setters and getters. The access bean behaves like a Java bean and hides all the enterprise bean specific programming interfaces, like JNDI, home and remote interfaces from the clients. Rational Application Developer provides tooling support to generate access beans from the schema.

Entity beans

Entity beans are used in the persistence layer within WebSphere Commerce. The architecture is implemented according to the EJB component architecture. The EJB architecture defines two types of enterprise beans: entity beans and session beans.

The business logic façade is a generic interface implemented as a stateless session bean.

The Struts controller calls the business logic façade to invoke controller commands.

A controller command performs business process logic such as OrderProcess. It invokes task commands to accomplish different units of work in the business process. By default, access control is enabled for controller commands. A task command is an autonomous task that accomplishes a specific unit of application logic such as check inventory.

A task command typically works with other task commands to complete the processing of a controller command. By default, access control is not enabled for task commands.

Business context service(BCS), It is a service that manages contextual information used by business components. The contexts include such information as globalization and entitlement.

Access beans are simple persistent objects with setters and getters. The access bean behaves like a Java bean and hides all the enterprise bean specific programming interfaces, like JNDI, home and remote interfaces from the clients. Rational Application Developer provides tool support to generate access beans from the schema.

Entity beans are used in the persistence layer within WebSphere Commerce. The architecture is implemented according to the EJB component architecture. The EJB architecture defines two types of enterprise beans: entity beans and session beans.

Finally, the presentation layer displays the result of command execution. The presentation layer can use JSP pages, or other rendering technologies.

2.Explain WebSphere Commerce Struts framework

Step 1: The Action servlet receives an HTTP request.

Step 2: The Action servlet routes the request to the module's request processor.

Step 3: The request processor passes the request, action form, and action mapping to the base action.

Step 4: Actions use action form data to invoke business logic operations on behalf of the client

Step 5: An ActionForward object is returned that indicates what view the controller should forward to.

Step 6: The request processor forwards to the appropriate view element when the action is completed.

3.Command error handling

A command can create one of 2 exception types.

An ECApplicationException is created if the error is related to user input and always fails.

For example, when a user enters an incorrect parameter, an ECApplicationException is created. When this exception occurs, the solution controller does not retry the command, even if it is specified as a retriable command.

An ECSystemException is created if a runtime exception or a WebSphere Commerce configuration error is detected.

For Examples of this type of exception include create exceptions, remote exceptions, and other EJB exceptions. When this type of exception occurs, the solution controller retries the command if it is retriable and the exception was caused by either a database deadlock or database rollback.

4.What is Access control?

In computer security, the process of ensuring that users can access only those resources of a computer system for which they are authorized.

Access control is composed of four elements: users, actions, resources, and relationships.

Users are the people that use the system.

For access control purposes, users must be grouped into relevant access groups. One common attribute that is used to determine membership of an access group is roles. Roles are assigned to users on a per organization basis. Some examples of access groups include registered customers, guest customers, or administrative groups like customer service representatives.

Actions are the activities that users can perform on the resource.

For access control purposes, actions must also be grouped into relevant action groups. For example, a common action used in a store is a view. A view is invoked to display a store page to customers. The views used in your store must be declared as actions and assigned to an action group before they can be accessed.

Resources are the entities that are protected. For example, if the action is a view, the resource to be protected is the command that invoked the view, for example com.ibm.commerce.command.ViewCommand.

For access control purposes, resources are grouped into resource groups.

Relationships are the relationship between a user and the resource requested. Access control policies might require that a relationship between a user and the source be satisfied. For example, users might only be allowed to display the orders that they have created.

What is controller command?

A controller command encapsulates the logic related to a particular business process. Examples of controller commands include the OrderProcessCmd command for order processing and the LogonCmd that allows users to log on. In general, a controller command contains the control statements (for example, if, then, else) and invokes task commands to perform individual tasks in the business process. Upon completion, a controller command returns a view name. The Web controller then determines the appropriate implementation class for the view command and executes the view command.

Controller command programming model

The abstract class and interface are both found in the com.ibm.commerce.command package.

The following diagram illustrates the relationship between the implementation class and interface of a new controller command with the existing abstract implementation class and interface.

A new controller command should extend the abstract controller command class ( com.ibm.commerce.command.ControllerCommandImpl). When writing a new controller command, you should override the following methods from the abstract class:

isGeneric()

In the standard WebSphere Commerce implementation there are multiple types of users. These include generic, guest, and registered users. Within the grouping of registered users there are customers and administrators.

The generic user has a common user ID that is used across the entire system. This common user ID supports general browsing on the site in a manner that minimizes system resource usage. It is more efficient to use this common user ID for general browsing, since the Web controller does not need to retrieve a user object for commands that can be invoked by the generic user.

The isGeneric method returns a Boolean value which specifies whether the command can be invoked by the generic user. The isGeneric method of a controller command's superclass sets the value to false (meaning that the invoker must be either a registered customer or a guest customer). If your new controller command can be invoked by generic users, override this method to return true.

You should override this method to return true if your new command does not fetch or create resources associated with a user. An example of a command that can be invoked by a generic user is the ProductDisplay command. It is sensible to allow any user to be able to view products. An example of a command for which a user must be either a guest or registered user (and hence, isGeneric returns false) is the OrderItemAdd command.

When isGeneric returns a value of true, the Web controller does not create a new user object for the current session. As such, commands that can be invoked by the generic user run faster, since the Web controller does not need to retrieve a user object.

isRetriable()

The isRetriable method returns a Boolean value which specifies whether the command can be retried on a transaction rollback exception. The isRetriable method of the new controller command's superclass returns a value of false. You should override this method and return a value of true, if your command can be retried on a transaction rollback exception.

An example of a command that should not be retried in the case of a transaction exception is the OrderProcess command. This command invokes the third party payment authorization process. It cannot be retried, since that authorization cannot be reversed. An example of a command that can be retried is the ProductDisplay command.

setRequestProperties(com.ibm.commerce.datatype.TypedProperty reqParms)

The setRequestProperties method is invoked by the Web controller to pass all input properties to the controller command. The controller command must parse the input properties and set each individual property explicitly within this method. This explicit setting of properties by the controller command itself promotes the concept of type safe properties.

validateParameters()

The validateParameters method is used to do initial parameter checking and any necessary resolution of parameters. For example, it could be used to resolve orderId=*. This method is called before both the getResources and performExecute methods.

getResources()

This method is used to implement resource-level access control. It returns a vector of resource-action pairs upon which the command intends to act. If nothing is returned, no resource-level access control is performed.

performExecute()

The performExecute method contains the business logic for your command. It should invoke the performExecute method of the command's superclass before any new business logic is executed. At the end, it must return a view name.

• Long-running controller commands
  If a controller command takes a long time to execute, you can split the command into two commands. The first command, which is executed as the result of a URL request, simply adds the second command to the Scheduler, so that it runs as a background job.
• Temporary changes to contextual information for URLs
  It is possible to override some of the command context information and execute URL commands within the context of another store, or on behalf of another user.
• Formatting of input properties to views
  For Web requests, when controller command completes, it returns the name of a view that should be executed. This view may require that several input properties get passed to it.
• Database commits and rollbacks for controller commands
  Throughout the execution of a controller command, data is often created or updated. In many cases, the database must be updated with the new information at the end of the transaction.
• Making controller commands retriable
  A retriable command is a controller command that can re-execute itself after encountering a system-level exception during the command execution.

What is task command?

A task command implements a specific unit of application logic. In general, a controller command and a set of task commands together implement the application logic for a URL request. A task command is executed in the same container as the controller command.

Task command programming model

A new task command should extend the abstract task command class com.ibm.commerce.command.TaskCommandImpl and implement an interface that extends the com.ibm.commerce.command.TaskCommand interface.

The following diagram illustrates the relationship between the implementation class and interface of a new task command with the existing abstract implementation class and interface. The abstract class and interface are both found in the com.ibm.commerce.command package.

In Java, the new MyTaskCmdImpl task command will then be defined as follows:

public class MyTaskCmdImpl extends com.ibm.commerce.command.TaskCommandImpl

implements MyTaskCmd

{

...

}

All the input and output properties for the task command must be defined in the command interface, for example MyTaskCmd. The caller programs to the task command interface, rather than the task command implementation class. This enables you to have multiple implementations of the task command (one for each store), without the caller being concerned about which implementation class to call.

All the methods defined in the interface must be implemented in the implementation class. Since the command context should be set by the caller (a controller command), the task command does not need to set the command context. The task command can, however, obtain additional session information by using the command context.

In addition to implementing the methods defined in the task command interface, you should override the performExecute method from the com.ibm.commerce.command.TaskCommandImpl class.

The performExecute method contains the business logic for the particular unit of work that the task command performs. It should invoke the performExecute method of the task command's superclass, before performing any business logic. The following code snippet shows an example performExecute method for a task command.

public void performExecute() throws ECException

{

super.performExecute();

// Include your business logic here.

// Set output properties so the controller command

// can retrieve the result from this task command.

}

The runtime framework calls the getResources method of the controller command to determine which protectable resources the command will access. It may be the case that a task command is executed during the scope of a controller command and it attempts to access resources that were not returned by the getResources method of the controller command. If this is the case, the task command itself can implement a getResources method to ensure that access control is provided for protectable resources.

Note that by default, getResources returns null for a task command and resource-level access control checking is not performed. Therefore, you must override this if the task command accesses protectable resources.

Data beans

Extending business logic might also result in new or modified data beans. A data bean is a Java bean that is mainly used to provide dynamic data in JSP pages.

There are 3 types of data beans:

Ø SmartDataBean

Ø CommandDataBean

Ø InputDataBean

SmartDataBean

A smart data bean uses a lazy fetch method to retrieve its own data. This type of data bean can provide better performance in situations where not all data from the access bean is required, since it retrieves data only as required. Smart data beans that require access to the database should extend from the access bean for the corresponding entity bean. For example, the ProductDataBean data bean extends the ProductAccessBean access bean, which corresponds to the Product entity bean.

Some smart data beans do not require database access. For example, the PropertyResource smart data bean retrieves data from a resource bundle, rather than the database.

command data bean

A command data bean relies on a command to retrieve its data and is a more lightweight data bean. The command retrieves all attributes for the data bean at once, regardless of whether the JSP page requires them. As a result, for JSP pages that use only a selection of attributes from the data bean, a command data bean can be costly in terms of performance. While access control can be enforced on a data bean level when using the smart data bean, this is not true for command data bean. Only use command data beans if using a smart data bean is impractical.

InputDataBean

A data bean implementing the InputDataBean interface retrieves data from the URL parameters or attributes set by the view. Attributes defined in this interface can be used as primary key fields to fetch additional data. When a JSP page is invoked, the generated JSP servlet code populates all the attributes that match the URL parameters, and then activates the data bean by passing the data bean to the data bean manager. The data bean manager then invokes the data bean's setRequestProperties() method to pass all the attributes set by the view.