[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
WS-Policy is more a set of vocabulary identifications or how to identify vocabularies and rules about assertions and how to make them and interpret them, especially relating to using other standards,such as WSS, WSDL, SOAP, UDDI, (not much allowance for ebXML), XML Digital Signatures, etc. I was asked about what I considered not as vital as policy, contract and data, and I noted that one could claim almost all of the specific items I mentioned as policies of some sort, if one was so inclined, I qualified my brief sample list. While most of our work takes Web Services almost as a given, I can understand thinking that alignment with WS-Policy, and many other specifications such as those mentioned above, is important, but I think that misses some important areas, especially in the area of IM, email and whatever XMLP finally turns out to be. At out level of abstraction, I think we need to be at least somewhat protocol and related-standard independent, too. Note, I said somewhat. Ciao, Rex At 12:34 AM -0400 5/22/05, Ken Laskey wrote: >While we shouldn't pretend to work in a vacuum, the RM concepts are >not constrained by other standards and certainly not by ones that >are under development and may benefit from thoughts on a broader >context in which they should operate and for which they should >provide support. > >Ken > > >On May 21, 2005, at 9: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 -- 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]