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 <[email protected]>: > > On Jul 10, 2014, at 2:48 PM, Jose María Zaragoza <[email protected]> > wrote: > > > 2014-07-10 15:21 GMT+02:00 Daniel Kulp <[email protected]>: > >> > >> 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 > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
