Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1

[Francis McCabe <fgm@fla.fujitsu.com>]

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
>>>
>>>
>>>
>>>
>>>
>>> Gregory A. Kohring wrote:
>>>
>>>
>>>> <current>
>>>> Figure 2-1 SOA Architectural Model
>>>> </current>
>>>>
>>>> <suggested>
>>>> Remove the figure.
>>>> </suggested>
>>>>
>>>>
>>>> <notes>
>>>> Sorry, but this figure is rather vacuous. All we see are a bunch of
>>>> rectangles stacked together with no obvious relationship between  
>>>> them.
>>>> Some of the rectangles have an "is-a" relationship to their  
>>>> neighbor,
>>>> while others have a "describes" relationship and some I cannot even
>>>> decipher what the relationship should be.
>>>>
>>>> I understand that people feel UML is too technical for this  
>>>> document,
>>>> however, diagrams like this detract from the document's  
>>>> readibility.
>>>> Try using a concept map if you really want to place a diagram at  
>>>> this
>>>> point.
>>>> </notes>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
> <figure1.png>
>