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:
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:]
Sent: 25 February 2007 22:21
To:
Cc:
Subject: Re: [soa-rm-ra] RE: updated
service description
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
