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


Greg:

Would you mind throwing together a mind map for us to replace this 
graphic?  If done properly, I agree that it could be more illustrative 
than a simple block diagram where relationships are not obvious.

-Matt

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



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