Översikt
Komponentbaserad programmering har blivit mer populärt än någonsin. Det finns knappt en applikation som byggs idag som inte innehåller komponenter i någon form, vanligtvis från olika leverantörer. I takt med att applikationerna har blivit mer sofistikerade har också behovet av att utnyttja komponenter som distribueras på fjärrmaskiner ökat.
Ett exempel på en komponentbaserad applikation är en end-to-end-lösning för e-handel. En e-handelsapplikation som finns på en webbfarm måste skicka order till en back-end ERP-applikation (Enterprise Resource Planning). I många fall finns ERP-applikationen på en annan maskinvara och körs kanske på ett annat operativsystem.
Microsoft Distributed Component Object Model (DCOM), en infrastruktur för distribuerade objekt som gör det möjligt för ett program att anropa COM-komponenter (Component Object Model) som är installerade på en annan server, har portats till ett antal icke-Windows-plattformar. DCOM har dock aldrig fått någon bred acceptans på dessa plattformar och används därför sällan för att underlätta kommunikationen mellan Windows- och icke-Windows-datorer. Leverantörer av ERP-programvaror skapar ofta komponenter för Windows-plattformen som kommunicerar med back-end-systemet via ett proprietärt protokoll.
Vissa tjänster som utnyttjas av en e-handelsapplikation kanske inte alls finns i datacentret. Om e-handelsapplikationen t.ex. accepterar kreditkortsbetalning för varor som kunden köper, måste den anlita handelsbanken för att behandla kundens kreditkortsinformation. Men i praktiken är DCOM och relaterade tekniker som CORBA och Java RMI begränsade till applikationer och komponenter som är installerade i företagets datacenter. De två främsta orsakerna till detta är att dessa tekniker som standard utnyttjar proprietära protokoll och att dessa protokoll är anslutningsorienterade.
Klienter som kommunicerar med servern via Internet möter många potentiella hinder för att kommunicera med servern. Säkerhetsmedvetna nätverksadministratörer över hela världen har implementerat företagsroutrar och brandväggar för att förhindra praktiskt taget alla typer av kommunikation över Internet. Det krävs ofta en gudomlig handling för att få en nätverksadministratör att öppna portar utöver det absoluta minimum.
Om du har turen att få en nätverksadministratör att öppna upp lämpliga portar för att stödja din tjänst, är chansen stor att dina kunder inte har samma tur. Som ett resultat är proprietära protokoll som de som används av DCOM, CORBA och Java RMI inte praktiska för Internet-scenarier.
Det andra problemet med dessa tekniker är som sagt att de till sin natur är anslutningsorienterade och därför inte kan hantera nätverksavbrott på ett elegant sätt. Eftersom Internet inte står under din direkta kontroll kan du inte göra några antaganden om anslutningens kvalitet eller tillförlitlighet. Om ett nätverksavbrott inträffar kan nästa anrop som klienten gör till servern misslyckas.
Den anslutningsorienterade karaktären hos dessa tekniker gör det också svårt att bygga de lastbalanserade infrastrukturer som krävs för att uppnå hög skalbarhet. När förbindelsen mellan klienten och servern bryts kan man inte bara dirigera nästa förfrågan till en annan server.
Utvecklare har försökt att övervinna dessa begränsningar genom att utnyttja en modell som kallas statslös programmering, men de har haft begränsad framgång eftersom tekniken är ganska tung och gör det dyrt att återupprätta en förbindelse med ett avlägset objekt.
Eftersom behandlingen av en kunds kreditkort sker på en fjärrserver på Internet är DCOM inte idealiskt för att underlätta kommunikationen mellan e-handelsklienten och servern för kreditkortsbehandling. Precis som i en ERP-lösning installeras ofta en tredjepartskomponent i kundens datacenter (i det här fallet av leverantören av lösningen för kreditkortsbehandling). Denna komponent fungerar som lite mer än en proxy som underlättar kommunikationen mellan e-handelsprogramvaran och affärsbanken via ett proprietärt protokoll.
Ser du något mönster här? På grund av den befintliga teknikens begränsningar när det gäller att underlätta kommunikationen mellan datorsystem har programvaruleverantörerna ofta tvingats bygga sin egen infrastruktur. Det innebär att resurser som kunde ha använts för att lägga till förbättrad funktionalitet i affärssystemet eller kreditkortsystemet istället har använts för att skriva egna nätverksprotokoll.
I ett försök att bättre stödja sådana Internetscenarier antog Microsoft ursprungligen strategin att utöka sina befintliga tekniker, inklusive COM Internet Services (CIS), som gör det möjligt att upprätta en DCOM-anslutning mellan klienten och fjärrkomponenten över port 80. Av olika skäl blev CIS inte allmänt accepterat.
Det stod klart att det behövdes ett nytt angreppssätt. Så Microsoft bestämde sig för att ta itu med problemet från botten och upp. Låt oss titta på några av de krav som lösningen var tvungen att uppfylla för att lyckas.
- Interoperabilitet Fjärrtjänsten måste kunna användas av klienter på andra plattformar.
- Internetvänlighet Lösningen bör fungera bra för att stödja klienter som får åtkomst till fjärrtjänsten från Internet.
- Starkt typade gränssnitt Det bör inte råda någon oklarhet om vilken typ av data som skickas till och tas emot från en fjärrtjänst. Dessutom bör de datatyper som definieras av fjärrtjänsten stämma någorlunda väl överens med de datatyper som definieras av de flesta procedurella programmeringsspråk.
- Möjlighet att utnyttja befintliga Internet-standarder Implementeringen av fjärrtjänsten bör utnyttja befintliga Internetstandarder så mycket som möjligt och undvika att uppfinna nya lösningar på problem som redan har lösts. En lösning som bygger på allmänt vedertagna Internetstandarder kan utnyttja befintliga verktyg och produkter som skapats för tekniken.
- Stöd för alla språk Lösningen bör inte vara tätt kopplad till ett visst programmeringsspråk. Java RMI, till exempel, är tätt kopplat till Java-språket. Det skulle vara svårt att anropa funktionalitet på ett fjärranslutet Java-objekt från Visual Basic eller Perl. En klient ska kunna implementera en ny webbtjänst eller använda en befintlig webbtjänst oavsett vilket programmeringsspråk klienten är skriven i.
- Stöd för alla typer av infrastrukturer med distribuerade komponenter Lösningen bör inte vara tätt kopplad till en viss komponentinfrastruktur. Faktum är att du inte ska behöva köpa, installera eller underhålla en infrastruktur för distribuerade objekt bara för att bygga en ny fjärrtjänst eller konsumera en befintlig tjänst. De underliggande protokollen bör underlätta en basnivå för kommunikation mellan befintliga infrastrukturer för distribuerade objekt, t.ex. DCOM och CORBA.
Med tanke på titeln på denna bok borde det inte komma som någon överraskning att den lösning som Microsoft skapade är känd som Webbtjänster. En webbtjänst tillhandahåller ett gränssnitt för att anropa en viss aktivitet för klientens räkning. En klient kan få tillgång till webbtjänsten genom att använda Internetstandarder.
Byggstenar för webbtjänster
Följande bild visar de viktigaste byggstenarna som behövs för att underlätta fjärrkommunikation mellan två applikationer.
Låt oss diskutera syftet med var och en av dessa byggstenar. Eftersom många läsare är bekanta med DCOM kommer jag också att nämna DCOM-ekvivalenten för varje byggsten.
- Upptäckt En klientapplikation som behöver tillgång till funktionalitet som exponeras av en webbtjänst behöver ett sätt att hitta fjärrtjänstens plats. Detta åstadkoms genom en process som allmänt kallas Upptäckt. Sökningen kan underlättas via en centraliserad katalog eller genom mer ad hoc-betonade metoder. I DCOM tillhandahåller Service Control Manager (SCM) tjänster för identifiering.
- Beskrivning När slutpunkten för en viss webbtjänst har bestämts behöver klienten tillräcklig information för att kunna interagera med den på rätt sätt. Beskrivningen av en webbtjänst omfattar strukturerade metadata om det gränssnitt som är avsett att användas av en klientapplikation samt skriftlig dokumentation om webbtjänsten inklusive exempel på användning. En DCOM-komponent exponerar strukturerad metadata om sina gränssnitt via ett typbibliotek (typelib). Metadata i en komponents typelib lagras i ett proprietärt binärt format och nås via ett proprietärt API (Application Programming Interface).
- Meddelandeformat För att kunna utbyta data måste en klient och en server komma överens om ett gemensamt sätt att koda och formatera meddelandena. Ett standardiserat sätt att koda data säkerställer att data som kodas av klienten tolkas på rätt sätt av servern. I DCOM formateras meddelanden som skickas mellan en klient och en server enligt definitionen i DCOM Object RPC (ORPC)-protokollet.
Utan ett standardiserat sätt att formatera meddelandena är det nästan omöjligt att utveckla en verktygslåda som abstraherar utvecklaren från de underliggande protokollen. Genom att skapa ett abstraktionslager mellan utvecklaren och de underliggande protokollen kan utvecklaren fokusera mer på det aktuella affärsproblemet och mindre på den infrastruktur som krävs för att implementera lösningen.
- Kodning De data som överförs mellan klienten och servern måste kodas in i meddelandetexten. DCOM använder ett binärt kodningsschema för att serialisera de data som finns i de parametrar som utväxlas mellan klienten och servern.
- Transport När meddelandet har formaterats och data har serialiserats i meddelandets kropp måste meddelandet överföras mellan klienten och servern via något transportprotokoll. DCOM stöder ett antal proprietära protokoll som är bundna till ett antal nätverksprotokoll, t.ex. TCP, SPX, NetBEUI och NetBIOS över IPX.
Beslut om design av webbtjänster
Låt oss diskutera några av de designbeslut som ligger bakom dessa byggstenar för webbtjänster.
Välja transportprotokoll
Det första steget var att bestämma hur klienten och servern skulle kommunicera med varandra. Klienten och servern kan befinna sig på samma LAN, men klienten kan potentiellt kommunicera med servern över Internet. Därför måste transportprotokollet vara lika lämpat för LAN-miljöer som för Internet.
Som jag nämnde tidigare är tekniker som DCOM, CORBA och Java RMI väl lämpade för att stödja kommunikation mellan klient och server över Internet. Protokoll som Hypertext Transfer Protocol (HTTP) och Simple Mail Transfer Protocol (SMTP) är beprövade Internetprotokoll. HTTP definierar ett begäran/svar-meddelandemönster för att skicka en begäran och få ett tillhörande svar. SMTP definierar ett routningsbart meddelandeprotokoll för asynkron kommunikation. Låt oss undersöka varför HTTP och SMTP är väl lämpade för Internet.
HTTP-baserade webbapplikationer är till sin natur statslösa. De förlitar sig inte på en kontinuerlig anslutning mellan klienten och servern. Detta gör HTTP till ett idealiskt protokoll för konfigurationer med hög tillgänglighet, t.ex. brandväggar. Om den server som hanterade klientens ursprungliga begäran blir otillgänglig kan efterföljande förfrågningar automatiskt dirigeras till en annan server utan att klienten vet om det eller bryr sig.
Nästan alla företag har en infrastruktur på plats som stöder SMTP. SMTP lämpar sig väl för asynkron kommunikation. Om tjänsten störs hanterar e-postinfrastrukturen automatiskt omförsök. Till skillnad från HTTP kan du skicka SMTP-meddelanden till en lokal e-postserver som försöker leverera e-postmeddelandet för din räkning.
Den andra stora fördelen med både HTTP och SMTP är deras genomslagskraft. Medarbetarna har lärt sig att förlita sig på både e-post och webbläsare, och nätverksadministratörerna har en hög komfortnivå när det gäller att stödja dessa tjänster. Tekniker som NAT (Network Address Translation) och proxyservrar gör det möjligt att komma åt Internet via HTTP från annars isolerade LAN. Administratörer exponerar ofta en SMTP-server som finns innanför brandväggen. Meddelanden som skickas till denna server dirigeras sedan till sin slutdestination via Internet.
När det gäller programvara för kreditkortsbehandling krävs ett omedelbart svar från handelsbanken för att avgöra om ordern ska skickas till affärssystemet. HTTP, med sitt request/response-meddelandemönster, är väl lämpat för denna uppgift.
De flesta affärssystem klarar inte av att hantera de stora ordervolymer som potentiellt kan komma från e-handelsapplikationen. Dessutom är det inte absolut nödvändigt att beställningarna skickas till affärssystemet i realtid. Därför kan SMTP utnyttjas för att ställa order i kö så att de kan behandlas seriellt av affärssystemet.
Om affärssystemet stöder distribuerade transaktioner är ett annat alternativ att använda Microsoft Message Queue Server (MSMQ). Så länge e-handelsapplikationen och affärssystemet finns inom samma LAN är anslutning via protokoll som inte är Internetprotokoll ett mindre problem. Fördelen med MSMQ jämfört med SMTP är att meddelanden kan placeras i och tas bort från kön inom ramen för en transaktion. Om ett försök att bearbeta ett meddelande som har tagits bort från kön misslyckas, placeras meddelandet automatiskt tillbaka i kön när transaktionen avbryts.
Att välja ett kodningssystem
HTTP och SMTP gör det möjligt att skicka data mellan klienten och servern. Ingen av dem specificerar dock hur data i meddelandetexten ska kodas. Microsoft behövde ett standardiserat, plattformsneutralt sätt att koda data som utväxlas mellan klienten och servern.
Eftersom målet var att utnyttja Internetbaserade protokoll var XML (Extensible Markup Language) det naturliga valet. XML erbjuder många fördelar, bland annat stöd för flera plattformar, ett gemensamt typsystem och stöd för teckenuppsättningar enligt branschstandard.
Binära kodningssystem som de som används av DCOM, CORBA och Java RMI måste hantera kompatibilitetsproblem mellan olika maskinvaruplattformar. Olika maskinvaruplattformar har t.ex. olika intern binär representation av flerbytesnummer. Intel-plattformar ordnar bytena i ett multibyte-tal med hjälp av Little Endian-konventionen, medan många RISC-processorer ordnar bytena i ett multibyte-tal med hjälp av Big Endian-konventionen.
XML undviker problem med binär kodning eftersom det använder ett textbaserat kodningsschema som utnyttjar standardiserade teckenuppsättningar. Dessutom kan vissa transportprotokoll, t.ex. SMTP, endast innehålla textbaserade meddelanden.
Binära metoder för kodning, som de som används av DCOM och CORBA, är besvärliga och kräver en stödjande infrastruktur för att abstrahera utvecklaren från detaljerna. XML är mycket lättare och enklare att hantera eftersom det kan skapas och konsumeras med hjälp av standardtekniker för textavläsning.
Dessutom finns det en mängd olika XML-parsers som ytterligare förenklar skapandet och användningen av XML-dokument på praktiskt taget alla moderna plattformar. XML är lättviktigt och har ett utmärkt verktygsstöd, så XML-kodning ger en otrolig räckvidd eftersom praktiskt taget alla klienter på alla plattformar kan kommunicera med din webbtjänst.
Välja en formateringskonvention
Det är ofta nödvändigt att inkludera ytterligare metadata i meddelandetexten. Du kanske t.ex. vill inkludera information om vilken typ av tjänster som en webbtjänst behöver tillhandahålla för att kunna uppfylla din begäran, t.ex. att delta i en transaktion eller routinginformation. XML tillhandahåller ingen mekanism för att skilja mellan meddelandetexten och dess associerade data.
Transportprotokoll som HTTP tillhandahåller en utbyggbar mekanism för rubrikdata, men vissa data som är kopplade till meddelandet kanske inte är specifika för transportprotokollet. Klienten kan t.ex. skicka ett meddelande som måste dirigeras till flera destinationer, eventuellt via olika transportprotokoll. Om routningsinformationen placerades i en HTTP-header skulle den behöva översättas innan den skickas till nästa mellanhand via ett annat transportprotokoll, t.ex. SMTP. Eftersom routningsinformationen är specifik för meddelandet och inte för transportprotokollet, bör den vara en del av meddelandet.
Simple Object Access Protocol (SOAP) är ett protokolloberoende sätt att associera rubrikinformation med meddelandetexten. Varje SOAP-meddelande måste definiera ett kuvert. Kuvertet har en kropp som innehåller meddelandets nyttolast och ett huvud som kan innehålla metadata som är associerade med meddelandet.
SOAP innehåller inga restriktioner för hur meddelandetexten kan formateras. Detta är ett potentiellt problem eftersom det utan ett konsekvent sätt att koda data är svårt att utveckla en verktygslåda som abstraherar dig från de underliggande protokollen. Du kan behöva ägna en hel del tid åt att sätta dig in i webbtjänstens gränssnitt istället för att lösa det aktuella affärsproblemet.
Vad som behövdes var ett standardiserat sätt att formatera ett RPC-meddelande (Remote Procedure Call) och att koda dess parameterlista. Detta är precis vad avsnitt 7 i SOAP-specifikationen tillhandahåller. Där beskrivs en standardiserad namngivningskonvention och kodningsstil för procedurorienterade meddelanden.
Eftersom SOAP tillhandahåller ett standardformat för serialisering av data i ett XML-meddelande kan plattformar som ASP.NET och Remoting abstrahera bort detaljerna åt dig.
Val av beskrivningsmekanismer
SOAP tillhandahåller ett standardiserat sätt att formatera meddelanden som utväxlas mellan webbtjänsten och klienten. Klienten behöver dock ytterligare information för att kunna serialisera begäran och tolka svaret på rätt sätt. XML Schema gör det möjligt att skapa scheman som kan användas för att beskriva innehållet i ett meddelande.
XML Schema tillhandahåller en grundläggande uppsättning inbyggda datatyper som kan användas för att beskriva innehållet i ett meddelande. Du kan också skapa dina egna datatyper. Handelsbanken kan t.ex. skapa en komplex datatyp för att beskriva innehållet och strukturen i meddelandetexten i ett meddelande som används för att skicka en begäran om kreditkortsbetalning.
Ett schema innehåller en uppsättning datatyp- och elementdefinitioner. En webbtjänst använder schemat inte bara för att kommunicera vilken typ av data som förväntas finnas i ett meddelande utan också för att validera inkommande och utgående meddelanden.
Ett schema i sig ger dock inte tillräckligt med information för att effektivt beskriva en webbtjänst. Schemat beskriver inte meddelandemönstren mellan klienten och servern. En klient måste t.ex. veta om den kan förvänta sig ett svar när en order läggs in i affärssystemet. En klient behöver också veta via vilket transportprotokoll webbtjänsten förväntar sig att ta emot förfrågningar. Slutligen måste klienten känna till den adress där webbtjänsten kan nås.
Denna information tillhandahålls av ett WSDL-dokument (Web Services Description Language). WSDL är ett XML-dokument som ger en fullständig beskrivning av en viss webbtjänst. Verktyg som ASP.NET WSDL.exe och Remoting SOAPSUDS.exe kan konsumera WSDL och automatiskt bygga proxyer för utvecklaren.
Som med alla komponenter som används för att bygga programvara bör en webbtjänst också åtföljas av skriftlig dokumentation för utvecklare som programmerar mot webbtjänsten. Dokumentationen bör beskriva vad webbtjänsten gör, vilka gränssnitt den exponerar och några exempel på hur den kan användas. Bra dokumentation är särskilt viktigt om webbtjänsten exponeras för klienter över Internet.
Att välja upptäcktsmekanismer
När du har utvecklat och dokumenterat en webbtjänst, hur kan potentiella kunder hitta den? Om webbtjänsten är utformad för att användas av en medlem i ditt utvecklingsteam kan din strategi vara ganska informell, till exempel genom att dela webbadressen till WSDL-dokumentet med din kollega ett par bås bort. Men när potentiella kunder finns på Internet är det en helt annan sak att marknadsföra din webbtjänst på ett effektivt sätt.
Vad som behövs är ett gemensamt sätt att annonsera webbtjänster. UDDI (Universal Description, Discovery, and Integration) tillhandahåller just en sådan mekanism. UDDI är en branschstandardiserad centraliserad katalogtjänst som kan användas för att annonsera och lokalisera webbtjänster. UDDI gör det möjligt för användare att söka efter webbtjänster med hjälp av en mängd olika sökkriterier, t.ex. företagsnamn, kategori och typ av webbtjänst.
Webbtjänster kan också marknadsföras via DISCO, ett proprietärt XML-dokumentformat som definieras av Microsoft och som gör det möjligt för webbplatser att marknadsföra de tjänster de erbjuder. DISCO definierar ett enkelt protokoll för att underlätta en hyperlänkstil för att lokalisera resurser. Den primära användaren av DISCO är Microsoft Visual Studio.NET. En utvecklare kan rikta in sig på en viss webbserver och navigera genom de olika webbtjänster som servern erbjuder.
Vad saknas i Web Services?
Du kanske har lagt märke till att vissa viktiga delar av en infrastruktur för distribuerade komponenter inte definieras av webbtjänster. Två av de mer märkbara bristerna är ett väldefinierat API för att skapa och konsumera webbtjänster och en uppsättning komponenttjänster, till exempel stöd för distribuerade transaktioner. Låt oss diskutera var och en av dessa saknade delar.
- Webbtjänstspecifikt API De flesta distribuerade komponentinfrastrukturer definierar ett API för att utföra uppgifter som att initiera körtiden, skapa en instans av en komponent och återspegla de metadata som används för att beskriva komponenten. Eftersom de flesta högnivåprogrammeringsspråk erbjuder en viss grad av interoperabilitet med C, exponeras API:et vanligtvis som en platt uppsättning C-metodsignaturer. RMI går så långt att dess API är tätt kopplat till ett enda högnivåspråk, Java.
I ett försök att säkerställa att webbtjänster är programmeringsspråkagnostiska har Microsoft lämnat det upp till enskilda programvaruleverantörer att binda stöd för webbtjänster till en viss plattform. Jag kommer att diskutera två implementeringar av webbtjänster för .NET-plattformen, ASP.NET och Remoting, senare i boken.
- Komponenttjänster Webbtjänstplattformen tillhandahåller inte många av de tjänster som är vanliga i infrastrukturer för distribuerade komponenter, till exempel hantering av objektens livslängd på distans, objektpooler och stöd för distribuerade transaktioner. Dessa tjänster är upp till den distribuerade komponentinfrastrukturen att implementera.
Vissa tjänster, t.ex. stöd för distribuerade transaktioner, kan införas senare när tekniken mognar. Andra, t.ex. objektpoolning och eventuellt hantering av objektens livstid, kan betraktas som en implementeringsdetalj i plattformen. Remoting definierar t.ex. tillägg för att ge stöd för hantering av objekts livstid och Microsoft Component Services ger stöd för objektpoolning.
Sammanfattning
Komponentbaserad programmering har visat sig vara en välsignelse för utvecklarnas produktivitet, men vissa tjänster kan inte kapslas in av en komponent som finns i klientens datacenter. Äldre tekniker som DCOM, CORBA och Java RMI är dåligt lämpade för att ge klienter tillgång till tjänster över Internet, så Microsoft ansåg att det var nödvändigt att börja från början och bygga ett industristandardiserat sätt att få tillgång till fjärrtjänster.
Webbtjänster är ett paraplybegrepp som beskriver en samling industristandardiserade protokoll och tjänster som används för att underlätta en basnivå av interoperabilitet mellan applikationer. Det branschstöd som Web Services har fått saknar motstycke. Aldrig tidigare har så många ledande teknikföretag ställt upp för att stödja en standard som underlättar interoperabilitet mellan applikationer, oavsett vilken plattform de körs på.
En av de bidragande orsakerna till webbtjänsternas framgång är att de bygger på befintliga Internetstandarder som XML och HTTP. Det innebär att alla system som kan tolka text och kommunicera via ett standardiserat transportprotokoll på Internet kan kommunicera med en webbtjänst. Företagen kan också dra nytta av de investeringar som de redan har gjort i dessa tekniker.