views:

894

answers:

1

I need some framework that will help me to do asynchronous streaming over http. It may look like SOAP WS or somethign else. I don't know if I name it correctly, so here is what I need:

ServerA wants to make a request to remote ServerB over http. The request contains arbitrary information. Result for it is going to contain multiple records of the same type. Some of them are available immediately, other are available later. ServerA wants to get available results as soon as possible, without waiting until all results are available. In real world ServerB will search across different data sources, some of which are more responsive that other.

I can think of 3 kinds of solution. First, ServerA generates random id of request, performs SOAP request

void ServerB.startSearch(id, request);

that will return immediately, and then A periodically calls

Result[] ServerB.areThereAnyNewResults(id);

So ServerA polls ServerB fore new reasults. I call this method polling. It involves multiple connections established from A to B. Another solution is to expose receiving service on ServerA side, like

ServerA.acceptResults(String id, Result[] newResults);

and call

ServerB.startSearch(id, request, serverAReceivingServiceEndpoindAddress);

So ServerB pushes new results to ServerA.acceptResults() when new results are available. I call it pushing. It involves 1 connection established from A to B and multiple connection established from B to A.

Another option is to stream results over same http channel, within single response.

A performs http call (I don't know if it can be SOAP or should be something else), B starts searching and when new results are available, it sends them over http stream and flushes it, so they may be available on the A side immediately. It does not close http connection until all results are available. It involves only single connection from A to B, thats why I would prefer to use it. I call it streaming. I understand that it may not work if some proxy is on the way that buffers the response content.

So, my question is if there is any solution that will do most of the work for me. What I'd like to do is call such code on A side

Service s = new RemoteAsyncService("http://serverb.com/serviceEndpoint", RemoteAsyncService.STREAMING); 
// or RemoteAsyncService.POLLING, or RemoteAsyncService.PUSHING
Request r = new Request(...);
Callback callback = new Callback(){
 void newResults(Result[] result){...}
 // e should be null if finished correctly
 void requestFinished(RemoteException e){...}
}
s.search(request, callback);

And implement it on ServerB side

public ServiceImpl implements Service{
  void search(Request r, Callback c){
   // perform search, call c.newResult() when new results are available
  }
}

And the rest is handled by framework, including reestablishing connection when it is dropped, falling to polling/pushing if streaming can not be done because of buffering proxy, calling callback.requestFinished() when ServerB finishes work or throws the exception, etc. Probbaly it should also handle authentication in some standard way.

So, is there any solution that abstracts the way commuinication is done, and is capabale of streaming when possible?

If there is not, do you think it would be useful to implement it as open source? :)

+1  A: 

What you're talking about sounds like a COMET service. You can read the Wikipedia entry here:

Comet (programming)

Not sure how you'd implement something like that in Java, but in .NET you can use a Duplex contract for a WCF service. You can read more about how to access and communicate with that style of service here:

How to: Access Services with a Duplex Contract

Justin Niessner
For Comet, servlet containers like [Jetty][1] have reasonable support. And yes, it does sound like Comet might help here.And conversely, SOAP is probably not all that useful -- rather, Comet or RESTish web service would allow more flexibility. [1]: http://www.mortbay.org/jetty/
StaxMan
I'd think Comet style communication would be limited to special cases because if the turnaround period is very long you can exhaust resources at both ends a pending operations pile up over time. Since SOAP is basically sync RPC, you almost end up needing to have two SOAP services, one exposed by the "server" and a reply/callback service exposed by the "client" who makes the initial call passing along a reply-to URI to tell the "server" where to callback to. I suppose this is what a WCF Duplex Contract is more or less.
Bob Riemersma