[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
Sorry Ken - I mixed up the policy specifications (WS-Confusion:p). It was WS-RM Policy, not WS-Policy. However, WS-RM Policy is based on WS-Policy, so perhaps WS-Policy will follow in the future (strictly a hunch). Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Monday, May 23, 2005 5:32 PM > To: SOA-RM > Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, > line 201, Figure 2-1 > > When did this happen and what TC is it in? > > Ken > > At 12:45 PM 5/23/2005, Francis McCabe wrote: > >I did not know that! > >Thanks for the heads up > >Frank > > > >On May 23, 2005, at 9:40 AM, Chiusano Joseph wrote: > > > >>Anything can change now that WS-Policy is being advanced > within OASIS. > >> > >>Joe > >> > >>Joseph Chiusano > >>Booz Allen Hamilton > >>Visit us online@ http://www.boozallen.com > >> > >> > >> > >>>-----Original Message----- > >>>From: Francis McCabe [mailto:fgm@fla.fujitsu.com] > >>>Sent: Monday, May 23, 2005 12:05 PM > >>>To: Michael Stiefel > >>>Cc: Rex Brooks; Duane Nickull; 'SOA-RM' > >>>Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, > line 201, > >>>Figure 2-1 > >>> > >>>WS-Policy's view of policy is also short-sighted. > >>> > >>>Frank > >>> > >>>On May 21, 2005, at 6: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]