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