I am decided to use CORBA to communicate between a C++ service and a java service. I want to know that is it possible using CORBA to inter call C++ library and java library like we call a dll in an application. It will be very helpful if anyone help me to take a good decision!
(Seems some confusion in my previous answer. I think it is better that I give another answer which state clearer my point)
CORBA is for interactions between "remote" components. Although I used the term "Remote" here, it doesn't mean that components needs to be located in remote machine. They can be in the same machine, or even same process.
The answer mostly depends on your aim:
If you are writing new libraries/components in C++ and Java, and you want to use them in the same application and have components in both language able to interact with each other, then yes, CORBA can help you in certain extend. However CORBA is helping you in the component communication part. You still need to use JNI (or other similar solutions) to invoke/startup your C++/Java component in your Java/C++ application. CORBA is not going to help you on this. You may want to do extra POC to see if having two ORBs in same application (one for C++, one for Java) is going to cause you any problem.
If you are talking about: you already have some existing libraries which is written in Java and C++ (of course, not in CORBA-awared manner), and you are looking for way to make use of these library in your new application (in Java/C++). Then no, CORBA cannot help you much on this. Of course you can still write a extra layer which expose your components in CORBA, and make use of them, but making use of CORBA here is not going to make "calling C++ library or Java library" anything easier.
However, imho, neither case above seems to be a strong reason to make use of CORBA. If you are just looking for interoperability of Java and C++ libraries, JNI, or JNA maybe something you want to look into.
Related
I have an existing library written in C# which wraps a much lower-level TCP/IP API and exposes messages coming down the wire from a server (proprietary binary protocol) as .NET events. I also provide method calls on an object which handles the complexities of marshalling convenient .NET types (like System.DateTime) down to the binary encodings and fixed-length structures that the API requires (for outgoing messages to the server). There are a fair number of existing applications (both internally and used by third parties) built on top of this .NET library.
Recently, we've been approached by someone who doesn't want to do all the legwork of abstracting the TCP/IP themselves, but their environment is strictly non-Windows (I assume *nix, but I'm not 100% sure), and they've intimated that their ideal would be something callable from Java.
What's the best way to support their requirements, without me having to:
Port the code to Java now (including an unmanaged DLL that we currently P/Invoke into for decompression)
Have to maintain two separate code-bases going forwards (i.e. making the same bug-fixes and feature enhancements twice)
One thing I've considered is to re-write most of the core TCP/IP functionality once into something more cross-platform (C / C++) and then change my .NET library to be a thin layer on top of this (P/Invoke?), and then write a similarly thin Java layer on top of it too (JNI?).
Pros:
I mostly spend my time writing things only once.
Cons:
Most of the code would now be unmanaged - not the end of the world, but not ideal from a productivity point of view (for me).
Longer development time (can't port C# sockets code to C / C++ as quickly as just porting to Java) [How true is this?]
At this point, the underlying API is mostly wrapped and the library is very stable, so there's probably not a lot of new development - it might not be that bad to just port the current code to Java and then have to make occasional bug-fixes or expose new fields twice in the future.
Potential instability for my existing client applications while the version they're running on changes drastically underneath them. (Off the top of my head I can think of 32/64 bit issues, endianness issues, and general bugs that may crop up during the port, etc.)
Another option I've briefly considered is somehow rigging Mono up to Java, so that I can leverage all of the existing C# code I already have. I'm not too clued up though on how smooth the developer experience will be for the Java developers who have to consume it though. I'm pretty sure that most of the code should run without trouble under Mono (bar the decompression P/Invoke which should probably just be ported to C# anyway).
I'd ideally not like to add another layer of TCP/IP, pipes, etc. between my code and the client Java app if I can help it (so WCF to Java-side WS-DeathStar is probably out). I've never done any serious development with Java, but I take some pride in the fact that the library is currently a piece of cake for a third-party developer to integrate into his application (as long as he's running .NET of course :)), and I'd like to be able to keep that same ease-of-use for any Java developers who want the same experience.
So if anyone has opinions on the 3 options I've proposed (port to Java & maintain twice, port to C and write thin language bindings for .NET and Java or, try and integrate Java and Mono), or any other suggestions I'd love to hear them.
Thanks
Edit: After speaking directly with the developer at the client (i.e. removal of broken telephone AKA Sales Department) the requirements have changed enough that this question no longer applies very well to my immediate situation. However, I'll leave the question open in the hopes that we can generate some more good suggestions.
In my particular case, the client actually runs Windows machines in addition to Solaris (who doesn't these days?) and is happy for us to write an application (Windows Service) on top of the library and provide a much more simplified and smaller TCP/IP API for them to code against. We will translate their simple messages into the format that the downstream system understands, and translate incoming responses back for them to consume, so that they can continue to interface with this downstream system via their Java application.
Getting back to the original scenario after thinking about this for a couple of weeks, I do have a few more comments:
A portable C-based library with different language bindings on top would probably be the way to go if you knew up front that you'd need to support multiple languages / platforms.
On *nix, can a single process host both a Java runtime and a Mono runtime simultaneously? I know in earlier versions of .NET you couldn't have two different .NET runtimes in the same process, but I believe they've fixed this with .NET 4? If this is possible, how would one communicate between the two? Ideally you'd want something as simple as a static method call and a delegate to raise responses with.
If there's no easy direct interface support between Java & Mono (methods & delegates, etc.), one might consider using something like ZeroMQ with Protocol Buffers or Apache Thrift as the message format. This would work in-process, inter-process and over the network because of ZeroMQ's support for different transports.
Spend more time getting the requirements nailed down before deciding on an implementation. Until you know what is required, you don't have any criteria for choosing between designs.
If it's a non-windows environment, it doesn't make sense to have .NET anywhere in there, for example.
If you need something that runs on the Java Virtual Machine but looks a lot like C#, you should check out Stab. This will not help you with P/Invoke and the like but you may find it less work to port your C# code to Java and maintain it.
You should look into Mono though. I expect that all your C# code would run unmodified (except the parts that touch the unmanaged DLL).
I have not used it but jni4net is supposed to allow calling .NET code from Java. If your clients want a Java interface, this may be a solution.
I use Mono on Linux and the Mac all the time even when .NET compatibility is not a priority. I like C# and the .NET libraries and prefer the CLR to the JVM. Mono is MIT/X11 licensed which means that you can use it commercially if you like. Unlike some others, I see no reason to avoid technology championed by Microsoft while favouring technology championed by Oracle and IBM.
Using Mono will not help you with the unmanaged bits, although you can still P/Invoke into a native DLL. You will just have to port that DLL yourself or find some equivalent.
You may also want to look into Mono Ahead of Time compilation.
Have you considered mono? It would most likely support your existing code in the non-windows environment. The trick would be calling it from java, but the mono folks might have something to help you out there, too.
This probably isn't the right solution in your case, but for completeness:
There are a few languages that can target both the JVM and .NET, in particular Ruby (JRuby and IronRuby) and Python (Jython and IronPython). Scala might eventually get there too, although right now the .NET version is a long way behind the JVM version.
Anyway, you could potentially rewrite your library in Ruby or Python and target both runtimes.
If what you really, really want is to be able to code in .NET and have it run on the JVM, you could check out Grasshopper (2015-09: link possibly dead). That is what it is designed to do.
I know the Mainsoft guys have been contributors to Mono over the years. If I remember correctly, they wrote the Visual Basic compiler for Mono.
There is also the C# to Java converter from Tangible. I have heard good things but I have never used it myself.
Also, it does not help your situation much but I should point out Mono for Android.
Mono for Android runs the CLR and the Dalvik VM in parallel. In other words, the C# code you wrote for Android can be calling into Java libraries (like the Android UI for example) and executing as a single app. You had asked about the ability to run .NET and Java code in the same process. Clearly, it can be done.
One thing I've considered is to re-write most of the core TCP/IP functionality once into something more cross-platform (C / C++) and then change my .NET library to be a thin layer on top of this (P/Invoke?), and then write a similarly thin Java layer on top of it too (JNI?).
That's a possibility. On the Java side, you should consider using JNA rather than JNI. (If you use JNI, the C / C++ code needs to be written to use JNI-specific signatures.)
Another possibility is to replace the proprietary binary protocol with something that "just works" with multiple programming languages. This is the kind of problem space where CORBA and similar technologies provide a good solution.
I have a fairly sophisticated server-side application which frequently requires me to see what is going on with its internals to debug and fix problems.
I've therefore embedded a Beanshell instance, which I can telnet into (normally over a ssh tunnel), but I'm wondering if there is a better way.
A few limitations:
No readline support, which I can get around by using 'rlwrap' on telnet, but its not ideal
Tab-completion of variables and methods would be really nice, but I haven't found a way to do this
Pre-defining variables (to access stuff I need to access frequently) doesn't seem to work, I have to pre-define functions instead
All-in-all its rather clunky, although Beanshell has the nice advantage that its a super-set of Java, so nobody needs to learn another programming language to use it.
I'm wondering if others have any experience with facilitating remote debugging/administration via a scripting language (Beanshell or otherwise), perhaps someone has found a better approach.
One of our application has a BeanShell interface that connects to our application over JMX with RMI+SSL.
You can indeed pre-define variables by calling Interpreter#set() before actually invoking the Interpreter.
Other than that, I agree with you on the "readline" like functionality. There is a project called java-readline (and BSH apparently ships with a plugin for it) that purports to provide functionality but I haven't investigated using it. It also requires a JNI library.
I've heard that people use Scala and Groovy to implement command line clients but as of now, I don't think the Scala API for embedding the interpreter is standardized yet. I also don't believe they support the "readline" features you're looking for.
I am not sure exactly what I am asking....The guys that do the software development for the company I work for write everything in VB. I am currently the Web developer for this company and I specialize in Flex apps. I am thinking about expanding into their area. But I do not want to do VB, I don't mean to bash on VB but the coding syntax is not for me. So I am wondering if Java can integrate with VB? Also not sure if it matters but I think everything they do is procedural, and I will be doing OOP.
Thanks.
There are lots of integration opportunities, but before examining them, if I were you I would re-examine the question itself.
It should be exceptional to introduce a new language into an established project. The desires or aesthetic preference or skillset of a single developer is not a good enough justification to do so. Introducing a new language into a project should be a strategic decision for the project, not a backhanded one.
If you do choose to expand the core languages used to develop the system,
COM interop
is possible with JACOB. I believe IBM has a bridge as well.(Check alphaworks)
Java-.NET bridging
is possible via JNBridge and other bridges. This makes sense only if VB.NET is in use.
SOAP, XML document exchange, REST
suitable over a services boundary. It requires TCP or HTTP or some network protocol.
common data stores
can serve as a rendezvous point. Both Java and VB can read and update data in SQL Server, Oracle, MSMQ, MQSeries, and so on. Even a filesystem can be an integration point.
Think of data format as related to, but ideally independent of, the integration mechanism. What I mean is: You can use an XML document for integration, whether it is stored in a database, or sent over a REST interface, or stored in a filesystem, or put/get on a queue. You can use a comma-separated file over any of those mechanisms as well.
Potentially they could expose a service layer via soap or something simpler? Also you could always work against the same database with different languages however unless most of the logic is in stored procedures (not necessarily recommending this approach) then you end up with repeated code.
Not really. Java uses CORBA for interop, and VB uses COM for interop. You may be able to make a bridge using JNI, but I understand that can be quite the pain.
I haven't done this by I believe you have the following options:
Use the Java-COM bridge, as VB uses COM. This library was already mentioned here several times
If you are using VB.net, you probably use hessian, As it has both Java and C# implementations.
You could bridge the two using a C/C++ adapter to map JNI calls with COM. But that would be horrible. I hope there is a better solution, but my understanding is that it is pretty hard to integrate .NET code and Java as both vendors (Sun and Microsoft) don't have any incentive to streamline that kind of development.
Any idea on interfacing with AutoCAD through a JAVA program. I am looking for a solution that can directly interface with an AutoCAD session (even start one), the way it works with the .NET extensions of AutoCAD. Or any way to work with ObjectARX through JAVA, definitely not writing a complete JNI wrapper over it.
Added: We are looking for something in open-source. In case there is none, we are ready to create one in open-source if someone can lend a helping hand explaining how it can be done. We have taken a look at JNA and JaWin. JNA clubbed with JNI might help but is too ugly. JaWin on the other hand has not been updated in the past 4 years, so sort of skeptical using it.
The only thing I can think of is to use a Java <-> .Net bridge like JNBridge. I've used this in other scenarios and it works fine. Never done any work with Java and AutoCad though so there might be other cheaper solutions.
If you are trying to interact with the AutoCAD application you will have a tough time.
If you want to interact with the dwg files themselves there is the Open Design Alliance which has libraries that allow working with dwg files without AutoCAD.
You can try to use the JavaBeans ActiveX bridge and the COM Automation to open AutoCAD and manipulate it.
That said, JavaBeans ActiveX bridge hasn't evolved in a while (I used it back in 2003) and Autodesk is seriously investing in .Net for everything related to extensions and automation in AutoCAD.
We are working on a similar project. What we are doing is writing the integration code in C#, and the business logic for our project in Java.
We are utilizing a C++ bridge that utilizes JNI to take Java calls down to C++, and then translates them back up to C#, and vice versa. Each function that needs to go from C# to Java has to be implemented in the bridge code. This is fairly involved, and there are some issues with getting the unmanaged C++ code to work with the C#, as well as the standard overhead of translating Jstrings into C# Strings and the like. The result is relatively fast, after we did some optimizations to insure that we aren't starting and stopping the JVM for each call into the Java layer.
We previously used COM objects which were called by the AutoCAD plugin, so that would be another approach.
I have to integrate a large Java library in a quite large C++ application. A solution is to use JNI but this requires to hand code all the classes. Python has, for example, a wonderful solution with JPype (http://jpype.sourceforge.net/) that automatizes the process (although the same solution cannot be applied to C++ due to C++ and Python different natures).
Thanks,
Das
SWIG is a tool that lets you auto-generate bindings from one language to another. It supports C++ and Java and a dozen other languages.
Seems that my question was not clear enough. Maybe the confusion comes from JNI that allows the access in booth directions ...
What I want to do is to access a Java library FROM C++. That is, someone give me a JAR file that contains a collection od JAVA compiled classes and I must write code in C++ to access it (as I want to integrate the functionality of that Java library into a C++ application).
Hope that this clarifies the direction of access :)
Thanks,
Das
Not sure if this commercial tool makes life any easier, but you might wanna explore -- http://www.teamdev.com/jniwrapper/index.jsf
JNA is not quite what you're looking for, but it does make your life a lot easier. It doesn't require any boilerplate/generated code - you just write an interface for the methods you want to call.
Certainly, there is every reason to use JNA instead of JNI.
I have two suggestions which may or may not work for you:
First, you could try something very simple. Run the Java code in a separate process, and communicate with it with pipes or sockets. This is fairly easy to do, and doesn't require any crazy libraries. The downside is that the communication is somewhat limited (just some simple pipes), you'll need to write your own wrapper around it to send data across
Secondly, what exactly is this library? Perhaps we can suggest alternatives that are not written in Java, that would be much easier to use in your C++ application?