RE: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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