"Many of the benefits of web services can't be realized until asynchronous interaction becomes well understood and widely practiced, and some high-value applications can't be deployed properly or at all without it."
The simplest approach for implementing an asynchronous web service is to pursue a polling approach; the client makes a request, and then at a later time checks back to see if the response is ready. The advantage of this approach is that it is universally accessable... an AJAX enabled web page could easily handle polling. The down side is that... well... you are polling. Polling is probably the biggest waste of bandwidth we could devise, and you've got that nasty problem on the server: How long should I hold the response?
A more elegant approach for implementing an asynchronous web service is to pursue a callback approach; the client makes a request and leaves a return address (where the service should send the response). The obvious drawback to the callback approach is the limitation that it places on the client; the client must have a mechanism that allows it to receive messages.
Best practices suggest that you should support both polling and callbacks when implementing an asynchronous web service. Supporting both approaches will make your service accessible to the widest audience of clients, and that's a good thing.
Web Service Addressing defines standard SOAP headers for request and response messages. Most web service containers do not directly support this specification yet, but hopefully that's changing.
What would really help the average Java business programmer would be a "standard" technique for decoupling the code for implementing each asynchronous technique from the code that actually implements the business functionality of the web service. Why clutter up business logic with what is essentially messaging logic?
JSR 181defines metadata for injecting web service aspects into POJOs, but it does not appear (to me at least) to provide for automating the creation of dual implementations (polling and callback).
My general feeling is that we are on the cusp of ubiquitous asynchronous web services, but we aren't quite there yet. It's still mostly a "roll-your-own" frontier, but the tracks have been laid and civilization is sure to follow.