aspose file tools*
The moose likes Other JSE/JEE APIs and the fly likes C++  <---> [JNI / CORBA] <----> Java Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Other JSE/JEE APIs
Bookmark "C++  <---> [JNI / CORBA] <----> Java" Watch "C++  <---> [JNI / CORBA] <----> Java" New topic
Author

C++ <---> [JNI / CORBA] <----> Java

Anirvan Majumdar
Ranch Hand

Joined: Feb 22, 2005
Posts: 261
Before you draw any conclusions, let me briefly explain my end goal-
There's an application suite developed using C++. And there's a distributed communication framework, an ESB, developed using Java. The inevitable problem that we need to face up to is - how to make C++ and Java apps communicate with each other in the most effective manner. Some parameters which will be critical for us [in no specific order] are -

>> Security of the data being exchanged
>> Integrity of data
>> Performance issues - mainly speed
>> Reliability

Keeping this in mind we identified 3 possible solutions - web services, JNI and CORBA. We quickly realised that web services wasn't exactly what we were looking for. Seemed more like a sledge hammer for a simple task. Esp, in a desktop environment there can't be any compelling justification for running a web server just for inter-app communication.
That left me with JNI and CORBA. I'm aware that CORBA's kind of old, but is it completely inappropriate? Before diving in, I was hoping someone having some experience in this scenario can put in a few caveats. Also, I'd much appreciate if any one can suggest alternatives worth looking at for the problem I'm trying to solve.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

You skipped JMS.

That aside, you don't have to run a full-scale web server to expose web services--you just need something listening on a port. It'd be *easiest* to run an embedded web server, because all the work is done for you, but it's not *required*.

Depending on how your ESB has been implemented there may already be a way to access it from other technologies anyway.
Anirvan Majumdar
Ranch Hand

Joined: Feb 22, 2005
Posts: 261
Hmm, JMS sounds interesting. But won't I need a web server, embedded or otherwise, for that too?

Besides, in terms of speed too, I really don't want to go ahead with a web server based solution [of course, if others don't work out, that's what it will be]. Some of the operations are purely desktop application based, so I don't want the latency of web server based communication to affect the user interaction.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18669
    
    8

You seem to be making a lot of casual assumptions in this analysis. First you just dismissed web services for no good reason. Then you declared that there was no reason to run a web server in a desktop environment (the people who developed Subversion wouldn't agree with that). Now you're talking about some "latency" associated with web servers which somehow doesn't exist in other forms of communication.

I don't know what you should do, but my decision would mostly be based on the capabilities of this ESB which you already have in place and the capabilities of the C++ application suite. You didn't say what the latter could do or whether changing it was an option.

And no, you don't need a web server to run JMS. You do need a JMS server, of course, but that's a standalone sort of thing. It's still a server though.
Anirvan Majumdar
Ranch Hand

Joined: Feb 22, 2005
Posts: 261
Paul,

It wasn't my intention to sound casual, so let me try and explain in a better way -
I've worked with subversion and I fully understand the argument about "latency", or rather the lack of it. But see, when people are using subversion, they already know that it's a client-server based application. If you ever try to submit a good number [15-20] of files together it takes 5-10 seconds [or more]. Now tell me if you're working with an application like Eclipse, and you want to save a similar number of files together, would a user really like to wait 5 seconds or more to do so.

Basically the reason for me to push web services down the list of alternatives is that it seems to be more of a solution for communication in a distributed system. I think one mistake I made in my description of the problem is to mention ESB. Let's just keep that aside, 'coz what I'm dealing with is a desktop based application [written in C++] which needs to interact with another Java application. The interaction needs to be bi-directional. Since the scope of communication is within a single machine, using a server to bridge the gap between 2 apps written in different languages doesn't seem correct.

So to put it simply, besides JNI and CORBA is/are there any other technologies I should look into? And if there's any one with some experience of working with JNI & CORBA, probably they can put in a few things to measure the up the two.

And Paul, just to put the "latency" associated with web servers which somehow doesn't exist in other forms of communication into perspective - JNI based interaction is *much* faster than client-server based interaction [order of ~50 times], though not quite as reliable.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

How on earth is JNI "not as reliable"?!
Anirvan Majumdar
Ranch Hand

Joined: Feb 22, 2005
Posts: 261
I'll take that back. What I meant was that there's a dearth of frameworks built around JNI, like you have for web services. So one needs to implement it the ground up. If there are frameworks abstracting certain common requirements using JNI, then I'm unaware.
 
 
subject: C++ <---> [JNI / CORBA] <----> Java