Thanks for clarification. It seems using WS-Addressing is not as simple as I hoped.
After <wsa:Action> comes my next question: How is <wsa:To> supported in CXF? I mean, in theory, I could get the request via SMTP or whatever protocol - but the endpoint in <wsa:To> could point to a HTTP endpoint. Is this <wsa:To> treated in CXF purely as an informative field - or is there real logic behind it? On Sat, Jul 12, 2014 at 12:31 AM, Iván Brencsics <[email protected]> wrote: > Hi Dan, > > Thanks for your efforts, and the good explanation. Now I understand quite > well how CXF handles the wsa:Action. I wonder what was the original > intention of wsa:Action in the WS-Addressing specification. I feel big > contradictions. The popular document/wrapped/literal kind of SOAP routes > messages based on payload that has consequences: inside a service there > cant be two operations that have the same input parameter. In the contrary, > if wsa:Action was an alternative routing approach, this would be possible, > so more operations could have the same input type. Furthermore if we would > use "wsa:Action only" based routing it would also be possible to send > multiple kinds of payloads to the same operation (of course if the > processing method would work with DOM, and not JAXB objects). So for me > this whole wsa:Action thing is very confusing. Not how it is handled in > CXF, but in general. However, the use cases you mentioned (WS-RM, > WS-SecureConversation, WS-Mex) make perfect sense. > > Ivan > > > 2014-07-11 21:19 GMT+02:00 Daniel Kulp <[email protected]>: > > > > > Just to follow up on this… > > > > I just pushed some changes that allow a more strict checking of the WSA > > Action. If an contextual property of > > "ws-addressing.strict.action.checking” is set to true, CXF will do a bit > > more validation of the Action to make sure it at least comes closer to > > matching the possible values. I don’t want to turn it on by default as > > it’s quite likely to break existing clients. Our own tests revealed a > > bunch of cases where the actions would not properly match. Kind of > makes > > me expect that this would cause lots of problems for folks out there. > > > > Anyway, this will be available in 3.0.1/2.7.12. > > > > Dan > > > > > > On Jul 11, 2014, at 9:52 AM, Daniel Kulp <[email protected]> wrote: > > > > > > > > On Jul 10, 2014, at 5:17 PM, Iván Brencsics <[email protected]> > > wrote: > > > > > >> 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. > > > > > > Correct. > > > > > > > > >> 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”) > > > > > > Same can be done with JAX-WS with the @javax.xml.ws.Action annotation > > and/or the @RequestWrapper (if using WRAPPED) or @WebParam if not. > > > > > >> 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. > > > > > > The same can be done with JAX-WS. However, in general, it’s a ton > > easier to “get right” if you use the code generator to generate the SEI > so > > that none of the actions and namespaces and such are typed in wrong. > > Things have to exactly match what the wsdl contains. > > > > > > > > >> Dont you think this has been one of the ideas of wsa:Action, to > provide > > an > > >> alternative way of SOAP message routing? > > > > > > Digging through the code, we actually DO determine the operation to > > invoke based on the Action if it’s present and something else (like the > > SOAPAction) hasn’t already determined it. However, if we cannot find an > > operation based on the Action, we then continue and try and determine it > > based on the contents of the body. If the contents of the body don’t > > agree with the operation determined by the Action, then an exception is > > thrown. However, if we cannot determine the operation based on the > Action > > and we are able to figure out an operation based on the payload, we don’t > > throw any sort of exception due to an invalid Action. > > > > > > I did just try adding an exception for this an all kinds of tests are > > failing. The main reason is that with JAX-WS, you can turn on > > WS-Addressing for any endpoint relatively easily (@Addressing annotation > or > > feature), but if the methods don’t have @Action annotations, the action > > that is generated can vary depending on how the client was created and > the > > setup of the WSDL. For example, even without the @Action, if the client > > is created with a wsdlLocation and the wsdl contains the appropriate > > wsam:Action attributes, it will use them. If they don’t contain the > > attributes, it will generate one, but the algorithm for the generated > > Action depends on if the wsdl:input contains a name attribute or not > (it’s > > optional). If the client is NOT created from a WSDL, the it will also > > generate an Action, but again, the algorithm for that may result in > > something different than what the service expects. This applies to > > publishing a service as well. Thus, you can easily get a bit > mix-matched > > between client/service depending on how they are created. > > > > > > Dan > > > > > > > > > > > > > > >> > > >> 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 > > >>> > > >>> > > > > > > -- > > > Daniel Kulp > > > [email protected] - http://dankulp.com/blog > > > Talend Community Coder - http://coders.talend.com > > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > > > >
