The Patterns Process: Runtime patterns
After you choose an appropriate Application pattern to meet your e-commerce needs, it is time to select the specific Runtime pattern used to design your solution. The Runtime pattern uses nodes to group functional and operational components. The nodes are interconnected to solve a business problem. Each Application pattern has at least one corresponding Runtime pattern. These runtime patterns are based on the Enterprise Solution Structure (ESS) Thin Client Transactional Pattern and are a representative solution for the Electronic Commerce composite pattern.
Each Runtime pattern may have additional variations as well, including:
Depending on the customer requirements, you might need to extend variations or combine them to achieve desired results.
Proven Basic Runtime Pattern
(Click a node to get a detailed explanation.)
At the logical level, this Runtime pattern involves a synchronous interaction with the user during the first part of the shopping experience. An asynchronous (and deferred) response for the processing of details and confirmation of a submitted order follows. Therefore, this runtime does not allow for real-time features such as immediate inventory validation, order completion, or shipping details.
Web-Up basic online shopping process
-
From a Web browser client, the shopper connects to the commerce site by entering the Web site URL and does one of the following:
- Logs in to the commerce site if the user is recognized as a registered shopper from a profile on the database server
- Browses the site anonymously
- Enters profile information to become a registered user
- The user then interacts with the pages of the site. These are either static pages from the commerce server or pages dynamically built with information from the database server.
- The user adds items to a shopping cart. The data for the shopping cart is stored on the database server along with required session state information. A cookie is sent to the client browser. This cookie helps the commerce server track the progress of the customer interactions on the commerce site and connect users with their shopping cart.
- When the shopper wants to buy or check out items in the shopping cart, the commerce server stores the submitted order on the database server for later processing. An acknowledgment is sent back to the shopper that the order has been submitted, and the interactive session is terminated.
- The system uses one of several techniques to retrieve the order and process it through the back-end fulfillment, inventory, payment, and shipping processes. Note that this pattern does not specify the details of back-end integration. It can be done in batch or manually. The example given below describes how one site performed their order processing functions.
- Eventually, a confirmation e-mail of order status (such as delivery, out of stock, credit problems) is sent to the user.
Typically, the logon process uses registration data from the database server node to identify registered shoppers and encryption technology, such as Secure Sockets Layer (SSL), to protect sensitive data (for example, credit card or address information).
Currently, most sites do not use digital certificates. In the Enterprise-out application pattern, the client wants to extend the back-end systems with a tightly integrated Web access channel, and might want to integrate with corporate-wide directory and security mechanisms. For this reason, the Enterprise-out runtime pattern includes directory and security nodes on the internal network.
In the Web-up runtime pattern, however, the directory and security nodes are omitted, because clients do not usually want corporate-wide directory and security mechanisms. The "ESS Reference Architecture", used by IBM Global Services provides a much more detailed flow of the online shopping process and how it interacts with the infrastructure. This information is often used to prepare vendor quotes for the products necessary to physically implement the logical Runtime pattern.
Runtime pattern=Variation 1
(where supported, e.g. WebSphere Commerce Suite V5.1)
(Click a node to get a detailed explanation.)
For additional security, this solution may be implemented with the commerce application server node positioned behind the second (domain) firewall.
Runtime pattern=Variation 2
(where supported, e.g. WebSphere Commerce Suite V5.1)
(Click a node to get a detailed explanation.)
For additional load balancing and availability functionality, this solution may be implemented with a duplexed web server and commerce application server and may have a second dispatcher (load balancer) in standby mode.
Runtime pattern=Variation 3
(where supported, e.g. WebSphere Commerce Suite V5.1)
(Click a node to get a detailed explanation.)
In our previous example, we followed a major retail department store that wants to expand their sales to the Web. They chose the Web-up application pattern because they need a internet-only solution without any back-end integration.
As shown in the diagram below, the department store implemented support for two distinct buying channels within the same site:
- Web browser-based shoppers use the Web channel.
- Telemarketers use their point-of-sales system to complete orders.
Walking through a purchase:
-
During the shopping process, the user interacts synchronously with the commerce server and the database server. This process is actually similar to the shopping experience found in the Enterprise-out approach. After the shopper decides to buy the items in the shopping cart, however, this pattern takes a very different approach:
- The shopper is simply notified that the order has been taken and that confirmation is forthcoming.
- Most importantly, there is no online linkage from the online buying front end to the backend systems.
-
The lower part of this diagram shows how order processing is completed:
- In the past, the orders were processed by telemarketers over the phone. With the new Internet front end, the call center representatives simply log in to the new application on the commerce server and access any submitted, but unfulfilled, orders on the database node.
- On behalf of the online shopper, the call center representatives submit the unfulfilled orders to the back-end order processing systems. These systems send e-mails to the shoppers, confirming their orders and providing information such as delivery dates. Online shoppers, while interacting with the system, are unaware of factors such as delivery dates or out-of-stock items. This is a major drawback of this solution design.
Reasons for this approach:
- Fast time to market, 2-3 months, was critical to this client.
- A process for customers to order over the phone was already in place.
- The back-end order processing systems offered no interactive interface for the commerce server front end to use for direct online access.
- The back-end order processing systems did not provide the "24x7" hours of operation demanded by Internet shoppers.
- The volume of orders was not expected to be large initially, so they believed they could handle the load manually. This approach provided a quicker time-to-market than that required by integrating directly with the back-end systems. The retailer expected lower volume due to the nature of their sales: primarily big ticket items such as refrigerators, not high-volume items such as pairs of socks.
Obviously, the retailer intends to expand usage and include many more items. With augmented advertising of the site, the retailer expects sales volume to increase dramatically and faces a pressing need to provide a less manual approach to the order processing back-end systems. This site will evolve over time into one that more closely resembles an Enterprise-out approach, by including automated interfaces to order processing either in batch or directly online.