Agree
- Michael
A couple clarifications:
- I expect a single description for a single item in a single domain and
the content of that description will evolve over time to meet the changing
needs of the domain (and where I'll scrupulously avoid defining
"domain").
- Descriptions to "leverage ... each other" has several aspects.
For a single service description, I will likely link to descriptions of other
things, such as policies, that have been independently developed but which I
want to apply. For a single resource, there may be overlapping
descriptions in different domains that emphasize important characteristics for
the individual domain, but it may be useful for one description to point to
its "siblings" as a potential source of additional information.
- As for "too much information", having focused descriptions that can
indicate where additional information may reside could be helpful because the
consumer wouldn't be stuck with every possible detail but would have
suggestions of where to look if more was needed.
I don't think we have any fundamental disagreements but we have surfaced
several angles that I hope we remember to include as appropriate in the final
write-up.
Ken
On Oct 17, 2007, at 5:05 AM, Poulin, Michael wrote:
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
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7151 Colshire Drive
fax: 703-983-1379
McLean VA 22102-7508
|