OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm] Architectural Scope of Reference Model


I agree.  The metadata describes stuff about the contract; it is not the
contract.  Think of your University online catalog; the online catalog
describes items you can access through the system.  This is the
*metadata* about the stuff.  The actually items are retrieved through a
link to an electronic version of something, or a physical container
pulled from a shelf or drawer.


Kathryn Breininger
Boeing Library Services
425-965-0182 phone





-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: Wednesday, April 20, 2005 10:38 AM
To: Gregory A. Kohring
Cc: Duane Nickull; Ken Laskey; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Architectural Scope of Reference Model


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]