Security and workload management
Customer Information Control System (CICS) applications and their associated data constitute some of the most valuable assets owned by an enterprise. Therefore, the protection of these assets is an essential part of any CICS mobile project.
After a review of the main mobile security challenges, this chapter outlines the options for securing CICS JavaScript Object Notation (JSON) web services, reviews how products, such as Worklight and DataPower, can help, and then shows examples of security configurations in CICS and Worklight.
In this chapter, we provide information about the different techniques that can be used to provide high system availability and workload management for JSON web service applications. We summarize how high availability is provided across an IBM Parallel Sysplex®, and a multi-region approach for processing JSON web services workload.
This chapter contains the following topics:
7.1 Security overview
Every day, countless confidential transactions with financial institutions, online merchants, airlines, and various other retailers are performed on mobile devices. The biggest challenge that mobile service providers have is how to secure these services.
In addition to the normal web security challenges (authentication, authorization, confidentiality, data integrity, and nonrepudiation) mobile applications pose new challenges. There can be little or no control over the device, including when it is used, where it is used, who is using it, and for what it is used.
The following list notes some specific mobile security challenges:
•Who has access to the devices used to run your mobile applications?
•Are all of the devices that run your organization’s mobile applications owned by your organization?
•What form of user authentication was implemented as part of the application? Has two-factor authentication been implemented?
•What sensitive information is stored or cached by mobile applications on the devices? Is this information encrypted? Could this data be deleted remotely?
•Can the mobile devices used to run your mobile applications be remotely disabled?
•Is communication between mobile devices and your enterprise network and systems secure?
•Is the distribution of your mobile applications controlled appropriately?
Addressing all of these challenges is clearly beyond the scope of CICS. However, securing access to resources managed by CICS is a significant part of the challenge. The chapter focuses on this area. It takes a brief look at the role of other products. For example, this chapter provides information about how Worklight server provides mobile application security, how DataPower can act as a mobile gateway, and how IBM Endpoint Manager for Mobile Devices addresses mobile device management.
7.1.1 Security principals and concepts
Mobile security is achieved through compliance with the following security principles:
Authentication Ensures that the identities of both the sender and receiver of the mobile transaction are true.
Authorization Grants a mobile user, system, or process either complete or restricted access to a resource.
Confidentiality Protects sensitive data from unauthorized disclosure.
Integrity Ensures that information that arrives at a destination is untampered.
Nonrepudiation Proves that a mobile transaction occurred, or that a message was sent or received.
Consider the risks if inadequate authentication and authorization mechanisms are put in place. Thieves of stolen devices might be able to retrieve user credentials from the mobile device, or cyber criminals might bypass authentication controls. To address these challenges, multi-factor authentication is normally required (for example, verification of the device, user, and mobile application).
Consider the consequences if inadequate confidentiality, integrity, and nonrepudiation mechanisms are put in place. Mobile users’ confidential information, such as bank account details, can be lost, cyber criminals might be able to modify the amounts of money being transferred, and mobile users might be able to deny the transactions that they performed. To address these challenges, it is normally required to use encryption, and also to ensure that new mobile security features are integrated into the existing enterprise security infrastructure.
7.1.2 CICS security options for JSON web services
In a CICS environment, the assets that you normally want to protect are the application programs and the resources that are accessed by the application programs. To prevent disclosure, destruction, or corruption of these assets, you must control access to the CICS region, and to different CICS components.
You can limit the activities of a CICS user to only those functions that the user is authorized to use by implementing one or more of the CICS security mechanisms that protect transactions, resources, and commands.
When CICS security is active, requests to attach transactions, and requests by transactions to access resources, are associated with a user ID. When a user makes such a request, CICS calls the external security manager, such as IBM Resource Access Control Facility (RACF®), to determine if the user ID has the authority to complete the request. If the user ID does not have the correct authority, CICS denies the request.
In some cases, a user is a human operator, interacting with CICS through a terminal or a workstation. In this case, the security scenario is straightforward, in that any transactions started by the signed-on user will automatically be authorized against the appropriate user ID.
However, in the case of a mobile user using a web service client application, it is unlikely that the mobile user will have a RACF user ID. Therefore, you need to consider how the user will be authenticated to CICS, and what user ID will be associated with the CICS transaction. You also need to consider how the confidentiality and integrity of the message will be protected.
Transport security
For Hypertext Transfer Protocol (HTTP) connections from mobile devices, there are two ways that the mobile user can be authenticated using transport security:
•An HTTP client can provide HTTP basic authentication information (a user ID and password). The CICS transaction that services the client’s request, and further requests made by that transaction, are associated with that user ID.
|
Note: A likely issue with this approach is the question of what basic authentication credentials a mobile user would use. Basic authentication is also not considered especially secure unless combined with Transport Layer Security or Secure Sockets Layer (TLS/SSL).
|
•A client program that is communicating with CICS using TLS or SSL can supply a client certificate to identify itself. The security manager maps the certificate to a user ID. The transaction that services the client’s request, and further requests made by that transaction, are associated with that user ID.
|
Note: A likely issue with this approach is that TLS/SSL can use many compute resources and might not be appropriate for a mobile device.
|
CICS user IDs
Figure 7-1 shows a security scenario in which a mobile application sends a JSON web service request to CICS over an HTTP or HTTP over SSL (HTTPS) connection. The following different user IDs are shown:
Flowed user ID This is a user ID that is flowed with the request (either in the JSON data or in an HTTP header). CICS enables a custom handler in the pipeline to extract such a user ID and use it to set the DFHW-USERID container. The target application then runs in a new task that is associated with this user ID.
Transport user ID The transport-based user ID can be set using either basic authentication or SSL client authentication (see “Transport security” on page 71).
URIMAP user ID A Uniform Resource Identifier (URI) mapping (URIMAP) resource definition matches the URIs of web service requests. The URIMAP associates a URI for the request with a PIPELINE and WEBSERVICE resource that specifies the processing to be performed. You can use a URIMAP to specify the user ID under which the CICS task runs (known as the pipeline alias transaction).
You can also use the URIMAP to set the name of the transaction that CICS uses for running the CICS task (the default is CPIH).
Default user ID When a user does not sign on, CICS assigns a default user ID to the user. It is specified in the SIT parameter DFLTUSER. In the absence of more explicit identification, it is used to identify Transmission Control Protocol/Internet Protocol (TCP/IP) clients that connect to CICS. You should not give much authority to the default user ID.
Region user ID The CICS region user ID is used for authorization checking when the CICS system (rather than an individual user of the system) requests access to system resources, such as CICS data sets and other servers.
Figure 7-1 CICS mobile security scenario
It is possible that for a single JSON web service request, transported by HTTP, multiple methods for setting the user ID will be used at the same time. In this event, CICS uses the following order of precedence for determining the user ID associated with the CICS task:
1. A user ID inserted into the DFHW-USERID container by a message handler that is included in the service provider pipeline. This user ID might be extracted from a token in the header or body of the HTTP request.
2. A user ID obtained from the mobile client using basic authentication, or a user ID associated with a client certificate.
3. A user ID specified in the URIMAP definition for the request.
4. The CICS default user ID, if no other user ID can be determined.
7.1.3 CICS mobile security topologies
Previously, Figure 7-1 on page 72 showed a mobile device connecting directly to CICS. However, in most cases mobile devices will connect to another server before the request is passed on to CICS. Figure 7-2 shows two common CICS mobile topologies.
Figure 7-2 CICS mobile topologies
The following list notes several advantages of using an intermediary server:
•The intermediary server normally supports a wider range of mobile authentication mechanisms.
•The intermediary server can enable mobile single sign-on (SSO). SSO is an authentication process in which a user can access more than one system or application by entering a single credential (for example, a user ID and password).
•The intermediary server can protect CICS against unauthorized access and attacks.
|
Note: Worklight and DataPower can be used together to create a secure mobile infrastructure.
|
When an intermediary server is used to authenticate mobile users on behalf of CICS, it is important to establish a trust relationship between the intermediary server and CICS.
Transport security mechanisms, such as basic authentication and SSL client authentication, can be used to establish this trust relationship (see 7.3, “Worklight security configuration” on page 78 for examples of using transport-based security between Worklight server and CICS).
7.1.4 Worklight security
IBM Worklight provides a set of security capabilities that address a wide range of mobile security objectives, including the following list:
•Protecting data on the device.
It is common for the mobile application user to have access to sensitive data that can be stored on the mobile device. However, this data stored on-device can potentially be stolen or tampered with by malware existing on the device. In the event that the device is lost or stolen, this sensitive data can be extracted by unauthorized third parties.
In addition, the mobile application can be required to function in an offline context (without any back-end connectivity), and at the same time require that only authenticated users be given access to the data stored on the mobile device.
Worklight provides encrypted on-device storage and offline authentication.
•Providing mobile application security.
In addition to protecting the on-device data, it is also important to protect the mobile application itself on the device. This prevents hackers from unpackaging a legitimate mobile application and then repackaging it with malicious code:
– Worklight provides an Application Center that can be used to install, configure, and administer a repository of mobile applications for use by individuals and groups within an enterprise or organization (see 6.2, “Worklight Server” on page 52).
– Worklight provides capabilities to encrypt the application code and web resources to prevent tampering with the application.
– By combining multiple authenticity tests (multi-factor authentication), Worklight can enforce more stringent levels of security for the application, device, and user. For example, by requiring application, device, and user authenticity tests, it is possible to only grant access to this legitimate application running on that authorized device for this authenticated user.
– Worklight also extends the concept of SSO to the applications on the mobile device, so that authenticating to one application means that the user does not have to authenticate to other applications on that device.
•Ensuring security updates.
In today’s mobile world, users can choose whether to download and install the latest release of a mobile application from an application store. It is difficult to ensure that users are downloading and running the correct version of the application in a timely manner. In the event that a fix is needed to correct a security flaw in the application, a timely propagation of security updates is essential to mitigate the possibility of critical problems.
Worklight provides features to help administrators ensure that critical updates are delivered to the applications on the mobile devices.
•Providing robust authentication and authorization.
Worklight’s authentication integration framework simplifies the task of connecting mobile applications with the enterprise back-end authentication infrastructure. Server-side components interact with the client-side security framework in a challenge-response process to ensure that only authenticated identities are used to access protected resources. Worklight supports a number of commonly used mechanisms for authentication, such as forms-based, cookie-based, or header-based, and so on.
For more information about Worklight security, see the IBM Redbooks publication Securing Your Mobile Business with IBM Worklight, SG24-8179.
7.1.5 DataPower security
WebSphere DataPower Appliances simplify, govern, and optimize the delivery of services and applications, and enhance the security of Extensible Markup Language (XML) and information technology (IT) services. In addition to the core business of service-oriented architecture (SOA) connectivity, WebSphere DataPower Appliances now serve areas of business-to-business (B2B) connectivity, web application proxying, and Web 2.0 integration with JSON and Representational State Transfer (REST).
WebSphere DataPower SOA Appliances provide the following key features:
•Acts as a web, mobile, and XML firewall
•Enables new workloads for securing mobile, web, and application programming interface (API) management, consolidating and simplifying enterprise infrastructure
•Provides authentication, authorization, and auditing (AAA) support
•Provides application-level security as an integral part of the user interaction
•Helps customers meet compliance requirements, serving as a governance policy enforcement point
•Can implement an enterprise SSO function using Lightweight Third Party Authentication (LTPA) tokens
•Simplifies integration to multiple back-end applications (including CICS), supporting a wide array of protocols
DataPower can be used on its own as a mobile gateway to CICS. For example, it can be used to authenticate a mobile user, and map the user’s credentials to a security token understood by CICS, a RACF user ID, or an Extended Identity Context Reference (ICRX). An ICRX is a z/OS identity token that contains a distributed identity. When the request is processed by CICS, it resolves the distributed identity to a RACF user ID, and sets the user ID of the CICS task to this value.
The z/OS identity propagation enables a z/OS security administrator to create a set of flexible rules, stored in the RACF database, and ensures that the distributed identity persists after the mapping stage and remains visible for operational support and auditing. For more information about using z/OS identity propagation with CICS see the IBM Redbooks publication CICS and SOA: Architecture and Integration Choices, SG24-5466.
DataPower can also be used in conjunction with Worklight. When used with Worklight, it can provide security capabilities beyond those provided by Worklight itself:
•Enhanced form-based authentication support for easy and quick integration with Worklight applications running on mobile devices
•Ready-to-use configuration patterns as a reverse proxy and security policy enforcement point in front of the Worklight Server
•Fine-grained authorization and authentication with a centralized policy enforcement
•Enhanced data transformation and connectivity capabilities
For more information about the WebSphere DataPower Appliances, see the IBM Redbooks publication, Strategic Overview of WebSphere Appliances, REDP-4790.
7.1.6 IBM Endpoint Manager for Mobile Devices
IBM Endpoint Manager for Mobile Devices provides a single platform with complete integration for managing, securing, and reporting on notebooks, desktops, servers, smartphones, tablets, and even point-of-sale terminals. The benefit to the enterprise is visibility and control over all devices, and cost reduction, productivity increases, and compliance improvements.
For more information about IBM Endpoint Manager for Mobile Devices, visit the following website:
7.2 Configuring security for JSON web services
This section shows how to configure security for CICS JSON web services.
7.2.1 Configuring the URIMAP
A URIMAP resource definition matches the URIs of JSON web service requests. The URIMAP associates a URI for the request with a PIPELINE and WEBSERVICE resource that specifies the processing to be performed.
Importantly, you can use a URIMAP to specify the following attributes:
•The name of the transaction that CICS uses for running the pipeline alias transaction (the default is CPIH)
•The user ID under which the pipeline alias transaction runs
Table 7-1 on page 76 shows the attributes of the URIMAP resource definition that affect the security context within which a service provider application runs.
Table 7-1 Security attributes in URIMAP resource for CICS service provider
|
Attribute
|
Description
|
|
HOST
|
Specifies the host component of the URI to which the URIMAP definition applies. An example of a host name is www.example.com. This attribute can be used to restrict web service requests to specific host names.
|
|
PIPELINE
|
Specifies the name of the PIPELINE resource definition for the web service. The PIPELINE resource definition provides information about the message handlers, including security message handlers, which act on the service request from the client.
|
|
SCHEME
|
Specifies the scheme component of the URI to which the URIMAP definition applies, which is either HTTP (without SSL) or HTTPS (with SSL). It can be used to restrict web service requests to HTTPS only.
|
|
TCPIPSERVICE
|
Specifies the name of a TCPIPSERVICE resource definition, that defines an inbound port to which this URIMAP definition relates. It can be used to restrict access to web services through a specific TCPIPSERVICE and its associated transport-based security mechanisms.
|
|
TRANSACTION
|
Specifies the name of the pipeline alias transaction that is to be used to start the pipeline. This is an important attribute, because it directly controls the transaction identifiers that are used for web service requests and that, therefore, need to be protected using transaction security.
|
|
USAGE
|
Must specify PIPELINE to indicate that this URIMAP definition applies to inbound web service requests.
|
|
USERID
|
Specifies the user ID under which the pipeline alias transaction is attached.
Important: A user ID that you specify in the URIMAP definition is overridden by any user ID that is obtained directly from the client.
|
|
WEBSERVICE
|
Specifies the name of the web service.
|
Further details about these URIMAP attributes are provided in the CICS Information Center.
When you install a PIPELINE resource, CICS scans the directory specified in the pipeline’s WSDIR attribute (the pickup directory) for WSBIND files, and creates URIMAP and WEBSERVICE resources dynamically. If you want to use the URIMAP definition to specify either the name of the transaction or the user ID under which the pipeline will run, you can set these parameters using the DFHLS2JS procedure.
7.2.2 Configuring the TCPIPSERVICE
A TCPIPSERVICE definition is required for a JSON web service that uses HTTP or HTTPS as transport. It contains information about the port on which inbound requests are received, and whether any transport-based security mechanisms will be applied by CICS.
Table 7-2 shows the attributes of the TCPIPSERVICE resource definition that affect the security context within which a service provider application runs.
Table 7-2 Security attributes in TCPIPSERVICE resource
|
Attribute
|
Description
|
|
AUTHENTICATE
|
Determines if an authentication and identification scheme is to be used at the transport layer. Specify BASIC if you want to use HTTP basic authentication, or CERTIFICATE if you want to use SSL client authentication.
|
|
CERTIFICATE
|
Specifies the label of an X.509 certificate that is used as a server certificate during an SSL handshake.
|
|
CIPHERS
|
Specifies the list of ciphers that this CICS region supports for SSL encryption.
|
|
PORTNUMBER
|
Specifies the number of the port on which CICS is to listen for incoming HTTP or HTTPS requests.
|
|
SSL
|
Specifies whether SSL is used for encryption and authentication. If you specify YES, CICS will send a server certificate. If you specify CLIENTAUTH, CICS will request the client to send a certificate.
|
Further details about these TCPIPSERVICE attributes are provided in the CICS Information Center.
|
Note: HTTP basic authentication scheme can only be considered a secure means of authentication when the connection between the web service client and the CICS region is secure. It is therefore suggested that basic authentication is used in parallel with an SSL connection to protect the user ID and password from being intercepted.
|
7.3 Worklight security configuration
This section shows how to configure Worklight for secure connectivity to CICS.
7.3.1 Configuring HTTP basic authentication in Worklight
If the TCPIPSERVICE definition installed in CICS is configured for HTTP basic authentication, follow these steps to configure the Worklight adapter to send basic authentication credentials:
1. Open the Worklight adapter's XML configuration file and select the design tab. Make sure that each of the procedures has the connect As option set to server.
2. Open the source tab to see the XML of the adapter's XML configuration file.
The <connectionPolicy> element is extended to contain an <authentication> child element, as shown in Figure 7-3 on page 79.
Figure 7-3 The connectionPolicy element for HTTP basic authentication
The ${user} can be replaced with a string of your choice or a variable, as per the Worklight Information Center subject in the following link:
7.3.2 Configuring SSL in Worklight
If the TCPIPSERVICE definition installed in CICS is configured for SSL, follow these steps to configure the Worklight adapter to use SSL:
1. Open the adapter's XML configuration file and select the design tab (Figure 7-4).
Figure 7-4 Adapter Editor
2. Add the required certificates to the server keystore, as per the procedure detailed in the following link:
3. Add the alias of the SSL Certificate that was added to the server's keystore to the appropriate box. If the certificate is protected with a password, make sure to enter the password in the sslCertificatePassword field.
4. To enable SSL for the IBM Worklight application center, follow the procedure shown in the following information center link:
7.4 Workload management overview
CICS has been providing web services capabilities since CICS TS V3, when support was introduced for SOAP web services.
The CICS Transaction Server for IBM z/OS Feature Pack for Mobile Extensions V1.0 introduces new capabilities to CICS web services: CICS can now receive and process an HTTP payload in JSON data format.
There are some differences with regard to JSON web service processing when compared with traditional CICS SOAP web services: JSON data is required to be stored within an HTTP payload, because WebSphere MQ transport is not currently supported. Additionally, the CICS pipeline processing is used within the CICS Java virtual machine (JVM) server.
Many of the workload management techniques that apply to SOAP web services also apply to JSON web services. You can take advantage of workload management techniques that might already be in place, such as TCP/IP load balancing and hosting the service provider over multiple listener and application-owning regions.
|
Note: This chapter summarizes some of the key concepts covered in the chapter on workload management and availability in CICS Web Services Workload Management and Availability, SG24-7144, and you should review that information in full for a detailed description of workload management topics.
|
7.5 Workload balancing
As the service hit rate from mobile applications increases, or due to increased availability demands, it might become necessary to balance a JSON web services workload across multiple CICS regions.
For HTTP, this can be achieved by using port sharing, or the Sysplex Distributor, to route the incoming requests to different CICS regions within a Sysplex. When within CICS, the existing business logic application that is linked from the message adapter can be on an application owning region (AOR) and workload managed, for example, by CICSPlex System Manager (CICSPlex SM).
Figure 7-5 shows an example of workload balancing across multiple regions.
Figure 7-5 Workload balancing across multiple regions
7.6 TCP/IP load balancing techniques
In this section, various TCP/IP load balancing techniques are summarized, describing the attributes of port sharing, virtual IP addressing, and the Sysplex Distributor.
7.6.1 Port sharing
TCP/IP port sharing provides a simple way of spreading HTTP requests over a group of CICS router regions running in the same z/OS image. CICS TCPIPSERVICEs in different regions are configured to listen on the same port, and TCP/IP is configured with the SHAREPORT or SHAREPORTWLM options.
The TCP/IP stack then balances connection requests across the CICS router regions.When SHAREPORT is specified on the PORT statement in the TCP/IP profile, TCP/IP evenly balances the number of active connections across the available servers. This balancing is based on the number of active and backlog socket connections.
Using port sharing spreads the JSON request messages across multiple CICS regions, and therefore improves availability. There remains, however, a single point of failure in the event of an IP stack or z/OS image failure.
7.6.2 Virtual IP addressing
A virtual IP address (VIPA) is configured the same way as a normal IP address or a physical adapter, except that it is not associated with any particular interface. TCP/IP hosts can use VIPA (a virtual device and virtual IP address) to select a z/OS IP stack without choosing a specific network interface on that stack. The virtual device defined for the VIPA is always active.
Dynamic VIPA (DVIPA) was introduced to enable the dynamic activation of a VIPA in addition to the automatic movement of a VIPA to another surviving z/OS image after a z/OS stack failure. There are two forms of DVIPA, both of which can be used for takeover functionality:
•Automatic VIPA takeover enables a VIPA address to move automatically to a stack (called a backup stack) where an existing suitable application instance is already active, and enables the application to serve the client formerly going to the failed stack.
•DVIPA activation for an application server enables an application to create and activate VIPA so that the VIPA moves when the application moves.
7.6.3 Sysplex Distributor
Sysplex Distributor is designed to address the requirement of one single network-visible IP address for the sysplex cluster. Clients in the network receive the benefits of workload distribution and high availability across the sysplex cluster. With Sysplex Distributor, client connections seem to be connected to a single IP host, even if the connections are established with different servers in the same sysplex cluster.
As with TCP/IP port sharing, Sysplex Distributor also supports server-specific Workload Manager (WLM) recommendations for load balancing. The distribution of new connection requests can now be based on the actual workload of a target server. Sysplex Distributor also takes into account information, such as quality of service (QoS) and policy information, provided by Communications Server for z/OS IP’s Service Policy Agent.
By combining this information with the information from WLM, the Sysplex Distributor has the unique ability to ensure that the best destination server instance is chosen for a particular client connection.
Sysplex Distributor has benefits over other load-balancing implementations:
•Cross-system coupling facility (XRF) links can be used between the distributing stack and target servers, as opposed to LAN connections, such as an Open Systems Adapter (OSA).
•It provides a total z/OS solution for TCP/IP workload distribution.
•It provides real-time workload balancing for TCP/IP applications, even if clients cache the IP address of the server, which is a common problem for Domain Name System (DNS)/WLM.
•It provides for takeover of the VIPA by a backup system if the distributing stack fails.
•It enables nondisruptive take back of the VIPA original owner to get the workload to where it belongs. The distributing function can be backed up and taken over.
It is possible to combine the use of Sysplex Distributor with TCP/IP port sharing for a high-availability CICS service provider configuration. Then the Sysplex Distributor distributes requests across logical partitions (LPARs), and port sharing distributes requests across different CICS systems within an LPAR.
When CICS is hosting a JSON web service requester application, Sysplex Distributor can also be used to route requests to multiple instances of the service provider, so long as the service provider application runs within the same parallel sysplex as the requester.
7.7 JSON web services and business logic: A multi-region approach
A target business logic application might run in the same CICS region that receives a JSON web service request (the front-end region), or it might run in another region (for example, an AOR). There are several advantages to running the target business logic program in a different region than the one that receives the JSON web service request:
•You can provide higher availability by having several regions that perform the same business function. If one of the regions fails, other regions of the same group can pick up the workload.
•You can implement workload balancing and workload separation.
•You are able to handle increasing workload by adding more CICS AORs.
There are two possible approaches to building a multi-region, front-end/back-end environment.
The simplest approach is to use a distributed program link (DPL) to start the business logic program. All pipeline processing is done in the front-end region, and the link to the business logic program is routed to an AOR. Separation of requests between different AORs might be achieved using workload separation based on different transaction IDs.
It is also possible to route the entire pipeline and business logic processing to an AOR. This might be done by setting the transaction ID in the URIMAP, and then dynamically routing this transaction. Setting the transaction ID in the URIMAP is necessary, because you cannot change the definitions of the default CICS pipeline transaction (CPIH).
Routing using DPL requests is suggested for the following reasons:
•It establishes a clearer definition, and a separation of the roles of the front-end regions and AORs.
•It performs better than transaction routing, because it avoids the effect of routing part of the pipeline processing.
•It is quicker for AOR regions added to the cluster to start processing work, compared to a new listener region that will wait for new HTTP connections. Note that most HTTP clients will continually reuse a pool of connections under steady load. AOR regions can be removed from the cluster more quickly without waiting for clients using HTTP persistent connections to decide to close them.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.