Communication (Interprocess) between applications?

Question

I'm about to write a "server" application that is responsible to talk with external hardware. The application shall handle requests from clients. The clients send a message to the server, and if the server is busy with doing stuff with the hardware the new messages shall be stored in a queue that will be processed later.

The client shall also be able to cancel a request (if it is in the server's queue.). When the server application is finished with the hardware it shall be able to send the result back to the client that requested the job.

The server and client applications may or may not be on the same PC. All development is done in .NET (C#) 2005.

So, my question is: what is the best way to solve this communication problem?

MSMQ? SOAP? WCF? Remoting? other?

Answer 1

Remoting

If all development is done in .NET 2005, Remoting is the best way to go. http://en.wikipedia.org/wiki/.NET_Remoting

Answer 2

Assuming you can use .NET 3.0 or greater then you probably want to WCF as the communications channel - the interface is consistent but it will allow you to use an appropriate transport mechanism depending on where the client and server are in relation to each other - so you can choose to use SOAP or MSMQ or a binary format or others as appropriate (and can roll your own if needed). It also covers the need for two way communication.

Queuing the messages at the server should probably be regarded as a separate problem - especially given the need to remove queued messages.

Answer 3

If clients and server processes are on the same machine, I think Named pipes will give you the fastest raw byte transfer rate. If the processes are across different machines, you'd need to use Sockets based approach.

Remoting is reportedly very slow. based on the target OSes that you're planning to deploy the solution on you could have options like WCF et.all However the overhead of these protocols is something you may want to look at while deciding.

Answer 4

MSMQ would make some sense, though there are then security and deployment considerations. You could look at a service bus (such s NServiceBus or MassTransit) and there's also SQL Server Service Broker that could help (and can also be used by a service bus as the transport).

WCF would be another thing to look at, however that's really the across-network transport, so you'd probably still want the WCF calls to put a message on the server queue.

I don't recommend remoting, because it's hard to maintain a separation of concerns, and before you know it you're developing a really chatty interface without realising it. Remote calls are expensive in relative terms, so you should be trying to keep the messages fairly coarse-grained. WCF would be my recommendation. Not least because you can set it up to use a HTTP transport and avoid a lot of deployment and security headache.

Answer 5

The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication, because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards, and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.

Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection.

Choosing Communication Options in .NET helps you decide which form of interobject communication you want for your application.