[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
For the record, I do not like this diagram. The correct relationship between a description of a service and the things described is one of reference not containment. The ontology/resource triangle may be relevant here: symbol <---> image <---> thing A description is an image, a URL is a symbol and the semantics (or whatever) is the thing. Things cannot be sent down wires, descriptions can. Frank On May 20, 2005, at 4:07 PM, Duane Nickull wrote: > Michael: > > I see why you are asking the question. If everything is a > constraint within the service description box and nothing is not a > constraint, we do not need to explicitly use the "constraint" box. > It's sole purpose is to group those members of the service > description that are distinguished as "of type 'constraint'" from > those that are not. > > That brings us to..... > > CoreRM8.png > > which looks suspiciously like the first drawing Gregory did ;-) > > Are we there yet? > > Duane > > Michael Stiefel wrote: > > >> But in that sense everything is a constraint. >> >> Frank does view the world that way (see his reply to my comment). >> >> Now if I may be pedantic - making everything a constraint is >> similar to saying that the words in a dictionary definition are a >> constraint because they constrain the way a word is used. While >> that may be ture, nobody thinks of a dictionary definition that >> way, so I am dubious about us looking at our definition of a >> service description that way. >> >> >> Michael >> >> At 06:26 PM 5/20/2005, Duane Nickull wrote: >> >> >>> My view on this is that the data model is a constraint of the >>> information flowing in and out of a service. It may be realized >>> as a schema referenced from a WSDL in WS architecture. >>> These things constraint the way a service is used. >>> >>> Duane >>> >>> Michael Stiefel wrote: >>> >>> >>>> How is the data model a constraint? >>>> >>>> If everything is constraint, what is being constrained? >>>> >>>> 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> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> >> >> <CoreRM8.png> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]