WebSphere® Commerce 5.4 is a highly scalable and flexible e-business application server that runs on WebSphere Application Server 4.0. This article describes the distributed configuration of WebSphere Commerce and its ability to function with various operating systems, databases, and Web servers. We show that a 3-tier topology is the best topology for enhancing system performance and security. You can expand the capacity of each of the three tiers by horizontal cloning and multiple Web server configuration. To increase the utilization of hardware resources of a node, you can use vertical cloning. Multi-instancing is a good strategy to host multiple e-commerce sites on a single system. If you use a distributed configuration, you can use firewalls, single sign-on capabilities, and reverse proxy to enhance the security and performance of your e-commerce system.
Overview of WebSphere Commerce
WebSphere Commerce contains a highly customizable e-commerce infrastructure. It is a set of integrated software components that run on WebSphere Application Server.
The latest release of WebSphere Commerce has many outstanding functions and features:
- Built-in B2B and B2C models
- Catalog and storefront creation and management
- Order and negotiation management
- Member management and system security
- Multi-lingual and multi-currency support
- Secure electronic payment processing
WebSphere Commerce supports the following:
- Operating systems: AIX®, Solaris, Windows® 2000, and Windows NT®
- Databases: DB2® or Oracle 8i
- Web servers: IBM HTTP Server, iPlanet Web Server, Lotus® Domino™ Server, and Internet Information Server
In addition, WebSphere Commerce is available for the iSeries™, zSeries™, and Linux platforms. This article discusses the distributed configuration of WebSphere Commerce on AIX, Solaris, Windows 2000, and Windows NT.
Figure 1. WebSphere Commerce software stack
WebSphere Commerce supports a multi-tier topology. In this topology, the database server and the Web server exist on nodes remote to the WebSphere Commerce server. In this article, 2-tier refers to a topology in which the database is on a remote node, and 3-tier if both the database server and the Web server are on two separate remote nodes.
The WebSphere Commerce application server supports cloning. Vertical cloning refers to a topology in which identical application servers exist on the same node. Horizontal cloning refers to a topology in which identical application servers exist on different nodes.
In addition, WebSphere Commerce supports multi-instancing. In this configuration, independent application servers run on the same node.
WebSphere Commerce can use the workload management capabilities of a WebSphere Application Server to communicate simultaneously with several Web servers. This allows scaling on the Web server tier.
We looked at many scenarios involving a distributed configuration of WebSphere Commerce. We used various combinations of the following components and strategies:
- Operating system: AIX, Solaris, Windows 2000, Windows NT
- Database: DB2, Oracle 8i
- Web server: IBM HTTP Server, iPlanet Web Server, Lotus Domino Server, Internet Information Server
- Multi-tier topology: 1-tier, 2-tier, 3-tier
- Cloning: vertical cloning, horizontal cloning
- Multi-instancing
- Web server clustering
- Firewalls
For each scenario or combination of scenarios, the following testing steps were performed:
- Installed and configured WebSphere Application Server 4.0.2, a database, and a Web server.
- Installed and configured WebSphere Commerce.
- Installed and configured WebSphere Payment Manager 3.1.2
- Created a WebSphere Commerce instance.
- Created a store archive file and published a Store Model from Store Services.
- Completed shopping flow on the Store Model.
- Performed uninstallation.
- Developed and reviewed product documentation.
A single-tier topology is the simplest configuration of WebSphere Commerce. In this configuration, the Web server, commerce server, WebSphere Payment Manager server, and database server are all installed on the same node (that is, on the same physical machine in a network). A minimum amount of manual configuration is required. On Windows 2000 and Windows NT, you can install the IBM DB2 and IBM HTTP Server with WebSphere Commerce automatically under umbrella installation.
The single-tier topology has potential performance and security issues. For instance, in this topology all four servers compete for the resources of a single machine at run time. Consequently, you cannot optimize the node's performance for all the servers. Because the Web server is on the same node as the other three servers, Internet users could conceivably gain access to everything on the node. As a result of these concerns, a single-tier topology is not the ideal topology to use in a production environment.
In a 2-tier topology, the database server runs on a node separate from the Web server and the WebSphere Commerce application server. To improve security, you can place the database server on a trusted network behind a firewall (for example, on an Intranet). Because the database server runs on its own machine, you can tune the machine for maximum performance of the database. In this topology, the database does not compete for resources with the WebSphere Commerce application server. Both performance and data security are improved in this topology.
Figure 2. 2-tier topology
In the 3-tier topology of WebSphere Commerce, the database server, Web server, and WebSphere Commerce application server run on separate machines. Both the database server node and the commerce server node are placed behind one or more firewalls. The most popular configuration is one firewall in front of the Web server node, and the other between the Web server node and the WebSphere Commerce server node. The Web server is placed in a demilitarized zone (DMZ). Each machine supports a single server, allowing you to tune the machines supporting the Web server, WebSphere Commerce application server, and database for best performance. The three servers do not compete with each other for resources. Consequently, the 3-tier topology is more flexible and secure than a 2-tier topology.
Figure 3. 3-tier topology
To increase the capacity of the commerce server tier, add additional nodes to an existing WebSphere Commerce configuration. You can install identical WebSphere Commerce application servers on multiple nodes in the same WebSphere Application Server administrative domain. This is called horizontal cloning. Each WebSphere Commerce application server has its own Java virtual machine (JVM). Horizontal cloning is typically used in 3-tier topology.
Horizontal clones share the same WebSphere Application Server database and the same store database. In addition, each clone shares the same Web server, payment server, and payment database. Only the WebSphere Commerce application server is cloned. At runtime, incoming requests are distributed among the WebSphere Commerce application servers in the cluster by the WebSphere plugin for the Web server. If a WebSphere Commerce application server goes down, new requests are dispatched to any WebSphere Commerce application servers that are still running. The sessions of the stopped server are taken over automatically by others that are running. When the WebSphere Commerce application server goes back online, it automatically shares the workload with the other WebSphere Commerce application servers in the cluster. Horizontal cloning groups multiple commerce application servers on different physical nodes into a single logical commerce application server that runs all the time.
Figure 4. Horizontal cloning
Legend: WAS - WebSphere Application Server database
WC - WebSphere Commerce store database
Horizontal cloning has many advantages. First, horizontal cloning can increase the throughput of the commerce application server tier by adding additional hardware. The workload is distributed among the commerce application servers. Second, the failover of a subset of commerce application servers does not halt the entire system. The e-commerce site is available all the time and interactions between Internet users and the e-commerce site are not disrupted.
In contrast to horizontal cloning, you can use vertical cloning if the node that the WebSphere Commerce application server resides on has extra resources; for example, extra memory or symmetric multiple processing power. Vertical cloning is not dependent on the topology of WebSphere Commerce. This article discusses vertical cloning in a 3-tier topology only.
In our model, identical WebSphere Commerce application servers are added onto the same node. These commerce application servers are vertical clones. Each application server runs on a separate JVM. Vertical cloning adds multiple JVMs to the same node. Each JVM uses a separate piece of memory, and a portion of symmetric multiprocessor (SMP) capability. In this configuration, hardware resources are used most effectively.
Similar to horizontal clones, vertical clones share the same WebSphere Application Server database and the same store database. In addition, they share the same Web server, payment server, and payment database. Only the WebSphere Commerce application server is cloned. At run time, incoming requests are distributed among the vertical clones on the node. If a vertical clone is turned off, new requests are dispatched to other vertical clones that are running. The sessions are automatically transferred to the other clones. When the vertical clone is started again, it shares the workload with the other vertical clones on the same node automatically. Vertical cloning groups multiple commerce application servers on the same node into a single logical commerce application server and expands the logical commerce server to the full capacity of the physical machine.
Figure 5. Vertical cloning
Legend: WAS - WebSphere Application Server database
WC - WebSphere Commerce store database
There are advantages to vertical cloning. First, vertical cloning can increase throughput to fully utilize the hardware resources on the node. As a result, the machine's memory and SMP, for example, are used more effectively. Second, vertical cloning provides failover protection in the sense that the entire system is still running when a subset of vertical clones are stopped.
Different commerce application servers running on the same node are called multi-instances. WebSphere Commerce supports the configuration of multi-instances. Each instance has its own JVM. Multi-instancing does not depend on the topology of WebSphere Commerce. In this article, multi-instances are discussed in relation to a 3-tier topology.
Unlike a vertical clone, each instance uses its own store database. Like a clone, each instance shares the WebSphere Application Server database with the other instances. In addition, the instances can share the same Web server. If they share the same Web server, the Web server must support multiple identities (that is, multiple host name and IP address pairs). Each WebSphere Commerce instance must have its own Web server identity. In addition, each instance must have its own payment application server, only one of which can reside on the same node as the commerce application servers. Instances run independently. There is no workload or information sharing. Multi-instancing splits one physical node into multiple independent logical nodes.
Figure 6. Multi-instances
Legend: WAS - WebSphere Application Server database
WC1 - WebSphere Commerce store database 1
WC2 - WebSphere Commerce store database 2
Multi-instancing has unique benefits. First, you can use multiple instances to host several independent e-commerce sites on the same node, one instance for each site. This is a preferred option for e-commerce service providers. Second, you can use multi-instancing to support staging. You can use one instance as the production server, the other as the staging server. Development can continue while the e-commerce site is running. When testing is complete, data assets are simply propagated onto the production server. The staging server is used for the next development cycle. There is virtually no disruption to the continuous running of the e-commerce site. The development is completed in the production environment so there are fewer surprises in the new release of the e-commerce site. This is a very useful feature for maintaining and updating an e-commerce site.
If a commerce server tier is the bottle neck that restricts throughput, horizontal cloning and vertical cloning are the perfect solution to this problem. In addition, the capacity and availability of the Web server tier can affect the entire system. WebSphere Commerce uses the capability of WebSphere Application Server workload management to handle multiple Web servers.
Similar to horizontal cloning, you can add multiple Web servers to the system to form a Web server cluster. WebSphere Commerce can communicate with multiple Web servers simultaneously. You can use products, such as IBM Network Dispatcher, a component of WebSphere Edge Server, to forward inbound requests to the Web servers.
The IBM Network Dispatcher and Web servers share a common cluster address. Web servers get requests from the network dispatcher instead of directly from the Internet. The Web servers forward requests to, and get responses from, the WebSphere Commerce application server. Web servers send responses from the commerce application server back to the Internet directly. If a subset of Web servers becomes unavailable, the new requests are directed by the network dispatcher to the running Web servers. As a result, the whole system is still available. When the failed Web servers are back online, the network dispatcher automatically shares the workload with the other Web servers. Multiple Web servers and the network dispatcher form a single logical Web server that runs all the time.
Figure 7. Web server clustering
Similar to horizontal cloning, there are advantages using Web server clustering. First, it can increase throughput of the Web server tier. The workload is balanced among the Web servers by the network dispatcher. Second, the failover of a subset of Web servers does not halt the entire system. The availability of the e-commerce site is maximized.
It is worth mentioning that the IBM Network Dispatcher does not become the new source of single point failure when a standby server is running to maximize the availability of the network dispatcher. Another solution is to configure multiple network dispatchers to backup each other.
The IBM Network Dispatcher does not become a performance bottleneck. The network dispatcher does not set up the TCP/IP connection for HTTP response to the client on the Internet. The connection is established directly between a Web server and the browser. The bandwidth of HTTP request is usually much smaller, comparing with that of the HTTP response. Request dispatching and load balancing are completed by forwarding packets at the kernel level. A detailed discussion on the network dispatcher is beyond the scope of this article.
The central idea of the distributed configuration is that scaling improves performance, availability, and security of WebSphere Commerce. This article discusses multi-tier topology, scaling on the commerce server tier (that is, horizontal cloning and vertical cloning), scaling on the Web server tier with multiple Web servers and the IBM Network Dispatcher, and multi-instancing.
You can combine the options of the distributed configurations to build an enterprise configuration. The network dispatcher provides a common interface on the Internet to all Web servers. Incoming traffic is balanced among multiple Web servers, each of which in turn, balances the load among multiple commerce application servers. On each commerce server node, there are multiple instances or vertical clones. Data is stored in the backend databases. Firewalls are plugged in, one in front of the network dispatcher, and one between the Web servers and the commerce servers. In addition, there is a standby network dispatcher and a database server.
Scaling on the database tier is possible. WebSphere Commerce considers the database as one logical database. The physical configuration of the database tier has no impact on the configuration or behavior of the commerce application servers. To ensure high availability, you can configure a standby database to mirror the working database. If the main database fails, then the standby database takes over to serve the data. IBM DB2 on AIX can use a feature called high availability cluster multiprocessing (HACMP) for this purpose. A discussion of the configuration of the database is beyond the scope of this article.
Figure 8. Enterprise configuration
As an example of enterprise configuration, stress and reliability testing was performed on a 3-tier setup with three horizontal clones. One Web server node, three commerce server nodes, and one database server node were used. The operating system was Windows 2000. Microsoft IIS was used as the Web server. WebSphere Payment Manager 3.1.2 was installed on one of the commerce server nodes. IBM DB2 7.2 was used as the database server. A significant increase of concurrency and completion of scenarios on both B2B and B2C store models were observed.
WebSphere Commerce is a highly scalable and flexible product. It supports remote Web server and remote database topologies. Additional nodes with Web server clustering and horizontal cloning allow scalable Web server and commerce server tiers. You can use vertical cloning to ensure full utilization of hardware resources. You can also use multi-instancing to host multiple e-commerce sites or for staging. Firewalls and the network dispatcher provide additional security and scalability.
The authors would like to thank Les Komaromy, Reshma Ramgoolam, Jeffrey Coveyduc, Kate Price, Mike Hume, Maurus Cappa, and Mark Stankevicius for their comments and suggestions in preparing this article.
-
IBM WebSphere V4.0 Advanced Edition Scalability
-
IBM WebSphere Commerce Install Guide for use with a DB2 Universal Database Version 5.4
-
IBM WebSphere Commerce Install Guide for use with an Oracle Database Version 5.4
-
IBM WebSphere Commerce Fundamentals Version 5.4
David Y. Yuan is a Software Engineer in e-Commerce Development at the IBM Toronto Lab in Toronto, Ontario.
Mark D. Ho is a Staff Software Engineer in e-Commerce Development at the IBM Toronto Lab in Toronto, Ontario.
Rick Stroebel is a Software Engineer in e-Commerce Development at the IBM Toronto Lab in Toronto, Ontario.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
