cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Iván Brencsics <ivan.brencs...@gmail.com>
Subject Re: WS-Addressing example from CXF 3.0.0
Date Thu, 10 Jul 2014 21:17:24 GMT
Hi Daniel,

Please correct me if I am wrong, but one task of a web service stack is to
route incoming SOAP requests to the right processing Java method. When
using document style SOAP services, the basic solution is to do this
routing based on the type of the message in the SOAP body. This is the
concept of JAXWS too. After working with Spring WS I understood that the
same routing can be done based on the wsa:Action value. In Spring WS a
method can be annotated one of the following ways:
1) @PayloadRoot(localPart = "orderRequest", namespace = "http://samples")
or
2) @Action("http://samples/CreateOrder")

So in case of 1) if there is an incoming SOAP request where the body has
the specified fully qualified name, the request is processed in this
method. In 2) if there is an incoming SOAP request with this wsa:Action, it
is routed to this method. For me this model makes more sense then the JAXWS
approach, where we generate a SEI, implement it, and route the SOAP
requests based on the SOAP body. In my opinion this is a very nice feature
of Spring WS.

Dont you think this has been one of the ideas of wsa:Action, to provide an
alternative way of SOAP message routing?

Regards,
Ivan





2014-07-10 21:12 GMT+02:00 Daniel Kulp <dkulp@apache.org>:

>
> On Jul 10, 2014, at 2:48 PM, Jose María Zaragoza <demablogia@gmail.com>
> wrote:
>
> > 2014-07-10 15:21 GMT+02:00 Daniel Kulp <dkulp@apache.org>:
> >>
> >> In general, CXF routes requests based on the target URI/address, not
> the Action, although there are some exceptions to that….
> >>
> >> In general, CXF only allows a single endpoint to be deployed on a
> specific address.   Through the MultipleEndpointObserver stuff, it’s
> possible to do it, but it’s not exactly easy.
> >>
> >> So… where is the Action used?   Under normal circumstances, the Action
> will be looked at by various interceptors on the chain that may be looking
> for a specific Action.   For example, if WS-RM is configured, the RM
> interceptors will be looking for Actions that pertain to RM
> (CreateSequence, etc…) at which point they will re-route the request into
> the RM stuff.   WS-SecureConversation is another example.  It’s interceptor
> will look for Actions related to issue/renew/cancel tokens.   WS-Mex is
> another.      Basically, if it gets through the chain without something
> “intercepting” the request, the request just goes to the normal endpoint
> like a normal request and is handled via the contents of the soap body.
> We likely SHOULD have a check in there to make sure the Action matches like
> we do check to make sure the SOAPAction header (if specified) matches.
> >
> >
> > Thanks Daniel. Good explanation
> > What kind of checking is applied to SOAPAction ?  SOAPAction == URI
> requested ?
>
> If there is a non-empty SOAPAction header, we do double check that the
> action that is specified matches the action that is configured for the
> target operation that is determined from the contents of the soap:Body.
> There’s a series of spoofing attacks that this prevents by making sure the
> entire processing of the message is consistently targeting the correct
> operation.
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

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