V ktorom roku sa objavili mydlové webové služby. Výpis triedy PersonServiceImpl

S vývojom internetu vznikla potreba vytvárať distribuované aplikácie. Aplikácie nainštalované v počítači zvyčajne využívajú knižnice, ktoré sa na ňom nachádzajú. Niekoľko programov môže používať jednu knižnicu. Môžu byť analógové knižnice zverejnené na internete, aby ich mohli volať rôzne stránky? Ukazuje sa, že áno.

Podniky na svojich stránkach poskytujú rôzne informácie. Napríklad spoločnosť Ford zo svojej webovej stránky http://www.Ford.com zverejňuje informácie o modeloch a cenách. Túto informáciu by chcel mať díler tejto firmy aj na svojej stránke. Webová služba umožňuje spotrebiteľskej stránke získať informácie zo stránky poskytovateľa. Spotrebiteľská stránka zobrazuje tieto informácie na svojich stránkach. Kód na generovanie týchto informácií je napísaný raz, ale môže ho použiť veľa spotrebiteľov. Údaje sú prezentované ako obyčajný text, takže ich možno použiť bez ohľadu na platformu.

Webové služby sú široko používané v desktopových aj internetových aplikáciách. Nie sú to aplikácie samotné, ale zdroje údajov pre aplikácie. Chýbajú používateľské rozhranie... Webové služby nie je potrebné používať cez sieť — môžu byť súčasťou projektu, v ktorom sa používajú.

Webové služby sú funkcie a údaje poskytované na použitie externými aplikáciami, ktoré interagujú so službami prostredníctvom štandardných protokolov a dátových formátov. Webové služby sú úplne nezávislé od jazyka a platformy. Technológia webových služieb je základným kameňom programovacieho modelu spoločnosti Microsoft. NET.

to ďalší vývoj programovanie komponentov CORBA a DCOM. Pre použitie takýchto komponentov je však potrebné ich zaregistrovať v systéme spotrebiteľa. Toto sa nevyžaduje pre webové služby. Komponenty fungujú dobre v lokálnych sieťach. HTTP nie je protokol vzdialeného volania procedúr (RPC). Dokonca aj v rámci tej istej organizácie, rôzne OS ktoré môžu komunikovať iba cez HTTP.

Bolo urobených niekoľko pokusov o vytvorenie komunikačného jazyka medzi heterogénnymi systémami – DCOM, CORBA, RMI, IIOP. Nedostali sa všeobecnej distribúcie, pretože každý z nich bol propagovaný rôznymi výrobcami, a preto bol viazaný na technológie konkrétneho výrobcu. Nikto nechcel prijať štandard niekoho iného. Na prekonanie tejto dilemy sa niekoľko spoločností dohodlo na vývoji štandardu pre odosielanie správ cez HTTP, ktorý je neutrálny voči predajcovi. V máji 2000 sa IBM, Microsoft, HP, Lotus, SAP, UserLand a ďalší priblížili k W3C a navrhli SOAP ako kandidáta na takýto štandard. SOAP spôsobil revolúciu vo vývoji aplikácií zjednotením dvoch internetových štandardov, HTTP a XML.

SOAP

Na interakciu s webovými službami sa používa protokol SOAP založený na XML. Dalo by sa použiť len XML, ale to je príliš voľný formát, v ktorom si každý dokument v skutočnosti vytvára svoj vlastný jazyk. SOAP je konvencia o formáte XML dokumentu, o prítomnosti určitých prvkov a menných priestorov v ňom.

SOAP vám umožňuje publikovať a konzumovať zložité dátové štruktúry, ako napríklad DataSet. Zároveň sa dá ľahko naučiť. Aktuálna verzia SOAP - 1.2.

SOAP je skratka pre Simple Object Access Protocol. SOAP je navrhnutý tak, aby uľahčil aplikáciám komunikáciu cez HTTP. Ide o špecifický formát správ cez internet nezávislý od platformy. Správa SOAP je bežný dokument XML. Štandardné

Lyrická časť.

Predstavte si, že ste implementovali alebo implementujete určitý systém, ktorý by mal byť prístupný zvonku. Tie. existuje určitý server, s ktorým musíte komunikovať. Napríklad webový server.

Tento server môže vykonávať mnoho akcií, pracovať s databázou, vykonávať niektoré požiadavky tretích strán na iné servery, vykonávať nejaké výpočty atď. žiť a prípadne sa vyvíjať podľa jeho známeho scenára (t.j. podľa scenára vývojárov). Človek nemá záujem komunikovať s takýmto serverom, pretože nemusí byť schopný / ochotný poskytnúť krásne stránky s obrázkami a iným užívateľsky príjemným obsahom. Je napísaná a funguje tak, aby fungovala a vydávala na ňu údaje, bez toho, aby sa starala o to, aby boli čitateľné, klient si s nimi poradí sám.

Iné systémy, odkazujúce na tento server, už môžu nakladať s údajmi prijatými z tohto servera podľa vlastného uváženia - spracovať, zhromaždiť, vydať svojim klientom atď.

Jednou z možností komunikácie s takýmito servermi je SOAP. SOAP xml protokol správ.

Praktická časť.

Webová služba (to je to, čo server poskytuje a čo využívajú klienti) umožňuje komunikovať so serverom v prehľadne štruktúrovaných správach. Faktom je, že webová služba neprijíma žiadne údaje. Na každú správu, ktorá nebude v súlade s pravidlami, webová služba odpovie chybou. Chyba bude, mimochodom, aj vo forme xml s jasnou štruktúrou (čo nie je pravda o texte správy).

WSDL (Web Services Description Language). Pravidlá, podľa ktorých sa zostavujú správy pre webovú službu, sú popísané rovnakým spôsobom pomocou xml a tiež majú jasnú štruktúru. Tie. ak webová služba poskytuje možnosť volať metódu, mala by dať klientom vedieť, aké parametre sa pre túto metódu používajú. Ak webová služba očakáva reťazec pre metódu Method1 ako parameter a reťazec musí mať názov Param1, potom budú tieto pravidlá špecifikované v popise webovej služby.

Ako parametre možno odovzdať nielen jednoduché typy, ale aj objekty, kolekcie objektov. Popis objektu je zredukovaný na popis každého komponentu objektu. Ak sa objekt skladá z niekoľkých polí, potom je v každom poli popísaný aký typ, názov (aké možné hodnoty). Polia môžu byť aj zložitého typu a tak ďalej, až kým popis typov nekončí jednoduchými – reťazec, boolean, číslo, dátum... Niektoré špecifické typy sa však môžu ukázať ako jednoduché, dôležité je, aby klienti mohli pochopiť, aké hodnoty v nich môžu byť obsiahnuté.

Klientom stačí poznať url webovej služby, wsdl tam bude vždy, pomocou čoho si môžete urobiť predstavu o metódach a ich parametroch, ktoré táto webová služba poskytuje.

Aké sú výhody všetkých týchto zvončekov a píšťaliek:

  • Vo väčšine systémov sa popis metód a typov vyskytuje v automatický režim... Tie. stačí, keď to povie programátor na serveri túto metódu možno volať cez webovú službu a popis wsdl sa vygeneruje automaticky.
  • Dobre štruktúrovaný popis je čitateľný pre každého mydlového klienta. Tie. bez ohľadu na webovú službu klient pochopí, aké údaje webová služba prijíma. Podľa tohto popisu si klient môže vybudovať vlastnú vnútornú štruktúru tried objektov, tzv. väzba "a. Výsledkom je, že programátor používajúci webovú službu musí napísať niečo ako (pseudokód):

    NewUser: = TSoapUser.Create ("Vasya", "Pupkin", "odmin"); mydlo.AddUser (NewUser);

  • Automatická validácia.

    • xml overenie. xml musí mať správny tvar. neplatný xml - okamžite chyba klientovi, nech na to príde.
    • validácia schémy. xml musí mať špecifickú štruktúru. xml nezodpovedá schéme - okamžite chyba klientovi, nech pochopí.
    • validáciu dát vykonáva mydlový server tak, aby dátové typy, obmedzenia zodpovedali popisu.
  • Je možné implementovať autorizáciu a autentifikáciu samostatná metóda... natívne. alebo pomocou autorizácie http.
  • Webové služby môžu fungovať ako cez protokol mydla, tak aj cez http, to znamená cez požiadavky get. To znamená, že ak sú parametre jednoduché údaje (žiadna štruktúra), potom môžete jednoducho zavolať obvyklé get www.site.com/users.asmx/GetUser?Name=Vasia alebo post. Nie je to však všade a nie vždy.
  • ...pozri wikipediu

Existuje aj veľa nevýhod:

  • Neprimerane veľká veľkosť správy. No, samotná povaha xml je taká, že formát je nadbytočný, čím viac značiek, tým viac zbytočných informácií. Navyše, mydlo dodáva svoju vlastnú redundanciu. V prípade intranetových systémov je problém s prevádzkou menej akútny ako v prípade internetu, takže mydlo lokálne siete viac žiadaný, najmä Sharepoint má webovú službu, s ktorou môžete úspešne (a s určitými obmedzeniami) komunikovať.
  • Automatická zmena popisu webovej služby môže zlomiť všetkých klientov. No, je to ako pre každý systém, ak nie je podporovaná spätná kompatibilita so starými metódami, všetko spadne ...
  • Nie mínus, ale nevýhoda. Všetky akcie pre volanie metód musia byť atomické. Napríklad pri práci s pododdielom môžeme začať transakciu, vykonať niekoľko požiadaviek, potom vrátiť späť alebo zaviazať. V mydle nie sú žiadne transakcie. Jedna žiadosť, jedna odpoveď, rozhovor sa skončil.
  • Môže byť dosť ťažké pochopiť popis toho, čo je na strane servera (je všetko správne popísané mnou?), Čo je na klientovi (čo mi tu bolo napísané?). Niekoľkokrát som musel riešiť klientskú stranu a presviedčať programátora servera, že jeho dáta sú nesprávne popísané a vôbec ničomu nerozumel, pretože automatické generovanie a on akoby nemal, toto je softvérový biznis. A chyba bola prirodzene v kóde metódy, programátor to jednoducho nevidel.
  • Prax ukazuje, že vývojári webových služieb sú strašne ďaleko od ľudí, ktorí tieto webové služby využívajú. V reakcii na akúkoľvek požiadavku (platnú zvonku) môže prísť nezrozumiteľná chyba „Chyba 5. Všetko je zlé“. Všetko záleží na svedomí vývojárov :)
  • Asi som si ešte na niečo nespomenula...

Ako príklad je tu otvorená webová služba belavia:

  • http://86.57.245.235/TimeTable/Service.asmx - vstupný bod, je tam aj textový popis metód pre vývojárov tretích strán.
  • http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl popis metód a typov prijatých a vrátených dát.
  • http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - popis konkrétnej metódy s príkladom xml požiadavky a xml odpovede.

Môžete manuálne vytvoriť a odoslať požiadavku, ako napríklad:

POST /TimeTable/Service.asmx HTTP / 1.1 Host: 86.57.245.235 Content-Type: text / xml; charset = utf-8 Content-Length: length SOAPAction: "http://webservices.belavia.by/GetAirportsList" ru

odpoveď príde:

HTTP / 1.1 200 OK Dátum: Po, 30. september 2013 00:06:44 GMT Server: Microsoft-IIS / 6.0 X-Powered-By: ASP.NET X-AspNet-Verzia: 4.0.30319 Cache-Control: súkromná, max. -vek = 0 Typ obsahu: text / xml; znaková sada = utf-8 Content-Length: 2940

Shl Predtým bola otvorená webová služba Aeroflot, ale potom, čo 1C pridal podporu mydla na 8k, skupina beta testerov 1c ju úspešne ukončila. Teraz sa tam niečo zmenilo (neviem adresy, v prípade záujmu môžete hľadať).
Vyhlásenie ZZY. Povedal mi to na úrovni domácnosti. Môžete kopať.

Vylúčenie zodpovednosti:Na túto tému bolo napísaných veľa článkov a ako ste, samozrejme, uhádli, toto je ďalší. Možno sa z toho dozviete niečo nové, ale nie je tu popísané nič supertajné, čo by ste si nevedeli vygoogliť sami. Iba poznámky z osobnej skúsenosti.

Úvod

Budeme brať do úvahy iba situáciu, keď existuje webová služba tretej strany a úlohou je nadviazať výmenu údajov.

Štruktúra služby je popísaná v súbore WSDL(Anglický jazyk popisu webových služieb)

Súbor je najčastejšie dostupný z odkazu, kde sa nachádza vstupný bod do samotnej webovej služby. Napísal som "najčastejšie", keďže existujú výnimky. Napríklad webová služba založená na SAP nezverejňuje súbor wsdl a možno ho získať iba uvoľnením zo samotnej aplikácie.

A tak máme popis webovej služby, prihlasovacie meno, heslo. Poďme sa spojiť.

// Definujte nastavenia URLServiceNameSpace = "http://Somesite.ru"; Meno používateľa = "TestUser"; Heslo = "q1w2e3"; LocationWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "NiektorýNázovSlužby"; ConnectionPointName = "SomeService_Port"; // Vytvorenie pripojenia SSL = New SecureConnection OpenSSL (); WSDefinition = Nová WSDefinition (UmiestnenieWSDL, SSL); WSProxy = Nové WSProxy (WSDefinition, URL ServiceNameSpace, ServiceName, ConnectionPointName, SSL); WSProxy.User = Meno používateľa; WSProxy.Password = Heslo;

Dobre! Pripojili sme sa k webovej službe! Teoreticky je to základ každej možnosti výmeny, pretože vám umožňuje vytvárať objekt dátovej štruktúry založené na wsdl a práca s takýmto objektom je potešením.

Zvážte XML, ktoré nám poskytuje SoapUI

357 121212 M 19900111 Mercedes GLS Audi TT

Teraz si to popíšeme programovo

// Vytvorenie objektu a jeho naplnenie údajmi XDTOFactory = WSDefinition.XDTOFactory; RootType = CustomXDTO.Type (URL ServiceNameSpace, "SUBMISSION"); RootObject = MyXDTOFactory.Create (RootType); RootObject.ID = "4356"; ClientType = CustomXDTO.Type (URL ServiceNameSpace, "CUSTOMER"); ClientObject = OwnXDTOFactory.Create (ClientType); ClientObject.CLIENT_ID = "121212"; ClientObject.SEX = "M"; // F - žena, M - muž ClientObject.CLIENT_BIRTHDAY = "19900111"; // Klientske autá AutoType = OwnFactoryXDTO.Type (URLServiceNameSpace, "CARS"); AutoObject = OwnXDTOFactory.Create (AutoType); AutoObject.CLASS = "Mercedes"; AutoObject.MODEL = "GLS"; ClientObject.CARS.Add (AutoObject); AutoObject = OwnXDTOFactory.Create (AutoType); AutoObject.CLASS = "Audi"; AutoObject.MODEL = "TT"; ClientObject.CARS.Add (AutoObject); RootObject.CUSTOMER.Add (ClientObject);

Údaje boli úspešne vyplnené. Teraz ich musíte poslať.

Práve v tejto chvíli vzniká veľa nuancií. Skúsme zvážiť každý z nich.

Recept 1. Odoslanie celého objektu XDTO

Výsledok = WSProxy.AddCustomers (RootObject);

Zostáva už len spracovať výsledok, ktorý nám služba vrátila a je to. Súhlaste s tým, že je to veľmi pohodlné!

Ale v praxi to nie je vždy tak. Napríklad 1c sa nezhoduje s predponou určitých značiek vo vnútri xml, keď je menný priestor koreňovej značky odlišný od menného priestoru detí. V takýchto prípadoch musíte mydlo zbierať ručne. Musel som sa popasovať aj s webovými službami, ktoré ako parameter čakajú na čisté xml. Šialenstvo, ale stále to nie je príliš ťažké.

Recept 2. Odoslanie čistého xml ako parametra

XMLWriteParameters = Nové parametre XMLWriterParameters ("UTF-8", "1.0", True); MyXML = Nový záznam XML; MyXML.SetString (Možnosti XMLWriter); MyXML.WriteXMLDeclaration (); MyXDTOFactory.WriteXML (MyXML, RootObject); Reťazec XML = MyXML.Close (); If DeleteNamespaceDescription Then Attempt FirstTagVSRow = StrGetString (XMLString, 2); RootTagName = RootObject.Type (). Názov; XMLString = StringReplace (XMLString, reťazec FirstTagVS, "<"+ИмяКорневогоТэга+">"); Výnimka // DescriptionErrors () EndTry; EndIf; Výsledok = WSProxy.AddCustomers (XML String);

Ak neodstránite priestor názvov, ktorý 1c štandardne pridáva, potom má viac ako 5 riadkov kódu. Častejšie zabalím konverziu xml do funkcie, pretože zvyčajne volám viac ako jednu metódu.

Recept 3. Odoslanie natívnej HTTP požiadavky.

StringSOAP = " | | | "+ reťazec XML +" | |"; // Opíšte hlavičky HTTP požiadavky Headers = New Match; Headers.Insert (" Content-Type "," text / xml; charset = UTF-8 "); Headers.Insert (" SOAPAction "," http: // sap.com/xi/WebService/soap1.1 "); Headers.Insert (" Autorizácia "," Basic "+ GetBase64AuthorizationHeader (používateľské meno, heslo)); // POZOR !!! // Nemôžete programovo vyplniť nasledujúce hlavičky, pretože to vedie k chybe // Platforma ich vyplní správne // Hlavičky. ЧГ = ")); // dĺžka správy // Hlavičky. Vložiť ("Host", "Somesite.ru:8001") ; // Hlavičky. Vložiť ("Pripojenie "," Keep-Alive "); // Hlavičky. Vložiť ("User-Agent", "Apache-HttpClient / 4.1.1 (java 1.5)"); // Pripojiť k site. Connection = New HTTPConnection ("Somesite.ru/WebService/Some", Username, Password, SSL, False); // Adresa musí byť bez https: // // Získajte text koreňovej stránky prostredníctvom požiadavky POST HTTP požiadavka c = New HTTPRequest ("/ GetCustomer", Headers); HTTPRequest.SetBodyFromString (StringSOAP); Výsledok = Connection.CallHTTPMethod ("POST", HTTPRequest);

V tomto prípade budeme musieť zbierať mydlo ručne. V skutočnosti len zabalíme xml z receptu 2 do mydlovej škrupiny, kde si v závislosti od požiadaviek webovej služby môžeme mydlo meniť, ako sa nám páči.

Ďalej popíšeme hlavičky podľa dokumentácie. Niektoré služby našu požiadavku pokojne prežúvajú aj bez hlavičiek, tu sa treba pozrieť na konkrétny prípad. Ak neviete, aké hlavičky napísať, najjednoduchším spôsobom je špehovať požiadavku v SoapUI prepnutím na kartu RAW.

Funkcia na získanie reťazca Base64 vyzerá takto (sledovaná):

Funkcia GetBase64AuthorizationHeader (meno používateľa, heslo) FileCoding = TextCode.UTF8; TemporaryFile = GetTemporaryFileName (); Record = Nový textový záznam (TemporaryFile, FileCode); Record.Record (Užívateľské meno + ":" + Heslo); Record.Close (); DWData = New BinaryData (TemporaryFile); Výsledok = Base64String (DWData); DeleteFiles (TemporaryFile); Výsledok = Priemer (Výsledok, 5); Výsledok vrátenia peňazí; EndFunction

Je tu dôležitý bod. Pri práci s HTTPConnection zadajte adresu bez špecifikovania protokolov "http: //" a "https: //", inak riskujete, že stratíte čas hľadaním zjavnej chyby.

Recept 4. Odoslanie cez WinHttpRequest

WinHttp = Nový COMObject ("WinHttp.WinHttpRequest.5.1"); WinHttp.Option (2, "UTF-8"); WinHttp.Option (4, 13056); // intSslErrorIgnoreFlag WinHttp.Option (6, true); // blnEnableRedirects WinHttp.Option (12, true); // blnEnableHttpsToHttpRedirects WinHttp.Open ("POST", "https://Somesite.ru/WebService/Some/GetCustomer", 0); WinHttp.SetRequestHeader ("Typ obsahu", "text / xml"); WinHttp.SetCredentials (meno používateľa, heslo, 0); WinHttp.Send (String SOAP); WinHttp.WaitForResponse (15); XMLResponse = WinHttp.ResponseText ();

Tu je v podstate to isté ako v predchádzajúcej verzii, ale pracujeme s objektom COM. Pripájací reťazec uvádzame celý spolu s protokolom. Osobitná pozornosť by sa mala venovať iba príznakom chyby certifikátu SSL ignorovať. Sú potrebné, ak pracujeme na SSL, ale bez špecifického certifikátu, keďže pri tejto možnosti nie je možné vytvoriť nové zabezpečené pripojenie (alebo neviem ako). Zvyšok mechanizmu je podobný predchádzajúcemu.

Okrem "WinHttp.WinHttpRequest.5.1" môžete použiť aj "Microsoft.XMLHTTP", "Msxml2.XMLHTTP", "Msxml2.XMLHTTP.3.0", "Msxml2.XMLHTTP.6.0", ak to náhle nezaberie vypnuté na WinHttp. Metódy sú takmer rovnaké, líši sa len počet parametrov. Mám podozrenie, že jedna z týchto možností je pevne zakódovaná v objekte 1c HTTPRequest.

Momentálne sú to všetky recepty, ktoré mám. Ak natrafím na nové, určite článok doplním.

Spracovanie výsledku

V Recepte 1 najčastejšie dostaneme hotový XDTO objekt a pracujeme s ním ako so štruktúrou. Vo všetkých ostatných prípadoch môžete previesť xml odpoveď na XDTO

If Result.StatusCode = 200 Then XMLReader = New XMLReader; ReadXML.SetString (Result.GetBodyAsString ()); ObjectResponse = OwnXDTOFactory.ReadXML (ReadXML); Správa (ObjectResponse.Body.Response.RESPONSE_ID); Správa (ObjectResponse.Body.Response.RESPONSE_TEXT); Koniec Ak;

Všetko je tu jednoduché.

Namiesto záveru

1. Začnite pracovať s webovými službami pomocou programu SoapUI. Je určený na takúto prácu a umožní vám rýchlo pochopiť, ako konkrétna služba funguje. Na zvládnutie je článok

2. Ak si so službou vymieňate cez nezabezpečený http kanál a vyvstáva otázka, čo presne 1c posiela vo vašich správach, potom môžete použiť sledovače návštevnosti ako Wireshark, Fiddler a iné. Problém nastane iba vtedy, ak používate ssl pripojenie.

3. Ak webová služba napriek tomu komunikuje cez https, potom na vzdialený počítač (akýkoľvek, hlavná vec nie je na nás samých) umiestnime server Nginx, na ktorý sa skontaktujeme, a ten sa zase zabalí všetko v https a pošlite to tam, kde je to potrebné ( reverzný proxy ) a pridajte do štandardnej konfigurácie:

Server (počúvať 0.0.0.0:8080; server_name MyServer; umiestnenie ~. * (Proxy_pass https://Somesite.ru:8001; proxy_set_header Host $ host; proxy_set_header Autorizácia "Základné "; proxy_pass_header Autorizácia ;))

5. Ak autentifikácia zahŕňa použitie cookies, potom sa zistilo nasledovné

P.S. Ak máte otázky, návrhy na vylepšenie kódu, máte vlastné recepty, ktoré sa líšia od tých popísaných, našli ste chyby alebo si myslíte, že autor je „štipľavý“ a „nemá miesto v 1c“, napíšte komentáre a my bude diskutovať o všetkom.

Názov témy je skutočne otázkou, pretože Sám neviem, čo to je a po prvý krát s tým skúsim pracovať v rámci tohto článku. Jediné, čo môžem zaručiť, že nižšie uvedený kód bude fungovať, ale moje frázy budú len domnienky a dohady o tom, ako tomu všetkému rozumiem ja. Tak, poďme ...

Úvod

Musíme začať tým, na čo bol koncept webových služieb vytvorený. V čase, keď sa tento koncept objavil, už vo svete existovali technológie, ktoré umožňovali aplikáciám interakciu na diaľku, kde jeden program mohol zavolať nejakú metódu v inom programe, ktorú zároveň bolo možné spustiť na počítači umiestnenom v inom meste alebo dokonca krajina. Toto všetko sa označuje skratkou RPC (Remote Procedure Calling). Príklady zahŕňajú technológie CORBA a pre Java - RMI (Remote Method Invoking). A všetko sa zdá byť v nich dobré, najmä v CORBA, tk. dá sa s ním pracovať v akomkoľvek programovacom jazyku, no stále tomu niečo chýbalo. Domnievam sa, že nevýhodou CORBA je, že funguje prostredníctvom niektorých svojich vlastných sieťové protokoly namiesto jednoduchého HTTP, ktoré prejde cez každý firewall. Myšlienkou webovej služby bolo vytvoriť RPC, ktoré by sa vlepilo do HTTP paketov. Takto sa začal vývoj normy. Aké sú základné pojmy tohto štandardu:
  1. SOAP... Pred volaním vzdialenej procedúry musíte toto volanie popísať XML súbor e formát SOAP. SOAP je jednoducho jedným z mnohých značiek XML používaných vo webových službách. Všetko, čo chceme niekam poslať cez HTTP, sa najskôr premení na XML SOAP popis, potom sa to vloží do HTTP paketu a cez TCP/IP sa odošle na iný počítač v sieti.
  2. WSDL... Existuje webová služba t.j. program, ktorého metódy možno volať na diaľku. Norma ale vyžaduje, aby bol k tomuto programu pripojený popis, ktorý hovorí, že „áno, nemýlite sa – toto je skutočne webová služba a môžete z nej volať také a také metódy.“ Tento popis je reprezentovaný iným súborom XML, ktorý má iný formát, a to WSDL. Tie. WSDL je len súbor s popisom XML pre webovú službu a nič iné.
Prečo sa tak krátko pýtaš? Nevieš dostať viac podrobností? Pravdepodobne môžete, ale na to sa musíte obrátiť na knihy ako Mashnin T. "Java Web Services". Ide o prvých 200 strán Detailný popis každý tag štandardov SOAP a WSDL. mám to urobiť? Podľa môjho názoru nie, tk. toto všetko sa generuje automaticky v Jave a všetko, čo musíte urobiť, je napísať obsah metód, ktoré sa majú volať na diaľku. Takže v Jave bolo také API ako JAX-RPC. Ak niekto nevie, keď hovorí, že Java má také a také API, znamená to, že existuje balík s množinou tried, ktoré zapuzdrujú predmetnú technológiu. JAX-RPC sa dlho vyvíjal z verzie na verziu a nakoniec sa vyvinul do JAX-WS. WS očividne znamená WebService a možno si myslíte, že ide o jednoduché premenovanie RPC na dnes populárne slovo. Nie je tomu tak, keďže Teraz sa webové služby vzdialili od pôvodnej myšlienky a umožňujú nielen volať vzdialené metódy, ale aj jednoducho posielať správy dokumentov vo formáte SOAP. Prečo je to potrebné, zatiaľ neviem, je nepravdepodobné, že odpoveď bude „pre každý prípad, zrazu to bude potrebné“. Sám by som sa rád učil od skúsenejších súdruhov. A posledná vec, potom tu bol aj JAX-RS pre takzvané webové služby RESTful, ale to je téma na samostatný článok. V tomto bode možno úvod ukončiť, pretože ďalej sa naučíme pracovať s JAX-WS.

Všeobecný prístup

Webové služby majú vždy klienta a server. Server je naša webová služba a niekedy sa nazýva koncový bod (ako koncový bod, kam prichádzajú správy SOAP od klienta). Musíme urobiť nasledovné:
  1. Popíšte rozhranie našej webovej služby
  2. Implementujte toto rozhranie
  3. Spustite našu webovú službu
  4. Napíšte klienta a na diaľku zavolajte požadovanú metódu webovej služby
Webovú službu je možné spustiť rôzne cesty: buď deklarujte triedu s hlavnou metódou a spustite webovú službu priamo ako server, alebo ju nasaďte na server, ako je Tomcat alebo čokoľvek iné. V druhom prípade my sami nebeháme nový server a neotvárajte ďalší port na počítači, ale jednoducho povedzte kontajneru servletov Tomcat, že „triedy webových služieb sme napísali tu, zverejnite ich, prosím, aby každý, kto vás kontaktuje, mohol používať našu webovú službu.“ Bez ohľadu na spôsob spustenia webovej služby budeme mať rovnakého klienta.

Server

Začnime IDEA a tvorme nový projekt Vytvoriť nový projekt... Zadáme meno HelloWebService a stlačte tlačidlo Ďalšie, potom tlačidlo Skončiť... V priečinku src vytvoriť balík ru.javarush.ws... V tomto balíku vytvoríme rozhranie HelloWebService: package ru. javarush. ws; // ide o anotácie, t.j. spôsob, ako označiť naše triedy a metódy, // v súvislosti s technológiou webových služieb importovať javax. jws. WebMethod; importovať javax. jws. Webová služba; importovať javax. jws. mydlo. SOAPBinding; // hovoríme, že naše rozhranie bude fungovať ako webová služba@Webová služba // povedzme, že webová služba bude použitá na volanie metód@SOAPBinding (štýl = SOAPBinding. Štýl. RPC) verejné rozhranie HelloWebService ( // hovoríme, že túto metódu možno volať na diaľku@WebMethod public String getHelloString (názov reťazca); ) V tomto kóde sú triedy WebService a WebMethod takzvané anotácie a nerobia nič iné, len označujú naše rozhranie a jeho metódu za webovú službu. To isté platí pre triedu SOAPBinding. Jediný rozdiel je v tom, že SOAPBinding je anotácia parametrov. V v tomto prípade parameter style sa používa s hodnotou, ktorá hovorí, že webová služba bude fungovať nie cez správy dokumentov, ale ako klasické RPC, t.j. zavolať metódu. Implementujme logiku nášho rozhrania a vytvorme v našom balíku triedu HelloWebServiceImpl. Mimochodom, podotýkam, že koniec triedy v Impl je konvencia v Jave, podľa ktorej sa takto označuje implementácia rozhraní (Impl - od slova implementácia, t.j. implementácia). Toto nie je požiadavka a triedu môžete pomenovať akokoľvek chcete, ale pravidlá dobrej formy to vyžadujú: package ru. javarush. ws; // rovnaká anotácia ako pri popise rozhrania, importovať javax. jws. Webová služba; // ale tu sa používa s parametrom endpointInterface, // s uvedením plne kvalifikovaného názvu triedy rozhrania našej webovej služby@WebService (endpointInterface = "ru.javarush.ws.HelloWebService") verejná trieda HelloWebServiceImpl implementuje službu HelloWebService (@Override public String getHelloString (názov reťazca) ( // stačí vrátiť pozdrav návrat "Ahoj," + meno + "!" ; )) Spustite našu webovú službu ako samostatný server, t.j. bez zapojenia akéhokoľvek Tomcatu a aplikačných serverov (toto je téma na samostatnú diskusiu). Ak to chcete urobiť, v štruktúre projektu v priečinku src vytvorme balíček ru.javarush.endpoint av ňom vytvoríme triedu HelloWebServicePublisher s hlavnou metódou: package ru. javarush. koncový bod; // trieda na spustenie webového servera s webovými službami importovať javax. xml. ws. koncový bod; // trieda našej webovej služby dovoz ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher (public static void main (String... args) ( // spustenie webového servera na porte 1986 // a na adrese uvedenej v prvom argumente, // spustenie webovej služby odovzdanej v druhom argumente Koncový bod. zverejniť ( "http: // localhost: 1986 / wss / hello", nový HelloWebServiceImpl ()); )) Teraz spustíme túto triedu kliknutím Shift + F10... V konzole sa nič nezobrazuje, ale server beží. Môžete to overiť tak, že do prehliadača napíšete riadok http: // localhost: 1986 / wss / hello? Wsdl. Stránka, ktorá sa otvorí, na jednej strane dokazuje, že webový server (http: //) sa spustil na našom počítači (localhost) na porte 1986 a na druhej strane zobrazuje WSDL popis našej webovej služby. Ak aplikáciu zastavíte, popis sa stane nedostupným, ako aj samotná webová služba, takže to neurobíme, ale pristúpime k napísaniu klienta.

Zákazník

V priečinku projektu src vytvorte balík ru.javarush.client a v ňom triedu HelloWebServiceClient s hlavnou metódou: package ru. javarush. zákazník; // potreboval získať popis wsdl a cez to // dostať sa k samotnej webovej službe importovať java. net. URL; // k takémuto spusteniu dôjde pri práci s objektom URL importovať java. net. MalformedURLException; // triedy na analýzu xml-ku s popisom wsdl // a dostanete sa na servisný štítok v ňom importovať javax. xml. menný priestor. QName; importovať javax. xml. ws. servis; // rozhranie našej webovej služby (potrebujeme viac) dovoz ru. javarush. ws. HelloWebService; verejná trieda HelloWebServiceClient (public static void main (string args) vyvolá MalformedURLException ( // vytvorte odkaz na popis wsdl Url url= nová adresa URL ( "http: // localhost: 1986 / wss / ahoj? wsdl") ; // Parametre ďalšieho konštruktora sa pozrieme na úplne prvý tag popisu WSDL - definície // pozri 1. argument v atribúte targetNamespace // pozri 2. argument v atribúte name QName qname = nový QName ("http: //ws.site/", "HelloWebServiceImplService"); // Teraz sa môžeme dostať k servisnej značke v popise wsdl, Servisná služba= Služba. vytvoriť (url, qname); // a potom až po značku vnoreného portu, takže // získame odkaz na objekt webovej služby vzdialený od nás HelloWebService ahoj = služba. getPort (trieda HelloWebService); // Hurá! Teraz môžete zavolať vzdialenú metódu systém. von. println (ahoj. getHelloString ("CodeGym")); )) Maximálne komentáre som dal ku kódu vo výpise. Nemám čo dodať, tak bežte (Shift + F10). V konzole by sme mali vidieť text: Ahoj, CodeGym! Ak ste to nevideli, pravdepodobne ste zabudli spustiť webovú službu.

Záver

V tejto téme bol prezentovaný krátky exkurz do webových služieb. Opäť platí, že veľa z toho, čo som napísal, sú moje dohady, ako to funguje, a preto by sa im nemalo príliš dôverovať. Bol by som vďačný, keby znalí ľudia opravia ma, lebo potom sa niečo naučím. UPD.

Alexej Bojko

SOAP a XML webové služby na platforme .Net

Webové služby XML ponúkajú túto úroveň kompatibility a interoperability medzi operačnými systémami,

platformy a jazyky, ktoré predtým jednoducho neboli dostupné.

Andrew Troelsen (MVP (najužitočnejší profesionál v Microsofte))

Ak ste ešte nepracovali s webovými službami XML, pravdepodobne ste už počuli slovo „SOAP“. Je načase sa s týmito pojmami vysporiadať.

Úvod

Ak máte záujem o internet alebo menšie siete, je pravdepodobné, že skôr či neskôr narazíte na webové služby XML. Webová služba XML nie je len webová aplikácia, ktorá môže odosielať informácie do prehliadača. Ide skôr o technológiu vzdialenej komunikácie, ktorá umožňuje vyvolať metódy a vlastnosti objektu cez sieť pomocou štandardných požiadaviek HTTP.

V praxi to znamená, že klienti takejto služby môžu byť napísaní v rôznych jazykoch a pre rôzne operačné systémy.

Ako informačný "transport" medzi službou a klientom môžete použiť metódy HTTP GET alebo POST.

A môžete „prekryť“ ešte jeden protokol – SOAP (Simple Object Access Protocol). Zvyčajne sa to robí, pretože v tomto prípade je možné odovzdať zložité typy (vrátane používateľsky definovaných). A klasické metódy GET a POST podporujú iba zoznamy, jednoduché polia a reťazce.

Príklad SOAP Interop

SOAP správa je XML dokument zabalený do tela HTTP požiadavky.

Výpis 1. Štruktúra správy SOAP

Interakcia medzi klientom a službou je nasledovná:

  • klient vytvorí požiadavku SOAP a odošle ju službe;
  • služba zapnutá vzdialený počítač vykoná procedúru a odošle odpoveď SOAP.

Napríklad požiadavka SOAP môže vyzerať takto: volá metódu HelloWorld () vzdialenej webovej služby XML:

Výpis 2. Príklad požiadavky SOAP

Metóda HelloWorld () podľa očakávania vracia reťazec „Ahoj svet!“:

Výpis 3. Vzorová odpoveď SOAP

Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xsd = "http://www.w3.org/2001/XMLSchema">

Ahoj svet!

Vytvorenie webovej služby XML v .NET 2.0

Môžete vytvoriť službu rôzne cesty, použijeme Visual Studio 2005. Kliknite na "Súbor -> Nový -> Webová lokalita", v otvorenom okne vyberte "Webová služba ASP.NET". Na adrese uvedenej pri vytváraní nájdete nasledujúce súbory a adresáre (pozri obr. 1).

Služba môže v zásade obsahovať iba jeden súbor s príponou * .asmx. (Prípona * .asmx sa používa na označenie webových služieb .Net.) V tomto prípade to tak nie je, pozrite si obsah súboru Service.asmx:

Výpis 4. Service.asmx definuje externý súbor podpora

<%@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" class="Service" %>

Atribút CodeBehind určuje externý súbor umiestnený v priečinku App_Code, ktorý obsahuje kód, ktorý implementuje metódu HelloWorld ():

Výpis 5. Súbor Service.cs implementujúci metódu HelloWorld ().

pomocou systému;

pomocou System.Web;

pomocou System.Web.Services;

Verejná služba () (

Návrat "Ahoj svet";

Je možné vytvoriť jeden súbor Service.asmx bez podporného kódu, ktorý má rovnakú funkčnosť:

Výpis 6. Service.asmx bez externého kódu podpory

<%@ WebService Language="C#" class="Service" %>

pomocou systému;

pomocou System.Web;

pomocou System.Web.Services;

pomocou System.Web.Services.Protocols;

Služba verejnej triedy: System.Web.Services.WebService

Verejná služba () (

Verejný reťazec HelloWorld () (

Návrat "Ahoj svet";

Toto nepotrebujeme a nebudeme to robiť.

Ako vidíte, jediná metóda v našej webovej službe je označená atribútom, ktorý informuje runtime ASP.NET, že táto metóda je dostupná pre prichádzajúce požiadavky HTTP. Členovia, ktorí nie sú identifikovaní týmto atribútom, nebudú k dispozícii klientskym programom.

Takáto jednoduchá služba je celkom vhodná pre naše experimenty, zostáva ju len zverejniť.

Publikovanie webovej služby XML pomocou IIS

Nehovoríme o publikovaní na internete, ale o vytváraní podmienok na testovanie našej služby na lokálnom počítači.

Prvým krokom je inštalácia IIS (Internet Information Server). Ak to chcete urobiť, otvorte okno „Pridať alebo odstrániť programy“ a vyberte „Inštalovať“. súčasti systému Windows". (Niektorí Verzie systému Windows nezahŕňajú inštaláciu IIS, ako napríklad Windows XP Home Edition.)

Poznámka: server IIS je lepšie nainštalovať skôr ako .Net Framework, inak budete musieť nakonfigurovať IIS na podporu aplikácií .Net spustením pomôcky príkazový riadok aspnet_regiis.exe (s príznakom / i).

Vytvorte virtuálny adresár. Ak používate Windows XP Pro, prejdite na "Ovládací panel -> Nástroje na správu -> Internetové informačné služby". V okne, ktoré sa otvorí, vyberte Akcia -> Vytvoriť -> Virtuálny adresár.

Spustí sa Sprievodca vytvorením nového virtuálneho adresára. Alias ​​​​Soap1 a zadajte cestu k adresáru, kam chcete umiestniť službu, napríklad C: \ Soap1. Teraz tam skopírujte obsah našej webovej služby.

Napíšte http: //localhost/soap1/Service.asmx do panela s adresou vášho prehliadača a mala by sa vám zobraziť stránka testovania služby (pozri obrázok 2).

Zobrazenie správ SOAP

Testovacia stránka neumožňuje odosielanie a čítanie správ SOAP. Z tohto dôvodu budete musieť použiť vývoj tretích strán, odporúčam použiť soapUI. (Toto je bezplatný produkt dostupný na http://www.soapui.org.)

Po nainštalovaní soapUI vytvorte nový projekt s názvom soap1, pričom ponechajte pole Initial WSDL prázdne (pozri obrázok 3).

Kliknite pravým tlačidlom myši na novovytvorený projekt a vyberte možnosť „Pridať WSDL z adresy URL“. V dialógovom okne, ktoré sa otvorí, zadajte http: //localhost/soap1/Service.asmx? Wsdl. Teraz máme možnosť odosielať požiadavky SOAP našej službe a prezerať si prijaté odpovede. (Požiadavky budú generované programom soapUI automaticky.)

Čo je to WSDL? Dokument WSDL popisuje, ako klienti interagujú s webovou službou. Popisuje, aké metódy služby sú dostupné pre externé vyvolanie, aké parametre akceptujú a čo vracajú, ako aj ďalšie informácie potrebné na diaľkové ovládanie. Takýto dokument je možné zostaviť ručne, alebo môžete jeho vygenerovaním poveriť server, na to stačí pridať do URL príponu? Wsdl smerujúcu na súbor * .asmx.

Ak chcete zobraziť dokument WSDL pre našu službu, zadajte do prehliadača http: //localhost/soap1/Service.asmx? Wsdl. Informácie z tohto dokumentu používa soapUI na automatické generovanie požiadaviek SOAP.

Rozšírenia SOAP

Ako ste si mohli všimnúť, vytvorenie webovej služby XML (ako aj klienta) sa nemusí zaoberať vzhľadom správ SOAP. Požadované metódy stačí označiť atribútom a runtime ASP.NET vygeneruje balíčky požadovaného formátu.

Na obr. 4 znázorňuje požiadavku a odpoveď webovej služby prijatú pomocou programu soapUI.

Urobme to ešte raz. Požiadavku generuje soapUI – pri vytváraní skutočných klientov pre službu tiež nemusíte manuálne formátovať pakety SOAP. Taktiež sme sa priamo nepodieľali na tvorbe servisnej odpovede. Toto všetko sa deje automaticky.

Je však pravdepodobné, že tieto balíčky budete musieť upraviť sami. Napríklad komprimovať alebo zašifrovať prenášané dáta. Toto je účelom rozšírení SOAP.

SOAP Extensions je mechanizmus, ktorý vám umožňuje ľubovoľne upravovať správy SOAP, ktoré odosielate a prijímate.

Správa SOAP "cesta"

Ak chcete začať s programovaním, musíte zvážiť cestu, ktorou správa SOAP prejde predtým, než je prijatá a spracovaná vhodnou metódou (pozri obrázok 5).

Správu SOAP si možno predstaviť ako dokument XML, ktorý popisuje objekt prenášaný cez sieť. Pred použitím takto odovzdaného predmetu ho treba zreštaurovať (alebo, ak chcete, zmontovať) z tohto popisu. Na tento účel slúži XML serializátor.

Prichádzajúce pakety sú deserializované (obnovenie objektu z popisu XML) a odoslané pakety sú serializované (vytvorenie XML popisu objektu).

Na obr. 5 ukazuje štyri body (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), v ktorých môžeme zachytiť SOAP správu pomocou SOAP Extensions. Upravte ho a pošlite ďalej.

Implementácia rozšírenia SOAP

Na začiatok si definujme úlohu: povedzme, že chceme upraviť pakety SOAP odosielané webovou službou, ako je uvedené vo výpise 7:

Výpis 7. Staré a nové odpovede webovej služby XML

Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xsd = "http://www.w3.org/2001/XMLSchema">

Ahoj svet

Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xsd = "http://www.w3.org/2001/XMLSchema">

Šifrovaný text

Akčný plán na implementáciu rozšírenia SOAP:

  • Vytvorte dll s triedou zdedenou z SoapExtension.
  • Pridajte priečinok bin do našej webovej služby a vložte tam vytvorenú dll.
  • Pridajte súbor web.config do služby a vykonajte v ňom potrebné zmeny.

Úlohu priečinka bin a súboru web.config si rozoberieme neskôr.

Vytvorenie DLL s rozšírením SOAP

Vytvorte nový projekt „Knižnica tried“ s názvom SoapExtensionLib. V tomto projekte potrebujeme implementovať iba jednu triedu, ktorá vykoná potrebné úpravy v balíkoch SOAP. Táto trieda musí dediť z triedy SoapExtension.

Výpis 8. Vytvorenie triedy dediacej z SoapExtension

pomocou systému;

pomocou System.Web.Services;

pomocou System.Web.Services.Protocols;

pomocou System.IO;

pomocou System.Net;

pomocou System.Xml;

Každé rozšírenie SOAP prijíma ako parameter prúd obsahujúci objekt, ktorý sa má preniesť cez sieť (pred alebo po serializácii). A musí vrátiť prúd.

Rozšírenie SOAP si možno predstaviť ako „škatuľu“, ktorú možno umiestniť na jeden alebo všetky zo štyroch bodov (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize) znázornených na obr. 5. V každom bode môže byť takýchto „vložiek“ ľubovoľný počet (pozri obr. 6).

Na príjem týchto tokov sa používa metóda ChainStream.

Výpis 9. Implementácia metódy ChainStream

public class TraceExtension: SoapExtension

Stream wireStream;

Stream appStream;

// metóda ako vstupný parameter

// získa prúd obsahujúci odovzdaný objekt

Verejné prepísanie Stream ChainStream (streamový stream)

WireStream = stream;

AppStream = new MemoryStream ();

Vrátiť appStream;

Pri BeforeDeserialize obsahuje wireStream prijatú požiadavku SOAP zo siete. Túto požiadavku SOAP je potrebné odovzdať toku aplikácie (appStream).

A v bode AfterSerialize musíte poslať wireStream odpoveď SOAP odoslanú do siete, ktorá bude umiestnená v appStream.

Ak chcete pracovať s vláknami v každom zo štyroch bodov, musíte implementovať metódu ProcessMessage.

Výpis 10. Implementácia metódy ProcessMessage, ktorá nemodifikuje správy SOAP

// ProcessMessage vykoná povinnú kópiu

// streamy v dvoch bodoch (BeforeDeserialize a AfterSerialize)

Switch (message.Stage)

// v bode BeforeDeserialize musíte prejsť

// požiadavka SOAP zo sieťového streamu (wireStream)

// do streamu aplikácie (appStream)

Case SoapMessageStage.BeforeDeserialize:

Kopírovať (wireStream, appStream);

AppStream.Position = 0;

Prestávka;

// v bode AfterSerialize musí prejsť

// Odpoveď SOAP z aplikačného toku do sieťového toku

AppStream.Position = 0;

Prestávka;

void Kopírovať (streamovať z, streamovať do)

Čítačka TextReader = new StreamReader (od);

TextWriter Writer = nový StreamWriter (komu);

Writer.WriteLine (reader.ReadToEnd ());

Spisovateľ.Flush ();

Výpis 10 považujte za prázdne miesto pre ďalšie experimentovanie. Táto implementácia metódy ProcessMessage nemá žiadny zmysel - odchádzajúca odpoveď SOAP nie je nijako upravovaná. Opravme to:

Výpis 11. Implementácia metódy ProcessMessage na úpravu odozvy SOAP

verejné prepísanie void ProcessMessage (správa SoapMessage)

Switch (message.Stage)

Prípad SoapMessageStage.AfterSerialize:

WriteOutput (správa);

Prestávka;

// časť kódu bola vystrihnutá, aby sa ušetrilo miesto

// prepíšte odpoveď SOAP

public void WriteOutput (správa SoapMessage)

AppStream.Position = 0;

// vytvorenie XML dokumentu zo streamu

XmlDocument document = new XmlDocument ();

Document.Load (appStream);

// Ak chcete použiť XPath, musíte definovať

// NamespaceManager

XmlNamespaceManager nsmgr = nový XmlNamespaceManager (document.NameTable);

Nsmgr.AddNamespace ("mydlo", "http://schemas.xmlsoap.org/soap/envelope/");

XmlNode ResultNode = document.SelectSingleNode ("// soap: Body", nsmgr);

// nahradenie obsahu uzla

ResultNode.InnerText = "ciphertext";

// vyčistite stream a napíšte doň novú odpoveď SOAP

AppStream.SetLength (0);

AppStream.Position = 0;

Document.Save (appStream);

// POVINNÁ AKCIA

// odoslanie odpovede SOAP z aplikačného streamu (appStream)

// do sieťového streamu (wireStream)

AppStream.Position = 0;

Kopírovať (appStream, wireStream);

Ďalej musíte definovať dve metódy (jedna z nich je preťažená, to znamená, že ju možno volať s rôznymi súbormi parametrov), ktoré v našom prípade nie sú potrebné. Musíme ich však definovať v súlade s pravidlami dedenia z triedy SoapExtension.

Zoznam 12. Ďalšie požadované metódy

// V súlade s pravidlami dedenia musíme

// definujeme tieto metódy, ale v žiadnom prípade ich nepoužívame

verejný objekt prepísania?

GetInitializer (LogicalMethodInfo methodInfo, atribút SoapExtensionAttribute)

Return null;

verejný objekt prepísania GetInitializer (typ WebServiceType)

Return null;

verejné prepísanie void Inicializovať (inicializátor objektu)

Návrat;

To je všetko, zostavujeme projekt. Nakoniec sme dostali dll s rozšírením SOAP. Kompletný zoznam SoapExtensionLib.dll nájdete na stránke časopisu v sekcii „Zdrojový kód“.

Konfigurácia webovej služby na prácu s rozšírením SOAP

Znovu otvorte náš projekt webovej služby XML pomocou Visual Studia. Kliknite na „Webová lokalita -> Pridať referenciu“ a vyberte súbor SoapExtensionLib.dll, ktorý ste vytvorili predtým.

Priečinok Bin sa automaticky pridá do projektu. Aplikácia automaticky odkazuje na súbory *.dll umiestnené v priečinku Bin.

Teraz vložte nasledujúci obsah do súboru Web.Config v adresári webovej služby:

Výpis 13. Súbor Web.Config

Priorita = "1"

Skupina = "0" />

Teraz štruktúra našej služby vyzerá ako na obr. 7.

Súbor Web.Config používame na informovanie rámca ASP.NET, že sme do webovej služby pridali rozšírenie XML Soap, ktoré je implementované v triede TraceExtension nachádzajúcej sa v súbore SoapExtensionLi.dll.

Výpis 14. Sekcia webových služieb v súbore Web.Config

Priorita = "1"

Skupina = "0" />

Ako už viete, je možné vytvoriť mnoho rozšírení SOAP a prúd prenášajúci odovzdaný objekt (pred alebo po serializácii) bude prechádzať každým z nich. Poradie, v ktorom tok prúdi cez rôzne rozšírenia SOAP, sa určuje pomocou atribútov priority a skupiny.

Stojí za zmienku, že konfiguráciou Web.Config týmto spôsobom informujeme okolie, že pre každú metódu služby označenú atribútom sa bude volať naše SOAP Extension. Je možné vytvoriť si vlastný atribút a označiť ním len tie metódy, pre ktoré potrebujete volať SOAP Extension.

Výpis 15. Príklad použitia vlastného atribútu

verejný reťazec HelloWorld () (

Návrat "Ahoj svet";

Ak to chcete urobiť, pridajte triedu zdedenú z SoapExtensionAttribute do SoapExtensionLi.dll (pozri obrázok 8).

Záver

Tento článok odráža hlavné body konštrukcie a prevádzky webových služieb XML na platforme .Net. Dúfam, že prezentovaný materiál bude dostatočný na to, aby ste sa v prípade potreby mohli venovať hlbšiemu štúdiu témy.


V kontakte s