[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
I agree. This graphic will be scrutinized by our peers which places a huge emphasis on getting it right. Duane Michael Stiefel wrote: > I am satisfied. > > While I still have questions about the processing model (see my > response to Francis), I think this is good enough for the moment. > > This is an important graphic. I, like I am sure many of you, give > talks that try to explain what a SOA is. This graphic could be very > useful in these talks so the effort that has been put into it will pay > off. If people find it compelling, they might then actually go and > look at the RM. > > Michael > > > At 07:07 PM 5/20/2005, 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> >>>>>>> >>> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]