Unfortunately not, although I agree from a architecture perspective.
The client is behind a firewall/proxy. The client will be pulling
transactions from a "public" server and feeding them into an internal
system via a different api, basically it's a bridge between two systems
with two APIs. The one system I have control over, and I have control
over the bridge.
The client needs to be fairly responsive to new transactions that become
"available" on the server and I'm worried polling would be expensive.
On 09/10/2012 01:16 PM, Ron Wheeler wrote:
This sounds like a "push" application.
Can you not put a web service on the client side that the server calls
when it has something new to say?
Ron
On 10/09/2012 9:29 AM, David Mansfield wrote:
Hi All,
Just wondering what the best practice is for having a web service
client "wait" for some event that happens server side.
In my particular case, I need to have a web service along the lines of
"get pending transactions" and a new transaction is submitted via a
form submit in the web application (servlet), hopefully in the same VM.
I realize polling is an option of course, but I despise polling and
would prefer some kind of blocking-queue type implementation with a
blocking "take" in the web service method and a "put" in the servlet
during the POST or whatever.
Some other considerations: it will only ever be _one_ client calling
the "get pending transactions" so issues of resource consumption by a
blocking call are not relevant.
Can I simply implement some blocking java code inside my web service
method and everything will just work neatly?
I have read about multiple asynchronous replies to a web-service
method and was wondering what that really means and if there are a any
references in CXF documentation?
TIA,
David Mansfield
Cobite, INC.
