CORBA 应用程序必须使用与 ORB 相同的语言来实现吗？
我知道CORBA允许用不同的编程语言实现多个对象，甚至可以在不同的计算节点上运行。但是，这是否也需要用两种不同语言编写的两个不同的 ORB？
示例：节点 A 运行 Java 应用程序 J1，而节点 B 运行 C++ 应用程序 C1。我是否必须为节点 A 获取“Java ORB”，为节点 B 获取“C++ ORB”，或者所有/部分 ORB 是否可以与以任何有 IDL 映射的语言编写的应用程序交互？
如果有人可以将我链接到明确说明这一点的来源，我将特别感激，因为我想引用它。我发现的最接近的是“程序员操纵a的方式结构或联合，使用代理进行远程调用或使用服务类实现接口在所有 C++ CORBA 产品中完全相同，在所有 Java CORBA 产品中完全相同，等等”。这让我认为我需要两个 ORB，但还不够明确。我基本上想知道我是否可以声明“由于 ORB 是用 C++ 编写的，因此应用程序程序员也只能使用 C++”。
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不。CORBA 的要点在于它完全解耦了组件。
显然，您的应用程序需要使用可以与之交互的客户端库。您的 ORB 可能只提供一种语言的绑定，在这种情况下您需要找到其他绑定，或者找到一种与它们互操作的方法（例如，如果使用 Python，如果您愿意，您仍然可以使用 C++ 库）。
尝试实际使用该技术。
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.
ORB 以哪种语言实现并不重要，重要的是它提供哪种语言绑定。对于语言 L，您需要为语言 L 提供绑定的 orb。通常，orb 只为编写自身的语言提供绑定，但它们也可以为某些其他语言提供绑定。
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.
实现 CORBA 应用程序时可以使用多种方法，但总而言之，ORB 基础结构必须使用与应用程序实现相同的语言。
在 Java 和 C++ 中，IDL 编译器都会生成存根和骨架，充当网络和程序之间的粘合剂。您提供 CORBA 对象的实现，通常继承自 IDL 编译器生成的类（骨架）。框架以某种方式从客户端获取请求，然后调用您的实现。在客户端，同样的情况反过来发生。
然后，骨架和存根都使用 ORB 提供的机制来远程调用服务器并回复响应，甚至包括在客户端和服务器位于不同机器上时建立网络连接。这种“魔法”是由 ORB 实现的，并且必须以库、函数集等的形式出现在您的程序中，存根和框架将使用它们来完成工作。
因此，每个程序都必须具有 ORB 的某种表示形式，以便与其他计算机中的其他 CORBA 客户端和服务器进行交互。
然而，从逻辑的角度来看，ORB 被视为一个层，它实际上无缝地连接客户端和服务器，因此，即使 C++ 应用程序有一些用 C++ 编写的 ORB 实现，而 Java 实现也有一个用 C++ 编写的 ORB在Java中，借助标准协议（GIOP、IIOP）的魔力，它们可以毫无问题地相互通信。
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.