[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
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]