Title: Re: [soa-rm-ra] RE: updated service description
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:
Web: 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*
**********************************************************
