[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 believe that the Policy from WS-RM is a binding to WS-Policy for WS- RM. I wouldn't read in to far. -matt On 23-May-05, at 5:33 PM, Chiusano Joseph wrote: > 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]