[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, Figure2-1
Duane, Do you have a specific url for a guide to Mind Maps? Ciao, Rex At 6:49 AM -0700 5/19/05, Duane Nickull wrote: >Gregory et al: > >In mind maps, arrows are often used by convention to denote >unilateral labelled associations. Removing them creates a bilateral >labelled association. It does not indicate process. > >Duane > >Gregory A. Kohring wrote: > >>Here is a new draft of figure 2-1 incorporating all the suggested >>changes to date. Let's use this as the basis for further discussions. >> >>-- Greg >> >> >>Peter F Brown wrote: >> >>>Greg: >>>Sounds better, I agree and would be happy to keep that definition. I'd still >>>like to see some other reactions (we might have to wait until the Americas >>>awake...) to my other point though: should this aspect be in the RM at all, >>>or are metadata (or other "free text" policies or service descriptions, >>>etc.) only part of specific and/or reference *architectures* rather than the >>>RM? >>> >>>-Peter >>>-----Original Message----- >>>From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de] Sent: 19 >>>May 2005 11:04 >>>To: peter@justbrown.net >>>Cc: 'SOA-RM' >>>Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure >>>2-1 >>> >>>Yes "realized as" is not the right phrase here. Would you support >>>"documented in"? >>> >>>-- Greg >>> >>> >>>Peter F Brown wrote: >>> >>> >>> >>>>I like this diagram more. I think it's closer to my understanding >>>>at least of wherewe want to go. >>>> >>>>My only question is: are the semantics *only* realised as metadata? Or more >>>>precisely: in a Reference Model, are the semantics of the service >>>>realised at all? Surely the metadata "realisation" is part of a >>>>reference architecture not a reference model? >>>> >>>>-Peter >>>> >>>>-----Original Message----- >>>>From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de] >>>>Sent: 19 May 2005 09:24 >>>>To: Francis McCabe >>>>Cc: SOA-RM; dnickull@adobe.com; mattm@adobe.com >>>>Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure >>>>2-1 >>>> >>>>Frank, >>>> >>>>If I understand you correctly, then in your view there is little >>>>to be gained by distinguishing between syntaxt and semantics at >>>>this level. >>>>Hence, the "Service Description" is purely semantics. >>>> >>>>Attached is another diagram which depicts this idea. Is this >>>>consistent with your ideas? >>>> >>>>-- Greg >>>> >>>>Francis McCabe wrote: >>>> >>>> >>>> >>>> >>>>>While I like the direction in which this is going, I have a couple of >>>>>issues: >>>>> >>>>>1. I do not see semantics as being inside service description. >>>>>Semantics is an abstract concept that may be referred to but is >>>>>not contained in any description. >>>>>2. I am not sure why data model is broken out in the way >>>>>suggested. To me, tehe data model is an asepct of the semantics >>>>>of the service. >>>>>3. I do not see a hard and fast distinction between syntax and >>>>>semantics. Again, any syntactic constraints are simply part of >>>>>the overall semantics. >>>>> >>>>>The *reason* for this is that while it is tempting to equate >>>>>semantics with application semantics, that is not, in fact, a >>>>>good slope to slip down. >>>>> >>>>>Once you liberate yourself from that misconception, one beings >>>>>to see all kinds of possibilities. For example, for an >>>>>encryption/decryption service, its entire semantic model >>>>>consists of messages with encryption markers etc. etc. Is that >>>>>syntax? Depends on your point of view; to my mind it is >>>>>semantics of a simple service. >>>>> >>>>> >>>>>Frank >>>>> >>>>> >>>>>On May 13, 2005, at 12:01 AM, Gregory A. Kohring wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Yes, this looks much better. Attached is a slight variation >>>>>>which moves the semantics into the description. At one time, >>>>>>"syntax" was also explicitly mentioned as being part of the >>>>>>description. Has that been dropped? >>>>>> >>>>>>-- Greg >>>>>> >>>>>>Duane Nickull wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Does something like this make more sense than a stack diagram. This is >>>>>>>uses a multi-layered approach to group things and reduce the >>>>>>>number of lines. >>>>>>> >>>>>>>Duane >>>>>>> >>>>>>>Duane Nickull wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>The issue we had with the concept map is we ended up with a >>>>>>>>proliferation of arrows for items like "semantics" and >>>>>>>>security since >>>>>>>>they are omni-present. We tried various other depictions and finally >>>>>>>>came to the stack. I agree that the stack alone is not >>>>>>>>sufficient and also lends itself to ambiguity so we agreed to >>>>>>>>place some text by >>>>>>>> >>>>>>>> >>>>it. >>>> >>>> >>>> >>>> >>>>>>>>There are standard conventions for interpreting stack >>>>>>>>diagrams. For example - layers in the stack are only able to >>>>>>>>talk to adjacent layers. Layer n can interact with n-1 and >>>>>>>>n+1, but not n+2. >>>>>>>> >>>>>>>>The position of the vertical layers indicate they are >>>>>>>>relevant to each horizontal layer they are adjacent to. >>>>>>>> >>>>>>>>In stack diagrams, there is no named associations present so >>>>>>>>it is ambiguous. >>>>>>>> >>>>>>>>Accordingly, one can infer the following from the diagram in 2.1 >>>>>>>> >>>>>>>>Service descriptions (are associated with) services Policies >>>>>>>>(are associated with) service descriptions Contracts (are >>>>>>>>associated >>>>>>>>with) policies data models (are associated with) contracts >>>>>>>>semantics (are associated with) service descriptions, >>>>>>>>policies, contracts and data models. >>>>>>>>Services, Service descriptions, policies, contracts and data >>>>>>>>models may all be discoverable and their presence and >>>>>>>>availability known. >>>>>>>> >>>>>>>>What I do not like is that it also separates the data model >>>>>>>>from the service description and separates the contract from >>>>>>>>the service description. >>>>>>>> >>>>>>>>It may be better to go with a layered concept map. >>>>>>>>Duane >>>>>>>> >>>>>>>> >>>>>>>> >> >> >> >> >>------------------------------------------------------------------------ -- 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]