You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by sol myr <so...@yahoo.com> on 2009/06/09 17:02:15 UTC
[cxf] Support for WS-Polling, or some other way-one http connection?
Hi,
Does CXF support WS-Polling (http://www.w3.org/Submission/ws-polling/)?
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.
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).
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.
Re: [cxf] Support for WS-Polling, or some other way-one http connection?
Posted by Andrew Harrison <a....@cs.cardiff.ac.uk>.
I was going to say that WS-Eventing supported the concept of pulling
events from a source, but as of *yesterday*, the spec has changed
considerably and no longer covers this. Instead, WS-MakeConnection is
referenced. :-)
At a tangent, WS-MetatdataExchange seems to be being used for a number
of out-of-bound considerations in different specs (for example, in
terms of WS-Eventing, finding out what the sink interface should look
like).
Are there any plans to support WS-MetadataExchange in CXF?
cheers,
Andrew
On 25 Sep 2009, at 20:12, Daniel Kulp wrote:
> 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
> dkulp@apache.org
> http://www.dankulp.com/blog
Re: [cxf] Support for WS-Polling, or some other way-one http connection?
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog
Re: [cxf] Support for WS-Polling, or some other way-one http
connection?
Posted by "john.greeley" <jo...@saic.com>.
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
> dkulp@apache.org
> 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.
Re: [cxf] Support for WS-Polling, or some other way-one http connection?
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog