[php] interresante SOAP extensie

[Rense Klinkenberg]

Bij m'n wekelijkse bladertochje door de php mailinglist, kwam ik het volgende tegen: [PHP-DEV] PHP-SOAP features.

Hoewel het een complete eenmansactie is, ziet het er toch heel erg veelbelovend uit volgens mij. Mischien is dit handig om te weten voor mensen die ook met soap bezig willen in php. Het zou nl. zonde zijn als iedereen hetzelfde wiel uit gaat vinden.

* Rense Klinkenberg hoopt dat ie pioniers wat werk bespaart heeft

edit: Het project staat op sourceforge: http://sourceforge.net/projects/phpsoaptoolkit/

[ACM]

Ik heb het even vluchtig doorgekeken en het ziet er idd wel geinig uit

[CyberSnooP]

Interessanter nog dan de SourceForge project pagina is de bijbehorende homepage.

Ik weet dat ik ook tutorials kan gaan lezen enzo, maar kan iemand even kort een scenario schetsen waarin SOAP in (uitsluitend) PHP handig zou kunnen zijn?

[Rense Klinkenberg]

In het verhaal zelf staat al een voorbeeld gegeven eigenlijk.

Verder geeft de auteur aan dat ie het oorspronkelijk bedacht had om met java clients bij een database op een server te komen. Hiervoor wouden ze niet de database openzetten voor de gehele buitenwereld en dus heeft ie een simpel soap servetje gemaakt, De verschillende methodes in de class voerden de database-queries uit, zodat de java clients alleen maar methodes aan te hoeven roepen en daarmee het beoogde resultaat terug kregen.

[CyberSnooP]

In de tussentijd heb ik zelf maar even bedacht dat het niet onaardig is om via SOAP affiliate diensten aan te bieden.

Dus sites van derden gebruik laten maken van jou content / diensten zonder ze nu rechtstreeks database toegang of een omslachtige http-api te laten gebruiken.

[mbravenboer]

Het voordeel van het gebruik van SOAP in PHP is helemaal geen bijzondere situatie: PHP is slechts de taal waarin je de gedachte van SOAP en web-services concreet kunt implementeren op de server-side.

Het zoeken naar het nut van het gebruik van SOAP in PHP is dus in feite een zoektocht naar het nut van het gebruik van SOAP in het algemeen. Dat je aan SOAP verwante ideeen nu ook makkelijk in PHP kunt gaan implementeren is natuurlijk leuk, maar er onstaat geen nieuwe situatie.

Vervang PHP door Java, C#, VB .NET, Python of wat dan ook en je kunt je ook afvragen in welke scenario's je SOAP goed zou kunnen toepassen...

[ACM]

Op zondag 26 mei 2002 15:37 schreef CyberSnooP het volgende:
Dus sites van derden gebruik laten maken van jou content / diensten zonder ze nu rechtstreeks database toegang of een omslachtige http-api te laten gebruiken.

Dat hoeven helemaal geen derden te zijn hoor

Ook communicatie met eigen services (bijv aan de andere kant van de wereld), vormen van distributed computing (alhoewel, imho, de protocol overhead te groot is), allerlei B2B situaties (bestellingen bij je leverancier automatiseren) etc kunnen ermee ondersteund worden.

Niets dat niet anders opgelost kan worden, maar veelal is het met SOAP wel erg handig (en natuurlijk al bijna gestandariseerd) te implementeren.
Vooral vanwege de platform onafhankelijke ondersteuning via oa XML.

[CyberSnooP]

Op zondag 26 mei 2002 15:42 schreef mbravenboer het volgende:
Het voordeel van het gebruik van SOAP in PHP is helemaal geen bijzondere situatie: PHP is slechts de taal waarin je de gedachte van SOAP en web-services concreet kunt implementeren op de server-side.

Je hebt gelijk, met dat verschil dat het doel van de taal PHP anders is dan wat algemenere programmeer talen. Ondanks (in mijn ogen) vage constructie als PHP-GTK blijft PHP voornamelijk bedoeld voor het bouwen van dynamische websites.

Mijn eerste indruk van SOAP is: COOL! Zo'n eenvoudige implementatie van object-gebruik-over-een-afstand nodigt uit tot het maken van nieuwe diensten voor jezelf of anderen

[ACM]

Op zondag 26 mei 2002 18:51 schreef CyberSnooP het volgende:
Je hebt gelijk, met dat verschil dat het doel van de taal PHP anders is dan wat algemenere programmeer talen. Ondanks (in mijn ogen) vage constructie als PHP-GTK blijft PHP voornamelijk bedoeld voor het bouwen van dynamische websites.

Nou en?

SOAP is ook voorn voor internet apps bedoelt

Mijn eerste indruk van SOAP is: COOL! Zo'n eenvoudige implementatie van object-gebruik-over-een-afstand nodigt uit tot het maken van nieuwe diensten voor jezelf of anderen

Mja, SOAP is wel meer dan dat natuurlijk, of eigenlijk.... Minder en door die eenvoud kan er meer mee.

Het is niet perse een remote-procedure geheel.
Zie ook deze quote:

SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC.

van: http://www.w3.org/TR/SOAP/#_Toc478383486

[mbravenboer]

ACM: Mja, SOAP is wel meer dan dat natuurlijk, of eigenlijk.... Minder en door die eenvoud kan er meer mee.

Best grappig om iemand eens te horen zeggen dat SOAP 'minder' en 'eenvoudig' is . De meeste kritiek op SOAP gaat meestal juist over de complexiteit van SOAP.

Op zich heb je deels wel gelijk want SOAP is inderdaad vrij simpel. Dit leidt er echter niet toe dat de oplossing waarin je SOAP gebruikt als geheel ook eenvoudig is. SOAP is namelijk eigenlijk nog een al een 'beperkte' standaard die zich eigenlijk voor het grootste deel slechts bezigheid met de 'enveloppen' waarin data verzonden kan worden.

Deze data in deze enveloppen kan alle mogelijke vormen aannemen, tot zelfs zeer complexe. In .NET Remoting gebruiken ze bijvoorbeeld SOAP als basis voor het volledige gedistribueerde object-systeem (vergelijkbaar met RMI en Corba). Dit zorgt ervoor dat er in de enveloppen enorm complexe data wordt verstuurd tot complete en zeer complexe object referenties.

SOAP is dus geen complete standaard voor data-uitwisseling omdat het in feite alleen aangeeft hoe de data die verstuurd wordt beschreven moet worden (samen met WSDL). Daardoor is SOAP zelf wellicht niet erg lastig, maar de gehele oplossing kan best erg lastig worden zoals je terug ziet in .NET Remoting en zelfs al de Google web-services.

Het is interessant om de complexiteit van SOAP te vergelijken met XML-RPC, wat door veel mensen als veel eenvoudiger wordt ervaren. Nu heb ik echter wel weer genoeg getikt .

[tomato]

mbravenboer: Het is interessant om de complexiteit van SOAP te vergelijken met XML-RPC, wat door veel mensen als veel eenvoudiger wordt ervaren. Nu heb ik echter wel weer genoeg getikt .

En nu verwacht je zeker dat ik hier op inhaak?

Eigenlijk is er al genoeg over gezegd, even zoeken op XML-RPC (niet alleen in /14) geeft genoeg informatie


* tomato is absoluut niet gecharmeerd van SOAP
* tomato ziet dat XML-RPC ook niet perfect is, maar kan het beter waarderen

[mbravenboer]

tomato: En nu verwacht je zeker dat ik hier op inhaak?

Tuurlijk, zo'n voorzet laat je toch niet lopen .

Maar het is dus een goed idee om niet blind achter de SOAP kudde aan te lopen en te kijken of je misschien ook goed kunt werken met XML-RPC, waar al veel implementaties van zijn, veel eenvoudiger te leren is en wat een veel kleinere foot-print heeft.

Net als bij Relax NG versus XML Schema kan een niet W3C standaard gerust beter zijn dan de consensus bloat die het W3C soms weet te produceren .

[Rense Klinkenberg]

Op zondag 26 mei 2002 21:26 schreef mbravenboer het volgende:
Maar het is dus een goed idee om niet blind achter de SOAP kudde aan te lopen en te kijken of je misschien ook goed kunt werken met XML-RPC, waar al veel implementaties van zijn, veel eenvoudiger te leren is en wat een veel kleinere foot-print heeft.

Deze topic was ook niet bedoeld om mensen met soap te gaan laten werken, maar degene die al met soap bezig wilden te informeren over de mogelijkheden die php hierin kan bieden. Voornamelijk mensen die dus nu gebruik maken van de pear soap inplementatie of eigen classes.

[tomato]

freak007: Deze topic was ook niet bedoeld om mensen met soap te gaan laten werken, maar degene die al met soap bezig wilden te informeren over de mogelijkheden die php hierin kan bieden. Voornamelijk mensen die dus nu gebruik maken van de pear soap inplementatie of eigen classes.

En soms heb je natuurlijk ook gewoon geen keus, bijvoorbeeld als jij een van de 27 clients voor een SOAP server implementeert

Dus dergelijke informatie is altijd handig

[mbravenboer]

freak007: Deze topic was ook niet bedoeld om ...

Ja, ik kwam wellicht wat verkeerd over: m'n opmerkingen over SOAP zijn natuurlijk helemaal niet specifiek gericht op deze implementatie of het gebruik daarvan.

Als je SOAP wilt of moet gebruiken kan deze library een uitkomst zijn, zeker ten opzichte van eigen 'gepruts'. Als je echter voor educatieve doeleinden gaat spelen met web-services (wat ten slotte de meeste mensen hier doen) is het goed om even heel het terrein te verkennen en dus ook eens naar XML-RPC te kijken, maar natuurlijk is het nog beter om naast deze hype-producten ook kennis te maken met 'conventionele' gedistribueerde object systemen .

[CyberSnooP]

Op zondag 26 mei 2002 22:41 schreef mbravenboer het volgende:
Als je echter voor educatieve doeleinden gaat spelen met web-services (wat ten slotte de meeste mensen hier doen) is het goed om even heel het terrein te verkennen en

dus blij te zijn met de opmerkingen die ik met m'n (eigenlijk) zinloze post teweeg brengt.

Veelal omdat ik projecten zelfstandig (als hobby) ontwikkel, waarbij ik dus niet vast zit aan eerder door anderen gekozen standaarden.

Zijn er naast XML-RPC en SOAP andere (in PHP) bruikbare standaarden?

[mbravenboer]

CyberSnooP: Zijn er naast XML-RPC en SOAP andere (in PHP) bruikbare standaarden?

Misschien is iemand zo gek geweest om een Corba implementatie te maken voor PHP?

Qua XML gerelateerd materiaal valt het verder wel mee als je naar de pure data-uitwisseling protocollen kijkt. Als je WSDL, XML Schema en dergelijke ook allemaal gaat meenemen wordt het natuurlijk wel een ander verhaal .

Je kunt trouwens ook kiezen voor een eigen eenvoudig XML formaat, wat je kunt documenteren met schema's in 1 van de XML schema talen.

[Rense Klinkenberg]

Op maandag 27 mei 2002 11:15 schreef mbravenboer het volgende:
Misschien is iemand zo gek geweest om een Corba implementatie te maken voor PHP?

Eerlijk gezegd moet ik wel bekennen dat ik zoiets ook ergens voorbij heb zien komen in de docs of op de newsgroup. er schijnt dus wel zoiets te zijn.

Je kunt trouwens ook kiezen voor een eigen eenvoudig XML formaat, wat je kunt documenteren met schema's in 1 van de XML schema talen.

Zoiets lijkt mij eigenlijk niet handig, omdat je vaak voor veel dingen opnieuw het wiel moet uitvinden waar ze dat al hebben gedaan.

Als je per se iets met xml zou willen doen, lijkt het me eerder handig om eens goed naar de huidige mogelijkheden te kijken voordat je zelf iets gaat verzinnen. Het lijkt me dan net zoiets als zelf een nieuwe xml schema taal verzinnen, terwijl er al genoeg alternatieven zijn.

[CyberSnooP]

Wat mij tot nu toe is opgevallen bij het kiezen (voor zover ik het überhaupt nodig heb) tussen XML-RPC en SOAP is dat XML-RPC veel meer aanpassingen in de code vereist. Hiermee wordt het natuurlijk flexibeler, en leg je precies vast wat je aan je de client mededeelt, maar het mooie van de (php)SOAP implementatie is dat je zonder moeite bestaande klassen kunt delen met een SOAPServer.

[mbravenboer]

freak007: Eerlijk gezegd moet ik wel bekennen dat ik zoiets ook ergens voorbij heb zien komen in de docs of op de newsgroup. er schijnt dus wel zoiets te zijn.

Idd, volgens mij is het zelfs hier wel eens ter sprake gekomen. Iemand wees mij er toen op dat er een Corba implementatie (of ten minste een poging daartoe) voor PHP is.

Zoiets lijkt mij eigenlijk niet handig, omdat je vaak voor veel dingen opnieuw het wiel moet uitvinden waar ze dat al hebben gedaan.

Voor een deel is dat zeker zo: de structuur van een methode invocatie en dergelijke is natuurlijk netjes geregeld in zowel SOAP als XML-RPC. Het nadeel van XML-RPC (zonder er ooit echt mee gewerkt te hebben, dus dat kan ik eigenlijk niet goed beoordelen) vind ik echter dat de data die je uitwisseld in nog een nieuwe laag van een abstract data type wordt gestopt. XML is namelijk zelf al een abstract data type, waar je alle boom achtige data in kunt represeteren. XML-RPC gooit hier een nieuwe laag overheen in de vorm van primtieven en structs. Dit is aan de ene kant een hele verstandige keuze omdat dit beter gemapped kan worden naar data-structuren in de talen waarin je XML-RPC gebruikt, maar aan de andere kant kan je je ook voorstellen dat je de structuur van data die je uitwisselt liever niet al te veel wilt laten beinvloden door de benodigde mapping, die je apart zou kunnen definieren. Voor SOAP geldt in feite hetzelfde probleem, maar dan naar mijn gevoel in iets mindere mate.

Als ik dus een punt van kritiek zou moeten leveren op XML-RPC, zou het dit wel zijn, met de aantekening dat de keuze ook logisch en dus goed verklaren is.

Het fraaie aspect van SOAP is toch wel dat de infrastructuur van de enveloppen meer gescheiden is van de data zelf. Dat SOAP bloat zooi aan het worden is, is niet percee het gevolg van deze beslissing.

Het lijkt me dan net zoiets als zelf een nieuwe xml schema taal verzinnen, terwijl er al genoeg alternatieven zijn.

Relax NG bijvoorbeeld .

[mbravenboer]

CyberSnooP: Wat mij tot nu toe is opgevallen bij het kiezen (voor zover ik het überhaupt nodig heb) tussen XML-RPC en SOAP is dat XML-RPC veel meer aanpassingen in de code vereist.

Dit is denk ik vooral een tool-probleem en niet zozeer direct een gevolg van de standaard die je kiest. Wel is het zo dat er bij SOAP een veel grotere trend is naar generatie van de web-service rond bestaande 'normale' code, wat ook wel goed te verklaren is gezien de complexiteit van SOAP. Bij XML-RPC zou je echter best hetzelfde kunnen doen...

[Rense Klinkenberg]

Op maandag 27 mei 2002 16:05 schreef mbravenboer het volgende:
Idd, volgens mij is het zelfs hier wel eens ter sprake gekomen. Iemand wees mij er toen op dat er een Corba implementatie (of ten minste een poging daartoe) voor PHP is.

Gevonden: http://pear.php.net/manual/en/pecl.satellite.php

RelaxNG bijvoorbeeld .

Die reactie had ik niet verwaht van jou zeg

edit: even topix uitgelegd hoe het wel moest

[mbravenboer]

Maak jij er even een zootje van .

[Soultaker]

Op maandag 27 mei 2002 17:15 schreef freak007 het volgende:
Gevonden: [url="http://pear.php.net/manual/en/pecl.satellite.php]

Eigenlijk is Universe een stuk geavanceerder dan Satellite (ie. het werkt echt), hoewel daar ook nog heel erg veel aan moet gebeuren voordat 't echt CORBA compliant is.

http://universe.2good.nu/

Het is wel leuk om mee te spelen, though.

[Verwijderd]

Dit is iets te hoog gegrepen voor mij.
Lees: Dit ga ik niet voor mijn plezier doorlezen.