>>> 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.
Yes we considered this possibility, which is why the WS-* layer doesn't deal with transport-specific concepts, such as a "202 Accepted" response code. Instead it delegates to Destination.getBackChannel()[1]. Then the transport-specific Destination.markPartialResponse() implementation handles the details (setting the response code to 202 in the HTTP case, but doing nothing much for JMS). >> 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... True. CXF support for WS-A and WS-RM were sortta developed in tandem by myself and another committer (who has since left the project). So the one influenced the other. We decided to use the partial response mechanism in all cases for consistency. IIRC we were also influenced by some interoperability concerns, for example with *Systinet.* > is there an easy way (via the API) in CXF to associate a class with a service JAXB context? Do you mean, a way to add the package containing your class to the list of packages passed to JAXBContext.newInstance() used for marshalling the request? Well, one way would be to use the JAX-WS Dispatch mechanism, which allows you to explicitly associate a JAXBContext via javax.xml.ws.Service.createDispatch() [2] Cheers, Eoghan [1] http://cxf.apache.org/javadoc/latest/org/apache/cxf/transport/Destination.html#getBackChannel(org.apache.cxf.message.Message,%20org.apache.cxf.message.Message,%20org.apache.cxf.ws.addressing.EndpointReferenceType) [2] http://java.sun.com/javase/6/docs/api/javax/xml/ws/Service.html#createDispatch(javax.xml.namespace.QName,%20javax.xml.bind.JAXBContext,%20javax.xml.ws.Service.Mode) 2009/3/24 Andrew Harrison <[email protected]> > > 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] > > > > >
