Automatically extract embedded XSD from WSDL to XSD file (s)

Question

I am using a third-party web service whose definition and implementation are uncontrollable. This web service will change in the future.

The web service should be used to generate an XML file that contains some of the same data (represented by the same XSD types) as the web service, plus the additional information generated by the program.

My approach:

• create my own XSD, referencing the XSD WSDL definitions of the called web service (this XSD also includes XSD types for more information.)
• use the Java XML data binding framework (e.g. ADB or JiXB) to generate the data binding classes from my own XSD file from step 1
• use a Java SOAP structure (e.g. Axis2 or CXF) with the same data binding structure to generate data binding classes from WSDL (this would allow me to use the objects obtained by the web service directly in XML generation.)

The XSD types that I intend to use in my own XSD file but are defined in WSDL can be changed. Whenever they change, I would like to automatically handle the XSD and WSDL data binding. (If the change is significant enough, this may trigger some development effort. (But usually it’s not.))

My problem:

In step 1, I need an XSD of the same types used by the web service.

WSDL refers to another WSDL, which refers to another WSDL, etc. In the end there is a WSDL with the necessary built-in XSD types. As far as I know, there is no way to directly refer to the built-in XSD WSDL types from XSD.

The approach that I consider to be the most viable should include an additional step in automatic processing (before data binding), which extracts the embedded XSD from the WSDL to another XSD file. These other XSD files can be attributed to my own XSD file.

Things I would like to avoid:

• Manually copy the embedded XSD insert into the XSD file (I'm looking for an automatic process.)
• Any steps in manual mode. (Like the definition of a WSDL containing built-in types manually (the location of this WSDL also changes.))
• Using xsd: any in my own XSD. I would like my own XSD file to be correct.
• Using technology other than Java (e.g. .NET)
• Huge amounts of implementation (but hints on how you could implement such an extraction are welcome anyway)

PS: I found several similar questions, but they all had answers such as: WTH would you like to do this? This is the reason for my rather large story.

Answer 1

I do not know any libraries that will do this for you, but with certain features it can be implemented with minimal effort (~ 200 lines). A rough metaprogram for generating all the built-in and included XSD:

method processWSDL(Document wsdl) { for each ("/wsdl:definitions/wsdl:types/xsd:schema" in wsdl) { call processXSD("inline_[i].xsd",".") } for each ("/wsdl:definitions/wsdl:import" in wsdl) { Document x = read and parse ("@location") if (x is WSDL) call processWSDL(x) else if (x is XSD) call processXSD("@location", x) } } method processXSD(String filename, Document xsd) { write "xsd" to a new file "filename" // if 'filename' is a URL, take only the part after the last '/' for each ("/xsd:schema/xsd:import" or "/xsd:schema/xsd:include" in xsd) { if ("@schemaLocation" is local reference) { // no 'http://' prefix Document x = read and parse ("@schemaLocation") call processXSD("@schemaLocation", x) } } } 

This is not a complete solution, for example. does not handle namespace prefixes defined outside the inline schema, but hopefully provides a good starting point.

Answer 2

To save this post, everything has changed since the moment the answer was accepted. Now in Java you can create what you want, starting with WSDL; JAX-WS provides a wsimport tool that does exactly what you need: take WSDL, create a client proxy along with a bunch of JAXB annotated classes to un / sort requests.

I would say that @MoizTankiwala indicates that the need to export XSD content from WSDL (or include all external XSD content inside the WSDL type section) is lively and tedious.

The first is that it makes sense when someone has a large amount of XSD, and there is a common problem regarding the effective management, analysis and development of this model in XSD.

The latter is also used because some (mostly) dynamic languages ​​still do not have full tool support when it comes to WSDL for client-side proxy generation.

My other answer to SO speaks of a similar need, which should help at least with the request of Moise ...