Asynchronous vs. synchronous Web Services practices?

Question

I venture that most but not all web services today are synchronous. A fundamental design decision existing if to implement asynchronous processing.

Is there value in implementing a processing queue system for asynchronous web services? It is a MOM/infrastructure decision with which I am toying. Instead of going system-to-system implement a middleware which will broker said transactions. The ease of management and tracking/troubleshooting of a spider web of services seems to make the most sense.

How best have you implemented asynchronous web services?

Answer 1

It is interesting I stumble into this question. I have exactly the same concern with the current project I am developing.

Our web services are develop using TIBCO technology, and they are also synchronous by default. We are considering creating a queue mechanism to process these requests asynchronously; the reason being: the back-end storage technology we have to interface with is notoriously slow (it is an imposed technology, and we have to deal with it)

Personally I am considering creating a 2nd WSDL definition for the asynchronous replies (which can occur from a few seconds to a few hours later than the request, depending on the load on the mentioned back-end storage.) Clients calling our Web Services will have to in turn implement a web service using this "2nd WSDL" to which we act as clients.

I'd be interested in knowing the directions you are exploring.