Alekszandr Kacsanov
A webszolgáltatások ötletét olyan számítástechnikai óriások dolgozták ki, mint a Sun, az Oracle, a HP, a Microsoft és az IBM. Ez az ötlet nem újdonság, de nagy előrelépést jelent a programok interneten keresztüli könnyebb elérése felé. A szabványos kommunikációs formátumok alapján a webszolgáltatások teljesen megváltoztathatják a weboldalak készítésének módjáról alkotott elképzeléseinket.
Mi az a webszolgáltatás?
A webszolgáltatásoknak köszönhetően bármely program funkciói elérhetővé tehetők az interneten keresztül. Így az olyan programok, mint a PHP, ASP, JSP szkriptek, JavaBeans, COM objektumok és az összes többi kedvenc programozó eszközünk, mostantól hozzáférhetnek egy másik szerveren futó programhoz (azaz egy webszolgáltatáshoz), és felhasználhatják a tőle kapott választ a weboldalán, ill. Alkalmazás.
Tegyük fel, hogy ha valamilyen programozási feladatot kell végrehajtanom, és túl elfoglalt vagyok (vagy eszméletlen vagyok, hogy újra feltaláljam a kereket), akkor igénybe vehetem egy webszolgáltatás szolgáltatásait, amelyeket az oldalam az interneten keresztül fog elérni. A paraméterekkel ellátott kérés webszolgáltatásnak való átadásával elvárom, hogy megkapjam a kérésem végrehajtásának eredményét tartalmazó választ.
Bárki, aki valaha is dolgozott Utóbbi időben Val vel Hotmail, részben már találkozott webszolgáltatásokkal: a Passport felhasználó-hitelesítési rendszer a Microsoft .NET kezdeményezés egyik szolgáltatása. Jelenleg ingyenesen érhető el, így a webhelyek készítői könnyedén megvalósíthatják a felhasználói hitelesítést webhelyükön.
Alapok
A webszolgáltatások mögött meghúzódó elvek meglepően egyszerűek. És semmi újat nem adnak az elosztott számítástechnika és az internet világához:
- a webszolgáltatásért felelős személy határozza meg a webszolgáltatásához intézett kérések formátumát és válaszait
- a hálózat bármely számítógépe kérést intéz egy webszolgáltatáshoz
- egy webszolgáltatás feldolgoz egy kérést, végrehajt valamilyen műveletet, majd választ küld
Ez a művelet lehet például egy tőzsdei árfolyam megjelenítése, egy adott termék árának megjelenítése, egy bejegyzés elmentése egy időpont-naptárba, szöveg fordítása egyik nyelvről a másikra, vagy hitelkártyaszám ellenőrzése.
Szabványok a lényegben
Az ok, amiért hirtelen mindannyian érdeklődünk a webszolgáltatások iránt, az az, hogy azok szabványokon, nyílt protokollokon alapulnak az adatcseréhez és -átvitelhez.
Ezt megelőzően sok vállalat kidolgozta saját szabványait és formátumait. A munkához pedig már csak az egyszerű XML-t (eXtensible Markup Language) kell ismernünk, amelyet a régi ismerős HTTP protokollon keresztül továbbítunk. Ez azt jelenti, hogy a webszolgáltatások működésével kapcsolatos információk mindenki számára elérhetőek, és azok a webfejlesztők, akik szakmájuk szerint ismerik ezeket a technológiákat, már ma elkezdhetnek játszani a webszolgáltatásokkal.
A webszolgáltatások és a fejlesztők által megismert egyéb technológiák (például DCOM, named pipes, RMI) közötti különbség az, hogy a webszolgáltatások nyílt szabványokon alapulnak, könnyen megtanulhatók, és ezeket a szabványokat világszerte széles körben támogatják. Unix és Windows platformokon.
A Simple Object Access Protocol (SOAP) a W3C által kifejlesztett szabványos protokoll. Meghatározza a webszolgáltatásokhoz intézett kérések formátumát.
A webszolgáltatás és a felhasználó közötti üzenetek SOAP-borítékokba vannak csomagolva. Az üzenetek vagy kérést tartalmaznak valamilyen művelet végrehajtására, vagy választ – a művelet végrehajtásának eredményét. A boríték és annak tartalma XML-ben van kódolva, és meglehetősen könnyen érthető. Így néz ki egy egyszerű SOAP-kérés, ha HTPP-n keresztül elküldik egy webszolgáltatásnak:
xmlns:m="http://www.somesite.com/Irányítószám">
A SOAP boríték kulcsfontosságú elemeit meglehetősen könnyű kideríteni: ez két paraméter (
És a válasz így fog kinézni:
xmlns:m="http://www.somesite.com/Irányítószám">
Ez az üzenet még könnyebben megfejthető. Elem
Most az UDDI-ról
Annak ellenére, hogy a SOAP protokoll egyszerű, a webszolgáltatások nem lennének hasznosak, ha nem találnánk meg őket. Szerencsére az IBM, a Microsoft és az Ariba felléptek, és létrehozták az UDDI (Univerzális leírás, felfedezés és integráció) projektet, amely reményeik szerint a weben található összes webszolgáltatás közös katalógusává válik.
Az UDDI rendszer lehetővé teszi a vállalatok számára, hogy webszolgáltatásaikat a nyilvánosság elé tárják. Ez a címtár az összes webszolgáltatás telefonkönyveként működik. Az UDDI könyvtárba való regisztráció ingyenes, és a projekt alapítói remélik, hogy ez a könyvtár tartalmazza majd a weben található összes, minden szolgáltatás leírását, így a kívánt webszolgáltatás megtalálásához csak egy UDDI-hoz kell fordulnia. Könyvtár.
Hogyan működik mindez
Tehát hogyan találhatom meg a megfelelő webszolgáltatást?
Képzeljük el, hogy webhelyfejlesztő vagyok, és az ügyfelem megkért, hogy adjak hozzá az oldalhoz új funkció: Hozzá kell adnia egy irányítószám-ellenőrzést a regisztrációs űrlaphoz.
Ennek az ellenőrzésnek az elvégzéséhez adatbázist kellene készítenem mind a 30 ország összes irányítószámáról, ahol cégünk üzleti tevékenységet folytat, majd regisztrációkor ellenőrizni kell, hogy az irányítószám megfelel-e a regisztrációban megadott városnak. De nem rendelkezem ilyen adatokkal, és úgy gondolom, hogy ezeknek az adatoknak a gyűjtésére jelentős összeget kell költeni.
Ahelyett, hogy pénzt áldoznék egy adatbázis vásárlására, a kód megírására, az összes adat sértetlenségének és helyességének biztosítására, valamint a szkriptek hibakeresésére, egyszerűen felkeresem az UDDI-könyvtárat, és megnézem, van-e olyan webszolgáltatás, amely képes erre a feladatra. én . A http://www.uddi.org/ oldalra érve elindítok egy keresést, és találok egy kiváló szolgáltatást az XYZ Corp.-tól.
Gondosan átnézem a webszolgáltatás formátumdefinícióját (a definíció WSDL-ben (Web Services Description Language) van írva), meggyőződve arról, hogy a szolgáltatás pontosan azt csinálja, amire szükségem van. Ezután kollégáimmal egyeztetem az XYZ Corp. hírnevét, és megtudom hogy szilárd , majd vegye fel a kapcsolatot az XYZ Corp.-val az árakkal kapcsolatban. Ha a szolgáltatás elérésének ára a költségvetésemen belül van, írok egy egyszerű JSP-oldalt a webhelyemhez, amely meghívja az XYZ Corp. webszolgáltatását, és lám, Az azonnali ellenőrzés megjelenik a webhely irányítószámán.
Megéri rászánni az időt
Még ha semmi köze a programozáshoz vagy a weboldal-fejlesztési technológiákhoz, a webszolgáltatásokról érdemes többet megtudni. Képzeljen el egy képet arról, hogyan tárgyal egy új webhelyről az ügyféllel, és megvitatja az új projekt összes funkcióját. Minden remekül megy: a költségvetés megfelel a megrendelő elvárásainak, tetszett neki a helyszínrajz vázlata, tetszettek a felületi példák. Úgy tűnik, minden működik.
És hirtelen emlékeznek valami nagyon összetett funkcióra. A puszta említésre a webfejlesztő arca zöldre vált, fuldokolni és köhögni kezd. Ez a fejlesztő jelzi, hogy ennek a funkciónak a kifejlesztése sok pénzt és időt igényel, vagy egyszerűen nem kivitelezhető ekkora költségvetéssel.
Engedd el a félelmed! Készen állok garantálni, hogy az interneten már létezik olyan webszolgáltatás, amely készen áll a szükséges funkció biztosítására, és ennek a webszolgáltatásnak a költsége sokkal alacsonyabb lesz, mint az analógja önálló fejlesztésének költsége. Így kíméli meg fejlesztőjét a felesleges fejfájástól, ügyfelét pedig felesleges pazarlás pénzt csak azzal tölteni, hogy néhány percet böngész az UDDI-könyvtárban.
Szolgáltatásfejlesztés
Természetesen a fejlesztőknek nem kell megelégedniük a mások által létrehozott webszolgáltatásokkal. Az alábbi eszközkészletek egyikével létrehozhatja saját webszolgáltatását, és annak szolgáltatásait más internetfelhasználóknak is nyújthatja.
A webszolgáltatások fejlesztéséhez szükséges eszközök választéka széles. Olyan cégek eszközeit tartalmazza, mint a Sun (Open Net), a Microsoft (.NET), (e-szolgáltatások) és az IBM (Web Services). Vannak nyílt forráskódú keretrendszerek is. Például a Mono Project célja a Microsoft .NET-eszközkészletének leváltása fordítók, futási környezet és könyvtárak biztosításával, amelyek ugyanazokat a webszolgáltatásokat futtatják minden platformon, beleértve a Unixot is.
A szerverek és webszolgáltatás-fejlesztő eszközök sokfélesége ellenére mindegyik ugyanazt a SOAP protokollt, XML nyelvet és UDDI rendszert támogatja.
Mínuszok
Mielőtt teljesen feladnám programozói pályafutásomat, és a webszolgáltatások használatának szentelném magam, fel kell tennem magamnak a kérdést: "Túl rózsás a kép. Mi a baj vele?" Sajnos a webszolgáltatásokban rejlő hatalmas lehetőségeknek ára van:
- Az XML adatátviteli formátumként való használata azt jelenti, hogy üzenetei nagyon nagy méretűek lesznek: maguk az XML címkék sok helyet foglalnak el, és ez bizonyos terhet ró ránk az üzenetek létrehozásában, továbbításában és értelmezésében.
- Mióta használjuk távoli számítógépek Bizonyos funkciók végrehajtása során teljes mértékben az Internetre hagyatkozunk, ami túl sok megbízhatatlan kapcsolatot hoz létre a webszerverünk és a webszolgáltatás közötti láncban.
- Ma már kevés cég hoz létre webszolgáltatásokat, és kevés cég használja is azokat. A webszolgáltatási rendszer hibakeresése és fejlesztése még hosszú időt vesz igénybe.
- A webszolgáltatások használatának engedélyezési és díjfizetési rendszerét még el kell fogadniuk a fejlesztőknek. Mivel még mindig túl kevés a webszolgáltatás, a legtöbb cég úgy próbál jó benyomást kelteni potenciális ügyfeleiben, hogy szándékosan csökkenti a szolgáltatások költségeit és kedvező licencfeltételeket kínál. Még eltelik egy kis idő, amíg a webszolgáltatások valós költsége világossá válik.
Amikor a webszolgáltatások átveszik a helyüket és mindenki számára elérhetővé válnak, felbecsülhetetlen segítséget jelentenek a webfejlesztők számára. Rugalmas hozzáférést biztosítanak számunkra a hálózat összes számítógépének teljes teljesítményéhez. Itt az ideje, hogy a webhelykészítők érdeklődjenek a webszolgáltatások iránt, és többet megtudjanak arról, mit kaphatnak tőlük.
Megjegyzés: Felhasználási területek. Előnyök. Webszolgáltatások fejlesztésének jellemzői .NET platformra. Egy webszolgáltatás leírása és felfedezése
Mi az az XML webszolgáltatás?
Az információs technológia fejlődésével a programok írásának különböző megközelítései jelentek meg: a moduláris programozás, eseményvezérelt programozás, komponens-orientált programozásés tervezés. E megközelítések logikus folytatása szolgáltatás-orientált volt szoftverfejlesztés.
A szolgáltatás-orientált megközelítések alkalmazása lehetővé teszi, hogy makroszinten (szolgáltatási szinten) beszéljünk újrahasználatról, szemben a mikroszinttel (objektumszint). A szolgáltatás-orientált megközelítés egyszerű és általánosan elfogadott szabványokat használ, ami lehetővé teszi az alkalmazások széles skálájának, hogy megosszák egymás funkcióit. A szolgáltatások különféle programozási nyelvekkel írhatók, különféle platformokon. Ezenkívül a szolgáltatások külön-külön vagy egy szoftvercsomag részeként telepíthetők a világ bármely pontján, és így hozzáférést biztosítanak funkcióikhoz a hálózaton keresztül.
Hívjuk fel szolgáltatás erőforrás, amely egy üzleti funkciót valósít meg, és a következő tulajdonságokkal rendelkezik:
- újrafelhasználható;
- egy vagy több explicit technológia-független interfész határozza meg;
- lazán kapcsolódik más hasonló erőforrásokhoz, és olyan kommunikációs protokollokon keresztül hívható meg, amelyek lehetővé teszik az erőforrások egymás közötti interakcióját.
Egy szolgáltatás speciális esete az XML webszolgáltatás.
XML webszolgáltatás egy speciális típusú webes alkalmazás, amely:
- webszerverre telepítve;
- külső kliensek által meghívható webmetódusokat tesz közzé;
- várja a HTTP kérések beérkezését, amelyek webmetódusok hívására szolgáló parancsok;
- webmetódusokat hajt végre, és eredményeket ad vissza.
A hagyományos webes alkalmazásokkal ellentétben a webszolgáltatásnak nincs felhasználói felülete. Helyette programozói felülettel rendelkezik, vagyis a webszolgáltatás távolról (például interneten keresztül) hívható funkciókat (webes metódusokat) tesz közzé. A webszolgáltatás nem a végfelhasználók kiszolgálására szolgál. Feladata, hogy szolgáltatásokat nyújtson más alkalmazásoknak, legyenek azok webalkalmazások, GUI-alkalmazások vagy konzolalkalmazások.
A webszolgáltatások valós idejű információkat szolgáltathatnak a részvényárfolyamokról, ellenőrizhetik a hitelkártyákat, vagy jelenthetik az időjárás-előrejelzést. A webszolgáltatások ugyanolyan sokrétűek, mint a hagyományos alkalmazások.
A webszolgáltatások nem egy adott cég tulajdonát képezik. Nyílt protokollokon (SOAP, HTTP stb.) alapuló ipari szabvány. A webszolgáltatások különféle platformokon (beleértve a Windows vagy UNIX rendszerű kiszolgálókat) vannak telepítve. A webszolgáltatások számos fejlesztőeszközzel fejleszthetők (a szövegszerkesztőtől a Microsoft Visual Studio családig).
A legtöbb webszolgáltatás módszerét SOAP-üzeneteket tartalmazó HTTP-kérések hívják meg. A SOAP egy XML-nyelv (XML-szókincs), amely távoli eljárások HTTP-n és más protokollokon keresztül történő meghívására szolgál (a SOAP teljes leírása http://www.w3.org/TR/SOAP) .
A webszolgáltatások helye az egyéb távoli hívástechnológiák között
Jó néhány távoli hívási protokoll és technológia létezik: Microsoft Distributed Component Object Model (DCOM), az Object Management Group Common Object Request Broker Architecture (CORBA), a Sun Remote Method Invocation (RMI), . NET Remoting, XML webszolgáltatások.
Mindezeket a komponens-alapú technológiákat (DCOM, CORBA és RMI) évek óta sikeresen alkalmazzák intranetes alkalmazásokban. Megbízható, méretezhető architektúrát biztosítanak. Két komoly probléma van azonban ezen technológiák internetes használatával. Először is, nem kommunikálnak jól egymással. Minden technológia objektumokon működik, de a részletekben jelentősen eltérnek egymástól: életciklus-kezelés, konstruktor-támogatás és az öröklési támogatás mértéke. A második, fontosabb szempont az, hogy az RPC interakciókra való összpontosítás szorosan összekapcsolt rendszerek felépítéséhez vezet, amelyek explicit objektum metódusok hívásain alapulnak.
Ezekkel a technológiákkal ellentétben az XML Web Services ill. A NET Remoting teljes mértékben megvalósul objektum-orientált megközelítés webes programozáshoz.
XML webszolgáltatás- olyan összetevő, amely az internetes ügyfelek számára API-funkciókat vagy webes metódusokat biztosít. Az XML azért szerepel a névben, mert a webszolgáltatások és ügyfeleik ezt használják adatcserére. A webszolgáltatások olyan nyílt szabványokon alapulnak, mint a HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol – egy Intenet-szabvány, amely leírja, hogy az alkalmazások hogyan tudnak interakcióba lépni, azaz hogyan hívhatják meg egymás metódusait HTTP és más protokollok használatával). A webszolgáltatások fő feladata a programok közötti interakció biztosítása. Sokan UNIX kiszolgálókon dolgoznak, és Windows kliensek érik el őket. A webszolgáltatásoknak küldött adatokat XML-ben sorba rendezzük, és SOAP-csomagokban küldjük el. Az ilyen üzenetek tartalmára vonatkozó metaadatokat a webszolgáltatás WSDL szerződése és az XSD sémák tárolják. Ennek a megközelítésnek a fő előnye a metaadatok olvashatósága. A fejlesztő könnyedén megtekintheti a webszolgáltatás teljes leírását, és akár saját modult is létrehozhat, amely a SOAP-csomagokat elemzi.
.NET Remoting infrastruktúrát biztosít az elosztott objektumok számára. Sokkal összetettebb, mint egy egyszerű üzenettovábbítási webszolgáltatás-architektúra. . A NET Remoting magában foglalja a paraméterek hivatkozás és érték szerinti átadását, a visszahívásokat, a több objektum aktiválását és az életciklus-kezelési házirendeket. E szolgáltatások használatához az ügyfélalkalmazásnak minden technológiában jártasnak kell lennie. Adatok c. A NET Remoting bináris vagy SOAP formátumban kerül továbbításra. Mindenesetre a továbbított információ szerkezetére vonatkozó metaadatokat a közös nyelvi végrehajtási környezet tartalmazza. Közös nyelvi futtatókörnyezet (CLR) nélkül az ügyfélalkalmazás nem tudja elemezni a nyelvspecifikusakat. NET Remoting SOAP fejlécek. Azaz. A NET Remoting lényegesen magasabb követelményeket támaszt a webszolgáltatásokhoz képest.
Webszolgáltatások fejlesztése .NET platformon
Számos módja van a webszolgáltatások írásának. Fejleszthetők manuálisan vagy a Microsoft, IBM stb. által biztosított SOAP eszközökkel. Webszolgáltatások írása a Microsoft segítségével. A NET-nek két előnye van:
- A .NET-keretrendszer nagymértékben leegyszerűsíti a fejlesztési folyamatot azáltal, hogy osztálykönyvtárat biztosít és automatizálja az egyes fejlesztési szakaszokat;
- A .NET-keretrendszerrel írt webszolgáltatások felügyelt alkalmazások. Vagyis az ilyen alkalmazásoknak nincsenek memóriaszivárgással, helytelenül inicializált mutatókkal és más tipikus programozási problémákkal kapcsolatos problémái.
Teremtés
Fejlesszünk egy egyszerű AdditionService webszolgáltatást, amely két számot ad hozzá. Csak egy Add metódusa lesz, amely két egész számot vesz paraméterként, és egy egész számot ad vissza. Az AdditionService bemutatja a webszolgáltatások Microsoft .NET-keretrendszerrel történő programozásának számos fontos alapelvét.
- A webszolgáltatások ASMX-fájlokként vannak megvalósítva. Az ASMX egy speciális fájlnév-kiterjesztés, amelyet az ASP .NET-hez (pontosabban az ASP.NET HTTP-kezelőhöz) regisztráltak a fő ASP .NET Machine.config konfigurációs fájlban.
- Az ASMX fájlok a @WebService direktívával kezdődnek. Ennek a direktívának tartalmaznia kell legalább a Class attribútumot, amely meghatározza, hogy a webszolgáltatás melyik osztályból áll.
- A webszolgáltatási osztályok opcionális WebService attribútumokkal rendelkezhetnek. BAN BEN ebben a példában Ez az attribútum adja meg a webszolgáltatás nevét és leírását, amely akkor jelenik meg a HTML oldalon, amikor a felhasználó meghívja az AdditionService.asmx fájlt a böngészőben.
- A webes metódusok deklarálása a WebMethod attribútumnak a webszolgáltatási osztály nyilvános metódusaihoz való hozzárendelésével történik. A belsőleg használt, de külső ügyfelek számára nem elérhető segédmetódusoknál ez az attribútum egyszerűen nincs megadva.
- A HTTP, az XML és a SOAP „láthatatlan”. A .NET-keretrendszer kezeli az XML-adatokat és a SOAP-üzeneteket.
AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>Rendszer használata System.Web.Services osztály használatával AddService ( public int Add (int a, in b) ( return a + b ) )
Kis mérete ellenére az AdditionService.asmx teljes értékű webszolgáltatás, ha ASP.NET-tel rendelkező webszerverre telepítik. Metódusait SOAP, HTTP GET és HTTP POST segítségével hívják meg, és SOAP-válaszként vagy egyszerű XML-burkolóként adhatja vissza az eredményeket.
A háttérkód használatával a webszolgáltatási osztályok áthelyezhetők asmx fájlokból külön fájlokba.
A webszolgáltatások támogatják a használatot összetett adattípusok bemeneti vagy kimeneti paraméterként. Az összetett adattípusok támogatottak, mivel az XML lehetővé teszi a legtöbb adattípus egyszerű sorba rendezését. Egy webszolgáltatás automatikus tesztelésekor azonban az ASP .NET nem hoz létre tesztoldalakat az elfogadó módszerekhez összetett típusok adat. Ez azért történik, mert a HTTP GET és POST használatával nem lehet összetett adattípusokat átadni egy webes metódusnak.
A webszolgáltatások lehetővé teszik módszereik meghívását aszinkron módon. Az aszinkron hívás azonnal visszaadja az irányítást, függetlenül attól, hogy mennyi ideig tart a webszolgáltatásnak a hívás feldolgozása. Az aszinkron hívások akkor hasznosak, ha egy hívás feldolgozása jelentős időt vesz igénybe. Az alkalmazás kezdeményezi a hívást, majd a hívás eredményének megvárása nélkül fut tovább, és később fogadja az aszinkron hívás eredményét. Az eredményt úgy kapjuk meg, hogy az alkalmazás számára megfelelő időpontban újra felhívjuk a webes metódust, vagy feliratkozunk a webszolgáltatás hívásfeldolgozásának befejezéséről szóló értesítésre (delegálási mechanizmus).
A webszolgáltatások olyan eszközök segítségével hozhatók létre, mint pl Microsoft Visual Studio 2005. Az általa nyújtott webszolgáltatások létrehozásához külön típus ASP .NET Web Service projekt. A Visual Studio létrehoz egy asmx fájlt, egy háttérkóddal rendelkező fájlt a webszolgáltatási osztályok leírásához, egy webszolgáltatás konfigurációs fájlt stb. Amikor a projektet elindítják végrehajtásra, a szolgáltatási osztályok összeállításra kerülnek, és az asmx fájl megnyílik a böngészőablakban. .
Webszolgáltatások leírása szerződések felhasználásával
Ahhoz, hogy más fejlesztők használhassák az AdditionService-t, tudniuk kell, hogy milyen metódusokat biztosít, milyen protokollokat támogat, metódus-aláírásokat és a webszolgáltatás címét (URL). Mindezek és egyéb információk WSDL-ben (Web Service Description language) írhatók le.
Webszolgáltatás felfedezése
Honnan tudnak más fejlesztők az AdditionService létezéséről?
Először is, a DISCO (a Discovery szó rövidítése) használata - egy fájl alapú mechanizmus a helyi webszolgáltatások keresésére, azaz egy olyan mechanizmus, amely a webszervereken található DISCO-fájlokból az elérhető webszolgáltatások listájának megszerzésére szolgál. Ezenkívül a DISCO-fájlok tartalmazzák az elérhető szolgáltatások WSDL-szerződéseinek helyét. A DISCO fájl egy XML fájl rekordokkal.
Lehetőség van VSDISCO fájlok használatára is, amelyek hasonlóak a DISCO fájlokhoz, de tartalmuk a webszolgáltatások dinamikus keresésének eredménye a megadott könyvtárakban és az összes alkönyvtárban. Az ASP .NET leképezi a .vsdisco fájlnév-kiterjesztést egy HTTP-kezelőre, amely az adott könyvtárban és annak alkönyvtáraiban megkeresi az asmx-et és a disco-t, és egy dinamikusan generált DISCO-dokumentumot ad vissza. Biztonsági okokból a dinamikus keresés le van tiltva a .NET-keretrendszer egyes verzióiban, de engedélyezheti a Machine.config fájl bejegyzéseinek szerkesztésével.
Hogyan keres webszolgáltatásokat a globális hálózaton? A webszolgáltatások globális hálózaton történő kereséséhez a Microsoft, az IBM és az Ariba közösen fejlesztette ki az UDDI-t (Universal Description Discovery and Integration) – egy olyan specifikációt, amely elosztott adatbázisok felépítésére szolgál, és lehetővé teszi a webszolgáltatások keresését. Az UDDI-t több száz cég támogatja. Az UDDI webhelyek maguk is webszolgáltatások. Bárki közzéteheti UDDI-alapú nyilvántartását. A legtöbb fejlesztő soha nem használja közvetlenül az UDDI API-t. Ehelyett az UDDI-nyilvántartásokat fejlesztőeszközök érik el. A felfedezett és kiválasztott webszolgáltatásokhoz wrapper osztályokat is generálnak.
Eredmények
Az XML webszolgáltatás olyan szoftverösszetevő, amely a legtöbbek által használható funkcionalitást biztosít különböző rendszerek, amely támogatja az olyan szabványokat, mint az XML és a HTTP. A webszolgáltatási ügyfelek lehetnek helyi és távoli alkalmazások is. A webszolgáltatások lehetővé teszik olyan struktúrák létrehozását, amelyek egyszerű, általánosan elfogadott szabványok alapján megkönnyítik a különböző rendszerek integrálását.
Áttekintettük általános fogalmak a mechanizmus használata « Web-szolgáltatások". Frissítsünk egy kis tudást.
A webszolgáltatások a szerver és a kliens közötti adatcserére szolgálnak; Az XML formátumot az adatok „csomagolására” használják a kommunikáció mindkét résztvevője közötti kölcsönös megértés érdekében.
FEJEZETén
PÉLDA A MEGVALÓSÍTÁSRAWEB- SZOLGÁLTATÁS AZ 1C:VÁLLALATI RENDSZERBEN
FELADAT: Létre kell hozni egy webszolgáltatást, amelyhez hozzáférve az ügyfelek minden szükséges információt meghatározhatnak alkalmazásaikról.
A feladat egy bemutató, és csak példaként szolgál a mechanizmus megértéséhez és tanításáhozweb- szolgáltatások.
MEGOLDÁS:
1. lépés. Hozzon létre egy új információs bázist konfiguráció nélkül, hogy új konfigurációt fejlesszünk ki.
2. lépés. Adjunk hozzá több új objektumot a konfigurációhoz
"Ügyfelek" könyvtár;
„Pályázat” dokumentum;
Felsorolás "Kérés állapotok".
3. lépés Hozzunk létre egy új XDTO-csomagot.
Miért és milyen célból készítünk XDTO-csomagot? Az XDTO-mechanizmus használatáról további információk találhatók a „16. Fejlesztői útmutató” és a .
Röviden megjegyezzük, hogy az XDTO mechanizmus univerzális módja az adatok bemutatásának különféle külső adatforrásokkal és szoftverrendszerekkel való interakcióhoz.
Esetünkben egy XDTO-csomag jön létre, amely leírja a webszolgáltatás visszatérési értékét.
Bontsuk ki az „Általános” ágat → „XDTO-csomagok” → Hozzáadás…
Adjuk meg az XDTO csomag nevét " DocumentsData"és annak névterét http://localhost/request vagy http://192.168.1.76/request (a megértés és a tanulási folyamat megkönnyítése érdekében feltüntetjük annak a számítógépnek a helyi IP-címét, amelyre a webszerver telepítve van (támogatott webszerverek): IIS vagy Apache)). Minden webszolgáltatás egyedileg azonosítható a nevével és a hozzá tartozó névtér URI-jával.
Csomagunk kétféle XDTO objektumot tartalmaz:
1) Ügyfél- adatok átvitelére a „Clients” címtárelemből.
- Név ;
2) Dokumentum- adatok átvitelére a „Pályázat” dokumentumból
Ez az XDTO objektumtípus a következő tulajdonságokat fogja tartalmazni:
- Ügyfél- Ügyfél típusa a névtérből: http://192.168.1.76/request ; hivatkozást jelent a fent definiált XDTO objektumra;
- Állapot- karakterlánc típusa a névtérből: http://www.w3.org/2001/XMLSchema ;
- Numder- karakterlánc típusa a névtérből: http://www.w3.org/2001/XMLSchema.
4. lépés. Adjunk hozzá egy új webszolgáltatást a konfigurációhoz
Bontsuk ki az „Általános” → „Webszolgáltatások” → Hozzáadás…
A webszolgáltatáshoz a következő tulajdonságértékeket adjuk meg:
Név - DocumentsData
Névtér URI - http://192.168.1.76/request
XDTO csomagok - DocumentsDatavagyhttp://192.168.1.76/request
Kiadvány fájl neve - kérés.1cws
5. lépés. A létrehozott webszolgáltatáshoz a " műveletet fogjuk meghatározni GetData»
Műveleti tulajdonságok értékei:
Visszaküldés típusa - Dokumentum (http://192.168.1.76/request)
Lehetséges üres érték - Igaz
Az eljárás neve - GetData.
6. lépés. A műtéten GetData definiáljuk a Сustomer paramétert a következő értékekkel tulajdonságok:
Értéktípus - típus húr a névtérből: http://www.w3.org/2001/XMLSchema;
átvitel iránya - bemenet.
7. lépés Nyissuk meg a létrehozott webszolgáltatás modulját, és helyezzük el benne a Get() függvényt, amely a webszolgáltatás meghívásakor fog lefutni.
Funkció GetData(Customer) // Az XDTO objektumok típusainak lekérése ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "Ügyfél"); RequestType = FactoryXDTO.Type("http://192.168.1.76/request", "Dokumentum"); // Az ügyfél lekérése ClientLink = Directories.Clients.FindByName(Customer); Ha nem ValueFilled(ClientRef) akkor Return Undefined; endIf; Request = Új kérés; Kérelem.Szöveg = "KIVÁLASZTÁS A 1. TOP 1. | Alkalmazás.Link, | KÉPVISELÉS(Alkalmazás.Állapot) AS állapota, | Alkalmazás.Szám |FROM | Dokumentum.Kérés AS Alkalmazás |HOL | Alkalmazás.Ügyfél = &kliens"; Request.SetParameter("Client", ClientLink); RequestResult = Request.Execute(); Ha QueryResult.Empty() akkor Return Undefined; endIf; Selection = QueryResult.Select(); Selection.Next(); Document = Selection.Link.GetObject(); // Egy rendelés XDTO objektumának létrehozása Order = FactoryXDTO.Create(OrderType); Application.Numder = Sample.Number; Ügyfél = FactoryXDTO.Create(ClientType); Client.Name = ClientLink.Name; Application.Customer = Ügyfél; Application.Status = Selection.Status; // A kérés visszaküldése Return Application; EndFunction
8. lépés Tegyük közzé a létrehozott webszolgáltatást a webszerveren.
Menüpont Konfigurátor: „Adminisztráció” → „Közzététel webszerveren”.
A „Webszolgáltatások” lapon jelölje be a „Webszolgáltatások közzététele” jelölőnégyzetet, és jelölje be az új webszolgáltatásunk melletti négyzetet is.
FEJEZETII
PÉLDA A FELLEBBEZÉSREWEB- AZ 1C:ENTERPRISE RENDSZERSZOLGÁLTATÁSHOZ HARMADIK FÉL ALKALMAZÁSÁBÓL
Az 1C:Enterprise rendszer webszolgáltatási mechanizmusának fő célja a szükséges adatok átvitele harmadik féltől származó alkalmazásokhoz.
Tekintsünk egy példát egy Delphi alkalmazás fejlesztésére, amely webszolgáltatásunkat hívja a cikk első részében.
1. lépés. Alkossunk új projektés helyezzen el több vezérlőt az űrlapon
Szövegmező - a webszolgáltatástól kapott információk megjelenítésére szolgál;
Két gomb - a szövegmező törlése és a webszolgáltatás elérése;
A beviteli mező a webszolgáltatásnak átadott paraméter.
2. lépés. WSDL fájl importálása
Ennek eredményeként egy új modult kapunk kérés(ezt a nevet közvetlenül az 1C-ben határoztuk meg). Ez a modul minden szükséges információt tartalmaz a webszolgáltatásról.
3. lépésÍrjunk webszolgáltatás híváskezelőt
A DocumentDataPortType változó már definiálva van a modulban kérés
4. lépés. Indítsa el az alkalmazást, és futtassa a tesztet.
FEJEZETIII
PÉLDA A FELLEBBEZÉSREWEB-SZERVIZ AZ 1C:VÁLLALATI RENDSZERBEN
1. lépés. Hozzon létre egy új külső feldolgozást "WEB_Service" néven
2. lépés. Adjunk meg egy új űrlapot a feldolgozáshoz
3. lépés Az űrlapon több részletet feltüntetünk
Kliens – írja be: "String"
ClientReturn - írja be a "String"
NumberReturn – írja be a „String”
StatusReturn - írja be a „String”-t.
A részleteket megjelenítjük az űrlapon.
4. lépés. Adjunk hozzá egy űrlapparancsot " Adatszerzéshez»
Adjuk meg a parancskezelőt
&OnClient eljárás GetData(Command) GetDataOnServer(Client); Az eljárás vége Eljárás GetDataOnServer(Client) // Hozzon létre egy WS-proxyt a hivatkozás alapján, és hajtsa végre a Get() műveletet Definition = New WSDefinitions("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl") ; Proxy = Új WSProxy(definíció, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); Alkalmazásadatok = Proxy.GetData(Client); Ha Alkalmazásadatok = Undefined, akkor ClientReturn = "Nem definiált"; StatusReturn = "Nem definiált"; ReturnNumber = "Nem definiált"; Visszatérés; endIf; CustomerReturn = Application Data.Customer.Name; StatusReturn = Alkalmazásadatok.Állapot; Visszatérési szám = Application Data.Numder; Az eljárás vége
Az 1C:Enterprise rendszer kétféle módon használhatja a más szolgáltatók által nyújtott webszolgáltatásokat:
Használva statikus a konfigurációs fában létrehozott hivatkozások;
"plusz": Magassebesség;
"mínusz": a WSDL leírás újraimportálása a konfigurátor segítségével, és a megváltozott konfiguráció mentése.
Használva dinamikus beépített nyelvi eszközökkel létrehozott hivatkozások
(Ennek megfelelően a statikusak „hátrányai” a dinamikusaknak „előnyök”)
FEJEZETIV
WEBES SZOLGÁLTATÁSOK HIBAKERESÉSE AZ 1C:VÁLLALATI RENDSZERBEN
A helyi webszolgáltatáshoz szüksége van:
1. lépés. Helyezze a fájlt a kliensre, ahol az 1C rendszer fut webservicecfg.xml a következő tartalommal
2. lépés. Fájlhoz alapértelmezett. vrd konfiguráció hozzáadása sor közzététele
3. lépés A konfigurátorban válassza ki a menüpontot
„Hibakeresés” → „Kapcsolat” → „Automatikus kapcsolat” → „Webszolgáltatások a szerveren”
4. lépés. Kattintson az „OK” gombra
A szerver opcióhoz az 1c szervert is hibakeresési módban kell futtatni a kulccsal /debug
A webszolgáltatások ötletét olyan számítástechnikai óriások dolgozták ki, mint a Sun, az Oracle, a HP, a Microsoft és az IBM. Ez az ötlet nem újdonság, de nagy előrelépést jelent a programok interneten keresztüli könnyebb elérése felé. A szabványos kommunikációs formátumok alapján a webszolgáltatások teljesen megváltoztathatják a weboldalak készítésének módjáról alkotott elképzeléseinket.
Mi az a webszolgáltatás?
A webszolgáltatásoknak köszönhetően bármely program funkciói elérhetővé tehetők az interneten keresztül. Így az olyan programok, mint a PHP, ASP, JSP szkriptek, JavaBeans, COM objektumok és az összes többi kedvenc programozó eszközünk, mostantól hozzáférhetnek egy másik szerveren futó programhoz (azaz egy webszolgáltatáshoz), és felhasználhatják a tőle kapott választ a weboldalán, ill. Alkalmazás.
Tegyük fel, hogy ha valamilyen programozási feladatot kell végrehajtanom, és túl elfoglalt vagyok (vagy eszméletlen vagyok, hogy újra feltaláljam a kereket), akkor igénybe vehetem egy webszolgáltatás szolgáltatásait, amelyeket az oldalam az interneten keresztül fog elérni. A paraméterekkel ellátott kérés webszolgáltatásnak való átadásával elvárom, hogy megkapjam a kérésem végrehajtásának eredményét tartalmazó választ.
Bárki, aki nemrégiben dolgozott együtt Hotmail, részben már találkozott webszolgáltatásokkal: a Passport felhasználó-hitelesítési rendszer a Microsoft .NET kezdeményezés egyik szolgáltatása. Jelenleg ingyenesen érhető el, így a webhelyek készítői könnyedén megvalósíthatják a felhasználói hitelesítést webhelyükön.
Alapok
A webszolgáltatások mögött meghúzódó elvek meglepően egyszerűek. És semmi újat nem adnak az elosztott számítástechnika és az internet világához:
- a webszolgáltatásért felelős személy határozza meg a webszolgáltatásához intézett kérések formátumát és válaszait
- a hálózat bármely számítógépe kérést intéz egy webszolgáltatáshoz
- egy webszolgáltatás feldolgoz egy kérést, végrehajt valamilyen műveletet, majd választ küld
Ez a művelet lehet például egy tőzsdei árfolyam megjelenítése, egy adott termék árának megjelenítése, egy bejegyzés elmentése egy időpont-naptárba, szöveg fordítása egyik nyelvről a másikra, vagy hitelkártyaszám ellenőrzése.
Szabványok a lényegben
Az ok, amiért hirtelen mindannyian érdeklődünk a webszolgáltatások iránt, az az, hogy azok szabványokon, nyílt protokollokon alapulnak az adatcseréhez és -átvitelhez.
Ezt megelőzően sok vállalat kidolgozta saját szabványait és formátumait. A munkához pedig már csak az egyszerű XML-t (eXtensible Markup Language) kell ismernünk, amelyet a régi ismerős HTTP protokollon keresztül továbbítunk. Ez azt jelenti, hogy a webszolgáltatások működésével kapcsolatos információk mindenki számára elérhetőek, és azok a webfejlesztők, akik szakmájuk szerint ismerik ezeket a technológiákat, már ma elkezdhetnek játszani a webszolgáltatásokkal.
A webszolgáltatások és a fejlesztők által megismert egyéb technológiák (például DCOM, named pipes, RMI) közötti különbség az, hogy a webszolgáltatások nyílt szabványokon alapulnak, könnyen megtanulhatók, és ezeket a szabványokat világszerte széles körben támogatják. Unix és Windows platformokon.
A Simple Object Access Protocol (SOAP) a W3C által kifejlesztett szabványos protokoll. Meghatározza a webszolgáltatásokhoz intézett kérések formátumát.
A webszolgáltatás és a felhasználó közötti üzenetek SOAP-borítékokba vannak csomagolva. Az üzenetek vagy kérést tartalmaznak valamilyen művelet végrehajtására, vagy választ – a művelet végrehajtásának eredményét. A boríték és annak tartalma XML-ben van kódolva, és meglehetősen könnyen érthető. Így néz ki egy egyszerű SOAP-kérés, ha HTPP-n keresztül elküldik egy webszolgáltatásnak:
xmlns:m="http://www.somesite.com/Irányítószám">
A SOAP boríték kulcsfontosságú elemeit meglehetősen könnyű kideríteni: ez két paraméter (
És a válasz így fog kinézni:
xmlns:m="http://www.somesite.com/Irányítószám">
Ez az üzenet még könnyebben megfejthető. Elem
Most az UDDI-ról
Annak ellenére, hogy a SOAP protokoll egyszerű, a webszolgáltatások nem lennének hasznosak, ha nem találnánk meg őket. Szerencsére az IBM, a Microsoft és az Ariba felléptek, és létrehozták az UDDI (Univerzális leírás, felfedezés és integráció) projektet, amely reményeik szerint a weben található összes webszolgáltatás közös katalógusává válik.
Az UDDI rendszer lehetővé teszi a vállalatok számára, hogy webszolgáltatásaikat a nyilvánosság elé tárják. Ez a telefonkönyv az összes webszolgáltatás telefonkönyveként működik. Az UDDI könyvtárba való regisztráció ingyenes, és a projekt alapítói remélik, hogy ez a könyvtár tartalmazza majd a weben található összes, minden szolgáltatás leírását, így a kívánt webszolgáltatás megtalálásához csak egy UDDI-hoz kell fordulnia. Könyvtár.
Hogyan működik mindez
Tehát hogyan találhatom meg a megfelelő webszolgáltatást?
Képzeljük el, hogy webhelyfejlesztő vagyok, és az ügyfelem megkért, hogy adjak hozzá egy új funkciót az oldalhoz: a regisztrációs űrlapon egy irányítószám-ellenőrzést kell hozzáadnom.
Ennek az ellenőrzésnek az elvégzéséhez adatbázist kellene készítenem mind a 30 ország összes irányítószámáról, ahol cégünk üzleti tevékenységet folytat, majd regisztrációkor ellenőrizni kell, hogy az irányítószám megfelel-e a regisztrációban megadott városnak. De nem rendelkezem ilyen adatokkal, és úgy gondolom, hogy ezeknek az adatoknak a gyűjtésére jelentős összeget kell költeni.
Ahelyett, hogy pénzt áldoznék egy adatbázis vásárlására, a kód megírására, az összes adat sértetlenségének és helyességének biztosítására, valamint a szkriptek hibakeresésére, egyszerűen felkeresem az UDDI-könyvtárat, és megnézem, van-e olyan webszolgáltatás, amely képes erre a feladatra. én . A www.uddi.org webhelyre érve keresek, és kiváló szolgáltatást találok az XYZ Corp.-tól.
Gondosan átnézem a webszolgáltatás formátumdefinícióját (a definíció WSDL-ben (Web Services Description Language) van írva), meggyőződve arról, hogy a szolgáltatás pontosan azt csinálja, amire szükségem van. Ezután kollégáimmal egyeztetem az XYZ Corp. hírnevét, és megtudom hogy szilárd , majd vegye fel a kapcsolatot az XYZ Corp.-val az árakkal kapcsolatban. Ha a szolgáltatás elérésének ára a költségvetésemen belül van, írok egy egyszerű JSP-oldalt a webhelyemhez, amely meghívja az XYZ Corp. webszolgáltatását, és lám, Az azonnali ellenőrzés megjelenik a webhely irányítószámán.
Megéri rászánni az időt
Még ha semmi köze a programozáshoz vagy a weboldal-fejlesztési technológiákhoz, a webszolgáltatásokról érdemes többet megtudni. Képzeljen el egy képet arról, hogyan tárgyal egy új webhelyről az ügyféllel, és megvitatja az új projekt összes funkcióját. Minden remekül megy: a költségvetés megfelel a megrendelő elvárásainak, tetszett neki a helyszínrajz vázlata, tetszettek a felületi példák. Úgy tűnik, minden működik.
És hirtelen emlékeznek valami nagyon összetett funkcióra. A puszta említésre a webfejlesztő arca zöldre vált, fuldokolni és köhögni kezd. Ez a fejlesztő jelzi, hogy ennek a funkciónak a kifejlesztése sok pénzt és időt igényel, vagy egyszerűen nem kivitelezhető ekkora költségvetéssel.
Engedd el a félelmed! Készen állok garantálni, hogy az interneten már létezik olyan webszolgáltatás, amely készen áll a szükséges funkció biztosítására, és ennek a webszolgáltatásnak a költsége sokkal alacsonyabb lesz, mint az analógja önálló fejlesztésének költsége. Így megkímélheti fejlesztőjét a felesleges fejfájástól, ügyfelét pedig a pénzpazarlástól, ha csak pár percet tölt az UDDI katalógus böngészésével.
Szolgáltatásfejlesztés
Természetesen a fejlesztőknek nem kell megelégedniük a mások által létrehozott webszolgáltatásokkal. Az alábbi eszközkészletek egyikével létrehozhatja saját webszolgáltatását, és annak szolgáltatásait más internetfelhasználóknak is nyújthatja.
A webszolgáltatások fejlesztéséhez szükséges eszközök választéka széles. Olyan cégek eszközeit tartalmazza, mint a Sun (Open Net), a Microsoft (.NET), (e-szolgáltatások) és az IBM (Web Services). Vannak nyílt forráskódú keretrendszerek is. Például a Mono Project célja a Microsoft .NET-eszközkészletének leváltása fordítók, futási környezet és könyvtárak biztosításával, amelyek ugyanazokat a webszolgáltatásokat futtatják minden platformon, beleértve a Unixot is.
A szerverek és webszolgáltatás-fejlesztő eszközök sokfélesége ellenére mindegyik ugyanazt a SOAP protokollt, XML nyelvet és UDDI rendszert támogatja.
Mínuszok
Mielőtt teljesen feladnám programozói pályafutásomat, és a webszolgáltatások használatának szentelném magam, fel kell tennem magamnak a kérdést: "Túl rózsás a kép. Mi a baj vele?" Sajnos a webszolgáltatásokban rejlő hatalmas lehetőségeknek ára van:
- Az XML adatátviteli formátumként való használata azt jelenti, hogy üzenetei nagyon nagy méretűek lesznek: maguk az XML címkék sok helyet foglalnak el, és ez bizonyos terhet ró ránk az üzenetek létrehozásában, továbbításában és értelmezésében.
- Mivel bizonyos funkciók végrehajtásához távoli számítógépeket használunk, teljes mértékben az Internetre hagyatkozunk, ami túl sok megbízhatatlan kapcsolatot hoz létre a webszerverünk és a webszolgáltatás közötti láncban.
- Ma már kevés cég hoz létre webszolgáltatásokat, és kevés cég használja is azokat. A webszolgáltatási rendszer hibakeresése és fejlesztése még hosszú időt vesz igénybe.
- A webszolgáltatások használatának engedélyezési és díjfizetési rendszerét még el kell fogadniuk a fejlesztőknek. Mivel még mindig túl kevés a webszolgáltatás, a legtöbb cég úgy próbál jó benyomást kelteni potenciális ügyfeleiben, hogy szándékosan csökkenti a szolgáltatások költségeit és kedvező licencfeltételeket kínál. Még eltelik egy kis idő, amíg a webszolgáltatások valós költsége világossá válik.
Amikor a webszolgáltatások átveszik a helyüket és mindenki számára elérhetővé válnak, felbecsülhetetlen segítséget jelentenek a webfejlesztők számára. Rugalmas hozzáférést biztosítanak számunkra a hálózat összes számítógépének teljes teljesítményéhez. Itt az ideje, hogy a webhelykészítők érdeklődjenek a webszolgáltatások iránt, és többet megtudjanak arról, mit kaphatnak tőlük.
Webszolgáltatások gyakorlati használata IBM Lotus Domino 7-ben
Mik azok a webszolgáltatások és miért fontosak?
Tartalom sorozat:
Ez a tartalom egy # cikkből álló sorozat # része: Webszolgáltatások gyakorlati használata IBM Lotus Domino 7-ben
https://www..jsp?series_title_by=Practical+use+of+web-services+in+ibm+lotus+domino+7
Maradjon velünk a sorozat új cikkeivel kapcsolatban.
Technikai cikkekben, leírásokban találkozhatott webszolgáltatásokra vonatkozó hivatkozásokkal szoftver termékek vagy akár a kollégákkal folytatott párbeszédekben. A webszolgáltatások nyilvánvalóan szükségesek és fontosak néhány ember számára, azonban amikor olyan definíciókkal találkozott, mint az „XML nyelvtan az üzenetküldés végpontjainak meghatározásához”, úgy döntött, hogy az ilyen összetett dolgokhoz nem érdemes hozzányúlni.
Szerencsére a webszolgáltatások mindenki számára érthető módon magyarázhatók anélkül, hogy belemennénk az egész működésének részleteibe. Meg kell próbálnia megérteni, mik is azok a webszolgáltatások, hiszen ezek (és a kapcsolódó szolgáltatásorientált architektúra, SOA) alkalmazási köre az IT világban folyamatosan bővül.
A webszolgáltatások egy autónak is felfoghatók: nem kell műszaki szinten tudnod a dugattyúk, vezérműtengelyek és az üzemanyag-befecskendezők működését - vásárolhatsz autót, vezetheted és beszélgethetsz az autókról a barátaiddal (kivéve persze mechanika) . Ugyanez vonatkozik a webszolgáltatásokra is; informatikai szakemberként csak meg kell értenie, hogy mik ezek és hogyan működnek, hogy megértsék, miért van rájuk szükség.
Ma már sokkal könnyebb a webszolgáltatásokkal a rejtett alacsony szintű technológiák érintése nélkül dolgozni, mivel a szoftvergyártók és a nyílt forráskódú közösség az elmúlt néhány évben sokat tettek azért, hogy elkülönítsék a webszolgáltatások felületét az alacsony szintű feladatoktól. Ez lehetővé teszi, hogy egyszerűen összekapcsolja az összetevőket anélkül, hogy bele kellene mélyednie az XML-üzenetek formázásával kapcsolatos hosszadalmas dokumentációba.
Ez a cikksorozat segít a Domino fejlesztőknek az IBM Lotus Domino V7.0 webszolgáltatásainak megértésében és használatában. Ez a bevezető cikk eleget tartalmaz hasznos információ, és hasznos lesz mindenkinek, aki meg akarja érteni, mik is azok a webszolgáltatások. A Lotus Domino V7.0 technológiái megkönnyítik a fejlesztők számára a webszolgáltatások létrehozását és használatát, erről később részletesebben is kitérünk.
Először is tisztázzuk, mi az a webszolgáltatás.
Mi az a webszolgáltatás?
Egyszerűen fogalmazva, a webszolgáltatás lehetővé teszi a számítógépes programok számára, hogy szabványos módon kommunikáljanak egymással.
Kommunikáció három vagy több gép között
Bár a példákban egy vagy két gépen belüli tranzakciókat veszünk figyelembe, a webszolgáltatások nagyszámú számítógép közötti kommunikációra is használhatók. Például a tranzakciók továbbítását vagy tárolását végrehajthatja egy köztes eszköz, vagy az egyik szerveren lévő webszolgáltatás hívása egy másik szerveren lévő szolgáltatás hívását eredményezheti.
A cikk végén, amikor a valódi SOA-t nézzük, a több gépen keresztül kommunikáló webszolgáltatásokról fogunk beszélni, mivel a SOA mindig ezt teszi.
A webszolgáltatás absztrakt összetevő, ahogyan az emberek közötti párbeszéd fogalma is elvont. A párbeszédben két vagy több ember beszél egy általuk ismert nyelven. Nyelvük határozza meg, hogy milyen szavakat használnak, és hogyan használják ezeket a szavakat mondatok kialakítására. A párbeszéd jellemzően kérdés-felelet szerkezetű, amikor valaki feltesz egy kérdést vagy nyilatkozik, és a beszélgetőpartner válaszol rá. Az emberek a közelben lehetnek, kommunikálhatnak telefonon, üzeneteket küldhetnek egymásnak e-mailben vagy chaten.
Mindenesetre a párbeszéd megvan összetett szerkezetés különböző módokon történhet, a kommunikáló személyek számától, a kommunikációhoz használt kommunikációs nyelvtől és a kommunikációhoz használt technológiáktól függően természetesen, ha vannak ilyenek.
A webszolgáltatásokat használó kommunikáció szerkezete számos olyan elemet tartalmaz, amelyeket ebben a cikkben érintünk. Az ötlet azonban ugyanaz, mint a rendszeres párbeszéd – a programok egy általuk ismert nyelven kommunikálnak, néha hálózaton keresztül. A programok elhelyezhetők egy számítógépen, vagy a világ különböző részein különböző gépeken, útválasztókkal és szerverekkel interneten keresztül kapcsolva. Az a jó, hogy a programoknak és a számítógépeknek nem kell azonosnak lenniük. A webszolgáltatásoknak köszönhetően egy laptopon két Microsoft .NET program képes kommunikálni, csakúgy, mint egy kanadai iSeries szerver Java programja egy Kínából származó Linux számítógépen lévő C++ programmal.
A webszolgáltatásokon keresztüli kommunikáció során a következő szabványos technológiákat használják:
- XML. A webszolgáltatás összetevői által használt nyelv (adatformátum).
- SOAP protokoll. A programok között váltott XML üzenetek
- Web Services Description Library (WSDL). XML-fájl, amely meghatározza a SOAP-üzenetek formátumát és küldésének módját
Az Univerzális leírás, felfedezés és integráció (UDDI) néven ismert szabványos technológia szintén használható a webszolgáltatások közötti kommunikációhoz. A cikk későbbi részében ezt meg fogjuk vizsgálni, de mivel az UDDI használata nem kötelező, sok webszolgáltatás nem használja.
Néhány terminológia: közzététel és webszolgáltatások használata
Mielőtt belekezdenénk a kifejezések magyarázatába, nézzünk meg néhány, a webszolgáltatásokhoz kapcsolódó terminológiát.
Amikor egy webszolgáltatás közzétételéről beszélünk, akkor olyan programról beszélünk, amely WSDL fájlt tesz közzé, és lehetővé teszi más programok számára a megfelelő szolgáltatás használatát. A webszolgáltatásokat közzétevő programokat szolgáltatóknak nevezzük.
Amikor webszolgáltatás használatáról beszélünk, olyan programra gondolunk, amely egy másik gépen egy webszolgáltatást hív meg. A webszolgáltatások felhasználóit klienseknek nevezzük.
XML: anyanyelv
Az XML a webszolgáltatás-összetevők közötti kommunikációra szolgál. Az alkalmazások között küldött üzenetek, valamint a webszolgáltatást meghatározó fájlok XML formátumúak. Az 1. ábra egy egyszerű XML fájl szerkezetét mutatja be.
1. ábra: Alapvető XML-struktúra
Amint láthatja, a fájl egyes adatait (például keresztnév, vezetéknév) háromszög zárójelben lévő címkék veszik körül. A János név így jelenik meg
A webszolgáltatások XML-ben való írásának számos előnye van, többek között:
- Az XML szerkezete és nyelvtana hasonló a többi programozási nyelvéhez, így a webszolgáltatásokkal kölcsönhatásba lépő programoknak nem kell közvetlenül XML-fájlok szerkezeti elemzését elvégezniük.
- Az XML fájlok szöveges és ember által olvashatók (más szóval, ha ismeri az XML-t, megnyithat egy XML fájlt szöveg szerkesztőés megértse a tartalmát). Ez segíthet a hibakeresésben.
- Az XML lehetővé teszi bármilyen szabványos kódolás használatát az üzenetekben, így angol, orosz vagy japán nyelven írhat üzeneteket.
- Az XML lehetővé teszi, hogy kihasználja az úgynevezett névteret, amelyben előre meghatározhatja egy adott nevű fájlelem kívánt szerkezetét. Például megadhat egy Price elemet, amelynek mindig lebegő elemnek kell lennie, vagy egy PersonName elemet, amely két karakterlánc-alelemet tartalmaz, a Keresztnév és a Vezetéknév.
Ezenkívül, ha szükséges, a névterek lehetővé teszik, hogy több azonos nevű elemnek eltérő definíciója legyen. Például egy StockPrice elem az egyik névtérben tartalmazhat egy ticker szimbólumot és egy árat, míg egy másik névtérben egy ticker szimbólumból, árból, napi legalacsonyabb és legmagasabb értékből, valamint 12 hónapos csúcsból állhat.
Az XML egyetlen hátránya, ha valóban hátránya, a következők:
- Az XML merev nyelv, ezért az XML-üzenetek helytelen formázása a teljes üzenet elemzése meghiúsulását okozza (még akkor is, ha a probléma könnyen értelmezhető vagy kihagyható). Ha azonban a szabványos könyvtárat használja XML-fájlok létrehozásához (ezt teszi a webszolgáltatások létrehozásakor), a könyvtár maga ellenőrzi a helyes formázást.
- Az XML-üzenet sima szöveges fájlban tárolódik, ezért több helyet foglal el, mint más formátumú megfelelője (például lecsupaszított, bináris vagy "házi" formátumban).
De ezek a problémák jelentéktelenek az XML formátum előnyeihez képest.
SZAPPAN: elküldött üzenetek
Tudja, hogy a webszolgáltatások XML formátumban kommunikálnak, de ez csak a probléma felét oldja meg. Az alkalmazások képesek elemezni az üzenetet, de honnan tudják, mit kezdjenek az elemzés után kapott eredménnyel?
A webszolgáltatások XML-üzeneteinek formázására vonatkozó szabályokat leíró utasítás SOAP néven ismert. Meghatározza az üzenetstruktúrát, hogy a programok tudják, hogyan kell adatokat küldeni és értelmezni. A SOAP üzenetek alapvető felépítése a 2. ábrán látható.
2. ábra: Alapvető SOAP üzenetstruktúra
XML-ben valahogy így nézne ki:
Alapesetben van egy SOAP csomag, amely tartalmaz egy SOAP törzset és egy törzset, amely tartalmazza az átvinni kívánt adatokat. Néha van egy opcionális SOAP fejléc is (a csomagban a törzs előtt), amely további információkat tartalmaz.
SOAP utasítások
Bár a SOAP formátum szabványos, és ugyanazokkal az utasításokkal rendelkezik, ne feledje, hogy a különböző gyártók kissé eltérően hajtják végre ezeket az utasításokat. Például az Apache Axis által generált SOAP-üzenetek névtereinek és XML-ének szerkezete nagyon eltérhet a Microsoft .NET által generált struktúrától. Egy megfelelően megírt kliens vagy szerver azonban minden olyan üzenetet képes feldolgozni, amely a SOAP utasításai szerint megfelelően van megírva.
Ezenkívül van néhány fontos különbség a WSDL 1.1 és a WSDL 2.0 utasítások között. Bár a 2.0-s utasítás a cikk írásakor még a végső szakaszában van, hamarosan átveszi az 1.1-es verzió helyét.
Ha még soha nem találkozott WSDL fájllal, és megpróbálja megnyitni és elolvasni, akkor nehéz lesz minden információt kiszednie belőle, mivel egy ilyen fájl szerkezete meglehetősen bonyolult lehet. A metódussal kapcsolatos összes információ (név, paraméterek, protokoll stb.) a fájl különböző részei között van szétszórva, és a SOAP-üzenet létrehozásához a kliens alkalmazásnak össze kell gyűjtenie azokat. A WSDL fájl részeinek leírása és azok együttműködés nem fog szerepelni ebben a cikkben.
Itt ismét segítségünkre van a technológia. Fejlesztőként nem kell elolvasnia, elemeznie vagy megértenie a WSDL-fájl tartalmát. Az eszközök megkapják ezeket az információkat, így csak azt kell kitalálnia, hogy mit küldjön a szolgáltatásnak, és hová tegye az eredményeket. Te nem csak tudsz használjon könyvtárakat és eszközöket, de biztosan fogsz. Van néhány kivétel, furcsaság és bonyolultság a webszolgáltatások összes összetevőjében, amelyeket érdemes megvizsgálni. segítségével Webszolgáltatás, ahelyett, hogy szétszerelné, majd az egyes összetevők részletes tanulmányozása következik.
Protokollok: az üzenetek küldésének módja
Még nem érintettük azt a kérdést, hogy ezek az üzenetek hogyan továbbíthatók a SOAP-on keresztül?
És általában a hálózaton (és/vagy az interneten) keresztül, a HTTP-protokoll segítségével továbbítják őket, szinte ugyanúgy, mint az oldalakat a szerverről a böngészőbe. A HTTP-t nem mindig használják (fő versenytársa az SMTP, de messze elmarad). A webszolgáltatás által használt protokollt a WSDL fájl határozza meg.
A WSDL-fájl általában HTTP-ként határozza meg a SOAP-üzenet továbbítására használt protokollt. A SOAP kliens a megadott protokoll szerint küld üzeneteket.
Egyéb webszolgáltatási feltételek, amelyekkel találkozhat
Az alapkifejezésekkel már foglalkoztunk, de előfordulhat, hogy a webszolgáltatásokról beszélünk még néhányat.
Gyenge kötelékek
A webszolgáltatásokat használó programok általában gyenge kapcsolatokat ápolnak a szolgáltatásokkal, vagyis a program működéséhez szükséges szolgáltatások nincsenek közvetlenül hozzá kötve, ahogy a program sem kötődik szolgáltatásokhoz. A program könnyedén használhat bármilyen szolgáltatást, amelyre szüksége van, és várják a hívást a programtól - minden olyan programtól, amelyre szükség van a válaszra.
A gyenge kapcsolatok valós példája a barátokkal való ebédelés. Több barát valahogy megegyezik egymással (személyesen, telefonon, keresztül email stb.). Mindenki saját maga jut el az étterembe, ebéd után mindenki maga fizeti az ételt. Akárhogy is sikerült az ebéd, a végeredmény ugyanaz – egy baráti ebéd volt.
Az autóvezetés azonban merevebb kapcsolatokkal rendelkező akció. Van egy rögzített eszközkészlete, amellyel előre meghatározott célokat kell elérnie. Amikor elhagyja a garázst, hátramenetbe állítja az autót, és rálép a gázra. Amikor balra fordul, a kormányt balra fordítja. Nincs lehetősége ugyanazt a dolgot különböző módon megtenni, mivel az egész rendszer nagyon precíz és koherens, és minden eleme össze van kötve a többivel.
UDDI
Az UDDI egy szabvány a tetszőleges számú program által biztosított webszolgáltatások katalógusának létrehozására. Ez olyan, mint egy telefonkönyv a webszolgáltatók számára. Az ügyfelek megkereshetik a szükséges információkat az UDDI nyilvántartásban, és a rendszerleíró adatbázis visszaküldi nekik a szolgáltatáshoz való csatlakozáshoz szükséges adatokat.
Bár az UDDI meglehetősen fontos szabvány a webszolgáltatások meghatározásában, jelentőségét nagymértékben csökkenti az a tény, hogy a webszolgáltatások opcionális eleme, és amikor szabadon választhatják, hogy használják-e vagy sem, sokan úgy döntenek, hogy nem használják.
A legtöbb szervezett vállalati környezet nagyszámú belső webszolgáltatással rendelkezik UDDI-nyilvántartással. Nagyszerű, ha van egy vállalati UDDI webhely, amely információkat tartalmaz a vállalatánál elérhető webszolgáltatásokról. Az összes szolgáltatás egyesítésével az UDDI lehetővé teszi, hogy zökkenőmentesen és zökkenőmentesen váltson szolgáltatót. Ha az ügyfelek UDDI-n keresztül keresnek szolgáltatásokat, akkor a SOAP-hívások automatikusan az új szolgáltatóhoz kerülnek.
Ez az összetevő azonban nem szükséges a webszolgáltatás-architektúrában.
Webszolgáltatások biztonsága
Amikor a SOAP-ról és a WSDL-ről olvas, észreveheti, hogy a biztonság témája nem foglalkozik. Hogyan történik a hitelesítés a szolgáltatási hívásoknál, ha a szolgáltató érzékeny információkkal dolgozik? Nyilvánvaló, hogy nem minden webszolgáltatás elérhető a nagyközönség számára, igaz?
Ez egy fontos kérdés, amelyre nem könnyű végleges választ adni. A helyzettől függően különféle sémákat használhat, például:
- A SOAP üzenetek érkezhetnek szövegként, vagy titkosítani kell őket?
- Elég neked az egyszerű bejelentkezés és jelszó hitelesítés, vagy legyen erős és token alapú?
- Ha tokeneket használnak, kötelező-e aláírni őket, és mi a helyes módja annak, hogy SOAP-üzenetbe foglalják őket?
- Mi van akkor, ha a kliens nem közvetlenül küld SOAP-üzeneteket, hanem valamilyen köztes struktúrán keresztül, például üzenetsoron vagy más webszolgáltatáson keresztül?
Ezenkívül előfordulhat, hogy az üzenetküldés nem mindig használ HTTP-t, így a meglévő HTTP biztonsági rendszereken kívül nem fogja tudni egyszerűen használni a webszolgáltatások biztonsági rendszereit.
Számos irányelv vonatkozik a webszolgáltatás biztonságának ezekre és más vonatkozásaira: WS-Security, WS-Policy, WS-Trust és WS-Privacy. Egyes szoftvergyártók és bizottságok évek óta dolgoznak ezeken a kérdéseken. Bár nem minden webszolgáltatás-megvalósítás támogatja az összes biztonsági irányelvet, a rendelkezésre álló biztonsági szabványok általában legalább néhány alapvető biztonsági utat valósítanak meg.
Middleware és Enterprise Service Bus
Van egy másik meglehetősen nagy szabványkészlet a webszolgáltatásokhoz, amelyeket egy meglehetősen nagy csomóba gyűjtenek össze, amelyeket általában WS-* utasításoknak neveznek. Ezek együttesen számos olyan tervezési szempontot kezelnek, amelyek akkor merülnek fel, amikor sok webszolgáltatást egyetlen környezetbe állít össze. A WS-* szabványok olyan problémákkal foglalkoznak, mint:
- Biztonság
- Megbízhatóság
- Üzenetváltás
- Tranzakciók
- Szolgáltatás minősége
Erre a számú szabványra azért van szükség, mert a webszolgáltatási kliens és a szerver közötti üzenetváltás ipari környezetben sokkal bonyolultabb lehet, mint az egyszerű kérés/válasz. Például hogyan biztosíthatja, hogy az üzenet eljusson a szolgáltatóhoz és visszajusson az ügyfélhez? Mi a teendő, ha egy SOAP-kérés több részből áll? Hogyan kezelheti azokat a folyamatokat, amelyek során a webszolgáltatások más webszolgáltatásokhoz is hozzáférnek? Mi van akkor, ha a program egy sor kérést küld válaszidő-követelményekkel?
A nagy szoftvercégek számára ezekkel a szabványokkal való munka egyszerre jelent kihívásokat és lehetőségeket. Egyes gyártók teljes webszolgáltatási köztesszoftver-csomagokat forgalmaznak, amelyeket gyakran Enterprise Service Bus-oknak vagy ESB-knek neveznek, és amelyek képesek a fenti feladatok mindegyikét vagy legalábbis egy részét kezelni. Ezek az ESB-k azért is értékesek, mert több webszolgáltatást is összekapcsolhatnak ugyanazon a szervezeten belül, és biztosítják funkcionalitásukat, rögzítik a műveleteiket, és sorokban tárolják az üzeneteket.
Szolgáltatás Alapú Achitektúra
És végül a szolgáltatás-orientált architektúra. A legtöbb esetben ez egyszerűen a fentiek kombinációja: lazán összekapcsolt webszolgáltatások különböző gyártóktól, amelyek az elfogadott szabványoknak megfelelően interakcióba lépnek (esetleg az ESB részvételével), és különböző programok gyűjtik össze, amelyek adatokat vesznek a szolgáltatásokból. és különféle módokon használja fel.
Mivel a SOA szoftverarchitektúra, felépítéséhez hatalmas mennyiségű koordinációs és tervezési munka társul. Ez nem csak egy csomó szolgáltatás; ez a szolgáltatások összeállításának és közzétételének megszervezése, milyen menedzsment eszközöket és köztes szoftvereket használnak, és hogyan figyelik és kezelik a szolgáltatásokat és a teljes rendszert.
Ha globálisabban nézzük, a SOA is egyfajta gondolkodás. Ez arra készteti az embert, hogy ne a nagy, önállóan futó programokban gondolkodjon, hanem arra, hogy mindent lehetséges komponensként fog fel, ami publikálható és gyártásban felhasználható. A funkciókban gazdag alkalmazások helyett konkrét és jól definiált szolgáltatásokra gondol – ez a webszolgáltatás.
Miért fontos?
Most már tud valamit a webszolgáltatások működéséről – a kliens beolvassa a szolgáltató WSDL fájlját, annak megfelelően formázza és küldi a SOAP üzenetet, majd válaszul egy újabb SOAP üzenetet kap. Miért olyan fontos ez? Mi a helyzet?
A szolgáltatások fontosságához hozzátartozik, hogy szabványos kommunikációs módot biztosítanak a programok számára, függetlenül attól, hogy milyen nyelven írták őket, vagy milyen platformon futnak. Korábban olyan adatformátumokkal kellett dolgoznunk, amelyek egyediek voltak a különböző programok számára, vagy olyan API-szintű függvényekkel, amelyekkel más nyelvű programok nem tudtak működni. Az XML használata az összes webszolgáltatási szabványban azt jelenti, hogy minden szolgáltatás elérhető és egyértelműen meghatározott.
Valójában ez lehetővé teszi, hogy a teljesen különböző programok könnyen kommunikáljanak egymással olyan nyelven, amelyet mindannyian megértenek. A különböző gyártók különböző technológiáival való munka során az egyik fő kihívás mindig is az volt, hogy ezeket a különböző programokat beszélni kell egymással és adatokat cserélni. Most, hogy az összes alkalmazása képes webszolgáltatásokat nyújtani és/vagy fogyasztani, hihetetlenül egyszerű az interoperabilitás közöttük.
A webszolgáltatások másik előnye, hogy a kliensek és a beszállítók különböző gépeken lehetnek, különböző hardvert és szoftvert használhatnak, és ez nem zavarja a kommunikációt. A programokat más programok is használhatják ugyanazon a gépen, vagy más gépekről is, de meghatározott adatátviteli formátum használatával. A webszolgáltatásoknak csak hálózati kapcsolatra és XML processzorra van szükségük.
Ha mindezeket a tényezőket együtt vesszük figyelembe, az eredmény jelentős. Ha egyszer megvan standard jogorvoslat Az alkalmazások közötti hálózaton keresztüli kommunikációhoz programjainkat másként is felépíthetjük. Ahelyett, hogy monolitikus programokat írnánk, amelyek minden alkalommal újra feltalálják a kereket, írhatunk olyan programokat, amelyek modulokból állnak.
Például egy nagy program helyett, amely több folyamatról gyűjt információkat, grafikonokká alakítja és megmutatja a felhasználóknak, létrehozhatunk egy dashboardot, amely több webszolgáltatástól kapott adatokat is megjelenít. Az összeállított adatokat egy vagy több szolgáltatás fogadja, és az eredményül kapott grafikonokat egy másik webszolgáltatás hozza létre, amely elfogadja az adatokat és grafikont készít.
A műszerfal egy nagy programból egyszerű felületté alakul. Ha új komponenseket szeretnénk hozzáadni, egyszerűen csak további szolgáltatásokhoz fordulunk. Ha más diagramra van szükségünk, akkor egy másik térképező szolgáltatáshoz fordulunk. Ha interaktívabb dashboardra van szükségünk, oktatási vagy rendezési lehetőségekkel, akkor a dashboard képes üzeneteket továbbítani a felhasználótól a megfelelő szolgáltatáshoz. Akár teljesen megváltoztathatjuk a hívott szolgáltatásokat, hogy a felhasználók ne vegyék észre (amíg a WSDL fájl nem változik), és a panel változatlan marad.
Informatikusként egyaránt fejleszthet interfészt és szolgáltatásokat, vagy mindkettőt. Egy ilyen projekten való munka során fontos megérteni, hogyan működik mindez együtt (vagy legalábbis tudni, hogy mi az).
Az is jó, hogy sok olyan eszköz áll rendelkezésre, amelyek segítenek a webszolgáltatások szállításában és használatában, és sokat tehetnek Ön helyett. A cikk következő részeiben meg fogjuk érteni, hogy az IBM Lotus Domino V7.0 használatával hogyan lehet egyszerűen webszolgáltatásokat nyújtani az ügyfeleknek vagy rendszereknek.
