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

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

Clarification: It is not WS-Policy, it's WS-RM Policy[1], which is built
on WS-Policy. Sorry for the mixup. Perhaps WS-Policy might follow...

Joe

[1] http://xml.coverpages.org/ni2005-04-19-a.html

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:45 PM
> To: Chiusano Joseph
> Cc: SOA-RM
> 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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> 
>