Store architecture

WebSphere Commerce separates individual front-end storefronts from the servers on which they rely. This architecture increases security, scalability, flexibility in server topology, and improves the ease of development and deployment of stores and store customizations.

The Store server consists of a lightweight JVM that separates the storefront presentation layer from the search and transactional backbone. The Store server persists user sessions with cookies, and handles security through the web channel (that is, between the store and the user over HTTP and HTTPS). All store transactions, search queries, and user authentications are done through REST services with the Transaction Server and Search server. The Store server has no direct database access.

The programming environment separates all customized storefront assets into a single web application archive. This separation of custom files from provided defaults allows for a simplified lifecycle, where changes become easier to implement when improvements to WebSphere Commerce are released. This architecture offers developers and site administrators several appealing characteristics:

• Security

  Separated duties of web channel security and backend API and data security:

  • Individual storefronts have no direct access to the database, communicating securely through REST services.

  • Store developers are prevented from potentially unsafe access to data beans, service objects, and backend object containers.

• Scalability and flexibility

  Separated scale of front-end and back-end servers and development tasks:

  • Individual storefronts can be built and deployed, decommissioned, further customized or modified, and tested without any impact to the operation of the site.

  • Clear delineation of front-end and back-end development duties.

• Modernization

  Uses modern, flexible technology:

  • The model-view-controller (MVC) framework used by the store is Spring. Spring is popular, supported, and easy to adopt by developers with previous Struts and WebSphere Commerce experience.

    See Spring MVC and store controller customization.

  • The Store server is run on WebSphere Application Server Liberty.

The following list describes the tasks that are performed and maintained by the Store server:

• Session management

  • Resolve session from cookies

  • Generate session cookies

  • Handle persistent session

• Security

  • Cookie and token validations

  • CSRF, XSS, parameter whitelist

  • Redirection whitelist

  • Session timeout

  • HTTPS redirection

  • Handle authentication-required views:

    • Non-generic-required views and guest user creation (non-generic guest user)

    • Full-credential-required views and guest user migration (generic, full-credential guest, or full-credential logged-in user)

    • Authentication-required views (logged-in user)

• Redirection for password invalidation

• Double-click handling

• SEO logic

• Error handling

• DynaCache for store data cache for synchronized configurations

Store server Architecture

The Store server remains lightweight by containing only the essentials required to display the storefront to shoppers. Only security, session management, and SEO logic is incorporated, and all data besides cache invalidation information is retrieved from the Transaction Server and Search server through REST services.

File structure

The contents of the store are located in the crs-web archive.

• Site-level, non-customizable assets, static assets, and default configuration files.

• Store-level, customizable assets and configuration files.

To learn more about the file structure of the store server, see Store assets.

• Spring MVC and store controller customization
  The model-view-controller (MVC) framework used for the store is Spring. Spring is popular, supported, and easy to adopt by developers with previous Struts and WebSphere Commerce experience. The following information details the store Spring MVC implementation, and details on how to customize actions and views. After customizations are made, respective modifications need to be made to the REST template configurations.

• Store assets
  Store assets are located in the crs-web archive on the Store server.