Skip to main content

Electronic Commerce::Enterprise-out application pattern::Product mappings=Linux for zSeries

Overview

This page provides example product mappings for the previous Runtime pattern using Linux for zSeries-based nodes for front-end shopping functionality. It illustrates the Linux for zSeries platform software product names and versions typically used with an implementation featuring WebSphere® Commerce Suite.

Enterprise-out::Product mapping=Linux for zSeries

Enterprise-out::Product mapping=Linux for zSeries Content Creation and Management Domain Firewall Dispatcher Protocol Firewall Database Application Application Application Commerce Server Retail Customer Intergration Systems Management Security Directory
(where supported, e.g. WebSphere Commerce Suite V5.1)
(Click a node to get a detailed explanation.)

Linux for zSeries might provide the lowest incremental cost e-commerce solutions for medium to large businesses and institutions. Customers choose Linux for zSeries for the following reasons, some of which might be subjective:

A Linux for zSeries e-commerce implementation also works within a parallel sysplex configuration with full "data sharing" of data stored in DB2. A 2216 network switch and the integrated e-network dispatcher technology enable incoming Internet requests for service to be spread across servers in the parallel sysplex environment.

In the department store example, the company physically implemented their solution based on WebSphere Commerce Suite, using primarily the Linux for zSeries product set. This let them use their existing skills in Linux for zSeries.

What's Next

Next, Review guidelines and related links or review another product mapping:

Content Creation and Management Node

This node represents the functionality supporting the creation of the data that resides on the Database Server and Commerce Server Nodes. It also represents the function to manage and stage that data into production on the servers. The functionality of this node is quite broad, and might be thought of as encompassing an entire subsystem.

The timely synchronization of several Web Servers is sometimes achieved by using a Shared File System as the content storage, capitalizing on the replication capability of this technology.

Domain firewall node

Firewalls provide services that can be used to control access from a less trusted network to a more trusted network. Traditional implementations of firewall services include:

  • Screening routers (the protocol firewall in this design)
  • Application gateways (the domain firewall)

The two firewall nodes provide increasing levels of protection at the expense of increasing computing resource requirements. The protocol firewall is typically implemented as an IP router, while the domain firewall is a dedicated server node.

Additional Resources

  • (in English) ESS

Network dispatcher node

The load balancer, or dispatcher, node provides horizontal scalability by dispatching HTTP requests among several, identically configured Web servers.

See Also

Additional Resources

  • (in English) ESS

Protocol Firewall Node

Firewalls provide services that can be used to control access from a less trusted network to a more trusted network. Traditional implementations of firewall services include:

  • Screening routers (the protocol firewall in this design)
  • Application gateways (the domain firewall)

The two firewall nodes provide increasing levels of protection at the expense of increasing computing resource requirements. The protocol firewall is typically implemented as an IP router, while the domain firewall is a dedicated server node.

Additional Resources

  • (in English) ESS

S/390 Database Server Node

Database Server node - DB2 Universal Database for S/390 provides an integrated relational database system that provides an ideal location for all of the data required in an e-Commerce site (products, categories, customers, merchants, and so on). The database server node must be in the same partition as the Commerce Server.

Application node

Existing applications are run and maintained on nodes that are installed in the internal network. These applications provide for business logic that uses data maintained in the internal network. The number and topology of these existing application and data nodes is dependent on the particular configuration used by these legacy systems.

Commerce server node

This node provides the infrastructure for application logic and can be part of a commerce server node. It is capable of running both presentation and business logic.

Retail Customer Node

This Node is a personal computing device, such as a PC, supporting a commercial browser (e.g. Netscape Navigator or Internet Explorer). The level of the browser is expected to support SSL and some level of DHTML. Most online buying implementations will send a "Cookie" to the browser on this node in order to maintain the shopping session. The cookie will contain a session id, which can be used to reconnect with a partially filled shopping basket or order and to re-establish the conversation for each interaction.

Integration Server Node

The purpose of this node is to interface between any front end access channel, such as the web, a call center, or a client/server ("fat client") PC, and whatever back-end application system is needed (including applications from other companies). It will perform the following kinds of services:

  • Convert protocols from the front end to match whatever the back-end systems understand
  • Decompose a single message from the front end (such as a web server) into several back-end messages (or transactions), and then re-compose the replies
  • Navigate from the front end to whatever back-end system needs to be accessed
  • In more complex cases, control the process or unit of work for a number of back-end interactions based on a request from the front end

The intent is to relieve each front end from having to handle the complexity of interfacing with potentially multiple back-end systems, which may be in different companies. The front end (such as the web server should just need to send a message to the integration server and have it look after the interface.

A second purpose for locating these interface services on the Integration server concerns security. There is a firewall between the web server and the integration server and the web server need have no knowledge of all the back-end addresses. Many location do not want a server located in the DMZ to have access directly to sensitive data and systems. In this case the web server can only send messages to the integration server, nowhere else.

Systems Management Node

This node is a logical representation of the functions required to manage all the nodes and components in the system, including the management of problems, changes, performance, configuration of assets, and others.

There are usually two aspects to systems management:

  • A managing aspect (with server components running on one or more systems management servers)
  • A managed aspect (with systems management client components running on every node in the system)

For example, there should be client components running on every node, which are able to accept and install changes sent from a change management server. The changes may be either pulled from the client on demand, or pushed from the server with centralized control. On critical nodes, there may also be problem management components that send a "heartbeat" back to a central monitoring site. If a heartbeat is missed, the managing site raises an alert.

It is important to remember that there is not only a server side but also a client side to systems management. The client side needs to reside on all nodes in the system. The one exception would be unmanaged workstations of the general public or of other business partners. In these cases, a particular organization would have no control and limited ability to provide systems management.

Security Node

This node is a logical representation of the functions needed to manage the security of a system. It works in conjunction with the Directory Node. Think of the directory as the repository that holds:

  • Data about security such as user IDs and associated passwords, or digital certificates (used to authenticate a user)
  • Lists of services that a user is authorized to perform (authorization or access control)

Think of the security node as holding the set of components that define the decisions to be made. The node may perform the actual security processing; for example, verify certificates. The authentication in most current designs validates the access to the Web Application Server, but it can also authenticate the access to the Database Server.

The security domain describes the components needed to implement the technical dimension of security and how these components interact to implement the technical aspects of a security policy.

The components that implement security are distributed throughout the network. It's unlikely there's a node in the system that does not include some components implementing some aspect of security. The Security Node represents centralized services that support security on other nodes.

The treatment of security combines network design for security with a particular emphasis on achieving a secure implementation of Internet and Intranet network access. Security is built by use of the following security services:

  • Confidentiality: providing privacy by protecting sensitive information from access unless authorized
  • Identification and Authentication: identifying entities, verifying their identities, and assuring individual accountability
  • Access Control: providing mechanisms for granting access to authorized and authenticated users
  • Data Integrity: providing detection of the unauthorized modification of data
  • Non Repudiation: assuring that any transaction that takes place can subsequently be proved to have taken place (also called accountability)
  • Isolation: providing protection by isolating a resource and therefore restricting potential access to it
  • Audit: monitoring and review of security-relevant events

Together these services must provide end-to-end security, integrating security facilities across heterogeneous environments.

Directory Node

Directory Services provides an integrated LDAP server that easily integrates with other LDAP servers to provide for the directory needs of an e-business solution.

Parallel Sysplex

Parallel Sysplex is a term that refers to the ability of an IBM System/390 hardware environment running MVS to operate multiple copies of the system platforms as if they were one large single image