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


Not sure I understand here; in my view, these are two separate things
that are related, in that one describes the other, but they are not of
types such that one could be a specialization of another...


Kathryn Breininger
Boeing Library Services
425-965-0182 phone





-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: Wednesday, April 20, 2005 1:48 PM
To: Francis McCabe
Cc: Gregory A. Kohring; Ken Laskey; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Architectural Scope of Reference Model


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]