[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Done! Duane Nickull wrote: > May I ask that this also be submitted to KAVI and also a reference from > the "Service Description" section of the strawman be made. > > Thanks > > Duane > > Gregory A. Kohring wrote: > >> Francis, >> >> You are correct, the last diagram I sent did not reproduce the >> semantics of your previous diagram. The one attached to this message >> does. It shows contract being realized as metadata as in your original >> diagram. >> >> Note: I don't understand your discussion about the "document" >> "describing" the contract. The relationship you depict in your >> original diagram is one of "realization" not description and the >> latter seems to me more appropriate in this case. >> >> -- Greg >> >> >> Francis McCabe wrote: >> >> >>> The problem with this diagram is that it assumes that a contract *isa* >>> metadata. I could not disagree more. And UML makes this awkward. >>> >>> The relationship between a contract (which is an abstract entity) and >>> its description (which is a document) is one of *describes*. >>> >>> On the other hand, a QoS agreement *isa* contract. >>> >>> I also included the stuff on choreography, business policy etc. >>> >>> I believe that choreography is part of the syntax -- it is part of what >>> you need to know about the mechanics of using the service. But it is >>> separate from business logic and semantics. >>> >>> Frank >>> >>> >>> >>> On Apr 20, 2005, at 2:09 AM, Gregory A. Kohring wrote: >>> >>> >>> >>>> OK, here is a slightly different view using UML. In this view >>>> metadata is the higher level abstraction, while contract is a more >>>> specialized abstraction. >>>> >>>> -- Greg >>>> >>>> Duane Nickull wrote: >>>> >>>> >>>> >>>>> Francis: >>>>> >>>>> Cool! This is perhaps a place where using UML to avoid ambiguity >>>>> may be >>>>> good. >>>>> >>>>> If I read your diagram, it asserts that "realized as" implies an >>>>> "abstract-concrete" association. I had viewed that the other concepts >>>>> are more of a "can be aggregated as part of" association. My >>>>> observation is that usually the abstract-concrete association is often >>>>> used for mapping a specific protocol or specification to a concept >>>>> in a >>>>> reference model or reference architecture. >>>>> I guess the question we need to consider is "what is the association >>>>> between the higher level abstract concept of metadata and specialized >>>>> metadata concepts?". >>>>> >>>>> Anyone care to take a stab at this as a UML class diagram (or >>>>> answering >>>>> the question)? >>>>> >>>>> Cheers (and beers next week) >>>>> >>>>> Duane >>>>> >>>>> >>>>> >>>>> >>>>> Francis McCabe wrote: >>>>> >>>>> >>>>> >>>>>> I prefer the following diagram :) >>>>>> >>>>>> >>>>>> Frank >>>>>> >>>>>> On Apr 19, 2005, at 9:51 AM, Duane Nickull wrote: >>>>>> >>>>>> >>>>>> >>>>>>> <Drawing1.png> >>>>>>> >>>> >>>> <metadata.pdf> >>>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]