[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
+1 At 10:35 AM -0700 5/20/05, Duane Nickull wrote: >Gregory: > >I would like to suggest that the arrows be added >back in to denote more specific associations. > >1. Between Service and Service Description - >since a service has a service description, and >the inverse is true, let's leave the arrow out. >If we do have an arrow, I would be tempted to >use the UML dependency convention to show that a >service description should not exist without a >service. Cardinality is assumed to be exactly >one in such instances. >2. Between Service Description and Metadata - a >service description "is" metadata IMO. Not sure >if we have to have a specific component called >metadata. A service description is a >"specialization" of the generalized concept of >meta data. I would be tempted to use the white >box arrow from UML to denote the >specialized-generalized association paradigm >here. >3. Between metadata and discover ability, >presence and availability (DPA) - not sure if >"enables discover ability is the best way to >express this since they are not both nouns. One >is a noun, the other is a concept. Accordingly, >the use of the word "discovery" in the box >implies to me that it does enable discovery in >some manner. I am not sure what to suggest >here. perhaps just a straight line with no >arrows or the arrow pointing back at the meta >data. >4. The line between data model and policy and >contract - I am not sure that it is necessary to >even have this line. Not all contracts may be >explicit?? > >Thoughts? > >Duane > >Rex Brooks wrote: > >>While this is more accurate, it is verging on >>being too concrete, though I would certainly >>allow it (Remember my initial position was to >>start from scenarios and use-cases and abstract >>upwards rather than model top-down as we are >>doing). >> >>Ciao, >>Rex >> >>At 9:39 AM +0200 5/20/05, Gregory A. Kohring wrote: >> >>>Duane, >>> >>>I agree that metadata has semantics, but in this case we are >>>interested in the semantics of the service, not the metadata. >>>Any diagram of this type will get too crowed if we have to >>>explicitly depict every possible relationship; therefore, we >>>need to restrict ourselves to the most important relationships. >>> >>>I think we now agree that metadata "documents" or "describes" the >>>semantics; however, a related question is >>>whether or not the documented metadata, as opposed to the semantics, >>>"enables discoverability". In other words, if semantics is ubiquitous >>>as you say, then semantics cannot by itself enable discoverability >>>(if it could then everything would already be discoverable), >>>rather it is the documentation of the semantics which >>>enables discoverability. >>> >>>Following this line of thought, I would propose the attached diagram. >>> >>>-- Greg >>> >>>Duane Nickull wrote: >>> >>>> Semantics are ubiquitous. No matter if they are explicit or implicit, >>>> they are present. >>>> Meta data has semantics. >>>> Metadata is a set of data declaring details pertaining to another set of >>>> data. >>>> I am not convinced that semantics are realized as metadata. In fact, in >>>> a reference model, nothing is realized - it is all abstract. >>>> >>>> Duane >>>> >>>> >>>> Gregory A. Kohring wrote: >>>> >>>>> 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. >>>====================================================================== >>> >>>Attachment converted: Macintosh HD:figure1a.png (PNGf/«IC») (0006807C) -- 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]