Geschiedenis van de schepping

Met de komst van personal computers ontstond de behoefte om ze te combineren. Aanvankelijk waren er eenvoudige kabelverbindingen, daarna verschenen er netwerkprotocollen die computers verenigden die op hetzelfde besturingssysteem draaiden. Met de ontwikkeling van de technologie verdween de noodzaak om één besturingssysteem op alle computers te hebben en werd het mogelijk om computers met verschillende besturingssystemen te combineren. Het internet heeft de bewegingssnelheid op het pad van eenwording veranderd.

Maar zelfs vandaag de dag zijn nog niet alle integratieproblemen opgelost; er bestond helaas geen enkel protocol voor de communicatie tussen internettoepassingen en -diensten. Om dit probleem op te lossen, werkten bedrijven als Microsoft, DevelopMentor, UserLand Software, IBM en Lotus Development samen en als resultaat van hun gezamenlijke activiteiten werd het Simple Object Access Protocol gecreëerd - een eenvoudig objecttoegangsprotocol dat een standaard beschrijft voor procedures op afstand. aanroepen gebaseerd op de XML-taal (Extensible Markup Language - extensible markup Language). SOAP is ontworpen om de ontwikkeling van meertalige applicaties en bedrijfsintegratietools aanzienlijk te vereenvoudigen. Er werd begonnen met SOAP 1.0, waarvoor het HTTP-protocol nodig was om te kunnen werken.

Na het verschijnen van de eerste versie van SOAP, gecreëerd, zoals reeds opgemerkt, door de gezamenlijke inspanningen van Microsoft, DevelopMentor en UserLand, sloten IBM en Lotus zich aan bij de ontwikkeling van het product. Als gevolg hiervan heeft de specificatie een aanzienlijke herziening ondergaan om beter aan te sluiten bij de integratie van heterogene omgevingen. Het belangrijkste verschil tussen de volgende versie van SOAP 1.1 en de eerste versie was de overgang van Microsoft's XML-Data naar XML Schema. Bovendien is de specificatie in de nieuwe versie niet langer afhankelijk van transportprotocollen. SOAP 1.0 vereiste het HTTP-protocol, terwijl voor SOAP 1.1 het type transport er niet toe doet: je kunt e-mail of massagequeving-links gebruiken om berichten door te sturen. Bedrijven die SOAP 1.0 al hadden ingevoerd, raakten gebonden aan de niet-standaardtechnologie van Microsoft. Een aantal veelbelovende producten van dit bedrijf, waaronder BizTalk Server en SQL Server 7.0, vertrouwen echter ook op XML-Data. Met de komst van versie 1.1 breidt de kring van voorstanders van het SOAP-protocol zich uit

De originele versie van SOAP 1.1, ingediend bij de IETF Internet Technical Task Force, was gebaseerd op XML-Data-technologie die in januari 1998 door Microsoft werd voorgesteld. Tijdens het beoordelingsproces van de W3C-standaarden werd de onderliggende structuur echter vervangen door XML Schema. Het World Wide Web Consortium werd gevraagd SOAP 1.1 als potentiële standaard te beschouwen.

De nieuwste versie van de Simple Object Access Protocol (SOAP)-specificatie is beschikbaar op de webserver voor MSDN™ Developer Program-leden (http://msdn.microsoft.com/). SOAP is een open, op standaarden gebaseerd protocol dat, op basis van XML (Extensible Markup Language), een gebruikelijk formaat definieert voor communicatie tussen internettoepassingen en -diensten. Deze versie breidt de mogelijkheden van SOAP voor asynchrone communicatie uit en omvat niet alleen ondersteuning voor HTTP, maar ook voor internetprotocollen zoals SMTP, FTP en TCP/IP. De nieuwste versie van de SOAP-specificatie heeft brede steun gekregen van bedrijven zoals ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, UserLand Software en Zveno Pty. Ltd. De SOAP-specificatie biedt een gemeenschappelijk mechanisme voor het integreren van diensten via internet en/of intranetten, ongeacht het gebruikte besturingssysteem, objectmodel of programmeertaal. Gebaseerd op de internetstandaarden XML en HTTP, zorgt SOAP ervoor dat nieuwe of bestaande applicaties met elkaar kunnen communiceren. Websites die SOAP ondersteunen kunnen webservices worden die puur programmatisch toegankelijk zijn en geen menselijke tussenkomst vereisen. Eén enkele infrastructuur die directe interactie tussen internetgerichte applicaties mogelijk maakt, opent nieuwe mogelijkheden voor het integreren van services en apparaten, ongeacht waar ze zich op internet bevinden.

Webservices en SOAP

Webservices en SOAP zijn ontworpen om de problemen van platformonafhankelijke applicatiecommunicatie op te lossen. Dit artikel helpt u inzicht te krijgen in deze nieuwe veelbelovende technologieën.

Wat is zeep

De momenteel gebruikte technologieën voor remote method calling (DCOM, CORBA/IIOP en RMI) zijn vrij lastig te configureren en interactie te organiseren. Dit brengt problemen met zich mee in de werking en het functioneren van gedistribueerde systemen (beveiligingsproblemen, transport door firewalls, etc.). De bestaande problemen werden met succes opgelost door de creatie van SOAP (Simple Object Access Protocol), een eenvoudig op XML gebaseerd protocol voor het uitwisselen van berichten in gedistribueerde omgevingen (WWW). Het is ontworpen voor het op afstand creëren van webservices en aanroepmethoden. SOAP kan worden gebruikt met verschillende transportprotocollen, waaronder HTTP, SMTP, enz.

Wat zijn webservices

Webservices zijn functionaliteit en gegevens die beschikbaar zijn voor gebruik door externe toepassingen die met de services communiceren via standaardprotocollen en gegevensformaten. Webservices zijn volledig onafhankelijk van de implementatietaal en het platform. Webservicestechnologie is de hoeksteen van het .NET-programmeermodel van Microsoft. Om de mogelijkheden van SOAP te demonstreren, heb ik de onlangs uitgebrachte implementatie van SOAP Toolkit versie 2.0 van Microsoft gebruikt. Opgemerkt moet worden dat de huidige versie van Toolkit merkbaar verschilt van de vorige (Microsoft SOAP Toolkit voor Visual Studio 6.0) en van de bètaversie van SOAP Toolkit 2.0.

Mechanisme van interactie tussen client en server

1. De clienttoepassing instantiëert een SOAPClient-object
2. SOAPClient leest webserv(WSDL en Web Services Meta Language - WSML). Deze bestanden kunnen ook op de client worden opgeslagen.
3. De clienttoepassing roept, gebruikmakend van de late bindingsmogelijkheden van het SOAPClient-object, een servicemethode aan. SOAPClient genereert een verzoekpakket (SOAP Envelope) en verzendt dit naar de server. Elk transportprotocol kan worden gebruikt, maar doorgaans wordt HTTP gebruikt.
4. Het pakket neemt een Listener-servertoepassing (kan een ISAPI-toepassing of een ASP-pagina zijn), creëert een SOAPServer-object en geeft het verzoekpakket daaraan door
5. SOAPServer leest de beschrijving van de webservice, laadt de beschrijving en het aanvraagpakket in XML DOM-bomen
6. SOAPServer roept een methode aan van het object/de applicatie die de service implementeert
7. De resultaten van de uitvoering van de methode of de foutbeschrijving worden door het SOAPServer-object omgezet in een antwoordpakket en naar de client verzonden
8. Het SOAPClient-object parseert het ontvangen pakket en stuurt de resultaten van de service of een beschrijving van de opgetreden fout terug naar de clienttoepassing.

Een WSDL-bestand is een XML-document dat de methoden beschrijft die door een webservice worden aangeboden. Ook parameters van methoden, hun typen, namen en locatie van de service Listener. De SOAP Toolkit-wizard genereert dit document automatisch.

SOAP-envelop (pakket) - een XML-document dat een verzoek/antwoord bevat voor het uitvoeren van een methode. Het is het handigst om het te beschouwen als een postenvelop waarin informatie is ingesloten. De Envelop-tag moet het hoofdelement van het pakket zijn. Het Header-element is optioneel, maar het Body-element moet aanwezig zijn en een direct onderliggend element zijn van het Envelope-element. Als er een methode-uitvoeringsfout optreedt, genereert de server een pakket met daarin een Fault-element in de Body-tag, dat een gedetailleerde beschrijving van de fout bevat. Als u de interfaces op hoog niveau SOAPClient, SOAPServer gebruikt, hoeft u niet in te gaan op de fijne kneepjes van het pakketformaat, maar kunt u desgewenst interfaces op laag niveau gebruiken of zelfs met de hand een pakket maken.

Het SOAP Toolkit-objectmodel maakt het mogelijk om met API-objecten op laag niveau te werken:

• SoapConnector - Biedt werk met het transportprotocol voor het uitwisselen van SOAP-pakketten
• SoapConnectorFactory - Biedt een methode voor het maken van een connector voor het transportprotocol dat is opgegeven in het WSDL-bestand (tag)
• SoapReader - Leest SOAP-berichten en bouwt XML DOM-bomen
• SoapSerializer - Bevat methoden voor het maken van een SOAP-bericht
• IsoapTypeMapper, SoapTypeMapperFactory - Interfaces waarmee u met complexe gegevenstypen kunt werken

Met behulp van API-objecten op hoog niveau kunt u alleen gegevens van eenvoudige typen overbrengen (int, srting, float ...), maar dankzij de SOAP 1.1-specificatie kunt u werken met complexere gegevenstypen, zoals arrays, structuren, lijsten en hun combinaties. Om met dergelijke typen te werken, moet u de interfaces IsoapTypeMapper en SoapTypeMapperFactory gebruiken.

Lyrisch gedeelte.

Stel je voor dat je een bepaald systeem hebt geïmplementeerd of aan het implementeren bent dat van buitenaf toegankelijk moet zijn. Die. er is een bepaalde server waarmee u moet communiceren. Bijvoorbeeld een webserver.

Deze server kan veel acties uitvoeren, met de database werken, verzoeken van derden aan andere servers uitvoeren, enkele berekeningen uitvoeren, enz. leven en eventueel ontwikkelen volgens het hem bekende scenario (dat wil zeggen volgens het scenario van de ontwikkelaar). Het is voor een mens niet interessant om met zo'n server te communiceren, omdat hij wellicht geen mooie pagina's kan/wil voorzien van afbeeldingen en andere gebruiksvriendelijke inhoud. Het is geschreven en werkt om te werken en gegevens te verstrekken wanneer daarom wordt gevraagd, zonder dat u zich zorgen hoeft te maken dat het voor mensen leesbaar is, de klant gaat er zelf mee aan de slag.

Andere systemen die toegang hebben tot deze server, kunnen de gegevens die zij van deze server ontvangen al naar eigen goeddunken verwerken - verwerken, verzamelen, doorgeven aan hun klanten, enz.

Welnu, een van de opties om met dergelijke servers te communiceren is SOAP. SOAP xml-protocol voor berichtuitwisseling.

Praktisch gedeelte.

Een webservice (dit is de naam van wat de server aanbiedt en wat clients gebruiken) maakt het mogelijk om met duidelijk gestructureerde berichten met de server te communiceren. Feit is dat de webservice geen gegevens accepteert. Op elk bericht dat niet aan de regels voldoet, reageert de webservice met een foutmelding. De fout zal overigens ook in xml-vorm zijn met een duidelijke structuur (wat niet geldt voor de tekst van het bericht).

WSDL (Web Services Beschrijving Taal). Ook de regels waarmee berichten voor de webservice worden samengesteld, zijn beschreven met behulp van xml en hebben bovendien een duidelijke structuur. Die. Als een webservice de mogelijkheid biedt om een ​​methode aan te roepen, moet deze de clients in staat stellen te weten welke parameters voor deze methode worden gebruikt. Als de webservice een string voor Method1 als parameter verwacht en de string Param1 moet heten, dan worden deze regels gespecificeerd in de webservicebeschrijving.

Niet alleen eenvoudige typen, maar ook objecten en verzamelingen objecten kunnen als parameters worden doorgegeven. De beschrijving van een object komt neer op een beschrijving van elk onderdeel van het object. Als een object uit meerdere velden bestaat, wordt elk veld beschreven, het type, de naam (wat zijn de mogelijke waarden). Velden kunnen ook van een complex type zijn, enzovoort, totdat de beschrijving van de typen eindigt met eenvoudige velden: string, boolean, getal, datum... Sommige specifieke typen kunnen echter eenvoudig blijken te zijn. Het is belangrijk dat clients kunnen begrijpen welke waarden ze kunnen bevatten.

Voor klanten is het voldoende om de url van de webservice te kennen; de wsdl zal altijd in de buurt zijn, van waaruit u een idee kunt krijgen van de methoden en hun parameters die deze webservice biedt.

Wat zijn de voordelen van al deze toeters en bellen:

• In de meeste systemen vindt de beschrijving van methoden en typen automatisch plaats. Die. de programmeur op de server hoeft alleen maar te zeggen dat deze methode kan worden aangeroepen via een webservice, en de wsdl-beschrijving wordt automatisch gegenereerd.

De beschrijving, die een duidelijke structuur heeft, is voor iedere soap-klant leesbaar. Die. Wat de webservice ook is, de klant begrijpt welke gegevens de webservice ontvangt. Met behulp van deze beschrijving kan de klant zijn eigen interne structuur van objectklassen bouwen, de zogenaamde. binding" en. Als resultaat moet de programmeur die de webservice gebruikt iets schrijven als (pseudocode):

NewUser:=TSoapUser.Create("Vasya", "Pupkin", "beheerder"); soap.AddUser(NieuweGebruiker);

• Automatische validatie.

  • XML-validatie. xml moet goed opgemaakt zijn. Ongeldige xml - onmiddellijk een fout voor de klant, laat hem het oplossen.
  • schema-validatie. xml moet een bepaalde structuur hebben. xml komt niet overeen met het schema - onmiddellijk een fout voor de klant, laat hem het oplossen.
  • Gegevensverificatie wordt uitgevoerd door de soapserver, zodat gegevenstypen en beperkingen overeenkomen met de beschrijving.
• Autorisatie en authenticatie kunnen via een aparte methode worden geïmplementeerd. van nature. of via http-autorisatie.
• Webservices kunnen zowel via het soap-protocol als via http werken, dat wil zeggen via get-verzoeken. Dat wil zeggen, als de parameters eenvoudige gegevens zijn (zonder structuur), dan kunt u eenvoudigweg de gebruikelijke get www.site.com/users.asmx/GetUser?Name=Vasia of post aanroepen. Dit is echter niet overal en niet altijd.
• ... zie op Wikipedia

Er zijn ook veel nadelen:

• Onredelijk grote berichtgrootte. Welnu, hier is de aard van XML zodanig dat het formaat overbodig is: hoe meer tags, hoe meer nutteloze informatie. Plus zeep voegt zijn redundantie toe. Voor intranetsystemen is de kwestie van het verkeer minder acuut dan voor internet, dus er is meer vraag naar soap voor lokale netwerken, met name Sharepoint heeft een soap-webservice waarmee je met succes (en enkele beperkingen) kunt communiceren.
• Het automatisch wijzigen van de beschrijving van een webservice kan alle clients kapot maken. Nou, zo is het voor elk systeem: als achterwaartse compatibiliteit met oude methoden niet wordt ondersteund, valt alles weg...
• Geen minpunt, maar een minpunt. Alle methodeaanroepen moeten atomair zijn. Als we bijvoorbeeld met een database werken, kunnen we een transactie starten, verschillende query's uitvoeren en vervolgens terugdraaien of vastleggen. Er zijn geen transacties in soap. Eén verzoek, één antwoord, het gesprek is voorbij.
• Omgaan met de beschrijving van wat er op de server staat (is alles correct beschreven?) en wat er op de client staat (wat hebben ze mij hier beschreven?) kan behoorlijk moeilijk zijn. Er waren verschillende keren dat ik de clientkant moest begrijpen en de serverprogrammeur ervan moest overtuigen dat zijn gegevens verkeerd waren beschreven, maar hij kon er helemaal niets van begrijpen, omdat automatische generatie en dat zou hij niet moeten doen, het is een kwestie van software . En de fout zat uiteraard in de methodecode; de ​​programmeur zag het gewoon niet.
• De praktijk leert dat ontwikkelaars van webservices vreselijk ver verwijderd zijn van de mensen die deze webservices gebruiken. Als reactie op elk verzoek (geldig van buitenaf) kan een onbegrijpelijke fout "Fout 5. Alles is slecht" optreden. Het hangt allemaal af van het geweten van de ontwikkelaars :)
• Ik weet zeker dat ik me nog steeds iets niet herinner...

Er is bijvoorbeeld een open webservice belavia:

• http://86.57.245.235/TimeTable/Service.asmx - toegangspunt, er is ook een tekstbeschrijving van methoden voor externe ontwikkelaars.
• http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl-beschrijving van methoden en typen ontvangen en geretourneerde gegevens.
• http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - beschrijving van een specifieke methode met een voorbeeld van het type XML-verzoek en XML-antwoord.

U kunt handmatig een verzoek maken en verzenden, zoals:

POST /TimeTable/Service.asmx HTTP/1.1 Host: 86.57.245.235 Inhoudstype: tekst/xml; charset=utf-8 Content-Length: lengte SOAPAction: "http://webservices.belavia.by/GetAirportsList" Ru

het antwoord zal komen:

HTTP/1.1 200 OK Datum: ma, 30 september 2013 00:06:44 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-versie: 4.0.30319 Cache-controle: privé, max -age=0 Inhoudstype: tekst/xml; charset=utf-8 Inhoudslengte: 2940

PS Eerder werd de Aeroflot-webservice geopend, maar nadat 1C soap-ondersteuning aan 8ku had toegevoegd, hebben een aantal 1C-bètatesters deze met succes geïnstalleerd. Nu is daar iets veranderd (ik weet het adres niet, als je geïnteresseerd bent, kun je het opzoeken).
ZZY-disclaimer. Hij sprak op het alledaagse niveau. Je kunt trappen.

Wat is zeep?

SOAP staat voor Simple Object Access Protocol. Ik hoop dat je na het lezen van het artikel alleen maar de vraag zult stellen: “Wat is dit voor een vreemde naam?”

SOAP in zijn huidige vorm is een RPC-methode (Remote Procedure Call) via een netwerk. (Ja, het wordt ook gebruikt om documenten als XML over te dragen, maar dat laten we voorlopig buiten beschouwing.)

Laten we het uitzoeken. Stel u voor dat u een dienst heeft die een aandelenkoers retourneert voor een bepaalde ticker (aandelensymbool). Het stuurt de gegevens naar de Nasdaq-website en genereert het gewenste resultaat op basis van de geretourneerde HTML. Vervolgens maak je van deze dienst een onderdeel dat via internet informatie over offertes opzoekt, zodat andere ontwikkelaars het binnen hun applicaties kunnen gebruiken. Het werkt prima totdat Nasdaq op een dag de lay-out van zijn pagina's verandert. Je moet de hele logica van de component heroverwegen en updates sturen naar alle ontwikkelaars die er gebruik van maken. En zij moeten op hun beurt updates naar al hun gebruikers sturen. Als dit min of meer constant gebeurt, kun je veel vijanden maken onder je mede-ontwikkelaars. En met programmeurs moet je, zoals je weet, niet spotten. Je wilt morgen toch niet een foto van je favoriete kat uit de papierversnipperaar halen?

Wat te doen? Laten we eens kijken... het enige dat u nodig heeft, is één functie aan te bieden die als invoer een tickersymbool (type string) gebruikt en een aandelenkoers retourneert (type float of double). Zou het dus niet eenvoudiger zijn om uw ontwikkelaars deze functie op de een of andere manier gewoon via internet te laten aanroepen? Geweldig! Ook nieuws voor mij: er zijn COM en Corba en Java die dit al jaren doen... wat waar is, maar deze methoden zijn niet zonder gebreken. COM-configuratie op afstand is niet triviaal. Bovendien moet je zoveel poorten in de firewall openen dat je niet genoeg bier aankan voor een systeembeheerder. Ja, en u zult gebruikers van alle besturingssystemen behalve Windows moeten vergeten. Maar Linux-gebruikers zijn soms ook geïnteresseerd in de uitwisseling.

Hoewel het erop lijkt dat niet alles verloren is voor Linux-gebruikers als ze DCOM gebruiken, meer hier: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

Ik kan niet veel zeggen over Corba en Java, dus als oefening nodig ik lezers uit om de nadelen van deze benaderingen te ontdekken.

SOAP is een standaard waarmee je zo’n oproep op afstand kunt beschrijven en de vorm waarin het resultaat terugkomt. U moet uw functie dus hosten in een applicatie die toegankelijk is via het netwerk en oproepen ontvangen als SOAP-pakketten. Vervolgens valideert u de invoer, voert u uw functie uit en retourneert u het resultaat in een nieuw SOAP-pakket. Het hele proces kan via HTTP verlopen, zodat u niet een groot aantal poorten op uw firewall hoeft te openen. Is het echt eenvoudig?

Waar gaat dit artikel over?

Dit is de eerste in een reeks artikelen die we schrijven over SOAP bij Agni Software. In dit artikel zal ik proberen je een idee te geven van wat SOAP is en hoe je een applicatie schrijft die communiceert met een SOAP-server.

Zeep en XML

Als SOAP je nog steeds eenvoudig lijkt, laten we XML toevoegen. Nu krijgen we in plaats van de functienaam en parameters een nogal complexe XML-envelop, alsof deze is ontworpen om u in verwarring te brengen. Maar haast je niet om bang te worden. Er komt meer bij kijken en je moet het hele plaatje zien om de complexiteit van SOAP te kunnen begrijpen.
Als je niet weet wat XML is, lees dan eerst mijn artikel over XML hier: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Alle SOAP-pakketten zijn in XML-formaat. Wat betekent het? Laten we eens kijken. Kijk eens naar deze functie (Pascal):
functie GetStockQuote(Symbool: string): dubbel;
Het ziet er geweldig uit, maar het probleem is dat het Pascal is. Wat is het nut van deze eenvoudige definitie voor een Java-ontwikkelaar? Of voor iemand die met VB werkt? We hebben iets nodig dat voor iedereen begrijpelijk is, zelfs voor VB-programmeurs. Geef ze dus XML met dezelfde informatie (parameters, aandelenkoersen, enz.). U maakt een SOAP-pakket, dat in wezen een oproep is voor uw functie, verpakt in XML, zodat elke toepassing op elk platform het kan begrijpen. Laten we nu eens kijken hoe onze SOAP-oproep eruit ziet:
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">


IBM

Informatief, toch? SOAP wordt steeds gemakkelijker voor onze ogen. Oké, grapjes opzij. Nu zal ik proberen u uit te leggen hoe u deze SOAP-oproep kunt begrijpen.

Tag-decodering De eerste tag die in het oog springt is

. Deze tag is de buitenste verpakking van een SOAP-pakket en bevat verschillende naamruimtedeclaraties waarin we niet bijzonder geïnteresseerd zijn, maar die erg belangrijk zijn voor elke programmeertaal of parser. Naamruimten worden gedefinieerd om ervoor te zorgen dat daaropvolgende voorvoegsels zoals "SOAP-ENV:" of "xsd:" door de parser worden begrepen. Volgende label – . (We hebben een tag gemist die hier niet wordt weergegeven - . Het staat niet in dit specifieke voorbeeld, maar als je er meer over wilt lezen, bekijk dan hier de SOAP-specificatie: http://www.w3.org/TR/SOAP/). Label

bevat feitelijk een SOAP-oproep. De volgende tag in de lijst is

Een opmerking over naamruimten: Een naamruimte maakt het mogelijk een XML-tag te kwalificeren. Je kunt bijvoorbeeld niet twee variabelen met dezelfde naam in één procedure hebben, maar als ze zich in twee verschillende procedures bevinden, is er geen probleem. Een procedure is dus een naamruimte, omdat alle namen daarin uniek zijn. Op dezelfde manier hebben XML-tags hun bereik binnen naamruimten, dus op basis van een naamruimte en een tagnaam kunt u deze uniek identificeren. We definiëren de naamruimte als een URI om onze NS1 te onderscheiden van copycats. In het bovenstaande voorbeeld is NS1 een alias die verwijst naar urn:xmethods-quotes.

Let ook op het encodingStyle attribuut: dit attribuut bepaalt hoe de SOAP-oproep wordt geserialiseerd.

Binnen een label bevat parameters. In ons eenvoudigste geval hebben we slechts één parameter: tag . Let op deze regel naast de tag:
xsi:type=”xsd:string”
Dit is ongeveer hoe typen in XML worden gedefinieerd. (Merk op hoe slim ik het woord ‘ongeveer’ heb gebruikt toen ik generaliseerde over technologie die kan veranderen zodra het artikel is gepubliceerd.) Wat betekent dit precies: een type dat is gedefinieerd in de xsi-naamruimte en waarvan u zult merken dat het in de tag is gedefinieerd – xsd:tekenreeks. En dit is op zijn beurt een string, gedefinieerd in de xsd-naamruimte, wederom eerder gedefinieerd. (Ik weet zeker dat advocaten hier heel blij mee zouden zijn).

Binnen een label "IBM" wordt aangegeven. Dit is de waarde van de symboolparameter van de GetStockQuote-functie.

Nou, uiteindelijk hebben we, net als fatsoenlijke mensen, alle tags gesloten.

Dus we hebben het SOAP-pakket ontdekt dat de oproep naar de SOAP-server definieert. En de SOAP-server decodeert deze oproep, met behulp van XML-parsers, de rode knop en het MIR-ruimtestation, en bepaalt dat u een aandelenkoers nodig heeft. Hij vindt meteen de juiste offerte en stuurt deze in deze vorm aan u terug:
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


34.5


Na het uitpakken van de SOAP-envelop, het afscheuren van de linten en het ritselen van de verpakking, vernemen we dat de koers van het IBM-aandeel 34,5 bedraagt.

De meeste commerciële servers zouden veel meer informatie retourneren, zoals in welke valuta en tegen welke prijs de laatste voorraad is gekocht. En de aandelenkoers zou misschien nauwkeuriger zijn geweest.

Zo weten wij wat de SOAP-server verwacht en wat deze teruggeeft. Dus HOE verzendt u deze informatie? Je kunt gebruik maken van elk vervoermiddel. Het meest gedekt is HTTP. Ik zal niet in detail treden over HTTP, voor degenen die het niet weten: dit is wat uw browser gebruikt om te communiceren met de sites die u bezoekt.

Het vereiste HTTP-verzoek ziet er ongeveer zo uit:
POST/StockQuote HTTP/1.1
Host: www.stockquoteserver.com

Inhoud-lengte: nnnn
SOAPActie: "Sommige-URI"

Het soap-verzoekpakket hier... Het enige andere dat het vermelden waard is, is de SOAPAction-header. Deze header geeft het doel van het verzoek aan en is vereist. Elke SOAP-server kan een onbeperkt aantal functies hebben en kan aan de hand van de SOAPAction-header bepalen welke functie wordt aangeroepen. Firewalls en multiplexers kunnen ook inhoud filteren op basis van deze header.

Het SOAP-antwoord van de HTTP-server ziet er als volgt uit:
HTTP/1.1 200 OK
Inhoudstype: tekst/xml; tekenset = "utf-8"
Inhoud-lengte: nnnn

Soap Response-pakket hier... Waarom HTTP? Ten eerste hoeven netwerkbeheerders niet veel aparte poorten te openen voor SOAP-oproepen... de webserver kan de oproepen met gemak afhandelen, omdat Poort 80 staat doorgaans voor iedereen open om inkomende verzoeken te ontvangen. Een ander voordeel is de uitbreidbaarheid van webservers met behulp van CGI, ISAPI en andere native modules. Dankzij deze uitbreidbaarheid kunt u een module schrijven die SOAP-verzoeken verwerkt zonder andere webinhoud te beïnvloeden.

Dat is alles

Ik hoop dat dit artikel enig licht heeft geworpen op SOAP. Als je nog steeds hier bent en meer over dit onderwerp wilt lezen, bezoek dan de website van de auteur: http://www.agnisoft.com/soap

Eenvoudig Object Access Protocol (SOAP) is een op XML gebaseerd protocol dat de regels definieert voor het verzenden van berichten via internet tussen verschillende applicatiesystemen. Het wordt voornamelijk gebruikt voor externe procedureaanroepen. SOAP is oorspronkelijk ontworpen om ‘boven’ HTTP te functioneren (om de integratie van SOAP in webapplicaties te vereenvoudigen), maar nu kunnen ook andere transportprotocollen, zoals SMTP, worden gebruikt.

Stel dat u een applicatietoegangsservice op internet maakt; Consumenten hebben interactie met deze dienst door deze van informatie te voorzien. Uw servers verwerken de gegevens en sturen de resultaten terug naar consumenten. Wat is de beste manier om de communicatie met het systeem te onderhouden?

U kunt een aangepaste client-servertoepassing maken en van consumenten eisen dat ze een aangepast clientprogramma gebruiken om toegang te krijgen tot uw service. Maar als je serieus wilt gaan werken in de internetwereld, zul je een client moeten maken die op alle mogelijke clientplatforms draait: Windows, Macintosh, Unix, Linux, enz. Met andere woorden, je zult veel verschillende clients moeten schrijven .

Wat vindt u van het gebruik van internet? Deze oplossing is natuurlijk heel acceptabel, maar is nauw verbonden met de browserimplementatie, en ook hier zul je een infrastructuur moeten creëren om inkomende en uitgaande informatie te verzenden en ontvangen, en de gegevens voor een dergelijke uitwisseling te formatteren en te verpakken. U kunt Java of ActiveX kiezen om complexe applicaties te implementeren, maar sommige gebruikers zullen uw diensten weigeren vanwege duidelijk te hoge bandbreedtevereisten en onvoldoende beveiliging.

Het enige dat nodig is, is een eenvoudig protocol dat het verpakken van applicatiegegevens vereenvoudigt en deze over het web verzendt met behulp van aan de inhoud aangepaste XML. Door dit te doen, zorgt het ervoor dat zowel de afzender als de ontvanger de inhoud van elk bericht gemakkelijk kunnen interpreteren. Tegelijkertijd zal het dankzij het gebruik van het HTTP-webprotocol als transportmiddel mogelijk zijn om de noodzaak om het niveau van firewallbescherming te verlagen te elimineren.

Het goed beschreven Simple Object Access Protocol (SOAP) is een eenvoudig ‘lijm’-protocol waarmee hosts op afstand applicatieobjecten kunnen aanroepen en resultaten kunnen retourneren. SOAP biedt een minimale set voorwaarden waarmee een applicatie berichten kan doorgeven: de client kan een bericht verzenden om een ​​programmaobject aan te roepen, en de server kan de resultaten van die oproep retourneren.

SOAP is vrij eenvoudig: berichten zijn XML-documenten met SOAP-opdrachten. Hoewel SOAP theoretisch aan elk transportprotocol voor toepassingen kan worden gekoppeld, wordt het doorgaans in combinatie met HTTP gebruikt.

Kennard Scribner, een van de auteurs van het boek SOAP begrijpen: de gezaghebbende oplossing(Macmillan USA, 2000), zegt dat SOAP werkt door de informatie die nodig is om een ​​methode aan te roepen (zoals argumentwaarden en transactie-ID's) om te zetten in XML-formaat.

De gegevens worden ingekapseld in HTTP of een ander transportprotocol en verzonden naar de ontvanger, meestal de server. Deze server haalt de SOAP-gegevens uit het pakket, voert de vereiste verwerking uit en retourneert de resultaten als een SOAP-antwoord.

Scribner merkte op dat SOAP fungeert als een remote procedure call-protocol, vergelijkbaar met het Remote Method Invocation-protocol in Java of het General Inter-ORB Protocol in CORBA.

Omdat HTTP en XML vrijwel overal worden gebruikt, lijkt SOAP het meest schaalbare protocol voor externe procedureaanroepen dat tot nu toe is gebouwd, aldus Scribner. SOAP is niet ontworpen om te fungeren als een complete objectarchitectuur.

SOAP vervangt het Remote Method Invocation-protocol in Java, Distributed Component Object Model en CORBA niet; het biedt regels die elk van deze modellen kan gebruiken. SOAP is geen volledige oplossing. Het ondersteunt geen objectactivering of -beveiliging. Volgens Scribner "vertrouwen SOAP-ontwikkelaars erop dat gebruikers deze code zelf zullen toevoegen" door deze bovenop SOAP te bouwen, in plaats van deze onderdeel te maken van het protocol zelf.

De afbeelding toont een voorbeeld uit de SOAP 1.1-specificatie waarin een host een offerteservice aanvraagt ​​voor de prijs van een bepaald aandeel. Het SOAP-verzoek is ingebed in een HTTP POST en de verzoektekst specificeert het type verzoek en de parameter: het aandelensymbool. Het antwoord biedt ook een XML-object ingekapseld in het HTTP-antwoord met een enkele retourwaarde (in dit geval 34,5).

Kenmerken van SOAP

Met SOAP kunnen ontwikkelaars net zo snel webservices maken als ze SOAP-berichten kunnen schrijven om programma's voor bestaande applicaties op te roepen, en deze applicaties vervolgens aan eenvoudige webpagina's toevoegen. Maar daarnaast hebben ontwikkelaars de mogelijkheid om SOAP-oproepen in speciale applicaties te gebruiken en applicaties te creëren die naar de webpagina's van anderen kunnen worden geporteerd, waardoor het tijdrovende en dure ontwikkelingsproces wordt vermeden.

Volgens Mark Stiver, een andere auteur van het boek Understanding SOAP, is dit precies het doel dat Microsoft nastreeft met zijn veelbelovende .Net-platform. “Dit is waar SOAP uitblinkt. Het geeft ontwikkelaars een geweldige manier om applicaties te maken zonder zich zorgen te hoeven maken over mogelijke incompatibiliteit”, zegt hij.

SOAP-voorbeeld

Het volgende voorbeeld illustreert een SOAP-verzoek met de naam GetLastTradePrice, waarmee een klant een verzoek kan verzenden voor de nieuwste koersen voor een bepaald aandeel.

POST/StockQuote HTTP/1.1
Gastheer: stockquoteserver.com
Inhoudstype: tekst/xml; tekenset = "utf-8"
Inhoud-lengte: nnnn
SOAPActie:"Sommige-URI"

De eerste vijf regels (onderdeel van de HTTP-header) specificeren het berichttype (POST), de host, het payload-type en de payload-lengte, en de SOAPAction-header specificeert het doel van het SOAP-verzoek. Het SOAP-bericht zelf is een XML-document met eerst een SOAP-envelop en vervolgens een XML-element dat de SOAP-naamruimte en eventuele attributen specificeert. Een SOAP-envelop kan een header bevatten (maar in dit geval niet), gevolgd door een SOAP-body. In ons voorbeeld bevat de hoofdtekst het GetLastTradePrice-verzoek en het symbool van het aandeel waarvoor de laatste koersen worden opgevraagd. Het antwoord op deze vraag zou er als volgt uit kunnen zien:

HTTP/1.1 200 OK
Inhoudstype: tekst/xml; tekenset = "utf-8"
Inhoud-lengte: nnnn

Nogmaals, de eerste drie regels maken deel uit van de HTTP-header; Het SOAP-bericht zelf bestaat uit een envelop die het antwoord op het oorspronkelijke verzoek bevat, met de naam GetLastTradePriceResponse, en de geretourneerde waarde bevat, in ons geval 34.5.