I’m working on a project at the moment that involves building a system in conjunction with another technical partner. The system will provide “monitoring” type functionality and operations will be long running with numerous “events” being returned and processed / returned to the user.
My initial reaction was to build a web service that did all of this processing, put the results in a database and allowed it to be queried by the other technical partner (via some kind of .NET WCF service interface). This is where I am most experienced having build many solutions such as this in the past. This seems kind of kludgey though in that the communication is then really via sticking something in a database and letting the other process access them.
However I have been reading a lot lately about enterprise integration patterns and messaging solutions and I can certainly see some benefits to this solution. This would allow events to be placed on a queue or bus and then processed accordingly. It seems to offer far more flexibility than a more RPC type web service interface.
Does anyone have any thoughts / experience making this type of choice? Also it is reasonable to use a mixture approaches within a single solution?
The short answer is that a mixture of approaches is ok – assuming there are a variety of contexts which drive the need for them.
If an synchronous call is appropriate (perhaps it’s a web-based UI?) then I’d have though a web service would be ‘better’; if asynchronous is more appropriate then an message queue would seem to be the natural answer.
With WCF you can choose between a number of different binding types – including web services, messaging and remoting – so in theory you can change the binding type via config whenever you wanted too.
Naturally, there are some gotchas, though: the call to the service must not expect a return value; the NetMsmqBinding only support one way communication.
This might be of interest if using WCF: WCF Binding decision chart