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

["Schuldt, Ron L" <ron.l.schuldt@lmco.com>]

Duane - if you add "Enable interpretation" to the line connected to the Semantics box, I believe you would have a suitable replacement for the multi-layered stack diagram.

Ron


-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: Thursday, May 12, 2005 1:46 PM
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201,
Figure 2-1


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