Isn't this type of "backchannel" delivery covered by WS-MakeConnection (http://docs.oasis-open.org/ws-rx/wsmc/200702)
On a related note, are there any plans to implement the newer OASIS WS-RX specs (WS-ReliableMessaging and WS-MakeConnection)? dkulp wrote: > > On Tue June 9 2009 11:02:15 am sol myr wrote: >> Hi, >> >> Does CXF support WS-Polling (http://www.w3.org/Submission/ws-polling/)? > > Nope. I actually had to find someone that new something about it to > give me > some history on it as this is one of the WS-* things I really hadn't heard > much about. (Thanks for the chat Glen Daniels!) > > Basically, from a "spec" standpoint, it doesn't look like it has really > gone > anywhere. Submitted in 2005, and pretty much nothing since then. > Neither > Glen (PMC of WS/Axis2) nor I could really find anyone that has implemented > it. > > That said, it's not a bad idea and definitely would have some use cases. > > >> Or some similar mechanism for one-way HTTP connections? >> >> For those unfamiliar with WS-Polling, please note it's not >> "response.isDone() polling"... >> >> WS-Polling means that when a service finishes calculating a response, >> it doesn't send it back to the client, but rather stores it on the >> server machine, until the client asks (polls) for it, using a dedicated >> protocol. > > In CXF, this part really wouldn't be that hard to implement. An > interceptor > that runs immediately after the ServiceInvoker interceptor could store the > message/exchange in a map on the Service or similar and then pause the > chain. > When a request comes in to obtain the result, look it up from the Service > and > resume the chain. Obviously some protocol mapping in there, but nothing > major and no different than what is done for WS-SecureConversation and > similar. > > >> That's low-level control on the way/timing responses travel on the wire >> - as opposed to "response.isDone()" which is an abstract API that >> assumes nothing about the underlying connection management (we would be >> glad if this API could transparently use WS-Polling behind the scenes). > > THIS is where the harder part is in CXF. This would require some > refactoring > of the client side stuff to get the "isDone()" to call call back into the > protocol stack to get the result. Nothing too major, but definitely > would > require some more thought. > > In anycase, it's definitely something that has NOT been on the radar > screen > for CXF. If it's something you'd like to tackle and submit patches > toward > it, that would be great. I'd be happy to help out "mentoring". > > Dan > > > >> We became interested in WS-Polling after eliminating some other options: >> >> - WS-ReliableMessaging is an overkill for us: our messages are not >> critical, and don't need reliability. >> >> - WS-Addressing with <ReplyTo> is problematic because our clients are not >> allowed to open a ServerSocket. >> >> >> >> Thanks very much. > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog > > -- View this message in context: http://www.nabble.com/-cxf--Support-for-WS-Polling%2C-or-some-other-way-one-http-connection--tp23944675p25599581.html Sent from the cxf-user mailing list archive at Nabble.com.
