What "technology" would you suggest to exchange some kind of messages between a Java server and several clients written in C#, Javascript and Java?
The background story:
In our current project we're trying to build a generic UI backend in Java (running on the server) which is then "bridged" into several UI frontends by means of different UI adaptors (running on the client, the server, or both). While our server technology will always be Java, there will be C# (Silverlight), JavaScript and Java clients. Maybe even more in the future (different Smartphones, Tablets).
The UI backend and UI frontends communicate through a bunch of more or less simple messages (mostly name/value-pairs) each of which encapsulates a specific property/state/data change on the client or server respectively. Within a single request cycle, several such simple messages are aggregated into one big message which is then passed from backend to frontend or vice versa. At the moment sending and receiving messages is done at a single entry point on the client as well as on the server. So there are no server methods exposed as WebService etc. - simply because this would most definitely be to slow in our case.
Our current prototype consists solely of a Java server, a Java Desktop Client (Swing) and a Java Web Client (Vaadin). The message exchanged between backend and frontend is effectively a list of POJOs (each representing a specific "change") serialized/deserialized to/from XML. So far, so good.
Now C# and Javascript come to the table. Since we want to work with some kind of object in each technology, we thought it would be a good idea to specify the messages/changes/pojos in some kind of abstract language and then generate objects for each target language. At some point these objects could then be serialized/deserialized and sent over the wire (probably via http/s). For this purpose we thought of Google's protocol buffers or Thrift. What do you think?
For the moment our synchronous request-response-cycle is enough but we will need asynchronous request-response or server-push respectively pretty soon. That's why we thought of using something like ActiveMQ straight away. What do you think? Too much? If not, how can we accomplish the object generation mentioned above (xsd, jaxb, ? for js)? Are there better ways? I've never used ActiveMQ but according to the website it should be possible with Java, C# (Spring.NET) and somehow with Javascript (STOMP) too. However, this seems pretty complex to me...
Any tips, hints, experiences or comments about this or related topics would be really helpful.
Thank you in advance.
I would recommend using webservices. The WSDL language defines objects and messages of your protocol in abstract form. Most modern languages like Java and C# have tools for converting WSDL to native types and libraries for handling I/O.
For the last two years i have been involved in building a similar system: backend for our project is c#, java and bunch of other languages, frontend is phone clients for ios, android, symbian, all the common webbrowsers and even windows desktop apps.
For all these services we use JSON, since it seems to be most widely supported format across all languages and platforms, it decodes fairly fast on the clients compared to xml based solution (esp. webbrowsers/javascript) and it has a pretty low overhead that compresses extremely well which is great for clients that lack bandwidth.
Related
Which technology would you suggest for PubSub between Java Service and C# desktop client.
What do you think about CometD? Is there any nice .net API for it?
Server and client will run within the same organization so can use different protocols
Is CometD a right choice at all or would it be better to use TCP instead of HTTP?
Since your apps run within the same organization, you will likely be able to use more efficient transport than HTTP, or even TCP, depending on your situation and requirements.
The Data Distribution Service (DDS) is a standard by the OMG based on Pub/Sub. Standardized language bindings are C, C++, Java and Ada, but C# and others are available as well. Different languages as well as operating systems can be mixed in your system. Structured datatypes to be distributed are specified in a language-neutral format (by the standard a subset of OMG IDL), which is then translated into language-specific interfaces and datatypes to be used by your applications.
It can use different transport layers, like UDP or also TCP. Although I can not determine from your brief description whether DDS would be your best choice, I think it is worth investigating. See this Wikipedia entry for a very brief introduction and list of references.
Warning: I have only used cometd (no atmosphere or even none-java solutions)
I like cometd as it was very fast to get started and the documentation was good. Also the javascript API worked without any issues.
and then the bayeux specification could be implemented on c# too: https://github.com/Oyatel/CometD.NET
http://bugs.cometd.org/browse/COMETD-23
You might want to look at some messaging protocols such as AMQP and STOMP. There's decent support for both protocols in both Java and .NET and you can choose your choice of message brokers such as RabbitMQ or ActiveMQ and others.
I'm in this project:
A web page that's gonna be used by the front-end company people to query and update data from a SQL DB.
I'm working with visual studio and the code behind (C#) is almost done, so the interactions between SQL and C# are ok.
My original idea was to work with ASP.NET which is familiar to me, but that's not gonna be possible. I have to switch to PHP.
So, today is my first day learning PHP, checking http://php.net/manual/en/index.php and a lot of things seem quite similar to ASP.NET so I guess it won't be that hard.
Anyways, some questions popped up quite fast as I wanted to script something else than a "hello world".
Is there an easy way to get/send C# variables from my class using a php page? I've read soemthing about using XML in order to do so, but still I'm scratching my head, is there another, easier, way to do this?
You have options.
direct integration. PHP can instantiate and use .NET objects . See the DOTNET library in PHP. So if you run PHP on Windows, and you expose your .NET logic according to the requirements of the PHP DOTNET infrastructure, then you can just call .NET classes directly from PHP. Some restrictions: PHP is built to integrate with the .NET 2.0 runtime. You can't build .NET 4.0 objects and connect to them from PHP.
synchronous network protocols. As others have suggested you can expose your C# logic via aREST or web services interface, then invoke those services from PHP using the curl library or file_get_contents(). The C# logic could be, but need not be, publicly exposed. In other words, you could make it accessible only from within the firewall of your app, so that no anonymous public access is possible. on the other hand your architecture may call for access to the same API from 3rd-party or user apps. In that case it needs to be exposed publicly.
in either case, public or private, you will want to use WCF or ASPNET MVC to expose these services implemented in C#.
asynchronous mechanisms. PHP can connect to MSMQ. See Using PHP to Open MSMQ Queues . Of course C# can do likewise. You could use MSMQ as a buffering communication mechanism between the two worlds. To do this you'd need to come up with a data serialization protocol, for the messages you put and get on the queue. JSON or XML would be appropriate choices here.
Database. If you are concerned about employing MSMQ as it is "one more piece of infrastructure to manage" you can also employ a database as a go-between. A shared database can be accessed by both PHP and C# and used as a message queue or communication conduit. PHP inserts messages in a MySQL Table, and the C# app could read and process them, then place reply messages in a different table. This would require some work by you to design the message formats, protocols, indexes, and request/reply correlation mechanism. But it relies on proven, existing technology that you already know how to use.
Finally, there is Phalanger. This lets you compile PHP onto the .NET Framework. This means integration between C# and PHP will be simple. I haven't tried this but it might satisfy your requirements.
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/).
We are trying to come up with our client and server standard and there is a big debate. One school of thought is C# client and java servers using some type of proprietary messsage library to share data objects (think XML like structure . .)
The issue with this model is that there is lots of code that needs to be duplicated (validation, parsing) that could simply be reused if you went with C# on the server as well. If there is a big push to use linux machine then wouldn't mono support your goal . .
anyone else have this dilemma?
There are frameworks for this. ICE (ZeroC), "protocol buffers", etc.
For example, my protocol buffers implementation (protobuf-net) works on mono, MS .NET, CF, Silverlight etc - and the binary format is compatible with a range of languages (java, etc). If you start from a .proto (a bespoke definition language), you can use it to generate the object layer in each language you need.
In any case I would use Protocol Buffers or something else defined in a language neutral form for the comms, to ensure that you aren't restricted in future.
Once you've done that you can start with C# on Mono. And then if that proves to be unworkable, you can switch to a different language.
I would suggest you use some old-but-good standard for transferring data between the two, SOAP and XML-RPC come to mind as examples for this. If either of these is possible or feasible, you may want to try JSON or writing your own XML format. Protocol buffers has been mentioned around lately quite a lot but I haven't looked into it so I really can't say anything about it.
I would try to keep the client and the server the same runtime (Java or CLR). We have had plenty of success using a mix of Mono and .Net client/Server.
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."