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 any开发者_运维百科one 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.
I think IIOP is good but you can see similar question here.
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.
精彩评论