Custom design: Select a Non-Functional Requirement

Overview
Many different Application patterns may be available to satisfy the requirements of various solutions in any given Business pattern. Both of the following Non-Functional Requirements custom designs are illustrated by the Self-Service::Stand-alone Single Channel application pattern. This application pattern provides for stand-alone applications that have no need for integration with existing applications or data. It assumes one delivery channel, most likely a Web client, although it could be something else. It consists of a presentation tier that handles all aspects of the user interface, and an application tier that contains the business logic to access data from a local database. The communication between the two tiers is synchronous. The presentation tier passes a request from the user to the business logic in the Web application tier. The request is handled and a response sent back to the presentation tier for delivery to the user.

Non-Functional Requirements custom designs feature variations within the demilitarized zone (DMZ) and external network of the Self-Service::Stand-Alone Single Channel application pattern, in order to emphasize specific non-functional requirements of a solution design.

As the second network tier of a typical Runtime pattern, the DMZ is a network area that is exposed to an untrusted outside world (Internet), and though it is separated from the Outside World by a protocol firewall, it is considered a high-risk zone for attacks. No confidential material should reside on any server in a DMZ in an unprotected form. Only approved ports should be opened between the first and second tiers.

Note that the following two Non-functional requirements are illustrated by the same Application pattern: the Self-Service::Stand-Alone Single Channel Application pattern. Variations within the two Non-functional requirements are first seen at the Runtime pattern level. However, general descriptions for each Non-Functional Requirement, and the differences between them, are provided below.

Non-Functional Requirements
Select the Non-functional requirement that best meets the needs of your e-business solution:

High Availability

Along with its many rewards for an enterprise, the most frustrating element of e-business is its propensity for constant change. By applying the principles of high availability Web site design, however, an e-business application can evolve alongside a business and the marketplace as a whole, rather than being rebuilt for each change.

High availability principles
The basic principals of high availability (HA) are very simple. You must consider the possible failure of each component in the architecture of your solution. This will have an impact on your decisions all the way down from the architecture to the design, technology, topology, and products used to build the overall solution. Once the solution as a whole is defined to meet high availability requirements, you must identify dependencies on which you may, or may not have short-term influence. Your Internet Service Provider (ISP) is an example of this. If your connection to the internet goes down, all you can do is to wait for it to come back. Dependence on a single ISP is a potential high availability bottleneck. Planning and designing a configuration using multiple ISPs for high availability requires a considerable amount of time to arrange. You must consider and plan for this well in advance.

The skills of your staff and availability of vendor support are crucial assets in supporting the high availability requirements of your configuration.

High availability rules for Runtime environments
Three basic rules exist when planning for the high availability of your runtime environment and for verifying existing high availability configurations:

1. Every entity must be redundant.
2. Each entity must be monitored for failure.
3. A failed entity must not receive any work.

The following high availability terms relate to the above rules by defining "the anatomy of a failure":

• detect - continually monitor your configuration for component failures or problems
• recover - use of redundant entities to continue processing during component failure
• decide - make a decision to not send work to a failed entity and then decide to send work to that entity after repair
• repair - fixing the problem component and bringing it back online

Redundancy
In order to make entities useful for high availability, they must be grouped together for redundancy. There are three major kinds of groups:

• High availability pair
  Some products have the capability to act in pairs, complying with all three high availability rules. There are two kinds of pairs. Primary/Backup, and Peer pairs.
  With the Primary/Backup type, one does the work (Primary role) while the other one monitors it (Backup or standby role). The Backup takes over in case of a detected failure. For example High Availability Cluster Multiprocessing - HACMP (AIX) or Solaris Cluster (SUN) achieve this at an operating system level.
  Another example is WebSphere Edge Server Load Balancer in high availability (HA) mode.
  In a peer high availability configuration, both members are actively working and still monitoring each other, taking over the work from its peer in case of a detected failure. WebSphere Edge Server Load Balancer in mutual HA mode works in this way.
• Cluster
  Most products that are grouped into a cluster are not capable of monitoring their peers. Usually, they are not even aware of being grouped. They need a third party to distribute requests between them and to comply with high availability rules 2 and 3 listed above. Each member of a cluster must be able to serve identical requests. Members of a cluster are typically capable of serving multiple requests in parallel (multithreaded). So they can have different levels of load assigned to them. Adding members to a cluster and deleting them from the cluster is an administrative task that can not be done on the distributor instance’s own initiative.
• Pool
  If the members of a group are threads, like servlet instances or JDBC connection instances, it is typically referred to as a pool. Like members of a cluster, they require a third party to distribute requests and to comply with high availability rules 2 and 3 listed above. In this example of a group, the distributing instance can create and delete threads in the pool to adjust to the overall load on the pool.

Request distribution
To distribute requests to the members of a cluster or pool, there must be an entity that is aware of all members. This entity must address high availability rules 2 and 3. If a distributing entity is enhanced with the capability to measure the load on the cluster members and distribute the load equally among them, it is referred to as a load balancer.
There are two distinct configurations using load balancers, the cluster configuration and the high availability configuration.

• Cluster configuration
  In a cluster configuration, multiple entities that are not aware of each other perform redirection or basic load balancing functions. Therefore they are grouped in clusters themselves. To comply with high availability rules 2 and 3, these entities would need a third party. Each entity has the following role:
  • Monitor members of a downstream cluster and detect a failure
  • Balance requests between the downstream servers in a given cluster
  The advantages of a configuration like this are security and separation of processing functions. The security aspect allows you to place the application server behind a domain firewall. The separation of processing functions allows the machine selection to be made to suit the appropriate processing request (for example Web serving as opposed to application serving).
  Examples of technologies that fit into this category include:
  • Caching proxy node enhanced with a content-based routing component (for example, WebSphere Edge Server CBR component)
  • Web server redirector node (for example, WebSphere Application Server Plug-in)
  • Java Virtual Machine (servlet pool, JDBC connection pool, etc.)
  • Stand-alone Load Balancer node (for example, WebSphere Edge Server Network Dispatcher)
• High availability configuration
  In a high availability configuration, the load balancers act in pairs, capable of complying with all three high availability rules. Each load balancer has the following role:
  • Capability to monitor its peer load balancer and detect a failure
  • Capability to take over the balancing task from its peer load balancer
  • Capability to monitor members of a downstream load balancer cluster and detect a failure
  • Capability to balance requests between the downstream servers in a given load balancer cluster
  An example of this would be the WebSphere Edge Server Load Balancer in high availability mode.

High Performance

In today's marketplace, performance is not only a nice thing to have, but an imperative and necessity for internet survival and success against competitors. The baseline evaluation for performance is obvious; you want good response times for your clients accessing your web site.

Performance Factors
There are two distinct aspects to performance. One is the minimum amount of time needed to process a given task. This is based on the nature of the task and the application design. The other is maintaining the amount of time needed for each task if the number of requests for that task increases. Performance is the result of three factors that interact with each other:

• Time
• Resources
• Workload

Conceptually, these three factors depend on one another in a triangular relationship. Each of the factors is a result of the other two. For a Web site, the time element is represented by the targeted response time: Time = Workload / Resources

Three approaches are used to manipulate the time element of this equation:

• Increase the resources:
  This is the obvious approach to increase throughput. The condition to meet is scalability of both the application and the runtime environment. Scalability of the runtime environment includes high availability It is achieved through an architecture that allows load balancing and clustering of resources. Scalability of the application is a matter of its design and is thus not further discussed here.
• Lower the workload:
  Because the time needed for a given task is defined by its nature and the design of the application, we can not influence it here. But we can try to reuse the product of such a task. Caching is the technique to achieve this goal. Today not only static content can be cached, but also dynamic results of processing tasks.
• Increase the time available:
  Although the first thought might be: That’s exactly what we cannot do, we can do it in a abstract way. We can split the workload into sub tasks where different functionality is needed and distribute them to specialized instances. In this way they can be processed in parallel and so the overall time available is increased. This will be limited or enhanced by many factors such as application design, application packaging, runtime topology, skills available etc. Good planning and communication between the business units involved is crucial here!

Enhancing performance with proxy servers
A proxy server has the ability to act as a relay station for clients. Forwarding requests and receiving the responses makes it an ideal place to cache request results for reuse. This kind of proxy server is known as a caching proxy and has several benefits:

• The response time to the client requests is reduced
• The load on the content server nodes is reduced
• Less network bandwidth between the content server nodes is used
• By freeing up resources, better scalability is achieved

A proxy server can also be used to establish an additional layer between the client and the content server nodes by hiding their IP addresses and locations, or to intercept requests for authentication.

Static caching
When a client requests a file from a Web server, the Web server must find the file, read it from disk and send it out to the network. Disk IO operations are among the most time consuming operations for a Web server. Saving such a file in memory and delivering it from there dramatically reduces the response time for all subsequent requests. This technique is known as caching. Today, most Web servers support the use of there own caches. Having redundant Web servers in a cluster results in redundant caching of files. Implementing a caching layer in front of the Web server clusters further improves the cache utilization and cache hit rate.

Dynamic caching
For e-business applications, much of the memory and CPU processing power is used to generate the dynamic presentation of data. Caching the results of those operations is known as dynamic caching. It reduces response time to the client and reduces the load on both the redirector server nodes and the application server nodes. It also reduces the used bandwidth between the content server nodes.

Memory cache
Memory is by far the fastest media to write to and read from. Therefore, this is the preferred cache storage. There are limitations of the size of memory a server can handle and the cost per megabyte of storage space is much higher than on a disk. Memory cache is preferred for frequently changing data of small to medium size amounts.

Disk cache
For large amounts of data, disk caches are still a reasonable compromise between performance benefit and storage cost. For very large caches of the size of hundreds of gigabytes, disk caching is the choice.

Cache arrays
Multiple caches can be grouped together to form an cache of much larger total size than one server could ever handle. Such a group is named a cache array. Specialized protocols such as Cache Array Routing Protocol (CARP) and Internet Caching Protocol (ICP) have been developed to enable the members of a cache array to communicate with each other, avoiding redundant caching within a cache array.

Proxy chaining
Implementing several layers of proxy server nodes enables the combination of different functionality to build sophisticated caching architectures.