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


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



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