\u00d6versikt<\/b>
\nKomponentbaserad programmering har blivit mer popul\u00e4rt \u00e4n n\u00e5gonsin. Det finns knappt en applikation som byggs idag som inte inneh\u00e5ller komponenter i n\u00e5gon form, vanligtvis fr\u00e5n olika leverant\u00f6rer. I takt med att applikationerna har blivit mer sofistikerade har ocks\u00e5 behovet av att utnyttja komponenter som distribueras p\u00e5 fj\u00e4rrmaskiner \u00f6kat.<\/p>\n
<\/p>\n
Ett exempel p\u00e5 en komponentbaserad applikation \u00e4r en end-to-end-l\u00f6sning f\u00f6r e-handel. En e-handelsapplikation som finns p\u00e5 en webbfarm m\u00e5ste skicka order till en back-end ERP-applikation (Enterprise Resource Planning). I m\u00e5nga fall finns ERP-applikationen p\u00e5 en annan maskinvara och k\u00f6rs kanske p\u00e5 ett annat operativsystem.<\/p>\n
Microsoft Distributed Component Object Model (DCOM), en infrastruktur f\u00f6r distribuerade objekt som g\u00f6r det m\u00f6jligt f\u00f6r ett program att anropa COM-komponenter (Component Object Model) som \u00e4r installerade p\u00e5 en annan server, har portats till ett antal icke-Windows-plattformar. DCOM har dock aldrig f\u00e5tt n\u00e5gon bred acceptans p\u00e5 dessa plattformar och anv\u00e4nds d\u00e4rf\u00f6r s\u00e4llan f\u00f6r att underl\u00e4tta kommunikationen mellan Windows- och icke-Windows-datorer. Leverant\u00f6rer av ERP-programvaror skapar ofta komponenter f\u00f6r Windows-plattformen som kommunicerar med back-end-systemet via ett propriet\u00e4rt protokoll.<\/p>\n
Vissa tj\u00e4nster som utnyttjas av en e-handelsapplikation kanske inte alls finns i datacentret. Om e-handelsapplikationen t.ex. accepterar kreditkortsbetalning f\u00f6r varor som kunden k\u00f6per, m\u00e5ste den anlita handelsbanken f\u00f6r att behandla kundens kreditkortsinformation. Men i praktiken \u00e4r DCOM och relaterade tekniker som CORBA och Java RMI begr\u00e4nsade till applikationer och komponenter som \u00e4r installerade i f\u00f6retagets datacenter. De tv\u00e5 fr\u00e4msta orsakerna till detta \u00e4r att dessa tekniker som standard utnyttjar propriet\u00e4ra protokoll och att dessa protokoll \u00e4r anslutningsorienterade.<\/p>\n
Klienter som kommunicerar med servern via Internet m\u00f6ter m\u00e5nga potentiella hinder f\u00f6r att kommunicera med servern. S\u00e4kerhetsmedvetna n\u00e4tverksadministrat\u00f6rer \u00f6ver hela v\u00e4rlden har implementerat f\u00f6retagsroutrar och brandv\u00e4ggar f\u00f6r att f\u00f6rhindra praktiskt taget alla typer av kommunikation \u00f6ver Internet. Det kr\u00e4vs ofta en gudomlig handling f\u00f6r att f\u00e5 en n\u00e4tverksadministrat\u00f6r att \u00f6ppna portar ut\u00f6ver det absoluta minimum.<\/p>\n
Om du har turen att f\u00e5 en n\u00e4tverksadministrat\u00f6r att \u00f6ppna upp l\u00e4mpliga portar f\u00f6r att st\u00f6dja din tj\u00e4nst, \u00e4r chansen stor att dina kunder inte har samma tur. Som ett resultat \u00e4r propriet\u00e4ra protokoll som de som anv\u00e4nds av DCOM, CORBA och Java RMI inte praktiska f\u00f6r Internet-scenarier.<\/p>\n
Det andra problemet med dessa tekniker \u00e4r som sagt att de till sin natur \u00e4r anslutningsorienterade och d\u00e4rf\u00f6r inte kan hantera n\u00e4tverksavbrott p\u00e5 ett elegant s\u00e4tt. Eftersom Internet inte st\u00e5r under din direkta kontroll kan du inte g\u00f6ra n\u00e5gra antaganden om anslutningens kvalitet eller tillf\u00f6rlitlighet. Om ett n\u00e4tverksavbrott intr\u00e4ffar kan n\u00e4sta anrop som klienten g\u00f6r till servern misslyckas.<\/p>\n
Den anslutningsorienterade karakt\u00e4ren hos dessa tekniker g\u00f6r det ocks\u00e5 sv\u00e5rt att bygga de lastbalanserade infrastrukturer som kr\u00e4vs f\u00f6r att uppn\u00e5 h\u00f6g skalbarhet. N\u00e4r f\u00f6rbindelsen mellan klienten och servern bryts kan man inte bara dirigera n\u00e4sta f\u00f6rfr\u00e5gan till en annan server.<\/p>\n
Utvecklare har f\u00f6rs\u00f6kt att \u00f6vervinna dessa begr\u00e4nsningar genom att utnyttja en modell som kallas statsl\u00f6s <\/i>programmering<\/i>, men de har haft begr\u00e4nsad framg\u00e5ng eftersom tekniken \u00e4r ganska tung och g\u00f6r det dyrt att \u00e5teruppr\u00e4tta en f\u00f6rbindelse med ett avl\u00e4gset objekt.<\/p>\n
Eftersom behandlingen av en kunds kreditkort sker p\u00e5 en fj\u00e4rrserver p\u00e5 Internet \u00e4r DCOM inte idealiskt f\u00f6r att underl\u00e4tta kommunikationen mellan e-handelsklienten och servern f\u00f6r kreditkortsbehandling. Precis som i en ERP-l\u00f6sning installeras ofta en tredjepartskomponent i kundens datacenter (i det h\u00e4r fallet av leverant\u00f6ren av l\u00f6sningen f\u00f6r kreditkortsbehandling). Denna komponent fungerar som lite mer \u00e4n en proxy som underl\u00e4ttar kommunikationen mellan e-handelsprogramvaran och aff\u00e4rsbanken via ett propriet\u00e4rt protokoll.<\/p>\n
Ser du n\u00e5got m\u00f6nster h\u00e4r? P\u00e5 grund av den befintliga teknikens begr\u00e4nsningar n\u00e4r det g\u00e4ller att underl\u00e4tta kommunikationen mellan datorsystem har programvaruleverant\u00f6rerna ofta tvingats bygga sin egen infrastruktur. Det inneb\u00e4r att resurser som kunde ha anv\u00e4nts f\u00f6r att l\u00e4gga till f\u00f6rb\u00e4ttrad funktionalitet i aff\u00e4rssystemet eller kreditkortsystemet ist\u00e4llet har anv\u00e4nts f\u00f6r att skriva egna n\u00e4tverksprotokoll.<\/p>\n
I ett f\u00f6rs\u00f6k att b\u00e4ttre st\u00f6dja s\u00e5dana Internetscenarier antog Microsoft ursprungligen strategin att ut\u00f6ka sina befintliga tekniker, inklusive COM Internet Services (CIS), som g\u00f6r det m\u00f6jligt att uppr\u00e4tta en DCOM-anslutning mellan klienten och fj\u00e4rrkomponenten \u00f6ver port 80. Av olika sk\u00e4l blev CIS inte allm\u00e4nt accepterat.<\/p>\n
Det stod klart att det beh\u00f6vdes ett nytt angreppss\u00e4tt. S\u00e5 Microsoft best\u00e4mde sig f\u00f6r att ta itu med problemet fr\u00e5n botten och upp. L\u00e5t oss titta p\u00e5 n\u00e5gra av de krav som l\u00f6sningen var tvungen att uppfylla f\u00f6r att lyckas.<\/p>\n
Med tanke p\u00e5 titeln p\u00e5 denna bok borde det inte komma som n\u00e5gon \u00f6verraskning att den l\u00f6sning som Microsoft skapade \u00e4r k\u00e4nd som Webbtj\u00e4nster<\/i>. En webbtj\u00e4nst tillhandah\u00e5ller ett gr\u00e4nssnitt f\u00f6r att anropa en viss aktivitet f\u00f6r klientens r\u00e4kning. En klient kan f\u00e5 tillg\u00e5ng till webbtj\u00e4nsten genom att anv\u00e4nda Internetstandarder.<\/p>\n
Byggstenar f\u00f6r webbtj\u00e4nster<\/b>
\nF\u00f6ljande bild visar de viktigaste byggstenarna som beh\u00f6vs f\u00f6r att underl\u00e4tta fj\u00e4rrkommunikation mellan tv\u00e5 applikationer.<\/p>\n
L\u00e5t oss diskutera syftet med var och en av dessa byggstenar. Eftersom m\u00e5nga l\u00e4sare \u00e4r bekanta med DCOM kommer jag ocks\u00e5 att n\u00e4mna DCOM-ekvivalenten f\u00f6r varje byggsten.<\/p>\n
Utan ett standardiserat s\u00e4tt att formatera meddelandena \u00e4r det n\u00e4stan om\u00f6jligt att utveckla en verktygsl\u00e5da som abstraherar utvecklaren fr\u00e5n de underliggande protokollen. Genom att skapa ett abstraktionslager mellan utvecklaren och de underliggande protokollen kan utvecklaren fokusera mer p\u00e5 det aktuella aff\u00e4rsproblemet och mindre p\u00e5 den infrastruktur som kr\u00e4vs f\u00f6r att implementera l\u00f6sningen.<\/p>\n
Beslut om design av webbtj\u00e4nster<\/b><\/p>\n
L\u00e5t oss diskutera n\u00e5gra av de designbeslut som ligger bakom dessa byggstenar f\u00f6r webbtj\u00e4nster.<\/p>\n
V\u00e4lja transportprotokoll<\/b><\/p>\n
Det f\u00f6rsta steget var att best\u00e4mma hur klienten och servern skulle kommunicera med varandra. Klienten och servern kan befinna sig p\u00e5 samma LAN, men klienten kan potentiellt kommunicera med servern \u00f6ver Internet. D\u00e4rf\u00f6r m\u00e5ste transportprotokollet vara lika l\u00e4mpat f\u00f6r LAN-milj\u00f6er som f\u00f6r Internet.<\/p>\n
Som jag n\u00e4mnde tidigare \u00e4r tekniker som DCOM, CORBA och Java RMI v\u00e4l l\u00e4mpade f\u00f6r att st\u00f6dja kommunikation mellan klient och server \u00f6ver Internet. Protokoll som Hypertext Transfer Protocol (HTTP) och Simple Mail Transfer Protocol (SMTP) \u00e4r bepr\u00f6vade Internetprotokoll. HTTP definierar ett beg\u00e4ran\/svar-meddelandem\u00f6nster f\u00f6r att skicka en beg\u00e4ran och f\u00e5 ett tillh\u00f6rande svar. SMTP definierar ett routningsbart meddelandeprotokoll f\u00f6r asynkron kommunikation. L\u00e5t oss unders\u00f6ka varf\u00f6r HTTP och SMTP \u00e4r v\u00e4l l\u00e4mpade f\u00f6r Internet.<\/p>\n
HTTP-baserade webbapplikationer \u00e4r till sin natur statsl\u00f6sa. De f\u00f6rlitar sig inte p\u00e5 en kontinuerlig anslutning mellan klienten och servern. Detta g\u00f6r HTTP till ett idealiskt protokoll f\u00f6r konfigurationer med h\u00f6g tillg\u00e4nglighet, t.ex. brandv\u00e4ggar. Om den server som hanterade klientens ursprungliga beg\u00e4ran blir otillg\u00e4nglig kan efterf\u00f6ljande f\u00f6rfr\u00e5gningar automatiskt dirigeras till en annan server utan att klienten vet om det eller bryr sig.<\/p>\n
N\u00e4stan alla f\u00f6retag har en infrastruktur p\u00e5 plats som st\u00f6der SMTP. SMTP l\u00e4mpar sig v\u00e4l f\u00f6r asynkron kommunikation. Om tj\u00e4nsten st\u00f6rs hanterar e-postinfrastrukturen automatiskt omf\u00f6rs\u00f6k. Till skillnad fr\u00e5n HTTP kan du skicka SMTP-meddelanden till en lokal e-postserver som f\u00f6rs\u00f6ker leverera e-postmeddelandet f\u00f6r din r\u00e4kning.<\/p>\n
Den andra stora f\u00f6rdelen med b\u00e5de HTTP och SMTP \u00e4r deras genomslagskraft. Medarbetarna har l\u00e4rt sig att f\u00f6rlita sig p\u00e5 b\u00e5de e-post och webbl\u00e4sare, och n\u00e4tverksadministrat\u00f6rerna har en h\u00f6g komfortniv\u00e5 n\u00e4r det g\u00e4ller att st\u00f6dja dessa tj\u00e4nster. Tekniker som NAT (Network Address Translation) och proxyservrar g\u00f6r det m\u00f6jligt att komma \u00e5t Internet via HTTP fr\u00e5n annars isolerade LAN. Administrat\u00f6rer exponerar ofta en SMTP-server som finns innanf\u00f6r brandv\u00e4ggen. Meddelanden som skickas till denna server dirigeras sedan till sin slutdestination via Internet.<\/p>\n
N\u00e4r det g\u00e4ller programvara f\u00f6r kreditkortsbehandling kr\u00e4vs ett omedelbart svar fr\u00e5n handelsbanken f\u00f6r att avg\u00f6ra om ordern ska skickas till aff\u00e4rssystemet. HTTP, med sitt request\/response-meddelandem\u00f6nster, \u00e4r v\u00e4l l\u00e4mpat f\u00f6r denna uppgift.<\/p>\n
De flesta aff\u00e4rssystem klarar inte av att hantera de stora ordervolymer som potentiellt kan komma fr\u00e5n e-handelsapplikationen. Dessutom \u00e4r det inte absolut n\u00f6dv\u00e4ndigt att best\u00e4llningarna skickas till aff\u00e4rssystemet i realtid. D\u00e4rf\u00f6r kan SMTP utnyttjas f\u00f6r att st\u00e4lla order i k\u00f6 s\u00e5 att de kan behandlas seriellt av aff\u00e4rssystemet.<\/p>\n
Om aff\u00e4rssystemet st\u00f6der distribuerade transaktioner \u00e4r ett annat alternativ att anv\u00e4nda Microsoft Message Queue Server (MSMQ). S\u00e5 l\u00e4nge e-handelsapplikationen och aff\u00e4rssystemet finns inom samma LAN \u00e4r anslutning via protokoll som inte \u00e4r Internetprotokoll ett mindre problem. F\u00f6rdelen med MSMQ j\u00e4mf\u00f6rt med SMTP \u00e4r att meddelanden kan placeras i och tas bort fr\u00e5n k\u00f6n inom ramen f\u00f6r en transaktion. Om ett f\u00f6rs\u00f6k att bearbeta ett meddelande som har tagits bort fr\u00e5n k\u00f6n misslyckas, placeras meddelandet automatiskt tillbaka i k\u00f6n n\u00e4r transaktionen avbryts.<\/p>\n
Att v\u00e4lja ett kodningssystem<\/b><\/p>\n
HTTP och SMTP g\u00f6r det m\u00f6jligt att skicka data mellan klienten och servern. Ingen av dem specificerar dock hur data i meddelandetexten ska kodas. Microsoft beh\u00f6vde ett standardiserat, plattformsneutralt s\u00e4tt att koda data som utv\u00e4xlas mellan klienten och servern.<\/p>\n
Eftersom m\u00e5let var att utnyttja Internetbaserade protokoll var XML (Extensible Markup Language) det naturliga valet. XML erbjuder m\u00e5nga f\u00f6rdelar, bland annat st\u00f6d f\u00f6r flera plattformar, ett gemensamt typsystem och st\u00f6d f\u00f6r teckenupps\u00e4ttningar enligt branschstandard.<\/p>\n
Bin\u00e4ra kodningssystem som de som anv\u00e4nds av DCOM, CORBA och Java RMI m\u00e5ste hantera kompatibilitetsproblem mellan olika maskinvaruplattformar. Olika maskinvaruplattformar har t.ex. olika intern bin\u00e4r representation av flerbytesnummer. Intel-plattformar ordnar bytena i ett multibyte-tal med hj\u00e4lp av Little Endian-konventionen, medan m\u00e5nga RISC-processorer ordnar bytena i ett multibyte-tal med hj\u00e4lp av Big Endian-konventionen.<\/p>\n
XML undviker problem med bin\u00e4r kodning eftersom det anv\u00e4nder ett textbaserat kodningsschema som utnyttjar standardiserade teckenupps\u00e4ttningar. Dessutom kan vissa transportprotokoll, t.ex. SMTP, endast inneh\u00e5lla textbaserade meddelanden.<\/p>\n
Bin\u00e4ra metoder f\u00f6r kodning, som de som anv\u00e4nds av DCOM och CORBA, \u00e4r besv\u00e4rliga och kr\u00e4ver en st\u00f6djande infrastruktur f\u00f6r att abstrahera utvecklaren fr\u00e5n detaljerna. XML \u00e4r mycket l\u00e4ttare och enklare att hantera eftersom det kan skapas och konsumeras med hj\u00e4lp av standardtekniker f\u00f6r textavl\u00e4sning.<\/p>\n
Dessutom finns det en m\u00e4ngd olika XML-parsers som ytterligare f\u00f6renklar skapandet och anv\u00e4ndningen av XML-dokument p\u00e5 praktiskt taget alla moderna plattformar. XML \u00e4r l\u00e4ttviktigt och har ett utm\u00e4rkt verktygsst\u00f6d, s\u00e5 XML-kodning ger en otrolig r\u00e4ckvidd eftersom praktiskt taget alla klienter p\u00e5 alla plattformar kan kommunicera med din webbtj\u00e4nst.<\/p>\n
V\u00e4lja en formateringskonvention<\/b><\/p>\n
Det \u00e4r ofta n\u00f6dv\u00e4ndigt att inkludera ytterligare metadata i meddelandetexten. Du kanske t.ex. vill inkludera information om vilken typ av tj\u00e4nster som en webbtj\u00e4nst beh\u00f6ver tillhandah\u00e5lla f\u00f6r att kunna uppfylla din beg\u00e4ran, t.ex. att delta i en transaktion eller routinginformation. XML tillhandah\u00e5ller ingen mekanism f\u00f6r att skilja mellan meddelandetexten och dess associerade data.<\/p>\n
Transportprotokoll som HTTP tillhandah\u00e5ller en utbyggbar mekanism f\u00f6r rubrikdata, men vissa data som \u00e4r kopplade till meddelandet kanske inte \u00e4r specifika f\u00f6r transportprotokollet. Klienten kan t.ex. skicka ett meddelande som m\u00e5ste dirigeras till flera destinationer, eventuellt via olika transportprotokoll. Om routningsinformationen placerades i en HTTP-header skulle den beh\u00f6va \u00f6vers\u00e4ttas innan den skickas till n\u00e4sta mellanhand via ett annat transportprotokoll, t.ex. SMTP. Eftersom routningsinformationen \u00e4r specifik f\u00f6r meddelandet och inte f\u00f6r transportprotokollet, b\u00f6r den vara en del av meddelandet.<\/p>\n
Simple Object Access Protocol (SOAP) \u00e4r ett protokolloberoende s\u00e4tt att associera rubrikinformation med meddelandetexten. Varje SOAP-meddelande m\u00e5ste definiera ett kuvert. Kuvertet har en kropp som inneh\u00e5ller meddelandets nyttolast och ett huvud som kan inneh\u00e5lla metadata som \u00e4r associerade med meddelandet.<\/p>\n
SOAP inneh\u00e5ller inga restriktioner f\u00f6r hur meddelandetexten kan formateras. Detta \u00e4r ett potentiellt problem eftersom det utan ett konsekvent s\u00e4tt att koda data \u00e4r sv\u00e5rt att utveckla en verktygsl\u00e5da som abstraherar dig fr\u00e5n de underliggande protokollen. Du kan beh\u00f6va \u00e4gna en hel del tid \u00e5t att s\u00e4tta dig in i webbtj\u00e4nstens gr\u00e4nssnitt ist\u00e4llet f\u00f6r att l\u00f6sa det aktuella aff\u00e4rsproblemet.<\/p>\n
Vad som beh\u00f6vdes var ett standardiserat s\u00e4tt att formatera ett RPC-meddelande (Remote Procedure Call) och att koda dess parameterlista. Detta \u00e4r precis vad avsnitt 7 i SOAP-specifikationen tillhandah\u00e5ller. D\u00e4r beskrivs en standardiserad namngivningskonvention och kodningsstil f\u00f6r procedurorienterade meddelanden.<\/p>\n
Eftersom SOAP tillhandah\u00e5ller ett standardformat f\u00f6r serialisering av data i ett XML-meddelande kan plattformar som ASP.NET och Remoting abstrahera bort detaljerna \u00e5t dig.<\/p>\n
Val av beskrivningsmekanismer<\/b><\/p>\n
SOAP tillhandah\u00e5ller ett standardiserat s\u00e4tt att formatera meddelanden som utv\u00e4xlas mellan webbtj\u00e4nsten och klienten. Klienten beh\u00f6ver dock ytterligare information f\u00f6r att kunna serialisera beg\u00e4ran och tolka svaret p\u00e5 r\u00e4tt s\u00e4tt. XML Schema g\u00f6r det m\u00f6jligt att skapa scheman som kan anv\u00e4ndas f\u00f6r att beskriva inneh\u00e5llet i ett meddelande.<\/p>\n
XML Schema tillhandah\u00e5ller en grundl\u00e4ggande upps\u00e4ttning inbyggda datatyper som kan anv\u00e4ndas f\u00f6r att beskriva inneh\u00e5llet i ett meddelande. Du kan ocks\u00e5 skapa dina egna datatyper. Handelsbanken kan t.ex. skapa en komplex datatyp f\u00f6r att beskriva inneh\u00e5llet och strukturen i meddelandetexten i ett meddelande som anv\u00e4nds f\u00f6r att skicka en beg\u00e4ran om kreditkortsbetalning.<\/p>\n
Ett schema inneh\u00e5ller en upps\u00e4ttning datatyp- och elementdefinitioner. En webbtj\u00e4nst anv\u00e4nder schemat inte bara f\u00f6r att kommunicera vilken typ av data som f\u00f6rv\u00e4ntas finnas i ett meddelande utan ocks\u00e5 f\u00f6r att validera inkommande och utg\u00e5ende meddelanden.<\/p>\n
Ett schema i sig ger dock inte tillr\u00e4ckligt med information f\u00f6r att effektivt beskriva en webbtj\u00e4nst. Schemat beskriver inte meddelandem\u00f6nstren mellan klienten och servern. En klient m\u00e5ste t.ex. veta om den kan f\u00f6rv\u00e4nta sig ett svar n\u00e4r en order l\u00e4ggs in i aff\u00e4rssystemet. En klient beh\u00f6ver ocks\u00e5 veta via vilket transportprotokoll webbtj\u00e4nsten f\u00f6rv\u00e4ntar sig att ta emot f\u00f6rfr\u00e5gningar. Slutligen m\u00e5ste klienten k\u00e4nna till den adress d\u00e4r webbtj\u00e4nsten kan n\u00e5s.<\/p>\n
Denna information tillhandah\u00e5lls av ett WSDL-dokument (Web Services Description Language). WSDL \u00e4r ett XML-dokument som ger en fullst\u00e4ndig beskrivning av en viss webbtj\u00e4nst. Verktyg som ASP.NET WSDL.exe och Remoting SOAPSUDS.exe kan konsumera WSDL och automatiskt bygga proxyer f\u00f6r utvecklaren.<\/p>\n
Som med alla komponenter som anv\u00e4nds f\u00f6r att bygga programvara b\u00f6r en webbtj\u00e4nst ocks\u00e5 \u00e5tf\u00f6ljas av skriftlig dokumentation f\u00f6r utvecklare som programmerar mot webbtj\u00e4nsten. Dokumentationen b\u00f6r beskriva vad webbtj\u00e4nsten g\u00f6r, vilka gr\u00e4nssnitt den exponerar och n\u00e5gra exempel p\u00e5 hur den kan anv\u00e4ndas. Bra dokumentation \u00e4r s\u00e4rskilt viktigt om webbtj\u00e4nsten exponeras f\u00f6r klienter \u00f6ver Internet.<\/p>\n
Att v\u00e4lja uppt\u00e4cktsmekanismer<\/b><\/p>\n
N\u00e4r du har utvecklat och dokumenterat en webbtj\u00e4nst, hur kan potentiella kunder hitta den? Om webbtj\u00e4nsten \u00e4r utformad f\u00f6r att anv\u00e4ndas 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\u00e5s bort. Men n\u00e4r potentiella kunder finns p\u00e5 Internet \u00e4r det en helt annan sak att marknadsf\u00f6ra din webbtj\u00e4nst p\u00e5 ett effektivt s\u00e4tt.<\/p>\n
Vad som beh\u00f6vs \u00e4r ett gemensamt s\u00e4tt att annonsera webbtj\u00e4nster. UDDI (Universal Description, Discovery, and Integration) tillhandah\u00e5ller just en s\u00e5dan mekanism. UDDI \u00e4r en branschstandardiserad centraliserad katalogtj\u00e4nst som kan anv\u00e4ndas f\u00f6r att annonsera och lokalisera webbtj\u00e4nster. UDDI g\u00f6r det m\u00f6jligt f\u00f6r anv\u00e4ndare att s\u00f6ka efter webbtj\u00e4nster med hj\u00e4lp av en m\u00e4ngd olika s\u00f6kkriterier, t.ex. f\u00f6retagsnamn, kategori och typ av webbtj\u00e4nst.<\/p>\n
Webbtj\u00e4nster kan ocks\u00e5 marknadsf\u00f6ras via DISCO, ett propriet\u00e4rt XML-dokumentformat som definieras av Microsoft och som g\u00f6r det m\u00f6jligt f\u00f6r webbplatser att marknadsf\u00f6ra de tj\u00e4nster de erbjuder. DISCO definierar ett enkelt protokoll f\u00f6r att underl\u00e4tta en hyperl\u00e4nkstil f\u00f6r att lokalisera resurser. Den prim\u00e4ra anv\u00e4ndaren av DISCO \u00e4r Microsoft Visual Studio.NET. En utvecklare kan rikta in sig p\u00e5 en viss webbserver och navigera genom de olika webbtj\u00e4nster som servern erbjuder.<\/p>\n
Vad saknas i Web Services?<\/b><\/p>\n
Du kanske har lagt m\u00e4rke till att vissa viktiga delar av en infrastruktur f\u00f6r distribuerade komponenter inte definieras av webbtj\u00e4nster. Tv\u00e5 av de mer m\u00e4rkbara bristerna \u00e4r ett v\u00e4ldefinierat API f\u00f6r att skapa och konsumera webbtj\u00e4nster och en upps\u00e4ttning komponenttj\u00e4nster, till exempel st\u00f6d f\u00f6r distribuerade transaktioner. L\u00e5t oss diskutera var och en av dessa saknade delar.<\/p>\n
I ett f\u00f6rs\u00f6k att s\u00e4kerst\u00e4lla att webbtj\u00e4nster \u00e4r programmeringsspr\u00e5kagnostiska har Microsoft l\u00e4mnat det upp till enskilda programvaruleverant\u00f6rer att binda st\u00f6d f\u00f6r webbtj\u00e4nster till en viss plattform. Jag kommer att diskutera tv\u00e5 implementeringar av webbtj\u00e4nster f\u00f6r .NET-plattformen, ASP.NET och Remoting, senare i boken.<\/p>\n
Vissa tj\u00e4nster, t.ex. st\u00f6d f\u00f6r distribuerade transaktioner, kan inf\u00f6ras senare n\u00e4r tekniken mognar. Andra, t.ex. objektpoolning och eventuellt hantering av objektens livstid, kan betraktas som en implementeringsdetalj i plattformen. Remoting definierar t.ex. till\u00e4gg f\u00f6r att ge st\u00f6d f\u00f6r hantering av objekts livstid och Microsoft Component Services ger st\u00f6d f\u00f6r objektpoolning.<\/p>\n
Sammanfattning<\/b><\/p>\n
Komponentbaserad programmering har visat sig vara en v\u00e4lsignelse f\u00f6r utvecklarnas produktivitet, men vissa tj\u00e4nster kan inte kapslas in av en komponent som finns i klientens datacenter. \u00c4ldre tekniker som DCOM, CORBA och Java RMI \u00e4r d\u00e5ligt l\u00e4mpade f\u00f6r att ge klienter tillg\u00e5ng till tj\u00e4nster \u00f6ver Internet, s\u00e5 Microsoft ans\u00e5g att det var n\u00f6dv\u00e4ndigt att b\u00f6rja fr\u00e5n b\u00f6rjan och bygga ett industristandardiserat s\u00e4tt att f\u00e5 tillg\u00e5ng till fj\u00e4rrtj\u00e4nster.<\/p>\n
Webbtj\u00e4nster<\/i> \u00e4r ett paraplybegrepp som beskriver en samling industristandardiserade protokoll och tj\u00e4nster som anv\u00e4nds f\u00f6r att underl\u00e4tta en basniv\u00e5 av interoperabilitet mellan applikationer. Det branschst\u00f6d som Web Services har f\u00e5tt saknar motstycke. Aldrig tidigare har s\u00e5 m\u00e5nga ledande teknikf\u00f6retag st\u00e4llt upp f\u00f6r att st\u00f6dja en standard som underl\u00e4ttar interoperabilitet mellan applikationer, oavsett vilken plattform de k\u00f6rs p\u00e5.<\/p>\n
En av de bidragande orsakerna till webbtj\u00e4nsternas framg\u00e5ng \u00e4r att de bygger p\u00e5 befintliga Internetstandarder som XML och HTTP. Det inneb\u00e4r att alla system som kan tolka text och kommunicera via ett standardiserat transportprotokoll p\u00e5 Internet kan kommunicera med en webbtj\u00e4nst. F\u00f6retagen kan ocks\u00e5 dra nytta av de investeringar som de redan har gjort i dessa tekniker.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/sv\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}