[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
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]