You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "john.greeley" <jo...@saic.com> on 2009/09/25 01:01:26 UTC
Re: [cxf] Support for WS-Polling, or some other way-one http
connection?
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 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