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
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
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
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" <klaskey@mitre.org>
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:danny_thornton2@yahoo.com] Sent:
Thursday, October 11, 2007 3:55 PM To: Scott Came; soa-rm-ra@lists.oasis-open.org 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 <scott.came@search.org>
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:klaskey@mitre.org] Sent:
Thursday, October 11, 2007 11:09 AM To: Scott Came Cc: soa-rm-ra@lists.oasis-open.org 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
|