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
[email protected]
http://www.dankulp.com/blog
