Wie heeft er voor mij een paar handige (als het kan Nederlandse) sites waar ik informatie kan halen over bovenstaande zaken. Ik heb natuurlijk xml.pagina.nl en de site van Microsoft globaal al doorgenomen, maar er zijn vast mensen die een aantal handige links hebben.
/u/2046/pooh2.png?f=community)
:strip_icc():strip_exif()/u/1309/yoda.jpg?f=community)
/u/12612/crop65b399f21bc43_cropped.png?f=community)
Ik schop deze even omhoog, dat moet kunnen vind ik 
Een korte vraag: waarom kan ik nergens beginners uitleg vinden over SOAP en dat soort dingen, ik ben op een 'missie' van de zaak om uit te vinden wat het nut kan zijn om met XML te werken. Maar overal wordt er vanuit gegaan dat alles je helemaal duidelijk is en dat je al jaren lang een XML developer bent. En dat ben ik niet.
Heeft iemand een goede beginners tutorial of een uitleg page voor me waar ik de beginselen door kan krijgen?
Alvast bedankt
Een korte vraag: waarom kan ik nergens beginners uitleg vinden over SOAP en dat soort dingen, ik ben op een 'missie' van de zaak om uit te vinden wat het nut kan zijn om met XML te werken. Maar overal wordt er vanuit gegaan dat alles je helemaal duidelijk is en dat je al jaren lang een XML developer bent. En dat ben ik niet.
Heeft iemand een goede beginners tutorial of een uitleg page voor me waar ik de beginselen door kan krijgen?
Alvast bedankt
Verwijderd
Er zijn al zat nuttige onderwerpen over deze zaken geweest hier, inclusief links, dus misschien moet je even de search aanroepen.
Verder is het heel moeilijk de voordelen te zien van dergelijke zaken als je niet een ervaren developer ben. En de meeste ervaren developers zullen al met XML en XSL gewerkt hebben, weten wat HTTP is, hebben al object georieenteerde software gemaakt en zijn ook zaken als COM / Corba / JEB componenten bekend. Daarom zal veel van deze artikelen op basis van die aannames geschreven worden.
Ik zal zelf even een korte poging wagen om de voordelen van XML, XSL en SOAP uit te leggen, voorzover ik ze weet.
XML: XML stelt je in staat om gegevens heel gestructureerd vast te leggen. Daarbij gaat het puur om content, niet layout. De structuur beschermt je al een beetje tegen het fouten maken, en bovendien zijn er manieren om fouten te voorkomen via DTD of XML Schema's
Het prettige aan XML is dat je de stukken software om met XML te werken (maken, parsen, doorzoeken, etc) al voor vrijwel ieder platform hebt. Deze stukken software zitten soms in software ingebouwd of zijn als losse componenten met duidelijke API's beschikbaar.
Omdat XML een heel gestructureerde en op alle platformen beschikbare manier voor het vastleggen informatie is, is het uitermate geschikt voor koppelingen tussen systemen. Dat is mijns inziens dan ook de killer app voor XML.
XSL: XSL stelt je in staat om relatief eenvoudig de content in een XML document om te zetten in een andere, nuttige vorm. Je legt feitelijk regels vast voor wat je met ieder stukje uit een XML document wil doen, drukt op de knop en klaar is Kees (of hoe je ook heet).
XSL wordt bijvoorbeeld gebruikt om XML documenten in HTML om te zetten, zodat het er in een browser mooi uit ziet. Je kan ook XML mbv XSL naar andere formaten veranderen zoals fixed text, SGML, WML of zelfs gewoon een ander XML document.
XSL is handig omdat je, zonder een XML document aan te passen, de informatie uit dat document in een voor jou nuttige vorm om kan zetten. Zo scheidt je de content van een document van de toepassing ervan (weergave in een browser, vastleggen in een logfile, doorgeven aan een ander systeem, etc.)
XSL ondersteuning is er ook op vrijwel alle platformen en in veel software, dus ook dat maakt het een krachtige tool.
SOAP: SOAP staat voor Simple Object Access Protocol, wat al aangeeft dat je met objecten gaat werken.
SOAP is een set met standaarden die gezamelijk tot doel hebben om objecten platformonafhankelijk over een TCP/IP netwerk (zoals het Internet) met elkaar te laten communiceren.
Dat wordt gedaan door gebruik te maken van een aantal bestaande standaarden:
- HTTP: HTTP is de manier waarop je webbrowser met een webserver communiceerd, maar het kan veel meer dan HTML heen en weer sturen.
HTTP biedt een manier om te communiceren tussen een server en een client die heel flexibel is (er zijn geen/weinig beperkingen aan de inhoud van de calls en responses), al goed werkt op de huidige TCP/IP infrastructuren (PC's, servers, routers, firewalls, etc) en ook op vrijwel alle platformen ondersteund wordt
- XML: de HTTP call bevat een XML document met de naam van het aan te roepen object, parameters met de datatypes etc. De HTTP response bevat een XML document met de output van het object
- Anders: ook andere standaard zaken zoals XML Schema's (waarmee afgedwongen kan worden dat een XML document aan vooraf gedefinieerde voorwaarden voldoet) worden gebruikt. Ik weet hier ook lang niet alles vanaf, dus misschien kunnen anderen hier iets meer over zeggen.
In de SOAP standaarden staat precies omschreven hoe objecten aangesproken moeten worden, en daarnaast wordt ook omschreven welke ondersteunende services er moeten zijn om SOAP compatible te zijn. Zo moet je bijvoorbeeld van een object via SOAP kunnen opvragen welke methodes en properties die ondersteunt, welke datatypes verwacht worden, wat voor data er terug komt, welke versie van het component gebruikt wordt, etc. Services zoals SDL, SCL en DISCO zijn gemaakt om dit soort zaken te fasciliteren.
Voordeel van deze afspraken is dat ze alleen maar omschrijven hoe gecommuniceerd gaat worden, niet hoe het geimplementeerd wordt. Zo kan je met PHP onder Apache op Linux een SOAP service maken, maar op Windows met Visual Studio.Net en IIS ook.
Uiteindelijk zullen er toolkits komen waardoor een groot deel van de technische complexiteit voor de developer wordt weggenomen en de developer zich kan concentreren op de functionaliteit van zijn software. Hoewel dat vast wel even wennen zal zijn en het soms wat beperkend zal aanvoelen, zal je er wel veel voordeel me kunnen behalen. Denk bijvoorbeeld aan hoe veel makkelijker mensen PHP leren en krachtige dingen kunnen maken, terwijl men vroeger nog in C++ een CGI programma schreef waarbij op veel meer dingen gelet moest worden en daardoor vaak complexer en tijdrovender was.
Ik hoop dat je hier iets aan hebt.
Enjoy
Verder is het heel moeilijk de voordelen te zien van dergelijke zaken als je niet een ervaren developer ben. En de meeste ervaren developers zullen al met XML en XSL gewerkt hebben, weten wat HTTP is, hebben al object georieenteerde software gemaakt en zijn ook zaken als COM / Corba / JEB componenten bekend. Daarom zal veel van deze artikelen op basis van die aannames geschreven worden.
Ik zal zelf even een korte poging wagen om de voordelen van XML, XSL en SOAP uit te leggen, voorzover ik ze weet.
XML: XML stelt je in staat om gegevens heel gestructureerd vast te leggen. Daarbij gaat het puur om content, niet layout. De structuur beschermt je al een beetje tegen het fouten maken, en bovendien zijn er manieren om fouten te voorkomen via DTD of XML Schema's
Het prettige aan XML is dat je de stukken software om met XML te werken (maken, parsen, doorzoeken, etc) al voor vrijwel ieder platform hebt. Deze stukken software zitten soms in software ingebouwd of zijn als losse componenten met duidelijke API's beschikbaar.
Omdat XML een heel gestructureerde en op alle platformen beschikbare manier voor het vastleggen informatie is, is het uitermate geschikt voor koppelingen tussen systemen. Dat is mijns inziens dan ook de killer app voor XML.
XSL: XSL stelt je in staat om relatief eenvoudig de content in een XML document om te zetten in een andere, nuttige vorm. Je legt feitelijk regels vast voor wat je met ieder stukje uit een XML document wil doen, drukt op de knop en klaar is Kees (of hoe je ook heet
). XSL wordt bijvoorbeeld gebruikt om XML documenten in HTML om te zetten, zodat het er in een browser mooi uit ziet. Je kan ook XML mbv XSL naar andere formaten veranderen zoals fixed text, SGML, WML of zelfs gewoon een ander XML document.
XSL is handig omdat je, zonder een XML document aan te passen, de informatie uit dat document in een voor jou nuttige vorm om kan zetten. Zo scheidt je de content van een document van de toepassing ervan (weergave in een browser, vastleggen in een logfile, doorgeven aan een ander systeem, etc.)
XSL ondersteuning is er ook op vrijwel alle platformen en in veel software, dus ook dat maakt het een krachtige tool.
SOAP: SOAP staat voor Simple Object Access Protocol, wat al aangeeft dat je met objecten gaat werken.
SOAP is een set met standaarden die gezamelijk tot doel hebben om objecten platformonafhankelijk over een TCP/IP netwerk (zoals het Internet) met elkaar te laten communiceren.
Dat wordt gedaan door gebruik te maken van een aantal bestaande standaarden:
- HTTP: HTTP is de manier waarop je webbrowser met een webserver communiceerd, maar het kan veel meer dan HTML heen en weer sturen.
HTTP biedt een manier om te communiceren tussen een server en een client die heel flexibel is (er zijn geen/weinig beperkingen aan de inhoud van de calls en responses), al goed werkt op de huidige TCP/IP infrastructuren (PC's, servers, routers, firewalls, etc) en ook op vrijwel alle platformen ondersteund wordt
- XML: de HTTP call bevat een XML document met de naam van het aan te roepen object, parameters met de datatypes etc. De HTTP response bevat een XML document met de output van het object
- Anders: ook andere standaard zaken zoals XML Schema's (waarmee afgedwongen kan worden dat een XML document aan vooraf gedefinieerde voorwaarden voldoet) worden gebruikt. Ik weet hier ook lang niet alles vanaf, dus misschien kunnen anderen hier iets meer over zeggen.
In de SOAP standaarden staat precies omschreven hoe objecten aangesproken moeten worden, en daarnaast wordt ook omschreven welke ondersteunende services er moeten zijn om SOAP compatible te zijn. Zo moet je bijvoorbeeld van een object via SOAP kunnen opvragen welke methodes en properties die ondersteunt, welke datatypes verwacht worden, wat voor data er terug komt, welke versie van het component gebruikt wordt, etc. Services zoals SDL, SCL en DISCO zijn gemaakt om dit soort zaken te fasciliteren.
Voordeel van deze afspraken is dat ze alleen maar omschrijven hoe gecommuniceerd gaat worden, niet hoe het geimplementeerd wordt. Zo kan je met PHP onder Apache op Linux een SOAP service maken, maar op Windows met Visual Studio.Net en IIS ook.
Uiteindelijk zullen er toolkits komen waardoor een groot deel van de technische complexiteit voor de developer wordt weggenomen en de developer zich kan concentreren op de functionaliteit van zijn software. Hoewel dat vast wel even wennen zal zijn en het soms wat beperkend zal aanvoelen, zal je er wel veel voordeel me kunnen behalen. Denk bijvoorbeeld aan hoe veel makkelijker mensen PHP leren en krachtige dingen kunnen maken, terwijl men vroeger nog in C++ een CGI programma schreef waarbij op veel meer dingen gelet moest worden en daardoor vaak complexer en tijdrovender was.
Ik hoop dat je hier iets aan hebt.
Enjoy
Mooi gezegd .
Kleine toevoeging over SOAP:
SOAP is in principe transport onafhankelijk. SOAP berichten kunnen ook over andere transport mechanismen als bijvoorbeeld SMTP worden verzonden.
SOAP is eigenlijk een vrij beperkte standaard. SOAP berichten bestaan uit enveloppen met een inhoud. SOAP beschrijft in feite alleen maar hoe de envelop eruit moet zien en wat de aanhef van de brief in de envelop is. De echte content van de brief is eigenlijk volledig vrij.
<off-topic>
Het is niet echt de bedoeling om in dit topic te discussieren over SOAP, maar toch merk ik maar even wat op. Je hoort regelmatig mensen beweren dat XML zo fantastisch is omdat alle applicaties dan samen kunnen werken. Naar mijn mening is dat zachtjes gezegd zwaar overdreven . XML is slechts een syntax om data te structuren. De applicatie die de XML documenten verwerkt moet die structuren nog wel kunnen begrijpen. Dit kan helaas maar zelden op een automagische manier.
Dit heeft een direct verband met SOAP. De inhoud van een SOAP bericht is, zoals ik net al zei, erg vrij. Op zich is dat fijn, omdat SOAP hierdoor een erg flexibel protocol is, maar het heeft ook grote problemen. De inhoud van de SOAP berichten kan zo merkwaardig worden dat de samenwerking tussen applicaties alles behalve gemakkelijk wordt.
Microsoft .NET Remoting, het gedistribueerde object systeem van .NET gebruikt SOAP als formaat van de berichten die tussen de applicaties worden verzonden. Men beweert dat door het gebruik van deze standaard .NET toegankelijk is voor andere platformen. Dit is zachtjes gezegd ook weer zwaar overdreven. Voor de grap zou je eens moeten kijken wat voor SOAP bericht je krjgt als je in .NET Remoting een referentie naar een remote object aanvraagt (wat toch wel vrij vaak voorkomt in een gedistribueerd objectsysteem ). De inhoud van dat bericht is totaal onbegrijpelijk voor een applicatie die niet weet dat aan de andere kant een Microsoft .NET remoting implementatie draait. Op zich is het dus nog wel prettig dat .NET remoting een open protocol gebruikt, maar de samenwerking tussen applicaties kan nooit zo vloeiend verlopen als je zou willen.
Op zich is het gebruik van SOAP in .NET Remoting nog steeds erg prettig. Ik ben bijvoorbeeld bezig met een Java RMI (Remote method invocation, het protocol onafhankelijke gedistribueerde object systeem van Java) bezig die naadloos kan samenwerken met .NET remoting applicatie (en uiteraard andersom). Dit is goed mogelijk door de toepassing van XML en SOAP in .NET Remoting.
XML-RPC is een veel beperkter protocol, maar is ook beter gespecificeerd. Ik denk dat je met het gebruik van XML-RPC kan communiceren met andere applicaties zonder dat je hoeft te weten waarin deze geimplementeerd zijn. XML-RPC is echter weer niet geschikt voor een volledig gedistribueerd objectsysteem.
</off-topic>
XSL(T) is trouwens fantastisch . Daar zou ik me zeer zeker in verdiepen.
.Kleine toevoeging over SOAP:
SOAP is in principe transport onafhankelijk. SOAP berichten kunnen ook over andere transport mechanismen als bijvoorbeeld SMTP worden verzonden.
SOAP is eigenlijk een vrij beperkte standaard. SOAP berichten bestaan uit enveloppen met een inhoud. SOAP beschrijft in feite alleen maar hoe de envelop eruit moet zien en wat de aanhef van de brief in de envelop is. De echte content van de brief is eigenlijk volledig vrij.
<off-topic>
Het is niet echt de bedoeling om in dit topic te discussieren over SOAP, maar toch merk ik maar even wat op. Je hoort regelmatig mensen beweren dat XML zo fantastisch is omdat alle applicaties dan samen kunnen werken. Naar mijn mening is dat zachtjes gezegd zwaar overdreven
. XML is slechts een syntax om data te structuren. De applicatie die de XML documenten verwerkt moet die structuren nog wel kunnen begrijpen. Dit kan helaas maar zelden op een automagische manier.Dit heeft een direct verband met SOAP. De inhoud van een SOAP bericht is, zoals ik net al zei, erg vrij. Op zich is dat fijn, omdat SOAP hierdoor een erg flexibel protocol is, maar het heeft ook grote problemen. De inhoud van de SOAP berichten kan zo merkwaardig worden dat de samenwerking tussen applicaties alles behalve gemakkelijk wordt.
Microsoft .NET Remoting, het gedistribueerde object systeem van .NET gebruikt SOAP als formaat van de berichten die tussen de applicaties worden verzonden. Men beweert dat door het gebruik van deze standaard .NET toegankelijk is voor andere platformen. Dit is zachtjes gezegd ook weer zwaar overdreven. Voor de grap zou je eens moeten kijken wat voor SOAP bericht je krjgt als je in .NET Remoting een referentie naar een remote object aanvraagt (wat toch wel vrij vaak voorkomt in een gedistribueerd objectsysteem
). De inhoud van dat bericht is totaal onbegrijpelijk voor een applicatie die niet weet dat aan de andere kant een Microsoft .NET remoting implementatie draait. Op zich is het dus nog wel prettig dat .NET remoting een open protocol gebruikt, maar de samenwerking tussen applicaties kan nooit zo vloeiend verlopen als je zou willen. Op zich is het gebruik van SOAP in .NET Remoting nog steeds erg prettig. Ik ben bijvoorbeeld bezig met een Java RMI (Remote method invocation, het protocol onafhankelijke gedistribueerde object systeem van Java) bezig die naadloos kan samenwerken met .NET remoting applicatie (en uiteraard andersom). Dit is goed mogelijk door de toepassing van XML en SOAP in .NET Remoting.
XML-RPC is een veel beperkter protocol, maar is ook beter gespecificeerd. Ik denk dat je met het gebruik van XML-RPC kan communiceren met andere applicaties zonder dat je hoeft te weten waarin deze geimplementeerd zijn. XML-RPC is echter weer niet geschikt voor een volledig gedistribueerd objectsysteem.
</off-topic>
XSL(T) is trouwens fantastisch
. Daar zou ik me zeer zeker in verdiepen.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Nog wat over XML-RPC (en SOAP 1.2)
Uit de vroege ontwikkelingen waar XML-RPC uit voortgekomen is, is ook SOAP voortgekomen. Userland (dacht ik) en Microsoft hadden een dergelijke techniek nodig en hebben hiervoor toen specificaties ontwikkeld op basis van bestaande protocollen zoals HTTP. Hieruit is later XML-RPC ontstaan (gespecificeerd door en nog steeds onder beheer van Userland) en Microsoft bedacht SOAP.
Toch bestaan er nogal wat verschillen tussen deze twee, zoals mbravenboer al duidelijk maakte. Een SOAP message is zonder goede uitleg niet zomaar te begrijpen. De envelop is altijd in dezelfde vorm, maar de inhoud kan van alles zijn (volgens goed SOAP gebruik een object, inclusief state). Dit biedt veel vrijheid en SOAP kan dan ook gebruikt worden voor het communiceren van veel soorten gegevens.
De structuur van een XML-RPC bericht is veel stricter van opzet. De specificaties zijn geheel volgens XML opgezet, daardoor is vrij gemakkelijk iets te doen met het bericht, al is enige uitleg vaak nog nodig. Bij XML-RPC gaat het altijd om een client-server verhouding waarbij de client een request doet in de vorm van een XML bericht, waarop de server response geeft in de vorm van een XML bericht. In SOAP hoeft dit dacht ik niet per se zo te gaan.
Deze XML-RPC messages worden verzonden via het bekende HTTP protocol, XML-RPC is dus eigenlijk niets anders dan een combinatie van HTTP en XML. Bij SOAP ligt het transportprotocol niet vast zoals mbravenboer al zei. XML-RPC is hierdoor vrijwel overal eenvoudig te gebruiken. Welke omgeving kent geen HTTP en XML? Zijn deze twee technieken beschikbaar, dan kun je XML-RPC gebruiken in je omgeving. De verschillende onderdelen in een (web)applicatie kunnen ook op totaal verschillende platformen draaien wanneer ze communiceren via XML-RPC. Ze moeten het alleen allemaal kunnen praten en begrijpen.
De XML approach van XML-RPC maakt het allemaal erg gemakkelijk te implementeren en te gebruiken, maar het nadeel laat zich raden: je zit min of meer vast aan XML en dat is zeker niet overal voor geschikt (in tegenstelling tot wat tegenwoordig een populaire gedachte schijnt te zijn ).
Het gebruik van bestaande technologieen als XML en HTTP is natuurlijk erg gemakkelijk omdat iedereen/alles ze kent, maar ook hier zitten zeker nadelen aan. HTTP is oorspronkelijk bedoeld voor het verzenden van eenvoudige HTML bestanden en er zijn (tegenwoordig) zeker efficienter protocollen voorhanden. XML-RPC is dus eigenlijk alleen geschikt voor het verzenden van eenvoudige berichten/documenten.
Meneer Keith Moore heeft hier een gedetaileerde discussie geschreven over het hergebruik van HTTP als basis voor andere protocollen.
Uit de vroege ontwikkelingen waar XML-RPC uit voortgekomen is, is ook SOAP voortgekomen. Userland (dacht ik) en Microsoft hadden een dergelijke techniek nodig en hebben hiervoor toen specificaties ontwikkeld op basis van bestaande protocollen zoals HTTP. Hieruit is later XML-RPC ontstaan (gespecificeerd door en nog steeds onder beheer van Userland) en Microsoft bedacht SOAP.
Toch bestaan er nogal wat verschillen tussen deze twee, zoals mbravenboer al duidelijk maakte. Een SOAP message is zonder goede uitleg niet zomaar te begrijpen. De envelop is altijd in dezelfde vorm, maar de inhoud kan van alles zijn (volgens goed SOAP gebruik een object, inclusief state). Dit biedt veel vrijheid en SOAP kan dan ook gebruikt worden voor het communiceren van veel soorten gegevens.
De structuur van een XML-RPC bericht is veel stricter van opzet. De specificaties zijn geheel volgens XML opgezet, daardoor is vrij gemakkelijk iets te doen met het bericht, al is enige uitleg vaak nog nodig. Bij XML-RPC gaat het altijd om een client-server verhouding waarbij de client een request doet in de vorm van een XML bericht, waarop de server response geeft in de vorm van een XML bericht. In SOAP hoeft dit dacht ik niet per se zo te gaan.
Deze XML-RPC messages worden verzonden via het bekende HTTP protocol, XML-RPC is dus eigenlijk niets anders dan een combinatie van HTTP en XML. Bij SOAP ligt het transportprotocol niet vast zoals mbravenboer al zei. XML-RPC is hierdoor vrijwel overal eenvoudig te gebruiken. Welke omgeving kent geen HTTP en XML? Zijn deze twee technieken beschikbaar, dan kun je XML-RPC gebruiken in je omgeving. De verschillende onderdelen in een (web)applicatie kunnen ook op totaal verschillende platformen draaien wanneer ze communiceren via XML-RPC. Ze moeten het alleen allemaal kunnen praten en begrijpen.
De XML approach van XML-RPC maakt het allemaal erg gemakkelijk te implementeren en te gebruiken, maar het nadeel laat zich raden: je zit min of meer vast aan XML en dat is zeker niet overal voor geschikt (in tegenstelling tot wat tegenwoordig een populaire gedachte schijnt te zijn
).Het gebruik van bestaande technologieen als XML en HTTP is natuurlijk erg gemakkelijk omdat iedereen/alles ze kent, maar ook hier zitten zeker nadelen aan. HTTP is oorspronkelijk bedoeld voor het verzenden van eenvoudige HTML bestanden en er zijn (tegenwoordig) zeker efficienter protocollen voorhanden. XML-RPC is dus eigenlijk alleen geschikt voor het verzenden van eenvoudige berichten/documenten.
Meneer Keith Moore heeft hier een gedetaileerde discussie geschreven over het hergebruik van HTTP als basis voor andere protocollen.
Pagina: 1