[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
While we shouldn't pretend to work in a vacuum, the RM concepts are not constrained by other standards and certainly not by ones that are under development and may benefit from thoughts on a broader context in which they should operate and for which they should provide support. Ken On May 21, 2005, at 9:23 PM, Michael Stiefel wrote: > 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 > > > ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]