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?


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

I would think we would choose aspects of each plus possibly some
additional features. For example, all of these employ distributed
objects which is a practice that has been marked as an antipattern.


On 5/31/05, Gregory A. Kohring <kohring@ccrl-nece.de> wrote:
> 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]