Re: [soa-rm] FYI: BEA SOA Reference Diagram

[Duane Nickull <dnickull@adobe.com>]

John:

The sentence was probably a bit short since it has been discussed many 
times before.  The long version is:

"We are building a reference model that captures the core elements, 
concepts and aspects of SOA, their externally visible properties and the 
relationships amongst them described in an abstract manner."

The key aspect of this is the abstract nature.  This is only the first 
piece of work to provide a framework for developing concrete SOA.  A RM 
used in a framework may be used to write a more concrete yet generalized 
reference architecture or one may skip this step and use the RM as a 
template to architecture a highly specialized SOA.

I hope this clears it up.

Cheers!

Duane

John Harby wrote:

>I can live with the diagram but I definitely don't like this statement
>for a deliverable:
>
>"Instead, we are examining (!) the concepts and relationships that are
>important in modeling SOAs."
>
>
>
>On 5/18/05, Duane Nickull <dnickull@adobe.com> wrote:
>  
>
>>Frank is right.  We are not writing an SOA, we are building a reference
>>model.  I would refer all back to my earlier posts on this subject.
>>
>>Reference models generally avoid any concrete detail, such as showing
>>two services.  In abstract, there are no multiple concrete  instances of
>>services.
>>
>>Case in point - look at the ISO reference model (7 layer stack).  It is
>>a communication stack.  It's whole purpose is to act as a reference
>>model for building networks yet it does not show two "things"
>>communicating.
>>
>>I am not saying the BEA bits are not useful.  We just need to keep
>>vigilant in the concepts being abstract.
>>
>>For those who wish to work on a SOA Reference Architecture, this is
>>probably a logical next sub project once the RM is complete.
>>
>>Duane
>>
>>Frank McCabe wrote:
>>
>>    
>>
>>>The diagram does not help me very much ...:)
>>>
>>>I agree, however, that combining services seems to me to be an
>>>integral part of service oriented architectures.
>>>
>>>However, we are *not* doing an SOA!!! At least, that is my
>>>understanding.
>>>
>>>Instead, we are examining (!) the concepts and relationships that are
>>>important in modeling SOAs.
>>><SNIP>
>>>      
>>>
>>    
>>