Re: Re: Can Two CORBA Interfaces Be Implemented in One UNIX Process?

[<lgust verizon net>]

Hi Bowie,

Thank you very much for your help. I followed your suggestion to
question #3, i.e., I put all the shared types in one IDL file, then
I created another IDL file that implemented both CORBA interfaces
and included the types file. It solved the compilation problem and
was an easy solution.

Thanks,
Larry S. Gustafson
> 
> From: Bowie Owens <bowie owens csiro au>
> Date: 2004/02/02 Mon PM 06:48:58 CST
> To: lgust verizon net
> CC: orbitcpp-list gnome org
> Subject: Re: Can Two CORBA Interfaces Be Implemented in One UNIX Process?
> 
> lgust verizon net wrote:
> 
> >Implement Two CORBA Interfaces in One UNIX Process
> >
> >January 31, 2004
> >
> >Problem Description:
> >I work with a small team of software developers that are new to building CORBA interfaces. In the last few months we have learned how to use ORBit2 and the C++ binding to build interfaces where the client and server for each interface are UNIX processes.
> >Now we have an architectural problem where we would like to build a single process that implements two different CORBA interfaces. We would like the server of one interface to run in a thread and the client of the other interface to run in a different thread. Our problem is complicated by the fact that the two different CORBA interfaces share common data types. The diagram below represents our basic hardware and software architecture.
> >
> >
> >
> >Simple IDL Example:
> >Although our interfaces are more complicated, I have included a simplified example that demonstrates the problem we have compiling the IDL files and linking the UNIX process. There are three IDL files, two define the interfaces (ClientInterface.idl and ServerInterface.idl) and the other file contains the common types that the two interfaces share (Types.idl).
> > 
> >
> >When the two interfaces are compiled with the following commands the ClientInterface-cpp-common.h and the ServerInterface-cpp-common.h files both pull the shared types into the files.
> >orbit-idl-2 -I. ClientInterface.idl
> >orbit-idl-2 --skeleton-impl --lang="cpp" -I. ClientInterface.idl
> >orbit-idl-2 -I. ServerInterface.idl
> >orbit-idl-2 --skeleton-impl --lang="cpp" -I. ServerInterface.idl
> >
> >When the process that contains the server thread and the client thread include the .h files for both interfaces, I get a compilation error for redefining the same types:
> >
> >gcc -c -g -DORBIT2=1 -D_REENTRANT -I/usr/local/include/orbit-2.0 -I/usr/local/include/linc-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/orbitcpp-2.0 -I/usr/local/include/orbit-2.0/ORBitservices ClientServerProc.cc
> >In file included from ClientServerProc.cc:16:
> >ServerInterface-cpp-common.h:26: error: redefinition of `struct NLCA::myType'
> >ClientInterface-cpp-common.h:26: error: previous definition of `struct 
> >   NLCA::myType'
> >
> >I looked at the command line flags that are defined for orbit-idl-2 --help and tried to see if there was a combination of settings that stops the C++ binding from including the shared type in the <interface name>-cpp-common.h files, but I could not find a solution.
> >
> >Questions:
> >1.	Is it possible to implement the architecture above with the ORBit2?s C++ binding?
> >  
> >
> To inhibit the generation of shared types take a look at #pragma inhibit 
> push and #pragma inhibit pop (or the --onlytop command line option). The 
> Bonobo IDL makes use of these pragmas to make libbonobo work. 
> Unfortunately, orbitcpp support for these is a bit sketchy. Depending on 
> your IDL this it may or may not work. I wouldn't recommend this path 
> anyway, see my answer to question three.
> 
> >2.	Is there documentation on the command-line flags defined for orbit-idl-2 other than the output from the --help flag?
> >  
> >
> orbit-idl-2 is part of ORBit2 so you might want to ask the orbit list. 
> http://www.gnome.org/projects/ORBit2/orbit-docs/orbit/book1.html has 
> some details on orbit-idl-2 scattered throughout.
> 
> >3.	Are there any examples that show how someone has solved a similar problem with ORBit2?
> >  
> >
> The easiest approach and the one I am working with on my project is to 
> simply have all the IDL in one file. Get both the interfaces for the 
> client and the server in a single IDL file and generate from that. That 
> said you may want to use the #include directive so that you can split 
> the IDL into multiple files for readability (this may require 
> #ifndef/#define include guards like in C++). This is what Bonobo does, 
> they have multiple files which all get included into one big IDL file.
> 
> The following is a simplification of my project renamed to make things 
> obvious:
> p-fwd.idl: forward declarations and definitions of basic types required 
> by client and server
> p-callback.idl: interface to callbacks within the client
> p.idl: server interface includes client interface.
> 
> As such I just do:
> orbit-idl-2 -lcpp -I . p.idl
> 
> In your case you would just need to create an IDL file with the 
> following (say Complete.idl):
> 
> #include "ClientInterface.idl"
> #include "ServerInterface.idl"
> 
> Depending on which program you are building you then need to compile and 
> link only one of ClientInterface*.o, ServerInterface*.o or Complete*.o.
> 
> 
> 
> -- 
> Bowie Owens
> 
> CSIRO Mathematical & Information Sciences
> phone  : +61 3 9545 8055
> fax    : +61 3 9545 8080
> mobile : 0425 729 875
> email  : Bowie Owens csiro au
> 
> 
>