Re: CORBA

[Dave Stampf <drs@bnl.gov>]

Hi,

I just want to add that I've also installed OmniBroker on a
Sparc/Solaris
system without any problems. I had a rockier time porting code written
for
an Orbix implementation of Corba (From Baker's book) that would seem to
indicate that programmers must discipline themselves to program in a
non-Orbix specific way if they hope to port *source* code from one
system to another.

I have no feel at all for the following aspects of Orbix & Omnibroker:

*Corba Services - is there any code in the GC that uses specific Corba
Services that may be optional in the standard and not in Omnibroker, but
which do appear in Orbix?

*Performance - for lightweight usage, this probably isn't an issue and
if specific system-wide bottlenecks appear, we could replace one
machine's ORB and libraries with a better performer.

*Developement Tools - as with many frameworks, lots of code can be
generated automagically. My limited experience indicates that Orbix has
some advantage here. Again, the neat part here is that if you have Orbix
on one machine, you can have it generate these templates and you can
carry it to another machine. The code must however be generated in a
portable style.


One more VERY IMPORTANT note - the Solaris/Intel version of Orbix is
*WAY* behind the other implementations and Iona has no plans to catch up
- it is not supported any longer! Also, Iona is not porting Orbix to
Linux. So if we run Unix on the commodity systems, it looks like Iona is
not a consideration for us.

Is that a problem for anyone in the GC?

Cheers,

Dave (Stampf)





Mark Pollack wrote:
> 
> Dear GC'ers,
> 
> During the past few days I have been fooling around with the
> free version of CORBA that I mentioned on the rhic mailing
> lists (Omnibroker www.ooc.com)  and ORBIX.
> I though I would mention what my experience has been.
> 
> The omnibroker orb compiled easily on both solaris/intel
> and NT 4.0. I tested co-located client/server communication
> on both these platforms and also with the server on NT and the
> client on solaris.  These tests went well and everything worked
> as expected.
> 
> I also then put the corba client inside of STAF on solaris/intel
> (just inside a PAM, not replacing the whole corba guts of STAF)
> and was able to get information from a co-located server.
> So there were  no apparent conflicts  using omnibroker inside of STAF.
> 
> I then went through in detail the "grid" example that comes with
> ORBIX and implemented this inside of omnibroker.  The differences
> the user would see in the two implementations of corba seem to be
> small.  ORBIX (on sun/solaris) uses nested classes and type definition
> scopes whereas omnibroker generates unnested definitions using the
> same names but :: is turned into _
> ie CORBA::Short   goes to CORBA_Short
> There is also a difference in how the IDL compilers handle a method
> with the same name as its class.
> 
> Another difference might be in the exception handling, at the surface it
> does not look like there is a difference but I did not test it yet.  I also did
> not look into the differences when using the TIE approach to implementation.
> 
> As it turned out, the "grid" example in ORBIX also was not 100% corba
> compliant in its initialization, however the ORBIX manual notes this and
> supports the corba compliant initalization.  So I was very pleased to see that
> at this level there were many similarities in using the two products.
> 
> The documentation that comes with ORBIX is extremely good where as that
> for omnibroker is rather poor.  However, it does come with the code
> used in the book "CORBA - Fundamentals and Programming from
> Siegel/OMG" and that code exercises many aspects of corba.
> 
> I also had an ORBIX client (on sun/solaris) talk via IIOP to
> the omnibroker server on my NT machine. I would expect that
> other configurations of client/server/os  would work, but
> I did not test that yet.
> 
> At the end of it all I got the impression that for "lightweight" use of CORBA,
> where we don't need many corba services or special database adapters,
> omnibroker is a solid product.  Also, since it can talk through IIOP to ORBIX
> we might be able to use ORBIX on the server to do things which omnibroker
> is not capable of performing and have an omnibroker client get the results.
> 
> - Mark

-- 
David R. Stampf     | "The fundamental delusion of humanity is to 
Brookhaven Nat. Lab.| suppose that I am here and you are out there." 
Upton, NY 11973     |   
1-516-344-4148      | Yasutani Roshi