WSDL and XSD issues for JAVA developers

Java development

A number of JAVA developers have issues consuming our WSDL’s and XSD’s. First of all our WSDL’s are automatically generated by .NET and therefore there can be some issue. Our XSD’s are made by hand.

WSDL

If we take for sampe the extendedclientlogic.wsdl. You can encounter errors like this:

  [WARNING] src-resolve.4.2: Error resolving component ‘xs:schema’. It was detected that ‘xs:schema’ is in namespace ‘http://www.w3.org/2001/XMLSchema’, but components from this namespace are not referenceable from schema document ‘http://XXXXXXXX/EUCARIS.Internal/ExtendedClientLogicService.svc?xsd=xsd13’. If this is the incorrect namespace, perhaps the prefix of ‘xs:schema’ needs to be changed. If this is the correct namespace, then an appropriate ‘import’ tag should be added to ‘http://XXXXXXXX/EUCARIS.Internal/ExtendedClientLogicService.svc?xsd=xsd13’.

    line 1 of http://XXXXXXXX/EUCARIS.Internal/ExtendedClientLogicService.svc?xsd=xsd13

  [WARNING] src-resolve.4.2: Error resolving component ‘xs:schema’. It was detected that ‘xs:schema’ is in namespace ‘http://www.w3.org/2001/XMLSchema’, but components from this namespace are not referenceable from schema document ‘http://XXXXXXXX/EUCARIS.Internal/ExtendedClientLogicService.svc?xsd=xsd0’. If this is the incorrect namespace, perhaps the prefix of ‘xs:schema’ needs to be changed. If this is the correct namespace, then an appropriate ‘import’ tag should be added to ‘http://XXXXXXXX/EUCARIS.Internal/ExtendedClientLogicService.svc?xsd=xsd0’.

    line 1 of http://XXXXXXXX/EUCARIS.Internal/ExtendedClientLogicService.svc?xsd=xsd0

  [ERROR] undefined element declaration ‘xs:schema’

    line 1 of http://XXXXXXXX/EUCARIS.Internal/ExtendedClientLogicService.svc?xsd=xsd0

The first 2 problems can be solved by adding the namespace: (xs:import).
The (xs:schema) entries are ignored when generating .NET code, but for JAVA they need to be removed.

JAVA also has problems consuming a .NET Dataset.
See also:
https://www.hanselman.com/blog/returning-datasets-from-webservices-is-the-spawn-of-satan-and-represents-all-that-is-truly-evil-in-the-world
Removing the (xs:schema) entry solves the issue.

Furthermore. The .Net WSDL can generate multiple entries with the same name. E.g.:

<xs:complexType name=”StatisticsResponse”>
            <xs:sequence>
                    <xs:element minOccurs=”0″ name=”Data” nillable=”true”  type=”tns:ArrayOfStatisticsResponseData” />
                    <xs:element minOccurs=”0″ name=”NrOfMessages” type=”xs:int” />
                    <xs:element minOccurs=”0″ name=”SenderCountry” nillable=”true” type=”xs:string” />
                    <xs:element minOccurs=”0″ name=”ServiceName” nillable=”true” type=”xs:string” />
                    <xs:element minOccurs=”0″ name=”StatisticsDate” type=”xs:dateTime” />
            </xs:sequence>
</xs:complexType>

<xs:element name=”StatisticsResponse” nillable=”true” type=”tns:StatisticsResponse” />

This can be resolved by forcing the code generation tool to use another name for the generated Java classes.
But by default both classes would have had the name “StatisticResponse” and would therefore fail.
See also:
https://stackoverflow.com/questions/23514814/named-the-selement-and-scomplextype-the-same-name

XSD

Unfortunately the XSD’s don’t use namespacing and we use (xs:any) which can be a problem for JAVA developers.
The XSD’s can be adjusted when needed. E.g. Austria (JAVA) have their own version of the envelope.xsd

General

For JAVA developers a number of adjustments are needed when consuming the EUCARIS WSDL’s and XSD’s. If you encounter any problems, please contact EUCARIS Operations. We have at least 2 countries using JAVA (Luxembourg and Austria). And if needed we can bring you into contact with each other. Also Austria can provide some Eclips samples on e.g. ExtendedClientLogic.wsdl.

In the future we would like to rebuild the WSDL’s (contract first) to make then compatible with Microsoft and JAVA. Also the future XSD’s might be made more JAVA proof.