Giter VIP home page Giter VIP logo

Comments (7)

droyo avatar droyo commented on July 29, 2024

I admit I haven't even manually tested this part of the generated code very thoroughly. Would you happen to have a WSDL endpoint in mind that we can use as an example?

from go-xml.

leth avatar leth commented on July 29, 2024

I'm new to the world of WSDL, so don't have any examples to test against.
It's fairly striaghtforward to catch: if you marshal and serialise a request struct to bytes, then try to deserialise and marshal it back to structs then it will just be empty.

IIUC it's because the Envelope Body is an interface{}; go can marshal it since it has a instance to reflect on, but it can't unmarshal it because it's not sure what type they should be.

from go-xml.

droyo avatar droyo commented on July 29, 2024

Ah, it looks like the tests I have in wsdlgen/examples/* only test marshalling.

I think the gentests/_testgen can be easily extended to generate tests for wsdlgen if there is a *.wsdl file, and mock responses if there is a *.sample file in the relevant directory, with some inspiration from the links you gave me in #25.

from go-xml.

droyo avatar droyo commented on July 29, 2024

Ok, I 've got some rudimentary tests pushed in the issue-25 branch and I think I might see the problem. It looks like I may have added an unnecessary layer of encapsulation in the temporary types used to marshal/unmarshal requests and responses. Example:

WSDL:

<message name="GetLastTradePriceOutput">
    <part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
    <operation name="GetLastTradePrice">
       <input message="tns:GetLastTradePriceInput"/>
       <output message="tns:GetLastTradePriceOutput"/>
    </operation>
</portType>

Go:

var output struct {
	XMLName struct{} `xml:"http://example.com/stockquote.wsdl GetLastTradePrice"`
	Args    struct {
		Body TradePrice `xml:"http://example.com/stockquote.wsdl body"`
	} `xml:"http://example.com/stockquote.wsdl GetLastTradePriceOutput"`
}

I'll need to check the soap spec again to see what the correct behavior is here.

from go-xml.

droyo avatar droyo commented on July 29, 2024

Ok, the relevant portion of the WSDL spec is https://www.w3.org/TR/2001/NOTE-wsdl-20010315#_porttypes and it does seem like I have a few too many layers here.

from go-xml.

droyo avatar droyo commented on July 29, 2024

OK, reading the specs a bit more I'm beginning to understand.

https://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap:operation

The value of this attribute also affects the way in which the Body of the SOAP message is constructed [...] If the attribute is not specified, it defaults to the value specified in the soap:binding element. If the soap:binding element does not specify a style, it is assumed to be "document".

https://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap:body

If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). [...]
If the operation style is document there are no additional wrappers, and the message parts appear directly under the SOAP Body element.

Relevant portions of the SOAP spec:

rpc style: https://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383533
doc style: https://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383503

So next steps would be:

  • extend wsdl package to parse the soap:binding element (it was ignored prior)
  • extend wsdl package to classify operations as "One-way", "Request-response", "Solicit-response", or "Notification".
  • when using rpc style for an operation or binding, parameters should be members of a wrapper struct.
    • If the relevant part for the parameter is not named, its name is that of the operation, plus ""/"Request"/"Response"/"Solicit", depending on the type of operation.
  • when using document style for an operation or binding, parameters are dropped right into the soap envelope's Body element.

I opened #76 for the related goal of generating error types for soap faults.

from go-xml.

leth avatar leth commented on July 29, 2024

Thanks for looking into this in such detail! In the interim I've switched to xsdgen, and manually built the soap envelope handling for my service.

I'm working with an operation which binds input and output to the SOAP body:

      <wsdl:input>
        <soap:body use="literal" />
      </wsdl:input>
      <wsdl:output>
        <soap:body use="literal" />
      </wsdl:output>

from go-xml.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.