Oversigt
Komponentbaseret programmering er blevet mere populært end nogensinde. Der bliver næsten ikke bygget et program i dag, som ikke involverer komponenter i en eller anden form, som regel fra forskellige leverandører. Efterhånden som programmerne er blevet mere sofistikerede, er behovet for at udnytte komponenter, der er distribueret på eksterne maskiner, også vokset.
Et eksempel på en komponentbaseret applikation er en end-to-end e-handelsløsning. En e-handelsapplikation, der ligger på en webfarm, skal sende ordrer til en back-end Enterprise Resource Planning (ERP)-applikation. I mange tilfælde ligger ERP-applikationen på en anden hardware og kører måske på et andet operativsystem.
Microsofts Distributed Component Object Model (DCOM), en infrastruktur for distribuerede objekter, der gør det muligt for et program at kalde Component Object Model (COM)-komponenter, der er installeret på en anden server, er blevet overført til en række ikke-Windows-platforme. Men DCOM har aldrig vundet bred accept på disse platforme, så det bruges sjældent til at lette kommunikationen mellem Windows- og ikke-Windows-computere. ERP-softwareleverandører skaber ofte komponenter til Windows-platformen, som kommunikerer med back-end-systemet via en proprietær protokol.
Nogle af de tjenester, som en e-handelsapplikation benytter sig af, ligger måske slet ikke i datacentret. Hvis e-handelsapplikationen f.eks. accepterer kreditkortbetaling for varer, som kunden har købt, skal den bruge den handlende banks tjenester til at behandle kundens kreditkortoplysninger. Men i praksis er DCOM og beslægtede teknologier som CORBA og Java RMI begrænset til applikationer og komponenter, der er installeret i virksomhedens datacenter. To primære årsager til dette er, at disse teknologier som standard anvender proprietære protokoller, og at disse protokoller i sagens natur er forbindelsesorienterede.
Klienter, der kommunikerer med serveren via internettet, står over for mange potentielle barrierer for at kommunikere med serveren. Sikkerhedsbevidste netværksadministratorer over hele verden har implementeret virksomhedsroutere og firewalls for at afvise praktisk talt enhver form for kommunikation over internettet. Det kræver ofte en Guds handling at få en netværksadministrator til at åbne porte ud over det absolutte minimum.
Hvis du er heldig nok til at få en netværksadministrator til at åbne de relevante porte til at understøtte din tjeneste, er der gode chancer for, at dine klienter ikke er lige så heldige. Derfor er proprietære protokoller som dem, der bruges af DCOM, CORBA og Java RMI, ikke praktiske i internetscenarier.
Det andet problem med disse teknologier er som sagt, at de i sagens natur er forbindelsesorienterede og derfor ikke kan håndtere netværksafbrydelser på en elegant måde. Fordi internettet ikke er under din direkte kontrol, kan du ikke gøre nogen antagelser om forbindelsens kvalitet eller pålidelighed. Hvis der opstår en netværksafbrydelse, kan det næste opkald, klienten foretager til serveren, mislykkes.
Den forbindelsesorienterede karakter af disse teknologier gør det også udfordrende at opbygge de belastningsbalancerede infrastrukturer, der er nødvendige for at opnå høj skalerbarhed. Når forbindelsen mellem klienten og serveren er afbrudt, kan man ikke bare sende den næste anmodning videre til en anden server.
Udviklere har forsøgt at overvinde disse begrænsninger ved at udnytte en model, der hedder tilstandsløs Programmering, men de har haft begrænset succes, fordi teknologierne er ret tunge og gør det dyrt at genoprette en forbindelse med et fjerntliggende objekt.
Da behandlingen af en kundes kreditkort udføres af en fjernserver på internettet, er DCOM ikke ideel til at lette kommunikationen mellem e-handelsklienten og kreditkortsbehandlingsserveren. Ligesom i en ERP-løsning installeres der ofte en tredjepartskomponent i klientens datacenter (i dette tilfælde af udbyderen af kreditkortbehandlingen). Denne komponent fungerer som lidt mere end en proxy, der letter kommunikationen mellem e-handelssoftwaren og den handlende bank via en proprietær protokol.
Kan du se et mønster her? På grund af de eksisterende teknologiers begrænsninger, når det gælder kommunikation mellem computersystemer, har softwareleverandørerne ofte været nødt til at bygge deres egen infrastruktur. Det betyder, at ressourcer, der kunne have været brugt til at tilføje forbedret funktionalitet til ERP-systemet eller kreditkortsystemet, i stedet er blevet brugt til at skrive proprietære netværksprotokoller.
I et forsøg på bedre at understøtte sådanne internetscenarier valgte Microsoft oprindeligt at udvide sine eksisterende teknologier, herunder COM Internet Services (CIS), som gør det muligt at etablere en DCOM-forbindelse mellem klienten og fjernkomponenten via port 80. Af forskellige årsager blev CIS ikke bredt accepteret.
Det blev klart, at der var brug for en ny tilgang. Så Microsoft besluttede at løse problemet nedefra og op. Lad os se på nogle af de krav, løsningen skulle opfylde for at blive en succes.
- Interoperabilitet Fjerntjenesten skal kunne bruges af klienter på andre platforme.
- Internet-venlighed Løsningen bør fungere godt til at understøtte klienter, der får adgang til fjerntjenesten fra internettet.
- Stærkt typede grænseflader Der bør ikke være nogen tvetydighed om typen af data, der sendes til og modtages fra en fjerntjeneste. Desuden bør datatyper, der er defineret af fjernservicen, passe rimeligt godt til datatyper, der er defineret af de fleste procedurale programmeringssprog.
- Evne til at udnytte eksisterende internetstandarder Implementeringen af fjernservicen bør udnytte eksisterende internetstandarder så meget som muligt og undgå at genopfinde løsninger på problemer, der allerede er løst. En løsning, der bygger på bredt vedtagne internetstandarder, kan udnytte eksisterende værktøjssæt og produkter, der er skabt til teknologien.
- Understøttelse af alle sprog Løsningen bør ikke være tæt koblet til et bestemt programmeringssprog. Java RMI er f.eks. tæt koblet til Java-sproget. Det ville være svært at påkalde funktionalitet på et eksternt Java-objekt fra Visual Basic eller Perl. En klient skal kunne implementere en ny webtjeneste eller bruge en eksisterende webtjeneste, uanset hvilket programmeringssprog klienten er skrevet i.
- Understøttelse af enhver distribueret komponentinfrastruktur Løsningen bør ikke være tæt koblet til en bestemt komponentinfrastruktur. Faktisk bør det ikke være nødvendigt at købe, installere eller vedligeholde en infrastruktur for distribuerede objekter, bare for at bygge en ny fjernservice eller bruge en eksisterende service. De underliggende protokoller skal muliggøre et grundlæggende kommunikationsniveau mellem eksisterende infrastrukturer for distribuerede objekter som DCOM og CORBA.
I betragtning af titlen på denne bog bør det ikke komme som nogen overraskelse, at den løsning, Microsoft skabte, er kendt som Webtjenester. En webtjeneste udstiller en grænseflade til at påkalde en bestemt aktivitet på vegne af klienten. En klient kan få adgang til webservicen gennem brug af internetstandarder.
Byggeklodser til webservices
Følgende grafik viser de centrale byggesten, der er nødvendige for at muliggøre fjernkommunikation mellem to applikationer.
Lad os diskutere formålet med hver af disse byggesten. Da mange læsere er fortrolige med DCOM, vil jeg også nævne DCOM-ækvivalenten for hver byggesten.
- Opdagelse Den klientapplikation, der har brug for adgang til en webtjenestes funktionalitet, skal kunne finde frem til fjerntjenestens placering. Dette opnås gennem en proces, der generelt kaldes opdagelse. Opdagelse kan gøres lettere via en central mappe såvel som ved mere ad hoc-metoder. I DCOM leverer Service Control Manager (SCM) opdagelsestjenester.
- Beskrivelse Når slutpunktet for en bestemt webtjeneste er fundet, har klienten brug for tilstrækkelig information til at kunne interagere korrekt med den. Beskrivelsen af en webtjeneste omfatter strukturerede metadata om den grænseflade, der er beregnet til at blive brugt af en klientapplikation, samt skriftlig dokumentation om webtjenesten, herunder eksempler på brug. En DCOM-komponent udstiller strukturerede metadata om sine grænseflader via et typebibliotek (typelib). Metadataene i en komponents typelib gemmes i et proprietært binært format og tilgås via en proprietær programmeringsgrænseflade (API).
- Beskedens format For at kunne udveksle data skal en klient og en server blive enige om en fælles måde at kode og formatere meddelelserne på. En standardiseret måde at kode data på sikrer, at data, der er kodet af klienten, bliver fortolket korrekt af serveren. I DCOM formateres meddelelser, der sendes mellem en klient og en server, som defineret i DCOM Object RPC (ORPC)-protokollen.
Uden en standardiseret måde at formatere meddelelserne på er det næsten umuligt at udvikle et værktøjssæt, der abstraherer udvikleren fra de underliggende protokoller. Ved at skabe et abstraktionslag mellem udvikleren og de underliggende protokoller kan udvikleren fokusere mere på det aktuelle forretningsproblem og mindre på den infrastruktur, der kræves for at implementere løsningen.
- Kodning De data, der sendes mellem klienten og serveren, skal kodes i meddelelsens brødtekst. DCOM bruger et binært kodningsskema til at serialisere de data, der er indeholdt i de parametre, der udveksles mellem klienten og serveren.
- Transport Når meddelelsen er blevet formateret, og dataene er blevet serialiseret i meddelelsens brødtekst, skal meddelelsen overføres mellem klienten og serveren via en transportprotokol. DCOM understøtter en række proprietære protokoller, der er bundet til en række netværksprotokoller som TCP, SPX, NetBEUI og NetBIOS over IPX.
Beslutninger om design af webtjenester
Lad os diskutere nogle af de designbeslutninger, der ligger bag disse byggesten til webtjenester.
Valg af transportprotokoller
Det første skridt var at fastlægge, hvordan klienten og serveren skulle kommunikere med hinanden. Klienten og serveren kan befinde sig på det samme LAN, men klienten kan potentielt også kommunikere med serveren via internettet. Derfor skal transportprotokollen være lige så velegnet til LAN-miljøer som til internettet.
Som jeg nævnte tidligere, er teknologier som DCOM, CORBA og Java RMI dårligt egnet til at understøtte kommunikation mellem klienten og serveren via internettet. Protokoller som Hypertext Transfer Protocol (HTTP) og Simple Mail Transfer Protocol (SMTP) er gennemprøvede internetprotokoller. HTTP definerer et anmodnings-/svar-kommunikationsmønster til at sende en anmodning og modtage et tilhørende svar. SMTP definerer en routbar meddelelsesprotokol til asynkron kommunikation. Lad os se nærmere på, hvorfor HTTP og SMTP er velegnede til internettet.
HTTP-baserede webapplikationer er i sagens natur stateless. De er ikke afhængige af en kontinuerlig forbindelse mellem klienten og serveren. Dette gør HTTP til en ideel protokol til konfigurationer med høj tilgængelighed, såsom firewalls. Hvis den server, der behandlede klientens oprindelige anmodning, bliver utilgængelig, kan efterfølgende anmodninger automatisk omdirigeres til en anden server, uden at klienten bemærker det eller tænker over det.
Næsten alle virksomheder har en infrastruktur, der understøtter SMTP. SMTP er velegnet til asynkron kommunikation. Hvis tjenesten afbrydes, sørger e-mail-infrastrukturen automatisk for at gentage forsøgene. I modsætning til HTTP kan man videresende SMTP-beskeder til en lokal mailserver, som vil forsøge at levere e-mailen på ens vegne.
Den anden væsentlige fordel ved både HTTP og SMTP er deres udbredelse. Medarbejderne er kommet til at stole på både e-mail og deres webbrowsere, og netværksadministratorer føler sig meget trygge ved at understøtte disse tjenester. Teknologier som Network Address Translation (NAT) og proxyservere giver mulighed for at få adgang til internettet via HTTP fra ellers isolerede virksomheds-LAN'er. Administratorer vil ofte stille en SMTP-server til rådighed, der befinder sig inden for firewallen. Beskeder, der sendes til denne server, vil derefter blive videresendt til deres endelige destination via internettet.
Når det drejer sig om software til kreditkortbehandling, er der behov for et øjeblikkeligt svar fra forretningsbanken for at afgøre, om ordren skal sendes videre til ERP-systemet. HTTP, med sit mønster af anmodnings- og svarmeddelelser, er velegnet til denne opgave.
De fleste ERP-softwarepakker er ikke i stand til at håndtere store ordremængder, som potentielt kan stamme fra e-handelsapplikationen. Desuden er det ikke absolut nødvendigt, at ordrerne sendes til ERP-systemet i realtid. Derfor kan SMTP udnyttes til at sætte ordrer i kø, så de kan behandles sekventielt af ERP-systemet.
Hvis ERP-systemet understøtter distribuerede transaktioner, er en anden mulighed at benytte Microsoft Message Queue Server (MSMQ). Så længe e-handelsapplikationen og ERP-systemet befinder sig på det samme LAN, er forbindelsen via protokoller, der ikke er baseret på internettet, ikke noget stort problem. Fordelen ved MSMQ i forhold til SMTP er, at meddelelser kan placeres i og fjernes fra køen inden for rammerne af en transaktion. Hvis et forsøg på at behandle en meddelelse, der er hentet fra køen, mislykkes, placeres meddelelsen automatisk tilbage i køen, når transaktionen afbrydes.
Valg af kodningsskema
HTTP og SMTP giver mulighed for at sende data mellem klienten og serveren. Ingen af dem angiver dog, hvordan dataene i meddelelsens brødtekst skal kodes. Microsoft havde brug for en standardiseret, platformsuafhængig metode til at kode de data, der udveksles mellem klienten og serveren.
Da målet var at udnytte internetbaserede protokoller, var Extensible Markup Language (XML) det oplagte valg. XML byder på mange fordele, herunder platformsuafhængig understøttelse, et fælles typesystem og understøttelse af tegnsæt, der er standard i branchen.
Binære kodningssystemer, såsom dem der anvendes af DCOM, CORBA og Java RMI, skal tage højde for kompatibilitetsproblemer mellem forskellige hardwareplatforme. Forskellige hardwareplatforme har for eksempel forskellige interne binære repræsentationer af multibyte-tal. Intel-platforme ordner byterne i et multibyte-tal efter little-endian-konventionen, mens mange RISC-processorer ordner byterne i et multibyte-tal efter big-endian-konventionen.
XML undgår problemer med binær kodning, da det anvender et tekstbaseret kodningssystem, der bygger på standardtegnsæt. Desuden kan visse transportprotokoller, såsom SMTP, kun indeholde tekstbaserede meddelelser.
Binære kodningsmetoder, såsom dem der anvendes af DCOM og CORBA, er besværlige og kræver en understøttende infrastruktur for at skærme udvikleren fra detaljerne. XML er langt mere letvægtig og nemmere at håndtere, fordi det kan oprettes og bruges ved hjælp af standardteknikker til tekstanalyse.
Derudover findes der en række forskellige XML-parsere, der yderligere forenkler oprettelsen og brugen af XML-dokumenter på stort set alle moderne platforme. XML er letvægtigt og har fremragende værktøjsunderstøttelse, så XML-kodning giver en utrolig bred rækkevidde, da stort set enhver klient på enhver platform kan kommunikere med din webservice.
Valg af formateringsstandard
Det er ofte nødvendigt at medtage yderligere metadata sammen med meddelelsens hovedtekst. Man kan f.eks. ønske at medtage oplysninger om, hvilke typer tjenester en webservice skal levere for at imødekomme ens anmodning, såsom deltagelse i en transaktion eller routingoplysninger. XML indeholder ingen mekanisme til at skelne mellem meddelelsens hovedtekst og de tilknyttede data.
Transportprotokoller som HTTP tilbyder en udvidelig mekanisme til header-data, men visse data knyttet til meddelelsen er muligvis ikke specifikke for transportprotokollen. For eksempel kan klienten sende en meddelelse, der skal videresendes til flere destinationer, eventuelt via forskellige transportprotokoller. Hvis routingoplysningerne blev placeret i en HTTP-header, ville de skulle oversættes, før de blev sendt til den næste mellemstation via en anden transportprotokol, såsom SMTP. Da routingoplysningerne er specifikke for meddelelsen og ikke for transportprotokollen, bør de være en del af selve meddelelsen.
Simple Object Access Protocol (SOAP) tilbyder en protokoluafhængig metode til at knytte headeroplysninger til meddelelsens brødtekst. Hver SOAP-meddelelse skal definere en konvolut. Konvolutten har en brødtekst, der indeholder meddelelsens nyttelast, og en header, der kan indeholde metadata knyttet til meddelelsen.
SOAP stiller ingen krav til, hvordan meddelelsens indhold skal formateres. Dette kan være et problem, da det uden en ensartet måde at kode dataene på er vanskeligt at udvikle et værktøjssæt, der abstraherer brugeren fra de underliggende protokoller. Du risikerer at skulle bruge en del tid på at sætte dig ind i webservicens grænseflade i stedet for at løse det aktuelle forretningsproblem.
Der var behov for en standardmetode til formatering af en RPC-meddelelse (Remote Procedure Call) og kodning af dens parameterliste. Det er netop det, afsnit 7 i SOAP-specifikationen omhandler. Her beskrives en standardnavngivningskonvention og en standardkodningsmetode for procedureorienterede meddelelser.
Da SOAP tilbyder et standardformat til serialisering af data til en XML-meddelelse, kan platforme som ASP.NET og Remoting håndtere detaljerne for dig.
Valg af beskrivelsesmekanismer
SOAP tilbyder en standardmetode til formatering af meddelelser, der udveksles mellem webservicen og klienten. Klienten har dog brug for yderligere oplysninger for at kunne serialisere anmodningen korrekt og fortolke svaret. XML-skema giver mulighed for at oprette skemaer, der kan bruges til at beskrive indholdet af en meddelelse.
XML Schema indeholder et sæt indbyggede datatyper, der kan bruges til at beskrive indholdet af en besked. Du kan også oprette dine egne datatyper. For eksempel kan handelsbanken oprette en kompleks datatype til at beskrive indholdet og strukturen i brødteksten af en besked, der bruges til at indsende en anmodning om kreditkortbetaling.
Et skema indeholder en række definitioner af datatyper og elementer. En webservice bruger skemaet ikke kun til at angive, hvilken type data der forventes at være i en besked, men også til at validere indgående og udgående beskeder.
Et skema alene giver dog ikke tilstrækkelige oplysninger til effektivt at beskrive en webservice. Skemaet beskriver ikke meddelelsesmønstrene mellem klienten og serveren. En klient skal for eksempel vide, om den kan forvente et svar, når en ordre indsendes til ERP-systemet. En klient skal også vide, via hvilken transportprotokol webservicen forventer at modtage anmodninger. Endelig skal klienten kende adressen, hvor webservicen kan nås.
Disse oplysninger leveres via et WSDL-dokument (Web Services Description Language). WSDL er et XML-dokument, der indeholder en fuldstændig beskrivelse af en bestemt webservice. Værktøjer som f.eks. ASP.NET WSDL.exe og Remoting SOAPSUDS.exe kan læse WSDL-dokumenter og automatisk oprette proxyer til udvikleren.
Ligesom alle andre komponenter, der bruges til at udvikle software, bør en webservice også ledsages af skriftlig dokumentation til de udviklere, der programmerer med udgangspunkt i webservicen. Dokumentationen bør beskrive, hvad webservicen gør, hvilke grænseflader den stiller til rådighed, samt give nogle eksempler på, hvordan den bruges. God dokumentation er især vigtig, hvis webservicen stilles til rådighed for klienter via internettet.
Valg af opdagelsesmekanismer
Når du har udviklet og dokumenteret en webservice, hvordan kan potentielle kunder så finde den? Hvis webservicen er beregnet til at blive brugt af et medlem af dit udviklingsteam, kan du nøjes med en ret uformel fremgangsmåde, f.eks. ved at dele URL’en til WSDL-dokumentet med din kollega et par skriveborde længere nede. Men når potentielle kunder befinder sig på internettet, er det en helt anden sag at markedsføre din webservice effektivt.
Der er brug for en fælles metode til at annoncere webtjenester. Universal Description, Discovery, and Integration (UDDI) tilbyder netop en sådan mekanisme. UDDI er en centraliseret katalogtjeneste, der er baseret på en industristandard, og som kan bruges til at annoncere og finde webtjenester. UDDI giver brugerne mulighed for at søge efter webtjenester ved hjælp af en række søgekriterier, herunder firmanavn, kategori og type webtjeneste.
Webtjenester kan også annonceres via DISCO, et proprietært XML-dokumentformat defineret af Microsoft, som gør det muligt for websteder at annoncere de tjenester, de stiller til rådighed. DISCO definerer en enkel protokol, der muliggør en hyperlink-lignende metode til at finde ressourcer. Den primære bruger af DISCO er Microsoft Visual Studio.NET. En udvikler kan målrette mod en bestemt webserver og navigere gennem de forskellige webservices, som serveren stiller til rådighed.
Hvad mangler der ved webservices?
Du har måske bemærket, at nogle centrale elementer i en infrastruktur med distribuerede komponenter ikke er defineret af webservices. To af de mest iøjnefaldende mangler er et veldefineret API til oprettelse og brug af webservices samt et sæt komponenttjenester, såsom understøttelse af distribuerede transaktioner. Lad os se nærmere på hver af disse manglende elementer.
- Webtjenestespecifik API De fleste infrastrukturer med distribuerede komponenter definerer et API til at udføre opgaver som f.eks. at initialisere kørselstiden, oprette en instans af en komponent og afspejle de metadata, der bruges til at beskrive komponenten. Da de fleste højniveauprogrammeringssprog tilbyder en vis grad af interoperabilitet med C, eksponeres API’et som regel som et fladt sæt af C-metodesignaturer. RMI går så langt som til at koble sit API tæt sammen med et enkelt højniveausprog, nemlig Java.
For at sikre, at webservices er uafhængige af programmeringssprog, har Microsoft overladt det til de enkelte softwareudbydere at knytte understøttelsen af webservices til en bestemt platform. Senere i bogen vil jeg gennemgå to implementeringer af webservices til .NET-platformen, nemlig ASP.NET og Remoting.
- Komponenttjenester Webtjenesteplatformen tilbyder ikke mange af de tjenester, der normalt findes i infrastrukturer med distribuerede komponenter, såsom styring af fjernobjekters levetid, objektpooling og understøttelse af distribuerede transaktioner. Det er op til infrastrukturen med distribuerede komponenter at implementere disse tjenester.
Nogle tjenester, såsom understøttelse af distribuerede transaktioner, kan indføres senere, efterhånden som teknologien modnes. Andre, såsom objektpooling og muligvis styring af objekters levetid, kan betragtes som en implementeringsdetalje i platformen. For eksempel definerer Remoting udvidelser, der giver mulighed for styring af objekters levetid, og Microsoft Component Services understøtter objektpooling.
Resumé
Komponentbaseret programmering har vist sig at være en stor fordel for udviklernes produktivitet, men visse tjenester kan ikke indkapsles i en komponent, der befinder sig i klientens datacenter. Ældre teknologier som DCOM, CORBA og Java RMI er uegnede til at give klienter adgang til tjenester via internettet, så Microsoft fandt det nødvendigt at starte fra bunden og udvikle en industristandard for adgang til fjernbetjente tjenester.
Webtjenester er et samlebegreb, der beskriver en samling af branchestandardprotokoller og -tjenester, der anvendes til at sikre et grundlæggende niveau af interoperabilitet mellem applikationer. Den opbakning, som webtjenester har fået fra branchen, er uden fortilfælde. Aldrig før har så mange førende teknologivirksomheder gået sammen om at støtte en standard, der fremmer interoperabilitet mellem applikationer, uanset hvilken platform de kører på.
En af de faktorer, der bidrager til webservicernes succes, er, at de bygger på eksisterende internetstandarder såsom XML og HTTP. Det betyder, at ethvert system, der kan fortolke tekst og kommunikere via en standard internettransportprotokol, kan kommunikere med en webservice. Virksomhederne kan desuden udnytte de investeringer, de allerede har foretaget i disse teknologier.