Choosing a messaging solution

Question

so i am building a client server application and i have to chose how they are going to talk to each other. i can:

1. have a TCP connection between client and server
2. send messages over REST or SOAP
3. using Tibco RV, EMS or IBM MQ . .

is there a matrix anywhere that can show me where i would use one of these technologies versus another. stuff like performance, reliability, etc would be helpfu.

Answer 1

Go for WCF if you have a pure .NET to .NET application. It will make your life simple when it comes to doing TCP/IP but preserving a nice layer of object oriented design to your messaging. It also makes it insanely easy to unit test your messaging code, which is I think the biggest benefit.

WCF will do TCP/IP, pipes on the local machine and it also supports many HTTP based solutions. You also get security for free on most of it and the code does a lot of error handling in the communication layers for you.

If you need an MQ solution, then have fun though. MSMQ is supported, but then again it's also MSMQ.

Using other solutions will benefit from more features, but with features comes complexity and risk. I've personally integrated a .Net application with websphere MQ and I was unimpressed with the cost and benefits of the solution. Not to mention that the performance of MQ on non P-Series hardware is lacking to say the least.

Answer 2

When building a communications app on .NET, the answer is almost always WCF. WCF does

• SOAP - including WS-*
• REST - XML, JSON, other
• sockets
• pipes
• binary formats
• Tibco RV
• IBM MQ
• MSMQ
• SAP
• lots more

The idea behind WCF is this: it is a general communications framework that maps over any communications substrate you wish to use. This means the programming model is consistent, the concepts are consistent, and the operations/administration is consistent. If you choose WCF and you want logging, it works the same way, regardless of what substrate you choose. AND, if you choose WCF, you can use named pipes when the parties are local, and switch to TCP when you distribute them. It requires no code change, only a configuration change. Which can be nice.

As for choosing the substrate - well, that is up to you. Depends on the features and capabilities you need, your requirements.

Answer 3

Queued or not queued?

What do you need from your messaging solution?

1. Interoperability? Do you need to be able to expose your solution to other applications? Then you'll need to go with one of the formats and protocols supported out there and that 99% of the cases means REST or SOAP
2. Availability? Does your client needs to be able to send message even when the server is down, unavailable or going through maintenance, then you'll certainly need a queued solution (MSMQ, MQ, SSB)
3. Security? Do the client and server need to authenticate across domains of trust? Then you need to make sure your solution has a non-domain based story for authentication (eg. certificates).
4. Reliability? If you client crashes, does it needs to resume sending pending messages? Again, only a queued solution will help here.
5. Correlation? Do you need to process correlated messages in order, do you need exclusive access to correlated messages, do you need to send back replies? Not all solutions offer a session semantics.
6. Scalability? Do you need to support one client or one million? Again, only a queued solution will work after a certain scale.
7. Spikes? Does your traffic has any spikes, like certain hours or days when it surges up? A coupled solution has to be planned for the capacity to accept the highest spike it can encounter or it will unceremoniously reject clients. If your hardware cannot cope with your regular spikes then you'll have to use a queued solution.

If you like WCF then you going to get a lot for free from it. But basically there are two modes of doing messaging: queued and non-queued. WCF offers a huge matrix of interchangeable channels, bindings, formats, protocols and authentication methods that can be switched in and out at a simple change of the .config file. But they're all for the non queued mode. If your solution is OK with a coupled communication channel then probably there's nothing better than WCF at the moment for CLR applications. If your requirements impose a queued based solution then you'll loose all the cool interchangeable binding toys and you'll leverage from WCF the serialization and maybe the activation model of your service.

And last but not least 90% of the messages sent in any messaging solutions end up in a database and quite a few also originate from a database. If you want a tight integration with SQL Server databases that offers performance while guaranteeing reliable delivery, there is a solution for that in SSB.