Woody Pollack
CHAIMS
4/24/99

Combining multiple ORBs

What we combined:
	We combined Orbix and Omnibroker.

Where we combined it:
	We have multiple servers that are distributed using CORBA.  Some use Orbix as their ORB and others use Omnibroker as their ORB.  We combined these two ORBs in the client, so the client uses multiple ORBs.

Difficulties that arose:
	The main problem we had was in using a complex data structure along with more than one ORB.  We have many servers that use the same type of data.  The problem is easiest to describe with an example.  Let's assume we have 1 service using Orbix for its ORB and another using Omnibroker for its ORB.  We'd like to have 1 client speak directly with both services, but we're not using IIOP.  The two services have an identical interface:

struct complex {
	int _int;
	char _char;
};

typedef sequence<complex> complex_type;
interface test_interface {
	void method( in complex_type);
}

Each ORB that we want to use for this interface must provide some way of handling that complex data structure.  This mechanism for handling this data will not be similar between ORBs.  This issue also presents itself as a naming conflict.  Both idl compilers will generate mechanisms to deal with 'complex_type'.  How will the client know which 'complex_type' methods to use?  In order to resolve this, we had to scope these data structures as in this example:

interface test_interface {

	struct complex {
		int _int;
		char _char;
	};

	typdef sequence<complex> complex_type;
	
	void method( in  complex_type);
}

Now, our client program must scope the use of variables of this type:
<server_name>::complex_type variable_name;
so the compiler/linker knows which methods to associate with variable_name.