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

[Rex Brooks <rexb@starbourne.com>]

If all we are describing is the service side of 
the implied transaction, this is workable. I'm 
still not very happy with it, for the same 
reasons of wanting more explicit relationships, 
but I will have to look at it closer within the 
context of the description, and live with it a 
while.

Ciao,
Rex

At 2:44 PM -0700 5/20/05, Duane Nickull wrote:
>Michael:
>
>Thanks - I tried it horizontally and for some 
>weird reason, it seems to resonate better.
>
>If we can get Frank's sign off and no one else 
>has any opposition, maybe we can use this one?
>
>One other thought - should Data Model be larger? 
>In the book Documenting Software Architectures, 
>I seem to recall some conversation about size 
>mattering (yeah yeah). Accordingly, I enlarged 
>the data model to give it more presence.  How 
>does this look?  See attached Core RM6.png
>
>Duane
>
>Michael Stiefel wrote:
>
>>Would going from right to left or left to right 
>>remove any associations of top and bottom as 
>>more natural or more fundamental?
>>
>>Have you ever looked at a globe with the 
>>Southern Hemisphere at the top? To most of us 
>>that live in the Northern Hemisphere it looks 
>>wrong, but of course, from the point of view of 
>>outer space either pole of the globe could be 
>>on top.
>>
>>I like the fact that semantics will be explained on the side.
>>
>>Michael
>>
>>
>>At 02:37 PM 5/20/2005, Duane Nickull wrote:
>>
>>>Here is a rendering based on Greg's diagram 
>>>that accounts for all the comments below.
>>>
>>>- I placed Metadata as a bracket inside the "service description" box.
>>>- Semantics will have to be explained using 
>>>text accompanying this diagram to state that 
>>>they are omnipresent.
>>>- turned the stack upside down so service is 
>>>at the bottom.  To me, it seemed more 
>>>intuitive that the thing that is core is at 
>>>the bottom and the other items are built out 
>>>(up??) from it.  Comments?
>>>- used the UML dependency arrow as the 
>>>convention between service and service 
>>>description to denote that a SD should not 
>>>exist without a service.
>>>- redrew the line between metadata and policy 
>>>/ contract to connect with the outer container 
>>>of "constraints"
>>>- removed the words "enables discoverability" from the association.
>>>
>>>If we use this, we should probably build an 
>>>appendix containing clear and concise rules 
>>>about how to interpret this mind map since it 
>>>borrows association conventions from UML and 
>>>mixes them together with other conventions.
>>>
>>>Comments?
>>>
>>>Duane
>>>
>>>
>>
>>
>
>
>Attachment converted: Macintosh HD:CoreRM6.png (PNGf/«IC») (00068198)


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309