Archief - [WSDL] XML doorgeven via WSDL

Ik ben momenteel bezig met een projectje om een aantal web services te maken. Er moeten blokken XML uitgewisseld worden, en ik heb de instructie gekregen om, in mijn wsdl de xml blok gewoon als string type te definieren ipv een complex type.

Bij het testen van m'n webservices via soapui krijg ik dan meteen ook volgende fout(en):

org.xml.sax.SAXException: SimpleDeserializer encountered a child element, which is NOT expected, in something it was trying to deserialize.

Of als ik in mijn body de xml header toevoeg:

org.xml.sax.SAXParseException: The processing instruction target matching "[xX][mM][lL]" is not allowed.

Gewone text invoeren werkt perfect en komt schoon binnen in mijn klasse.

Moet ik eigenlijk mijn xsd linken in de wsdl? Of is een complex type de enige manier om xml uit te wisselen?

Ik heb wel de tip gekregen om een string type te gebruiken, maar nu dat ik met de problemen zit is er niemand thuis

Ik heb al redelijk wat gegoogled (en nog steeds bezig) maar vind momenteel geen concrete oplossing voor m'n probleem.

't is een Java omgeving en alles draait op IBM Websphere. Onderliggende interfaces enzo zijn gegenereerd met Axis.

Update:

Als ik test via de Eclipse web service browser lukt het en komt m'n xml binnen in mijn klasse. Als ik de source opvraag van het iframe dat Eclipse gebruikt, dan zie ik dat em mijn XML < & > vertaalt naar &lt; & &gt;.

Als ik mijn xml in SoapUI doorgeef met &lt; en &gt; codes dan werkt het daar ook en komt het proper binnen in mijn klasse.

Voor m'n baas is het probleem opgelost maar ik voel me er nie goe bij ... ik vind het echt geen cleane manier van werken.

Maar ze willen persé een string type om xml door te geven. Zodat we compatibel blijven met onze klanten als we in de xml bijvoorbeeld extra velden zetten. Met een complextype zou je de velden moeten beschrijven van je xml, en heb je een probleem als er eentje extra binnekomt ...

Probleem voorlopig opgelost ... input hieromtrent is natuurlijk nog steeds welkom

Catscratch zei:

Update:
Maar ze willen persé een string type om xml door te geven. Zodat we compatibel blijven met onze klanten als we in de xml bijvoorbeeld extra velden zetten. Met een complextype zou je de velden moeten beschrijven van je xml, en heb je een probleem als er eentje extra binnekomt ...

Klik om te vergroten...

Ik ga van het volgende uit:
- Jij (of je firma) biedt de webservice aan
- Je klanten hebben client programmas errond draaien.
Als ik hier al verkeer zit, skipt de rest van mijn post dan maar.

Uw xml doorsturen als type string heeft geen enkel nut.
De xml die je aanlevert (als 'string') zal namelijk ook volgens een vaste structuur zijn. Je klanten zullen ook van deze structuur vanuit gaan om hun programmas te maken. Als jij dan achteraf velden toevoegd, dan is dit net hetzelfde probleem dat je hebt als je de xml rechtstreeks in de webservice had gedefinieerd.

Wat wij hier doen is onze structuur zo volledig mogelijk beschrijven binnen de wsdl. Maar al onze datatypes hebben een xsd:any element.
Je kan dan achteraf velden toevoegen zonder dat men client programmas moet aanpassen die deze data niet gebruiken.

Ice zei:

Ik ga van het volgende uit:
- Jij (of je firma) biedt de webservice aan
- Je klanten hebben client programmas errond draaien.
Als ik hier al verkeer zit, skipt de rest van mijn post dan maar.

Klik om te vergroten...

Correct!

Ice zei:

Uw xml doorsturen als type string heeft geen enkel nut.
De xml die je aanlevert (als 'string') zal namelijk ook volgens een vaste structuur zijn. Je klanten zullen ook van deze structuur vanuit gaan om hun programmas te maken. Als jij dan achteraf velden toevoegd, dan is dit net hetzelfde probleem dat je hebt als je de xml rechtstreeks in de webservice had gedefinieerd.

Klik om te vergroten...

Hangt er eigenlijk een beetje vanaf hoe de klanten hun parser hebben geschreven imho, maar je hebt wel gelijk. Die kans zit er dik in.

Ice zei:

Wat wij hier doen is onze structuur zo volledig mogelijk beschrijven binnen de wsdl. Maar al onze datatypes hebben een xsd:any element.
Je kan dan achteraf velden toevoegen zonder dat men client programmas moet aanpassen die deze data niet gebruiken.

Klik om te vergroten...

Hoe bedoel je concreet? Een complextype met een onberkt aantal herhalingen van een veld type xsd:any element?

Alleszins al bedankt voor de input

Catscratch zei:

Hoe bedoel je concreet? Een complextype met een onberkt aantal herhalingen van een veld type xsd:any element?

Klik om te vergroten...

Best dit even lezen dan zal het wel duidelijk worden http://www.xfront.com/ExtensibleContentModels.html

Ice zei:

Best dit even lezen dan zal het wel duidelijk worden http://www.xfront.com/ExtensibleContentModels.html

Klik om te vergroten...

Ik begrijp het. ^^

Baas is hier juist toegekomen ... ik heb em het probleem uitgelegd. Hij wil eerst de String behouden, en zien hoe het gaat met onze 2 eerste klanten. Indien er geen problemen zijn blijven we de String gebruiken. Indien er wel problemen zijn, gaan wij ons flexibel opstellen en moet ik een andere oplossing verzinnen.

En die oplossing heb ik bij deze dus gevonden, thanks!

Geen probleem!