[omniORB] COM-omniORB Interface

[Sai-Lai Lo]

David,

Given your requirements, I think a COM-CORBA mediator running
on the client machine is quite an attractive proposition:

 +-------------+                 +----------------------------+
 |  ETS-Kernel |                 |     Windows NT/95          |
 |             |                 |                            |
 | +-------+   |                 |  +---------+   +-------+   |
 | |       |   |   CORBA         |  |         |COM|       |   |
 | | server|<---------------------->| mediator|<->| GUI   |   |
 | |       |   |                 |  |         |   | app	  |   |
 | |       |   |                 |  |         |   |       |   |
 | +-------+   |                 |  +---------+   +-------+   |
 |             |                 |                            |
 +-------------+                 +----------------------------+


I do not have any experience with using any COM-CORBA bridge
product so I can't comment on this approach.

However, I think it is not difficult to handcraft the mediator
using omniORB2 and the COM support that comes with VC++.
It is simply a matter of writing wrappers to call from COM to
omniORB2 stubs and vice versa. 

By keeping the server interface in OMG IDL, you keep the door
open to move to non-win32 GUIs. Perhaps quite soon, your client
will prefer a pure java-based GUI!

Regards,

Sai-Lai


>>>>> David Morgenlender writes:

> I'm in the process of developing an app, consisting of 2 pieces:
> 1.  CORBA server app running under ETS-Kernel (a realtime OS
> supporting the Win32 API).  This is currently under development
> using Visual C++ 5.  I'll hopefully know soon how well omniORB
> works in this environment.

> 2.  CORBA client app running under Win95 (later NT4).  This is
> currently under development using Borland C++ Builder 3.  I'm running
> into problem after problem getting omniORB working under BCB3 ...
> I keep running into compiler bugs.

> Until a couple of days ago, this was the entire system.  However,
> then I learned the client would like to be able to write Visual
> Basic apps to control the CORBA server app, e.g. for Q&D diagnostics.

> This left me in a quandry.  At first glance I need to find some way
> for a VB app to use CORBA.  VB handles COM well, so I could acquire &
> test a COM-CORBA bridge product.  But I suspect this is asking for
> more headaches, both getting it work & in ongoing support.

> However, there's a solution which solves all my problems (hah, hah <g>).
> I can write a VC++ exe which uses omniORB on one side to function
> as a CORBA client, and COM on the other side.  This provides support
> to a VB app.  It also allows my BCB app to communicate with it via COM;
> voila, no need to get omniORB working under BCB!  Theoretically, BCB
> provides good support for writing a COM
> client.

> There are some negatives though, e.g.:

> 1.  Another layer:  complexity, overhead, etc.

> 2.  A change to an interface function requires changes in 3, not 2,
> places: CORBA server, COM-CORBA app, BCB app.

> 3.  Just one more buzzword to support:  COM.

> What do you think of this approach?

> Can you suggest any better alternatives?