[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 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 >>>> >>>> >>> >>> >>> >>> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]