Mike, this is overkill. We think that the second binding element (the one in the tns3 namespace, which is really the soap namespace) is required (we see lots of examples of this for web services on www.xmethods.net) and we are even more sure that we must have the second binding element. 

Are you able to get any more information about why the wsdl does not validate? I suspect that it might be to do with the xsi:type elements. Could you try just taking out those elements? If that is the problem we could do a quick fix where we suppress them. In fact we do not want SDO to generate them at all, and it would be useful for us to know that they cause validation errors for you. After a quick fix, I could raise a defect report on the SDO code.

I just realised that when I said 'the second binding element (the one in the tns3 namespace...' I meant the second _operation_ element (i.e. the one with the soapAction). Sorry about that.

Can you say why the wsdl does not validate? Is it the xsi:type  attributes?

I just raised a defect report against the underlying C++ code that is in the sdo extension. 

https://issues.apache.org/jira/browse/TUSCANY-1297

Sorry for not being more responsive to this ticket.  The issue I'm reporting here is not the xsi:type attibute, although that is an issue that I reported in #11012.

What I'm seeing is that the element <tns3:operation> is not a valid child of <operation>.  Also, <tns3:binding> is not a valid child of <binding>.  

I validated my WSDL using both oXygen and SOAPScope, and both complained about those elements.  

I and also spent some time trying to understand the WSDL XML schema, and I don't see how these elements could be validly placed were they are in the binding section.  But, I certainly don't feel confident with my understanding of these XML grammars and there is a good chance my alalysis is wrong.  Even so, I don't understand why the to above mentioned products both fail my generated WSDL because of these elements.

http://issues.apache.org/jira/browse/TUSCANY-1297

I just tried loading some SCA-generated WSDL using XERXES and got some useful messages:

Error: URI=file:///C:/Documents%20and%20Settings/Administrator/workspace/XML/Greeting.wsdl Line=48: cvc-complex-type.2.4.a: Invalid content was found starting with element 'tns3:operation'. One of '{"http://schemas.xmlsoap.org/wsdl/":fault}' is expected.
Error: URI=file:///C:/Documents%20and%20Settings/Administrator/workspace/XML/Greeting.wsdl Line=50: cvc-complex-type.2.4.a: Invalid content was found starting with element 'tns3:binding'. One of '{"http://schemas.xmlsoap.org/wsdl/":operation}' is expected.


It dawned on me that this is to do with the order of the elements in the WSDL. Because tOperation and so on inherit from tExtensibleDocumented, it is allowable for them to have elements from other namespaces e.g. from the soap namespace as we do, but the order is wrong. We are generating: 
  <binding name="GreetingBinding" type="tns2:GreetingPortType">
    <operation name="greet">
      <input>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>

      </input>
      <output>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </output>
      <tns3:operation xsi:type="tns3:tOperation" soapAction=""/>
    </operation>
    <tns3:binding xsi:type="tns3:tBinding" transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
  </binding>

which fails. The XML passes though if the elements from the soap namespace come first:
  <binding name="GreetingBinding" type="tns2:GreetingPortType">
    <tns3:binding xsi:type="tns3:tBinding" transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
    <operation name="greet">
      <tns3:operation xsi:type="tns3:tOperation" soapAction=""/>
      <input>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>

      </input>
      <output>
        <tns3:body xsi:type="tns3:tBody" use="literal"/>
      </output>
    </operation>
  </binding>

OK, that's the source of the problem. Now how we are going to fix it I don't know, as this is the order in which it comes out from SDO. Pass to Tuscany I suppose.

I just added this new information to Tuscany JIRA 1297

I believe the order of the elements is now different and this is fixed in 1.2.2, so I am closing. Please feel free to reopen if you find the problem is still there.