REST, WCF and Queues

Question

I created a RESTful service using WCF which calculates some value and then returns a response to the client.

I am expecting a lot of traffic so I am not sure whether I need to manually implement queues or it is not neccessary in order to process all client requests.

Actually I am receiving measurements from clients which have to be stored to the database - each client sends a measurement every 200 ms so if there are a multiple clients there could be a lot of requests.

And the other operation performed on received data. For example a client could send an instruction "give me the average of the last 200 measurements" so it could take some time to calculate this value and in the meantime the same request could come from another client.

I would be very thankful if anyone could give any advice on how to create a reliable service using WCF.

Thanks!

Answer 1

It will depend on what you mean by "calculates some value" and "a lot of traffic". You could do some load testing and see how the #requests/second evolves with the traffic.

Answer 2

If you are using Web Service, Transmission Control Protocol (TCP/IP) will act as the queue to a certain degree.

TCP provides reliable, ordered delivery of a stream of bytes from one program on one computer to another program on another computer.

This guarantees that if client sends packet A, B, then C, the server will received it in that order: A, B, then C. If you must reply back to the client in the same order as request, then you might need a queue.

By default maximum ASP.NET worker thread is set to 12 threads per CPU core. So on a dual core machine, you can run 24 connections at a time. Depending on how long the calculation takes and what you mean by "a lot of traffic" you could try different strategies.

The simplest one is to use serviceTimeouts and serviceThrottling and only handle what you can handle, and reject the ones you can't.

If that's not an option, increase hardware. That's the second option.

Finally you could make the service completely asynchronous. Implement two methods
string PostCalc(...) and double GetCalc(string id). PostCalc accepts the parameters, stuff them into a queue (or a database) and returns a GUID immediately (I like using string instead of Guid). The client can use the returned GUID as a claim ticket and call GetCalc(string id) every few seconds, if the calculation has not finished yet, you can return 404 for REST. Calculation must now be done by a separate process that monitors the queue.

The third option is the most complicated, but the outcome is similar to that of the first option of putting cap on incoming request.

Answer 3

You could use the MsmqBinding and utilize the method implemented by eedsi9n. However, from what I'm gathering from this post is that you're looking for something along the lines of a pub/sub type of architecture.

This can be implemented with the WSDualHttpBinding which allows subscribers to subscribe to events. The publisher will then notify the user when the action is completed.

Therefore you could have Msmq running behind the scenes. The client subscribes to the certain events, then perhaps it publishes a message that needs to be processed. THe client sits there and does work (because its all async) and when the publisher is done working on th message it can publish an event (The event your client subscribed to) letting you know that its done. That way you don't have to implement a polling strategy.

There are pre-canned solutions for this as well. Such as NService Bus, Mass Transit, and Rhino Bus.

Answer 4

There's nothing WCF specific here if you are RESTful the GET for an Average would give a URI where the answer would wait once the server finish calculating (if it is indeed a long operation) Regarding getting the measurements - you didn't specify the freshness needed (i.e. when you get a request for an average - how fresh do you need the results to be) Also you did not specify the relative frequency of queries vs. new measurements In any event you can (and IMHO should) use the queue (assuming measuring your performance proves it) behind the endpoint. If you change the WCF binding you might still be RESTful but will not benefit from the standard based approach of REST over HTTP