Cross Language Messaging [closed]

Question

We use a java-focused tool that uses JMS both internally and to communicate with external java software. We now have to set up a new interface to a C# application. Our JMS provider provides a C# implementation that should work but I'm not entirely sure JMS is the way to go in this case. It would introduce a new vendor-specific dependency in a C# application both for the details of the implementation and the support of the client.

Some googling led me to STOMP which seems to be an established wire-level protocol supported by multiple JMS-capable message brokers (hornetq, activemq,...) but there appears to be a distinct lack of actual clients in C# (and java to some extent). Without delving too deep I'm also not entirely sure where the emphasis on "Text" comes into play? Does it not support binary objects?

Another solution could be AMQP which is another wire-level protocol but the 1.0 spec has not yet been released and we are weary of implementing the 4-year old 0.9.1 spec because it seems a lot has changed in 1.0.

What solution would be best for inter-language asynchronous messaging considering security, support, transactionality, standards compliancy, portability,... Note that soap with the proper WS-* is not an option for this particular interface.

EDIT1: I have seen questions such as Cross-platform, cross-language messaging system? but they seem to focus on a specific tool that works in multiple languages. I'm actually looking for a standards compliant protocol that is or can be implemented by multiple vendors.

Answer 1

An option would be to abstract the C# client from the underlying specific notification protocol and let it work at the level of in-ports and out-ports where in-ports and out-ports are implemented with common interop adapters - a relational database, a web service, a xml file in specific folder.

It is your responsibility to provide adapters and a bridge between adapters and your messaging subsystem but there are clear benefits: the mutual obligation between enterprise environments is defined at very common level. You can even replace the messaging subsystem someday and retain all your in- and out-ports. In other words, the C# client wouldn't even notice that you replaced JMS with another messaging infrastructure because it still sends/receives the data from the same set of adapters.

Answer 2

I don't know if I understood your question correctly but RabbitMQ is an AMQP implementation and has bindings for C# and Java.

In order to prevent "a new vendor-specific dependency in a C# application" you might want to have a look at the Messaging Component in the Spring.Net framework as well as their related AMQP for .Net project. This allows you to have POCOs and business logic separated from the messaging middleware and infrastructure.