Sample Middle-Tier Deployment Scenarios

Scenario 1 illustrates the most basic topology. All of the SAS middle-tier components are installed on a single system. All the SAS Web applications run in a single Web application server. The SAS Remote Services application is also installed on the same middle-tier server, but runs as a server application outside the Web application server.

As the maintainability advantages in the previous table indicates, scenario 1 is easy to implement. This middle-tier topology can be completely installed and configured by the SAS Deployment Wizard. SAS provides another topology that can be completely installed and configured by the SAS Deployment Wizard, yet provides better scalability and performance.

A variation of this scenario is to use the SAS Deployment Wizard to distribute the SAS Web applications across two Web application server instances (managed servers) on the same middle-tier server. This distribution of Web applications is different from clustering in that there is still only one instance of each application. By distributing the applications to two managed servers, this alternative configuration allows more memory availability for the applications deployed on each managed server and also increases the number of users that can be supported. Some SAS Solutions are configured with multiple servers by the SAS Deployment Wizard automatically. However, you can choose to configure multiple managed servers by running the wizard with the custom prompting level and selecting this feature.

The sample topology in scenario 3 includes a cluster of Web application servers in a network that implements a secure demilitarized zone (DMZ).

In the figure, note that the SAS Remote Services application resides on a machine that is separate from the cluster of Web application servers. This separation serves to illustrate that the SAS Remote Services application is a server application that does not participate in clustering. The SAS Remote Services Application could just as well reside on any one of the machines in the cluster.

In order to provide greater scalability, availability, and robustness, WebLogic Server, WebSphere Application Server, and JBoss support some form of clustering. With clustering, multiple Web application server instances participate in a load-balancing scheme to handle client requests. Workload distribution is usually managed by the same application server plug-in module that enables the use of a reverse proxy for static content.

The Web application server instances (managed servers) in a cluster can coexist on the same machine (vertical clustering), or the managed servers can run on a group of middle-tier server machines (horizontal clustering). The SAS Web applications can be deployed on both vertical and horizontal clusters.

A different approach to load distribution involves merely deploying individual SAS Web applications on separate, non-clustered Web application servers. Though this approach reduces the memory load for any given server, a clustering strategy is preferable. Deployment is easier to manage with a cluster because all machines and server instances are identically configured. Furthermore, Web application servers provide deployment management services that facilitate management of a cluster. It is relatively easy to add additional nodes and increase the size of the cluster.

For SAS Web applications to be deployed into a clustered environment, the Web application servers must implement session affinity. Session affinity is an association between a Web application server and a client that requests an HTTP session with that server. This association is known in the industry by several terms, including session affinity, server affinity, and sticky sessions. With session affinity, once a client has been assigned to a session with a Web application server, the client remains with that server for the duration of the session. By default, session affinity is enabled in WebSphere Application Server and WebLogic Server.

Although WebSphere Application Server, WebLogic Server, and JBoss provide the ability to migrate HTTP sessions from one server to another, the SAS Web applications do not support this capability. Business intelligence sessions often contain large data elements, such as results sets from ad hoc queries, reporting, and analytical tasks, that cannot be migrated easily among Web application servers.

Many organizations use a series of firewalls to create a demilitarized zone (DMZ) between their servers and the client applications. A DMZ provides a network barrier between the servers and the clients. A DMZ provides this protection whether the clients reside within the organization's computing infrastructure (intranet) or reside outside the organization on the Internet.

In the previous figure, the outer firewall that connects to the public network is called the domain firewall. Typically, only the HTTP (80) and HTTPS (443) network ports are open through this firewall. Servers that reside directly behind this firewall are exposed to a wide range of clients through these limited ports, and as a result the servers are not fully secure.

An additional firewall, the protocol firewall, is configured between the non-secure machines in the DMZ and the machines in the secure middle-tier network. The protocol firewall has additional network ports opened. However, the range of IP addresses that are allowed to make connections is typically restricted to the IP addresses of the servers that reside in the DMZ.

The DMZ usually contains HTTP servers, reverse proxies, and load-balancing software and hardware. Do not deploy Web application servers or any SAS servers that handle important business logic, data, or metadata in the DMZ.

If your applications are accessed by clients through the Internet, then you should include a DMZ as part of your deployment in order to safeguard critical information. For deployments on a corporate intranet, you might want to implement a DMZ as an additional layer of security.

In scenario 3, the Web application servers are clustered to balance the load and to provide increased availability. While this scenario provides redundancy for the application servers, the HTTP server that is deployed as a reverse proxy remains a potential bottleneck and single point of failure. To improve availability and increase capacity, you can distribute HTTP traffic across multiple reverse proxies by placing load-balancing software or hardware in front of those servers. A single load-balancing component can accept client HTTP requests and distribute those requests across a cluster of reverse proxies.

A number of vendors sell load-balancing software and hardware products for HTTP servers, including IBM, Cisco, and Nortel. If you are interested in this type of load-balancing, you can explore the product lines for these and other vendors.

If you are moving sensitive information across the Internet, then you might want to use HTTPS and Secure Socket Layer (SSL) to encrypt your communication links. SSL uses Public Key Cryptography, which is based on the implementation of a public and private key pair. Each of your servers that handles encrypted communications manages certificates that contain both the private key and the public key. A description of how Public Key Cryptography and SSL work is beyond the scope of this document. However, there are many good sources for that information.

Here are some factors to consider when determining whether and how to use SSL:

By default, SAS Web applications use the form-based authentication that is provided by the SAS Logon Manager Web application. When credentials are provided to the SAS Logon Manager Web application, the credentials are sent to the SAS Metadata Server for authentication. The metadata server then authenticates the credentials against its authentication provider. The default provider is the host operating system.

As an alternative, you can configure the SAS Web applications to authenticate on the middle tier. When users log on to a SAS Web application, the Web application server handles the initial authentication. In this configuration, the Web application server's JAAS login module authentication provider verifies the user's identity. Then, the SAS Logon Manager Web application makes a trusted user connection to the metadata server to check that the authenticated user has a SAS identity in metadata.

Performing Web authentication facilitates single sign-on. Most likely, your organization has several applications behind a common set of reverse proxy and HTTP servers. By having a common server handle authentication, users do not need to re-authenticate for access to each application.

For more information, see the following topics:

Middle-tier applications use the SAS Remote Services application to pass session and user context between Web applications. The SAS Remote Services application enables the user to pass seamlessly through to the target without the requirement for a separate logon.

During installation, the SAS Deployment Wizard enables you to specify the desired initial and maximum heap size for the SAS Remote Services application by using the JVM option format. You must run the SAS Deployment Wizard at the Custom prompting level to set these values.

JVM options of the SAS Remote Services application are set to handle a moderately high number of concurrent users. For a very large number of concurrent users and a distributed topology, you should tune the JVM options to accommodate the deployment.

If you use the Windows service, you can increase the initial and maximum heap size of the SAS Remote Services application. Edit the wrapper.conf file located in the SAS-config-dir\Lev1\Web\Applications\RemoteServices directory.