[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
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 >>>>>>> >>>>>>> >>>>>>> > > > > > > ------------------------------------------------------------------------ >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]