Waarom SOAP ipv http post/get

[MrHighStone]

Stel dat ik tussen een applicatie en een website wat info wil uitwisselen. Ongeacht of hier geopperde oplossing goed of slecht is, wil ik wat voor's en tegen's bij elkaar hebben. De scripting inrichting van de webserver (asp of php ed) is ook niet echt van belang hier.

Huidige situatie:
Er is een standaard winkel website, die asp pagina's heeft waarmee ik de voorraad kan opvragen van een artikel en een order kan plaatsen.

Toekomstige situatie:
Behalve deze site, komt er nu een vb applicatie die op een of andere manier ook van de website functionaliteit gebruik dient te maken.
De vb app verbouwen naar een web interface is geen optie.

Volgens mij kan ik dit oplossen in drie richtingen:
- Van de vbapp naar de webapp praten mbt gewoon http get/post (alsof je een formpje submit)
- Van de vbapp naar de webapp praten door een xml bericht over http naar een asp pagina te sturen
- Van de vbapp naar de webapp praten mbv soap (op de webserver een soapservertje bouwen, en vanuit de vbapp een soap client laten praten)

Iemand voors en tegens voor deze opties, of misschien heb ik wel een goede oplossing over het hoofd gezien?

[Verwijderd]

Je zou het liefst willen dat zowel de webpagina's als de vbapp met hetzelfde component babbelen:

code:

+-------------+
|web-pagina's |--------+
+-------------+   |     +---------+ +---------+
                 +-----|Component|------|Database?|
+-------------+   |     +---------+ +---------+
|VB applicatie|--------+
+-------------+

Op deze manier is je code-redundantie (dat je bij een wijziging het maar op één plek hoeft te wijzigen) minimaal. En als ik dan naar jou opties kijk, doe je dat met SOAP.

Bij die eerste optie moet je VB-app het HTML-antwoord gaan interpreteren en bij de tweede optie moet je allemaal dingen gaan doen die SOAP al voor je doet....

[mbravenboer]

Merk allereerst op de je van de deelverzameling naar deelverzameling gaat:

1. HTTP POST
2. XML HTTP POST
3. SOAP XML HTTP POST

Allereerst: waarom zou je XML gebruiken?

Je kunt gebruik gemaken van bekende standaarden. Hierbij doel ik op:
a) documentatie en validatie met DTD/XML Schema.
b) standaard parsers zoals DOM, SAX, Pull
c) transformatie tools
d) XPath tools
enz.

Je wordt door het gebruik van XML geduwd in de richting van een duidelijk formaat van de communicatie.

Ik kan nog een heleboel voordelen gaan noemen, maar dit zijn wel de belangrijkste 2 imho. Het komt er op neer dat je gaat voor duidelijkheid en hergebruik van bestaande tools. Al deze voordelen gelden uiteraard voor jezelf, maar nog belangrijker: ook voor diegene die met je wil communiceren.

Waarom zou je SOAP kiezen?

De communicatie zal waarschijnlijk richting een soort RPC mechanisme gaan. Hierbij wil je vaak je communicatie mechanisme scheiden van de echte implementatie. Hierdoor ga je in feite methoden aanroepen op remote-objecten. SOAP biedt hiervoor een standaard. Allereerst is dit makkelijk omdat je niet zelf een eigen standaard hoeft te verzinnen. Gebruikers van jouw service kennen SOAP wellicht al en kunnen dus snel gaan samenwerken met jouw service.

Maar het echte voordeel is de abstractie: als je SOAP gebruikt kan je gebruik gaan maken van standaard tools die de volledige communicatie voor je regelen. Hierdoor hoeven jij en je klanten zich niet meer direct bezig te houden met het formaat van de XML berichten die heen en weer worden verzonden. De standaard libraries kunnen ervoor zorgen dat waarden op de correcte manier worden ge(de)serializeerd en dat de goede methoden worden aangeroepen. Daarnaast kan je uiteraard nog genieten van alle documentatie vormen die er zijn voor SOAP zoals WSDL.

Schrijf trouwens ook XML-RPC niet te snel af. SOAP is best wel complex, terwijl die complexiteit vaak niet erg zinvol is. XML-RPC heeft als filosofie: waarom moeilijk doen als het makkelijk kan. Het XML formaat van XML-RPC is een stuk makkelijker en duidekijker dan dat van SOAP. XML-RPC is ook een volledige standaard. SOAP is in feite alleen een standaard voor de 'enveloppen' waarin de echte data verstuurd gaat worden.

[MrHighStone]

Thanks, goed begin! Nog meer mensen?

[Verwijderd]

Op woensdag 13 februari 2002 13:05 schreef mbravenboer het volgende:
1. HTML HTTP POST
2. XML HTTP POST
3. SOAP XML HTTP POST

Zie in bold/italic ene kleine verbetering

Schrijf trouwens ook XML-RPC niet te snel af. SOAP is best wel complex, terwijl die complexiteit vaak niet erg zinvol is.

Och, je gebruikt gewoon programma dat van XWDL een proxy maakt, zie je van al dat XML niets meer...

[Grum]

Ben momenteel bezig meteen grote implementatie van xmlrpc en ik moet zeggen dat en errug fijn is .. het is gelimiteerd maar perfect voor het non-advanced rpc werk

www.xml-rpc.com btw

[MrHighStone]

Heeft er iemand toevallig ook een site met voorbeelden hoe zowel een server en een client mbv de ms soap toolkit te realiseren is? Bij voorkeur in asp code?

[Grum]

op de site met de ASP (vast een com object) implementatie van SOAP staat 100% zeker genoeg

ik dacht zelfs dat dit gewoon van MS was .. dus msdn zou geen rare plek zijn om te zoeken

btw .. ken je google.com niet ofzo ?

[raptorix]

Op woensdag 13 februari 2002 15:09 schreef MrHighStone het volgende:
Heeft er iemand toevallig ook een site met voorbeelden hoe zowel een server en een client mbv de ms soap toolkit te realiseren is? Bij voorkeur in asp code?

Deze vond ik zeer goed:

http://www.perfectxml.com/articles/xml/vbsoap.asp

Ik had eigenlijk nauwelijks kennis van XML/SOAP toen ik deze zag en aan hand van dit voorbeeld lukte het me binnen 4 daten een vrij compelexe webservice te bouwen.

[tomato]

Doekman: Zie in bold/italic ene kleine verbetering

mbravenboer maakte geen fout, hij wilde juist van deelverzameling naar deelverzameling zoals hij al aangaf. Overigens heeft HTML sowieso niet zoveel te maken met HTTP POST.

Grum_: Ben momenteel bezig meteen grote implementatie van xmlrpc en ik moet zeggen dat en errug fijn is .. het is gelimiteerd maar perfect voor het non-advanced rpc werk

Mooi

_{Zie ook m'n icon}

[Verwijderd]

Op woensdag 13 februari 2002 21:16 schreef tomato het volgende:

[..]

mbravenboer maakte geen fout, hij wilde juist van deelverzameling naar deelverzameling zoals hij al aangaf. Overigens heeft HTML sowieso niet zoveel te maken met HTTP POST.

Ik drukte me verkeerd uit. * doekman bedoelde natuurlijk toevoeging.

Ik ben met je eens dat HTML niet zoveel te maken heeft met HTTP, net zo min als XML wat te maken heeft met HTTP.

Ik wilde met die opmerking alleen aangeven dat het verschil tussen punt 1 en punt 2 xml/html is. Maw, in vb 1 moet je HTML parsen (want dat krijg je als antwoord) en in voorbeeld 2 kun je XML parsen, wat iets gemakkelijker is...

^{martin verhinderd?}

[mbravenboer]

Doekman: Ik drukte me verkeerd uit. * doekman bedoelde natuurlijk toevoeging.

Dat begreep ik, maar het was eigenlijk een incorrecte toevoeging. Het heeft namelijk helemaal niets met HTML forms te maken... Een HTTP POST heeft gewoon een body en die body kan alle mogelijke vormen aannemen. Het ging in mijn voorbeeld van deelverzamelingen helemaal niet specifiek om een POST vanuit een HTML Form .

Het is namelijk helemaal gezegd dat je bij een pure HTTP POST aanpak (niet XML) dan ook maar dezelfde body moet gebruiken als de submission van een HTML Form.

Maw, in vb 1 moet je HTML parsen (want dat krijg je als antwoord) en in voorbeeld 2 kun je XML parsen, wat iets gemakkelijker is...

Je krijgt bij een pure HTTP POST gewoon een body mee. Bij een HTTP POST vanuit een HTML Form krijg je als body een wat vage constructie met name-value paren. Die laatste is inderdaad lastig te parsen en eigen niet-XML formaat hoogst waarschijnlijk ook .

martin verhinderd?

Nee hoor, zag even niets om dringend te reageren .

[MrHighStone]

Dank voor jullie wijze woorden en discussie
De link naar perfectxml was een goeie. Veel nuttige info.

De pech met google is, is dat je vaak een enorme meuk aan
hits krijgt, maar nooit precies wat je zoekt. Bovendien kunnen mensen de inhoud van een document beter op inhoud en waarde schatten is mijn mening.

[raptorix]

Op donderdag 14 februari 2002 09:55 schreef MrHighStone het volgende:
Dank voor jullie wijze woorden en discussie
De link naar perfectxml was een goeie. Veel nuttige info.

De pech met google is, is dat je vaak een enorme meuk aan
hits krijgt, maar nooit precies wat je zoekt. Bovendien kunnen mensen de inhoud van een document beter op inhoud en waarde schatten is mijn mening.

Deze link vond ik zelf nog beter:

http://www.vbip.com/xml/soap_syd.asp

[Grum]

Op woensdag 13 februari 2002 21:16 schreef tomato het volgende:

_{Zie ook m'n icon}

herken het nu pas eigelijk - ook xml-rpc voorstander ?

[Martijn02]

Klinkt vast heel simpel, maar waarom communiceer je niet gewoon met dezelfde database?

[Grum]

soms wil je gewoon niet dat mensen (klanten ) direct ergens mee kunnen praten .. dus dan zet je der een xmlrpc layer tussen en alles is safe

[Martijn02]

Ok, niks gezegd... (ik zocht alleen een simpele oplossing, niet aan veiligheid gedacht)

[raptorix]

Daarnaast scheelt het gezeik met de firewall omdat nu het verkeer gewoon over zelfde port als een website kan.

[Verwijderd]

Op donderdag 14 februari 2002 00:20 schreef mbravenboer het volgende:

[..]

Dat begreep ik, maar het was eigenlijk een incorrecte toevoeging.

Het is maar net waar je vanuit gaat. Als ik het volgende lees:

Op woensdag 13 februari 2002 12:49 schreef MrHighStone onder andere het volgende:
- Van de vbapp naar de webapp praten mbt gewoon http get/post (alsof je een formpje submit)

dan denk ik dat hij z'n webapp niet wil herbouwen in VB.

Stel, pagina A toont een formulier en pagina B schrijft de POST die pagina A genereert naar een database of zo. Ik nam aan dat MrHighStone z'n vb-app net zo'n POST zou willen laten genereren als pagina A. Voordeel: dan hoef je de boel niet opnieuw te bouwen. Nadeel: legio

We praten dus een beetje langs elkaar heen , dus:

* MrHighStone : had je het idee van Marin in je hoofd of die van mij?

[mbravenboer]

Doekman: Ik nam aan dat MrHighStone z'n vb-app net zo'n POST zou willen laten genereren als pagina A.

Ah ja, daar zit wel wat in .

Kleine aanvulling bij deze situatie: het is natuurlijk niet veel werk om even de HTML Form POST vanuit een browser om te bouwen naar een XML gebaseerde POST . In de toekomst zou je hiervoor uitmuntend XForms kunnen gebruiken, maar ja: die zijn er nog niet .

[MrHighStone]

We praten wbt de oplossing allemaal een beetje langs elkaar heen. Inmiddels ben ik na anderhalve dag het web afstruinen ook een stuk wijzen geworden.

Punt is dat de kassa appl en de webshops met elkaar moeten kunnen praten.
Dat kon mijns inziens op de volgende manieren:
1. via een http post van name/value pairs in de http body
2. via een http post van xml in de http body
3. via soap (eigenlijk dus ook xml in de http body, maar nu aan mekaar geknoopt middels soap en wat abstracter gemaakt).

Inmiddels ben ik erachter dat het voor een client enorm makkelijk is om soap te praten naar een soapservertje met de mssoap toolkit. Waarschijnlijk gaat het dus deze oplossing worden, aangezien het hier overal microsoft is wat de klok slaat...
Waar ik eigenlijk naar op zoek was zijn de voors en tegens van deze 3 manieren.

Beetje duidelijker geworden zo? In ieder geval lokt het leuke discussies uit

[Grum]

[sup]* Grum fluistert xml-rpc[/sup]

[Verwijderd]

Op donderdag 14 februari 2002 22:26 schreef MrHighStone het volgende:Inmiddels ben ik erachter dat het voor een client enorm makkelijk is om soap te praten naar een soapservertje met de mssoap toolkit. Waarschijnlijk gaat het dus deze oplossing worden, aangezien het hier overal microsoft is wat de klok slaat...

Lijkt me een goede keus. Die MSSOAP toolkit werkt zelfs met BEA Weblogic/Apache (een J2EE applicatieserver)!!