Question

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?

Answer 1

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

友情链接