Reputation: 21
I am aware that CORBA allows for multiple objects to be implemented in different programming languages and even run on different computing nodes. However, does this then require two different ORBs written in two different languages, as well?
Example: Node A runs Java application J1, while node B runs C++ application C1. Will I have to obtain a "Java ORB" for node A and a "C++ ORB" for node B, or can all/some ORBs interact with applications written in any language that there is an IDL mapping for?
I would be especially grateful if anyone could link me to a source stating this explicitly, as I would like to cite it. The closest I have found is "the way a programmer manipulates a struct or union, makes a remote call using a proxy or implements an interface with a servant class is exactly the same across all C++ CORBA products, is exactly the same across all Java CORBA products, and so on" . This makes me think that I would need two ORBs, but is not explicit enough. I would basically like to know if I can state that "As the ORB is written in C++, application programmers are also constrained to use C++".
Thanks
Upvotes: 1
Views: 434
Reputation: 4392
It is not important in which language ORB is implemented, it is important which language bindings it provides. For language L you need orb that provides bindings for language L. Often orbs just provide binding for the language in which themselves are written, but they can also provide bindings for some other languages.
Upvotes: 2
Reputation: 49886
No. The point of CORBA is that it fully decouples the components.
Obviously, your applications need to use client libraries that they can interface with. Your ORB may only supply bindings for one language, in which case you need to find other bindings, or find a way to interoperate with them (e.g. if using Python, you could still work with C++ libraries if you wanted).
Try actually using the technology.
Upvotes: 3
Reputation: 29019
There are several approaches that can be used when implementing CORBA applications, but summing them up, yes, the ORB infrastructure has to be in the same language as your application implementation.
Both in Java and in C++, the IDL compiler generates stubs and skeletons that serve as a glue between the network and your program. You provide the implementation of your CORBA Objects, usually inheriting from a IDL compiler generated class (the skeleton). The skeleton gets the request from the client in some way, and then calls your implementation. The same happens in reverse in the client side.
Then, both the skeleton and the stub use the mechanisms provided by the ORB to remotely calling the servers and to answer responses back, even including stablishing network connections if client and servers are in different machines. This "magic" is implemented by the ORB, and has to be present in your program in form of a library, set of functions, etc. that the stub and skeleton will use to get the job done.
So, every program has to have some kind of representation of the ORB to interact with other CORBA clients and servers in other machines.
However, from a logical point of view, the ORB is seen as a layer, that actually and seamlessly connects both clients and servers, so, even when a C++ application has some ORB implementation written in C++, and a Java implementation have an ORB written in Java, by way of the magic of standard protocols (GIOP, IIOP), they can communicate with each other without problems.
Upvotes: 0