Is it possible to implement a RabbitMQ RPC between Java (acting as a client) and a .NET application (server/worker) using the RabbitMQ .NET library?
It seems like it should be possible, as RabbitMQ broker handles the queues and the socket connections are established between party and the RabbitMQ broker.
Are there any practical considerations in doing so?
The short answer is yes. In fact, my company uses RabbitMQ for that very reason - it offers a platform-neutral (as close as possible anyway) way to communicate between different applications. So in theory, I could have Java applications running on Linux and .NET applications running on Windows, and everything works together just fine.
You will need to come up with a common serialization format for your messages; I recommend using JSON as there are JSON libraries in every major programming language.
If you have any trouble with the RabbitMQ .NET library, feel free to post more questions :-)
Related
I'm involved in a project with many others companies. We started to develop our systems at the same time but only at the end the communication problem was taken into account.
I've developed my system on Linux with Mono (Linux is mandatory for me). I have to communicate with a Windows .Net system which is exposing a Wcf web services. Unfortunately they told me only now they are using wsHttpBinding and I've just discovered that this communication protocol is not supported by Mono.
I'm here to ask if there is a way to communicate with that web service. They are not going to change the wsHttpBinding because is used by many other companies. I cannot change my OS and my code base is too big to leave Mono now. I can only add a layer (always on Linux) between my Mono implementation and their web services.
Any suggestions?
Microsoft has recently released the .NET source code as MIT licence (open source).
This means that, if something is not supported by Mono, you can just bring the code yourself and incorporate it, so that it becomes officially supported.
Some Mono developers have actually been doing this the past weeks to incorporate things that they had not implemented yet. So you could bring the wsHttpBinding along to Mono. An example of such a change is this commit.
I have been looking for a comparison between newly released servicebus for windows server, NServicebus and Mule ESB. Requirement is to develop .NET based real-time data integration solution using publisher/subscriber communication pattern.
Idea is to transfer protobuf serialised data messsages over the servicebus.But, it would be great if any of these support file transfers too as we have varied volumes and various kinds of data sources.
I am not sure which one would be a better option to go with.
Really, Azure Service Bus isn't a direct competitor to NServiceBus and Mule ESB. It is closer to a message broker (like ActiveMQ or RabbitMQ) than to an integration platform. It does have a couple of features beyond simple messaging such as web service proxy and some nice mobile push notification support.
Mule ESB is an integration platform, which means you create integration applications by using Mule configuration language and extending Mule programming components using the java platform. You deploy your integration application to a standalone Mule server or to CloudHub (Mulesoft's cloud environment). They also offer a pretty big library of connectors, which simplify integration with various other technologies and SaaS.
I have little experience with NServiceBus, but the documentation shows some of the same features as Mule ESB.
Since you can download both NServiceBus and MuleESB for free to try them, I'd suggest giving them both a whirl to see how they apply to your particular integration problem.
.NET service bus is designed to communicate with Azure and enable devices to do RCP-style calls. It does support pub/sub but the maximum message size is only 64 KB.
NServiceBus is probably the most capable choice in terms of interop. It supports one-way, full-duplex and pub/sub messaging. The maximum message size is 4 MB when using MSMQ for transport, but its data bus can be used to transfer large files. It also has a unique concept of sagas, which are long running processes with a shared state. I have not used the latest tools for it, but traditionally the tooling and integration options were not up to par compared to Java based solutions. Also, the licensing model is complex, and seems to be a subject to change with every release.
There is a Mass Transit free .NET service bus which has most of the NServiceBus features, but is a bit more difficult to use.
[edit] Mule ESB has a free community edition and a commercial version. It is a very mature Java based service bus. It has a lot of tooling and integration options with various products. But I do not think it has sagas. But it does have file transport support.
My only experience with SOA comes from working with NServiceBus. It's really well designed and has some nifty features that I really like:
Processing of messages is transactional (and taken care of for you), so it's "once and only once" (as opposed to "at least once")
Built-in saga support
Automatic retry support
Pub/sub support (but I assume all service/message busses support this)
All that stuff leaves me to concentrate exclusively on the app's logic, but I've only used it in .NET, and Windows is almost certainly a non-starter for the project I'm working on. So my question is...
What service bus technologies out there exist in the *nix ecosystem (including experiences running NSB on Mono) and how do they measure up to NServiceBus running on Windows?
Bonus: In addition to the features above, what languages can send/receive/process messages from the bus? Having the flexibility to write one service in language A and another in language B would be very advantageous for this project.
SonicESB / MQ
I can speak from experience with SonicESB on Linux. It's basically SonicMQ - a JMS compliant MOM - with a process mediation layer on top; that's the service bus.
Pros
Itinerary-based routing; messages contain their own workflow for what services to visit
Intra-container messaging; increases performance by routing messages within the ESB container, avoiding the broker entirely.
Web service endpoints; ESB service may be invoked over HTTP endpoints, bridging the gap between non-Java/JMS clients and the bus.
Good development tools in eclipse for developing and debugging esb services and processes in Java.
Administration tools aren't bad either.
Cons
Transactions don't span service boundaries (may have changed since version 7.5)
No message retry mechanism; we rolled our own using a utility service and message parameter manipulation (may have changed in 7.5)
Pricey; licensed by core, so expect to pay for it.
Client Support
In terms of what technologies can send and receive to/from SonicESB, anything Java JMS, that's for sure. Sonic also offers a library in .net/C#/VB for Windows technology, so you can send and receive messages from the bus. This was a huge plus for us since our development teams use RIA's built in C#.
You may want to check out MuleESB, an open source service bus.
Hope it helps,
It has been quite a while since I've seriously used NServiceBus (in fact, back then, it wasn't even called that - it was just replacement library Udi wrote, to an awful comm library we had to use on a joint project :) ) so I don't know about all NServiceBus features.
I would say, based on what I do know, that Apache Kafka (originally developed by LinkedIn) would be a good starting point. It has relatively strong ordering guarantees, supports publish/subscribe to pools of consumers and is supportive of workflow behaviours e.g. Samza which provides a streaming framework on top of it
Also regarding the client interfaces. You can find the current list here
i'm going to build a instant messager
and now i have to decide how i implement the networking.
So far i only worked with Sockets (TCP or UDP). Now i heared about RMI (in Java) and want this in my C#-Chatapplication too.
There is .NET Remoting and WCF. I think building the instant messager with Sockets is not a good idea, right? But that should i use? .NET Remoting or WCF?
.NET Remoting seems to be the older technologie and is similar to Java RMI. I read that .NET Remoting is faster than WCT (article from 2007).
Which technologie should i use for my instant messager? I want to send formatted text from the richtextbox and inline images.
Furthermore i want to exchange files from chat-client to chat-client.
For .NET Remoting i found a tutorial which uses
ChannelServices.RegisterChannel(myChan);
But this is marked as obsolete. Is .NET Remoting a obsolete technologie?
Is it possible to send images and files with WCF or .NET Remoting or are Sockets the better choice?
I read that WCF is a collection of networking technologies (Web Services, Remoting, ...) but if i search for WCF and remote method invocation i only get examples for Web Services...
BTW: Later, i want to implement a Web-Client for my instant messager with ASP.NET. Are there some limitations respective to Networking (WCF/Remoting)?
Thank you :)
.NET Remoting is maintained for backward compatibility only as of .NET 3.0. Thus, if you are going to be using .NET 3.0 or greater, use WCF.
For your immediate use, I would suggest the NetTcpBinding. You can then select a more appropriate binding using the following chart.
.
Finally, to learn about WCF, refer to this SO question.
For your instant messager solution I would recommend WCF P2P here is an article to get you started Peer-to-Peer Programming with WCF and here it is an example of p2p on codeproject.
I need a way to exchange data between a process and a windows service.
The process (Windows Form Application, Console Application, in the future also a Web Solution) needs to instruct and interact with the windows service.
I want to know which way is the best to accompplish this.
I'll write the solution in C#, .NET Framework version does not matter.
In the past I've used Remoting (Activator), WCF Interface with Contracts, Inter Process Exchange IPC and some named pipe implementation. What is your experience? Other ways?
I would choose WCF. It is most modern and probably best supported approach at the moment. It "replaced" older technologies in most scenarios. Nice feature of the WCF is that if you need to move your service to other protocol you can do that simply in configuration.
If you expect that windows service will always run on the same machine as other application you can use WCF with netNamedBinding. If you decide to move your service to other machine you will have to change configuration (probably to netTcpBinding) because Named pipes in WCF are limited only to IPC.
My previous experiences have always been over an IPCChannel, mainly because the only code I've had to be involved in that does any form of inter-process communication. It's never caused me any problems and the code is working away quite merrily as I type.
The only real answer to this question is, whichever you're most comfortable with.