WebSphere brand IBM WebSphere Telecom Web Services Server, Version 7.1

SLA Enforcement mediation primitives

Controls the type of traffic admitted into the network for individual requesters.

Description

The Service Level Agreement (SLA) mediation primitives–SLA Local Enforcement and SLA Cluster Enforcement–control the type of traffic admitted into the network for individual requesters.

SLA limits form a three-level hierarchy: requester, service, and operation. Requester limits govern all traffic from a specific requester across all services. Service limits constrain the rate of requests for all operations executed against that service, regardless of the distribution of requests to the individual operations. Operation limits constrain the rate of requests executed against a particular operation.

Telecom Web Services Server provides two types of SLA tracking in separate mediation primitives: SLA Local Enforcement and SLA Cluster Enforcement. The SLA Local Enforcement mediation primitive tracks all usage information locally and assumes a distribution of requests across the Access Gateway cluster through a load balancer, such as a round-robin scheme. The SLA Cluster Enforcement mediation primitive uses a relational database based persistence mechanism to track the cluster-wide requests and to allocate requester rates to individual cluster members as needed. In doing this, it ensures that the requester rate limit is not exceeded across the cluster.

The Access Gateway does not make use of session affinity, as the Service Platform components do. Thus, given a random distribution of requests sprayed across an Access Gateway cluster over time, the SLA Local Enforcement mediation primitive will provide equivalent functionality to the SLA Cluster Enforcement mediation primitive.

However, the SLA Cluster Enforcement mediation primitive will provide more accurate limiting of requester rate for transient, uneven distributions. This comes at an additional cost, because performance can be affected due to the dependency on the relational database. Both mediation primitives may also be used within the same flow, where local SLA policy limits may be set to control individual server access and cluster SLA policy limits to control access across the cluster as a whole. This method of using these primitives provides function that is similar to the Admission Control component Web service.

Hierarchical rate limits are expressed in policy information and can be updated in the policy database at any time. Request rates are expressed in tokens per unit of time, where the time is calculated based on the service policy values message.sla.TimeUnit, and message.sla.TimeWindow. A weighting can be provided for the operation as an additional policy attribute. The weighting is measured in tokens and represents the cost of executing the operation. When calculating the total cost of the operation, the SLA mediation primitives will look for an upstream SOAP header indicating the number of targets against which the operation is being executed. The total number of tokens to be consumed admitting the request is calculated using the formula: (policy weight * number of targets). This total weighting represents the number of tokens that will be consumed by allowing this request.

For SLA Cluster Enforcement, hierarchical limits in the SLA mediation primitive are enforced using a sliding window, rate limiting bucket algorithm. The algorithm works as follows: the first request received with a positive weighting from a quiesce (idle with no active sliding window) state begins a sliding window, with an interval determined by the TimeWindow/TimeUnit policies, until the next quiesce state. Requests can arrive at any rate within the window as long as the limit is not exceeded. This constrains the average rate of Web service requests, regardless of the characteristics of the incoming flow of traffic. Requests with higher weightings will consume more tokens against the limit than requests with lower weightings. Requests with a weight of zero are automatically admitted, regardless of the limit.

For SLA Local Enforcement, hierarchical limits in the SLA mediation primitive are enforced using a fixed window algorithm. When the system receives a request, it calculates the SLA usage by computing the total tokens used in that particular time window on that cluster member. If the total tokens consumed exceeds the limit, the request is rejected.
Note: For SLA Local enforcement, the rate policies (message.sla.LocalRequesterRate, message.sla.LocalServiceRate, message.sla.LocalOperationRate) should specify the number of tokens to be consumed on each cluster member. For SLA cluster enforcement, the rate policies (message.sla.ClusterRequesterRate, message.sla.ClusterServiceRate, message.sla.ClusterOperationRate) should specify the number of tokens consumed cluster-wide.

Policy configuration

This mediation primitive uses the following policies for runtime configuration.

For the SLA Local Enforcement mediation primitive:

message.sla.LocalEnabled

SLA measurements enabled.
  • Type: Boolean
  • Default: True

message.sla.LocalWeight

Weight for the service or operation.
  • Type: Integer
  • Default: 0
  • Supported values: must be 0 or a positive integer

message.sla.LocalRequesterRate

The number of requests permitted for this requester.
  • Type: Integer
  • Default: 0 (denied)

message.sla.LocalServiceRate

The number of service requests to admit in the system for this requester.
  • Type: Integer
  • Default: 0 (denied)

message.sla.LocalOperationRate

The number of operation requests to admit in the system for this requester.
  • Type: Integer
  • Default: 0 (denied)

For the SLA Cluster Enforcement mediation primitive:

message.sla.ClusterEnabled

SLA measurements enabled.
  • Type: Boolean
  • Default: True

message.sla.ClusterWeight

Weight for the service or operation.
  • Type: Integer
  • Default: 0
  • Supported values: must be 0 or a positive integer

message.sla.ClusterRequesterRate

The number of requests permitted for this requester.
  • Type: Integer
  • Default: 0 (denied)

message.sla.ClusterServiceRate

The number of service requests to admit in the system for this requester.
  • Type: Integer
  • Default: 0 (denied)

message.sla.ClusterOperationRate

The number of operation requests to admit in the system for this requester.
  • Type: Integer
  • Default: 0 (denied)

For both SLA Local Enforcement and SLA Cluster Enforcement mediation primitives:

message.sla.TimeUnit

The unit used to measure the time window.
Note: This policy must be used in combination with message.sla.TimeWindow.

message.sla.TimeWindow

The amount of time for which the Requester/Service/Operation rate is valid. The time units–for example minute or second–are determined by the value of message.sla.TimeUnit.
Note: This policy must be used in combination with message.sla.TimeUnit.

Mediation primitive properties

This mediation primitive uses the following configuration properties. These properties can be modified using WebSphere® Integration Developer (WID) tooling. Properties that are promoted can be configured using the Integrated Solutions Console

cleanupInterval

The interval between cleanup timer runs. The cleanup timer cleans up inactive requesters from the in-memory data structures, which is used to track SLA usage. The interval is measured in milliseconds.
  • Type: Long
  • Default: 2000
  • Promoted: Yes

maxEntriesPerCleanup

The maximum number of entries to examine per run of the cleanup timer. As there can be a large number of requesters tracked within the in-memory data structures, this spreads out the cost of discovering and cleaning up inactive requesters over time. The higher this number, the faster inactive requesters are purged from the data structures (more efficient with memory), but at the cost of higher CPU utilization.
  • Type: Integer
  • Promoted: Yes
  • Default: 25

The SLA Cluster Enforcement mediation primitive includes the following additional configuration properties:

dataSourceName: The JNDI data source name.
  • Type: String
  • Promoted: Yes
  • Default: jdbc/SLADB

Upstream SOAP headers

The following SOAP header elements are expected from upstream mediation primitives:
<twss:twssHeaders>
  ...
  <twss:requesterID>
    <!-- The requester ID. If this header is missing, then
         "UNAUTHENTICATED" is assumed. -->
  </twss:requesterID>
  <twss:policies>
    <twss:policy attribute="" value=""/>
    <twss:policy attribute="" value=""/>
    ...
  </twss:policies>
  <twss:operationTargets>
    <!-- Used to calculate the weighting or cost of this request. If
         this header is not provided, then a default of ‘1' is
         assumed. -->
  </twss:operationTargets>
  ...
</twss:twssHeaders>

Added SOAP headers

None

Message handling

Messages that are successfully processed by the SLA mediation primitives are passed to the output terminal of the mediation primitive. If an error occurs while processing a message or an SLA has been exceeded, the message is redirected to the fault terminal:
  • The service message object (SMO) data object transient context (“context/transient/exceptionType”) indicates whether a service-related or policy-related exception occurred.
  • Fault information is set in the SMO headers as indicated in the following table:
    SMO header (represented by XPath) Content
    ServiceMessageObject/context/failInfo/failureString The full message text that represents the fault situation with substituted variables. For example, SOAC4025E: Error occurred.
    ServiceMessageObject/context/failInfo/origin The name of the mediation primitive class that originated the fault.
    ServiceMessageObject/SOAPFaultInfo/faultcode The TWSS message code that represents the fault situation. For example, SOAC4025E.
    ServiceMessageObject/SOAPFaultInfo/faultstring The full message text that represents the fault situation with substituted variables. For example, SOAC4025E: Error occurred.



Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.