On 24 Mar 2009, at 12:13, Eoghan Glynn wrote:
It might be nice to be able to set this somewhere if the message
protocol
considers that a 202 might be the best strategy.
Shouldn't the <wsa:ReplyTo> header be set to anonymous in those
cases? You
could provide the callback/sink reference via some other header for
example,
or via an explicit parameter (say in the style of the <wsrm:AcksTo>)
You're right. ReplyTo implies an asynch response. For my particular
situation there should either be no ReplyTo, or a controller service
that receives the response and triggers the sink creation.
Have any tests been done on the impact of this with other transfer
protocols?
By other transfer protocols, do you mean HTTP versus FTP etc.?
yes - protocols that do not support the concept of an Accept. I mean
sending partial responses - not the asynch response.
Not really, as HTTP is the primary target transport for WS-RM (why
use RM
with the JMS transport for example, as this provides its own native
delivery
guarantees).
Except this happens without WS-RM as well...
So when the 202 is sent, I presume the HTTP connection is closed?
Depends on whether HTTP keep-alive was enabled.
But assuming it wasn't, then the client will drop the outgoing
connection on
receiving the 202.
Then another connection is opened to send the full response based
on the
ReplyTo header?
Yes.
That's really the nub of it. One sets <wsa:ReplyTo> to a non-anonymous
address so as to cause this separate server->client connection to be
established when the response is ready for delivery.
Cheers,
Eoghan
Thanks again.
One slightly unrelated question - is there an easy way (via the API)
in CXF to associate a class with a service JAXB context? I have a
class that is modeled in wsdl as having an xsd:any. But I would like
client code to be able to easily insert their own data structures into
the any list and be picked up during (un)marshalling.
cheers,
Andrew
2009/3/24 Andrew Harrison <[email protected]>
Hi Eoghan,
Thanks for the quick response :-)
This makes sense to me, although it seems potential overkill in
some cases.
It might be nice to be able to set this somewhere if the message
protocol
considers that a 202 might be the best strategy. I'm implementing
WS-Eventing. At the moment there is no real need for a 202 because
the
messages are just control messages as opposed to application-specific
exchanges (These obviously happen via notification in WSE). I
suppose this
could change.
Have any tests been done on the impact of this with other transfer
protocols?
The isPartialResponse(message) was the incantation I was looking
for to
handle this in my interceptors - thanks for the clue.
So when the 202 is sent, I presume the HTTP connection is closed?
Then
another connection is opened to send the full response based on the
ReplyTo
header?
I presume this is the case because my sink service was not actually
deployed until the response to the subscribe operation returned -
which is
where the exception was occurring. This is because you may not want
to
deploy a sink unless the source actually accepts your subscription.
But this
is an error on my part - you shouldn't include a replyTo to
something that's
not there yet!!
I am getting other exceptions now, but I think I can work it out.
Thanks for you help.
cheers,
Andrew
On 24 Mar 2009, at 10:05, Eoghan Glynn wrote:
Hi Andrew,
The purpose of ContextUtils.rebaseResponse() is to cause a partial
response
to be sent from the server-side interceptor chain when an incoming
message
with a non-anonymous <wsa:ReplyTo> is encountered.
A partial response may have some <soap:headers> but always has an
empty
<soap:body/>. The purpose of sending this message is two-fold:
(a) to unblock the client-side transport with a HTTP "202 Accepted"
response
(b) to optionally allow for certain headers to be passed back to the
client
*at the earliest possible opportunity
*The motivation for (a) is to avoid tieing up a connection for the
duration
of time required to process the request, given that the full
reponse is
going to be sent on a separate server->client connection.
The main motivation of (b) was the timely provision of WS-RM
acknowledgements.Any pending ACKs may be encoded in the partial
response
to
avoid establishing a new server->client connection just to deliver
these
ACKs. Waiting for the full response to be ready in order to send
pending
ACKs may not be feasible as the request may take an indeterminate
amount
of
time to process.
Now where is the exception on the outgoing partial response actually
occurring?
Is it in your own interceptor code? Do you need to actually do
anything
specific with the partial response? If not, how about just
ignoring it and
allowing it to complete without interference? You can check if a
message
is
a partial response via the
org.apache.cxf.message.MessageUtils.isPartialResponse() API.
Cheers,
Eoghan
School of Computer Science, Cardiff University,
Queen's Buildings, 5 The Parade, Cardiff CF24 3AA, Wales, UK
tel: +44(0)2920 879184
email: [email protected]
