Simple Object Access Protocol

Av og til vinner den enkleste teknologien. Derfor gir vi SOAP en sjanse.

Trykket i Nettverk & Kommunikasjon nr.10/2000
(c) Anders Fongen 2000

Anders Fongen er høgskolelektor og fagsjef ved Den Polytekniske Høgskolen. Web-stedet hans er på www.fongen.no

Ofte er teknologien altfor avansert. Ofte er teknologien laget av personer som bruker hele sin arbeidstid på å trenge inn i et problemområde, og som derfor oppnår mye mer innsikt enn de fleste. Så lager de teknologiske løsninger som reflekterer denne innsikten. Innenfor programvare har vi mange ganger sett eksempler på at slike løsninger krever mye mer innsikt enn hva de fleste brukerne har, til tross for at utviklerne har lagt mye krefter i å få til en "innkapsling" som skal være enkel å bruke.

Teknologiske løsninger som har denne egenskapen vil utbre seg sent, den er ofte kostbar i innkjøp og koster mye å bruke. Konsulenthonorarer eller vedlikehold av intern spisskompetanse bidrar til slike kostnader.

HTML var ikke det første hyperlenke-språket, heller ikke det beste. XML var ikke den første overføringssyntaks, heller ikke den beste. De fleste Internet-protokollene er i sin utforming enklere enn dem de har utkonkurrert. Disse eksemplene burde vise at teknologi ikke bare skal løse et problem, men også være tilgjengelig for bruk av "vanlige" fagfolk.

Klient/tjener, RPC og fjernobjekter

For å få utviklingen av distribuerte programmer til å ligne mest mulig på utviklingen av andre slags programmer liker vi å fremstille distribuerte programmer slik; at meldinger over nettet ligner på prosedyrekall, og meldingsinnholdet er parametrene. Returverdien til en slik funksjon er innholdet i en "svarmelding" som sendes motsatt vei.

Denne programmeringsmetoden kalles "Remote Procedure Call" (RPC), og den skaper denne illusjonen av nærværende prosedyrer ved å la fjernprosedyrer representeres lokalt av en "stub" prosedyre. En stub ser ut som den virkelige prosedyren, men inneholder ingen annen funksjonalitet enn å bidra til at parametrene og returverdien overføres i nettverket. Disse stub-prosedyrene lages ikke manuelt, men automatisk basert på en beskrivelse av fjernprosedyrens grensesnitt (navn og parametertyper).

Og nederst ligger nettverket

1. Datatyper er representert forskjellig i ulike maskintyper. Et heltall kan ikke flyttes mellom en Motorola- og en Intel-CPU uten konvertering, fordi de tolker de samme bitene til å bety ulike tallverdier. Overføringsprotokollen må derfor sørge for den nødvendige konverteringen.
2. Sammensatte datatyper (objekter) kan ha pekere til andre objekter. En peker kan ikke overføres som en vanlig dataverdi, man må passe på at de peker dit de skal etter overføring (det som de peker på må også være overført).
3. En vanlig form for parameteroverføring er å sende en peker til en dataverdi fremfor å sende dataverdien selv (pass-by-reference). Gjennom pekeroverføring kan klienten og tjeneren dele en datavariabel i et lokalt system. Dette er kjempevanskelig å få til ved bruk av fjernprosedyrer, fordi det krever at datavariabler blir synkronisert mellom partene før, etter og endog under utførelsen av fjernprosedyren.
4. Flere programmeringsspråk har en "nødutgang" fra prosedyren i form av Exceptions (Java og C++ har dette). Dette er ingen vanlig returverdi, men en "unntakstilstand" som kommer i retur fra prosedyren som blir kalt.

En slik nettverksprotokoll har en tendens til å bli meget komplisert, og bruken av den krever ganske omstendelig "mellomvare", i form av prosedyrebibliotek og hjelpeprogrammer (f.eks. for å lage stub-prosedyrene).

Ulempe 1:

Vi ønsker oss en alternativ nettverksprotokoll som lar oss "manuelt" gå inn i protokollen og lage og lese meldingene uten bruk av komplisert mellomvare. En protokoll og et meldingsformat som er så enkelt at et par hundre linjer med programsetninger kan betjene den nødvendige kommunikasjonen.

Ulempe 2:

• at man av ytelseshensyn har valgt å bruke UDP-protokoll, noe som sperres av de fleste brannveggene.
• at man bruker TCP-portnummer som varierer. Brannvegger liker ikke det.
• at man setter opp forbindelser begge veier mellom klient og tjener. Ofte slipper en brannvegg kun gjennom forbindelser "innenfra" og "ut".

Dersom man klarer å benytte en "kjent" internet-protokoll (Web, E-mail, FTP) til RPC-formål, kan vi oppnå at rekkevidden av de tilbudene som tjeneren gir kan blir mye større i Internet-verdenen.

Remedium 1: XML

Remedium 2: HTTP

Og så har HTTP den fordel at den er godt kjent av brannvegger, som nesten alltid slipper slik trafikk forbi, i det minste der hvor klienten er på "innsiden" og tjeneren på "utsiden" av brannveggen.

Dette er SOAP

SOAP er en spesifikasjon laget av WorldWideWeb Consortium (W3C) og baserer seg som sagt på XML. SOAP sier egentlig ikke at HTTP er nødvendig, men at mange slags protokoller kan brukes. Vi venter oss lite bruk av SOAP på andre protokoller derimot, siden HTTP er såpass skreddersydd for dette formålet.

SOAP sier ikke bare at meldingene skal være XML-kodet, men gir en del nærmere bestemmelser om hvordan meldingen skal bygges opp og hvilke XML-egenskaper som skal brukes (bestemmer f.eks. bruk av diverse "namespaces").

Et eksempel på en melding og et svar i SOAP er vist i tekstboksen. I motsetning til mange andre protokoller vil SOAP som nevnt overføre alle data som "lesbare" meldinger. Det innebærer at programvaren kan bruke vanlige tegnstreng-funksjoner for å lese og skrive dataene, men ikke minst viktig er det at en slik melding kan leses av mennesker. For en person med kjennskap til SOAP-protokollen kan det å lese meldingen slik den overføres gjøre feilfinning og testing mye enklere.

Forholdet til CORBA

Kan SOAP brukes som nettverksprotokoll i store klient-tjener anvendelser basert på f.eks. CORBA? Ja, det kan det i noen utstrekning, men noen av egenskapene ved CORBA's nettverksprotokoll (kalt IIOP - Internet Inter-Orb Protocol) er vanskelig å få til med SOAP, men det kommer vi tilbake til litt senere i denne artikkelen.

Kommersielle CORBA-produkter som Orbix beveger seg i retning av å utnytte SOAP, og de har demonstrert prototyper på dette. Noen utviklingsverktøy som lar oss studere SOAP implementasjonen i detalj er derimot ikke tilgjengelig, så noen av våre uttalelser om forholdet mellom CORBA og SOAP er antagelser.

Et CORBA-produkt vil inneholde verktøy for å lage prosedyre "stubs", og for å ta i bruk SOAP må dette verktøyet endres slik at stub-prosedyrene lager meldinger kodet etter SOAP-regler, ikke lenger etter IIOP-regler. I tillegg må hjelpeprosedyrene for kjøremiljøet støtte bruk av HTTP-protokollen.

En CORBA-tjeneste tilbudt via SOAP-protokollen har som tidligere antydet den egenskap at motparten (klienten) ikke trenger å være en full CORBA-klient, men kan være en liten mikrokontroller programmert i assembler, eller et PC-program programmert i et språk hvor det ikke finnes CORBA-støtte lett tilgjengelig (vi har f.eks. aldri hørt om CORBA for Perl).

Objektorientert?

Objekter er bra å ha i et programmeringsspråk, men objekter må skapes og fjernes (lifecycle management). I et lokalt objektmiljø oppstår objekter ofte gjennom eksplisitt instansiering (en new-operasjon) og fjernes gjennom en prosess som kalles garbage collection. Garbage collection sørger for å fjerne objektet når det ikke lenger er noen som henviser (peker) til objektet.

I CORBA er det ikke mulig å skape fjernobjekter med new-operasjonen, men man ber et objekt hos tjeneren (et fabrikkobjekt) om å skape et. Objektet fjernes ved at vi bruker distributed garbage collection (DGC), som innebærer at en henvisning til et fjernobjekt blir vedlikeholdt gjennom regelmessige meldinger (hjerteslag) i nettverket. Når disse meldingene opphører, ansees henvisningen som borte, og objektet kan etterhvert fjernes når alle henvisningene er borte.

DGC er ikke mulig å til i SOAP, men det finnes alternative metoder, kalt leasing. Leasing innebærer at en klient sier "dette objektet trenger jeg i 5 minutter", og etter denne tiden opphører henvisningen dersom det ikke er kommet en ny leasing-melding. Leasing krever noe mer programmering på klient-siden, men metoden skalerer bedre enn DGC, og foretrekkes derfor i mange sammenhenger. Lifecycle Management basert på Leasing er mulig å få til med SOAP.

Konklusjon

Sitatbokser:

• SOAP utvider klient/tjener-miljøet til å omfatte ikke-CORBA deltakere.
• En mikrokontroller kan nå en tjener gjennom SOAP.
• SOAP utvider rekkevidden til en tjener bak brannveggene.

Tekstboks:

POST /Termostat HTTP/1.1
Content-Type: text/xml;
Content-Length: xxxx

<Envelope>
   <Body>
      <SetTermostat>
		<verdi>22.1</verdi>
	</SetTermostat>
   </Body>
</Envelope>