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


So what would be a constraint that is not as vital as policy, contract, and 
data?

Michael

At 07:14 PM 5/20/2005, Rex Brooks wrote:
>At 6:18 PM -0400 5/20/05, Michael Stiefel wrote:
>>How is the data model a constraint?
>
>How is not?
>
>>If everything is constraint, what is being constrained?
>
>What the service is and does and how it does it, how it can be consumed, 
>by whom, etc. Everything is a constraint, and I would be happy to see it 
>join semantics in the wings as omnipresent.
>
>But it does serve the purpose of implying that some constraints are more 
>vital to the concept of a service than others, and I think policy, 
>contract and data model all stand up to that test.
>
>Ciao,
>Rex
>
>>Michael
>>
>>At 05:56 PM 5/20/2005, Francis McCabe wrote:
>>>I would prefer to see
>>>1. policy, contract linked together -- reflecting the contract=agreed
>>>policy idea.
>>>2. data model is one of the constraint types, like policy and contract
>>>3. we should also mention process model if we are going to call out
>>>the data model.
>>>
>>>Being a total pedantic, policy, agreement, process model, data model
>>>together characterize the semantics; however, the metadata/service
>>>description is a projection of that semantics (there may be several
>>>service descriptions for one service).
>>>
>>>Frank
>>>
>>>
>>>On May 20, 2005, at 2:44 PM, 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>><CoreRM6.png>
>
>
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-849-2309




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