Re: popular CORBA systems ?
On 2010-09-23 23:15:05 -0400, gk said:
However, suppose an application has been developed with C++ and hosted
in HOST1 and another application has been developed with C and hosted
in HOST2.
can these two be brought under CORBA system now ? I am afraid we
can't because C is not a OO Language . we can' think objects
here...is that correct ?
It's completely possible to implement objects exposed via CORBA in C.
You end up doing a lot of bookkeeping yourself to keep track of which
function pointers and structs go with which CORBA object identifiers,
instead of having language features take care of it for you, though:
it's *convenient* to implement CORBA objects with language-level
objects, but not required.
This isn't just true for CORBA, either. The Windows COM and DCOM object
systems are heavily inspired by CORBA, and work with a notion of an
object, but it's possible to implement COM objects in C, too. In
principle, you could even implement an RMI service (another distributed
"object" system) for Java clients using C, if you had appropriate
protocol libraries. Distributed object systems all use a notion of
objects that's separate from the way objects work in any of the host
languages.
I think unlike SOA , CORBA transfers objects whereas SOA transfers
XML.
The whole point of CORBA is avoiding transferring objects around: one
program that implements a CORBA service hosts some objects, and when a
client program need to use those objects, the client program sends a
message containing a method call to the implementing program and gets
back a message containing the result. Messages, which are nothing more
than sequences of bytes, are the only thing that travel around the
network.
"SOA" isn't a specific technology at all, so your comparison is pretty
bogus. A better analogy would be SOAP*:
- CORBA has a name service; SOAP has URLs
- CORBA apps use ORBs to handle calls; SOAP uses web servers and HTTP
libraries
- CORBA objects expose methods; SOAP services expose methods
- CORBA methods are called using IIOP messages; SOAP uses XML messages
- CORBA APIs are described using IDL; SOAP uses WSDL to describe APIs
They're actually fairly similar technologies. However, CORBA specifies
many things that SOAP does not:
- CORBA provides support for several threading models; SOAP does not
consider threading at all.
- CORBA includes support for distributed transactions spanning
multiple processes; SOAP requires an additional spec (WS-Transaction)
which is not widely supported.
- CORBA supports transient objects; SOAP assumes services are fairly static.
However, the SOAP spec authors were aware of CORBA and learned some
things from failings of CORBA in the real world:
- IIOP messages are not human-readable; XML messages can be debugged by hand.
- IDL only offers a handful of field types; WSDL (XSD, actually)
allows new field types (simple types) to be defined as restrictions or
extensions of existing types.
- CORBA offers many features that see only limited use; SOAP offers
fewer features, making it easier to understand.
This list is not exhaustive; there are many other places where SOAP and
CORBA are very similar, and there are many other places where they
differ greatly.
I dont know if any of this helps. The key point is: don't get too hung
up on the term "object": every distributed system eventually has to
represent things using nothing but bytes, which means the individual
processes in the system can be written using any language that can
operate on bytes - which is basically all of them.
-o
* "Simple *Object* Access Protocol".