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

[Duane Nickull <dnickull@adobe.com>]

Apologies on previous email - I didn't read my inbox in order. Didn't 
realize this was submitted already.

Duane

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>
>>>>
>>>> 
>>>>
>>>>        
>>>>
>
>  
>
>
> ------------------------------------------------------------------------
>

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Chair - OASIS Service Oriented Architecture Reference Model Technical Committee - 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Adobe Enterprise Developer Resources  - http://www.adobe.com/enterprise/developer/main.html
***********