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

Hi Ken,
let me just to answer your questions about the article.
1. It was written before SOA RM was released and before I was able to look at your draft docs. So, the terminology is different.
2. In particular, my "service function" is quite close to your definition of RM action.
3. My "service component" was everything in the service besides its meta-description and interface(s). In RM, you went to more granular level. So, my answers the same Yes to both your questions. Moreover, my major idea was to label the entire service ( does not matter how complex it is behind the interface) with single (compound) version.
4. What I meant as a SLA is, actually, Service Contract in SOA RA terminology. The SLA is supposed to be measurable while Contract may not be ( though an execution of a Policy may be a check-point OR a binary  measure(?!) ). I 100% agree with yours "It is then up to the client to compare the collected metrics with the SLA and determine fitness for use."
In the article I tried to argue that knowledge of the service interface is NOT enough for the consumer but multiple dependencies of component versions (including interface, end-points etc. ) should not be exposed to the consumer as well.
Thank you for reading the article.
- Michael 

Fidelity Investments - Web Delivery
Phone: +44-173-783-6038
E-mail: michael.poulin@uk.fid-intl.com
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: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 25 February 2007 22:21
To: michael.poulin@uk.fid-intl.com
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] RE: updated service description


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

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