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.