Title: Re: [soa-rm] Diagram
Sorry if I'm offering this on
the wrong thread, but it's fresh on my mind - regarding service being an action
vs. an object:
I believe that service is (what I will
loosely term) a "dual-representation" concept, in that it has both a noun
representation ("a service") and an action (infinitive) representation ("to
service"). Both representations are valid, and either can be used where
appropriate. Other such concepts are: campaign ("a campaign", "to campaign") and
"box" ("a box", "to box" something up).
The issue then comes down to: which
representation should one use for a concept map? Thinking it through further, it
seems to me that the infinitive representation of such concepts would be very
difficult to represention in a concept map (i.e. how does one really represent
"to service"?), while the noun representation is natural and easy.
As a quick parallel, in the DRM we
(meta)-model information exchanges, representing them using concepts such as
"ExchangePackage", "PayloadDefinition", "Supplier", and "Consumer" (among
others). "Exchange" is also what I would term a dual-representation concept, yet
we (meta)-model it as a noun through the "ExchangePackage" concept and its
related concepts.
My $.02,
Joe
From: Francis McCabe
[mailto:]
Sent: Wed 12/7/2005 6:26 PM
To:
Duane Nickull
Cc: SOA-RM
Subject: Re: [soa-rm]
Diagram
Actually, I think that an error/fault report is a legitimate
RWE!
Perhaps it is not the desired effect... Otherwise if you try
to
distinguish successful interactions from unsuccessful ones you
are
going to get into an awful tangle.
Again, it is not a
question of what needs to be visible. But rather
that visibility is an
inherent aspect of SOA.
Visibility may be enhanced by discovery/descriptions
etc. but is a
separate concept. For one thing, it is inherently
consumer/provider
neutral.
the relationship between service and
interaction is one of usage: to
use a service is to interact with
it.
Keep on trucking
Frank
On Dec 7, 2005, at 3:13 PM,
Duane Nickull wrote:
> I couldn't find an accurate description of
"exchange" in the current
> draft and this was what I inferred. We
may wish to beef it up to
> explain this better.
>
> I thought
about the capability/interaction thing a lot and am not 100%
> sure either
way. It is really only a successful interaction with a
> service that uses
the capability that results in a RWE. An
>
unsuccessful
> interaction results in an error/fault etc. This got
me also asking if
> having an interaction is too concrete? Does this
now mean we have an
> infrastructure if there are two things
interacting. Not sure but
> think
> this needs more
discussion during f2f.
>
> Exchange may be best represented similar
to how UMl class view
> diagrams
> use association
classes. (see attached). The exchange is part of the
>
association class?
>
> The intent on visibility ws to effectively
depict that there are
> certain
> animals that need to be
visible, discoverable etc (the three are
> service, policy and service
descrition). I am not happy either
> with the
> way it
is. Any suggestions for a better way?
>
> I do like this
better than the jigsaw but think it needs refinement.
>
>
D
>
> *******************************
> Adobe Systems, Inc. -
http://www.adobe.com
> Vice Chair -
UN/CEFACT http://www.uncefact.org/
> Chair -
OASIS SOA Reference Model Technical Committee
> Personal Blog - http://technoracle.blogspot.com/
>
*******************************
>
>
> -----Original
Message-----
> From: Francis McCabe [mailto:]
> Sent:
Wednesday, December 07, 2005 2:57 PM
> To: Duane Nickull
> Cc: Ken
Laskey;
> Subject: Re: [soa-rm]
Diagram
>
> Duane:
> It is not the interaction
that results in a real world effect.
> It is the use of the
capability that does.
> Also I don't think its quite accurate
to say that the link between
> interaction and service is exchange. You
interact with a service by
> exchanging information.
>
The execution context includes *everything* needed to support
>
interaction.
> It is not right to say that visibility =
policy+service+description
> (as implied by the nesting. We currently
state that
>
visibility=awareness+willingness+reachability.
>
> Frank
>
P.S. I gave a talk about the RM to OMG yesterday. Went down very
> well.
People like the simplicity.
> P.P.S. Concept maps are very flexible. That
is both an advantage and
> a risk :)
>
>
>
Of course, what is not captured is how the RWE(tm) itself is
>
modeled...
>
> On Dec 7, 2005, at 10:13 AM, Duane Nickull
wrote:
>
>> See new revision.
>>
>> Answering
your and Wes's comments, I have realized I made a gross
>> inconsistent
decision in the graph. If Service description points at
>>
Functionality, then Wes is right and it should also point at policy.
>>
For simplistic sake, I would like to recommend we remove the binary
>>
association between service description and functionality and
>>
state in
>> accompanying text that if the service description
describes
>> aspects of
>> the service, the
functionality represented by the service, along with
>> the policy MAY
be described along with other aspects of a service.
>>
>> In
keeping with the concept of managed transparency, it would be
>> best
to
>> keep this as a MAY IMO.
>>
>>
KISS!
>>
>> Duane
>>
>>
*******************************
>> Adobe Systems, Inc. - http://www.adobe.com
>> Vice Chair -
UN/CEFACT http://www.uncefact.org/
>> Chair -
OASIS SOA Reference Model Technical Committee
>> Personal Blog - http://technoracle.blogspot.com/
>>
*******************************
>>
>>
>>
-----Original Message-----
>> From: Ken Laskey [mailto:]
>> Sent:
Tuesday, December 06, 2005 10:00 AM
>> To: Duane Nickull;
>> Subject: Re: [soa-rm]
Diagram
>>
>> Duane,
>>
>> In general, I
like the diagram but have a few suggested mods:
>>
>> 1.
"Capability Metadata" (not included in current diagram) describes
>> a
Capability, Service Description just describes the
>> Service.
However, as seems appropriate to the service provider, the
>> Service
Description can point to and otherwise reference the
>> Capability
Metadata if that is useful in describing the Service.
>>
>> 2.
More appropriate to say Service accesses Capability rather than
>>
represents.
>>
>> A version hacked in Powerpoint is
attached.
>>
>> Ken
>>
>> At 12:24 PM
12/6/2005, Duane Nickull wrote:
>>> I tried to spin the puzzle
diagram into a pseudo layered stack.
>>>
>>>
D
>>>
>>>
*******************************
>>> Adobe Systems, Inc. - http://www.adobe.com
>>> Vice Chair
- UN/CEFACT http://www.uncefact.org/
>>>
Chair - OASIS SOA Reference Model Technical Committee
>>> Personal
Blog - http://technoracle.blogspot.com/
>>>
*******************************
>>>
>>>
>>
>>
--
>>
>>
---------------------------------------------------------------------
>>
-
>
>> --
>> ---------
>>
/ Ken
>> Laskey
>
>>
\
>> | MITRE Corporation, M/S
H305 phone: 703-983-7934
|
>> | 7515 Colshire
Drive
fax:
>> 703-983-1379 |
>>
\ McLean VA 22102-7508
>> /
>>
>>
---------------------------------------------------------------------
>>
-
>
>> --
>> ----------
>>
<SOA-RM-Model-August2005.png>
>
>
<Drawing15.png>
