Hoe xml te gebruiken in webservices

[Dennis]

Hallo,

In het bedrijf waar ik werk ben ik bezig met het herinrichten van een aantal bedrijfsprocessen die ICT gerelateerd zijn. Het gaat vooral om gegevensuitwisseling tussen ons informatiesysteem en een aantal andere systemen, zoals dat van onze klanten.

Stap 1 waar ik nu mee aan de slag ga is het creëren van een aantal services die op ons informatiesysteem aansluiten (SOA). Dan moet je dus denken aan een service om klanten op te vragen, met een bepaald filter. Deze service, en de andere, wordt beschikbaar gesteld als webservice zodat al onze andere applicaties er gemakkelijk mee kunnen communiceren. Maar nu heb ik een architectuur-vraag.

Ik ben bekend met het maken van webservices met c# (.net). Dat is niet zo moeilijk, men maakt een methode en je zet er [webservice] boven . Bij die methode kun je gewone programmeerdingen gebruiken zoals parameters. Ik wil echter xml meegeven als parameter, maar vraag me af of dat echt een parameter is of dat je dat op een andere manier moet oplossen.

De bedoeling is dus dat je aan een webservice bijvoorbeeld het volgende wilt meegeven:

code:

<zoekklant>
  <klantcode></klantcode>
  <klantnaam></klantnaam>
</zoekklant>

Ik wil ook weer pure xml terugsturen. De vraag is of ik dat moet opnemen als parameter (uitgaande van .net) of dat je het ergens in de WSDL moet stoppen. En hoe wordt dat nou verzonden? Zoals je ziet ben ik technisch niet helemaal bekend met webservices en heb ik eigenlijk alleen maar ervaring met een simpel voorbeeld in c#.

Wie kan mij uitleggen hoe dit technisch in elkaar steekt? Zoeken op 'webservices xml' levert niet echt duidelijke pagina's op ( ). Alvast bedankt.

[Gonadan]

Google
w3schools

Volgens mij is daar wel een boel te vinden

[bvp]

Dit kun je dus gewoon opnemen in je wsdl.

Bijv.

XML:

<xsd:simpleType name="Klantcode">
<xsd:annotation>
<xsd:documentation>De klantcode(tussen 5 en 10 characters lengte).</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]"/>
<xsd:minLength value="5"/>
<xsd:maxLength value="10"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="Klantnaam">
<xsd:annotation>
<xsd:documentation>De klantcode(tussen 5 en 32 characters lengte).</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9]"/>
<xsd:minLength value="5"/>
<xsd:maxLength value="32"/>
</xsd:restriction>
</xsd:simpleType>

<wsdl:message name="vraagKlantOpRequest">
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Vraag een bepaalde klant op.</wsdl:documentation>
<wsdl:part name="transactionId" type="xsd:string"/>
<wsdl:part name="klantcode" type="tns:Klantcode"/>
<wsdl:part name="klantnaam" type="tns:Klantnaam"/>
</wsdl:message>

In java heb je hier vervolgens een build.xml voor WSDL2Java die hieruit dan de Java-interface genereert in een jar.
Deze kun je dan weer gebruiken in je webservice.

bijv.

Java:

public KlantGegevens vraagKlantOp (String trxId, Klantcode klant, Klantnaam naam);

Zo heb ik je een beetje op weg geholpen.....

Voor meer info over wsdl:
wsdl

[Dennis]

Dankjewel voor je antwoord bvp . Dit is inderdaad erg duidelijk. Ik was aan het kijken naar de output die een webservice vervolgens weer geeft. Ook daar ga ik weer xml gebruiken, maar ik vermoed dat ik die output gemakkelijker kan analyseren.

[bvp]

Dennis schreef op maandag 20 maart 2006 @ 10:21:
Dankjewel voor je antwoord bvp . Dit is inderdaad erg duidelijk. Ik was aan het kijken naar de output die een webservice vervolgens weer geeft. Ook daar ga ik weer xml gebruiken, maar ik vermoed dat ik die output gemakkelijker kan analyseren.

Gaat dus eigenlijk gewoon op dezelfde manier he, je definieert in je WSDL bijv. vraagKlantOpResponse en wat hij daarbij terug moet geven.

Deze geef je in je methode dus weer terug als argument

[Dennis]

Inderdaad, alleen zie ik een voorbeeld waarbij Plain Text wordt teruggestuurd, gewoon als een normale html pagina. Dat lijkt mij niet de bedoeling van webservices (toch?). Ik neem aan dat de volledige http response van een échte webservice xml bevat (SOAP reponse), waarbij ik dus voor het resultaat ook weer xml kan gebruiken.

Overigens, nu ik op internet wat voorbeelden van SOAP envelopes heb gevonden wordt het meteen een stuk duidelijker, ik denk dat dat ook een beetje is wat ik zocht.

[bvp]

Ben je natuurlijk helemaal vrij in wat je terugstuurt.

Op het voorbeeld dat ik jou hierboven verder gaf kun je dus echt restrictions meegeven.
Dit wordt dus een blauwdruk van jouw interface.
Hiermee zeg je dus tegen andere systemen die jouw interface aan willen roepen: Aan deze voorwaarden moet jouw request voldoen (lengte, character-set etc.) en de response die je terugkrijgt is van dit en dit formaat.
Een mooie manier dus om éénduidingheid en duidelijkheid te verschaffen.

[Dennis]

Dat is ook heel belangrijk waarvoor ik het ga gebruiken! Wij gaan in-huis deze (web)services ontwikkelen en de tools die met deze services moeten gaan werken worden hoogstwaarschijnlijk door externe partijen ontwikkeld. Die moeten natuurlijk duidelijkheid hebben waar het systeem aan moet voldoen. Bovendien is het iets wat achteraf eigenlijk niet gewijzigd mag (en kan) worden.

[djc]

Heb je een duidelijke reden waarom je voor WS-* gaat in plaats van REST-style?

Zie onder andere:
http://www.tbray.org/ongoing/When/200x/2006/03/16/WS-Gartner
http://lesscode.org/2006/03/19/high-low-rest/
http://lesscode.org/2006/03/19/high-rest/
http://lesscode.org/2006/03/19/rest-wins-noone-goes-home/

[Dennis]

Manuzhai schreef op maandag 20 maart 2006 @ 15:03:
Heb je een duidelijke reden waarom je voor WS-* gaat in plaats van REST-style?

Zie onder andere:
http://www.tbray.org/ongoing/When/200x/2006/03/16/WS-Gartner
http://lesscode.org/2006/03/19/high-low-rest/
http://lesscode.org/2006/03/19/high-rest/
http://lesscode.org/2006/03/19/rest-wins-noone-goes-home/

Ehm, waar heb je het over?

Als je vraag is waarom ik webservices gebruik... nou, ten eerste is dat de duidelijke definering van services, ten tweede is dat de interoperabiliteit en ten derde vanwege het feit dat wij verschillende applicaties gebruiken en data aanbieden aan derde partijen (en omgekeerd). Daarom dus.

[Croga]

Manuzhai schreef op maandag 20 maart 2006 @ 15:03:
Heb je een duidelijke reden waarom je voor WS-* gaat in plaats van REST-style?

Zie onder andere:
http://www.tbray.org/ongoing/When/200x/2006/03/16/WS-Gartner
http://lesscode.org/2006/03/19/high-low-rest/
http://lesscode.org/2006/03/19/high-rest/
http://lesscode.org/2006/03/19/rest-wins-noone-goes-home/

Leuke verhaaltjes, maar nergens wordt het verschil tussen WS-* (wat een verzonnen term uit één van de stukjes is. De rest van de wereld noemt het gewoon WebServices) en RESTian (geen REST-style) nou eigenlijk is.

Ofwel: Vertel ons wat RESTian is en waarom het beter zou zijn dan WebServices maar dump alsjeblieft niet gewoon 4 linkjes met vage opinie.

[djc]

Croga schreef op maandag 20 maart 2006 @ 19:44:
Leuke verhaaltjes, maar nergens wordt het verschil tussen WS-* (wat een verzonnen term uit één van de stukjes is. De rest van de wereld noemt het gewoon WebServices) en RESTian (geen REST-style) nou eigenlijk is.

Ofwel: Vertel ons wat RESTian is en waarom het beter zou zijn dan WebServices maar dump alsjeblieft niet gewoon 4 linkjes met vage opinie.

Als ik het jou moet uitleggen, waarom verbeter je me dan wat betreft RESTian vs. REST-style?

RESTian web services zijn services die gebruik maken van gewone XML, JSON of XHTML over HTTP (mogelijkerwijs met een iets uitgebreider gebruik van HTTP dan gangbaar is in simpele webapplicaties, in dat geval wordt het -- sinds kort -- high REST genoemd). Grootste voordeel hierbij is dat er geen enorme stukke software nodig zijn om alle abstracties te implementeren die in alle verschillende WS-protocollen gebruikt worden, zodat de complexiteit veel minder groot is.

[Croga]

Manuzhai schreef op maandag 20 maart 2006 @ 23:45:
RESTian web services zijn services die gebruik maken van gewone XML, JSON of XHTML over HTTP (mogelijkerwijs met een iets uitgebreider gebruik van HTTP dan gangbaar is in simpele webapplicaties, in dat geval wordt het -- sinds kort -- high REST genoemd). Grootste voordeel hierbij is dat er geen enorme stukke software nodig zijn om alle abstracties te implementeren die in alle verschillende WS-protocollen gebruikt worden, zodat de complexiteit veel minder groot is.

Maar in feite zegt dat dus dat er helemaal geen verschil hoeft te zijn. Een WebService implementatie kán zo gemaakt worden dat hij een POST accepteerd en XML over HTTP terug geeft. In dat geval zou je dus een RESTian implementatie van een WebService hebben. Als ik je uitleg zo lees dan zijn het twee compleet verschillende technologiën die elkaar niet in de weg zitten, en zelfs zouden kunnen aanvullen.

[djc]

Croga schreef op dinsdag 21 maart 2006 @ 08:48:
Maar in feite zegt dat dus dat er helemaal geen verschil hoeft te zijn. Een WebService implementatie kán zo gemaakt worden dat hij een POST accepteerd en XML over HTTP terug geeft. In dat geval zou je dus een RESTian implementatie van een WebService hebben. Als ik je uitleg zo lees dan zijn het twee compleet verschillende technologiën die elkaar niet in de weg zitten, en zelfs zouden kunnen aanvullen.

Het verschil is natuurlijk wel wat voor XML het betreft -- het kan het soort XML zijn zoals in een aantal WS-* standaards vastgelegd (WS-Transfer) bijvoorbeeld, XML die allemaal extra semantiek toevoegt aan de applicatie, of het kan "simpeler" XML zijn (Plain Old XML, of POX), waarin alleen de daadwerkelijke data wordt gecommuniceerd waar het in de applicatie om gaat. DAT is het verschil: alle transport-eigenaardigheden worden door HTTP afgehandeld, en niet door een laag daar bovenop.

Web Services, letterlijk genomen, is een hele brede term die inderdaad zowel op WS-* gebaseerde services van toepassing kan zijn, maar ook op RESTian services.