This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
There are two import functions. The first is the wsdl:import element. This element is used only to import other WSDL files. You also have the xs:import. The xs:import may only be used inside a <xs:schema> element which you can find in the wsdl:types element. The xs:import may only import files that begin with <xs:schema> (thus importing only other XSD's).
RMH means that, inside an <xs:schema> within the wsdl:types element, you cannot import schema's declared inside the wsd:types element of other WSDL files. This is only logical, since this would mean importing another WSDL file, and that is not allowed for the xs:import.
The first WSDL file defines a schema inside the wsdl:types element:
The second WSDL file needs to use an element from the schema defined in the previous WSDL file. You can do this by importing the complete WSDL file, and simply re-use the schema element in the wsdl:message for example:
I'm not 100% sure if this is BP conformant, but I cannot find anything against this in the spec...
The second possiblity would be that you externalize the schema. This way you endup having 3 files. 1 XSD file, and 2 WSDL files each refering to that same XSD.
So, the WSDL1 (and WSDL2) would look liket this:
Note that there is no targetNamespace defined in the schema defined in the wsdl:types. Since you are not defining any elements in that schema (you are just using it to import another schema which contains what you need) you are allowed to bypass the targetNamespaces (but you MAY IMHO). Follow paragraph from the BP illustrates this:
R2105 All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s). [ January 03, 2007: Message edited by: Jim Janssens ]
Joined: Jan 02, 2007
Thanks a lot.
Joined: Sep 24, 2004
Hmm, it seems that the first solution I explained seems not BP conformant and is even not allowed. Allthough my WSDL validates.
The idea is that when you import a WSDL the visibility restrains you from using schema's in that WSDL. Either schemas specifically defined in the imported WSDL, or schema's imported in the imported WSDL. Therefore if you use a schema, the schema should always be in the CURRENT WSDL, either directly or imported.
Now, what IS allowed, is to import the wsdl:message from the other WSDL (and is the portType, binding and so forth). So, if import WSDL1 in WSDL2, you cannot (may not) re-use the schema's defined or imported in that WSDL. But you MAY re-use the messages defined in that WSDL that use the schemas from that WSDL.
The second solution, having the schema in a separate XSD file, remains valid.
I've found that many SOAP layers will permit things that aren't strictly in compliance with the standard (and some will reject things that are). So using a WSDL validator to determine whether something is really valid WSDL isn't going to give more than a broad indication (if it validates it's more likely to be valid than when it doesn't) but that's as far as it goes.
The source generator from .NET 2.0 is one of the best I've tried so far. It will yield warnings in many places where Axis for example silently agrees with your invalid WSDL. Things like overloaded methods for example aren't allowed according to the spec, .NET gives a warning but generates them where Axis just goes ahead and gives you the green light.