问题标签 [corba]

我想向现有服务器的 CORBA 接口添加一个方法。这需要重新编译所有客户端吗？

我正在使用TAO。

我们希望允许从 Excel 访问我们的一些 EJB。目标是提供可从 VBA 使用的 API。

我们的 EJB 主要是无状态会话 Bean，它们使用 POJO 执行简单的 CRUD 操作。

一些可能的解决方案：

• 将 EJB 公开为 WebServices 并创建一个包装它们的 VB/C# dll，
• 使用 Corba 从 C# 访问 EJB，
• 创建一个使用 Java 访问 EJB 的 COM 库，

欢迎指出这些解决方案的框架或其他想法。

如何让 AS3 和/或 Flex/AIR 应用程序与 CORBA 应用程序通信？

我正在开发一个基于 .NET 的服务器组件，该组件使用各种特定于目标的协议与一组目标（具体而言，股权期权交换）进行通信。我们计划添加的下一个目标使用 CORBA，因此我正在研究可以使用 CORBA 的 .NET 库。

到目前为止，我发现了三种可能性：

• IIOP.NET是一个开源项目，看起来很成熟并且相当活跃。
• J-Integra Espresso是 Intrinsyc 的 Microsoft <-> Java 互操作性工具套件之一。
• VisiBroker for .NET（以前称为“Janeva”）是 Borland 的 VisiBroker CORBA 包的一个模块。

有没有人有任何这些经验，好的或坏的？

还有其他选择吗？

我可以通过混合的本地托管 C++/CLI 代码使用基于 C++ 的 CORBA 库之一（omniORB和TAO似乎是前两个，但还有其他），但数据需要进出托管核心服务器在某些时候增加了编组的性能成本，并且在混合代码场景中使用本机 C++ 库往往是相当痛苦的。

更新 - 我们已经开始使用 IIOP.NET，到目前为止它看起来还不错。最新版本 (1.9 sp1) 的性能似乎可以接受，并且 API 相当易于使用。我肯定会按照 Todd Stout 的建议研究IKVM - 如果 IIOP.NET 没有成功，这看起来是一个非常有趣的可能性。

更新 #2（2010 年 7 月）——我们在生产环境中使用 IIOP.NET 已有一段时间了，效果很好。IIOP.NET 项目并不完全是我所说的活动项目，但 CORBA 也不是，因此似乎不需要更多的开发。

我们有一个包含 C++ 和 Java 模块的分布式应用程序，通过 CORBA 进行交互。

是否有任何 C++ 库/工具可以将“变量”和“方法”暴露给 JMX 工具（以创建统一管理）？

我遇到了一个问题，我编写了一个在我的开发机器上完美运行并且在 Lab 系统上完美运行的 Java 应用程序，但是当我将它安装到客户端机器上时，我收到以下错误：

org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0

有谁知道可能出了什么问题？我是否缺少 Jar 文件？或者客户端可能安装了错误的 Java 版本？

我有一个用 Java 编写的客户端-服务器应用程序，使用 CORBA 进行通信。使用的ORB 是orbd，Java6 平台提供的ORB。我必须将 Java 服务器实现替换为另一个用 C++ 编写的实现。所以问题是，在 CORBA 库的免费源代码实现中，哪个更好地与这个 ORB 互操作？我是否应该替换 Java ORB 并同时使用 C++ 库提供的 ORB？

目标是在用新的 C++ 实现替换已经运行的服务器时实现简单而平稳的过渡。还有什么我应该考虑的吗？

对于相对粗粒度的并行处理（数据传输可以在 100 Mbit 以太网中完成），您认为适用于 Windows 和 Linux 的哪个中间件最好？科尔巴？MPI1? MPI2? XML-RPC/SOA/WSDL？自定义网络协议？Java RPC？Python RPC？其他的？

我一直迷恋于基于组件的编程（无论是使用 COM、另一个系统，还是仅使用纯 C++ 中的范例）。如果一个人通常习惯于“传统”OOP 模型，它需要一点时间来适应，但它绝对值得。它使我的代码更易于维护和扩展。

我目前正在做的项目是使用范式，但没有设置系统。但是，我真的很想找到某种可以满足以下要求的系统。从我现在拥有的系统切换到新系统需要一些时间，但我会在以后节省很多时间。

要求：

1. 跨平台
2. 快速地
3. 适用于 C++
4. 支持跨进程编组

让我详细说明这些要求：

跨平台

基本上，我需要它在 Windows 和 Mac 上工作。Linux 会很好，但绝不是必不可少的。此外，它确实需要满足所有平台的其他要求。有一个适用于 Mac 的 COM，非常理想，但它不支持要求 4。此外，它必须同时支持 GCC 和 MSVC。

快速地

这就是 CORBA 不幸失败的地方，尽管它满足了其他三个要求。进程内方法调用需要尽可能快（理想情况下，如 COM），因为某些例程也可能从音频中断中调用。

适用于 C++

...我想这个很明显。我不介意不使用 C++ 类来实现组件，尽管这肯定会有所帮助，而且替代方案必须仍然易于使用，特别是因为最终我打算发布一个用于 3rd 方扩展的 API。

支持跨进程编组

我的意思是至少能够序列化调用。如果这是通过 IDL 生成的代码来完成的，那对我来说完全没问题，而且我也不介意实现跨进程通信本身。

COM 会很棒，但它不能完全满足要求 1。CORBA 也会很棒，但它不满足要求 2（即使有最快的 ORB）。XPCOM 可能不满足要求 2，并且不适用于 MSVC，因此不满足要求 1。

有什么想法吗？我的下一步将是使用 protobufs 或类似的东西来推出自己的产品，但我当然想避免这种情况。

更新

详细说明 - 在这种情况下，音频中断可以低至 2-3 毫秒。那个时间对我来说甚至都不完整，因为其他组件需要在那个时间处理，而我的软件本身正在包装另一个需要在那个时间处理的软件。这就是为什么进程内和跨进程编组都需要非常快的原因。

我在 Corba 客户端上工作了一段时间。我遇到的一个问题是我无法真正定义超时配置。

我正在使用 Mico C++ orb，但这似乎是一个全球性问题，因为我发现没有人可以描述是否有 Corba 定义的方法来配置请求超时。

有谁知道这样的接口或球体初始化？