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


Kathryn:

You are right.  After analyzing my response and comments to it, I wish 
to withdraw my assertion.  I like the last one sent by Gregory.

Duane

Breininger, Kathryn R wrote:

>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]