[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Corba vs SOA
|
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----- 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, >>> Tel: 781-856-7230 >>> Fax: 781-631-7693 >>> e-mail: flinn@alum.mit.edu >>> http://flintsecurity.com >>> >>> >>> >> >> >> > -- > Don Flinn > President, > 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]