S rozvojem internetu vznikla potřeba vytvářet distribuované aplikace. Aplikace nainstalované v počítači obvykle využívají knihovny, které jsou na něm umístěny. Jednu knihovnu může používat několik programů. Mohou být analogy knihoven zveřejněny na internetu, aby je mohly volat různé stránky? Ukázalo se, že ano.
Podniky na svých stránkách poskytují různé informace. Například společnost Ford na svých webových stránkách http://www.Ford.com zveřejňuje informace o modelech a cenách. Tuto informaci by chtěl mít dealer této firmy i na svém webu. Webová služba umožňuje spotřebitelské stránce získat informace ze stránky poskytovatele. Spotřebitelský web zobrazuje tyto informace na svých stránkách. Kód pro generování těchto informací je napsán jednou, ale může být použit mnoha spotřebiteli. Data jsou prezentována jako prostý text, takže je lze použít bez ohledu na platformu.
Webové služby jsou široce používány v desktopových i internetových aplikacích. Nejsou to aplikace samotné, ale zdroje dat pro aplikace. Chybí uživatelské rozhraní... Webové služby není nutné používat přes síť — mohou být součástí projektu, ve kterém jsou použity.
Webové služby jsou funkce a data poskytovaná pro použití externími aplikacemi, které interagují se službami prostřednictvím standardních protokolů a datových formátů. Webové služby jsou zcela nezávislé na jazyku a platformě. Technologie webových služeb je základním kamenem programovacího modelu společnosti Microsoft. SÍŤ.
to další vývoj programování komponent CORBA a DCOM. Pro použití takových komponent je však nutné je zaregistrovat v systému spotřebitele. Toto není vyžadováno pro webové služby. Komponenty fungují dobře v místních sítích. HTTP není protokol vzdáleného volání procedur (RPC). I v rámci stejné organizace, různé OS které mohou komunikovat pouze přes HTTP.
Bylo učiněno několik pokusů o vytvoření komunikačního jazyka mezi heterogenními systémy - DCOM, CORBA, RMI, IIOP. Neobdržely všeobecnou distribuci, protože každý z nich byl propagován různými výrobci, a proto byl vázán na technologie konkrétního výrobce. Nikdo nechtěl přijmout standard někoho jiného. K překonání tohoto dilematu se několik společností dohodlo na vývoji standardu pro zasílání zpráv přes HTTP, který je neutrální vůči dodavatelům. V květnu 2000 se IBM, Microsoft, HP, Lotus, SAP, UserLand a další přiblížily k W3C a předložily SOAP jako kandidáta na takový standard. SOAP způsobil revoluci ve vývoji aplikací spojením dvou internetových standardů, HTTP a XML.
MÝDLO
Pro interakci s webovými službami se používá protokol SOAP založený na XML. Dalo by se použít pouze XML, ale to je příliš volný formát, ve kterém si každý dokument vlastně vytváří svůj vlastní jazyk. MÝDLO je konvence o formátu dokumentu XML, o přítomnosti určitých prvků a jmenných prostorů v něm.
SOAP vám umožňuje publikovat a využívat složité datové struktury, jako je DataSet. Přitom se dá snadno naučit. Současná verze SOAP - 1.2.
SOAP je zkratka pro Simple Object Access Protocol. SOAP je navržen tak, aby aplikacím usnadnil komunikaci přes HTTP. Jedná se o specifický formát zpráv přes internet nezávislý na platformě. Zpráva SOAP je běžný dokument XML. Standard
Lyrická část.
Představte si, že jste zavedli nebo zavádíte určitý systém, který by měl být přístupný zvenčí. Tito. existuje určitý server, se kterým musíte komunikovat. Například webový server.
Tento server může provádět mnoho akcí, pracovat s databází, provádět některé požadavky třetích stran na jiné servery, provádět nějaké výpočty atd. žít a případně se vyvíjet podle jeho známého scénáře (tedy podle scénáře vývojářů). Člověk nemá zájem komunikovat s takovým serverem, protože nemusí být schopen / ochoten poskytnout krásné stránky s obrázky a jiným uživatelsky příjemným obsahem. Je napsán a funguje tak, aby fungoval a vydával na něj data k požadavkům, aniž by se staral o to, aby byly čitelné pro člověka, klient si s nimi poradí sám.
Jiné systémy, odkazující na tento server, již mohou nakládat s daty přijatými z tohoto serveru podle vlastního uvážení - zpracovávat, hromadit, vydávat svým klientům atd.
Jednou z možností pro komunikaci s takovými servery je SOAP. Protokol pro zasílání zpráv SOAP xml.
Praktická část.
Webová služba (to je to, co server poskytuje a co využívají klienti) umožňuje komunikovat se serverem v jasně strukturovaných zprávách. Faktem je, že webová služba nepřijímá žádná data. Na každou zprávu, která nebude v souladu s pravidly, webová služba odpoví chybou. Chyba bude mimochodem také ve formě xml s jasnou strukturou (což není pravda o textu zprávy).
WSDL (Web Services Description Language). Pravidla, podle kterých se sestavují zprávy pro webovou službu, jsou popsána stejným způsobem jako u pomocí xml a také mají jasnou strukturu. Tito. pokud webová služba poskytuje možnost volat metodu, měla by dát klientům vědět, jaké parametry se pro tuto metodu používají. Pokud webová služba očekává jako parametr řetězec pro metodu Method1 a řetězec se musí jmenovat Param1, pak budou tato pravidla specifikována v popisu webové služby.
Jako parametry lze předávat nejen jednoduché typy, ale také objekty, kolekce objektů. Popis objektu je redukován na popis každé součásti objektu. Pokud se objekt skládá z několika polí, pak je u každého pole popsán typ, název (jaké možné hodnoty). Pole mohou být i složitého typu a tak dále, dokud popis typů nekončí jednoduchými – řetězec, boolean, číslo, datum... Některé konkrétní typy se však mohou ukázat jako jednoduché, důležité je, aby klienti mohli pochopit, jaké hodnoty v nich mohou být obsaženy.
Klientům stačí znát url webové služby, vždy tam bude wsdl, pomocí kterého si můžete udělat představu o metodách a jejich parametrech, které tato webová služba poskytuje.
Jaké jsou výhody všech těchto zvonků a píšťalek:
- Ve většině systémů se popis metod a typů vyskytuje v automatický režim... Tito. stačí, když to řekne programátor na serveru tato metoda lze volat prostřednictvím webové služby a popis wsdl se vygeneruje automaticky.
Automatická validace.
- xml validace. xml musí být správně vytvořen. neplatný xml - okamžitě chyba klientovi, ať na to přijde.
- validace schématu. xml musí mít specifickou strukturu. xml neodpovídá schématu - okamžitě chyba klientovi, ať to pochopí.
- validaci dat provádí soap-server tak, aby datové typy, omezení odpovídaly popisu.
- Lze implementovat autorizaci a autentizaci samostatná metoda... nativně. nebo pomocí http autorizace.
- Webové služby mohou fungovat jak přes protokol soap, tak i přes http, tedy prostřednictvím požadavků get. To znamená, že pokud jsou parametry jednoduchá data (bez struktury), můžete jednoduše zavolat obvyklé get www.site.com/users.asmx/GetUser?Name=Vasia nebo post. To však není všude a ne vždy.
- ... viz wikipedie
Dobře strukturovaný popis je čitelný pro každého mýdlového klienta. Tito. bez ohledu na webovou službu klient pochopí, jaká data webová služba přijímá. Podle tohoto popisu si klient může sestavit vlastní vnitřní strukturu tříd objektů, tzv. vazba "a. V důsledku toho musí programátor používající webovou službu napsat něco jako (pseudokód):
NewUser: = TSoapUser.Create ("Vasya", "Pupkin", "odmin"); soap.AddUser (NewUser);
Existuje také spousta nevýhod:
- Nepřiměřeně velká velikost zprávy. No, samotná podstata xml je taková, že formát je nadbytečný, čím více značek, tím více zbytečných informací. Navíc mýdlo dodává svou vlastní redundanci. U intranetových systémů je problém s provozem méně akutní než u internetu lokální sítě více žádané, konkrétně Sharepoint má mýdlovou webovou službu, se kterou můžete úspěšně (a s určitými omezeními) komunikovat.
- Automatická změna popisu webové služby může zničit všechny klienty. No, je to jako u každého systému, pokud není podporována zpětná kompatibilita se starými metodami, všechno spadne ...
- Ne mínus, ale nevýhoda. Všechny akce pro volání metod musí být atomické. Například při práci s pododdělením můžeme zahájit transakci, provést několik požadavků a poté vrátit zpět nebo potvrdit. V mýdle nejsou žádné transakce. Jedna žádost, jedna odpověď, konverzace je u konce.
- Může být docela obtížné porozumět popisu toho, co je na straně serveru (popisuji vše správně?), Co je na klientovi (co mi tu bylo napsáno?). Několikrát jsem musel jednat s klientskou stranou a přesvědčit programátora serveru, že jeho data jsou špatně popsána a vůbec ničemu nerozuměl, protože automatické generování a on jakoby neměl, tohle je softwarová firma. A chyba byla přirozeně v kódu metody, programátor ji prostě neviděl.
- Praxe ukazuje, že vývojáři webových služeb jsou strašně daleko od lidí, kteří tyto webové služby využívají. V reakci na jakýkoli požadavek (platný zvenčí) může přijít nesrozumitelná chyba „Chyba 5. Všechno je špatné“. Vše záleží na svědomí vývojářů :)
- Asi jsem si ještě na něco nevzpomněl...
Jako příklad je zde otevřená webová služba belavia:
- http://86.57.245.235/TimeTable/Service.asmx - vstupní bod, je zde i textový popis metod pro vývojáře třetích stran.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl popis metod a typů přijímaných a vracených dat.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - popis konkrétní metody s příkladem xml požadavku a xml odpovědi.
Můžete ručně vytvořit a odeslat požadavek jako:
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"
odpověď přijde:
HTTP / 1.1 200 OK Datum: Po, 30. září 2013 00:06:44 GMT Server: Microsoft-IIS / 6.0 X-Powered-By: ASP.NET X-AspNet-Verze: 4.0.30319 Řízení mezipaměti: soukromé, max. -věk = 0 Typ obsahu: text / xml; znaková sada = utf-8 Content-Length: 2940
Shl Dříve byla otevřena webová služba Aeroflot, ale poté, co 1C přidal podporu mýdla na 8k, skupina beta testerů 1c ji úspěšně ukončila. Teď se tam něco změnilo (neznám adresy, v případě zájmu můžete hledat).
ZZY Vyloučení odpovědnosti. Řekl mi to na úrovni domácnosti. Můžeš kopnout.
Vyloučení odpovědnosti:Na toto téma bylo napsáno mnoho článků a jak jste samozřejmě uhodli, toto je další. Možná se z toho dozvíte něco nového, ale není zde popsáno nic supertajného, co byste si nemohli sami vygooglit. Pouze poznámky z vlastní zkušenosti.
Úvod
Budeme zvažovat pouze situaci, kdy existuje webová služba třetí strany a jejím úkolem je zřídit výměnu dat.
Struktura služby je popsána v souboru WSDL(Anglický jazyk popisu webových služeb)
Soubor je nejčastěji dostupný z odkazu, kde se nachází vstupní bod do samotné webové služby. Napsal jsem "nejčastěji", protože existují výjimky. Například webová služba založená na SAP nepublikuje soubor wsdl a lze jej získat pouze uvolněním ze samotné aplikace.
A tak máme popis webové služby, přihlašovací jméno, heslo. Pojďme se propojit.
// Definujte nastavení URLServiceNameSpace = "http://Somesite.ru"; UserName = "TestUser"; Heslo = "q1w2e3"; LocationWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "NěkteréNázevSlužby"; ConnectionPointName = "SomeService_Port"; // Vytvořit připojení SSL = New SecureConnection OpenSSL (); WSDefinition = Nová WSDefinition (LocationWSDL, SSL); WSProxy = Nové WSProxy (WSDefinition, URL ServiceNameSpace, ServiceName, ConnectionPointName, SSL); WSProxy.User = Uživatelské jméno; WSProxy.Password = Heslo;
Pokuta! Připojili jsme se k webové službě! Teoreticky je to základ každé výměnné opce, protože vám umožňuje vytvářet objekt datové struktury založené na wsdl a práce s takovým objektem je radost.
Zvažte XML, které nám poskytuje SoapUI
Nyní si to popíšeme programově
// Vytvořte objekt a naplňte jej daty 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"; // Klientská auta 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 byly úspěšně vyplněny. Nyní je musíte odeslat.
Právě v tuto chvíli vyvstává mnoho nuancí. Zkusme zvážit každý z nich.
Recept 1. Odeslání celého objektu XDTO
Výsledek = WSProxy.AddCustomers (RootObject);
Zbývá pouze zpracovat výsledek, který se nám služba vrátila a je to. Souhlaste, že je to velmi pohodlné!
Ale v praxi tomu tak vždy není. Například 1c si nerozumí s předponou určitých značek uvnitř xml, když se jmenný prostor kořenové značky liší od jmenného prostoru dětí. V takových případech musíte mýdlo sbírat ručně. Musel jsem se také potýkat s webovými službami, které jako parametr čekají na čisté xml. Šílenství, ale přesto to není příliš obtížné.
Recept 2. Odeslání čistého xml jako parametru
XMLWriteParameters = Nové XMLWriterParameters ("UTF-8", "1.0", True); MyXML = Nový záznam XML; MyXML.SetString (volby XMLWriter); MyXML.WriteXMLDeclaration (); MyXDTOFactory.WriteXML (MyXML, RootObject); Řetězec XML = MyXML.Close (); If DeleteNamespaceDescription Then Attempt FirstTagVSRow = StrGetString (XMLString, 2); RootTagName = RootObject.Type (). Název; XMLString = StringReplace (XMLString, řetězec FirstTagVS, "<"+ИмяКорневогоТэга+">"); Výjimka // DescriptionErrors () EndTry; EndIf; Výsledek = WSProxy.AddCustomers (XML String);
Pokud neodeberete jmenný prostor, který 1c ve výchozím nastavení přidává, stane se z něj více než 5 řádků kódu. Častěji než ne, zabalím xml konverzi do funkce, protože obvykle volám více než jednu metodu.
Recept 3. Odeslání nativního požadavku HTTP.
StringSOAP = "V tomto případě budeme muset sbírat mýdlo ručně. Ve skutečnosti jen zabalíme xml z receptu 2 do mýdlové skořápky, kde v závislosti na požadavcích webové služby můžeme naše mýdlo libovolně měnit.
Dále popíšeme hlavičky podle dokumentace. Některé služby naši žádost klidně přežvýkají bez hlaviček, zde je potřeba se podívat na konkrétní případ. Pokud nevíte, jaké hlavičky napsat, pak je nejjednodušší špehovat požadavek v SoapUI přepnutím na záložku RAW.
Funkce pro získání řetězce Base64 vypadá takto (sledováno):
Funkce GetBase64AuthorizationHeader (uživatelské jméno, heslo) FileCoding = TextCode.UTF8; TemporaryFile = GetTemporaryFileName (); Záznam = Nový textový záznam (TemporaryFile, FileCode); Record.Record (Uživatelské jméno + ":" + Heslo); Record.Close (); DWData = New BinaryData (TemporaryFile); Výsledek = Base64String (DWData); DeleteFiles (TemporaryFile); Výsledek = prům. (výsledek, 5); Výsledek vrácení peněz; EndFunction
Je tu důležitý bod. Při práci s HTTPConnection zadejte adresu bez uvedení protokolů "http: //" a "https: //", jinak riskujete ztrátu času hledáním zjevné chyby.
Recept 4. Odeslání přes 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 (uživatelské jméno, heslo, 0); WinHttp.Send (String SOAP); WinHttp.WaitForResponse (15); XMLResponse = WinHttp.ResponseText ();Zde v podstatě stejné jako v předchozí verzi, ale pracujeme s objektem COM. Připojovací řetězec označujeme celý spolu s protokolem. Zvláštní pozornost by měla být věnována pouze ignorování příznaků chyby certifikátu SSL. Jsou potřeba, pokud pracujeme na SSL, ale bez konkrétního certifikátu, protože v této možnosti nelze vytvořit nové zabezpečené připojení (nebo nevím jak). Zbytek mechanismu je podobný předchozímu.
Kromě "WinHttp.WinHttpRequest.5.1" můžete také použít "Microsoft.XMLHTTP", "Msxml2.XMLHTTP", "Msxml2.XMLHTTP.3.0", "Msxml2.XMLHTTP.6.0", pokud to náhle nezabere vypnuto na WinHttp. Metody jsou téměř stejné, liší se pouze počet parametrů. Mám podezření, že jedna z těchto možností je pevně zakódována v objektu 1c HTTPRequest.
Momentálně jsou to všechny recepty, které mám. Pokud narazím na nové, určitě článek doplním.
Zpracování výsledku
V Receptu 1 nejčastěji dostaneme hotový XDTO objekt a pracujeme s ním jako se strukturou. Ve všech ostatních případech můžete převést xml odpověď na XDTO
If Result.StatusCode = 200 Then XMLReader = New XMLReader; ReadXML.SetString (Result.GetBodyAsString ()); ObjectResponse = OwnXDTOFactory.ReadXML (ReadXML); Zpráva (ObjectResponse.Body.Response.RESPONSE_ID); Zpráva (ObjectResponse.Body.Response.RESPONSE_TEXT); EndIf;
Všechno je zde jednoduché.
Místo závěru
1. Začněte pracovat s webovými službami pomocí programu SoapUI. Pro takovou práci je určen a umožní vám rychle pochopit, jak konkrétní služba funguje. K masteringu je článek
2. Pokud si se službou vyměňujete přes nezabezpečený http kanál a vyvstane otázka, co přesně 1c posílá ve vašich zprávách, můžete použít sniffery provozu jako Wireshark, Fiddler a další. Problém nastane pouze v případě, že používáte ssl připojení.
3. Pokud přesto webová služba komunikuje přes https, pak na vzdálený počítač (jakýkoli, hlavní věc není náš vlastní) vložíme server Nginx, na který se obrátíme, a ten se zase zabalí vše v https a poslat tam, kde je to nutné ( reverzní proxy ) a přidejte do standardní konfigurace:
Server (list 0.0.0.0:8080; server_name MyServer; umístění ~. * (Proxy_pass https://Somesite.ru:8001; proxy_set_header Host $ host; proxy_set_header Authorization "Základní
5. Pokud autentizace zahrnuje použití cookies, pak bylo zjištěno následující
P.S. Pokud máte dotazy, návrhy na vylepšení kódu, máte své vlastní recepty, které se liší od těch popsaných, našli jste chyby nebo si myslíte, že autor je „prkný“ a „nemá místo v 1c“, napište komentáře a my vám vše probrat.
Název tématu je opravdu otázkou, protože Sám nevím, co to je a poprvé se s tím pokusím pracovat v rámci tohoto článku. Jediná věc, kterou mohu zaručit, že níže uvedený kód bude fungovat, ale moje fráze budou jen domněnky a dohady o tom, jak tomu všemu sám rozumím. Tak pojďme ...
Úvod
Musíme začít tím, k čemu byl koncept webových služeb vytvořen. V době, kdy se tento koncept objevil, již ve světě existovaly technologie, které umožňovaly interakci aplikací na dálku, kdy jeden program mohl volat nějakou metodu v jiném programu, kterou bylo možné spustit na počítači umístěném v jiném městě nebo dokonce v zemi. To vše se označuje zkratkou RPC (Remote Procedure Calling). Příklady zahrnují technologie CORBA a pro Javu - RMI (Remote Method Invoking). A vše se zdá být v nich dobré, zejména v CORBA, tk. můžete s ním pracovat v jakémkoli programovacím jazyce, ale stále tomu něco chybělo. Domnívám se, že nevýhodou CORBA je, že funguje prostřednictvím některých svých vlastních síťových protokolů místo jednoduchého HTTP, které proleze jakýkoli firewall. Myšlenkou této webové služby bylo vytvořit RPC, které by se drželo paketů HTTP. Takto začal vývoj standardu. Jaké jsou základní pojmy tohoto standardu:- MÝDLO... Před voláním vzdálené procedury musíte toto volání popsat XML soubor e formátu SOAP. SOAP je jednoduše jedním z mnoha značek XML používaných ve webových službách. Vše, co chceme někam poslat přes HTTP, se nejprve převede do XML SOAP popisu, pak se to vloží do HTTP paketu a přes TCP/IP se to pošle na jiný počítač v síti.
- WSDL... Existuje webová služba, tj. program, jehož metody lze volat na dálku. Norma ale vyžaduje, aby byl k tomuto programu připojen popis, který říká, že „ano, nepletete se – toto je skutečně webová služba a můžete z ní volat takové a takové metody“. Tento popis je reprezentován jiným souborem XML, který má jiný formát, a to WSDL. Tito. WSDL je pouze soubor popisu XML pro webovou službu a nic jiného.
Obecný přístup
Webové služby mají vždy klienta a server. Server je naše webová služba a někdy se nazývá koncový bod (jako koncový bod, kam chodí zprávy SOAP od klienta). Musíme provést následující:- Popište rozhraní naší webové služby
- Implementujte toto rozhraní
- Spusťte naši webovou službu
- Napište klienta a vzdáleně zavolejte požadovanou metodu webové služby
server
Začněme IDEA a tvoříme nový projekt Vytvořit nový projekt... Zadáme jméno HelloWebService a stiskněte tlačítko další, poté tlačítko Dokončit... Ve složce src vytvořit balíček ru.javarush.ws... V tomto balíčku vytvoříme rozhraní HelloWebService: package ru. javarush. ws; // jedná se o anotace, tzn. způsob, jak označit naše třídy a metody, // ve vztahu k technologii webových služeb import javax. jws. WebMethod; import javax. jws. Webová služba; import javax. jws. mýdlo. SOAPBinding; // říkáme, že naše rozhraní bude fungovat jako webová služba@Webová služba // říká, že webová služba bude použita k volání metod@SOAPBinding (style = SOAPBinding. Styl. RPC) veřejné rozhraní HelloWebService ( // říkáme, že tuto metodu lze volat na dálku@WebMethod public String getHelloString (název řetězce); ) V tomto kódu jsou třídy WebService a WebMethod tzv. anotacemi a nedělají nic jiného, než že označují naše rozhraní a jeho metodu jako webovou službu. Totéž platí pro třídu SOAPBinding. Jediný rozdíl je v tom, že SOAPBinding je anotace parametru. PROTI v tomto případě parametr style se používá s hodnotou, která říká, že webová služba bude fungovat nikoli přes zprávy dokumentů, ale jako klasické RPC, tzn. zavolat metodu. Pojďme implementovat logiku našeho rozhraní a vytvořit v našem balíčku třídu HelloWebServiceImpl. Mimochodem podotýkám, že konec třídy v Impl je konvence v Javě, podle které se takto označuje implementace rozhraní (Impl - od slova implementace, tedy implementace). Toto není požadavek a můžete si třídu pojmenovat, jak chcete, ale pravidla dobré formy to vyžadují: package ru. javarush. ws; // stejná anotace jako při popisu rozhraní, import javax. jws. Webová služba; // ale používá se zde s parametrem endpointInterface, // s uvedením plně kvalifikovaného názvu třídy rozhraní naší webové služby@WebService (endpointInterface = "ru.javarush.ws.HelloWebService") veřejná třída HelloWebServiceImpl implementuje službu HelloWebService (@Override public String getHelloString (název řetězce) ( // stačí vrátit pozdrav návrat "Ahoj," + jméno + "!" ; )) Začněme naši webovou službu jako samostatný server, tzn. bez zapojení jakéhokoli Tomcatu a aplikačních serverů (toto je téma na samostatnou diskusi). Chcete-li to provést, ve struktuře projektu ve složce src pojďme vytvořit balíček ru.javarush.endpoint a v něm vytvořit třídu HelloWebServicePublisher s hlavní metodou: package ru. javarush. koncový bod; // třída pro spuštění webového serveru s webovými službami import javax. xml. ws. Koncový bod; // třída naší webové služby import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher (public static void main (String... args) ( // spusťte webový server na portu 1986 // a na adrese uvedené v prvním argumentu, // spuštění webové služby předané ve druhém argumentu Koncový bod. zveřejnit ( "http: // localhost: 1986 / wss / hello", nový HelloWebServiceImpl ()); )) Nyní spustíme tuto třídu kliknutím Shift + F10... V konzole se nic nezobrazuje, ale server běží. Můžete to ověřit zadáním do prohlížeče řádek http: // localhost: 1986 / wss / hello? Wsdl. Stránka, která se otevře, na jedné straně dokazuje, že na našem počítači (localhost) na portu 1986 byl spuštěn webový server (http: //), a na druhé straně ukazuje WSDL popis naší webové služby. Pokud aplikaci zastavíte, popis se stane nepřístupným, stejně jako samotná webová služba, takže to neuděláme, ale přistoupíme k psaní klienta.Zákazník
Ve složce projektu src vytvořte balíček ru.javarush.client a v něm třídu HelloWebServiceClient s hlavní metodou: package ru. javarush. klient; // potřeboval získat popis wsdl a přes něj // dosažení samotné webové služby importovat java. síť. URL; // k takovému spuštění dojde při práci s objektem URL importovat java. síť. MalformedURLException; // třídy pro analýzu xml-ku s popisem wsdl // a dostanete se na servisní značku v něm import javax. xml. jmenný prostor. QName; import javax. xml. ws. Servis; // rozhraní naší webové služby (potřebujeme další) import ru. javarush. ws. HelloWebService; veřejná třída HelloWebServiceClient (veřejná statická void main (argumenty řetězce) vyvolá výjimku MalformedURLException ( // vytvořit odkaz na popis wsdl Adresa URL= nová adresa URL ( "http: // localhost: 1986 / wss / ahoj? wsdl") ; // Na parametry dalšího konstruktoru se podíváme v úplně první značce popisu WSDL - definice // viz 1. argument v atributu targetNamespace // viz 2. argument v atributu name QName qname = nový QName ("http: //ws.site/", "HelloWebServiceImplService"); // Nyní můžeme dosáhnout servisní značky v popisu wsdl, Servisní služba= Služba. vytvořit (url, qname); // a pak až k vnořené značce portu, takže // získat odkaz na objekt webové služby vzdálený od nás HelloWebService hello = služba. getPort (třída HelloWebService); // Hurá! Nyní můžete zavolat vzdálenou metodu Systém. ven. println (ahoj. getHelloString ("CodeGym")); )) Maximálně jsem komentoval kód ve výpisu. Nemám co dodat, tak spusťte (Shift + F10). V konzoli bychom měli vidět text: Hello, CodeGym! Pokud jste to neviděli, pravděpodobně jste zapomněli spustit webovou službu.Závěr
V tomto tématu byl představen stručný exkurz do webových služeb. Opět platí, že mnoho z toho, co jsem napsal, jsou mé dohady, jak to funguje, a proto by se tomu nemělo příliš věřit. Byl bych vděčný, kdyby znalí lidé oni mě opraví, protože pak se něco naučím. UPD.Alexej Bojko
SOAP a XML webové služby na platformě .Net
Webové služby XML nabízejí tuto úroveň kompatibility a interoperability napříč operačními systémy,
platformy a jazyky, které dříve jednoduše nebyly dostupné.
Andrew Troelsen (MVP (nejhodnotnější profesionál v Microsoftu))
Pokud jste ještě nepracovali s webovými službami XML, pravděpodobně jste slyšeli slovo „SOAP“. Je čas se s těmito pojmy vypořádat.
Intro
Pokud se zajímáte o internet nebo menší sítě, je pravděpodobné, že dříve nebo později narazíte na webové služby XML. Webová služba XML není pouze webová aplikace, která může odesílat informace do prohlížeče. Jde spíše o technologii vzdálené komunikace, která umožňuje vyvolat metody a vlastnosti objektu přes síť pomocí standardních požadavků HTTP.
V praxi to znamená, že klienti takové služby mohou být napsáni v různých jazycích a pro různé operační systémy.
Jako informační "transport" mezi službou a klientem můžete použít metody HTTP GET nebo POST.
A můžete „překrýt“ ještě jeden protokol – SOAP (Simple Object Access Protocol). To se obvykle provádí, protože v tomto případě je možné předat složité typy (včetně uživatelsky definovaných). A klasické metody GET a POST podporují pouze seznamy, jednoduchá pole a řetězce.
Příklad SOAP Interop
Zpráva SOAP je dokument XML zabalený do těla požadavku HTTP.
Výpis 1. Struktura zprávy SOAP
Interakce mezi klientem a službou je následující:
- klient vytvoří požadavek SOAP a odešle ho službě;
- služba zapnuta vzdálený počítač provede proceduru a odešle odpověď SOAP.
Požadavek SOAP může například vypadat takto, volá metodu HelloWorld () vzdálené webové služby XML:
Výpis 2. Příklad požadavku SOAP
Metoda HelloWorld () podle očekávání vrací řetězec „Ahoj světe!“:
Výpis 3. Ukázka odpovědi SOAP
Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xsd = "http://www.w3.org/2001/XMLSchema">
Vytvoření webové služby XML v .NET 2.0
Můžete vytvořit službu různé způsoby, použijeme Visual Studio 2005. Klikněte na "Soubor -> Nový -> Webový server", v otevřeném okně vyberte "Webová služba ASP.NET". Na adrese uvedené při vytváření naleznete následující soubory a adresáře (viz obr. 1).
Služba může v zásadě obsahovat pouze jeden jediný soubor s příponou * .asmx. (Přípona * .asmx se používá k označení webových služeb .Net.) V tomto případě tomu tak není, podívejte se na obsah souboru Service.asmx:
Výpis 4. Service.asmx definuje externí soubor Podpěra, podpora
<%@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" class="Service" %>
Atribut CodeBehind určuje externí soubor umístěný ve složce App_Code, který obsahuje kód, který implementuje metodu HelloWorld ():
Výpis 5. Soubor Service.cs Implementace metody HelloWorld ().
pomocí systému;
pomocí System.Web;
pomocí System.Web.Services;
Veřejná služba () (
Návrat "Ahoj světe";
Je možné vytvořit jeden soubor Service.asmx bez kódu podpory, který má stejnou funkci:
Výpis 6. Service.asmx bez kódu externí podpory
<%@ WebService Language="C#" class="Service" %>
pomocí systému;
pomocí System.Web;
pomocí System.Web.Services;
pomocí System.Web.Services.Protocols;
služba veřejné třídy: System.Web.Services.WebService
Veřejná služba () (
Veřejný řetězec HelloWorld () (
Návrat "Ahoj světe";
To nepotřebujeme a nebudeme to dělat.
Jak můžete vidět, jediná metoda v naší webové službě je označena atributem, který informuje běhové prostředí ASP.NET, že tato metoda je dostupná pro příchozí požadavky HTTP. Členové, kteří nejsou označeni tímto atributem, nebudou klientským programům k dispozici.
Taková jednoduchá služba je pro naše experimenty docela vhodná, zbývá ji pouze publikovat.
Publikování webové služby XML pomocí IIS
Nemluvíme o publikování na internetu, ale o vytváření podmínek pro testování naší služby na lokálním počítači.
Prvním krokem je instalace IIS (Internet Information Server). Chcete-li to provést, otevřete okno „Přidat nebo odebrat programy“ a vyberte „Instalovat Komponenty Windows". (Nějaký Verze Windows nezahrnují instalaci IIS, jako je Windows XP Home Edition.)
Poznámka: server IIS je lepší nainstalovat dříve než .Net Framework, jinak budete muset nakonfigurovat IIS tak, aby podporovala aplikace .Net spuštěním nástroje příkazový řádek aspnet_regiis.exe (s příznakem /i).
Vytvořte virtuální adresář. Pokud používáte Windows XP Pro, přejděte na "Ovládací panely -> Nástroje pro správu -> Internetové informační služby". V okně, které se otevře, vyberte Akce -> Vytvořit -> Virtuální adresář.
Spustí se Průvodce vytvořením virtuálního adresáře. Alias Soap1 a zadejte cestu k adresáři, kam chcete službu umístit, například C: \ Soap1. Nyní tam zkopírujte obsah naší webové služby.
Do adresního řádku prohlížeče zadejte http: //localhost/soap1/Service.asmx a měla by se zobrazit stránka testování služby (viz obrázek 2).
Zobrazení zpráv SOAP
Testovací stránka neumožňuje odesílání a čtení zpráv SOAP. Z tohoto důvodu budete muset použít vývoj třetích stran, doporučuji použít soapUI. (Toto je bezplatný produkt dostupný na http://www.soapui.org.)
Po instalaci soapUI vytvořte nový projekt s názvem soap1 a ponechte pole Initial WSDL prázdné (viz obrázek 3).
Klikněte pravým tlačítkem na nově vytvořený projekt a vyberte "Přidat WSDL z URL". V dialogovém okně, které se otevře, zadejte http: //localhost/soap1/Service.asmx? Wsdl. Nyní máme možnost odesílat požadavky SOAP naší službě a prohlížet obdržené odpovědi. (Požadavky budou generovány systémem soapUI automaticky.)
Co je to WSDL? Dokument WSDL popisuje, jak klienti komunikují s webovou službou. Popisuje, jaké servisní metody jsou dostupné pro externí vyvolání, jaké parametry přijímají a co vracejí, stejně jako další informace potřebné pro vzdálenou komunikaci. Takový dokument lze zkompilovat ručně, nebo můžete jeho vygenerováním svěřit serveru, k tomu stačí přidat příponu? Wsdl k URL odkazující na soubor * .asmx.
Chcete-li zobrazit dokument WSDL pro naši službu, zadejte do prohlížeče http: //localhost/soap1/Service.asmx? Wsdl. Informace z tohoto dokumentu používá soapUI k automatickému generování požadavků SOAP.
Rozšíření SOAP
Jak jste si možná všimli, vytvoření webové služby XML (stejně jako klienta) se nemusí zabývat vzhledem zpráv SOAP. Požadované metody stačí označit atributem a runtime ASP.NET vygeneruje balíčky požadovaného formátu.
Na Obr. 4 ukazuje požadavek a odpověď webové služby přijaté pomocí programu soapUI.
Udělejme to ještě jednou. Požadavek je generován soapUI – při vytváření skutečných klientů pro službu také nemusíte ručně formátovat pakety SOAP. Také jsme se přímo nepodíleli na tvorbě odpovědi služby. To vše se děje automaticky.
Je však pravděpodobné, že tyto balíčky budete muset upravit sami. Například komprimovat nebo šifrovat přenášená data. To je účelem SOAP Extensions.
Rozšíření SOAP je mechanismus, který vám umožňuje libovolně upravovat zprávy SOAP, které odesíláte a přijímáte.
SOAP zpráva "cesta"
Chcete-li začít s programováním, musíte zvážit cestu, kterou zpráva SOAP prochází, než je přijata a zpracována příslušnou metodou (viz obrázek 5).
Zprávu SOAP si lze představit jako dokument XML popisující objekt přenášený sítí. Před použitím takto předaný předmět je nutné jej zrestaurovat (nebo chcete-li sestavit) z tohoto popisu. K tomuto účelu slouží XML serializátor.
Příchozí pakety jsou deserializovány (obnovení objektu z popisu XML) a odeslané pakety jsou serializovány (vytvoření XML popisu objektu).
Na Obr. 5 ukazuje čtyři body (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), ve kterých můžeme zachytit SOAP zprávu pomocí SOAP Extensions. Upravte jej a odešlete dále.
Implementace rozšíření SOAP
Pro začátek si definujme úkol: řekněme, že chceme upravit pakety SOAP odesílané webovou službou, jak je znázorněno ve výpisu 7:
Výpis 7. Staré a nové odpovědi webové služby XML
Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xsd = "http://www.w3.org/2001/XMLSchema">
Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xsd = "http://www.w3.org/2001/XMLSchema"> Šifrovaný text
Akční plán pro implementaci rozšíření SOAP:
- Vytvořte dll s třídou zděděnou z SoapExtension.
- Přidejte složku bin do naší webové služby a vložte tam vytvořenou dll.
- Přidejte do služby soubor web.config a proveďte v něm potřebné změny.
Roli složky bin a souboru web.config probereme později.
Vytváření DLL s rozšířením SOAP
Vytvořte nový projekt "Knihovna tříd" s názvem SoapExtensionLib. V tomto projektu potřebujeme implementovat pouze jednu třídu, která bude provádět potřebné úpravy balíčků SOAP. Tato třída musí dědit ze třídy SoapExtension.
Výpis 8. Vytvoření třídy dědící z SoapExtension
pomocí systému;
pomocí System.Web.Services;
pomocí System.Web.Services.Protocols;
pomocí System.IO;
pomocí System.Net;
pomocí System.Xml;
Každé rozšíření SOAP přijímá jako parametr proud obsahující objekt, který má být předán sítí (před nebo po serializaci). A musí vrátit proud.
Rozšíření SOAP si lze představit jako „krabici“, kterou lze umístit na jeden nebo všechny ze čtyř bodů (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize) zobrazených na Obr. 5. V každém bodě může být takových "vložek" libovolný počet (viz obr. 6).
Pro příjem těchto streamů se používá metoda ChainStream.
Výpis 9. Implementace metody ChainStream
public class TraceExtension: SoapExtension
Stream wireStream;
Stream appStream;
// metoda jako vstupní parametr
// získá proud obsahující předaný objekt
Veřejné přepsání Stream ChainStream (streamový stream)
WireStream = stream;
AppStream = new MemoryStream ();
Návrat appStream;
…
Při BeforeDeserialize obsahuje wireStream přijatý požadavek SOAP ze sítě. Tento požadavek SOAP musí být předán aplikačnímu streamu (appStream).
A v bodě AfterSerialize musíte odeslat odpověď SOAP odeslanou do sítě do wireStreamu, který bude umístěn do appStreamu.
Chcete-li pracovat s vlákny v každém ze čtyř bodů, musíte implementovat metodu ProcessMessage.
Výpis 10. Implementace metody ProcessMessage, která nemodifikuje zprávy SOAP
// ProcessMessage provádí povinnou kopii
// streamy ve dvou bodech (BeforeDeserialize a AfterSerialize)
Switch (message.Stage)
// v bodě BeforeDeserialize musíte projít
// požadavek SOAP ze síťového streamu (wireStream)
// do aplikačního streamu (appStream)
Případ SoapMessageStage.BeforeDeserialize:
Kopírovat (wireStream, appStream);
AppStream.Position = 0;
Přestávka;
// v bodě AfterSerialize musí být předán
// Odezva SOAP z aplikačního toku do síťového toku
AppStream.Position = 0;
Přestávka;
void Kopírovat (streamovat z, streamovat do)
Čtečka TextReader = new StreamReader (od);
TextWriter Writer = nový StreamWriter (do);
Writer.WriteLine (reader.ReadToEnd ());
Spisovatel.Flush ();
Seznam 10 považujte za prázdné místo pro další experimentování. Tato implementace metody ProcessMessage nedává žádný smysl - odchozí odpověď SOAP není nijak upravována. Pojďme to opravit:
Výpis 11. Implementace metody ProcessMessage pro úpravu odezvy SOAP
veřejné přepsání void ProcessMessage (zpráva SoapMessage)
Switch (message.Stage)
Případ SoapMessageStage.AfterSerialize:
WriteOutput (zpráva);
Přestávka;
// část kódu byla vyříznuta, aby se ušetřilo místo
// přepsat odpověď SOAP
public void WriteOutput (zpráva SoapMessage)
AppStream.Position = 0;
// vytvoření XML dokumentu ze streamu
XmlDocument document = new XmlDocument ();
Document.Load (appStream);
// Chcete-li použít XPath, musíte definovat
// NamespaceManager
XmlNamespaceManager nsmgr = nový XmlNamespaceManager (document.NameTable);
Nsmgr.AddNamespace ("mýdlo", "http://schemas.xmlsoap.org/soap/envelope/");
XmlNode ResultNode = document.SelectSingleNode ("// soap: Body", nsmgr);
// nahradí obsah uzlu
ResultNode.InnerText = "ciphertext";
// vyčistit stream a napsat na něj novou odpověď SOAP
AppStream.SetLength (0);
AppStream.Position = 0;
Document.Save (appStream);
// POVINNÁ AKCE
// předání odpovědi SOAP z aplikačního streamu (appStream)
// do síťového streamu (wireStream)
AppStream.Position = 0;
Kopírovat (appStream, wireStream);
Dále je třeba definovat dvě metody (jedna z nich je přetížená, to znamená, že ji lze volat s různými sadami parametrů), které v našem případě nejsou potřeba. Musíme je však definovat v souladu s pravidly dědičnosti ze třídy SoapExtension.
Výpis 12. Další požadované metody
// V souladu s pravidly dědičnosti musíme
// definujeme tyto metody, ale nijak je nepoužíváme
objekt veřejného přepisu?
GetInitializer (LogicalMethodInfo methodInfo, atribut SoapExtensionAttribute)
Return null;
veřejný objekt přepsání GetInitializer (typ WebServiceType)
Return null;
public override void Inicializovat (inicializátor objektu)
Vrátit se;
To je vše, sestavujeme projekt. Nakonec jsme dostali dll s rozšířením SOAP. Kompletní výpis SoapExtensionLib.dll lze nalézt na webu časopisu v sekci "Zdrojový kód".
Konfigurace webové služby pro práci s rozšířením SOAP
Otevřete znovu náš projekt webové služby XML pomocí sady Visual Studio. Klikněte na "Web -> Přidat odkaz" a vyberte SoapExtensionLib.dll, který jste vytvořili dříve.
Složka Bin bude automaticky přidána do projektu. Aplikace automaticky odkazuje na soubory *.dll umístěné ve složce Bin.
Nyní vložte následující obsah do souboru Web.Config v adresáři webové služby:
Výpis 13. Soubor Web.Config
Priorita = "1" Skupina = "0" />
Nyní struktura naší služby vypadá jako na obr. 7. Soubor Web.Config používáme k informování ASP.NET, že jsme do webové služby přidali rozšíření XML Soap, implementované ve třídě TraceExtension umístěné v souboru SoapExtensionLi.dll. Výpis 14. Sekce webServices v souboru Web.Config Priorita = "1" Skupina = "0" />
Jak již víte, lze vytvořit mnoho rozšíření SOAP a proud přenášející předávaný objekt (před nebo po serializaci) bude procházet každým z nich. Pořadí, ve kterém proud proudí přes různá rozšíření SOAP, je určeno pomocí atributů priority a skupiny. Za zmínku stojí, že konfigurací Web.Config tímto způsobem informujeme okolí, že pro každou metodu služby označené atributem bude voláno naše SOAP Extension. Je možné vytvořit si vlastní atribut a označit jím pouze ty metody, pro které potřebujete volat SOAP Extension. Výpis 15. Příklad použití vlastního atributu veřejný řetězec HelloWorld () ( Návrat "Ahoj světe"; Chcete-li to provést, přidejte třídu zděděnou z SoapExtensionAttribute do SoapExtensionLi.dll (viz obrázek 8). Závěr Tento článek odráží hlavní body konstrukce a provozu webových služeb XML na platformě .Net. Doufám, že prezentovaného materiálu bude dostačující k tomu, abyste se v případě potřeby mohli věnovat hlubšímu studiu tématu. V kontaktu s
