Web services workloads

The web services set of workloads measure the performance of CICS® as a SOAP web service provider.

These workloads contain a range of configuration options for testing, including variations of:

Connection persistence
SSL usage
SSL provider
SSL handshake type (none, abbreviated, or full)

All variations follow the same application topology, as shown in Figure 1. Note that other resources are required to configure CICS to use web services, but these resources are omitted for clarity. For a detailed setup guide, see Configuring web services.

Flow as described in the surrounding text — Figure 1. Topology of CICS web services workload

The DFHLS2WS utility is used to produce a CICS wsbind file. This file is installed into the CICS provider region and configures CICS to invoke a COBOL application by using a channel interface.

Two copybooks are used as input to the utility:

The first copybook defines the input data to the SOAP web service.
The second copybook defines the output data from the SOAP web service.

Both copybooks are similar, with the input data copybook shown in the example copybook below. This configuration results in a web service that accepts a SOAP message that contains 10 80-byte fields as an input and returns a SOAP message that contains 10 80-byte fields as an output.


        01 RECEIVED-DATASTRUCTURE.
          02 JB1                     PIC X(80).
          02 JB2                     PIC X(80).
          02 JB3                     PIC X(80).
          02 JB4                     PIC X(80).
          02 JB5                     PIC X(80).
          02 JB6                     PIC X(80).
          02 JB7                     PIC X(80).
          02 JB8                     PIC X(80).
          02 JB9                     PIC X(80).
          02 JB10                    PIC X(80).

The workload is driven by using a second CICS region (the requester region) that uses a URIMAP resource to send web service requests into the CICS provider region under test. The requester region runs on a separate LPAR and is driven by running CICS transactions at a simulated console by using IBM® Workload Simulator for z/OS®, as described in Workload driving.

The CPU consumption of the CICS provider region is measured during execution of the benchmark. When combined with the known arrival rate of the SOAP messages, a CPU per request value can be obtained.

Web services variations

Test variations are achieved by modification of resources in both the provider and requester regions, with the following available options:

Connection persistence.
The choice between persistent and non-persistent connections is configured by modifying the SOCKETCLOSE attribute in the URIMAP of the requester region. When set to zero, the connection closes after the response message arrives.
Use of SSL.
SSL is enabled by specifying the SCHEME(HTTPS) parameter in the URIMAP of the requester region.
Use of CICS SSL or AT-TLS.
The use of CICS SSL is configured by specifying SSL(YES) for the TCPIPSERVICE parameter in the provider region. The use of Application Transparent Transport Layer Security (AT-TLS) is achieved by specifying SSL(NO) for the TCPIPSERVICE parameter in the provider region and configuring AT-TLS in IBM Communication Server.
SSL handshake type.
No SSL handshakes are performed during the measurement period when persistent connections are used. (The configuration of this is described previously.) When non-persistent connections are used, the CICS SSLDELAY SIT parameter in the requester region controls whether a full or a abbreviated SSL handshake is performed.

A setting of zero for SSLDELAY specifies that the provider region does not cache SSL session tokens, and therefore a full SSL handshake takes place for every new connection.
A nonzero setting for SSLDELAY specifies the amount of time in seconds for which the provider region caches the SSL session token. A value of 600 is used to guarantee that the session token is always cached between successive requests, regardless of the transaction rate used.