On Thu September 24 2009 7:01:26 pm john.greeley wrote: > 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)?
At one point, Eoghan was looking at it, but I know he's busy on unrelated things right now so no work as started toward it. :-( Dan > > 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
