Bridge to asynchronous water
Kevin W. Hammond points out that programming asynchronous webservices (using SOAP over MSMQ) creates a mindcandy for developers used to the RPC style of SOAP over HTTP:
If you want request/response semantics when using SOAP over MSMQ, you must keep in mind that the WSE 2.0 channel model actually requires your client to become a server. Â Your client must listen for incoming SOAP messages and understand how to act upon them to correlate them back to the original request, which is distinctly different from the blocking semantics you get with SOAP over HTTP.
[Kevin W. Hammond]
In my opinion this is one of the areas withing SOA that needs more attention. When designing services on different layers of applications, and between applications you will at some point find it reasonable to implement a service asynchronously to ensure scalability and reliability, among other things. Most developers that design UIs will say that they need to be synchronous to respond to their users fast enough to not make the users go do something else.
Kevin also points out that a service invoking an asynchronous method needs, itself, to be a service in order to receive the callback when the message is processed, thus increasing the complexity of the calling service.
One solution for some use cases is datacaching. User Interface services can work towards a cached set of data optimized to reduce potential conflicts. Updates to the canonical data source can then be done asynchronously in the background, creating the illusion of synchronousity. This approach does however demand some form of conflict handling for the scenarios where the canonical data conflict with the cache upon which the update was made.
I am thinking about this these days, and hoping for guidelines. According to subtle signals from the Indigo evangelists they will make the programming models (sync/async) more transparent. For now it' really just a matter of good architecture, and we can probably learn a lot from people that have implemented highly scalable (transacted) asynchronous systems for a long time. However, someone with the knowhow would at least get my appreciation and respect for bridging to the asyncronous waters in my SOA implementations.