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] 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.


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.


On 2/27/07 5:42 AM, "Poulin, Michael" <Michael.Poulin@uk.fid-intl.com> 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: michael.poulin@uk.fid-intl.com <BLOCKED::mailto:michael.poulin@uk.fid-intl.com>  
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:dnickull@adobe.com]
Sent: 26 February 2007  18:51
To: Ken Laskey; michael.poulin@uk.fid-intl.com
Cc:  soa-rm-ra@lists.oasis-open.org
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.


On 2/25/07 2:21 PM, "Ken Laskey"  <klaskey@mitre.org> wrote:


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.


On Feb 25, 2007, at 10:00 AM,  michael.poulin@uk.fid-intl.com 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

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