Electronic Commerce::Enterprise-out application pattern: Runtime patterns

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:

• Basic Runtime pattern
• Runtime Variation 1
• Runtime Variation 2
• Runtime Variation 3

Depending on the customer requirements, you might need to extend variations or combine them to achieve desired results.

Enterprise-out Overview

This is the preferred Electronic Commerce runtime pattern because it provides immediate confirmation of order completion, combined with other information such as shipping details and volume discount pricing. This Runtime pattern utilizes either a (preferred) synchronous or asynchronous connection to back end systems to provide online access to back end systems during checkout and order completion. Enterprise-out designs are based on the ESS Online Buying Reference Architecture. and represent a starting point for selling merchandise over the Web when integration with existing enterprise back-end systems is used to Web-enable existing commerce systems.

The following diagrams are composed of logical nodes that represent a collection or grouping of the major building blocks of the solution. Nodes are used by a lead architect to describe the design at a logical level. They contain a set of components that provide either infrastructure or application functionality. Examples of infrastructure components that could run on a commerce server node include Web servers, Java Virtual Machines, and TCP/IP stacks. Examples of application components that could reside on a commerce server node include HyperText Mark-up Language (HTML) pages, Java, and CGI programs developed by the programming team. Logical nodes map to product instantiations in our next step called "product mappings." In some cases the logical node maps one-to-one to a physical machine; however, this is not always the case. Multiple nodes can be mapped to one machine, or a single logical node can be spread across multiple physical machines.

Enterprise-out application pattern: Runtime pattern
(Click a node for more information.)

Enterprise-out basic online shopping process

1. From a Web browser client, the shopper connects to the commerce site by entering the Web site URL and does one of the following:
2. • 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
3. 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.
4. 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.
5. When the shopper wants to buy (or check out the shopping cart) one of two implementations is taken:
6. 1. An interaction is performed through the integration node to access the back-end application nodes (such as order processing, pricing, inventory, credit, and shipping) and immediately provide feedback to the shopper such as confirmations and delivery dates. This is the preferred approach.
   2. The less preferred approach is to store the submitted order on the database server for later submission using batch processing. Acknowledgment that the order has been submitted is sent back to the shopper from the commerce server to the Web browser. An e-mail confirmation of delivery, out of stock conditions, and credit problems is later sent by the back-end processing systems. From a user's viewpoint this approach lacks features such as immediate inventory validation, order completion, and estimated shipping details. From the company's viewpoint, this approach provides less direct control of order completion and shipping processes. This approach is similar to the Web-up approach, except that it provides more automated linkage to the batch processes.

Typically, the logon process uses registration data on the database node to identify registered shoppers and encryption technology, such as Secure Socket Layers (SSL), to protect sensitive transmissions (for example, credit card or address information).

Currently, most sites do not use digital certificates. This Runtime pattern includes directory and security nodes, indicating that the use of technologies such as Lightweight Directory Access Protocol (LDAP) directories and digital certificates is likely in the future. The content creation and management node represents the functions required to create and administer the data on the database and commerce server nodes.

The ESS Reference Architecture, used by IBM Global Services when delivering online buying projects, provides a much more detailed flow of how this process works and the way the infrastructure interacts. It also provides detailed descriptions of the nodes, including their functions and infrastructure components. The ESS Reference Architecture provides information required to obtain vendor quotes for products necessary to physically implement the logical Runtime pattern.

Enterprise-out application pattern: Runtime pattern - Variation 1
(where supported, e.g. WebSphere Commerce Suite V5.1)
(Click a node for more information.)

Enterprise-out application pattern: Runtime pattern - Variation 2
Though created for the Electronic Commerce::Web-up application pattern, Variation 2 might prove useful for an enterprise establishing an Enterprise-out solution, because it can provide enhanced load balancing and availability functionality through the use of a duplexed web server and commerce application server. To review this design, visit Web-up Variation 2.

Enterprise-out application pattern: Runtime pattern - Variation 3

Each project team might need to modify the basic node diagram of how the logical architecture works to accommodate individual client requirements. This variation shows the modifications to produce a client-specific diagram for a major site.

The outsourced commerce front end in this example is connected using a synchronous link to in-house back end order processing systems. The previous example follows a major clothing retailer that wants to expand their sales to the Web. The company intends to outsource the Web front end to the IBM Universal Server Farm and have the back end reside on the company's host systems in their data center. The IBM Universal Server Farm refers to a set of outsourcing sites run by IBM. Server technology from multiple vendors is operated by IBM on behalf of organizations that would rather not manage their own server operations. Frequently in online buying sites, the nodes in the Demilitarized Zone (DMZ) front end and the database server node are outsourced. These are then networked to the company's own data center for back-end order processing.

The reasons for implementing their Web channel with the Enterprise-out runtime pattern variation are discussed below in "Reasons for architectural approach." This approach is quite close to the basic Runtime pattern, but differs in the following ways:

• The front end commerce site is outsourced and hosted at the IBM Universal Server Farm.
• The back end resides at the company's in-house data center. Modification here includes communication between the DMZ and the internal network taking place over the Internet using a secure connection between two firewalls (firewalls 4 and 5). This also implies TCP/IP communication to the back end.
• The retailer chose the preferred approach of linking to the back end order entry systems in a synchronous and online manner. The reasons for this are listed below in "Reasons for architectural approach."
• A separate batch link exists for publishing and maintaining data that is necessary for administration of the site.

Reasons for architectural approach:

The company had a mandatory business requirement that users have immediate confirmation of orders with shipping, discounts, and pricing information. This data was to be provided through the back end order processing systems. The company was providing immediate confirmation of call center orders and did not want less functionality for its Web customers. The company needed to support the existing call center. The back end systems were already in place with server interfaces and sufficient hours of operation. It was relatively easy to use the same interfaces to support Internet access.

Next, review product mappings.