RE: [soa-rm] What is NOT an SOA?

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Secondary point: I don't see us as explicitly extending from any type of
paradigm, but rather taking the lessons learned from that paradigm and
incorporating them into our work. An extension of each of the 3
paradigms below would be very time-consuming as we would need to
constantly refer to all of the nuances of each particular paradigm while
extending it.

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de] 
> Sent: Tuesday, May 31, 2005 6:16 AM
> To: soa-rm@lists.oasis-open.org
> Subject: [soa-rm] What is NOT an SOA?
> 
> Duane's challenge to create examples of software 
> architectures which are not SOA still has me a bit puzzled 
> and I wonder if we can reach a better understanding of an SOA 
> by determining the predecessor of the SOA.
> 
> Three possible predecessors to the SOA:
> 
> Distributed Object Architectures
> 
>     Epitomized by CORBA. In a DOA all the constituents
>     are objects and there exists a naming object for finding objects
>     to satisfy a particular request.
> 
> Component Based Architectures
> 
>     Examples include CCA. In a CBA the components have well defined
>     behaviors, standardized interfaces and their granularity should
>     be such as to encourage reuse.
> 
> Client-Server Architectures
> 
>     An FTP server is a good example. In a CSA, the server encapsulates
>     a set of known behaviors and the client knows how to access
>     the server to activate the behaviors.
> 
> 
> If we claim our SOA RM extends DOA, then our SOA RM should 
> contain the extension of an object and the extension of the 
> naming object.
> 
> If we claim our SOA RM extends CBA, then our SOA RM need only 
> contain the extension of a component.
> 
> If we claim our SOA RM extends CSA, then our SOA RM should 
> contain the extension of the client and the server.
> 
> 
> I am sure others can nominate more examples of base 
> architectures to extend from; however, this does not subtract 
> from my conclusion that in order to determine what are the 
> minimum constituents for our SOA RM, we need to determine 
> where we are starting from and what the minimum requirements 
> are to significantly differentiate our SOA RM from the base model.
> 
> 
> -- Greg
> 
> --
> ======================================================================
> G.A. Kohring
> C&C Research Laboratories, NEC Europe Ltd.
> ======================================================================
>