Vad är webbtjänster och varför är de viktiga? Vad är en "webbtjänst" på vanlig engelska

Alexander Kachanov

Idén om webbtjänster utvecklades av sådana jättar inom datorindustrin som Sun, Oracle, HP, Microsoft och IBM. Den här idén är inget nytt, men det är ett stort steg framåt för att göra program lättare att komma åt via webben. Baserat på standardkommunikationsformat kan webbtjänster generellt förändra vår förståelse för 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. webbtjänst) och använda ett svar från henne på hennes webbplats eller applikation.

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 på nytt), kan jag använda tjänsterna för en webbtjänst som min webbplats kommer åt via Internet. När jag skickar en förfrågan med parametrar till webbtjänsten förväntar jag mig att få ett svar som kommer att innehålla resultatet av min förfrågan.

Alla som någonsin har arbetat i Nyligen Med het mail, har redan stött på några webbtjänster: Passport-användarautentiseringssystemet är en av tjänsterna som ingår i Microsoft .NET-initiativet. medan den är tillgänglig gratis, så att webbplatsskapare enkelt kan implementera användarautentisering på sin webbplats.

Grunderna

Principerna bakom webbtjänster är anmärkningsvä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 definierar 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 webbtjänsten
webbtjänsten behandlar begäran, utför någon åtgärd och skickar sedan ett svar

Den här åtgärden kan till exempel vara att visa en börsnotering, visa priset på en viss produkt, spara ett möte i kalendern, ö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 utbyte och överföring av data.

Dessförinnan utvecklade många företag sina egna proprietära standarder och format. Och nu, för arbetet, behöver vi bara känna till enkel XML (eXtensible Markup Language), som överförs ö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 - 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 på alla Unix- 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 packas i SOAP-kuvert (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 XML-kodat och är ganska lätt att förstå. Så här ser en enkel SOAP-förfrågan ut, som skickas via HTTP 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 lätta att känna igen: det här är två parametrar ( ("postnummer") och ("land")), som finns i ett element som kallas . Detta element är namnet på webbtjänsten som vi gör en 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. Element i vår fråga ändrats till ett element som svar på en begäran. Detta element innehåller endast ett element , vars värde anger om vårt postnummer är korrekt eller inte. Så med SOAPs magi har vi skapat en fråga som gör användbart arbete för oss. Som svar får vi via nätverket en viss typ av svar i XML.

Nu om UDDI

Även med SOAP-protokollets enkelhet, skulle det vara liten användning i webbtjänster om vi inte hade något sätt att hitta dem. Lyckligtvis har IBM, Microsoft och Ariba tagit initiativet och skapat 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. Den här katalogen fungerar som en telefonbok för alla webbtjänster. Registrering i UDDI-katalogen är gratis, och grundarna av projektet hoppas att denna katalog kommer att innehålla beskrivningar av alla-alla-alla tjänster över hela webben, så att endast en UDDI-katalog räcker för att hitta den önskade webbtjänsten.

Hur det hela fungerar

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 att lägga till på webbplatsen ny funktion: Behöver lägga till postnummervalidering i 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 stämmer överens med den stad som anges i registreringen under 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 köpa en databas, skriva min egen kod, se till att all data är konsekvent och korrekt, och felsöka skript, går jag bara till UDDI-katalogen och letar efter en webbtjänst som kan göra jobbet åt mig. . När jag kommer till http://www.uddi.org/ gör jag en sökning och hittar en fantastisk tjänst från XYZ Corp.

Jag granskar noggrant definitionen av webbtjänstformatet (definitionen är skriven i WSDL (Web Services Description Language), ser till att tjänsten gör precis vad jag behöver. Sedan frågar jag mina kollegor om XYZ Corp.s rykte, jag får reda på att den är solid , och sedan kontaktar jag XYZ Corp. för ett pris, om priset för att få tillgång till tjänsten ligger inom min budget, skriver jag en enkel JSP-sida för min webbplats som anropar XYZ Corps webbtjänst, och hej, omedelbar utcheckning visas på webbplatsen postnummer.

Det är värt att ta sig 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, diskuterar alla funktioner i ett nytt projekt. Allt går bra: budgeten motsvarar kundens förväntningar, han gillade konturerna av platsplanen, han 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 själv börjar kvävas i en 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örbar med en sådan budget.

Släpp rädslan! Jag kan slå vad om att det redan finns en webbtjänst på webben 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 utveckla dess analog själv. Därmed räddar du din utvecklare från onödig huvudvärk, din klient från avfall pengar, bara spendera ett par minuter på att bläddra i UDDI-katalogen.

Tjänsteutveckling

Utvecklare behöver förstås inte nöja sig med bara webbtjänster skapade av andra. Med hjälp av någon av följande verktygssatser kan du skapa din egen webbtjänst och tillhandahålla dess tjänster till andra invånare i nätverket.

Valet av verktyg för att utveckla webbtjänster är omfattande. Den innehåller verktygssatser från företag som Sun (Open Net), Microsoft (.NET), (e-tjänster) och IBM (Web Services). Det finns också ramverk med öppen källkod. Till exempel försöker Mono Project ersätta Microsoft .NET-verktygssatsen genom att tillhandahålla ett kompileringssystem (kompilatorer), kodexekvering (runtime) och bibliotek (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: "Den här bilden är för rosa. Vad är det för fel på den?". Tyvärr finns det ett pris att betala för webbtjänsternas stora potential:

Att använda XML som dataöverföringsformat resulterar i att dina meddelanden blir mycket stora: själva XML-taggarna tar upp mycket utrymme, och detta lägger en viss börda på oss när det gäller 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 på Internet, vilket skapar för många opålitliga länkar i kedjan mellan vår webbserver och webbtjänst.
Just nu är det få företag som skapar webbtjänster, och få företag använder dem. Det tar fortfarande lång tid att felsöka och förbättra webbtjänstsystemet.
Systemet för licensiering och avgifter för användning av webbtjänster har ännu inte antagits av utvecklare. På grund av att det fortfarande finns för få webbtjänster försöker de flesta företag 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änsttjänster är klarlagda.

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 på webben. Det är dags för de som gör webbplatser att intressera sig för webbtjänster och lära sig mer om vad de kan få ut av dem.

Anteckning: Användningsområden. Fördelar. Funktioner för att utveckla webbtjänster för .NET-plattformen. Beskrivning och upptäckt av en webbtjänst

Vad är en XML-webbtjänst?

Med utvecklingen av informationsteknologin har olika tillvägagångssätt för att skriva program uppstått: modulära programmering, händelsestyrd programmering, komponentorienterad programmering och design. Den logiska fortsättningen på dessa tillvägagångssätt var serviceinriktad mjukvaruutveckling.

Användningen av tjänsteorienterade tillvägagångssätt gör att vi kan prata om återanvändning ( återanvändning ) på makronivå (servicenivå), till skillnad från mikronivå (objektnivå). Ett tjänsteorienterat tillvägagångssätt innebär användning av enkla och allmänt accepterade standarder, vilket gör att en mängd olika applikationer kan använda varandras funktionalitet. Tjänster kan skrivas med en mängd olika programmeringsspråk, på en mängd olika plattformar. Dessutom kan tjänster distribueras separat eller som en del av ett mjukvarupaket var som helst i världen och kommer därmed att ge tillgång till deras funktionalitet över nätverket.

Låt oss ringa service en resurs som implementerar en affärsfunktion och har följande egenskaper:

är återanvändbar;
definieras av ett eller flera explicita teknikoberoende gränssnitt;
löst kopplade till andra liknande resurser och kan anropas genom kommunikationsprotokoll som tillåter resurserna att interagera med varandra.

Ett specialfall av en tjänst är en XML-webbtjänst.

XML Web Serviceär en speciell typ av webbapplikation som:

distribueras på en webbserver;
publicerar webbmetoder som kan anropas av externa kunder;
väntar på mottagandet av HTTP-förfrågningar, som är kommandon för att anropa webbmetoder;
exekverar webbmetoder och returnerar resultat.

Till skillnad från en traditionell webbapplikation har en webbtjänst inget användargränssnitt. Istället har den ett API, det vill säga en webbtjänst tillhandahåller funktioner (webbmetoder) som kan anropas på distans (till exempel över Internet). Webbtjänsten är inte utformad för att tjäna slutanvändare. Dess syfte är att tillhandahålla tjänster till andra applikationer, oavsett om de är webbapplikationer, GUI-applikationer eller konsolapplikationer.

En webbtjänst kan ge realtidsinformation om aktiekurser, kontrollera kreditkort eller rapportera vädret. Webbtjänster är lika olika som konventionella applikationer.

Webbtjänster är inte ett visst företags egendom. Det är en industristandard baserad på öppna protokoll (SOAP, HTTP, etc.). Webbtjänster distribueras på olika plattformar (inklusive servrar som kör Windows eller UNIX). Webbtjänster kan utvecklas med många utvecklingsverktyg (från en textredigerare till Microsoft Visual Studio-familjen).

Metoder för de flesta webbtjänster anropas av HTTP-förfrågningar som innehåller SOAP-meddelanden SOAP är ett XML-språk (XML-vokabulär) för anrop av fjärrprocedurer över HTTP och andra protokoll (fullständig beskrivning av SOAP http://www.w3.org/TR/SOAP) .

Platsen för webbtjänster bland andra tekniker för fjärrsamtal

Det finns många fjärranropsprotokoll och teknologier: Microsoft Distributed Component Object Model (DCOM), Object Management Groups Common Object Request Broker Architecture (CORBA), Suns Remote Method Invocation (RMI), . NET Remoting, XML Web Services.

Alla dessa komponentorienterade teknologier (DCOM, CORBA och RMI) har använts framgångsrikt i intranätapplikationer i många år. De ger en robust, skalbar arkitektur. Det finns dock två stora problem med att använda dessa tekniker på Internet. För det första interagerar de inte bra med varandra. Alla teknologier fungerar på objekt, men skiljer sig väsentligt i detaljer: livscykelhantering, stöd för konstruktörer och graden av arvsstöd. Den andra, viktigare aspekten är att fokus på RPC-interaktioner leder till konstruktionen av tätt kopplade system baserade på explicita objektmetodanrop.

Till skillnad från dessa tekniker, XML Web Services och . NET Remoting fullt implementera objektorienterat förhållningssätt för webbprogrammering.

XML Web Service- en komponent som förser Internetklienter med en uppsättning API-funktioner eller webbmetoder. XML är en del av namnet eftersom webbtjänster och deras kunder använder det för att utbyta data. Webbtjänster bygger på öppna standarder som HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol - en internetstandard som beskriver hur applikationer kan interagera, det vill säga anropa varandras metoder, med hjälp av HTTP och andra protokoll ). Huvuduppgiften för webbtjänster är att tillhandahålla interprogram interaktion. Många körs på UNIX-servrar och nås av Windows-klienter. Data som skickas till webbtjänster serialiseras till XML och skickas i SOAP-paket. Metadata om innehållet i sådana meddelanden lagras i webbtjänstens WSDL-kontrakt och XSD-scheman. Den största fördelen med detta tillvägagångssätt är läsbarheten av metadata. En utvecklare kan enkelt se hela beskrivningen av en webbtjänst och till och med skapa sin egen modul som analyserar SOAP-paket.

.NET-fjärrkontroll tillhandahåller infrastruktur för distribuerade objekt. Det är mycket mer komplext än en enkel webbtjänstarkitektur baserad på meddelandeöverföring. . NET Remoting inkluderar överföring av parametrar efter referens och värde, callbacks, aktivering av flera objekt och policyer för livscykelhantering. För att kunna använda dessa funktioner måste klientapplikationen vara skicklig i alla teknologier. Data in. NET Remoting skickas i binärt eller SOAP-format. Men i vilket fall som helst, finns metadata om strukturen för den överförda informationen i den vanliga språkkörningen. Utan en gemensam språkkörning (CLR) kommer klientapplikationen inte att kunna analysera . NET Remote SOAP headers. Det är. NET Remoting har betydligt högre krav än webbtjänster.

Utveckling av webbtjänster på .NET-plattformen

Det finns många sätt att skriva webbtjänster. De kan utvecklas för hand eller med hjälp av SOAP-verktyg från Microsoft, IBM mfl. Skriva webbtjänster med Microsoft. NET har två fördelar:

.NET Framework förenklar utvecklingsprocessen avsevärt genom att tillhandahålla ett klassbibliotek och automatisera individuella utvecklingssteg;
Webbtjänster skrivna med .NET Framework är hanterade applikationer. Det vill säga, i sådana applikationer finns det inga problem med minnesläckor, felaktigt initierade pekare och andra typiska programmeringsproblem.

Skapande

Låt oss utveckla en enkel AdditionService webbtjänst som utför tillägg av två siffror. Det kommer bara att ha en Add-metod som tar två heltal som en parameter och returnerar ett heltal också. AdditionService visar flera viktiga principer för programmering av webbtjänster med hjälp av Microsoft .NET Framework.

Webbtjänster implementeras som ASMX-filer. ASMX är ett speciellt filnamnstillägg registrerat med ASP .NET (mer specifikt ASP.NET HTTP-hanteraren) i huvudkonfigurationsfilen för ASP .NET Machine.config.
ASMX-filer börjar med @WebService-direktivet. Detta direktiv måste innehålla åtminstone attributet Class, som anger den klass som webbtjänsten består av.
Webbtjänstklasser kan ha valfria WebService-attribut. I detta exempel ett sådant attribut anger namnet på webbtjänsten och beskrivningen som visas på HTML-sidan när användaren anropar AdditionService.asmx i webbläsaren.
Webbmetoder deklareras genom att tilldela WebMethod-attributet till de publika metoderna för webbtjänstklassen. För hjälpmetoder som används internt men inte är tillgängliga för externa klienter utelämnas detta attribut helt enkelt.
HTTP, XML och SOAP är "osynliga". XML-data och SOAP-meddelanden hanteras av .NET Framework.

AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>använder System som använder System.Web.Services klass AddService ( public int Add (int a, int b) ( return a + b ) )

Trots sin ringa storlek är AdditionService.asmx en komplett webbtjänst när den installeras på en ASP.NET-webbserver. Dess metoder anropas med SOAP, HTTP GET och HTTP POST, och det kan returnera resultat som SOAP-svar eller som enkla XML-omslag.

Med hjälp av bakgrundskoden kan webbtjänstklasserna tas ur asmx-filer till separata filer.

Webbtjänster stödjer användningen komplexa datatyper som in- eller utgångsparametrar. Komplexa datatyper stöds eftersom XML gör det enkelt att serialisera de flesta datatyper. Men när en webbtjänst testas automatiskt genererar ASP .NET inte testsidor för metoder som accepterar komplexa typer data. Detta beror på att du inte kan skicka komplexa datatyper till webbmetoden med HTTP GET och POST.

Webbtjänster låter dig anropa dina egna metoder asynkront. Ett asynkront samtal återkommer omedelbart, oavsett hur lång tid det tar för webbtjänsten att behandla samtalet. Asynkrona samtal är användbara när ett samtal tar lång tid att bearbeta. Applikationen ringer, fortsätter sedan att köra utan att vänta på resultatet av samtalet och tar senare emot resultatet av det asynkrona samtalet. Resultatet erhålls när webbmetoden anropas igen vid en lämplig tidpunkt för applikationen, eller genom att prenumerera på ett meddelande om slutet av samtalsbehandlingen av webbtjänsten (delegatmekanism).

Webbtjänster kan skapas med hjälp av verktyg som t.ex Microsoft Visual Studio 2005. För att skapa webbtjänster finns det separat typ ASP .NET Web Service-projekt. Visual Studio genererar en asmx-fil, en fil med bakgrundskod för att beskriva webbtjänstklasser, en webbtjänstkonfigurationsfil etc. När projektet startas för exekvering kompileras tjänsteklasserna och asmx-filen öppnas i ett webbläsarfönster.

Beskriva webbtjänster med hjälp av kontrakt

För att andra utvecklare ska kunna använda AdditionService måste de veta vilka metoder den exponerar, vilka protokoll den stöder, metodsignaturer och webbtjänstadressen (URL). All denna och annan information kan beskrivas i WSDL (Web Service Description language).

Web Service Discovery

Hur vet andra utvecklare om AdditionServices existens?

För det första med hjälp av DISCO (förkortning av ordet upptäckt) - en filmekanism för att söka efter lokala webbtjänster, det vill säga en mekanism för att få en lista över tillgängliga webbtjänster från DISCO-filer som finns på webbservrar. Dessutom innehåller DISCO-filer register över var WSDL-kontrakten för de tillgängliga tjänsterna finns. DISCO-fil är en XML-fil med poster.

Det är också möjligt att använda VSDISCO-filer, som liknar DISCO-filer, men deras innehåll är resultatet av en dynamisk sökning efter webbtjänster i de angivna katalogerna och alla kapslade underkataloger. ASP .NET mappar filnamnstillägget .vsdisco till en HTTP-hanterare som söker i den givna katalogen och dess underkataloger efter asmx och disco och returnerar ett dynamiskt genererat DISCO-dokument. Av säkerhetsskäl är dynamisk sökning inaktiverad i vissa versioner av .NET Framework, men du kan aktivera det genom att redigera poster i filen Machine.config.

Men hur är sökningen efter webbtjänster i det globala nätverket? För att söka efter webbtjänster i det globala nätverket utvecklade Microsoft, IBM och Ariba tillsammans UDDI (Universal Description Discovery and Integration) – en specifikation för att bygga distribuerade databaser som gör att du kan hitta webbtjänster. UDDI stöds av hundratals företag. UDDI-webbplatser är själva webbtjänster. Vem som helst kan publicera sitt register baserat på UDDI. De flesta utvecklare använder aldrig UDDI API direkt. Istället nås UDDI-register av utvecklingsverktyg. De genererar också omslagsklasser för de upptäckta och utvalda webbtjänsterna.

Resultat

En XML-webbtjänst är en mjukvarukomponent som ger funktionalitet som de flesta olika system, stödjande standarder som XML- och HTTP-webbtjänstklienter kan vara antingen lokala eller fjärrtillämpningar. Webbtjänster låter dig skapa strukturer som gör det lättare att integrera olika system baserat på enkla, allmänt accepterade standarder.

Vi har granskat allmänna begrepp mekanism « webb-tjänster". Låt oss fräscha upp lite kunskap.

Webbtjänster används för att utbyta data mellan en server och en klient; XML-formatet används för att "paketera" data för ömsesidig förståelse mellan båda deltagare i kommunikationen.

KAPITELjag

GENOMFÖRANDE EXEMPELWEBB-SERVICE I SYSTEMET "1C: FÖRETAG"

UPPGIFT: Det är nödvändigt att skapa en webbtjänst, med hänvisning till vilka kunder kan bestämma all nödvändig information för sina applikationer.

Uppgiften är en demonstration och fungerar endast som ett exempel för att förstå och lära sig mekanismenwebb-tjänster.

LÖSNING:

Steg 1. Låt oss skapa en ny infobas utan konfiguration för att utveckla en ny konfiguration.

Steg 2 Låt oss lägga till några nya objekt till konfigurationen

Katalog "klienter";

Dokument "Ansökan";

Uppräkning "Status för applikationer".

Steg 3 Låt oss skapa ett nytt XDTO-paket.

Varför och varför skapar vi ett XDTO-paket? Du kan läsa mer om att använda XDTO-mekanismen i "Kapitel 16. Developer's Guide" och.

Låt oss bara kort notera att XDTO-mekanismen är ett universellt sätt att presentera data för interaktion med olika externa datakällor och mjukvarusystem.

I vårt fall skapas ett XDTO-paket för att beskriva returvärdet för webbtjänsten.

Expandera grenen "Allmänt" → "XDTO-paket" → Lägg till...

Ange namnet på XDTO-paketet " Dokumentdata” och dess namnområde http://localhost/request eller http://192.168.1.76/request (för att underlätta förståelsen och inlärningsprocessen anger vi den lokala IP-adressen för datorn där webbservern är installerad (webbservrar som stöds: IIS eller Apache)). Varje webbtjänst kan identifieras unikt med sitt namn och URI för namnområdet som den tillhör.

Vårt paket innehåller två typer av XDTO-objekt:

1) Kund- för att överföra data från katalogelementet "Clients".

- namn ;

2) dokumentera- för att överföra data från dokumentet "Ansökan"

Den här typen av XDTO-objekt kommer att innehålla följande egenskaper:

- Kund- Kundtyp från namnområdet http://192.168.1.76/request; är en referens till XDTO-objektet vi definierade ovan;

- Status- strängtyp från http://www.w3.org/2001/XMLSchema namnutrymme;

- Nummer- strängtyp från http://www.w3.org/2001/XMLSchema namnutrymme.

Steg 4 Lägg till en ny webbtjänst i konfigurationen

Utöka grenen "Allmänt" → "Webbtjänster" → Lägg till ...

För webbtjänsten anger du följande egenskapsvärden:

Namn - Dokumentdata

URI-namnområden - http://192.168.1.76/request

XDTO-paket - Dokumentdataellerhttp://192.168.1.76/request

Publikationsfilnamn - begäran.1cws

Steg 5 För den skapade webbtjänsten definierar vi operationen " hämta data»

Operationsegenskapsvärden:

Returtyp - Dokument (http://192.168.1.76/request)

Eventuellt tomt värde - Sann

Procedurnamn - hämta data.

Steg 6 Drift hämta data definiera Kundparametern med följande värden egenskaper:

Värdetyp - typ sträng från http://www.w3.org/2001/XMLSchema namnrymden;

Överföringsriktning - inmatning.

Steg 7 Låt oss öppna modulen för den skapade webbtjänsten och placera funktionen Get() i den, som kommer att exekveras när denna webbtjänst anropas.

Funktion GetData(Customer) // Hämta typerna av XDTO-objekt ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "Customer"); RequestType = FactoryXDTO.Type("http://192.168.1.76/request", "Dokument"); // Hämta klienten ClientReference = Directories.Clients.FindByName(Customer); Om inte ValueFilled(ClientReference) Returnera sedan Undefined; EndIf; Request = Ny begäran; Request.Text = "VÄLJ FÖRSTA 1 | Ticket.Reference, | REPRESENTATION(Ticket.Status) AS Status, | Ticket.Number |FROM | Document.Ticket AS Ticket |WHERE | Ticket.Client = &Client"; Request.SetParameter("Client", ClientReference); QueryResult = Query.Execute(); Om QueryResult.Empty() Returnera sedan Undefined; EndIf; Selection = QueryResult.Select(); Selection.Next(); Document = Selection.Reference.GetObject(); // Skapa ett XDTO-biljettobjekt Ticket = FactoryXDTO.Create(TicketType); Application.Numder = Sample.Number; Client = FactoryXDTO.Create(ClientType); Client.Name = ClientReference.Name; Application.Customer = Klient; Application.Status = Selection.Status; // Returförfrågan Returförfrågan; EndFunctions

Steg 8 Låt oss publicera den skapade webbtjänsten på webbservern.

Konfiguratormenyalternativ: "Administration" → "Publicera på en webbserver".

På fliken "Webbtjänster" ställer du in flaggan "Publicera webbtjänster" och markerar även rutan bredvid vår nya webbtjänst.

KAPITELII

EXEMPEL PÅ REFERENS TILLWEBB- 1C:FÖRETAGSSERVICE FRÅN EN TREDJEPARTSAPPLIKATION

Huvudsyftet med webbtjänstmekanismen i 1C:Enterprise är att överföra nödvändiga data till tredjepartsapplikationer.

Låt oss överväga ett exempel på att utveckla en applikation i Delphi som anropar vår webbtjänst från det första avsnittet i den här artikeln.

Steg 1. Låt oss skapa nytt projekt och placera flera kontroller på formuläret

Textfält - används för att visa information mottagen från webbtjänsten;

Två knappar - rensa textfältet och komma åt webbtjänsten;

Inmatningsfältet är en parameter som skickas till webbtjänsten.

Steg 2 Importera WSDL-filen

Som ett resultat får vi en ny modul begäran(vi definierade ett sådant namn direkt i 1C). Denna modul innehåller all nödvändig information om webbtjänsten.

Steg 3 Skriv en webbtjänstsamtalshanterare

Variabeln DocumentDataPortType är redan definierad i modulen begäran

Steg 4 Starta applikationen och kontrollera.

KAPITELIII

EXEMPEL PÅ REFERENS TILLWEBB-SERVICE I SYSTEMET "1C: FÖRETAG"

Steg 1. Låt oss skapa en ny extern bearbetning med namnet "WEB_Service"

Steg 2 För bearbetning definierar vi en ny form

Steg 3 Ange flera detaljer för formuläret

Klient - skriv "String"

ClientReturn - skriv "String"

NumberReturn - skriv "String"

StatusReturn - typ "String".

Vi kommer att visa detaljerna i formuläret.

Steg 4 Låt oss lägga till kommandot form " För att få data»

Ange en kommandohanterare

&OnClient Procedur GetData(Command) GetDataOnServer(Client); Procedurslut Procedur GetDataOnServer(Client) // Skapa en WS-proxy baserat på länken och kör Get()-operationen Definition = New WSDefinitions("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl") ; Proxy = New WSProxy(Definition, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); RequestData = Proxy.GetData(Client); Om OrderData = Odefinierat Då ClientReturn = "Odefinierat"; StatusReturn = "Odefinierad"; ReturnNumber = "Odefinierat"; Lämna tillbaka; EndIf; CustomerReturn = RequestData.Customer.Name; StatusReturn = RequestData.Status; ReturnNumber = RequestData.Numder; Slutprocedur

1C:Enterprise kan använda webbtjänster som tillhandahålls av andra leverantörer på två sätt:

Genom att använda statisk länkar skapade i konfigurationsträdet;

"plus": hög arbetshastighet;

"minus":återimportera WSDL-beskrivningen med hjälp av konfiguratorn och spara den ändrade konfigurationen.

Genom att använda dynamisk länkar skapade med hjälp av det inbyggda språket

(respektive "nackdelar" med statiska för dynamiska är "plus")

KAPITELIV

FELSÖKNING AV WEBTJÄNSTER I 1C:ENTERPRISE-SYSTEMET

För en lokal webbtjänst behöver du:

Steg 1. Sätt på klienten där 1C-systemet startas filen webservicecfg.xml med följande innehåll

Steg 2 Att fila standard. vrd publicera konfiguration lägg till rad

Steg 3 Välj menyalternativet i konfiguratorn

"Felsökning" → "Anslutning" → "Automatisk anslutning" → "Webbtjänster på servern"

Steg 4 Klicka på knappen "OK".

För serverversionen måste du också köra 1c-servern i felsökningsläge med nyckeln /debug

Vad är en webbtjänst?

Alla som någonsin har jobbat med het mail, har redan stött på några webbtjänster: Passport-användarautentiseringssystemet är en av tjänsterna som ingår i Microsoft .NET-initiativet. medan den är tillgänglig gratis, så att webbplatsskapare enkelt kan implementera användarautentisering på sin webbplats.

Grunderna

Principerna bakom webbtjänster är anmärkningsvä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 definierar 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 webbtjänsten
webbtjänsten behandlar begäran, utför någon åtgärd och skickar sedan ett svar

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 utbyte och överföring av data.

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

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

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

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

Nu om UDDI

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 denna katalog kommer att innehålla beskrivningar av alla-alla-alla tjänster över hela webben, så att endast en UDDI-katalog räcker för att hitta den önskade webbtjänsten.

Hur det hela fungerar

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 postnummervalidering i registreringsformuläret.

Istället för att köpa en databas, skriva min egen kod, se till att all data är konsekvent och korrekt, och felsöka skript, går jag bara till UDDI-katalogen och letar efter en webbtjänst som kan göra jobbet åt mig. . När jag går till www.uddi.org gör jag en sökning och hittar en fantastisk tjänst från XYZ Corp.

Det är värt att ta sig tid

Släpp rädslan! Jag kan slå vad om att det redan finns en webbtjänst på webben 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 utveckla dess analog själv. På så sätt räddar du din utvecklare från onödig huvudvärk, din klient från att slösa pengar, bara spendera ett par minuter på att bläddra i UDDI-katalogen.

Tjänsteutveckling

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

Minus

Att använda XML som dataöverföringsformat resulterar i att dina meddelanden blir mycket stora: själva XML-taggarna tar upp mycket utrymme, och detta lägger en viss börda på oss när det gäller 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änst.
Just nu är det få företag som skapar webbtjänster, och få företag använder dem. Det tar fortfarande lång tid att felsöka och förbättra webbtjänstsystemet.
Systemet för licensiering och avgifter för användning av webbtjänster har ännu inte antagits av utvecklare. På grund av att det fortfarande finns för få webbtjänster försöker de flesta företag 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änsttjänster är klarlagda.

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 artiklar: Praktisk användning av webbtjänster i IBM Lotus Domino 7

https://www..jsp?series_title_by=Practical+using+web services+in+ibm+lotus+domino+7

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

Du kanske har stött på referenser till webbtjänster i tekniska artiklar, mjukvaruprodukter eller till och med i dialoger med kollegor. Tydligen behöver någon webbtjänster och det är viktigt, men efter att ha träffat definitioner som "XML-grammatik för att definiera uppsättningar av slutpunkter för meddelanden", bestämde du dig för att så komplicerade saker inte bör röras.

Lyckligtvis kan webbtjänster förklaras på ett sätt som alla förstår 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) applikationer i IT-världen ständigt expanderar.

Webbtjänster kan ses som en bil: du behöver inte veta på teknisk nivå hur kolvar, kamaxlar och bränsleinsprutare fungerar - du kan köpa en bil, köra den och prata om bilar med vänner (såvida naturligtvis, de är mekaniker). Det är samma sak med webbtjänster, som IT-proffs behöver du 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 de dolda lågnivåteknikerna, eftersom programvaruleverantörer och öppen källkodsgemenskap har gjort mycket under de senaste åren för att separera webbtjänsters gränssnitt från lågnivåuppgifter. Detta gör att du kan arbeta genom att helt enkelt koppla ihop komponenter utan att behöva fördjupa dig i långa XML-meddelandeformateringsdokumentation.

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 är 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 konsumera webbtjänster, och vi kommer att beröra detta i detalj senare.

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

Vad är en webbtjänst?

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

Kommunikation mellan tre eller flera maskiner

Även om exemplen är baserade på transaktioner inom en eller två maskiner, kan webbtjänster också användas för att kommunicera mellan flera maskiner. Till exempel kan transaktioner vidarebefordras eller lagras av en mellanliggande enhet, eller så kan ett anrop till en webbtjänst på en server utlösa ett anrop till en tjänst på en annan.

I slutet av den här artikeln, när vi tittar på verklig SOA, kommer vi att prata om webbtjänster som interagerar på flera maskiner, eftersom det är så SOA alltid fungerar.

En webbtjänst är en abstrakt komponent, precis som begreppet mänskligt samtal är abstrakt. Dialogen involverar två eller flera personer som talar ett språk de kan. Deras språk definierar de ord de använder och hur dessa ord bildar meningar. Vanligtvis har dialogen 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, prata i telefon, skicka meddelanden till varandra via post eller chatt.

Det har i alla fall dialogen komplex struktur och kan ske på olika sätt, beroende på antalet personer som kommunicerar, vilket kommunikationsspråk som används för kommunikationsteknologier, 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 den med vanlig dialog - program kommunicerar på ett språk de kan, ibland över ett nätverk. Program kan antingen placeras på samma dator eller finnas på olika maskiner i olika delar av världen, anslutna via Internet med routrar och servrar. Den goda nyheten är att program och datorer inte behöver vara samma sak. Med webbtjänster kan två Microsoft .NET-program på samma bärbara dator kommunicera, samt ett Java-program på en kanadensisk iSeries-server med ett C++-program på en Linux-dator från Kina.

Webbtjänstkommunikation använder följande standardtekniker:

xml. Språket (dataformatet) som används av webbtjänstkomponenter.
SOAP-protokoll. XML-meddelanden utbytt mellan program
Web Services Description Library (WSDL). En 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 ta upp detta senare i artikeln, men eftersom UDDI är valfritt använder många webbtjänster det inte.

Lite terminologi: Publicera och använda webbtjänster

Innan vi börjar förklara våra termer, låt oss titta på en del av terminologin som är förknippad med webbtjänster.

När vi pratar om att publicera en webbtjänst menar vi 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 filerna som definierar webbtjänsten, är i XML-format. Figur 1 visar strukturen för en enkel XML-fil.

Figur 1. Grundläggande XML-struktur

Som du kan se är viss information i filen (som förnamn, efternamn) omgiven av taggar omgivna av triangulära parenteser. 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 för XML liknar den för andra programmeringsspråk, så program som interagerar med webbtjänster behöver inte analysera XML-filer direkt.
XML-filer är textfiler och kan läsas av en människa (med andra ord, om du kan XML-språket 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 använda vad 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, eller ett PersonName, som innehåller två strängsubelement, FirstName och LastName.
Vid behov tillåter namnutrymmen dessutom att flera element med samma namn har olika definitioner. Till exempel kan StockPrice-elementet i ett namnområde inkludera en ticker-symbol och ett pris, medan det i ett annat namnutrymme 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-språket är stelbent, 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 split, binärt eller "self-made" format).

Men dessa frågor är irrelevanta jämfört med fördelarna med XML-formatet.

SOAP: skickade meddelanden

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

Instruktionen som beskriver formateringsregler för 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-header (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 på lite olika sätt. 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 välskriven klient eller server kan dock bearbeta alla meddelanden som är välskrivna enligt SOAP-instruktionerna.

Dessutom finns det några viktiga skillnader mellan WSDL 1.1 och WSDL 2.0 instruktioner. Även om 2.0-instruktionen fortfarande är i slutskedet 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 det att vara svårt för dig att extrahera all information därifrån, 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 måste samlas in av klientapplikationen för att kunna konstruera ett SOAP-meddelande. Beskrivningar av delar av en WSDL-fil och deras gemensamt arbete kommer inte att finnas i den här artikeln.

Det är här tekniken kommer till undsättning igen. Som utvecklare behöver du inte läsa, analysera och förstå innehållet i en WSDL-fil. 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 inte bara du kan använda bibliotek och verktyg, men också säkert du kommer. Det finns många undantag, hicka och komplexitet för alla webbtjänstkomponenter, och du bör titta närmare på använder sig av Webbtjänst, och inte demontering, följt av en detaljerad studie av varje komponent.

Protokoll: hur meddelanden skickas

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

Och de överförs vanligtvis över nätverket (och/eller Internet) med hjälp av HTTP-protokollet, på ungefär 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.

I en WSDL-fil definieras vanligtvis protokollet som används för att skicka ett SOAP-meddelande 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 är vanligtvis löst kopplade till tjänster, det vill säga de tjänster som krävs för att programmet ska köras är inte direkt bundna till det, precis som programmet inte är bundet 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.

Ett verkligt exempel på svaga band ä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 middagen betalar alla 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 tätare kopplingar. Du har en fast uppsättning verktyg för att uppnå förutbestämda mål. När du lämnar garaget sätter du på backväxeln och trycker på gasen. Vid vänstersväng 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 koordinerat, och vart och ett av dess element är kopplat till andra.

UDDI

UDDI är en standard för att skapa en katalog över webbtjänster som tillhandahålls av valfritt antal program. Det är ungefär som en telefonbok för webbtjänstleverantörer. Klienter kan slå upp den information de behöver i UDDI-registret och registret returnerar den data de behöver 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 det faktum att det är ett valfritt inslag i webbtjänster, och när de ges valet att använda det eller inte väljer många att inte använda det.

De flesta organiserade företagsmiljöer med många interna webbtjänster har UDDI-register. Det är bra att ha en UDDI företagswebbplats 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 leverantörer. Om klienter söker upp tjänster via UDDI så 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 när man ringer tjänster om leverantören arbetar med känslig information? Det är trots allt tydligt 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 entydigt besvara. Det finns olika system som du kan använda beroende på situationen, till exempel:

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

Dessutom kan meddelandehantering inte alltid använda HTTP, så du kan inte bara använda webbtjänstsäkerhet utöver befintlig HTTP-säkerhet.

Det finns flera riktlinjer som täcker dessa och andra aspekter av webbtjänsters sä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äkerhetsinstruktioner, implementerar befintliga 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, buntade samman till en ganska stor bunt, vanligen kallad WS-*-instruktionerna. Tillsammans täcker de många av de designfrågor som dyker upp när du sätter ihop många webbtjänster i en miljö. WS-*-standarderna hanterar frågor som:

Säkerhet
Pålitlighet
Meddelandeutbyte
Transaktioner
Service kvalitet

Detta antal standarder är nödvändigt eftersom meddelanden mellan en webbtjänstklient och server i en produktionsmiljö kan vara mycket mer komplex än en enkel begäran/svar. Hur ser man till exempel till att meddelandet når leverantören och återkommer till klienten? Vad händer om 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 mjukvaruleverantörer innebär arbetet med dessa standarder både utmaningar och möjligheter. Flera leverantörer marknadsför hela mellanvarupaket för webbtjänster, ofta kallade Enterprise Service Bus, eller ESBs, som hanterar alla eller åtminstone några av ovanstående uppgifter på en gång. 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.

Serviceorienterad arkitektur

Och slutligen, serviceinriktad arkitektur. I de flesta fall är det bara en kombination av allt ovan: löst kopplade webbtjänster från olika leverantörer, som interagerar enligt accepterade standarder (kanske med ESB:er) och sätts ihop av olika program som tar data från tjänsterna och använder dem på olika sätt .

Eftersom SOA är en mjukvaruarkitektur är det mycket samordning och planering involverat i att bygga den. Det är inte bara ett gäng tjänster som blandas ihop; det är organisationen av hur tjänster sätts ihop och publiceras, vilka hanteringsverktyg och mellanprogram som används och hur tjänster och systemet som helhet övervakas och hanteras.

Ser man mer globalt så är SOA också en typ av tänkande. Det tvingar oss att inte tänka på oberoende stora program, utan att uppfatta allt som möjliga komponenter som kan publiceras och användas i produktionen. Istället för rika applikationer tänker du på specifika och väldefinierade tjänster – vilket är vad webbtjänster är.

Varför är det viktigt?

Vid det här laget vet du redan ett och annat om hur webbtjänster fungerar - klienten läser leverantörens WSDL-fil, formaterar och skickar ett SOAP-meddelande i enlighet med detta, och får ytterligare ett SOAP-meddelande som svar. Så varför är det så viktigt? Vad är problemet?

En del av betydelsen av tjänster ligger i det faktum 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 är unika för olika program, eller med funktioner på API-nivå som program på andra språk inte kunde fungera med. Genom att använda XML i alla webbtjänster innebär standarder 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 utmaningarna när man arbetar med olika teknologier från olika tillverkare har alltid varit behovet av att få alla dessa olika program att kommunicera med varandra och utbyta data. Nu när alla dina applikationer kan leverera och/eller konsumera webbtjänster är det otroligt enkelt att kommunicera mellan dem.

En annan fördel med webbtjänster är att kunder och leverantörer kan vara på olika maskiner och använda olika hårdvara och mjukvara utan att störa 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-hanterare.

När alla dessa faktorer betraktas 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å ett annat sätt. Istället för att skriva monolitiska program där hjulet uppfinns på nytt varje gång, kan vi skriva program som är uppbyggda av moduler.

Till exempel, istället för ett stort program som samlar information om flera processer, förvandlar den till grafer och visar dem för användarna, kan vi skapa en instrumentpanel som visar data som tas emot från flera webbtjänster. Sammanställd data tas emot från en eller flera tjänster, och de resulterande plotten skapas av en annan webbtjänst som tar data och producerar någon form av plot.

Instrumentpanelen förvandlas från ett stort program till ett enkelt gränssnitt. När vi vill lägga till nya komponenter kräver vi helt enkelt 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 möjlighet att lära eller sortera, då kan instrumentpanelen skicka meddelanden från användaren till lämplig tjänst. Vi kan till och med helt ändra de tjänster som anropas utan att användarna märker det (tills WSDL-filen ändras) och panelen förblir densamma.

Som IT-proffs kan du utveckla front-end, tjänsteutveckling eller båda. Att förstå hur allt fungerar tillsammans (eller åtminstone veta vad det är) är viktigt för att arbeta med ett projekt som detta.

Det är också bra att det finns många verktyg som hjälper dig att leverera och konsumera webbtjänster och kan göra mycket av det hårda arbetet åt dig. I följande delar av den här artikeln kommer vi att se hur du enkelt kan leverera webbtjänster till klienter eller system med IBM Lotus Domino V7.0.