Vi har släppt en ny bok "Content Marketing in i sociala nätverk: Hur du kommer in i dina prenumeranters huvuden och får dem att bli kära i ditt varumärke."

Prenumerera

Webbtjänst (tjänst) är ett program som organiserar interaktion mellan webbplatser. Information från en portal överförs till en annan.

Det finns till exempel ett flygbolag. Hon har många flygresor, vilket gör att hon har många biljetter. Den överför information via en webbtjänst till en webbplats för reseaggregat. En användare som kommer åt aggregatorn kommer att kunna köpa biljetter till detta flygbolag direkt där.

Ett annat exempel på webbtjänster är en väderspårningssajt som innehåller information om väderförhållanden i en specifik stad eller ett land som helhet. Denna informationen används också ofta av tredje part.

Informationen på Internet är varierad. Webbplatserna hanteras olika system. Olika överförings- och krypteringsprotokoll används. Webbtjänster förenklar utbytet av information mellan olika webbplatser.

Webbtjänster arkitektur och protokoll

Du kan definiera 3 myndigheter som interagerar med varandra: katalog, entreprenör och kund. Efter att ha skapat tjänsten registrerar entreprenören den i katalogen och kunden hittar tjänsten där.

Mekanismen för datautbyte bildas i webbtjänstbeskrivningen. Detta är en specifikation som täcker vidarebefordringsformat, innehållstyper, transportprotokoll som används i processen för informationsutbyte mellan kunden och tjänstetransportören.

Idag används oftast flera tekniker för att implementera olika webbtjänster:

1. TCP/IP är ett protokoll som förstås av nästan alla nätverksutrustning, från stordatorer till bärbara enheter och PDA.
2. HTML är ett universellt märkningsspråk som används för att visa innehåll på konsumentenheter.
3. XML är ett universellt verktyg för att bearbeta alla typer av data. Andra protokoll för informationsutbyte kan fungera på grundval av detta: SOAP och WSDL.
4. UDDI är en universell källa till erkännande, integration och beskrivning. Det fungerar som regel i privata nätverk och har ännu inte hittat tillräcklig distribution.

Mångsidigheten hos de presenterade teknikerna är grunden för att förstå webbtjänster. De arbetar med standardtekniker som är oberoende av applikationsleverantörer och andra nätverksresurser. Kan användas i alla operativsystem, applikationsservrar, programmeringsspråk osv.

Fördelar

• Skapa de nödvändiga förutsättningarna för interaktion mjukvarukomponenter oavsett plattform.
• Webbtjänster är baserade på öppna standardprotokoll. Tack vare införandet av XML förenklas skapandet och konfigureringen av webbtjänster.
• Användningen av HTTP garanterar interaktion mellan systemen genom tillgång till Internet.

Brister

• Låg prestanda och stor trafikvolym, i jämförelse med RMI, CORBA, DCOM-system, på grund av användningen av XML-meddelanden i textsammanhang.
• Säkerhetsnivå. Alla moderna webbtjänster måste implementera kodning och kräver användarbehörighet. Huruvida HTTPS räcker här eller om mer tillförlitliga protokoll behövs, såsom XML-kryptering, SAML, etc., avgörs under utvecklingen.

Uppgifter för webbtjänster

Webbtjänster kan användas inom många områden.

B2B-transaktioner

Integrering av processer sker omedelbart, utan medverkan av människor. Till exempel uppdatera onlinebutikskatalogen med nya produkter. De förs till lagret och lagerhållaren noterar ankomsten i databasen. Informationen överförs automatiskt till webbutiken. Och köparen, istället för att markera "Ej i lager" på produktkortet, ser dess kvantitet.

Integration av företagstjänster

Om företaget använder företagsprogram hjälper webbtjänsten till att sätta upp deras gemensamma arbete.

Skapa ett klient-serversystem

Tjänster används för att konfigurera driften av klienten och servern. Detta ger fördelar:

• du kan inte sälja den själv programvara, men gör åtkomst till webbtjänsten betald;
• Det är lättare att lösa problem med programvara från tredje part;
• det är lättare att organisera åtkomst till serverns innehåll och material.

En webbtjänst är en applikation som förenklar den tekniska installationen av resursinteraktion.

Ämnets rubrik är verkligen en fråga, för... Jag själv vet inte vad det är och för första gången kommer jag att försöka arbeta med det inom ramen för denna artikel. Det enda jag kan garantera är att koden som presenteras nedan kommer att fungera, men mina fraser kommer bara att vara antaganden och gissningar om hur jag själv förstår allt detta. Låt oss gå...

Introduktion

Vi måste börja med varför konceptet webbtjänster skapades. När detta koncept dök upp i världen fanns det redan teknologier som gjorde det möjligt för applikationer att interagera på avstånd, där ett program kunde anropa någon metod i ett annat program, som kunde startas på en dator i en annan stad eller till och med ett land. Allt detta förkortas RPC (Remote Procedure Calling). Exempel inkluderar CORBA-teknologier och för Java - RMI (Remote Method Invoking). Och allt verkar vara bra i dem, speciellt i CORBA, för... Du kan arbeta med det i vilket programmeringsspråk som helst, men något saknades fortfarande. Jag tror att nackdelen med CORBA är att den fungerar genom några av sina egna nätverksprotokoll istället för enkel HTTP, som kommer att ta sig igenom vilken brandvägg som helst. Tanken med webbtjänsten var att skapa en RPC som skulle infogas i HTTP-paket. Därmed började utvecklingen av standarden. Vilka är de grundläggande begreppen i denna standard:

1. TVÅL. Innan du anropar en fjärrprocedur måste du beskriva detta samtal i en XML-fil i SOAP-format. SOAP är helt enkelt en av de många XML-uppmärkningar som används i webbtjänster. Allt vi vill skicka någonstans via HTTP konverteras först till en XML SOAP-beskrivning, stoppas sedan i ett HTTP-paket och skickas till en annan dator i nätverket via TCP/IP.
2. WSDL. Det finns en webbtjänst, d.v.s. ett program vars metoder kan anropas på distans. Men standarden kräver att detta program åtföljs av en beskrivning som säger att "ja, du har rätt - det här är verkligen en webbtjänst och du kan anropa sådana och sådana metoder från den." Denna beskrivning representeras av en annan XML-fil, som har ett annat format, nämligen WSDL. De där. WSDL är bara en XML-fil som beskriver en webbtjänst och inget mer.

Varför så kortfattat frågar du? Kan du inte vara mer specifik? Det är förmodligen möjligt, men för att göra detta måste du vända dig till böcker som T. Mashnin, "Java Web Services". Där, under de första 200 sidorna, finns en detaljerad beskrivning av varje tagg i SOAP- och WSDL-standarderna. Är det värt att göra? Enligt min åsikt nej, för... allt detta skapas automatiskt i Java, och du behöver bara skriva innehållet i de metoder som är tänkta att kallas på distans. Så ett API som JAX-RPC dök upp i Java. Om någon inte vet, när de säger att Java har ett sådant och ett API, betyder det att det finns ett paket med en uppsättning klasser som kapslar in den aktuella tekniken. JAX-RPC utvecklades med tiden från version till version och blev så småningom JAX-WS. WS står uppenbarligen för WebService och du kanske tror att detta helt enkelt är ett byte av RPC som ett populärt modeord nuförtiden. Detta är inte sant, eftersom Nu har webbtjänster gått bort från den ursprungliga idén och låter dig inte bara ringa fjärrmetoder, utan också att helt enkelt skicka dokumentmeddelanden i SOAP-format. Jag vet inte varför detta behövs ännu; det är osannolikt att svaret här kommer att vara "ifall det behövs." Själv skulle jag vilja lära mig av mer erfarna kamrater. Och sist, då dök JAX-RS upp för så kallade RESTful webbtjänster, men detta är ämnet för en separat artikel. Introduktionen kan sluta här, eftersom... Därefter ska vi lära oss att arbeta med JAX-WS.

Allmän riktlinje

I webbtjänster finns det alltid en klient och en server. Servern är vår webbtjänst och kallas ibland för slutpunkten (som i slutpunkten dit SOAP-meddelanden från klienten når). Vi behöver göra följande:

1. Beskriv gränssnittet för vår webbtjänst
2. Implementera detta gränssnitt
3. Starta vår webbtjänst
4. Skriv en klient och fjärranrop önskad webbtjänstmetod

Webbtjänsten kan startas olika sätt: beskriv antingen en klass med en huvudmetod och kör webbtjänsten direkt som en server, eller distribuera den till en server som Tomcat eller någon annan. I det andra fallet startar vi inte själva en ny server och öppnar inte en annan port på datorn, utan säger helt enkelt till Tomcat servletcontainern att ”vi har skrivit webbtjänstklasser här, vänligen publicera dem så att alla som kontaktar dig kan använd vår användning av webbtjänsten." Oavsett sätt att lansera webbtjänsten kommer vi att ha samma klient.

Server

Låt oss starta IDEA och skapa nytt projekt Skapa nytt projekt. Låt oss ange namnet Hej WebService och tryck på knappen Nästa, sedan knappen Avsluta. I mappen src låt oss skapa ett paket ru.javarush.ws. I det här paketet kommer vi att skapa HelloWebService-gränssnittet: package ru. javarush. ws; // dessa är anteckningar, dvs. ett sätt att markera våra klasser och metoder, // relaterat till webbtjänstteknik importera javax. jws. WebMethod; importera javax. jws. Webb-service; importera javax. jws. tvål. SOAPBindning;// vi säger att vårt gränssnitt kommer att fungera som en webbtjänst @Webb-service// vi säger att webbtjänsten kommer att användas för att anropa metoder @SOAPBinding (stil = SOAPBinding. Style. RPC) offentligt gränssnitt HelloWebService (// vi säger att denna metod kan kallas på distans @WebMethod public String getHelloString(String name) ; ) I den här koden är klasserna WebService och WebMethod så kallade annoteringar och gör ingenting förutom att markera vårt gränssnitt och dess metod som en webbtjänst. Detsamma gäller för SOAPBinding-klassen. Den enda skillnaden är att SOAPBinding är en annotering med parametrar. I det här fallet används stilparametern med ett värde som indikerar att webbtjänsten inte kommer att fungera genom dokumentmeddelanden, utan som en klassisk RPC, d.v.s. att anropa metoden. Låt oss implementera vår gränssnittslogik och skapa en HelloWebServiceImpl-klass i vårt paket. Förresten, jag noterar att att avsluta en klass med Impl är en konvention i Java, enligt vilken implementeringen av gränssnitt är så betecknad (Impl - från ordet implementering, dvs implementering). Detta är inget krav och du är fri att döpa klassen till vad du vill, men gott uppförande kräver det: paket ru. javarush. ws;// samma anteckning som när man beskriver gränssnittet, importera javax. jws. Webb-service; // men här används den med parametern endpointInterface, // indikerar fullständiga namn gränssnittsklass för vår webbtjänst @WebService(endpointInterface="ru.javarush.ws.HelloWebService" ) public class HelloWebServiceImpl implementerar HelloWebService ( @Override public String getHelloString (String name) (// returnera bara hälsningen src returnera "Hej, " + namn + "!" ; ) ) Låt oss lansera vår webbtjänst som en oberoende server, d.v.s. utan deltagande av någon Tomcat och applikationsservrar (detta är ett ämne för en separat diskussion). För att göra detta, i projektstrukturen i mappen Låt oss skapa ett paket ru.javarush.endpoint, och i det skapar vi en HelloWebServicePublisher-klass med huvudmetoden: paket ru. javarush. slutpunkt;// klass för att köra en webbserver med webbtjänster importera javax. xml. ws. Slutpunkt; import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher ( public static void main (String... args) ( // starta webbservern på port 1986 // och till adressen som anges i det första argumentet, // starta webbtjänsten som skickas i det andra argumentet Slutpunkt. publicera( "http://localhost:1986/wss/hello", nya HelloWebServiceImpl () ); ) ) Låt oss nu köra den här klassen genom att klicka Skift+F10. Inget kommer att visas i konsolen, men servern är igång. Du kan verifiera detta genom att skriva raden http://localhost:1986/wss/hello?wsdl i din webbläsare. Sidan som öppnas bevisar å ena sidan att vi har en webbserver (http://) som körs på port 1986 på vår dator (localhost), och visar å andra sidan en WSDL-beskrivning av vår webbtjänst. Om du stoppar applikationen blir beskrivningen otillgänglig, liksom webbtjänsten själv, så vi kommer inte att göra detta utan går vidare till att skriva klienten.

Klient

I projektmappen src Låt oss skapa ett paket ru.javarush.client , och i det klassen HelloWebServiceClient med huvudmetoden: paket ru. javarush. klient; // behövs för att få wsdl-beskrivning och genom den // nå själva webbtjänsten importera java. netto. URL; // detta undantag kommer att inträffa när du arbetar med ett URL-objekt importera java. netto. MalformedURLEundantag; // klasser för att analysera xml med wsdl-beskrivning // och nå servicetaggen i den importera javax. xml. namnutrymme. QName; importera javax. xml. ws. Service; // gränssnitt för vår webbtjänst (vi behöver mer) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient (public static void main (String args) kastar MalformedURLException ( // skapa en länk till wsdl-beskrivning URL url= ny URL ( "http://localhost:1986/wss/hello?wsdl") ; // Vi tittar på parametrarna för nästa konstruktor i den allra första taggen i WSDL-beskrivningen - definitioner // titta på det första argumentet i targetNamespace-attributet // titta på det andra argumentet i namnattributet QName qname = new QName ("http://ws.site/", "HelloWebServiceImplService" ); // Nu kan vi nå servicetaggen i wsdl-beskrivningen, Servicetjänst= Service. skapa (url, qname); // och sedan upp till porttaggen kapslad i den, så att // få en länk till ett webbtjänstobjekt på avstånd från oss HelloWebService hej = tjänst. getPort(HelloWebService.class); // Hurra! Du kan nu anropa fjärrmetoden Systemet. ut. println (hej. getHelloString ("JavaRush") ); ) ) Jag gav maximala kommentarer om koden i listan. Jag har inget att tillägga, så låt oss köra (Skift+F10). Vi bör se texten i konsolen: Hej, JavaRush! Om du inte såg det, har du förmodligen glömt att starta webbtjänsten.

Slutsats

I detta ämne presenterades kort utflykt till webbtjänster. Återigen kommer jag att säga att mycket av det jag skrev är min gissning om hur det fungerar, och därför ska du inte lita för mycket på mig. Jag skulle vara tacksam om kunniga människor De kommer att rätta mig, för då lär jag mig något. UPD.

Praktisk användning av webbtjänster i IBM Lotus Domino 7

Vad är webbtjänster och varför är de viktiga?

Innehållsserie:

Det här innehållet är en del # av en serie med # artiklar: Praktisk användning av webbtjänster i IBM Lotus Domino 7

https://www..jsp?series_title_by=Praktisk+användning+av+webbtjänster+i+ibm+lotus+domino+7

Håll utkik efter nya artiklar i den här serien.

Du kan ha stött på referenser till webbtjänster i tekniska artiklar, beskrivningar mjukvaruprodukter eller till och med i dialoger med kollegor. Tydligen är webbtjänster nödvändiga och viktiga för vissa människor, men när du stötte på definitioner som "XML-grammatik för att definiera uppsättningar av slutpunkter för meddelanden", bestämde du dig för att sådana komplexa saker inte var värda att beröra.

Lyckligtvis kan webbtjänster förklaras på ett sätt som alla kan förstå utan att gå in på detaljerna om hur det hela fungerar. Du bör försöka förstå vad webbtjänster är, eftersom omfattningen av deras (och relaterade tjänsteorienterade arkitektur, SOA) applikation i IT-världen ständigt expanderar.

Webbtjänster kan ses som en bil: du behöver inte veta hur man gör teknisk nivå hur kolvar, kamaxlar och bränsleinsprutare fungerar - du kan redan köpa en bil, köra den och prata om bilar med vänner (om de inte är mekaniker förstås). Det är samma sak med webbtjänster som IT-specialist, du behöver bara förstå vad de är och hur de fungerar för att förstå varför du behöver dem.

Det är nu mycket lättare att arbeta med webbtjänster utan att röra vid de dolda lågnivåteknikerna, eftersom mjukvaruleverantörer och öppen källkodsgemenskapen har gjort mycket under de senaste åren för att separera webbtjänsternas gränssnitt från lågnivåuppgifterna. Detta gör att du kan arbeta genom att helt enkelt koppla ihop komponenter, utan att behöva fördjupa dig i lång dokumentation om formatering av XML-meddelanden.

Denna serie artiklar hjälper Domino-utvecklare att förstå och använda webbtjänster i IBM Lotus Domino V7.0. Den här inledande artikeln innehåller tillräckligt användbar information, och kommer att vara användbar för alla som vill förstå vad webbtjänster är. Teknikerna i Lotus Domino V7.0 gör det enkelt för utvecklare att skapa och använda webbtjänster, och vi kommer att gå in mer i detalj om detta senare.

Låt oss först förstå vad en webbtjänst är.

Vad är en webbtjänst?

Enkelt uttryckt tillåter en webbtjänst datorprogram kommunicera med varandra på ett standardiserat sätt.

Kommunikation mellan tre eller flera maskiner

Även om vi i exemplen betraktar transaktioner inom en eller två maskiner, kan webbtjänster också användas för kommunikation mellan stor mängd datorer. Till exempel kan vidarebefordran eller lagring av transaktioner utföras av en mellanliggande enhet, eller så kan ett anrop till en webbtjänst på en server resultera i ett anrop till en tjänst på en annan.

I slutet av den här artikeln, när vi tittar på sann SOA, kommer vi att prata om webbtjänster som kommunicerar över flera maskiner, eftersom det är vad SOA alltid gör.

En webbtjänst är en abstrakt komponent, precis som begreppet dialog mellan människor är abstrakt. En dialog involverar två eller flera personer som talar ett språk som de känner till. Deras språk definierar de ord de använder och hur dessa ord används för att bilda meningar. Vanligtvis har en dialog en fråga-svar-struktur, när någon ställer en fråga eller gör ett uttalande, och samtalspartnern svarar på den. Människor kan vara i närheten, kommunicera i telefon, skicka meddelanden till varandra via post eller chatt.

Dialogen har i alla fall en komplex struktur och kan ske på olika sätt, beroende på antalet personer som kommunicerar, kommunikationsspråket, vilka teknologier som används för kommunikation, naturligtvis, om några används.

Strukturen för kommunikation med hjälp av webbtjänster inkluderar många av de element som vi kommer att beröra i den här artikeln. Tanken är dock densamma som vanlig dialog - program kommunicerar på ett språk de är bekanta med, ibland över ett nätverk. Program kan antingen finnas på en dator eller på olika bilar V olika punkter globe, ansluten via Internet med routrar och servrar. Det som är bra är att program och datorer inte behöver vara samma sak. Tack vare webbtjänster kan två personer kommunicera Microsoft-program.NET på en bärbar dator och ett Java-program på en kanadensisk iSeries-server med ett C++-program på en Linux-dator från Kina.

Följande standardtekniker används i kommunikation via webbtjänster:

• XML. Språket (dataformatet) som används av webbtjänstkomponenter.
• SOAP-protokoll. XML-meddelanden utbytt mellan program
• Web Services Description Library (WSDL). XML-fil som definierar formatet för SOAP-meddelanden och hur de ska skickas

En standardteknik som kallas Universal Description, Discovery and Integration (UDDI) kan också användas för att kommunicera mellan webbtjänster. Vi kommer att titta på detta senare i artikeln, men eftersom det inte krävs att använda UDDI, använder många webbtjänster det inte.

Lite terminologi: publicering och användning av webbtjänster

Innan vi går in på att förklara våra termer, låt oss titta på några av de terminologier som är förknippade med webbtjänster.

När vi pratar om att publicera en webbtjänst talar vi om ett program som publicerar en WSDL-fil och låter andra program använda motsvarande tjänst. Program som publicerar webbtjänster kallas leverantörer.

När vi talar om att använda en webbtjänst menar vi ett program som ringer en webbtjänst på en annan maskin. Användare av webbtjänster kallas klienter.

XML: modersmål

XML används för att kommunicera mellan webbtjänstkomponenter. Meddelanden som skickas mellan applikationer, såväl som filer som definierar webbtjänsten, är i XML-format. Figur 1 visar strukturen enkel fil XML.

Figur 1. Grundläggande XML-struktur

Som du kan se är viss information i filen (som förnamn, efternamn) omgiven av taggar omgivna av triangelparenteser. Namnet John visas som John. Det finns också element där andra element är kapslade, till exempel i elementet Kapslade element , Och .

Det finns många fördelar med att skriva webbtjänster i XML, inklusive:

• Strukturen och grammatiken i XML liknar den för andra programmeringsspråk, så program som interagerar med webbtjänster behöver inte utföra strukturanalys XML-filer direkt.
• XML-filer är text- och läsbara för människor (med andra ord, om du kan XML kan du öppna en XML-fil i textredigerare och förstå dess innehåll). Detta kan hjälpa till med felsökning.
• XML låter dig använda vilken standardkodning som helst i meddelanden, så att du kan skriva meddelanden på engelska, ryska eller japanska.
• XML låter dig dra nytta av det som kallas ett namnområde, där du kan fördefiniera den önskade strukturen för ett filelement med ett specifikt namn. Du kan till exempel definiera ett Price-element, som alltid måste vara ett flytande element, eller ett PersonName-element, som inkluderar två strängunderelement, FirstName och LastName.

  Dessutom, om nödvändigt, tillåter namnutrymmen flera element med samma namn har olika definitioner. Till exempel kan ett aktiepris-element i ett namnområde inkludera en ticker-symbol och ett pris, medan det i ett annat namnområde kan bestå av en ticker-symbol, pris, daglig låg och hög, och 12-månaders högsta.

De enda nackdelarna med XML, om de verkligen är nackdelar, är:

• XML är ett stelt språk, så all felaktig formatering av ett XML-meddelande kommer att göra att analysen av hela meddelandet misslyckas (även om problemet är lätt att tolka eller missa). Men om du använder standardbiblioteket för att generera XML-filer (vilket är vad du gör när du skapar webbtjänster), kontrollerar biblioteket självt efter korrekt formatering.
• XML-meddelandet lagras i en vanlig textfil, och tar därför upp mer utrymme än motsvarande i ett annat format (som ett delat, binärt eller "hemlagat" format).

Men dessa problem är obetydliga jämfört med fördelarna med XML-formatet.

SOAP: meddelanden skickas

Du vet att webbtjänster kommunicerar in XML-format Detta löser dock bara halva problemet. Applikationer kan analysera meddelandet, men hur vet de vad de ska göra med resultatet efter analys?

Instruktionen som beskriver reglerna för formatering av XML-meddelanden för webbtjänster kallas SOAP. Den definierar en meddelandestruktur så att program vet hur de ska skicka och tolka data. Den grundläggande strukturen för ett SOAP-meddelande visas i figur 2.

Figur 2. Grundläggande SOAP-meddelandestruktur

I XML skulle det se ut ungefär så här:

FOO

I basfallet har du ett SOAP-paket som innehåller en SOAP-kropp och en body som innehåller data som ska överföras. Ibland finns det också en valfri SOAP-rubrik (inuti paketet före brödtexten) som innehåller ytterligare information.

SOAP instruktioner

Även om SOAP-formatet är standard och har samma instruktioner, måste man komma ihåg att olika tillverkare kan implementera dessa instruktioner lite olika. Till exempel kan strukturen för namnutrymmen och XML i ett SOAP-meddelande som genereras av Apache Axis skilja sig mycket från strukturen som genereras av Microsoft .NET. En korrekt skriven klient eller server kan dock bearbeta alla meddelanden som är korrekt skrivna enligt SOAP-instruktioner.

Dessutom finns det några viktiga skillnader mellan WSDL 1.1- och WSDL 2.0-satser. Även om instruktion 2.0 fortfarande är i sitt slutskede i skrivande stund kommer den snart att börja ersätta version 1.1.

Om du aldrig har stött på en WSDL-fil tidigare och försöker öppna en och läsa den, kommer du att ha svårt att få ut all information ur den, eftersom strukturen för en sådan fil kan vara ganska komplex. All information om metoden (namn, parametrar, protokoll, etc.) är spridd över olika sektioner av filen, och för att kunna konstruera ett SOAP-meddelande måste det samlas in av klientapplikationen. Beskrivningar av delarna av WSDL-filen och deras samarbete kommer inte att ingå i den här artikeln.

Det är här tekniken kommer till vår hjälp igen. Som utvecklare behöver du inte läsa, analysera eller förstå innehållet i WSDL-filen. Verktygen hämtar denna information åt dig, så du behöver bara ta reda på vad du ska skicka till tjänsten och var du ska placera resultaten. Du är inte bara du kan använda bibliotek och verktyg, men också säkert du kommer. Det finns en hel del undantag, egenheter och komplexitet i alla webbtjänstkomponenter som du bör titta närmare på. använder sig av Webbtjänst, snarare än att demontera den följt av en detaljerad studie av varje komponent.

Protokoll: hur meddelanden skickas

Vi har ännu inte berört frågan om hur alla dessa meddelanden överförs via SOAP?

Och de överförs vanligtvis över nätverket (och/eller Internet) med hjälp av HTTP-protokollet, nästan på samma sätt som sidor överförs från servern till din webbläsare. HTTP används inte alltid (dess främsta konkurrent är SMTP, men det ligger långt efter). Protokollet som används av webbtjänsten definieras i WSDL-filen.

Vanligtvis definierar WSDL-filen protokollet som används för att transportera SOAP-meddelandet som HTTP. SOAP-klienten skickar meddelanden enligt det angivna protokollet.

Andra villkor för webbtjänster som du kan stöta på

Vi har redan täckt de grundläggande termerna, men du kanske hör några fler när du pratar om webbtjänster.

Svaga band

Program som använder webbtjänster har vanligtvis svaga kopplingar till tjänster, det vill säga de tjänster som behövs för att programmet ska fungera är inte direkt knutna till det, precis som programmet inte är knutet till tjänster. Programmet kan enkelt använda alla tjänster det behöver, och de väntar på ett samtal från programmet - från vilket program som helst som behöver deras svar.

Livsexempel svaga band- det här är lunch med vänner. Flera vänner kommer på något sätt överens sinsemellan (personligen, per telefon, genom e-post etc.). Alla tar sig till restaurangen på egen hand och efter lunch betalar var och en för sin egen mat. Hur lunchen än gick så är slutresultatet detsamma – det var en trevlig lunch.

Men att köra bil är en handling med stelare kopplingar. Du har en fast uppsättning verktyg som du behöver för att uppnå fördefinierade mål. När du lämnar garaget sätter du bilen i backen och trampar på gasen. När du svänger vänster vrider du ratten åt vänster. Du har inte möjlighet att göra samma sak på olika sätt, eftersom hela systemet är mycket exakt och sammanhängande, och vart och ett av dess element är kopplat till de andra.

UDDI

UDDI är en standard för att skapa en katalog över webbtjänster som levereras av valfritt antal program. Det är något liknande telefonbok Webbtjänstleverantörer. Klienter kan slå upp den information de behöver i UDDI-registret, och registret returnerar dem nödvändiga data för att ansluta till tjänsten.

Även om UDDI är en ganska viktig standard för att definiera webbtjänster, minskar dess betydelse avsevärt av att det är ett valfritt inslag i webbtjänster, och när man får välja om man vill använda det eller inte väljer många att inte använda det.

De flesta organiserade företagsmiljöer med ett stort antal interna webbtjänster har UDDI-register. Det är bra att ha en företags UDDI-webbplats som innehåller information om de webbtjänster som finns tillgängliga i ditt företag. Genom att sammanföra alla tjänster låter UDDI dig sömlöst och sömlöst byta tjänsteleverantör. Om klienter söker tjänster via UDDI skickas SOAP-samtal automatiskt till den nya leverantören.

Den här komponenten krävs dock inte i en webbtjänstarkitektur.

Säkerhet för webbtjänster

När du läser om SOAP och WSDL kanske du märker att ämnet säkerhet inte täcks. Hur utförs autentisering för servicesamtal om leverantören arbetar med känslig information? Det är uppenbart att inte alla webbtjänster är tillgängliga för allmänheten, eller hur?

Detta är en viktig fråga som inte är lätt att definitivt besvara. Det finns olika system som du kan använda, beroende på situationen, till exempel:

• Kan SOAP-meddelanden komma som text eller måste de krypteras?
• Räcker enkel inloggning och lösenordsautentisering för dig, eller bör den vara stark och tokenbaserad?
• Om tokens används, måste de vara signerade, och vad är det korrekta sättet att inkludera dem i ett SOAP-meddelande?
• Vad händer om klienten skickar SOAP-meddelanden inte direkt, utan genom någon mellanliggande struktur, till exempel en meddelandekö eller någon annan webbtjänst?

Dessutom kan meddelandehantering inte alltid använda HTTP, så du kommer inte bara att kunna använda webbtjänstsäkerhet utöver befintliga system HTTP-säkerhet.

Det finns flera riktlinjer som täcker dessa och andra aspekter av webbtjänstsäkerhet: WS-Security, WS-Policy, WS-Trust och WS-Privacy. Vissa mjukvaruleverantörer och kommittéer har arbetat med dessa frågor i flera år. Även om inte alla implementeringar av webbtjänster stöder alla säkerhetsriktlinjer, implementerar tillgängliga säkerhetsstandarder vanligtvis åtminstone några grundläggande säkerhetsvägar.

Middleware och Enterprise Service Bus

Det finns en annan ganska stor uppsättning standarder för webbtjänster, samlade till en ganska stor klump, som vanligtvis kallas WS-*-instruktioner. Tillsammans tar de upp många av de designöverväganden som uppstår när du sätter ihop många webbtjänster i en miljö. WS-*-standarderna tar upp frågor som:

• Säkerhet
• Pålitlighet
• Meddelandeutbyte
• Transaktioner
• Service kvalitet

Detta antal standarder är nödvändiga eftersom utbytet av meddelanden mellan en webbtjänstklient och server i en industriell miljö kan vara mycket mer komplex än en enkel begäran/svar. Hur säkerställer du till exempel att meddelandet når leverantören och kommer tillbaka till kunden? Vad händer om en SOAP-förfrågan har flera delar? Hur hanterar du processer som innebär att webbtjänster får åtkomst till andra webbtjänster? Vad händer om programmet skickar en sekvens av förfrågningar med krav på svarstid?

För stora mjukvaruföretag innebär arbetet med dessa standarder både utmaningar och möjligheter. Vissa leverantörer marknadsför hela mellanvarupaket för webbtjänster, ofta kallade Enterprise Service Buses, eller ESBs, som kan hantera alla eller åtminstone några av ovanstående uppgifter. Dessa ESB:er är också värdefulla eftersom de kan knyta ihop flera webbtjänster inom samma organisation och tillhandahålla deras funktionalitet, registrera deras handlingar och lagra meddelanden i köer.

Serviceinriktad arkitektur

Och slutligen, serviceinriktad arkitektur. I de flesta fall är det helt enkelt en kombination av allt ovanstående: löst kopplade webbtjänster från olika leverantörer, som interagerar i enlighet med accepterade standarder (eventuellt med medverkan av ESB) och samlas ihop av olika program som tar data från tjänsterna och använda den på olika sätt.

Eftersom SOA är mjukvaruarkitektur, då innebär dess konstruktion en enorm mängd samordnings- och planeringsarbete. Det är inte bara ett gäng tjänster som slängs ihop; det är organisationen av hur tjänster sätts ihop och publiceras, vilka hanteringsverktyg och mellanprogram som används samt hur tjänster och hela systemet övervakas och hanteras.

Om man ser mer globalt är SOA också en typ av tänkande. Det får dig att inte tänka på stora program som körs självständigt, utan att uppfatta allt som möjliga komponenter som kan publiceras och användas i produktionen. Istället för multifunktionella applikationer du tänker på specifika och väldefinierade tjänster – vilket är vad webbtjänster är.

Varför är det viktigt?

Nu vet du redan något om hur webbtjänster fungerar - klienten läser leverantörens WSDL-fil, formaterar och skickar ett SOAP-meddelande enligt den, och får ytterligare ett SOAP-meddelande som svar. Så varför är detta så viktigt? Vad är problemet?

En del av betydelsen av tjänster är att de tillhandahåller ett standardsätt för program att kommunicera, oavsett vilka språk de är skrivna på eller vilka plattformar de körs på. Tidigare var vi tvungna att arbeta med dataformat som var unika för olika program, eller med funktioner på API-nivå som program på andra språk inte kunde fungera med. Användningen av XML i alla webbtjänststandarder innebär att alla tjänster är tillgängliga och tydligt definierade.

I själva verket tillåter detta helt olika program att enkelt kommunicera med varandra på ett språk som de alla förstår. En av de största svårigheterna när man arbetar med olika tekniker från olika tillverkare det fanns alltid ett behov av att tvinga fram alla dessa olika program kommunicera med varandra och utbyta data. Nu när alla dina applikationer kan leverera och/eller konsumera webbtjänster är interoperabiliteten mellan dem otroligt enkel.

En annan fördel med webbtjänster är att kunder och leverantörer kan vara på olika maskiner, använda olika hårdvara och programvara, och detta stör inte kommunikationen. Program kan användas av andra program inom samma maskin, eller från andra maskiner, men med ett specifikt dataöverföringsformat. Webbtjänster behöver bara en nätverksanslutning och en XML-processor.

Om alla dessa faktorer beaktas tillsammans är resultatet betydande. När vi väl har standardmedel För kommunikation mellan applikationer över nätverket kan vi bygga våra program på olika sätt. Istället för att skriva monolitiska program som varje gång uppfinner hjulet på nytt, kan vi skriva program som består av moduler.

Till exempel istället för stort program, samlar in information om flera processer, förvandlar den till grafer och visar dem för användarna, vi kan skapa en instrumentpanel som visar data från flera webbtjänster. Den sammanställda datan tas emot från en eller flera tjänster, och de resulterande graferna skapas av en annan webbtjänst som accepterar data och producerar en graf.

Instrumentpanelen förvandlas från ett stort program till ett enkelt gränssnitt. Om vi ​​vill lägga till nya komponenter vänder vi oss helt enkelt till ytterligare tjänster. Om vi ​​behöver ett annat sjökort vänder vi oss till en annan karttjänst. Om vi ​​behöver en mer interaktiv instrumentpanel, med utbildnings- eller sorteringsmöjligheter, kan instrumentpanelen överföra meddelanden från användaren till lämplig tjänst. Vi kan till och med helt ändra de tjänster som anropas så att användarna inte märker det (så länge WSDL-filen inte ändras), och panelen förblir densamma.

Som IT-proffs kan du utveckla både gränssnitt och tjänster, eller båda. Att förstå hur allt fungerar tillsammans (eller åtminstone veta vad det är) är viktigt när man arbetar med ett projekt som detta.

Det är också bra att det finns många verktyg som hjälper dig att leverera och använda webbtjänster och kan göra mycket av det tunga lyftet åt dig. I följande delar av artikeln kommer vi att förstå hur du med IBM Lotus Domino V7.0 enkelt kan leverera webbtjänster till kunder eller system.

Valentin Kolesov
utvecklare av Krasnoyarsk-grenen av St. Petersburg-företaget "Astrosoft", certifierad Microsoft-specialist (MCSD, MCSE, MCDBA)
[e-postskyddad]

Demonstration av hur SOAP fungerar med exemplet att skriva en webbserver

Vad är SOAP

De för närvarande utbredda teknologierna för fjärrmetodanrop (DCOM, CORBA/IIOP och RMI) är ganska svåra att konfigurera och organisera interaktion. Detta medför svårigheter i drift och funktion av distribuerade system (säkerhetsproblem, besvär med transport genom brandväggar etc.). Många problem löstes genom skapandet av SOAP (Simple Object Access Protocol), ett enkelt XML-baserat protokoll för att utbyta meddelanden i distribuerade miljöer (WWW). Protokollet är utformat för att skapa webbtjänster och anropsmetoder på distans. SOAP kan användas i kombination med olika transportprotokoll, inklusive HTTP, SMTP och andra.

Vad är webbtjänster

Vi kallar webbtjänster aktivt innehåll som implementerar viss funktionalitet och data som finns på webbservrar och görs tillgängliga för användning av externa applikationer. Webbtjänster är helt oberoende av implementeringsspråk och plattform. Externa applikationer interagerar med tjänster med hjälp av standardprotokoll och dataformat. Webbtjänstteknik är hörnstenen programmodell Microsoft .NET.

För att demonstrera funktionerna hos SOAP använder den här artikeln den nyligen släppta implementeringen av SOAP Toolkit version 2.0 från Microsoft. Det bör nämnas att Aktuell version Toolkit skiljer sig märkbart från den tidigare (Microsoft SOAP Toolkit för Visual Studio 6.0) och från betaversionen av SOAP Toolkit 2.0.

SOAP Toolkit-objektmodellen tillhandahåller både lågnivå- och högnivågränssnitt (SOAPClient, SOAPServer), som döljer hela det "interna köket" för programmeraren - tolka och generera paket, anropsmetoder etc. Genom att använda dessa gränssnitt kan du använda Webbaserade verktyg på ett mycket elegant sätt i utvecklade applikationer. SOAPClient-objektet fungerar som en proxy, tillhandahåller ett webbtjänstgränssnitt och låter dig arbeta med det som med ett vanligt COM-objekt (Fig. 1).

1. Klientapplikationen instansierar SOAPClient-objektet.
2. SOAPClient läser webbtjänstens metodbeskrivningsfiler (i WSDL och Web Services Meta Language, WSML). Dessa filer kan också lagras på klientsidan.
3. Klientapplikationen, som använder de sena bindningsfunktionerna för SOAPClient-objektet, anropar en servicemetod. SOAPClient genererar ett förfrågningspaket (SOAP Envelope) och skickar det till servern. Alla transportprotokoll kan användas, men HTTP används vanligtvis.
4. Listener-serverapplikationen (detta kan vara en ISAPI-applikation eller en ASP-sida) tar emot paketet, skapar ett SOAPServer-objekt och skickar förfrågningspaketet till det. Dessutom bearbetar Lyssnaren HTTP-paket från klienten, skickar paket med resultatet av tjänsten till klienten, hanterar fel och använder funktionaliteten hos SOAP-objekt.
5. SOAPServer läser webbtjänstbeskrivningen, laddar beskrivningen och begärandepaketet i XML DOM-träd.
6. SOAPServer anropar en metod på objektet eller applikationen som implementerar tjänsten.
7. Metodens exekveringsresultat eller felbeskrivningen konverteras av SOAPServer-objektet till ett svarspaket och skickas till klienten.
8. SOAPClient-objektet analyserar det mottagna paketet och returnerar resultatet av tjänsten eller en beskrivning av felet som uppstod till klientapplikationen.

En WSDL-fil är ett XML-dokument som beskriver metoderna som exponeras av en webbtjänst, såväl som metodparametrarna, deras typer, namn och plats för Listener-tjänsten. SOAP Toolkit-guiden genererar automatiskt detta dokument, ett utdrag av det visas nedan:

Envelope-taggen måste vara paketets rotelement. Header-elementet är valfritt, men Body-elementet måste finnas och vara ett direkt underordnat element till Envelope-elementet. I händelse av ett metodexekveringsfel genererar servern ett paket som innehåller ett Fault-element i Body-taggen, som innehåller detaljerad beskrivning fel.

Om du använder högnivågränssnitten SOAPClient, SOAPServer, behöver du inte gå in på paketformatets krångligheter, men om du vill kan du använda lågnivågränssnitt eller till och med skapa ett paket "manuellt" med valfri programmering språk.

SOAP Toolkit-objektmodellen gör det möjligt att arbeta med lågnivå-API-objekt:

• SoapConnector - ger arbete med transportprotokollet för utbyte av SOAP-paket.
• SoapConnectorFactory - Tillhandahåller en metod för att skapa en anslutning för transportprotokollet som anges i WSDL-filen (taggen).
• SoapReader - läser SOAP-meddelanden och bygger XML DOM-träd.
• SoapSerializer - innehåller metoder för att skapa ett SOAP-meddelande.·
• IsoapTypeMapper, SoapTypeMapperFactory - gränssnitt som låter dig arbeta med komplexa datatyper.

Med hjälp av API-objekt på hög nivå kan du bara överföra data av enkla typer (int, string, float, etc.), men SOAP 1.1-specifikationen låter dig arbeta med mer komplexa datatyper, såsom arrayer, strukturer, listor och kombinationer därav. För att arbeta med sådana typer måste du använda gränssnitten IsoapTypeMapper och SoapTypeMapperFactory.

Exempel

För att visa hur SOAP fungerar, låt oss skriva en enkel webbtjänst som kan lägga till och subtrahera siffror. Serverapplikationen kräver IIS 5 för att köras. Windows-miljö 2000 eller IIS4 på Windows NT 4.0 Service Pack 6 och SOAP Toolkit 2.0 installerat.

Klientapplikationskrav - OS Microsoft Windows 98/Me eller Windows NT 4.0 Service Pack 6/2000 Service Pack 1, samt SOAP Toolkit 2.0 installerat.

Skapa en server

Öppna ett nytt ActiveX DLL-projekt i VB. Ändra klassnamnet till SOAPClass och projektnamnet till SOAPProj.

Skapa följande metoder i klassen:

I nästa guidefönster kan du välja metoder som ska ingå i webbtjänsten. I det här fallet väljer du alla metoder. Ange sedan var webbapplikationen ska finnas (till exempel http://wsd010/soap/), ställ in Listener-applikationstypen (ASP eller ISAPI), välj ASP, schemaformat (standard). Ange sökvägen där webbtjänstbeskrivningsfilerna ska finnas och kodningen. När guiden är klar kommer ASP-, WSDL- och WSML-filer att visas i webbkatalogen - detta är Listener för ASP och tjänstebeskrivningen (se listor 1-3).

Allt som återstår är att konfigurera åtkomsträttigheter till webbapplikationen - det är tillrådligt att installera NT Challenge/Response-autentisering. Detta slutför arbetet med att skapa servern.

Skapa en klient

Öppna ett nytt Standard EXE-projekt i VB. Gör en länk till Microsoft SOAP-typbiblioteket i menyn Projekt/Referenser. Skapa en knapp på formuläret, skriv följande kod i knappklickshanteraren:

Dim SoapClient som ny SoapClient SoapClient.mssoapinit "http://wsd010/soap/SOAPService.wsdl" MsgBox SoapClient.AddNumbers(4, 3) MsgBox SoapClient.SubtractNumbers(3, 2)

Glöm inte att ändra webbserveradressen och sökvägen till WSDL-filen på andra raden till adressen och sökvägen till din webbtjänst.

Efter att SOAPClient-objektet har skapats måste det initieras - ange sökvägen till webbtjänstbeskrivningsdokumentet. Efter initiering kommer objektet att ha webbtjänstmetoder. Du kan arbeta med dem som med ett vanligt COM-objekt.

Med hjälp av det utmärkta MsSoapT.exe (Trace Utility) som ingår i verktygslådan kan du se paket som går från klient till server och tillbaka i realtid. För att göra detta måste du hitta en tagg i WSDL-filen och istället för en rad som http://wsd010/soap/SOAPService.ASP skriva http://wsd010:8080/soap/SOAPService.ASP, det vill säga specificera port 8080. Efter detta måste du köra verktygsspårningen och acceptera standardinställningarna och sedan skapa nytt objekt Formaterad spårning. Nu finns alla SOAP-paket för att arbeta med webbtjänsten tillgängliga för snabb visning. Om spåraren inte är laddad, måste du ta bort port 8080-indikationen. Figur 4 visar innehållet i förfrågningspaketet för exekvering av SubstractNumbers-metoden.

Och svarspaketet ser ut så här:

1

Så här ser serverpaketet ut när det kom som svar på en begäran av ett felaktigt format:

SOAP-ENV:Server Connector - Dålig begäran till servern. -2146823238 800a13ba

Ytterligare information om ämnet

http://msdn.microsoft.com/webservices/ och http://msdn.microsoft.com/soap/ - de senaste nyheterna om SOAP och webbtjänster från Microsoft. Du kan också hitta de senaste mjukvaruversionerna där.

http://www.vbxml.com/soap/ - mycket användbar information för utvecklare. Det finns presentationer och tutorials om SOAP.

http://www.w3.org/TR/SOAP/ - SOAP-specifikation från W3C.

http://www.w3.org/TR/wsdl - information om standarden Web Services Definition Language (WSDL) 1.1/

http://microsoft.public.xml.soap - i denna konferens kommer experter att hjälpa till att lösa komplexa SOAP-programmeringsproblem.

Lista 1. Lyssnarkod för ASP <%@ LANGUAGE=VBScript %> <% Option Explicit On Error Resume Next Response.ContentType = "text/xml" Dim SoapServer If Not Application("SoapServerInitialized") Then Application.Lock If Not Application("SoapServerInitialized") Then Dim WSDLFilePath Dim WSMLFilePath WSDLFilePath = Server.MapPath("SOAPService.wsdl") WSMLFilePath = Server.MapPath("SOAPService.wsml") Set SoapServer = Server.CreateObject("MSSOAP.SoapServer") If Err Then SendFault "Cannot create SoapServer object. " & Err.Description SoapServer.Init WSDLFilePath, WSMLFilePath If Err Then SendFault "SoapServer.Init failed. " & Err.Description Set Application("SOAPServiceServer") = SoapServer Application("SoapServerInitialized") = True End If Application.UnLock End If Set SoapServer = Application("SOAPServiceServer") SoapServer.SoapInvoke Request, Response, "" If Err Then SendFault "SoapServer.SoapInvoke failed. " & Err.Description Sub SendFault(ByVal LogMessage) Dim Serializer On Error Resume Next " "URI Query" logging must be enabled for AppendToLog to work Response.AppendToLog " SOAP ERROR: " & LogMessage Set Serializer = Server.CreateObject("MSSOAP.SoapSerializer") If Err Then Response.AppendToLog "Could not create SoapSerializer object. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.Init Response If Err Then Response.AppendToLog "SoapSerializer.Init failed. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.startEnvelope Serializer.startBody Serializer.startFault "Server", "The request could not be processed due to a problem in the server. Please contact the system administrator. " & LogMessage Serializer.endFault Serializer.endBody Serializer.endEnvelope If Err Then Response.AppendToLog "SoapSerializer failed. " & Err.Description Response.Status = "500 Internal Server Error" End If End If End If Response.End End Sub %>

Lista 2. WSDL-filkod

Lista 3. WSDL-filkod

Idén med webbtjänster utvecklades av datorindustrijättar som Sun, Oracle, HP, Microsoft och IBM. Denna idé är inget nytt, men det är ett stort steg framåt mot enklare tillgång till program över webben. Baserat på standardkommunikationsformat kan webbtjänster helt förändra vårt sätt att tänka på hur vi ska göra webbplatser.

Vad är en webbtjänst?

Tack vare webbtjänster kan alla programs funktioner göras tillgängliga över Internet. Således kan program som PHP, ASP, JSP-skript, JavaBeans, COM-objekt och alla våra andra favoritprogrammeringsverktyg nu komma åt något program som körs på en annan server (d.v.s. en webbtjänst) och använda svaret från henne på hennes webbplats, eller Ansökan.

Låt oss säga att om jag behöver utföra någon programmeringsuppgift, och jag är för upptagen (eller inte vettet för att själv uppfinna hjulet igen), kan jag använda tjänsterna för en webbtjänst som min webbplats kommer åt via Internet. Genom att skicka en förfrågan med parametrar till webbtjänsten förväntar jag mig att få ett svar som innehåller resultatet av att utföra min förfrågan.

Alla som någon gång har arbetat med Hotmail nyligen har redan blivit lite utsatta för webbtjänster: Passport-användarautentiseringssystemet är en av tjänsterna som ingår i Microsoft .NET-initiativet. Den är för närvarande tillgänglig gratis, så webbplatsskapare kan enkelt implementera användarautentisering på sin webbplats.

Grunderna

Principerna bakom webbtjänster är förvånansvärt enkla. Och de tillför inget nytt till världen av distribuerad datoranvändning och Internet:

• den person som är ansvarig för webbtjänsten bestämmer formatet för förfrågningar till sin webbtjänst och dess svar
• vilken dator som helst i nätverket gör en begäran till en webbtjänst
• en webbtjänst bearbetar en begäran, utför någon åtgärd och skickar sedan ett svar

Denna åtgärd kan till exempel vara att visa en aktiekurs, visa priset på en viss produkt, spara en post i en möteskalender, översätta text från ett språk till ett annat eller kontrollera ett kreditkortsnummer.

Standarder i grunden

Anledningen till att vi alla plötsligt är intresserade av webbtjänster är att de bygger på standarder, öppna protokoll för datautbyte och överföring.

Innan detta utvecklade många företag sina egna proprietära standarder och format. Och nu för att fungera behöver vi bara känna till enkel XML (eXtensible Markup Language), som sänds över det gamla välbekanta HTTP-protokollet. Det innebär att information om hur webbtjänster fungerar är tillgänglig för alla och webbutvecklare som är bekanta med dessa tekniker till yrket kan börja leka med webbtjänster idag.

Skillnaden mellan webbtjänster och andra tekniker som utvecklare har stött på (till exempel DCOM, named pipes, RMI) är att webbtjänster är baserade på öppna standarder, de är lätta att lära sig och dessa standarder stöds brett över hela världen och Windows-plattformar.

Simple Object Access Protocol (SOAP) är ett standardprotokoll utvecklat av W3C. Den definierar formatet för förfrågningar till webbtjänster.

Meddelanden mellan en webbtjänst och dess användare är förpackade i SOAP-kuvert. Meddelanden innehåller antingen en begäran om att utföra någon åtgärd eller ett svar - resultatet av att utföra denna åtgärd. Kuvertet och dess innehåll är kodat i XML och är ganska lätt att förstå. Så här ser en enkel SOAP-förfrågan ut när den skickas via HTPP till en webbtjänst:

Xmlns:env="http://www.w3.org/2001/06/soap-envelope">

xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
Storbritannien

Nyckelelementen i ett SOAP-kuvert är ganska enkla att känna igen: dessa är två parametrar ("postnummer") och ("land"), som finns inuti elementet under namnet. Detta element är namnet på webbtjänsten som vi gör begäran till. Andra data i kuvertet, såsom textkodning och SOAP-version, hjälper webbtjänsten att behandla förfrågan korrekt.

Och svaret kommer att se ut så här:

Xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

Env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
Ja

Detta meddelande är ännu lättare att tyda. Elementet i vår begäran har ändrats till elementet i svaret på begäran. Detta element innehåller endast ett element, vars värde indikerar om vårt postnummer är korrekt eller inte. Så genom SOAPs magi har vi skapat en fråga som gör ett användbart jobb för oss. Som svar via nätverket får vi en viss typ av svar i XML.

Nu om UDDI

Även om SOAP-protokollet är enkelt, skulle webbtjänster vara till liten nytta om vi inte hade något sätt att hitta dem. Lyckligtvis gick IBM, Microsoft och Ariba upp och skapade projektet Universal Description, Discovery and Integration (UDDI), som de hoppas ska bli en gemensam katalog över alla webbtjänster på webben.

UDDI-systemet tillåter företag att exponera sin webbtjänst för allmänheten. Denna katalog fungerar som en telefonbok för alla webbtjänster. Registrering i UDDI-katalogen är gratis, och grundarna av projektet hoppas att den här katalogen kommer att innehålla beskrivningar av alla, alla, alla tjänster på webben, så att det räcker med att vända sig till en för att hitta den önskade webbtjänsten UDDI-katalog.

Hur fungerar det hela

Så hur hittar jag rätt webbtjänst?

Låt oss föreställa oss att jag är en webbplatsutvecklare, och min klient bad mig lägga till en ny funktion på webbplatsen: Jag måste lägga till en postnummerkontroll på registreringsformuläret.

För att utföra denna kontroll skulle jag behöva skapa en databas med alla postnummer i alla 30 länder där vårt företag bedriver verksamhet, och sedan kontrollera att postnumret motsvarar den stad som anges i registreringen vid registreringen. Men jag har inte dessa uppgifter, och jag tror att det kommer att kosta en betydande summa pengar att samla in sådan data.

Istället för att lägga ut pengar för att köpa en databas, skriva koden själv, säkerställa integriteten och korrektheten av all data och felsöka skripten, går jag bara till UDDI-katalogen och ser om det finns en webbtjänst som kan göra jobbet för jag. När jag anländer till www.uddi.org gör jag en sökning och hittar en utmärkt tjänst från XYZ Corp.

Jag granskar noggrant definitionen av webbtjänstformatet (definitionen är skriven i WSDL (Web Services Description Language), och ser till att tjänsten gör precis vad jag behöver. Sedan kollar jag med mina kollegor om XYZ Corp.s rykte och får reda på det att den är solid och kontakta sedan XYZ Corp med en prisfråga. Om priset för att få tillgång till tjänsten ligger inom min budget, skriver jag en enkel JSP-sida för min sida som anropar XYZ Corps webbtjänst, och se och häpna, omedelbar verifiering. visas på webbplatsen.

Det är värt din tid

Även om du inte har något att göra med programmering eller teknik för webbutveckling är webbtjänster värda att lära dig mer om. Föreställ dig en bild av hur du diskuterar en ny webbplats med en kund och diskuterar alla funktioner i det nya projektet. Allt går bra: budgeten motsvarar kundens förväntningar, han gillade skissen av platsplanen och gillade exemplen på gränssnittet. Allt verkar fungera.

Och plötsligt kommer de ihåg någon mycket komplex funktion. Bara om det nämns blir din webbutvecklares ansikte grönt och han börjar kvävas och hosta. Det här är utvecklaren som ger dig en signal om att utvecklingen av den här funktionen kommer att kräva mycket pengar och tid eller helt enkelt inte är genomförbart med en sådan budget.

Släpp din rädsla! Jag är redo att garantera att det redan finns en webbtjänst på Internet som är redo att förse dig med den nödvändiga funktionen, och kostnaden för att använda denna webbtjänst kommer att vara mycket lägre än kostnaden för att självständigt utveckla dess analoga. På så sätt räddar du din utvecklare från onödig huvudvärk, din klient från att slösa pengar genom att bara spendera ett par minuter på att bläddra i UDDI-katalogen.

Tjänsteutveckling

Utvecklare behöver naturligtvis inte nöja sig med bara webbtjänster skapade av andra. Med hjälp av en av följande verktygssatser kan du skapa din egen webbtjänst och tillhandahålla dess tjänster till andra Internetanvändare.

Valet av verktyg för att utveckla webbtjänster är omfattande. Den innehåller verktyg från företag som Sun (Open Net), Microsoft (.NET), HP (e-tjänster) och IBM (Web Services). Det finns också ramverk med öppen källkod. Till exempel syftar Mono Project till att ersätta Microsofts .NET-verktygssats genom att tillhandahålla kompilatorer, runtime och bibliotek för att köra samma webbtjänster på alla plattformar, inklusive Unix.

Trots mångfalden av servrar och webbtjänstutvecklingsverktyg stöder de alla samma SOAP-protokoll, XML-språk och UDDI-system.

Minus

Innan jag helt överger min karriär som programmerare och ägnar mig åt att använda webbtjänster måste jag ställa mig frågan: "Det är en för rosa bild, vad är det för fel på den?" Tyvärr har webbtjänsternas stora potential ett pris:

• Att använda XML som dataöverföringsformat innebär att dina meddelanden blir mycket stora i storlek: själva XML-taggarna tar upp mycket utrymme och det lägger en viss börda på oss att skapa, överföra och tolka meddelanden.
• Eftersom vi använder fjärrdatorer för att utföra vissa funktioner förlitar vi oss helt och hållet på Internet, vilket skapar för många opålitliga länkar i kedjan mellan vår webbserver och webbtjänsten.
• Idag är det få företag som skapar webbtjänster, och få företag använder dem. Att felsöka och förbättra webbtjänstsystemet kräver fortfarande lång tid.
• Systemet för licensiering och avgifter för användning av webbtjänster har ännu inte accepterats av utvecklare. På grund av att det fortfarande finns för få webbtjänster försöker de flesta företag att göra ett gott intryck på sina potentiella kunder genom att medvetet sänka kostnaderna för tjänster och erbjuda förmånliga licensvillkor. Det kommer fortfarande att dröja innan den verkliga kostnaden för webbtjänster blir klar.

När webbtjänster tar sin plats och blir tillgängliga för alla kommer de att bli en ovärderlig hjälp för webbutvecklare. De kommer att ge oss flexibel tillgång till den fulla kraften hos alla datorer i nätverket. Det är dags för webbplatsbyggare att bli intresserade av webbtjänster och lära sig mer om vad de kan få ut av dem.

Översättning: Alexander Kachanov (http://webmascon.com)