[omniORB] CORBA versus Sockets

[OKeeffe, Michael K]

>
>Hi,
>
>> All packets are encoded in XML.  So the advantages of IDL go away.

Not necessarily, see below.

>> Socket are available for most platforms / software development tools.

True, although it sounds like your platform is MS, anyway, so doesn't
seem to be a requirement (cross-platform).

>> So no extra points for CORBA here either.  And we do not need any
>> failover type features.

>From what I've read, failover is best at a lower level anyway.

>>
>> In our environment there will be a single server written in 
>C# running
>> on MS Windows XP.  However, there are multiple clients (written in C#
>> and Python) all connecting to the same server.  The server and the
>> clients sometimes run on the same PC and other times on 
>different PCs.

I assume your Python clients are the reason you're considering sockets
or CORBA, otherwise why wouldn't you want to use WCP or whatever the
"Microsoft Way" is, i.e. whatever their calling their latest iteration
of COM/DCOM/?  I think there's IronPython for .NET.  But anyway..

>>
>> The problem is that people know and are comfortable with 
>sockets.  Given
>> the above, are there still good arguments to be made in 
>favor of CORBA?

I'd say that's your best point, although if you're using CORBA at a
simple level, not getting too fancy, there's not much to it.  That's the
whole point - it handles the low-level details, which you'll need to
code if you're using sockets.  But sounds like that's not an issue.

>
>Given that all your data structures are XML text, I don't 
>think that CORBA 
>will be a lot of help for you. The things you will have to do 
>yourself if 
>you use sockets are:
>- Server thread management
>- Connection management
>- Exception/error signaling (but you probably do this in XML already)
>
 - I might also add that you'll need some sort of locator capability -
like the Naming Service.

>It's probably easier to solve these issues with sockets than 
>to educate the 
>developers about CORBA.
>

Maybe - but if they find themselves doing an awful lot of coding, it's
time to rethink.  As an example, if I need a simple logging capability,
then I might be able to implement that with 1 or 2 classes/programs.
Fine.  But if I start adding features for other requirements -
performance, log to these devices, logging customized for each program,
etc etc, then you should think about log4cpp or something.

But perhaps best to keep it simple at first, i.e. use sockets, see how
it works.

>I personally like to use CORBA because of the strict interface 
>definitions 
>in IDL, and because of the flexibility (combining different 
>platforms and 
>languages). If you don't specify the interface in IDL but put 
>everything in 
>XML (which can also be used across platforms/languages), then 
>I don't see 
>the point anymore.
>
There's value for some sort of interface definition even if you are
using XML.  For example, web services use XML, but store the "contract"
in WSDL.  Steve Vinoski (naturally) is a big proponent of separating the
implementation from the interface.

You can search his blog for WSDL and or IDL for many relevant articles,
also see the first paragraph on pg. 90 - "XML documents are not, by
default, fully self-describing"
http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Just_A_Mapping_Problem.pdf