[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
You definition of policy does not seem to coincide with policy in the sense that WS-Policy* understands it to be. Michael At 08:45 PM 5/20/2005, Rex Brooks wrote: >Well, that gets difficult, doesn't it, since almost anything can be >brought in under policy, but my first list was expiration, synchronous v. >asynchronous processing, registration, security-both physical and per >protocol, OS, platform, standards compliance, language dependence, flavor >of DBMS, etc, etc. I think of policy in this context to be related to >terms and conditions and legalities, such whether or not a service is >intended to have persistence or only exists during a lifecycle triggered >by an event such as an emergency alerting service or whether a software >unit like an accounting package can be applied to a single department such >as financial services or several departments such as Human Resources, CRM, >ECM, etc. > >Ciao, >Rex > > >At 7:41 PM -0400 5/20/05, Michael Stiefel wrote: >>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 > > >-- >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]