寻找 .NET CORBA 库的建议
我有一个即将进行的项目，其中我必须通过新的 C# .NET 3.5 完整框架应用程序与现有 CORBA 系统进行交互。
谁能提供最近的 .NET CORBA itneroperability 故事并推荐一个堆栈来使我们的 .NET 应用程序能够与第三方 CORBA 服务进行互操作？免费固然很好，但商业化也不错。
上下文
WCF 似乎没有将 CORBA 作为标准，这很遗憾，因为这本来是我的首选路线。 CORBA 本身似乎是“去年”的技术之一，我认为这就是为什么 Google 在这个话题上未能成为我的朋友！
CORBA 客户端需要安全连接，这对于我迄今为止发现的两个 OSS COBRA 堆栈来说似乎太多了（IIOP.NET 和 Remoting.CORBA）。尽管这可能只是由于对 Windows 证书管理的无知，而不是库本身。 Borland 的 Janeva 似乎已经从网络上消失了。
我们也在内部（仍然）使用 Delphi 6 开发应用程序，但如果可以的话，我们希望保持新内容 100% .NET。我们可能会使用 .NET 4，这会有所帮助，但 3.5 中的任何解决方案都会更容易。
I have an upcomming project in which I must interact with an existing CORBA system from a new C# .NET 3.5 full framework application.
Can anyone provide a recent .NET CORBA itneroperability story and recommend a stack to enable our .NET applications to interoperate with a third party CORBA service? Free would be great, but commercial fine too.
Context
It would seem that WCF does not do CORBA as standard, which is a shame as that would have been my preferred route. CORBA itself seems very much one of "last years" technologies, and I think thats why Google has fails to be my friend on this topic!
The CORBA client requires secure connections wich seems to be too much for the two OSS COBRA stacks I found to date (IIOP.NET and Remoting.CORBA). Although this might just be due to ignorance about windows certifciate management rather then the libraries themselves. Borland's Janeva seems to have dropped of the web.
We do also develop applicaitons in Delphi 6 in house (still) but would ideally like to keep the new stuff 100% .NET if we can. We can potentially go .NET 4 is this helps but any solution in 3.5 would be easier.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为 IIOP 很好，但你可以看到类似的问题此处。
I think IIOP is good but you can see similar question here.
如果您有任何可用的 C++ 专业知识，我建议您在 C++ 中实现 CORBA 接口（并通过 C++/CLI 将其桥接到您的 dotnet 代码中）。
使用 C++ ORB 将为您提供一个具有“所有”功能的完全兼容的 ORB，而不是缩减版本。
如果您是一家非 C++ 商店，您最好还是外包 CORBA / C++ 模块来与第 3 方 CORBA 服务交互。
omniORB 和 TAO 是 C++ ORB 的明显选择。
我喜欢omniORB（相对）简单性。让它运行，我还成功地将omniORB集成到由C#/.NET应用程序加载的C++ DLL中。
I would recommend implementing the CORBA interface in C++ (and bridge that into you dotnet code via C++/CLI) if you have any C++ expertise available.
Using a C++ ORB will give you a fully compliant ORB with "all" features, instead of a cut down version.
If you are a non-C++ shop, you still might be better off outsourcing the CORBA / C++ module to interface with the 3rd party CORBA service.
omniORB and TAO are obvious choices for C++ ORBs.
I like omniORBs (relative) simplicity wrt. getting it running and I also have successfully integrated omniORB into a C++ DLL that is loaded by a C#/.NET application.