[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
I am not sure what you mean by an abstract metadata class. There is a real distinction between metadata and contracts -- neither is a specialization of the other (IMO). Think of human contracts: if you sign a contract, and then accidentally pour some ink over the paper that you signed; you still have a contract. All that the ink did was destroy the representation of the contract. This is what I meant earlier about UML -- it strongly encourages people to think in terms of specialization. But that is not the only relationship of interest. Frank On Apr 20, 2005, at 1:47 PM, Duane Nickull wrote: > Would it be fair (and legal) to state that "contract" is a > specialization of the abstract metadata class and also stereotype it > as an abstract class? > > Duane > > > 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> >> >> > > -- > *********** > Senior Standards Strategist - Adobe Systems, Inc. - > http://www.adobe.com > Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ > Adobe Enterprise Developer Resources - > http://www.adobe.com/enterprise/developer/main.html > *********** >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]