I have two programs. One is in C# and another one in Java.
Those programs will, most probably, always run on the same machine.
What would be the best way to let them talk to each other?
So, to clarify the problem:
This is a personal project (so professional/costly libraries are a no go).
The message volume is low, there will be about 1 to 2 messages per second.
The messages are small, a few primitive types should do the trick.
I would like to keep the complexity low.
The java application is deployed as a single jar as a plugin for another application. So the less external libraries I have to merge, the better.
I have total control over the C# application.
As said earlier, both application have to run on the same computer.
Right now, my solution would be to use sockets with some sort of csv-like format.
I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
Kyle has the right approach in asking about the interaction. There is no "correct" answer without knowing what the usage patterns are likely to be.
Any architectural decision -- especially at this level -- is a trade-off.
You must ask yourself:
What kind of messages need to be passed between the systems?
What types of data need to be shared?
Is there an important requirement to support complex model objects or will primitives + arrays do?
what is the volume of the data?
How frequently will the interactions occur?
What is the acceptable communication latency?
Until you have an understanding of the answers, or potential answers, to those questions, it will be difficult to choose an implementation architecture. Once we know which factors are important, it will be far easier to choose the more suitable implementation candidates that reflect the requirements of the running system.
I've heard good things about IKVM, the JVM that's made with .NET.
Ice from ZeroC is a really high performance "enterprisey" interop layer that supports Java and .net amongst others. I think of it as an updated Corba - it even has its own object oriented interface definition language called Slice (like Corba's IDL, but actually quite readable).
The feature set is extensive, with far more on offer than web services, but clearly it isn't an open standard, so not a decision to make lightly. The generated code it spits out is somewhat ugly too...
I realize you're talking about programs on the same machine, but I've always liked the idea of passing messages in XML over HTTP.
Your server could be a web server that's ready to accept an XML payload. Your client can send HTTP messages with XML in the body, and receive an HTTP response with XML in it.
One reason I like this is that HTTP is such a widely used protocol that it's easy to accept or create HTTP POST or GET requests in any language (in the event that you decide to change either the client or server language in the future). HTTP and XML have been around for a while, so I think they're here to stay.
Another reason I like it is that your server could be used by other clients, too, as long as they know HTTP and XML.
I used JNBridge (http://www.jnbridge.com/jnbpro.htm) on a relatively simple project where we had a .NET client app using a relatively significant jar file full of business object logic that we didn't want to port. It worked quite nicely, but I wouldn't say we fully exercised the capabilities of JNBridge.
I am a big fan of Thrift an interoperability stack from Facebook. You said they code will probably run on the same machine so it could be overkill but you can still use it.
If they are separate programs and running as independent applications,you may use sockets. I know it's bit complex to define communication protocol but it'll be quite straight-forward.
However if you have just two separate programs but want to run them as single application, then I guess IKVM is a better approach as suggested by marxidad.
It appears a very similar question has been asked before here on stack overflow (I was searching Google for java windows shared memory):
Efficient data transfer from Java to C++ on windows
From the answer I would suggest you to investigate:
"Your fastest solution will be memory
mapping a shared segment of memory,
and them implementing a ring-buffer or
other message passing mechanism. In
C++ this is straight forward, and in
Java you have the FileChannel.map
method which makes it possible."
Related
I'm getting into socket programming on C#.net for the project I am writing.
The project will be a multi-client system of which the client services monitor system resources and report back to a central server(s).
I was looking into Remoting, WCF etc. to determine which would be best for me. I settled with socket programming because of a number of requirements:
Sockets are faster than the rest with little overhead
I can support more connections per resources on the servers
Sockets can, with albeit modifications, allow me to interact with UNIX based systems also.
I can implement encryption on the link myself in code without having to rely on an SSL cert.
I may be wrong in my thinking here? If I am please do tell. Some suggest WCF as it is "wasy to use" and does everything I want but I believe it is that much slower with overheads.
My main issue is, that while the client machine will not keep a connection open, there could be thousands, or tens of thousands, of client machines and I would have to assume that the machine will be hammered with connections. Considering minimum times between connections, per client, may be as small as 1 min.
Now to my problem at hand: How to send multiple objects over the link and more importantly how to determine what they are on the other side?
I'm assuming this is possible over one connection as I have read a number of articles saying so, albeit they describe the methods differently and so are the examples.
The issue is I can't find any example that actually does this. No example shows how to send multiple objects and then how to determine what they are on the other side.
Can anyone help me here or point me to examples. I'm quite able to figure stuff out once I have a base to work from.
It feels like the classic case of premature optimization and reinventing the wheel. I might be mistaken because I don't know what are your performance requirements, development resources and time frame. But I suspect that very smart people had the same problems before you. And they came up with the variety of solutions, including HTTP (SOAP, REST) and XMPP (if you want statefull protocol). A lot can be done to improve performance even at the app level (minimizing amount of data send over wire, caching etc). Without complexity overhead introduced by using sockets directly. You probably know all of this but I highly recommend you to evaluate your decision again.
As to usual serialization format suspects like XML and JSON you might also want to look at Protocol Buffers:
protocol buffers is the name of the binary serialization format used
by Google for much of their data communications. It is designed to be:
small in size - efficient data storage (far smaller than xml)
cheap to process - both at the client and server
platform independent - portable between different programming architectures
extensible - to add new data to old messages
You might be trying to reinvent the wheel here. But since you have set your mind about using sockets (been there, done that, learned a lot), read those links on serialization:
How to deal with XML in C#
XML Serialization and Inherited Types
How do I serialize a C# anonymous type to a JSON string?
Parse JSON in C#
I have to write an application that is essentially a proxy server to handle all HTTP and HTTPS requests from our server (web browsing, etc). I know very little C++ and am very comfortable writing the application features in C#.
I have experimented with the proxy from Mentalis (C# socket proxy) which seems to work fine for small webpages but if I go to large sites like tigerdirect.ca and browse through a couple of layers it is very slow and sometimes requests don't complete and I see broken images and javascript errors. This happens with all of our vendor sites and other content heavy sites.
Mentalis uses HTTP 1.0 which I know is not as efficient but should a proxy be that slow? What is an acceptable amount of performance loss from using a proxy? Would HTTP 1.1 make a noticeable difference?
Would a C++ proxy be much faster than one in C#? Is the Mentalis code just not efficient?
Would I be able to use a premade C++ proxy and import the DLL to C# and still get good performance or would this project call for all C++?
Sorry if these are obvious questions but I have not done network programming before.
EDIT In response to Joshua's question: I don't necessarily need to write the core proxy server myself as long as there is a good implementation out there but like I said I have been experimenting with Mentalis which isn't performing that well. The final application needs to install on a Windows PC/Server from a single installer with 0 manual configuration.
I can write all the necessary registry edits in the installer as I have done that before in C#.
UPDATE I took Aaronaught's advice and looked into improving Mentalis' code. I fix a problem so it works with HTTP 1.1 allowing it to work with Chrome and Firefox (Safari 4 on Windows crashes the proxy though for some reason).
When I tested in FireFox and Chrome I discovered the performance problems were not there which implied it was an IE problem not a problem with the proxy. After resetting the browsing history settings the problem went away.
Thanks everyone!
How you actually design and code the application is going to make infinitely more of a difference than the platform you choose.
If you design the server efficiently, it will be efficient. If you design it inefficiently, it will be inefficient. There's no clear advantage to choosing C++ over C# or vice versa... unless you'd have to learn the entire language from scratch, which is a huge negative (hard to come up with a good design when you barely know the tools).
Things you'll probably have to understand for this type of application:
I/O completion ports
Thread pools and multi-threading in general
Networking protocols (including HTTP, FTP, TCP, etc.) - especially for error handling
Certificates and signing/encryption (for SSL/HTTPS)
...
Honestly, you're talking about a non-trivial undertaking here. I don't mean to sound overly negative but what makes you think you can do a better job without an extensive knowledge of the underlying networking protocols and proxy design? Why not take a look at the Mentalis Proxy source code instead and see if you can improve it, rather than trying to write your own from scratch? Surely the former would be easier than the latter.
Anyway, a socket is a socket; .NET sockets are not much more than paper-thin wrappers over Windows sockets, so performance is not going to be noticeably different in C++.
C++ is not an easy language to learn. Combine that with lack of networking experience and you are in a totally new territory. If you want to explore - fine, you'll make all the mistakes and learn a lot. If, on the other hand, you need to deliver something by some date - go with whatever you are comfortable with at the moment.
If you want to write a really fast, clean, down-to-the metal server, go with C++ or plain C.
C++ is not an easy language, and is easy to mis-use. C++ requires the discipline to actually read and contemplate difficult books. Used right, it is the best systems programming language available.
If performance is not an issue, you may use fluffier tools such as C#.
the ways I can think of
Web service or soap
Socket
Database table
shared file
Any concise example you know of for webservice?
Web services or soap would be fairly easy, however, if the C++ application isn't a web server naturally (or the C# application), it may be easier to just use socket programming directly.
Sockets are fairly easy to use from both C# and C++. They give you complete control over the type of date transmitted, at the cost of potentially a little more work in the handling.
The biggest issues to watch for are probably endianness of binary data, and encoding of text data, if you use sockets directly. Otherwise, it's very easy.
Since you are already aware of the Web service and socket approach, I'll mention some other options. If you like simplicity, check out XML-RPC. This is what SOAP was before large standards committees and corporate interests began to control the specification. You can find implementations of XML-RPC for just about every major programming language out there. Hessian is an interesting binary protocol that has many fans and supports just about every major language as well. Protocol Buffers is popular within Google. The official version from Google does not support C#. However, the two highest rep users of SO do provide ports of protobuf for the .Net space.
I will probably be ridiculed for this, but also take a look at CORBA. It's not in vogue these days, but has many substantial technical creds, especially if one end of the communication is C++. IMHO, it's WS-* with OO support and no angle brackets required. For interop, I think it still should have a seat at the table. When engaged in C++ development, I found OmniOrb to be quite effective and efficient. Take a look at this SO Question for some pointers concerning using CORBA in .Net.
Sockets are easiest; and I would always go for that first. If database is an option, that's also trivial, but that would really depend. If it's queued events, that would make sense, but if it's request/response, it's probably not so great.
you can use gsoap to have a C/C++ program use a webservice.
You can also call a cgi program that is written in C++.
I have written a server in C that communicated with a C# client, and the endianess can be a pain to deal with, webservices is so much simpler.
Do you want it to communicate with each other (for instance, through tcp (like many others have pointed)) or do you want to be able to translate objects from C# to C++? If so, check out Apache Thrift (http://incubator.apache.org/thrift/).
I have two C# programs and I want to send some data back and forth between them. (And check if the data arrived to the other application.)
The two programs will always run on the same computer, so no networking capability is required. I've already read some questions with similar topics here, but I'm not entirely sure which is the right method for me. (WCF, Remoting, etc.)
What I want to know, is which one is the easier to implement for a beginner in C#?
(I don't want it to get too complicated anyway, it's only a few integers and some text that I want to send.)
If there isn't a real difference in difficulty, what advantages does one have over the other?
I'd really appreciate some simple example code as well.
Thanks in advance.
You can use Pipes to send data between different instances of your application. If you just need to tell the other instance that something has happened you can send messages from one application to another by using SendMessage api.
WCF essentially packages up the various methods of communication between applications (web services, remoting, MSMQ etc) in a single package, so that they are programmatically the same in the way that they are used, and the detail of what method is used is left for configuration of the binding between. A slight simplification perhaps, but essentially what it's about.
It is worth getting into WCF if you need inter-process communication, and this would certainly be my advice as to the way to go with this. It's worth looking at IDesign, who produce a number of articles on the subject, as well as some reusable code libraries, that you may find useful. Their Juval Lowy has also written an excellent book on the subject,
Another good point about WCF is that if your requirements ever change and all of a sudden you have to move one of the application to a different machine, requiring now network capability, you will only need to change configuration on both sides, instead of having to recode.
Plus, ad David said, WCF is a good tool to have in your bag.
Cheers, Wagner.
I found MSMQ is simple to implement.
My friend and I are having a disagreement over an application development issue. It's a simple production management application.
According to my friend, the front-end stores data in XML, and a Java program will read the XML document, store it (at the back-end), and apply some business logic and again store the results into another XML document. And a C# front-end will display the result ( He wants to use sockets for communicating the status of XML ).
I think this is a bad idea. I suggested that whole application should either be written in C# or in Java.
Note: The application is standalone. It's not used over a network.
Have any of you tried this? Please share your thoughts :)
You're right and your friend gave a bad idea. In addition, from your question, I see there are several troubled issues, I don't know where to begin so I will just list them but not in any particular oder. But the ground rule for you to read on is you must agree that simpler is better as Einstein said "Things should be made as simple as possible but not simpler" (or something like that, I don't remember the exact quote).
The notion of front end and back end do not really apply to a desktop application. Rather, you want to use the MVC pattern for the separation of concerns. Wikipedia might be a good place to start learning or reviewing.
Why use of socket (which is totally unnecessary) if you don't have to. This is the first reason why it's a bad idea as you would not need using sockets if everything is done in language, running in the same process space (Your app is a desktop or standalone app).
Similarly, why XML (again unnecessary). No need because you can just pass Java or C# objects around. With XML, first there is the signal to noise issue as tags are added to the true data. Then there is the time to parse, to construct the XML, additional libraries potentially, etc. Thid would be all that code which are introduced in your friend's approach.
These are the most obvious reasons. There are other reasons from a manager's or company's perspective:
To maintain this application, the manager or company needs to hire 2 different skillsets. This might not be true as most programmers are multilingual anyway. But that's not always the case.
In term of deployment, now you force your users to have both the JRE and the .NET framework installed just to be able to run your application. And either of those is not exactly a small footprint.
Talk about making it complex. Either Java or C#. One really isn't a backend for another. They both 'do the same things' as languages. The only difference is whether you want to leverage the power of .NET, or the power of the immensely huge Java frameworks.
This is a desktop application that "is not used over a network"... I'm failing to see a need for a real "backend" at all.
Write the desktop application in a single language, and store your data in XML.
So your application is standalone and doesn't need to work over a network, but your friend insists on connecting the front and back ends of the app using sockets? Something is wrong with this setup, seems more complicated than it needs to be.
It sounds to me like your friend wants to use Java because he understands Java's XML handling framework better. Personally, I think interop between Java and .NET is overkill. You'll save yourself a lot of man hours and frustration by writing the app in a single language of your choice.
What your friend is suggesting is to keep things modular. It doesn't really matter what language you use, but if throw it together in one big project you might make it non modular.
For that type of app I would use one only one language.
It may be possible to leverage the power of C# desktop app on the front-end and Use Java Ejb+Web Service (Jax-ws) on the backend. C# apps can read SOAP wsdl to create the stubs and the interfaces to access Java backend implemented by Jax-ws.