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

[Ken Laskey <klaskey@mitre.org>]

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