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] What is NOT an SOA?


Below I contribute the primary issue with each of the 3 approaches that
I believe gives SOA an advantage.

Joe

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

PRIMARY ISSUE: Typically RPC (synchronous interaction) only. Both
synchronous and asynchronous interactions are needed. (NOTE: Secondary
issues include proprietary nature and potentially up-front investment
cost).

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

PRIMARY ISSUE: Too fine-grained for WWW-based interaction.

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

PRIMARY ISSUE: A client is a client, a server is a server. Need services
that can act as both clients (service consumers) and servers (service
providers).

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

> 
> 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.
> ======================================================================
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]