Any WSDL experts out there?

[JamzTheMan]

Ok, so I have a non-maptool question regarding WSDL & Java and looking to pick a brain or two?

I have a older java app that connects to a PeopleSoft listener to get data via SOAP, then connects to a Cognos server to get a pdf, then connects to another PeopleSoft listener to write data to a db.

I have our current WSDL & related XSD files which have changed slightly adding a third data type to our scheme. Since the WSDL changed, the app complains about missing @proptypes so I went down the path of regenerating the client/server using Axis + Eclipse plugin.

The class files I get though are different names like Z_COGNOS_SDK vs current ZCOGNOSSDK. It's like a different wsdl was used to generate the files. Yet the code still works with the WSDL we currently have.

I *think* Axis 1.4 was used, I currently have Axis 1.6 (but called Axis 2?) and tried generating 1.x compatible files, always run into the nameing issue. Not sure what I need to change at this point.

Does any of this make any sense to anyone else? Any hints on where to go from here?

[Azhrei]

Sorry, no can help.

I played with some WSDL stuff long ago but my brain has completely forgotten all of it.

[Jagged]

Axis is a little out of date now. Try JAX-WS. It's essentially the same process though

If it complains about duplicate parameter names while creating java objects based on WSDL, I think there is a parameter to cope with that (-extension?).

[jfrazierjr]

Ok, so I have a non-maptool question regarding WSDL & Java and looking to pick a brain or two?

....

The class files I get though are different names like Z_COGNOS_SDK vs current ZCOGNOSSDK. It's like a different wsdl was used to generate the files. Yet the code still works with the WSDL we currently have.

I *think* Axis 1.4 was used, I currently have Axis 1.6 (but called Axis 2?) and tried generating 1.x compatible files, always run into the nameing issue. Not sure what I need to change at this point.

Does any of this make any sense to anyone else? Any hints on where to go from here?

I won't cop to being an "expert", but I have 6-7 years of experience with wsdl's(I am a much bigger fan of soap than in most REST base API's that I have seen implementations for, which always leave something to be desired... they generally trade complexity of SOAP/WSDL for complexity of API object graphs were you have to know and understand the relationship between all the objects that you just done have to deal with in a properly built SOAP based WS...)

Anyway, your problem is almost certainly NOT your wsdl(assuming the wsdl you see is what was used to generate the original code). They generally contain little information(directly) about the objects and more handle the communication aspect. Your problem is either with a difference in the xsd's OR(more likely) your library(ie, Axis) version differences.

IIRC, xml tags have the exact same naming restrictions as java(and likely many other languages), so anything that is an XML element/attribute name should be just fine as java class/field. Then comes the point of how the xsd's are built and the contents. As another poster mentioned, one possibility is that your xsd's contain two(or more) elements with the same name(but perhaps in a different XML namespace) and the library needs a way to differentiate these from each other, so it renames them. Unfortunately, each library has it's own quirks about how to handle variations in xsd's. Honestly, even "compatibility" mode from different versions don't really always mean what you think it means in how it will generate the output XML.

I have a older java app that connects to a PeopleSoft listener to get data via SOAP, then connects to a Cognos server to get a pdf, then connects to another PeopleSoft listener to write data to a db.

I have our current WSDL & related XSD files which have changed slightly adding a third data type to our scheme. Since the WSDL changed, the app complains about missing @proptypes so I went down the path of regenerating the client/server using Axis + Eclipse plugin.

I am a bit confused about this part. The first sentence seems to indicate that YOU are acting a the client in all these connections(ie, calling into a remote web service), but the second one seems to indicate that you are hosting a web service. Perhaps it's just how I am reading it and the choice of words you used.

I would start with a comparison of the old xsd and the new one and preferably any sample xml files from each version if available(or can be generated). I am HUGE FAN of the free SoapUI program and use it extensively in my day job(I build integrations with third party vendors for sending Background Checks,Assessments, I9, etc requests and receiving the corresponding results for use within our product, though we utilize a middleware product that abstracts some of the complexity) I would start by creating a SoapUI project pointing to the old wsdl and then do the same for the new one and compare the xml message formats for any major changes in message structure as the first/easy step. Other than that, I can't really help with Axis specifically as I don't use it directly(but have a few times in the past, but that was a few years ago). The only other step would require me to actually get a good look at both of the wsdl's/xsd's in question....

[JamzTheMan]

Thanks for the replies! Let me absorb that and try a few things.

[Azhrei]

IIRC, xml tags have the exact same naming restrictions as java(and likely many other languages), so anything that is an XML element/attribute name should be just fine as java class/field.

Well, I know XML element names and attributes can have dashes in them and Java classes and members cannot, so there's one difference.

I don't know how Axis works, but namespaces could be taken care of by simply changing any ":" in a tag to an underscore. Obviously that doesn't resolve the reference, but as far as building class name it would be sufficient.

[JamzTheMan]

OK, so problem solved. I was barking up a wrong tree. First I tried the web services menu in eclipse to build the client, then installed the Axis plugin with same results. Turned out it was done in Java 1.5 with JAX-WS. Although I was able to use the Java 1.6 to generate the code, it was finally back to the proper class names.

Nothing like being handed code done by a long gone consultant written 5 years ago.

Thanks for the help, sometimes it just takes bouncing it off other people and making sure you're at least in the general area. Now I can get back to the important stuff, like hacking MT.

[jfrazierjr]

IIRC, xml tags have the exact same naming restrictions as java(and likely many other languages), so anything that is an XML element/attribute name should be just fine as java class/field.

Well, I know XML element names and attributes can have dashes in them and Java classes and members cannot, so there's one difference.

I don't know how Axis works, but namespaces could be taken care of by simply changing any ":" in a tag to an underscore. Obviously that doesn't resolve the reference, but as far as building class name it would be sufficient.

Oi! Your right, there are TONS of allowed characters in xml element/attribute names that are not valid as java class/field names. I should know this better, it's my job! I guess I was thinking back to some really old spec or something and since I had not encountered any xml(and I have seen literally thousands of different schemas(and my schema's I more mean distinct xml content from the others, not the formal xml xsd "schema") over the years and just have never seen anything other than AlphaNumeric|Underscore|period for name parts(not counting the namespace prefix colon thingy), so it just became a standard "in my own mind".