OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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


Works for me.

Rex

At 1:58 PM +0200 5/19/05, Gregory A. Kohring wrote:
>Here is a new draft of figure 2-1 incorporating all the suggested
>changes to date. Let's use this as the basis for further discussions.
>
>-- Greg
>
>
>Peter F Brown wrote:
>>  Greg:
>>  Sounds better, I agree and would be happy to keep that definition. I'd still
>>  like to see some other reactions (we might have to wait until the Americas
>>  awake...) to my other point though: should this aspect be in the RM at all,
>>  or are metadata (or other "free text" policies or service descriptions,
>>  etc.) only part of specific and/or reference *architectures* rather than the
>>  RM?
>>
>>  -Peter
>>  -----Original Message-----
>>  From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
>>  Sent: 19 May 2005 11:04
>>  To: peter@justbrown.net
>>  Cc: 'SOA-RM'
>>  Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure
>>  2-1
>>
>>  Yes "realized as" is not the right phrase here. Would you support
>>  "documented in"?
>>
>>  -- Greg
>>
>>
>>  Peter F Brown wrote:
>>
>>>I like this diagram more. I think it's closer to my understanding at
>>>least of wherewe want to go.
>>>
>>>My only question is: are the semantics *only* realised as metadata? Or
>>>more
>>>precisely: in a Reference Model, are the semantics of the service
>>>realised at all? Surely the metadata "realisation" is part of a
>>>reference architecture not a reference model?
>>>
>>>-Peter
>>>
>>>-----Original Message-----
>>>From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
>>>Sent: 19 May 2005 09:24
>>>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.
>======================================================================
>
>Attachment converted: Macintosh HD:figure1 2.png (PNGf/«IC») (000673E7)


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]