[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1
You mean because of the arrows? Would it help if we
removed
the arrow heads?
-- Greg
Chiusano Joseph wrote:
>
Will some readers perceive this as looking very much like a process
>
diagram (forget the labels for a second), and hence our message may be
>
lost?
>
> Joe
>
> Joseph Chiusano
> Booz Allen
Hamilton
> Visit us online@ http://www.boozallen.com
>
>
>
>>-----Original
Message-----
>>From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
>>Sent:
Thursday, May 19, 2005 3:24 AM
>>To: Francis McCabe
>>Cc:
SOA-RM; dnickull@adobe.com; mattm@adobe.com
>>Subject: Re: [soa-rm]
[issue:structure] draft 07, sect 2,
>>line 201, Figure
2-1
>>
>>Frank,
>>
>>If I understand you
correctly, then in your view there is
>>little to be gained by
distinguishing between syntaxt and
>>semantics at this level.
Hence, the "Service Description" is
>>purely
semantics.
>>
>>Attached is another diagram which depicts this
idea. Is this
>>consistent with your ideas?
>>
>>--
Greg
>>
>>Francis McCabe
wrote:
>>
>>>While I like the direction in which this is
going, I have a
>>
>>couple
of
>>
>>>issues:
>>>
>>>1. I do not
see semantics as being inside service description.
>>>Semantics is
an abstract concept that may be referred to but is not
>>>contained
in any description.
>>>2. I am not sure why data model is broken out
in the way
>>
>>suggested.
>>
>>>To
me, tehe data model is an asepct of the semantics of the
service.
>>>3. I do not see a hard and fast distinction between
syntax and
>>>semantics. Again, any syntactic constraints are simply
part of the
>>>overall semantics.
>>>
>>>The
*reason* for this is that while it is tempting to
equate
>>>semantics with application semantics, that is not,
in fact, a good
>>>slope to slip
down.
>>>
>>>Once you liberate yourself from that
misconception, one
>>
>>beings to
see
>>
>>>all kinds of possibilities. For example, for
an
>>
>>encryption/decryption
>>
>>>service,
its entire semantic model consists of messages
with
>>>encryption markers etc. etc. Is that syntax? Depends
on
>>
>>your point of
>>
>>>view;
to my mind it is semantics of a simple
service.
>>>
>>>
>>>Frank
>>>
>>>
>>>On
May 13, 2005, at 12:01 AM, Gregory A. Kohring
wrote:
>>>
>>>
>>>>Yes, this looks much
better. Attached is a slight variation which
>>>>moves the
semantics into the description. At one time,
>>
>>"syntax"
was
>>
>>>>also explicitly mentioned as being part of
the
>>
>>description. Has
that
>>
>>>>been
dropped?
>>>>
>>>>--
Greg
>>>>
>>>>Duane Nickull
wrote:
>>>>
>>>>
>>>>>Does
something like this make more sense than a
stack
>>
>>diagram. This
is
>>
>>>>>uses a multi-layered approach to group
things and reduce
>>
>>the
number
>>
>>>>>of
lines.
>>>>>
>>>>>Duane
>>>>>
>>>>>Duane
Nickull
wrote:
>>>>>
>>>>>
>>>>>
>>>>>>The
issue we had with the concept map is we ended up with
a
>>>>>>proliferation of arrows for items like "semantics"
and
>>
>>security
since
>>
>>>>>>they are omni-present.
We tried various other
>>
>>depictions and
finally
>>
>>>>>>came to the stack. I agree
that the stack alone is
not
>>
>>sufficient
>>
>>>>>>and
also lends itself to ambiguity so we agreed to place
>>
>>some
text by it.
>>
>>>>>>There are standard
conventions for interpreting stack
diagrams.
>>>>>>For example - layers in the stack are
only able to talk
>>
>>to
adjacent
>>
>>>>>>layers. Layer n can
interact with n-1 and n+1, but not
n+2.
>>>>>>
>>>>>>The position of the
vertical layers indicate they are
>>
>>relevant
to
>>
>>>>>>each horizontal layer they are
adjacent to.
>>>>>>
>>>>>>In stack
diagrams, there is no named associations
>>
>>present so it
is
>>
>>>>>>ambiguous.
>>>>>>
>>>>>>Accordingly,
one can infer the following from the diagram in
2.1
>>>>>>
>>>>>>Service descriptions
(are associated with) services
>>
>>Policies
(are
>>
>>>>>>associated with) service
descriptions Contracts (are associated
>>>>>>with) policies
data models (are associated with) contracts
>>>>>>semantics
(are associated with) service descriptions,
policies,
>>>>>>contracts and data
models.
>>>>>>Services, Service descriptions, policies,
contracts and
>>
>>data
models
>>
>>>>>>may all be discoverable and their
presence and
>>
>>availability
known.
>>
>>>>>>What I do not like is that it also
separates the data model from
>>>>>>the service description
and separates the contract from
>>
>>the
service
>>
>>>>>>description.
>>>>>>
>>>>>>It
may be better to go with a layered concept
map.
>>>>>>Duane
>>>>>>
>>
>>
>>
>>--
>>======================================================================
>>G.A.
Kohring
>>C&C Research Laboratories, NEC Europe
Ltd.
>>======================================================================
>>
>
>
--
======================================================================
G.A.
Kohring
C&C Research Laboratories, NEC Europe
Ltd.
======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]