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