Two Laptop Bag*
The moose likes Web Services and the fly likes  .NET WSDL client generation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark " .NET WSDL client generation" Watch " .NET WSDL client generation" New topic
Author

.NET WSDL client generation

Dean Pullen
Ranch Hand

Joined: May 30, 2003
Posts: 58
Hi all.

I�ve used Axis to generate client side stubs before, but I�ve never worked with a) a .NET service and b) a service that wasn�t our own, and I�m having a few issues understanding what I need to do. Hopefully someone can help.

I have a WSDL definition from a .NET service, below is an edited version (to allow for anonymity):



This would allegedly provide a response like so:



Where �schema� and �xml� in this line: are �placeholders�.

Now I�m expecting a lot of user data to come back in this response, and I presume that it will come within these placeholders.



But if the WSDL's correct how do I generate a client stub using Axis that represents this service (and the 'actual' response)?

If I generate a stub using this WSDL as is, I only get the ability to perform:


And not the specific getters for user name, user language etc etc that should appear in the response.

I'm clearly missing something here, your thoughts and help would be appreciated.


Dean.
[ September 18, 2007: Message edited by: Dean Pullen ]
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Dean Pullen:
And not the specific getters for user name, user language etc etc that should appear in the response.

I'm clearly missing something here, your thoughts and help would be appreciated.


You are not missing anything. The use of the "any" (or "anyType") permits any wellformed XML. So the binding compiler cannot know during compile time what exactly is going to appear in that part of the message - so it cannot generate any code to help you access that part of the message.

org.apache.axis.message.MessageElement implements:
  • org.w3c.dom.Element
  • org.w3c.dom.Node
  • org.w3c.dom.NodeList
  • javax.xml.soap.Node
  • javax.xml.soap.SOAPElement


  • Using XPath would be the easiest way to extract information. Other than that you could use DOM to navigate through the XML fragment or possibly some SAX or STAX parser code to extract what you need from any possible fragment.
    Dean Pullen
    Ranch Hand

    Joined: May 30, 2003
    Posts: 58
    Ah ok!

    Well that makes complete sense. I have no problem with manually parsing the response - in fact, if I hadn't of had an answer from anyone, I would of done exactly that (begrudgingly in case I was doing the 'wrong' thing).

    It surprises me though. I would expect a well formed response, something that was specified explicitly in the WSDL.

    Thank you very much for clearing that up for me.
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Originally posted by Dean Pullen:
    It surprises me though. I would expect a well formed response, something that was specified explicitly in the WSDL.


    I suspect that somebody was trying to bypass the issue of WSDL versioning - thereby rendering the WSDL next to useless; it's kind of an open-ended service contract (that means not a contract by any means).

    Loosely typed versus strongly typed Web services
    Tip: xsd:any: A cautionary tale

    However I forgot to mention that you have an opportunity to cut down on your manual coding.
    If you have access to all the XML schemas that may be used in the response then you can use them together with JAXB to generate (un)marshallers and the equivalent Java classes to give you your "specific getters for user name, user language etc".

    Then you simply peek into the contents of the MessageElement to determine what you are dealing with and select the correct marshaller to parse the fragment and use the converted Java object instances.

    The JAXB xjc compiler is much more configurable than most web service interface code generators so you have quite a bit of control over the type of object that is generated.
    Dean Pullen
    Ranch Hand

    Joined: May 30, 2003
    Posts: 58
    I apreciate the reply, and the URLs provided certainly boost my understanding.

    Many thanks again.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: .NET WSDL client generation