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>
