SLA for SOA

Monitoring multiple SLAs and associated parameters, and taking meaningful action in real time requires a flexible solution.

The Problem: Message-based SLAs

Service Level Agreements (SLAs) address situations when, due to contractual or other reasons, compliance to one or more defined service level benchmarks needs to be verified. Although very common in telecom and datacom environments, SLAs are being used with increasing frequency in general application integrations, e-commerce, outsourcing and B2B deployments.

Metrics like processing time, messages per hour, rejected transaction counts and queries per day are common examples of defined service levels which may be measured either at end-points, or by an intermediary. These measurements are then typically compared by an enforcement process or application to the level desired, the result of which drives some form of action. This action can be simply gathering and reporting results, identifying and forwarding SLA violations, or changing service behavior based on current SLA conformance. In hard-wired deployments, SLAs may be relatively easy to implement using conventional software tools.

Agents can be deployed to gather the desired metrics, and code can be added to applications to process these metrics and behave accordingly. But, in a loosely-coupled enterprise SOA environment this may not be quite as easy. Service end points may be added or changed. New services might be offered or existing SLAs redefined. SLAs may even exist between different enterprises entirely. This is in addition to the complexity required to define SLAs based on service operations, identities and message content, all of which may be essential to define a meaningful SOA SLA.

Solution: Policy-based Compliance

Implementing Service Level Agreements in a SOA requires a process flow that can define SLAs, measure compliance and act accordingly. This drives some essential capabilities:

The ability to capture virtually any type of service level related metric on a per-message basis.
A flexible authoring environment to create policy logic based on SLA metrics and other service data.
A mechanism to verify policy compliance and handle SLA violations or related exceptions.
Any system that meets these requirements also has to work with any existing infrastructure that might be part of the overall business process being managed. This may include identity management systems, application servers, Web servers, portals, and client applications from one or more different vendors. From this perspective, it makes sense to use an intermediary that is not tightly bound to the underlying infrastructure but can implement SLAs at standards-based level.

Layer 7 Value: Cluster-wide Rate Limiting

Acting as a centralized policy enforcement point, the SecureSpan XML Networking Gateway can enforce SLAs without altering code. The XML Networking Gateway can capture message statistics flowing through it, increment centralized counters and perform an SLA instruction defined inside the SecureSpan Manager or external SOA Management product.

SLAs can be enforced for diverse application performance metrics including service availability, number of requests or traffic levels. Unlike some intermediary products, all SLA performance measurements and responses are executed simultaneously across a SecureSpan cluster, ensuring rate-limiting policies are adhered to. The SecureSpan Manager also supports monitoring features to ensure notification as SLA limits are being approached or exceeded.

Search, View and Navigation

SLA for SOA

Monitoring multiple SLAs and associated parameters, and taking meaningful action in real time requires a flexible solution.

The Problem: Message-based SLAs

Solution: Policy-based Compliance

Layer 7 Value: Cluster-wide Rate Limiting

Resources