SLA for SOA

The Problem: Managing and Monitoring SLAs in SOA

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 that leverage SOA architectural approaches.

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 zservice 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: SecureSpan XML Gateways + Service Manager

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: SLA Management from Definition to Execution

Using the SecureSpan Policy Manager, end-users can declaritively define service level agreements for individual or groups of services. Acting as a centralized policy enforcement point, the SecureSpan SOA Gateway can enforce SLAs without altering code. The SOA Gateway can capture message statistics flowing through it, increment centralized counters and perform an SLA instruction defined inside the SecureSpan Policy 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 Enterprise Service Manager also supports monitoring features to ensure notification as SLA limits are being approached or exceeded. Taken together the SecureSpan SOA Gateway and Enterprise Service Manager provide a comprehensive solution for defining, enforcing and monitoring SLA's inside an SOA.