 |
Can I call you back? - Asynchronous Web Services
Posted by johnreynolds on February 01, 2006 at 07:32 AM | Comments (5)
Asynchronous Services are a fact of life, and a key requirement for successful SOA solutions.
Doug Kaye summed it up well in his book, Loosely Coupled:
The Missing Pieces of Web Services:
"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 181 defines 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.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
FWIW this is one of the motivating factors of the SCA standard being used in the Apache Tuscany project; it provides annotations like @Oneway and @Callback to enrich POJOs with the metadata to describe asynchronous method calls, remote services, callbacks and session lifecycles (what should be sticky or not etc).
Incidentally in the JMS world, we've had these features for while in Lingo: http;//lingo.codehaus.org/ which offers async one way methods, async request-response and traditional request-response as well as publish/subscribe and queue based load balancing.
Whichever technology is used to achieve async services, the future is clear - we need to annotate code with metadata to indicate which operations can proceed asynchronously, what are callbacks - then let the middleware techology inject into our POJOs so that the actual implementation middleware stays out of our business logic.
Posted by: jstrachan on February 01, 2006 at 08:11 AM
-
Very cool jstrachan... Apache Tuscany sounds interesting.
--JohnR
Posted by: johnreynolds on February 01, 2006 at 03:13 PM
-
I'm skeptical about this. "loosely coupled" and "callbacks" aren't the same thing. A callback requires that
the client know the server
the server know the client, making them peer to peer
the client able to track over time and relate callbacks to the initiating process
The systems that you describe may not be tightly coupled in the classic sense, but they certainly are coupled. I’m also having trouble imagining a web service that runs so long that the client can’t simply wait for a response. If it’s anything less than an hour the client can open an HTTP call and leave it open without consuming a thread (assuming it's using NIO)…the server could send small packets every now and then indicating that it was still working. If the server needs more than an hour, then I don’t see why the client can’t go ahead and use coarse grained polling on the order of a check every hour. It’s simple, if the web service is long running, then you probably don’t need to know it’s finished the instant it’s done…and if the web service is short running, you can get the result in a normal HTTP request/response. This web service call back thing is another solution looking for a problem. The clearest indication that we should move along is the JSR reference. Yet another JSR…yikes, run away, run away!
Oh, you may also want to have a checkup…I think you’ve come down with AJAX Turret’s syndrome (the uncontrollable urge to insert the word “AJAX” into every discussion.)
Posted by: tcowan on February 03, 2006 at 07:53 PM
-
tcowan,I can't (AJAX) imagine what the (AJAX) heck you are talking (AJAX) about... I hardley (AJAX) ever (AJAX) even think about (AJAX) any more... unless (AJAX) of course, (AJAX) I happen to be awake at the time (AJAX), or dreaming ;-)
In all seriousness though, don't get too hung up on the "Web" part of "Web Services". What's being developed are standards for building heterogenous distributed programs using SOAP... one service endpoint may be C# .Net, another endpoint Java, and another Ruby (and all of these services may be hosted by separate business partners).
I'm kind of surprised that you are "having trouble imagining a web service that runs so long that the client can't simply wait for a response", and I'm even more surprised that you think "if the web service is long running, then you probably don’t need to know it’s finished the instant it’s done".
Think about a Publish/Subscribe scenario; you want to know the moment something happens, but you have no idea when the event may occur (could be hours).
Asynchronous scenarios are actually quite common in many Business Processes. If you're thinking Web Page == Web Service Client, then you need to widen your horizons. Think more along the lines of using something like BPEL to orchestrate services in a long running multi-party business process.
Of course, if you could get all your business partners to agree to use Jini you'd be able to do all of this much more efficiently, but sadly, that's not happening in the world that I live in :-(
--JohnR
Posted by: johnreynolds on February 03, 2006 at 09:02 PM
-
Check out eBay's Web Services. I do not know if any of these are asynchronous at present, but it would certainly make sense if they were.
--JohnR
Posted by: johnreynolds on February 10, 2006 at 07:24 AM
|
java.net RSS Feeds
