e-Marketplace composite pattern: Runtime pattern

In an e-Marketplace, the available Runtime pattern depends largely on the integration requirements of the e-Marketplace participants identified by the Application pattern. For example, a relatively advanced e-Marketplace can provide automated real-time integration and delivery of product and catalog data from each of the suppliers in the e-Marketplace. This data would then be aggregated into the hub’s catalog, ready for buyers to purchase those products immediately in the e-Marketplace.

e-Marketplace runtime patterns often combine the infrastructures of both the e-commerce and integration architectures. Because an e-Marketplace has potential interactions with multiple buyers and sellers, you must consider Runtime patterns that address the integration requirements of these participants, even if integration of buyers and suppliers is not scheduled to be implemented immediately.

Emerging basic Runtime pattern

This Runtime pattern, and its associated variation, are still an emerging pattern, although they are based on a proven Electronic Commerce Runtime pattern. They are being reverified as more implementations are completed and cataloged. These solution designs represent the core functionalities generally considered the foundation of an e-Marketplace. It is important to note that the additional subsets presented later all inherit and extend from this foundation.

The basic Runtime pattern shown above is commonly implemented as the foundation for e-commerce sites and is usually extended in line with the load and functionality requirements of the site.

In this Runtime pattern, the Web server and the application server are combined to form the Commerce Server node residing within the demilitarized zone (DMZ). This is separated by a protocol firewall to the outside world and a domain firewall to protect the directory services and primary data repository. Most of the application logic is executed on the Commerce Server node under the application server and served to the client through the Web server.

While this Runtime pattern is simple to implement, its limitations include:

• Limited availability and failover capability.
• No support for horizontal scalability because it uses only one application server.
• Limited vertical scalability options. However, additional processing power and memory can assist in this area.
• Security for the application server applications is limited to that provided by the protocol firewall. While this is often acceptable for static HTML content residing on the Web server, it is generally inappropriate for securing critical applications.
• The number of simultaneous connections to the Web server is restricted to its capacity.

Emerging basic Runtime pattern variation

The basic Runtime pattern variation shown above increases the number of simultaneous client connections by adding to the number of application and Web servers available within the commerce server node. A load balancer is also introduced to distribute incoming requests to the most appropriate (determined by a particular algorithm) Web or application server. This approach provides increased failover capabilities and the ability to scale horizontally by adding Web and application servers.

While this Runtime pattern variation improves the availability and performance offered by the basic Runtime pattern, it still has a number of potential problems. The primary issue lies in the lack of separation between the Web server and the application server. A common resolution to this is to place the application server behind the domain firewall, where it benefits from the extra security provided by the firewall. Be aware that adding Web and application servers provides limited performance gains that are largely dependent on the workloads of back-end resources and other subsystems.

e-Marketplace runtime pattern subsets

The following subsets 1,2, and 3, reflect additional enhancements to the basic Runtime pattern. Each of these subsets relates to the correspondingly numbered phases discussed earlier.

The subsets include additional nodes specific to the e-Marketplaces. These designs do not implement the variation runtime pattern. However, this can be implemented if required. Starting with a simple, Web-integrated e-Marketplace in subset 1, you can progress to a fully integrated e-Marketplace in subset 3, which features real-time, automated integration of both buyers and suppliers.

Subset 1 - Web integrated e-Marketplace

The Web integrated e-Marketplace provides the simplest Runtime pattern for an e-Marketplace implementation. This design provides for the integration of suppliers and buyers using a Web interface only. For suppliers, this Runtime pattern means manual data exchange with the e-Marketplace using eXtensible Mark-up Language (XML) scripts or HTML data entry. The obvious benefit of this model is that suppliers can participate in the e-Marketplace without developing applications or employing middleware services.

The buying process

In this subset, the process for buying from the online catalog follows these steps:

1. The buyer logs into the commerce server through the main entry page. If the user is registered with the e-Marketplace, a user profile is gathered based on information contained on the database server.
2. The personalization engine in the commerce server presents the buyer with a personalized view of the catalog and other services offered in the e-Marketplace.
3. The buyer interacts with the site through the static and dynamic pages provided by the site.
4. Items of interest to the buyer are added to the buyer’s shopping cart. The database server maintains this information in addition to persisting data required to manage the session state. A cookie is delivered to the buyer’s browser, allowing the commerce server to track the interactions with the site and to reestablish the connections to the shopping cart. Other product pricing options are available to the buyer. For example, the commerce server can provide other negotiation mechanisms such as RFQ, auctions, or exchange.
5. When the buyer purchases the shopping cart items, a purchase order is generated and stored by the commerce server and is subsequently made available to the appropriate suppliers.

The supplier process

1. Like the buyer, the supplier logs into the commerce server but is identified as a supplier through the supplier role.
2. The supplier can retrieve the purchase orders generated by the buyer through a Web interface by interacting with the commerce server. They could also respond to RFPs/RFQs at this point.
3. The supplier can provide catalog data for the e-Marketplace by interacting with the content management/aggregated catalog node, either through an interactive Web-based session or through a mass import of product data in XML format.

In this Runtime pattern, user authentication and security is provided by the directory and security services node. Additionally, encrypted transmissions are used to protect sensitive data such as the transmission of credit card numbers.

Subset 2 - e-Marketplace with supplier integration

The next evolution of the e-Marketplace introduces the supplier as an integrated node. This also introduces the delivery gateway node and the B2B gateway node.

These additional nodes provide automated integration of data between the supplier and the e-Marketplace. Generally, data fed back and forth between the e-Marketplace and the supplier is in an industry standard form such as XML documents.

Supplier integration is a key aspect of the e-Marketplace and provides, for example, the ability for suppliers to automatically update product data into the e-Marketplace as it becomes available.

In addition, it allow suppliers to:

• Receive RFPs, RFQs and purchase orders automatically by the commerce server
• Provide real-time inventory information to the e-Marketplace such as the quantity and availability of stocks
• Automatically receive order data and order status changes
• Integrate their business process with the e-Marketplace through the B2B gateway node and the associated delivery gateway node residing within the DMZ.

Subset 3- e-Marketplace with full integration

The third Runtime pattern builds on the previous two designs and introduces the buyer as an integrated node with the e-Marketplace. The buyer node lets buyer-side procurement systems integrate with the e-Marketplace for these interactions:

• Automatic order placement
• Automatic RFQ placement and notification of response
• Automatic buyer registration with the e-Marketplace

Again, the integration to the buyer's system is based on XML documents issued between the commerce server and the buyer’s procurement system.

This Runtime pattern is unaltered from subset 2, with the exception of and added buyer node as shown in the figure above.

Advanced Runtime pattern

The patterns and variations above may prove constraining for e-marketplaces that are very large or very sophisticated. For those marketplaces, some of the nodes in the pattern must be split into multiple nodes with expanded roles and new nodes will need to be introduced. In addition, some of the processing that is shown above in the DMZ should be moved behind the domain firewall. The marketplace characteristics that might drive the need for an advanced Runtime pattern include a combination of the following:

• Very large user and supplier membership and high usage levels
• Integrated supply chain services
• Advanced site management
• Virtual procurement capability
• Multilevel authorization schemes

Work is under way to document this advanced Runtime pattern. This site will be updated with its description at the time of its completion.

Next, review product mappings.