Ken,
I agree with your thoughts that policies and contracts
are referenced from the Service Description and can be
fully defined elsewhere.� Many people in the industry
tend to think of the Service Description as a
contract.� The reasoning behind this is because it can
be said the consumer has to abide by the Service
Description and therefore it is a contract.� At the
implementation level, people often equate a WSDL to a
contract.� I see this view of a SOA contract as a
half-truth.� As stated in one of Michael�s previous
e-mails, WSDL does not capture the business meaning of
a service. The meaning of contract is rooted more in
the social structure than anything at the
implementation level.� In business a contract is a
legally binding agreement between two or more parties.
�It may or may not be personalized, it may be human
enforceable, it may be electronically enforceable.�
For electronically enforceable policies and contracts,
the computing mechanisms that enforce a policy or a
contract can be the same. �
One person's stated policy can be another person's
enforced contract.� Not abiding by stated policies can
have real world effects just like not abiding by a
contract.� Loss of a job for not following company
policy for example.� It is difficult for me to see a
clear distinction between a policy and a contract
other than what is stated in the OASIS SOA RM.� A
contract and a policy have a clear distinction at the
level of the social structure.� At the implementation
level, just tell me the rules that need to be
enforced, whether it is a policy or a contract doesn't
matter to me.
The Service Description encompasses more about the
social structure than the contracts so I do not put
contracts at the same level as Service Description.�
The contract is a subset of Service Description if the
contract is part of the Service Description.�
Discussions about contracts and policies and Service
Descriptions will tend to swirl around the following
three questions:� What is the distinction at the
business level between a policy and a contact?� What
is the distinction at the implementation level between
a policy and a contract?� Where do the various forms
of a contract fit in relation to the Service
Description? �
Danny
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,
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
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
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time�
with the Yahoo! Search movie showtime shortcut.