Hi Oli, thanks for the clarifications,
I'm wondering, is it indeed "Robust In-Only" case that we are talking about here : http://www.pacificspirit.com/Authoring/async/async-scenarios.html#twoway-robust-inonly-b so we have a client sending a oneway request, getting a 202 ACK, and then possibly getting a fault back at some local endpoint. But CXF does not support WSDL 2.0... cheers, Sergey On Fri, Oct 1, 2010 at 8:03 AM, Oliver Wulff <[email protected]>wrote: > Hi Sergey > > I thought that wsdl 1.1 specification requires that a fault message is used > only in combination with an output message. > WSDL 2.0 defines the MEP called "Robust In-Only" where you could define an > input and a fault message. > > I'm only aware of WS-ReliableMessaging where a soap envelope can be > returned for a one-way message to send the acknowledges back where soap body > itself is empty. This is only valid if the Anonymous epr is used for AcksTo > element. > > Oli > > ________________________________________ > Von: Sergey Beryozkin [[email protected]] > Gesendet: Freitag, 1. Oktober 2010 00:19 > An: Daniel Kulp > Cc: [email protected] > Betreff: Re: Interceptor chains, one way requests, WSA FaultTo > > Hi > > I'm wondering, does Fault qualify as a response in case of one way > requests. > > I'm thinking that may be specifying a decoupled FaultTo as part of oneways > is an attempt to find out if a given oneway request ultimately succeeded or > not. > > Thus I'm not sure what the right answer is here. It's part of the advanced > WSA-related transactions framework test suite but if it is a valid test - I > do not know... > > But I guess that code I'm prototyping may also help in cases where we have > a > 2 way request and decoupled ReplyTo and FaultTo values. At the moment, the > fault will be sent to the decoupled ReplyTo (because > ContextUtils.rebaseUtils uses replyTo to rebase)... > > We then can decide if we want that code to execute in case of oneways or > not. > > cheers, Sergey > > > On Thu, Sep 30, 2010 at 7:45 PM, Daniel Kulp <[email protected]> wrote: > > > > > My question is: is this even a valid use case? > > > > According to the WS-I Basic Profile: > > > > > > R2714 For one-way operations, an INSTANCE MUST NOT return a HTTP response > > that > > contains an envelope. Specifically, the HTTP response entity-body must be > > empty. > > > > R2750 A CONSUMER MUST ignore an envelope carried in a HTTP response > message > > in > > a one-way operation. > > > > R2727 For one-way operations, a CONSUMER MUST NOT interpret a successful > > HTTP > > response status code (i.e., 2xx) to mean the message is valid or that the > > receiver would process it. > > > > One-way operations do not produce SOAP responses. Therefore, the Profile > > prohibits sending a SOAP envelope in response to a one-way operation. > > > > > > Thus, producing a Fault as part of processing a One-Way operation would > be > > against the spec. > > > > > > Dan > > > > > > > > > > On Thursday 30 September 2010 1:32:11 pm Sergey Beryozkin wrote: > > > Hi > > > > > > I'm looking at the following issue. > > > A oneway request with a decoupled WSA FaultTo address is processed on > the > > > server side and then a fault is thrown. > > > MapCodec and MapAggregator interceptors are not handling this case at > the > > > moment. > > > > > > Eoghan clarified how ContextUtils.rebaseAddress used by MapAggregator > > > works. Particularly, a partial response is sent back asap, and then > > > an out message is prepared such that a normal response is sent to the > > > decoupled ReplyTo (during this process an out interceptor chain is > > > created). > > > > > > The question is how to forward a fault to the decoupled address in case > > of > > > oneway requests and particularly, how to build a proper chain. > > > I'm prototyping the following code in MapCodec.handleFault() : > > > > > > // MapCodec::handleFault(Message message) > > > if (oneWay and !isRequestor()) > > > { > > > Exchange exchange = message.getExchange(); > > > > > > // we need the input message so that we can get the WSA > > > properties from it > > > > > > Message inMessage = exchange.getInMessage(); > > > AddressingPropertiesImpl maps = > > > ContextUtils.retrieveMAPs(inMessage, false, false, > > > true); if (maps != null && > > > !ContextUtils.isGenericAddress(maps.getFaultTo())) { > > > > > > // boilerplate code for getting a backChannel, using > > > inMessage > > > Destination target = inMessage.getDestination(); > > > exchange.setOutMessage(message); > > > > > > Conduit backChannel = target.getBackChannel(inMessage, > > > > message, > > > > > > maps.getFaultTo()); > > > > > > // Set up the chain > > > InterceptorChain chain = > > > OutgoingChainInterceptor.getOutInterceptorChain(exchange); > > > message.setInterceptorChain(chain); > > > > > > exchange.put(ConduitSelector.class, > > > new > > > PreexistingConduitSelector(backChannel, > > > > > > exchange.get(Endpoint.class))); > > > > > > chain.doIntercept(message) > > > } > > > > > > > > > The question is basically how to set up an out chain properly to deal > > with > > > delivering a fault message in case of oneway requests. > > > > > > Some clarifications would help > > > thanks, Sergey > > > > -- > > Daniel Kulp > > [email protected] > > http://dankulp.com/blog > > >
