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?


There have certainly been discussions in which SOA was compared to other
paradigms, but I do not recall anything as strong as what you are
stating, which is that folks are advocating starting from one particular
paradigm and extending it. 

Can you please provide URLs from our archives that discuss this?

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 9:25 AM
> To: Chiusano Joseph
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] What is NOT an SOA?
> 
> SOA is not a revolutionary technology void of antecedents; it 
> is an evolutionary technology and in order to understand what 
> it is we need to understand where it came from.
> 
> The three architectural approaches listed are possible bases 
> from which to evolve an SOA RM. We need to pick one (or one 
> of something
> else) as the primary base. We cannot pick all 3! Otherwise 
> our SOA RM will encompass everything and nothing will not be 
> an SOA leaving us with a meaningless RM.
> 
> In part this process is already taking place. Duane and his 
> supports seem to be starting from the CBA and are therefore 
> justified in their belief that one only needs to extend the 
> concept of the "component" to that of "service" in order to 
> arrive at a RM for SOA.
> 
> Rebekah and the "community" supports seem to using the DOA as 
> their starting point and are therefore justified in stating 
> that the so-called "fabric" should be part of the RM.
> 
> Finally, there are some who would see us starting from CSA 
> and think the RM should include the concepts of service and 
> consumer, but very little else.
> 
> 
> 
> It appears then, that were we begin may determine our destination...
> 
> 
> 
> -- Greg
> 
> 
> 
> 
> Chiusano Joseph wrote:
> > 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.
> >>============================================================
> ==========
> >>
> > 
> > 
> 
> 
> --
> ======================================================================
> G.A. Kohring
> C&C Research Laboratories, NEC Europe Ltd.
> ======================================================================
> 


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