Overview of Topologies

Now that we have seen the WebSphere server components up close and how they work together, let's now apply these elements to three common WebSphere topologies.

Single-Server Scenarios

The simplest and most prevalent topology in which WebSphere is used is the single-server topology. This includes a single, stand-alone, independent application server instance. This topology shows up in a number of cases, including:

• A developer desktop where you need an instance in which to test or assemble application components, or to experiment with the application server to understand how a particular feature works before incorporating that into an application

• Individuals who want to try out the application server, perhaps to compare it other competitive application servers

• Engineers involved in integration activities – responsible for combing application components to form a progressively more complete application

• Small businesses or lines of business within a larger enterprise, needing only the capacity of a single application server for their business needs

  Important

  The objective of the single-server topology is simple: to get you up and running with as little effort as possible. It is the fastest path to getting your first application up and running.

A common and important variation on this topology is where multiple application servers are executed on the same machine, but independent of each other. We treat this as equivalent to the single-server topology. It is expected that each server instance will be managed independently, often by separate administrators who often double as the owner or user of the app server.

In this topology, everything is administered through an independent configuration file and through direct communication with the application server for operations management function. WebSphere does not impose a dependency on a secondary process for managing the application server in the standalone, single-server topology.

If more than a single-server is operated on a given node, then each server should have its own independent configuration file – independently describing what applications will be hosted on that server instance, what resources will be used by that application server, and so on. There is no attempt to mediate shared resources between the application servers when they are operated as stand-alone servers.

In this topology, configuration is performed by editing the XML files that define the configuration of that server. To perform operations management, the methods on the JMX MBean server, embedded in the application server, are invoked (at least for everything but physically starting the application server process). Both of these are augmented by an Admin application that can be configured to run in the application server – essentially the same 'thin client' administration application used for other scenarios, but by virtue of the configuration confined to operate solely on the application server that it resides on. As an alternative, this same Admin application can be pointed to the configuration of another application server – to edit the configuration file of that server. However, there is no prior knowledge of that other application server.

This is the standard setup you get when you install WebSphere straight out of the box. You get a single app server and basic command-line tools for installing and configuring applications. During installation you specify names for both the app server and the node of which it is a part.

The following diagram depicts the single-server configuration:

The chief benefit of the single-server topology is that it is easy to set up. It is autonomous, because you administer it directly and by itself. It is the perfect configuration for exploration, development, or entry-level application hosting for a small business or department. This configuration is not sufficient for larger deployments that have application workloads too big for a single-server. This could be from either the number of applications in use or the number of users of those applications or both. Either way, multiple app servers are probably required. These may be installed on the same physical hardware, if that machine offers enough processing power and storage to host the workload.

The alternative is to install app servers on multiple machines, providing increased computational resources. Multiple computers also provide increased availability in case of a system failure. The following diagram depicts these two different approaches:

The downside to just adding more app servers is that as the number of app servers increases, it becomes inconvenient and awkward to administer each app server separately – a single point of administration is much more effective as the number of app servers grows. The following section will explore multi-server topologies and centralized administration in greater detail.

Multi-Server Scenarios

As we saw at the end of the last section, you can throw more and more servers at your workload and application portfolio to increase computing capacity and availability; however, that alone is not the approach we recommend for managing multi-server topologies. Central administration is critical to multi-server configurations, and is the reason for organizing app servers into a WebSphere cell. In a cell configuration, all app servers can be administered from a single point of control. Let's look at some typical multi-server scenarios.

Branch Offices

A number of large enterprises are organized around using branches as outlets for their business – bringing their business to the people. Branches tend to look very much like small businesses, requiring their own local computing resources both to reduce latency for high volume functions, and to enable continued business operations when communication to the central organization is cut off temporarily.

These businesses want to install application servers in their respective branch offices to provide local application functions. However, branch offices cannot afford local IT skills – they must completely rely on central operations to manage their IT assets. Further, since the premise of branch computing is to reach a geographically dispersed clientele, those same scales of geography also inhibit the central operations organization from traveling to the branch to provide on-site support. All aspects of administering the branch office systems must be performed remotely. This includes software distribution and installation, configuration and execution control, backup and recovery procedures, and so on.

In addition, the branch must remain autonomous, managing itself automatically when communication with the central operations is cut off temporarily. Fortunately, business procedures in branch offices are not highly dynamic – they do not require massive reconfiguration on an hourly or even daily basis. Any dynamic nature in business processes for these staid bricks-and-mortar institutions is generally measured in weeks or months, often coupled with training for the humans involved in the business process.

Peak workloads can vary throughout the day, or under special economic circumstances. However, these peaks are often moderated by the physical capacity of the branch facilities. In other words, since electronically generated transactions typically bypass the branch and are routed directly to the central operations center, the branch is only involved in transactions that are manually brokered by an agent in the branch.

For example, bank branches only process as many transactions as their tellers are able to handle. Since the branch-based business model generally involves a large ratio of branch offices to central operations, the cost of computing dedicated to each branch ends up being multiplied by the number of branches. There is no pro-rating of shared resources for anything that has to be installed and dedicated to a particular branch. Consequently, the economic model for branch computing is to keep the cost of computing in each branch as small as possible. For example, the computing hardware has very little excess capacity, and companies are generally willing to compromise redundancy to keep their operational costs low.

A vanilla branch configuration will involve a small number (between one and five) of application servers running on one server node. Generally, there is no clustering support used in the branch. The applications used in the branch are designed both to collaborate with centralized applications, and to work off-line. Likewise, the system management facilities must both collaborate with the centralized operations center, enabling full remote control, and be able to continue to work autonomously in off-line mode – being able to re-synchronize themselves automatically when they return to on-line processing.

A small to medium sized community or regional enterprise may consist, typically, of five to fifty branch offices. Each branch typically will have its own app server to provide local access for availability and performance. These app servers will be organized into a cell and centrally administered through a Deployment Manager, running at a central location. All administration for applications and servers is orchestrated from the central location. The following diagram depicts such a configuration, involving three branch offices and a Deployment Manager owned by central IT:

Departmental or Workgroup

Departmental or workgroup computing represents the majority of production topologies in use today. This scenario can exist in both large and small enterprises. Generally it is characterized by a setup that is dedicated to one or a small number of highly related applications all based on the WebSphere runtime. For this reason, the environment is relatively homogenous. In general, any backend systems required by these applications are hosted on other systems, outside the WebSphere cell. They are not subject to management by the WebSphere system management facilities (other than to create bindings to those systems), nor impinging on the computing capacity dedicated for use by WebSphere-based application components.

The departmental or workgroup topology typically involves multiple nodes, or a single high capacity, multi-processor node. Workload across these nodes needs to be balanced. But workload does not need to be balanced against an arbitrary set of general-purpose applications residing on a range of different middleware technologies. Consequently, workload can be balanced against a relatively limited set of variables, mostly stemming from client-generated demand. In this topology, it is often as accurate to base workload balancing decisions on a prior knowledge of the capacity of the nodes as anything else.

This topology may involve from one to twenty nodes, one Deployment Manager, and one Node Agent per node in the cell. The workgroup or departmental topology is administered through a single logical image of the entire workgroup hosted in a Deployment Manager. In many cases, multiple application servers running on the same physical computer can satisfy departmental or workgroup computing, so long as it is sufficiently large. The following diagram depicts an app server workgroup configured and administered as a cell housed on a single large computer:

While not geographically dispersed, as in the case of the branch office, a department or workgroup configuration may also want to consider multiple computer systems for increased scale and availability.

Important

WebSphere cells can be organized into local or wide-area cells that can be centrally administered for consistency and increased control. However, clustering and firewall configurations must be added to deliver scalability and access.

Cell configurations are very helpful in consolidating administration and enabling business policies, such as security, to be applied consistently across all app servers within the same cell. Moreover, cells can be used to isolate one WebSphere configuration from another. There are limitations in these topologies, however. The need for increasing application scalability and availability is not naturally met by a group of individual servers – even when centrally administered. Furthermore, these topologies do not address the security and performance issues of applications serving on the Internet.

Scaling Up-and-Out – Enterprise Scenarios

Enterprise topology represents the extremes of cell scaling: vertically or horizontally.

Vertical scaling involves many application server instances – tens or hundreds – on a single logical or physical node. Horizontal scaling involves many nodes in a single cell, any of which may be a vertically scaled node.

You scale vertically to the extent you have sufficient compute-capacity on a single physical machine to support multiple app servers. High-end machines, such as IBM zSeries and pSeries, as well as certain machines made by Sun, and others, have sufficient computing resources to host large numbers of app servers. You still cluster horizontally for increased scale, but also for availability – if you lose one machine, you can still provide the application from another machine.

An enterprise topology will generally involve sharing computing resources between WebSphere-based applications, and applications based on other middleware – including strategic, legacy, proprietary, and standard technologies. Resource utilization must be balanced among all of the applications, based on workloads derived from a variety of sources. For example, an enterprise system may support WebSphere, CICS, SAP, TPF, and proprietary environments. Many different applications may be hosted on these systems supporting traditional 3270 clients, ATM networks and financial switches, APPN or MQ based messaging, IIOP or HTTP-based clients, and so on. The applications may be completely independent of each other, loosely coupled through MQ messaging, web services, or workflow management, or tightly coupled through interdependencies designed into the application.

The levels of scaling and additional execution complexity that represent the enterprise topology require additional features in system management that are not required for workgroup or departmental computing. In particular, clustering servers together for workload balance and availability, building firewall configurations, providing efficient access to application data across wide networks, and integrating EIS resources, are all required capabilities in these topologies.

Clustering

A WebSphere server cluster is a grouping of servers that are administered as individual servers, but represent themselves to application clients as a single logical server. As work is driven onto the server cluster, it is automatically, transparently, and seamlessly distributed across the bank of servers that compose the cluster. This distribution of incoming work requests in this manner is the basis for application scalability on WebSphere.

Note that not all applications can scale this way. Applications that are stateless or have managed affinity can run on a cluster. By "managed affinity" we mean a server affinity that is known to WebSphere, and thus can be managed by WebSphere – for example, a transaction or HTTP session. If an application is stateless, individual requests can be correctly executed on any app server in the cluster. If an application has an affinity, that generally means it has some temporal memory-based resource and must execute in the same process until the application no longer has that affinity. Applications can implicitly establish process affinity through use of transactions and HTTP sessions. WebSphere knows about these affinities and can route requests for such an application back to the correct app server based on the affinity. If an application has other affinities – those not know to WebSphere – such as opening a socket and reading data into memory, then this application cannot execute on a cluster.

Clustered servers can be configured on the same, or across different, network nodes (or machines), so not only can you increase scalability, you can also increase availability by having more servers available on more physical machines. The outage of an individual server or machine does not represent an outage of the application served by the cluster.

True to the WebSphere philosophy, you can organize, spread, and group your servers to meet your specific scale and availability requirements. The following diagram depicts some of these options in effect:

The benefits of clustering are significant:

• First, it presents a single logical server to your application clients, freeing them from awareness of the physical topology of your WebSphere cell. For example, the application clients find logical clusters in the namespace – not individual servers.

• Second, because clients operate on logical – not physical – definitions, this frees your IT organization from reconfiguring physical resources as requirements and availability dictate. This means that additional servers can be added to or removed from to a cluster without awareness by, or impact on, your application clients.

• Third, your application clients are insulated from server failure. The cluster – and the applications deployed on it – remain available to your clients even if individual servers fail and become unavailable. This level of availability is an absolute requirement for mission-critical applications.

• Fourth, a WebSphere cluster can be formed from WebSphere servers residing on any platform WebSphere supports. This provides your organization with maximum flexibility and choice in deciding how best to apply available computer resources to satisfy the workload appetite of your client community. This is also helpful for managing application upgrades across a set of servers because you can install it across the cluster's members one at a time.

In the Zone

If you want to allow thousands of customers to access you electronic storefront, but are concerned about the security risks, WebSphere has a common topology for providing safe Internet access.

A sound practice for configuring app servers for Internet access is to setup a demilitarized zone, or DMZ. The DMZ is established through the use of a firewall pair, which establishes a double-layered protection against intruders. The DMZ is actually the area between the firewalls. In the DMZ, you would typically configure a web server. The left-most firewall (as shown in the following diagram) exposes perhaps only port 80 (default HTTP port) to the Internet, so the DMZ web server can be reached. The right-most firewall exposes ports as required for the DMZ web server to access app servers, other web servers, and possibly other types of server altogether, as dictated by your system architecture:

Important

Serving only HTTP from inside a DMZ is a common topography for safe Internet access. In this configuration, only DMZ web servers have access to your WebSphere app servers.

The importance of the DMZ firewall topology is that it is among the safest techniques for enabling Internet access to selected applications, without exposing your entire internal network to the outside. The disadvantage of firewalls, generally, is that by their nature they restrict access. This in turn makes it more difficult to provide access to application clients that require use of communication protocols other than HTTP, such as IIOP and JMS. Advances in firewall technology, such as IIOP firewalls, will increase the ability to provide greater access options, without sacrificing security and control.

Serving to the Edge

An Edge Server is a special WebSphere add-on for extending the reach and performance of your enterprise's web presence and applications. "Edge" refers to the area of your WebSphere topology that is closest to your end users, such as where some of your HTTP servers might be found, but farthest away from the servers where your business and data logic is deployed. It is the first point of contact between your enterprise and your customers, business partners, and employees – ultimately the users who access your applications. The trick here is to provide the best access to your users for least cost. This was never an easy goal to achieve. The world of Internet computing, while opening immeasurable possibilities, has also increased network size, bandwidth demand, and the number of devices between users and servers. All this further complicates the tasks required to achieve the goal. The WebSphere Edge Server is an additional tool to help you balance access performance against delivery cost.

The WebSphere Edge Server, installed separately, is a kind of caching proxy server. It can be run in both forward and reverse proxy mode. The following diagram depicts the two common strategies for proxy and content caching across the network:

Important

The WebSphere Edge Server enables you to distribute and cache application content closer to your end users, increasing perceived application performance, while simultaneously offloading work from your mainline application servers.

The most common place to deploy a proxy server is at a network bottleneck. Bottlenecks are often created by slow connections at network gateways. Managing bandwidth at these locations is imperative as your business grows and network traffic continues to increase. The Internet gateway and the branch office connection are two likely bottleneck locations and are therefore prime candidates for a proxy server deployment.

Forward Proxy

Corporations are deploying proxy servers in increasing numbers on their intranets, both in remote locations and on major sub-networks. Proxy servers deployed at major sub-network connections can drastically reduce the traffic on your corporate backbone. At remote offices, which are often connected via slow links to the corporate network, proxy servers can provide a quick mechanism for replicating content, providing better company integration, and increasing network performance – all of which can be achieved without large capital and communications expense.

Many organizations are seeing the value of deploying proxy servers throughout their intranet. Types of deployments that use multiple servers can take advantage of the proxy routing capabilities of the WebSphere Edge Server. Proxy routing allows you to chain proxies together to create a hierarchical caching system that can better serve the various organizations within your enterprise.

Proxy chaining allows multiple Edge servers to cache content locally, setting up a hierarchy of servers for client access. The result is a managed network of proxy servers that is completely transparent to the user. In a typical implementation, smaller, local proxies might be situated near end-user communities, with larger proxies near the firewall and external connections. For most installations, two levels of hierarchy is optimum, but you may benefit from adding more levels, depending on the size of your organization and where the bottlenecks occur on your network.

Reverse Proxy

If you have a content server that has sensitive information that must remain secure, such as a database of credit-card numbers, you can set up a proxy outside the firewall as a stand-in for your content server. When outside clients try to access the content server, they are sent to the proxy server instead. The real content resides on your content server, safely inside the firewall. The proxy server resides outside the firewall, and appears to the client to be the content server. When a client makes a request to your site, the request goes to the proxy server. The proxy server then sends the client's request through a specific passage in the firewall to the content server. The content server passes the result through the passage back to the proxy. The proxy sends the retrieved information to the client, as if the proxy was the actual content server – this is depicted on the bottom of the preceding diagram. If the content server returns an error message, the proxy server can intercept the message and change any URLs listed in the headers before sending the message to the client. This prevents external clients from getting redirection URLs to the internal content server.

In this way, the proxy provides an additional barrier between the secure database and the possibility of malicious attack. In the unlikely event of a successful attack, the perpetrator is more likely to be restricted to only the information involved in a single transaction, as opposed to having access to the entire database. The unauthorized user cannot get to the real content server because the firewall passage allows only the proxy server to have access.

You can use multiple proxy servers within an organization to balance the network load among web servers. This model lets you take advantage of the caching features of the proxy server to create a server pool for load balancing. In this case, the proxy servers can be on either side of the firewall. If you have a web server that receives a high number of requests per day, you could use proxy servers to take the load off the web server and make the network access more efficient. The proxy servers act as go-betweens for client requests to the real server. The proxy servers cache the requested documents. If there is more than one proxy server, DNS can route the requests using a round-robin selection of their IP addresses. The client uses the same URL each time, but the route the request takes might go through a different proxy each time.

The advantage of using multiple proxies to handle requests to one heavily used content server is that the server can handle a heavier load, or the same load more efficiently than it could alone. After an initial start-up period in which the proxies retrieve documents from the content server for the first time, the number of requests to the content server can drop dramatically.

Only CGI requests and occasional new requests must go all the way to the content server. A proxy can handle the rest. For example, suppose that 90% of the requests to your server are not CGI requests (which means they can be cached), and that your content server receives two million hits per day. In this situation, if you connect three reverse proxies, and each of them handles two million hits per day, about six million hits per day would then be possible. The 10% of requests that reach the content server could add up to about 200,000 hits from each proxy per day, or only 600,000 total, which is far more efficient. The number of hits could increase from around two million to six million, and the load on the content server could decrease correspondingly from two million to 600,000. Your actual results would depend upon your situation.

Use of the WebSphere Edge Server can dramatically improve perceived application performance, increase overall network performance, enhance workload balancing, and increase the scope and reach of your applications. This does come at the cost of increased complexity and administrative demand, but the benefits are well worth it.

EIS Integration

The next topographical consideration is most relevant to customers of existing EIS systems, such as users of IBM CICS and IMS transaction monitors. A common requirement for new applications is to leverage and interact with existing application assets.

The Java 2 Connector Architecture (JCA) defines a standard interface for accessing arbitrary backend systems. The unique pluggable nature of JCA connectors enables easy third-party add-ons. Naturally, JCA adapters are available to connect WebSphere to CICS and IMS. You can anticipate availability of JCA adapters from both IBM and other vendors for a growing number of existing application execution environments.

Let's take a closer look at what an EIS integration topology might look like. The following diagram depicts a WebSphere/CICS application integration scenario:

Through JCA adapters, the reach of WebSphere is extended to include access to a number of key application execution environments, including CICS, IMS, and DB2.

While the strength of the J2EE architecture and WebSphere includes the ability to easily integrate EIS applications with new J2EE applications – even across disparate machine architectures and operating systems – WebSphere is uniquely positioned like no other J2EE application server to deliver high performance, highly scalable EIS integration with other IBM application environments through z/OS and OS/390 version of WebSphere.

As the diagram below depicts, WebSphere for z/OS and OS/390, delivers the tremendous benefit of co-locating your J2EE application server with your CICS, IMS, or DB2 server on the same execution platform, which leverages substantial local optimizations:

WebSphere and J2EE bring a rich array of tools and capabilities to bear on the task of EIS integration. WebSphere for z/OS and OS/390 offers unique strengths and capabilities for integration with existing CICS, IMS, and DB2 systems. There are many considerations for EIS integration. You can find more information on this topic in Chapter 7.

WebSphere provides unique integration possibilities with your existing EIS infrastructure. You can easily deploy both IBM and third-party JCA connectors for accessing CICS, IMS, SAP, and other EIS systems. You have great flexibility in deciding the best mix of cost and performance. Application server deployments on middle-tier systems (for example Unix), with remote access to your EIS can deliver reasonable performance for moderate access to your EIS at modest cost. Alternatively, WebSphere allows you the option of co-locating your application servers on the same system as your EIS – particularly large scale EIS, such as CICS and IMS on z/OS or OS/390 – delivering significant performance advantages by leveraging local access to the EIS assets.

Large Enterprise Topology

Large enterprises typically have diverse requirements that lead to larger, mixed networks of servers. Often a combination of departmental server groups, Internet-accessible line-of-business servers, and EIS integration, large enterprises demand the highest levels of scale, availability, and control.

WebSphere server networks, by their modular nature and single logical image, are especially well suited to meeting the needs of large enterprises. The following diagram depicts a particular large enterprise configuration, which combines a number of departmental servers with an internet-accessible clustered server, accessing an EIS application on CICS:

The diversity of WebSphere configuration, advanced administration facilities, and superior EIS integration capability makes it particularly well suited for tackling the needs of the largest enterprise. Moreover, WebSphere clustering delivers the scalability and availability characteristics that enterprise workloads demand.

The benefit of WebSphere to the large enterprise is flexibility. The rich configurability of WebSphere, the breadth of supported platforms, the power and reach of available JCA connectors, and the comprehensive control of WebSphere cell administrative services, all combine to make WebSphere a strong ally in solving the widest array of application deployment and integration requirements.