Their performance in negligible since they run on same machine communication will not take much time.
The are extensible interms of both processes can be moved different machines. Even new languages can also be used to communicate, since almost all the programming languages provides some way of using sockets.
Maintenance will not be a problem, since most of them are aware of operation of sockets. It will be easier to maintain sockets rather creating or using something else. (May be you can use XML for transferring. Web Services. eh?)
As I said all the popular programming languages support sockets, it should be,of course, ease of use with proper documentation.
Sockets are certainly an option. If the data to be transferred is quite simple, then sockets may indeed be the best option.
If the interactions between the processes are complex, then using sockets directly will involve you writing an awful lot of code, to define the protocols for information passing. In such a situation, you could consider using something smarter.
RPC over sockets is one level smarter than plain sockets. It can be done between lots of languages. C++ and Java are probably included, but I haven't done it.
I have lots of experience using CORBA between C++ and Java. That goes over sockets, but provides a fairly high-level interface on top of it, so that objects implemented on a remote machine can be accessed fairly transparently on the local machine.
These days, there are loads more options, but I don't know much about them, so won't spout a load of BS about them.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
1. Shared files/database:- Coding is Messy, messy, messy. Performance is low because bothe aps will have to continously poll the file. I just put this in there because inspite of the drawbacks, many people find this option attractive. This option might work if you don;t need real-time synchronous communication. FOr example, if you just want you Java program to give some data to C++ program, and the Java program doesn;t care about when the data gets processed, then the Java program can dump the data into a database. The C++ program can be scheduled to run at regular intervals and process data.
2. Sockets:- Coding is a bit messy, because you have to define your own protocol. Also, you will need some thread waiting on the listening socket, and you have to take care of timeouts, do your own marshalling. Performance is good
3. DCOM (only for Windows):- Coding is less messy. But you start running into installation hell. Windows will take care of marshalling and threading, and you have to manage error handling. Performance is good. However, you need to implement your C++ program as a DCOM server. I don;t know if you have that flexibility
4. RPC:- DOn't have too much to say because I have never used it myself
5. Web services:- Coding is very simple. The framework provides all the stubs and all you have to do is implement your code as a local call. Performance is less than DCOM/RPC. However, you need to host your programs as web applications.
Joined: Jul 02, 2003
Thanks for your valuable responses. We had finalized the Socket option.
The best option to tranfer the data structures is the real issue. We have Java Classes and C/C++ structures defined. When data will flow on socket how to map C/C++ stucture to Java Object?
1) Send data in string tokenized format 2) Use JNI at Java side to convert C/C++ structure to JAva 3) Send XML between the processes.
The issue is, system needs to be very performace centric. XML does not seems to be vaibale option.
Please let me know the best pattern for this data communication.
Joined: Mar 21, 2006
1) Send data in string tokenized format
This might be suitable when small amount of data to be transferred, since it is not good to do tokenizing of large amount of data when other data formats are available.
2) Use JNI at Java side to convert C/C++ structure to JAva
Good. But there will be possibility of pragram get crashed if the object is not contructed properly (though i dont find any reason for this to happen). (I havent tried this, but I think there will lot of complexities be involved to implement.)
3) Send XML between the processes.
Yes it is not viable to send large amount of data because extra tags involved. But it is much safer to use than other because of large amount robust parsers available. If you have got better system, performance will not be affected. Other option, which you can use (if they are not in same system), using transperant compression of xml data between both the ends.
Correct me if I am wrong. [ March 24, 2006: Message edited by: Dilip Kumar Jain ]