ODE
  1. ODE
  2. ODE-212

problem with ws-addressing/headers

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: 1.1.1
    • Component/s: BPEL Runtime
    • Labels:
      None
    • Environment:
      windows xp/tomcat5.5

      Description

      I get the following response from a web service call generated by a BPEL process.....................

      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.
      w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:wsa="http://www.w3.org/2005/08/addressing"><soapenv:Header><wsa:
      FaultDetail xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:
      ProblemHeaderQName>wsa:Action</wsa:ProblemHeaderQName></wsa:FaultDetail><wsa:
      To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To><wsa:Action>http:
      //www.w3.org/2005/08/addressing/fault</wsa:Action><wsa:MessageID>uuid:
      776FBB32-0116-4000-E000-709CAC1E5121</wsa:MessageID><wsa:RelatesTo>uuid:
      hqejbhcnphr2rvi363aw4a</wsa:RelatesTo></soapenv:Header><soapenv:Body><soapenv:
      Fault><faultcode>wsa:MessageAddressingHeaderRequired</fault
      code><faultstring><![CDATA[A required header representing a Message Addressing
      Property is not present]]></faultstring></soapenv:Fault></soapenv:Body></soapenv:Envelope>

      The Web service request header looks like this............

      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
      <soapenv:Header><addr:To xmlns:addr="http://www.w3.org/2005/08/addressing">http://testws.state.de.us:1101/dti/USPSAddressService</addr:To>
      <addr:Action xmlns:addr="http://www.w3.org/2005/08/addressing"></addr:Action>
      <addr:ReplyTo xmlns:addr="http://www.w3.org/2005/08/addressing">
      <addr:Address>http://www.w3.org/2005/08/addressing/anonymous</addr:Address>
      </addr:ReplyTo>
      <addr:MessageID xmlns:addr="http://www.w3.org/2005/08/addressing">uuid:hqejbhcnphr2rvi363aw4a</addr:
      MessageID></soapenv:Header><soapenv:Body><axis2ns2:verifyAddress xmlns:
      axis2ns2="http://us.de.state.usps" xmlns:ns="http://us.de.state.usps">

        Activity

        Hide
        Matthieu Riou added a comment -

        Couple questions:

        Thanks!

        Show
        Matthieu Riou added a comment - Couple questions: Which version of ODE are you using? If you're on 1.1 you'll want to check out the SVN 1.1 branch as we've been fixing a few bugs there related to WS-Addressing headers ( http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.1/ ). What type of implementation the web service you're invoking uses? Thanks!
        Hide
        James Roe added a comment -

        First question - I'm using 1.1, so I'll look at the reference you gave
        me.

        Second question - not entirely sure what you're asking. The web service
        is deployed on an IBM Websphere 6.1 server.

        If I take the generated soap request and remove the <addr: addressing
        headers altogether, the call would work.
        Also if I include something between the <addr:Action> tags the call will
        work - it doesn't seem to like those empty tags.
        Thank you,
        James.

        Show
        James Roe added a comment - First question - I'm using 1.1, so I'll look at the reference you gave me. Second question - not entirely sure what you're asking. The web service is deployed on an IBM Websphere 6.1 server. If I take the generated soap request and remove the <addr: addressing headers altogether, the call would work. Also if I include something between the <addr:Action> tags the call will work - it doesn't seem to like those empty tags. Thank you, James.
        Hide
        Matthieu Riou added a comment -

        Can you check whether your WSDL document has a non-empty soap action defined in its operation bindings, like:

        <soap:operation soapAction="some url here"/>

        Following the ws-addressing spec, the addr:Action header is required to be present and empty if an empty soap action is declared in the WSDL. If there's a non-empty action then the addr:Action should reflect that value.

        So if you have an explicit action defined, this could be a bug in ODE. If your soapAction is empty or non-defined then Websphere is not ws-addressing compliant

        Show
        Matthieu Riou added a comment - Can you check whether your WSDL document has a non-empty soap action defined in its operation bindings, like: <soap:operation soapAction="some url here"/> Following the ws-addressing spec, the addr:Action header is required to be present and empty if an empty soap action is declared in the WSDL. If there's a non-empty action then the addr:Action should reflect that value. So if you have an explicit action defined, this could be a bug in ODE. If your soapAction is empty or non-defined then Websphere is not ws-addressing compliant
        Hide
        James Roe added a comment -

        I have no explicit action....
        <wsdlsoap:operation soapAction="" />
        Therefore, based on what you said, the problem may lie with WebSphere.
        This seems strange - I have not encountered any other interoperability
        problems with that particular service. No other client generator tool
        that I've tried has even attempted to generate the ws addressing
        headers.
        Thank you,
        James.

        Show
        James Roe added a comment - I have no explicit action.... <wsdlsoap:operation soapAction="" /> Therefore, based on what you said, the problem may lie with WebSphere. This seems strange - I have not encountered any other interoperability problems with that particular service. No other client generator tool that I've tried has even attempted to generate the ws addressing headers. Thank you, James.
        Hide
        Matthieu Riou added a comment -

        Actually one last question: do you have wsa:Action attributes on your input/output/fault operation binding elements?

        Show
        Matthieu Riou added a comment - Actually one last question: do you have wsa:Action attributes on your input/output/fault operation binding elements?
        Hide
        James Roe added a comment -

        No, I don't.
        James.

        Show
        James Roe added a comment - No, I don't. James.
        Hide
        Matthieu Riou added a comment -

        Okay so that's definitely a Websphere problem. As a workaround you could try to specify a value for the soapAction in your WSDL. Although I don't know which value would make websphere happy and if it uses the soapAction at all. You could also use an Axis2 web service that you would deploy in Websphere, you'd have far more interoperability issues.

        Show
        Matthieu Riou added a comment - Okay so that's definitely a Websphere problem. As a workaround you could try to specify a value for the soapAction in your WSDL. Although I don't know which value would make websphere happy and if it uses the soapAction at all. You could also use an Axis2 web service that you would deploy in Websphere, you'd have far more interoperability issues.
        Hide
        James Roe added a comment -

        I did as you suggested, and included SOAP actions for every operation in
        my WSDL. This seemed to resolve the problem at the WebSphere end.
        The problem seems to be occur with Websphere Server 6.1, but not 6.0.
        Thank you,
        James.

        Show
        James Roe added a comment - I did as you suggested, and included SOAP actions for every operation in my WSDL. This seemed to resolve the problem at the WebSphere end. The problem seems to be occur with Websphere Server 6.1, but not 6.0. Thank you, James.

          People

          • Assignee:
            Matthieu Riou
            Reporter:
            James Roe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development