[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dist-obj] CORBA implementation ideas

Mike Beedle said:
> Geez, I hate to admit it Steve, but our experiences are 
> similar to those described by Mark.

Now that the fire is roaring, I might as well put my marshmallows in too ;-)

>From Nov 97 to June 98 I was involved in primarily the front end of a
project that consisted of NT with a third-party contact management
application that we extended with ActiveX controls.  We used VC++ 5.0/MFC, a
third-party grid control, and Orbix Desktop 2.03.  The Orbix part was used
as middleware to communicate with an application server on a Solaris box.
Here are some problems and cool things we ran into:

1) Linking the multi-threaded Orbix library into *any* DLL (let it be a
regular DLL, inproc ActiveX control, etc.) would cause the application
loading the DLL (which in turn used Orbix) to hang or crash.  We had to
almost literally "pistol whip" Iona for several months until they finally
gave us a patch that resolved the problem.  I remember at one point the
support person told me about a hack where I could load the Orbix library,
fake a 'this' onto the stack, and call a C++ method that should have
explicitly unloaded some sort of internal factory that was causing the hang.

2) The stub code alone took up most of the space in our binaries.

3) I really liked the I/O callback feature because we essentially created
connection observers that would re-bind if the server went down before
invoking CORBA methods.  On the server side we used the daemon restart
service that restarted the server if it died.  So we could rip the network
cable out of the wall or kill -9 on the pid of the server and it would keep
on chugging along just fine.

As we speak I've been working on doing a review of a firewall-based
application that tunnels through an HTTP plug in our firewall and into the
intranet to a Jaguar CTS (Sybase) server for calling CORBA methods that in
turn do database stuff and return results back.

1) If I'm not mistaken, IIOP stands for Internet Inter-Orb Protocol.  Sure,
it was supposed to work over the Internet, but DID THEY THINK ABOUT
FIREWALLS?  I know, Wonderwall is supposed to address this, but anybody who
designs a protocol that works from one port then randomly assigns subsequent
ports wasn't thinking firewalls in real businesses trying to build really
secure business applications.

2) The good thing was that the Jaguar CORBA stub actually works on a UNIX
platform (our web server where the servlet runs in a DMZ is Solaris-based)!

In my subjective opinion, CORBA took many different companies (with many
differing political, technical, and business imperatives) and created a
standard that many different vendors are attempting to implement in many
different and incompatible ways.  Interoperability even in a single vendor
between ORB versions is sometimes very difficult or not supported.

This has resulted in an architecture (CORBA) that makes it harder, not
easier, to develop solutions.  Microsoft Research -- in addition to many
other efforts already mentioned in this thread -- are trying to abstract the
programmer from needing to deal with distributed programming issues to make
their lives easier and more productive, not harder, when developing
solutions.

Regards,
Philip

PS: Aw, heck, let's all be friends and pull those 11/780s out of storage and
start hacking punch cards again ;-)
============================================================================
To unsubscribe and other requests, mailto:dist-obj-help@unity.cs.caltech.edu 
Archives, FAQ, etc.       http://www.distributedcoalition.org/mailing_lists/