[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Corba vs SOA
Hamid I agree with your differences between the older distributed models, where CORBA is an example, BUT I believe that some of the members of the TC would reject them for inclusion in the RM as being too concrete. For example, loose-coupling has been rejected by some members as being too concrete a concept. IMHO this is one of the distinguishing features that differentiate an SOA from the previous distributed systems. Don On Thu, 2005-05-19 at 15:46 -0700, Hamid Ben Malek wrote: > Frank, > > Using Matt's expression, Corba could be put in the category of "OO + > extra things". Corba is Object-Oriented, has discovery services, > interfaces, language neutral, a communication bus, and so many other > features. However, Corba is definitely NOT SOA. Why? There are many > reasons for this. It suffices to only cite one reason which is related > to the third SOA principle (“Contracts and Schemas”). Corba does not > satify the third principle (actually it does not satify other > principles too). Corba is RPC-based, and the message that goes inside > the wire is a binary OO-RPC call. The limitations of OO-RPC calls for > applications that go beyond the enterprise scope are well known > (problems related to very tight-coupling, versioning problems, etc…). > The third principle in SOA roughly states that the calls between SOA > services and between a client and an SOA service are all XML messages > and that only the contrats and schemas are shared between services and > clients (no RPC interfaces such as those described in Corba by IDL, or > other OO artifats). The third principle ensures loose-coupling through > the use of contracts and schemas. This is not the case in Corba. > > > > Regards, > > > > Hamid. > > > > -----Original Message----- > From: Francis McCabe [mailto:fgm@fla.fujitsu.com] > Sent: Thursday, May 19, 2005 2:43 PM > To: Don Flinn > Cc: SOA-RM > Subject: Re: [soa-rm] SOA System > > > > Well, > > I wasn't aware that CORBA name servers had anything other than > > IDLs in them; but be that as it may ... > > Is there a problem in recasting CORBA as an SOA? Or casting SOA > as > > distributed computing? > > > > There will be many factors that affect scalability in the design > > of an architecture. The service-orientedness is just one of those > > factors. To paraphrase an old maxim, there are few ways to be > > scalable and many ways to be fragile:) > > > > I.e., SOA is one property of an architecture - the focus on > public > > interactions etc. etc. To model that we need descriptions, semantics > > etc. > > To build a high-class SOA, we will need to consider other things; > > and we will need to apply the SOA RM to the architecture. > > > > Clear as mud, I guess, as my 'ole pappy used to say. > > Frank > > > > > > > > > > On May 19, 2005, at 2:30 PM, Don Flinn wrote: > > > > > Hi Frank > > > > > > My point was not to discuss CORBA's problems or lack of such. (I > was > > > one of the OMG/CORBA specification chairs during CORBA'S hay- > days :-) > > > But to ask at what level of abstraction does our RM specify that > which > > > makes it a reference model for an SOA. I know that an SOA is > > > different > > > from previous distributed models, but what qualities in our abstract > > > model do we discuss that makes it different from a specification of > a > > > generic distributed model. > > > > > > You mentioned "the focus on the public description of things". Is > > > this > > > the only thing that makes an SOA different and what our reference > > > model > > > should discuss? Even there, again using poor old CORBA, at an > > > abstract > > > level the CORBA naming service is a public description of things. > > > > > > What I'm driving at and what we all are trying to grapple with is > > > where > > > on the abstract spectrum should we be. At one extreme, one enters > the > > > world of metaphysics and the question become "What is the meaning of > > > life :-)" My question is simpler, maybe. Where on the abstract > > > spectrum > > > should we be to model an SOA as opposed to any distributed model? I > > > don't believe that we can produce a usable specification if the > > > model is > > > abstracted to such a high level that we are delivering a reference > > > model > > > for any distributed computing model. Specifically, what are the > > > abstract qualities that distinguish an SOA from a generic > distributed > > > model? > > > > > > Don > > > > > > On Thu, 2005-05-19 at 10:57 -0700, Francis McCabe wrote: > > > > > >> And the problem is ... > > >> > > >> I think that CORBA's problems did not come at this level of > > >> abstraction, but in the low-level realization. E.g., IDL is C++ in > a > > >> different syntax. It is rigid, and not capable of incorporating > > >> descriptions of policies, etc. > > >> > > >> SOA *is* different from random distributed computing, because of > the > > >> focus on public descriptions of things. > > >> > > >> Frank > > >> > > >> > > >> On May 19, 2005, at 10:20 AM, Don Flinn wrote: > > >> > > >> > > >>> To All > > >>> > > >>> As we abstract and restrict our reference model, I begin to wonder > > >>> what > > >>> makes this reference model a SOA reference model as opposed to say > a > > >>> CORBA reference model. CORBA had interfaces as one of its primary > > >>> constructs and had a specific language, IDL, to define the > > >>> interfaces. > > >>> The interfaces were the external front-end to Impls, which at our > > >>> level > > >>> of abstraction were the same as services and CORBA had the notion > of > > >>> metadata. It also had a Discovery & Advertise entity, the naming > > >>> service. This comparison is not limited to CORBA, but could > include > > >>> DCE, DCOM, J2EE, etc. to a greater or lesser extent. So my > > >>> question is; > > >>> At the level of abstraction that we are going, what makes our > > >>> reference > > >>> model a SOA reference model and not a generic distributed > computing > > >>> model? If the answer is the latter, is this what the world is > > >>> expecting > > >>> from us? > > >>> > > >>> Don > > >>> > > >>> On Thu, 2005-05-19 at 09:10 -0700, Francis McCabe wrote: > > >>> > > >>> > > >>>> Matt, et. al. > > >>>> In case this thought has not been raised in future > emails ... :) > > >>>> > > >>>> I believe that I am correct in stating that, in practice, the > > >>>> best > > >>>> aspects of languages like Java is not features such as > inheritance > > >>>> but the ease with which applications can be slotted together. > > >>>> The key > > >>>> feature that enables this Lego®-style assembly is the > > >>>> *interface*. It > > >>>> turns out that interfaces make the task of programming large > > >>>> systems > > >>>> significantly easier. > > >>>> > > >>>> The logical development of the type-only interface is the > > >>>> *semantic* interface. But in any case, modern SOAs represent one > > >>>> aspect of the trend towards focusing on interfaces as a way of > > >>>> controlling complexity and enabling rapid > development/deployment > > >>>> etc. > > >>>> > > >>>> So, at one level of abstraction, it may be useful to think of > > >>>> SOAs > > >>>> as a system of interfaces that allow architectures to be crossed, > > >>>> ownership domains to be crossed, different implementation > languages > > >>>> to be used, different versions to coexists, etc. etc. > > >>>> > > >>>> Our task is to try to pick out the keystones that bear the SOA > > >>>> hallmark; which seem to me to be what we have: services as > *action > > >>>> boundaries*™, semantic interfaces, tons of descriptions. > > >>>> > > >>>> Frank > > >>>> > > >>>> On May 18, 2005, at 7:22 PM, Matthew MacKenzie wrote: > > >>>> > > >>>> > > >>>> > > >>>>> Michael, > > >>>>> > > >>>>> On 18-May-05, at 5:55 PM, Michael Stiefel wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>> Matt, re your comment that "SO is OO, basically, with some > value- > > >>>>>> add infrastructure such as discovery and description." > > >>>>>> > > >>>>>> Now this raises an interesting point in our definition of > service > > >>>>>> abstraction. Normally people cite as one of the differences > > >>>>>> between SO and OO the fact that the former is more loosely > > >>>>>> coupled. > > >>>>>> > > >>>>>> Would you maintain that OO systems that can work with wire > > >>>>>> formats > > >>>>>> of object systems (such as COM and CORBA) that allowed runtime > > >>>>>> dynamic binding of heterogenous systems fall into the SO > > >>>>>> category? > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> I maintain that in certain situations that they *could* fall > into > > >>>>> the SO category. I think that the "loosely coupled" argument is > > >>>>> sort of weak, because I am not completely certain that even > things > > >>>>> like web services end up creating loosely coupled systems! > > >>>>> > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> Or do you see looser coupling as a useful feature that is much > > >>>>>> more easily achieved with newer implementation technologies > such > > >>>>>> as Web services, and therefore have nothing to do with SO. > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> I love loose coupling...but yeah, I do just view it as "a good > > >>>>> thing", and not a necessary element of SOA. > > >>>>> > > >>>>> -matt > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> -- > > >>> Don Flinn > > >>> President, Flint Security LLC > > >>> Tel: 781-856-7230 > > >>> Fax: 781-631-7693 > > >>> e-mail: flinn@alum.mit.edu > > >>> http://flintsecurity.com > > >>> > > >>> > > >>> > > >> > > >> > > >> > > > -- > > > Don Flinn > > > President, Flint Security LLC > > > Tel: 781-856-7230 > > > Fax: 781-631-7693 > > > e-mail: flinn@alum.mit.edu > > > http://flintsecurity.com > > > > > > > > -- Don Flinn President, Flint Security LLC Tel: 781-856-7230 Fax: 781-631-7693 e-mail: flinn@alum.mit.edu http://flintsecurity.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]