[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
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 >>>>>> > -- ====================================================================== G.A. Kohring C&C Research Laboratories, NEC Europe Ltd. ======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]