I read a post one of my colleagues, Yuval Mazor, had written -
ReactiveQueue Example: Increasing Throughput for Stateless WCF services
After reading the post I decided I have to comment on this.
I must say, I enjoyed the blog post and it does show what RxContrib can do for you, a really good job.
I understand the example there is just for the sake of showing RxContrib capabilities but I feel like I have to say a couple of words about it :)
In general, you should always design your services properly to meet its purpose and requirements.
I don’t want to get into a deeper conversation regarding SOA principles and where developers usually get it wrong, but this is a good example for that :)
Exposing a functionality in a service is the most basic “SOA” manner does get you to say “Yippy, I’m doing SOA”, but it can certainly be that you’re doing it the wrong way.
Looking at the service example in Yuval’s post – a common stateless logging service which should be available to large amount of client calls.
- The service in that example is configured as a singleton and with single concurrency mode – Why?
- If the solution to improve its throughput is to move all calls to a concurrent queue manipulation technique – Why not handle calls concurrently in the service level?
- If the service is stateless and no synchronization or ordering is important – Why not make it PerCall?
- Low on resources and doing IO work – Consider implementing the service in asynchronous pattern.
- Consider making the operation One-way and choose appropriate bindings
Actually, if the service had been designed better, I don’t think you would benefit all that much from using RxContrib in this case. on the contrary, it may even affect it to the worse, though I have to say I didn’t check it.
In conclusion, you should always examine your services in a systematic view and design it properly to meet your requirements. Otherwise, it is just plain bad SOA.