Certainly, a collection of descriptions can show the
service from different perspectives. However, I am not sure what might be a
right recommendation here to the customers who are searching for the service.
That is, customers, in most of the cases, are interested in the service to
fulfil particular function, in particular domain. A knowledge of the service use
in other domains may be as useful for the customer's judgement ( service
selection ) as disturbing ( too much to know and consider ).
I agree with descriptors leverage common resources but
disagree with "and each other". That is, I prefer looking into one descriptor in
my domain of interest than being referenced to another descriptor (in a foreign
domain) for a part of information relevant to my case ( as well as to another
case/domain probably). Or, do you mean another mechanism for 'leveraging each
other' ?
- Michael
From: Ken Laskey [mailto:]
Sent: 16 October 2007 16:53
To: Poulin,
Michael
Cc: soa-rm-ra
Subject: Re: multiple descriptions
[was: [soa-rm-ra] Questions on action m odel]
Michael,
I think the more important point is that the descriptions are not
isolated entities but leverage common resources and each other, so a
collection of descriptions should tell you more (OK, at least as much) about
the subject than you get from any single description.
Ken
On Oct 16, 2007, at 11:44 AM, Poulin, Michael wrote:
Thank you, Ken. I think we have agreed with Danny that
multiple descriptors make sense in multiple business domains/contexts and/or
multiple registries/repositories. This, probably, may be reflected in
the RA.
- Michael
From: Ken Laskey [mailto:]
Sent: 16 October 2007 16:27
To: Michael
Poulin
Cc: Duane Nickull; Scott Came;
Subject:
multiple descriptions [was: [soa-rm-ra] Questions on action
model]
Michael,
I see your discomfort and if all we had were multiple, independently
generated descriptions, this would certainly lead to ambiguity and
contradiction.
I have often talked about a service description as being a table of
contents, so less than the source of many description elements, it is the
collection points of things created for other, related purposes. For
example, I do not see writing policies into each service description but I
see those with expertise in rules systems developing policies in parallel
and the service description author would link to the existing
policies. In the same way, I do not see duplicating my address and
phone number for every service for which I am a responsible party, but I
do see a link to the resource where my contact (and possibly other
personal information) is maintained.
In this way, a different subset of possible description could be
emphasized for different contexts, but the subsets would leverage common
resources for the description elements.
At one time, I advocated the idea of a "complete description" where
the description would explicitly collect the description elements needed
for the context but would provide other links where additional description
sets or description elements could be found. The idea was a given
description would highlight what was needed for the context but there
would be tendrils to the rest of the world where more information
resides.
Ken
On Oct 15, 2007, at 4:43 AM, Poulin, Michael wrote:
Duane wrote: "In an ecosystem of
services, there could potentially
be many service descriptions for a service.
The service description a
consumer uses may be dependent on
the entity the consumer interacts with when they use the service, or it could be
dependent on the particular
context the service description is
provided. Because of unforeseen possibilities for
a service to have multiple service
descriptions, I do not think the
OASIS SOA RA can qualify one service to
one service description."
I
have a lot of concerns about underlined
statements.
1) Service
description gets used as the service definition now. I agree that in an
ecosystem not all information about the service is in the Service
Descriptor. However, in this case, I prefer to recognise that I have
different 'domains' in the ecosystem of services (voice, signs, UDDI,
etc.) where the Service Description is the single unique
one.
2) To
me, the "service description a consumer uses may be dependent on the entity the consumer interacts
with when they use the
service" looks much
more like an execution context and related Service Contract than a
service description. Again, "be dependent on the particular context the service
description is provided" is either
services ecosystem domain specific Description or the EC and Service
Contract.
3) as I
mentioned before, SOA RM states that EC is not a context of service
interaction only ( though in many places it says so ) but also the
context of service execution per se. If we allow "a service to have multiple service
descriptions" (w/o defining concrete conditions where it is possible),
we have to clearly distinguish it from a
service to have multiple service descriptions in multiple service
execution contexts - interaction and execution
ones.
4) I,
personally, dislike the idea of "a
service to have multiple service descriptions", at least, in the
same Service Description Repository. Though this is a lower level
technical implementation detail, it is VERY important for
practical use of SOA and quoted statement above can easily screw it,
which I hate.
-
Michael
Important:
Fidelity Investments International (Reg. No.1448245), Fidelity
Investment Services Limited (Reg. No. 2016555), Fidelity Pensions
Management (Reg. No. 2015142) and Financial Administration Services
Limited (Reg. No. 1629709, a Fidelity Group company) are all registered
in England and Wales, are 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:]
Sent: 12 October 2007 16:49
To: Ken Laskey; Scott
Came
Cc:
Subject:
Re: [soa-rm-ra] Questions on action model
Concur. Look at the cardinality of WSDL.
Not everything is mandatory either. On a purely logical level,
consumers can use only that which they require. It is unlikley
that any one service description artifact would in fact contain
*all* the information required.
At least some info is
known via alternative mechanisms (voice, signs, UDDI,
etc.)
Duane
On 10/11/07 6:22 PM, "Ken Laskey" <>
wrote:
The RM says
The service
description represents the information needed in order to use a
service. In most cases, there is no one “right” description but
rather the elements of description required depend on the context
and the needs of the parties using the associated
entity.
Thus, the implication is
there may be overlapping descriptions relevant to different
contexts.
Ken
On Oct 11, 2007, at 8:08 PM, Scott Came
wrote:
Danny:
I don't personally have a strong
feeling one way or the other on this
issue. I did sense
the "one description" position as the subcommittee
consensus,
however...mostly from reading the RA 0.2
draft.
Thanks.
--Scott
-----Original
Message-----
From: Danny Thornton [mailto:]
Sent:
Thursday, October 11, 2007 3:55 PM
To: Scott Came;
Subject:
RE: [soa-rm-ra] Questions on action
model
Scott,
Thank you for the summarization.
The only statement I
have an exception with is 3, A service has
one
description.
In an ecosystem of services, there
could potentially
be many service descriptions for a
service. The
service description a consumer uses may be
dependent
on the entity the consumer interacts with when
they
use the service, or it could be dependent on
the
particular context the service description
is
provided. Because of unforeseen possibilities for
a
service to have multiple service descriptions, I do
not
think the OASIS SOA RA can qualify one service to
one service
description.
Danny
--- Scott Came <>
wrote:
Subcommittee:
I'd like to
take attempt a summarization of this
thread. Note the
word
"attempt"...please let me know if I've
misconstrued
anything said so
far.
1. The
action model of a service may contain
multiple actions
2.
The actions in a given service's action model
may
produce
distinct real-world effects, meaning that a
consumer
may choose to
interact with (invoke?) some subset
of actions and
not others
3. A service has one
description, but that one
description may make
specific
reference to particular actions in order to
describe
their
individual effects, and it also may specify
specific
policies for
individual actions, though those
specific individual
policies can be
viewed as part of one
whole policy for the service.
4. The process model of a
service shows how a
consumer may interact
with (invoke?)
specific actions in sequence to
accomplish some
business
function aligned with the service's RWE
5. There
may be multiple processes in the process
model,
involving
different sequences and different functions
6. A
consumer may interact with (invoke?) a single
action
to
achieve a particular effect (whether that is a
process
with one step, or
no process, is an issue I suppose)
7.
The mechanism by which a consumer interacts with
a service is
by
invoking an action through message exchange; that
is,
the consumer and
service exchange information (in the form of
a
message) to achieve some
effect
8. Interaction with
different actions can be by
different MEPs
9. The decision
about service boundaries-which of
all possible
actions
should be in a given service's action
model-can be
productively
guided by a set of design principles, which the
RA
may include at some
future time. Principles
should be carefully and
precisely defined.
The
example again is an Employee Time Management
service.
The action
model of this service might consist of four
actions:
add time records,
update existing time
records, delete time records,
and view time
records.
A process model for this service may, for
example,
indicate
that it makes sense to view time records prior
to
updating them. But,
it is also possible to add
time records in
isolation...without any of
the other
actions being involved. The overall RWE
of this service
is
management of employee time, but each action has
a
separate effect of
independent value to a
consumer. There is no
absolute rule
regarding
whether it makes sense to include all four of
these
actions in one
service-without more analysis, it is
not clear
whether this is a "good"
service model or
not. However, there are some
design principles that
an
architect (creator of a concrete architecture)
can
apply in making this
determination: loose
coupling, statelessness,
autonomy,
abstraction,
etc.
Thanks.
--Scott
________________________________
From:
Ken Laskey [mailto:]
Sent:
Thursday, October 11, 2007 11:09 AM
To: Scott Came
Cc:
Subject:
Re: [soa-rm-ra] Questions on action
model
Scott,
Indeed I do not
expect we (and anyone else) will
provide a
definitive
cookbook for defining services. However, it
is
exactly those guiding
principles that I think will be
valuable and with
which the RA should be
consistent.
Thomas Erl's book may provide a good
starting point.
If
anyone can summarize between now and when I
eventually
make it to a book
store (or log into Amazon), we can begin
considering
those.
Note when we mention
principles, we have to do much
more than use terms
which
are familiar but overused and never really
defined. The
RM
specifically took shots at loose-coupling
and
coarse-grained. I also
put agility into that
category. When we state the
principles (assuming
we
can), those SHOULD be phrases that convey enough
meaning that
they
cannot be automatically misconstrued (by accident
or
on purpose) and
then crisply
elaborated.
Again, I'm energized to revise the
service
description model but have a
long list of
household chores to catch up on first.
Keep sending
ideas.
Alternately, you can come over and fix the
lawn
mower.
Ken
On Oct 11,
2007, at 1:35 PM, Scott Came
wrote:
Ken:
Regarding your
#1...
I think this kind of specific guidance is
best
reflected in a set of
principles. I don't
believe there will be a "one
size fits all" set of
rules
that tell you, in every situation, how to
design a
service
properly. The best you can do is identify
the
principal forces at
play-those factors that, at a
minimum, the designer
should at least
consider when
setting service boundaries. Those
forces are
represented
in principles that say what should characterize
a
proper service.
Proper application of these principles
(selecting
among the sometimes
competing forces) requires
the skill of a designer,
but well-stated
principles
accelerate the design process and bound
the
designer's
discretion somewhat, in pursuit of an overall
design
objective.
And not just any old set of
principles will do. SOA
has an overall
purpose-to
increase agility, adaptiveness,
responsiveness to
change-so
===
message truncated
===
________________________________________________________________________
____________
Boardwalk
for $500? In 2007? Ha! Play Monopoly Here and Now (it's
updated
for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
-----------------------------------------------------------------------------
Ken
Laskey
MITRE Corporation, M/S H305
phone: 703-983-7934
7151 Colshire Drive
fax:
703-983-1379
McLean VA
22102-7508
--
**********************************************************************
"Speaking
only for myself"
Blog - http://technoracle.blogspot.com
Community
Music - http://www.mix2r.com
My
Band - http://www.myspace.com/22ndcentury
MAX
2007 - http://technoracle.blogspot.com/2007/07/adobe-max-2007.html
**********************************************************************
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305
phone:
703-983-7934
7151 Colshire Drive
fax: 703-983-1379
McLean VA 22102-7508
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7151 Colshire Drive
fax: 703-983-1379
McLean VA 22102-7508
