[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]