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


May I ask that this also be submitted to KAVI and also a reference from 
the "Service Description" section of the strawman be made.

Thanks

Duane

Gregory A. Kohring wrote:

>Francis,
>
>You are correct, the last diagram I sent did not reproduce the
>semantics of your previous diagram. The one attached to this message
>does. It shows contract being realized as metadata as in your original
>diagram.
>
>Note: I don't understand your discussion about the "document"
>"describing" the contract.  The relationship you depict in your
>original diagram is one of "realization" not description and the
>latter seems to me more appropriate in this case.
>
>-- Greg
>
>
>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]