cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Interceptor chains, one way requests, WSA FaultTo
Date Fri, 01 Oct 2010 11:42:55 GMT
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 <oliver.wulff@sopera.com>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 [sberyozkin@gmail.com]
> Gesendet: Freitag, 1. Oktober 2010 00:19
> An: Daniel Kulp
> Cc: dev@cxf.apache.org
> 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 <dkulp@apache.org> 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
> > dkulp@apache.org
> > http://dankulp.com/blog
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message