So, the general rule for an SLA is that all listed
characteristics out to be measurable. In this case, a statement like "you will get 20% faster response
than the average" is not a legitimate SLA statement because it cannot be
measured - the 'average' value is not defined, i.e. the statement is not
self-contained or complete. Actually, the latter note may be the second
requirement to an SLA. Moreover, a statement like "an average response time
should be less than 3 seconds" is also not self-contained because 'average'
value changes over the time; so, the proper statement has to sound like "an
average response time should be less than 3 seconds for any 30 minutes after
first 1 hour of work".
I agree with Duane, nobody would care how long a response
time is if "it is within an acceptable amount
of time"... after "an acceptable amount
of time" is clearly defined.
- Michael
From: Ken Laskey [mailto:]
Sent: 28 February 2007 02:59
To: Duane
Nickull
Cc: Poulin, Michael;
Subject: Re: [soa-rm-ra] RE: updated
service description
I more align with Duane's thinking here. The SLA has to
specify what is being measured and what is the standard or limit against which
it is being compared. An SLA can say you will get 20% faster response
than the average, but then you have to collect metrics to compute and need a
way to respond to requests to see the average.
Ken
On Feb 27, 2007, at 12:07 PM, Duane Nickull wrote:
But if you cannot see the response time of the other
service requests for comparison, how can the consumer surmise they got the
SLA they are assured of? Should they really care? As long as it
is within an acceptable amount of time, it shouldn’t
matter.
Duane
On 2/27/07 5:42 AM, "Poulin, Michael" <>
wrote:
The "priority over al others" - like silver/gold user types - may be exposed as a
'response time', which can be easily monitored and measured. Moreover, why
a SLA has to contain only run-time characteristics? It may contain a
'change control response time' (in days) as well,
right?
The
difference between SLA and Service Contract may be viewed as Policy
section that cannot be a part of SLA.
- Michael
Fidelity Investments - Web
Delivery
Phone: +44-173-783-6038
E-mail:
<BLOCKED::">mailto:>
Web: http://www.fidelity.co.uk/
<BLOCKED::">http://www.fidelity.co.uk/>
Important: Fidelity Investments International, Fidelity
Investment Services Limited, Fidelity Pensions Management and Financial
Administration Services Limited (a Fidelity Group company) are all
authorised and regulated in the UK by the Financial Services Authority and
have their registered offices at Oakhill House, 130 Tonbridge Road,
Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only
gives information on products and does not give investment advice to
private clients based on individual circumstances. Any comments or
statements made are not necessarily those of Fidelity. The information
transmitted is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. If you
received this in error, please contact the sender and delete the material
from any computer. All e-mails sent from or to Fidelity may be subject to
our monitoring procedures. Direct link to Fidelity’s website - http://www.fidelity-international.com/world/index.html
From: Duane Nickull [mailto:]
Sent: 26 February 2007 18:51
To: Ken Laskey;
Cc:
Subject:
Re: [soa-rm-ra] RE: updated service description
SLA can only encompass
externally visible facets of a services operations, otherwise it
is more or less moot. Why would someone even contemplate
saying “your service request will be treated with priority over al
others” if there is no way to verify or authenticate from an
external standpoint? SLA’s should really just stick to
things like timeouts, error reporting and other externally visible
behaviors.
My $0.02.
D
On 2/25/07 2:21
PM, "Ken Laskey" <>
wrote:
Michael,
I started to respond
to this hours ago, then printed out your paper, and finally make
it past numerous distractions (including a unexpected 3 inches
of snow to shovel) to finally collect my thoughts.
On
your first point, I think of the service description as being
the executive summary and table of contents. It gives you
the critical overview and tells you where to find more details.
So while Interaction Policies & Contracts in the
description may explicitly lay out such things, these are more
likely to be fully defined elsewhere and referenced from the
description. Of course, one benefit of this is that the
policy, for example, becomes reusable.
As for the
personal nature of policy agreements, if it is a one-time
agreement, I see it residing in the execution context (whose
concrete manifestation is still to be discussed). If the
agreement is intended to be reused, it should be catalogued
somewhere. The idea of a general purpose somewhere also
needs to be tackled, perhaps (definitely?) as part of the
RA.
I then read your paper and if you went through the TC
emails, you could find discussions touching on but never resolving
many of these issues. So here are some general questions
and some specifics ones relating to your paper.
- What is
a service component? If we have a composite service, i.e.
one that shows a single interface but is actually a combination
of other services, do you consider the constituent services to
be service components? In the RM, we distinguish between
the capability and the service that provides access to the
capability. Is an implementation of the capability also a
service component? Personally, I think I'd say yes to both
where changes to either can affect the client
experience.
- Are "service functions" the same as RM
actions?
- One of my favorites: what belongs in a SLA?
Some views have it so complete that it basically becomes
the service description, i.e. it describes functionality,
constraints, interface details, and the birthdays of anyone who
ever used it. Personally, I take a more minimalist
approach and think of SLA as being strictly a set of well defined
metrics against which compliance can be measured. I agree
with with your line that "a SOA service ... is invoked ... when
the client is fully aware of the service behavior and
conditions." (We could quibble over "fully".) To
accomplish this, I rely on an adequate service description, of
which a metrics-laden SLA is a part. However, another part
is an indication of how one can obtain metrics collected against the
service. It is then up to the client to compare the
collected metrics with the SLA and determine fitness for use.
For example, if I have a service that says I will relieve
80% of world hunger and the metrics show me only relieving 70%,
does my service provide value?
Enough for
now.
Ken
On Feb 25, 2007, at 10:00 AM,
wrote:
Hi Ken,
I have two notes
to the update (actually, to the doc as it is with the
update):
1) There is an entity in the Service
Description diagram named "Interaction Policies &
Contracts". I think that Contract belongs to another area than
service description because it is 'personalized' based on
consumer/provider agreement. Yes, logically, a Contract is a
special type of description but it would be more comprehensive
if we put it into Interacting with Services Model
section.
2) You have mentioned <A discussion
of how version designation/value should be impacted by change
of version of any of its components (or any descriptions?)
still needs to be discussed.> To me, a version of the
service is one of very important characteristics of the
service description (and, respectively, of the service
contract). I would propose placing version as an entity in the
Service Description diagram either under Identity or at the
level of Service Description entity because version affects
Service Reachability, Service Functionality, Interaction
Policies, and Service Interface entities. I have published a
few thoughts about SOA service versioning in SOA-WebServices
Journal (http://java.sys-con.com/read/250503.htm
).
-
Michael
------------------------------------------------------------------------------------------
Ken
Laskey
MITRE Corporation, M/S H305
phone: 703-983-7934
7515
Colshire Drive
fax:
703-983-1379
McLean VA
22102-7508
--
**********************************************************
Sr.
Technical Evangelist - Adobe Systems, Inc.
*
Chair
- OASIS SOA Reference Model Technical Committee
*
Blog: http://technoracle.blogspot.com
*
Music:
http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************
--
**********************************************************
Sr.
Technical Evangelist - Adobe Systems, Inc.
*
Chair -
OASIS SOA Reference Model Technical Committee *
Blog:
http://technoracle.blogspot.com
*
Music:
http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305
phone: 703-983-7934
7515 Colshire Drive
fax:
703-983-1379
McLean VA 22102-7508
