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, Figure2-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.
======================================================================


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