OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm-ra] definition of SLA

Interesting.  In the early pages of the RM, we often talk about constraints and policies as a duo, and later define policy in terms of the word constraint.  Now what you bring up is the idea that configuration happens in response to some information exchanged in initiating the interaction.  This could be the result of policy or technical assumptions or possibly other things.  I think much of this could (but not necessarily does) happen in response to things separate from a SLA.  The response can be noted as part of the discussion of interaction but likely happens without the consumer's explicit knowledge.

So it feels like another loose end.


On Jan 26, 2007, at 2:31 PM, Danny Thornton wrote:

To add to this comment:

So, it would appear that 
- most of these items relate to policy and, as
appropriate, should be referenced in the "policy
section" of the service description

The SLA will consist of those things that are
measurable by the computing systems and those things
that are not measurable. This also applies to all
policies/contracts. Looking at the measurables in the
SLA, when the SLA is consumed by the provider's
computing system, those measurables in the SLAs are
translated into policies (probably for a PDP) and/or
configurables.  The configurations are applied to
devices and services during the course of execution. 
The measurables in the SLA that were translated and
given to the PDP are checked at run time and can
result in changes to configurations of devices and
services to stay within the boundaries of what was
defined in the SLA.  The underlying mechanisms that
collect metrics on the system in support of the
parameters in the SLA can consist of many devices and
services.  As for those things that are not measurable
in the SLA, human intervention would be required in
the case of a breach of the terms of the SLA.

An SLA could be distinguished from a policy by stating
that SLAs result in configurables and policies whereas
policies are just policies and not configurables. 
Performance (QoS) is widely used in SLAs so we are
safe with classifying that as part of the SLA.  


--- Ken Laskey <klaskey@mitre.org> wrote:

Still chewing on SLA.

Jeff - was the Duke work done with SOA in mind or a
more general idea  
for IT delivery?  The Wikipedia article also seems
to indicate the  
general IT case:

Service Level Agreement (SLA) is that part of a
service contract in  
which a certain level of service is agreed upon. An
SLA is therefore  
not a type of service contract, but a rather a part
of a service  
contract. A service contract can contain zero, one,
or more SLAs. A  
contract containing SLAs is usually referred to as a

In practice, the term SLA is sometimes used
incorrectly in the  
context of contracted delivery time (of the service)
or performance.

The discussion of SLA seems to assume there is no
other description  
-- in our case, no service description.

Let's look at the list Danny provided (from
index.htm) because that seems (overly) exhaustive.

Definition of Services - while we haven't finished
tackling the  
details, this is definitely service description. 
However, I've  
recently seen this become another phrase for
requirements.  Other  
than the idea of description-driven development (I
tell you want I  
want and you agree to build it), is there a
rationale for capturing  
what were supposed to be requirements vs. what the
service actually  

Problem Management - this is briefly the "process to
handle and  
resolve unplanned incidents".  This needs more
thought on how it  
relates to SLA.  My initial thoughts are:
1. Some handling of faults are based in the
infrastructure (e.g.  
messages dropped in transport) and need to be
resolved at that  
level.  The power utility does not give me detailed
of how they will  
handle downed transmission lines.
2. The more endpoint related remedies seem to be the
domain of  
lawyers.  To a certain extent, this is where the
UDDI model has run  
into problems because businesses don't get things
from other business  
without laying some groundwork for the business
Someone will have to figure what this means in the
SOA context  
because everything will grind to a halt if we have
to wait for the  
lawyers for every new service interaction.
So let's assume there are some standard answers here
and those are  
either embedded in the cloud, referenced as part of
the service  
policies, or agreed to and incorporated into the
execution context.

Performance Management - Briefly, this "deals with
monitoring and  
measuring service level performance".  I don't think
this can be done  
without reference to some form of NetOps (network
operations) or ESM  
(enterprise service management) that will be the
recognized agent to  
collect metrics.  It does not make sense to demand
things that can't  
be measured.

Customer Duties and Responsibilities - see Problem
Management, item 2.

Warranties and Remedies - definitely see Problem
Management, item 2.
    Service quality
    Third party claims
    Remedies for breaches
    Force majeure

    Information Security Policies
    Security Audit and Internal Audit

Disaster Recovery - see Problem Management, item 1.

Termination - if the relationship has the unit of
per interaction,  
then termination is simply no more interactions. 
Beyond that, see  
Problem Management, item 2.

So, it would appear that
- most of these items relate to policy and, as
appropriate, should be  
referenced in the "policy section" of the service
- things specific to a particular set of
participants would be  
captured in the SLA, but don't overload this to
include all contract law
- things needing to be measured can be part of SLA
but they should  
coordinate with what can be measured
- things that are clearly description and are
relevant to any  
interaction no matter who are the participants
should captured in the  
service description



On Jan 23, 2007, at 10:23 AM, Jeffrey A. Estefan

Hey Ken,

This is certainly relevant to our service
description and service  
management models.  I mentioned SLAs in passing in
the service mgmt  
model but did not explicitly define it.  Recommend
keeping the  
adopted defn simple and consistent with our scope
(see, for  
example, the Wikipedia defn for SLA).  The
important point being  
that the SLA is "part" of the service contract and
not a "type" of  
service contract.  It's also important to
differentiate SLAs from  
OLAs and a decent distinction is captured at


 - JAE


Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:     
McLean VA 22102-7508

Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.


Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]