Az internet fejlődésével szükség volt elosztott alkalmazások létrehozására. A számítógépre telepített alkalmazások általában a rajta található könyvtárakat használják. Egy könyvtárat több program is használhat. Feltehetők-e könyvtáranalógok az internetre, hogy a különböző oldalak felhívhassák őket? Kiderült, igen.

A vállalkozások sokféle információt kínálnak oldalaikon. A Ford például a http://www.Ford.com weboldalán tesz közzé információkat a modellekről és az árakról. Ennek a cégnek a kereskedője szeretné, ha ezt az információt a honlapján közzétennék. A webszolgáltatás lehetővé teszi a fogyasztói oldal számára, hogy információkat kérjen le a szolgáltató webhelyéről. A fogyasztói oldal ezt az információt az oldalain jeleníti meg. Az információ generálására szolgáló kódot egyszer írják le, de sok fogyasztó használhatja. Az adatok egyszerű szövegben jelennek meg, így platformtól függetlenül használhatók.

A webszolgáltatásokat széles körben használják asztali és internetes alkalmazásokban egyaránt. Ezek nem maguk az alkalmazások, hanem az alkalmazások adatforrásai. Hiányoznak felhasználói felület... A webszolgáltatásokat nem szükséges a hálózaton keresztül használni – ezek részei lehetnek annak a projektnek, amelyben használják őket.

A webszolgáltatások olyan külső alkalmazások által biztosított funkcionalitás és adatok, amelyek szabványos protokollokat és adatformátumokat használnak a szolgáltatásokkal együttműködve. A webszolgáltatások teljesen nyelv- és platformfüggetlenek. A webszolgáltatási technológia a Microsoft programozási modelljének sarokköve. HÁLÓ.

azt további fejlődés komponens programozás CORBA és DCOM. Az ilyen komponensek használatához azonban regisztrálni kell azokat a fogyasztó rendszerében. Ez nem szükséges a webszolgáltatásokhoz. Az összetevők jól működnek a helyi hálózatokon. A HTTP nem távoli eljáráshívás (RPC) protokoll. Még ugyanazon a szervezeten belül is, másként OS amelyek csak HTTP-n keresztül tudnak kommunikálni.

Több próbálkozás is történt heterogén rendszerek - DCOM, CORBA, RMI, IIOP - közötti kommunikációs nyelv létrehozására. Nem kaptak általános forgalmazást, mivel mindegyiket más-más gyártó reklámozta, és ezért egy adott gyártó technológiáihoz kötötték. Senki sem akarta elfogadni valaki más mércéjét. Ennek a dilemmának a megoldására több vállalat megállapodott abban, hogy gyártósemleges szabványt dolgoznak ki a HTTP-n keresztüli üzenetküldéshez. 2000 májusában az IBM, a Microsoft, a HP, a Lotus, az SAP, a UserLand és mások megkeresték a W3C-t, és a SOAP-ot javasolták egy ilyen szabvány jelöltjeként. A SOAP forradalmasította az alkalmazásfejlesztést két internetes szabvány, a HTTP és az XML egyesítésével.

SZAPPAN

A webszolgáltatásokkal való interakcióhoz az XML-alapú SOAP protokollt használják. Használhat csak XML-t, de ez túl laza formátum, amelyben minden dokumentum létrehozza a saját nyelvét. SZAPPAN egy konvenció az XML-dokumentum formátumáról, bizonyos elemek és névterek jelenlétéről.

A SOAP lehetővé teszi összetett adatstruktúrák, például DataSet közzétételét és felhasználását. Ugyanakkor könnyű megtanulni. Jelenlegi verzió SZAPPAN - 1.2.

A SOAP a Simple Object Access Protocol rövidítése. A SOAP célja, hogy megkönnyítse az alkalmazások HTTP-n keresztüli kommunikációját. Ez egy speciális platformfüggetlen üzenetküldési formátum az interneten keresztül. A SOAP üzenet egy szokásos XML-dokumentum. Alapértelmezett

Lírai rész.

Képzelje el, hogy egy bizonyos rendszert implementált vagy valósít meg, amelynek kívülről elérhetőnek kell lennie. Azok. van egy bizonyos szerver, amellyel kommunikálni kell. Például egy webszerver.

Ez a szerver számos műveletet végrehajthat, dolgozhat az adatbázissal, harmadik féltől származó kéréseket hajthat végre más szerverek felé, valamilyen számítást végezhet stb. az ő jól ismert forgatókönyve szerint (azaz a fejlesztők forgatókönyve szerint) éljen és esetleg fejlődjön. Az embert nem érdekli egy ilyen szerverrel kommunikálni, mert nem biztos, hogy tud/ akar szép oldalakat adni képekkel és egyéb felhasználóbarát tartalommal. Úgy van megírva és működik, hogy működjön és adatokat adjon ki a kéréseknek, anélkül, hogy törődne azzal, hogy azok ember által olvashatóak legyenek, az ügyfél maga fogja kezelni őket.

Más rendszerek erre a szerverre hivatkozva már saját belátásuk szerint rendelkezhetnek az erről a szerverről kapott adatokkal - feldolgozhatják, felhalmozhatják, kiadhatják ügyfeleiknek stb.

Nos, az ilyen szerverekkel való kommunikáció egyik lehetősége a SOAP. SOAP xml üzenetcsere protokoll.

A gyakorlati rész.

Egy webszolgáltatás (ez az, amit a szerver nyújt, és amit a kliensek használnak) lehetővé teszi a szerverrel való kommunikációt világosan strukturált üzenetekben. A helyzet az, hogy a webszolgáltatás nem fogad el semmilyen adatot. A szabályoknak nem megfelelő üzenetekre a webszolgáltatás hibával válaszol. A hiba egyébként szintén áttekinthető szerkezetű xml formájában lesz (ami az üzenet szövegére nem igaz).

WSDL (Web Services Description Language). A webszolgáltatás üzeneteinek összeállításának szabályai a következővel azonos módon vannak leírva xml használatávalés világos felépítésük is van. Azok. ha egy webszolgáltatás lehetőséget biztosít egy metódus meghívására, akkor tudatnia kell az ügyfelekkel, hogy milyen paramétereket használnak ehhez a metódushoz. Ha a webszolgáltatás a Method1 metódushoz karakterláncot vár paraméterként, és a karakterláncnak Param1 névvel kell rendelkeznie, akkor ezek a szabályok a webszolgáltatás leírásában lesznek megadva.

Paraméterként nem csak egyszerű típusok adhatók át, hanem objektumok, objektumgyűjtemények is. Az objektum leírása az objektum egyes összetevőinek leírására redukálódik. Ha az objektum több mezőből áll, akkor minden mezőben le van írva, hogy milyen típusú, név (milyen lehetséges értékek). A mezők lehetnek összetett típusúak is, és így tovább, amíg a típusok leírása nem végződik egyszerűekkel - karakterlánc, logikai érték, szám, dátum... Néhány konkrét típus azonban egyszerűnek bizonyulhat, fontos, hogy az ügyfelek megérteni, milyen értékeket tartalmazhatnak.

Az ügyfelek számára elegendő a webszolgáltatás url-jének ismerete, a wsdl mindig ott lesz, amivel képet kaphat a webszolgáltatás által biztosított módszerekről és azok paramétereiről.

Milyen előnyei vannak ezeknek a harangoknak és sípoknak:

• A legtöbb rendszerben a módszerek és típusok leírása a automatikus üzemmód... Azok. elég, ha a szerveren lévő programozó azt mondja ez a módszer webszolgáltatáson keresztül hívható meg, és a wsdl leírása automatikusan létrejön.

A jól felépített leírást bármely szappanügyfél elolvashatja. Azok. Bármi is legyen a webszolgáltatás, az ügyfél megérti, hogy a webszolgáltatás milyen adatokat fogad el. E leírás szerint a kliens saját objektumosztályokból felépítheti belső struktúráját, az ún. kötés "és. Ennek eredményeként a webszolgáltatást használó programozónak valami ilyesmit kell írnia (pszeudokód):

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

• Automatikus érvényesítés.

  • xml érvényesítés. xml-nek jól formázottnak kell lennie. érvénytelen xml - azonnal hiba az ügyfélnek, hadd találja ki.
  • séma érvényesítése. Az xml-nek meghatározott szerkezettel kell rendelkeznie. xml nem felel meg a sémának - azonnal hiba az ügyfélnek, hadd értse meg.
  • Az adatellenőrzést a szappanszerver végzi úgy, hogy az adattípusok, korlátozások megfeleljenek a leírásnak.
• Az engedélyezés és hitelesítés megvalósítható külön módszer... natívan. vagy http jogosultság használatával.
• A webszolgáltatások a szappan protokollon és a http-n keresztül is működhetnek, azaz get kéréseken keresztül. Azaz, ha a paraméterek egyszerű adatok (nincs struktúra), akkor egyszerűen hívhatja a szokásos get www.site.com/users.asmx/GetUser?Name=Vasia vagy post. Ez azonban nem mindenhol és nem mindig.
• ... lásd a wikipédiát

Sok hátránya is van:

• Indokolatlanul nagy üzenetméret. Nos, itt az xml lényege olyan, hogy a formátum redundáns, minél több címke, annál több haszontalan információ. Plusz szappan hozzáadja a redundanciát. Az intranetes rendszerek esetében a forgalmi probléma kevésbé akut, mint az internet esetében helyi hálózatok nagyobb a kereslet, különösen a Sharepoint rendelkezik egy szappan webszolgáltatással, amellyel sikeresen kommunikálhat (és bizonyos korlátozásokkal).
• Egy webszolgáltatás leírásának automatikus módosítása minden ügyfelet megszakíthat. Nos, ez olyan, mint minden rendszernél, ha a régi módszerekkel való visszafelé kompatibilitás nem támogatott, akkor minden leesik ...
• Nem mínusz, hanem hátrány. A metódusok hívásához szükséges összes műveletnek atomi jellegűnek kell lennie. Például egy felosztással dolgozva elindíthatunk egy tranzakciót, végrehajthatunk több kérést, majd visszaállíthatjuk vagy véglegesíthetjük. Nincsenek tranzakciók szappannal. Egy kérés, egy válasz, a beszélgetésnek vége.
• Elég nehéz lehet megérteni a leírást, hogy mi van a szerver oldalon (mindent jól írtam le?), Mi van a kliensen (mit írtak nekem ide?). Többször előfordult, hogy a kliens oldallal kellett megküzdenem, és meggyőzni a szerver programozót, hogy az adatai rosszul vannak leírva, és egyáltalán nem értett semmit, mert az automatikus generálásnak és neki nem szabadna, ez az szoftver üzlet. A hiba pedig természetesen a metódus kódjában volt, a programozó nem látta egyszerűen.
• A gyakorlat azt mutatja, hogy a webszolgáltatások fejlesztői rettenetesen távol állnak az ezeket a webszolgáltatásokat használó emberektől. Bármilyen (kívülről érvényes) kérésre válaszolva egy érthetetlen hibaüzenet érkezhet: "Error 5. Everything is bad". Minden a fejlesztők lelkiismeretén múlik :)
• Valószínűleg még mindig nem emlékeztem valamire...

Példaként van egy belavia nyílt webszolgáltatás:

• http://86.57.245.235/TimeTable/Service.asmx - belépési pont, szöveges leírás is található a módszerekről a külső fejlesztők számára.
• http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl a fogadott és visszaküldött adatok módszereinek és típusainak leírása.
• http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList – egy adott metódus leírása egy xml-kérés és egy xml-válasz példájával.

Manuálisan létrehozhat és elküldhet kérelmet, például:

POST /TimeTable/Service.asmx HTTP / 1.1 Host: 86.57.245.235 Tartalomtípus: szöveg / xml; charset = utf-8 Content-Length: long SOAPAction: "http://webservices.belavia.by/GetAirportsList" ru

jön a válasz:

HTTP / 1.1 200 OK Dátum: H, 30 Sep 2013 00:06:44 GMT Szerver: Microsoft-IIS / 6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: privát, max. -age = 0 Tartalom típusa: szöveg / xml; karakterkészlet = utf-8 Tartalomhossz: 2940

Shl Korábban megnyílt az Aeroflot webszolgáltatás, de miután az 1C hozzáadta a szappan támogatását a 8k-hoz, egy csomó 1c bétatesztelő sikeresen letette. Most ott változott valami (nem tudom a címeket, kereshetsz, ha érdekel).
ZZY Jogi nyilatkozat. Háztartási szinten elmondta. Tudsz rúgni.

Jogi nyilatkozat:Sok cikk született már ebben a témában, és ahogyan természetesen sejtitek, ez egy másik. Talán tanulsz belőle valami újat, de itt nincs leírva semmi olyan szupertitkos dolog, amit ne tudtál volna google-ba keresni. Csak személyes tapasztalatból származó megjegyzések.

Bevezetés

Csak akkor vesszük figyelembe azt a helyzetet, amikor van harmadik féltől származó webszolgáltatás, és a feladat az adatcsere létrehozása.

A szolgáltatás felépítését a fájl írja le WSDL(A webszolgáltatások angol nyelve)

A fájl leggyakrabban arról a hivatkozásról érhető el, ahol a webszolgáltatás belépési pontja található. A "leggyakrabban" írtam, mert vannak kivételek. Például egy SAP-alapú webszolgáltatás nem teszi közzé a wsdl-t, és csak az alkalmazásból való eltávolításával érhető el.

És így van a webszolgáltatás leírása, bejelentkezési név, jelszó. Kapcsolódjunk.

// Adja meg az URLServiceNameSpace beállításokat = "http://Somesite.ru"; UserName = "TestUser"; Jelszó = "q1w2e3"; LocationWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "SomeServiceName"; ConnectionPointName = "SomeService_Port"; // SSL kapcsolat létrehozása = New SecureConnection OpenSSL (); WSDefinition = Új WSDdefiníció (LocationWSDL, SSL); WSProxy = Új WSProxy (WSDdefiníció, ServiceNameSpace URL, ServiceName, ConnectionPointName, SSL); WSProxy.User = Felhasználónév; WSProxy.Password = Jelszó;

Bírság! Csatlakoztunk a webszolgáltatáshoz! Elméletileg ez minden csereopció alapja, mivel lehetővé teszi a létrehozást adatstruktúra objektum wsdl alapján, és egy ilyen objektummal öröm dolgozni.

Tekintsük a SoapUI által adott XML-t

357 121212 M 19900111 Mercedes GLS Audi TT

Most írjuk le programszerűen

// Hozzon létre egy objektumot és töltse fel adatokkal XDTOFactory = WSDefinition.XDTOFactory; RootType = CustomXDTOFactory.Type (ServiceNameSpace URL, "BENYÚJTÁS"); RootObject = MyXDTOFactory.Create (RootType); RootObject.ID = "4356"; ClientType = CustomXDTOFactory.Type (ServiceNameSpace URL, "CUSTOMER"); ClientObject = OwnXDTOFactory.Create (ClientType); ClientObject.CLIENT_ID = "121212"; ClientObject.SEX = "M"; // F - nő, M - férfi ClientObject.CLIENT_BIRTHDAY = "19900111"; // Kliens autók 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);

Az adatok kitöltése sikeresen megtörtént. Most el kell küldenie őket.

Ebben a pillanatban sok árnyalat merül fel. Próbáljuk meg mindegyiket mérlegelni.

1. recept. A teljes XDTO objektum elküldése

Eredmény = WSProxy.AddCustomers (RootObject);

Már csak az eredményt kell feldolgozni, hogy a szolgáltatás visszatért hozzánk, és ennyi. Elfogadom, hogy ez nagyon kényelmes!

De a gyakorlatban ez nem mindig van így. Például az 1c nem boldogul bizonyos címkék előtagozásával az xml-ben, ha a gyökércímke névtere eltér a gyermekekétől. Ilyen esetekben kézzel kell összegyűjteni a szappant. Olyan webszolgáltatásokkal is kellett foglalkoznom, amelyek paraméterként tiszta xml-re várnak. Őrültség, de mégsem túl nehéz megcsinálni.

2. recept: tiszta xml küldése paraméterként

XMLWriteParameters = Új XMLWriteParameters ("UTF-8", "1.0", igaz); MyXML = Új XML rekord; MyXML.SetString (XMLWriter Options); MyXML.WriteXMLDeclaration (); MyXDTOFactory.WriteXML (MyXML, RootObject); XML String = MyXML.Bezárás (); If DeleteNamespaceDescription Then Attempt FirstTagVSrow = StrGetString (XMLString, 2); RootTagName = RootObject.Type (). Név; XMLString = StringReplace (XMLString, FirstTagVS karakterlánc, "<"+ИмяКорневогоТэга+">"); Kivétel // DescriptionErrors () EndTry; EndIf; Eredmény = WSProxy.AddCustomers (String XML);

Ha nem távolítja el az 1c által alapértelmezés szerint hozzáadott névteret, akkor az több mint 5 kódsorból áll. Leggyakrabban az xml konverziót egy függvénybe csomagolom, mivel általában több metódust is meghívok.

3. recept. Natív HTTP-kérés küldése.

StringSOAP = " | | "+ XML karakterlánc +" | |"; // Ismertesse a HTTP-kérés fejléceit Headers = New Match; Headers.Insert (" Content-Type "," text / xml; charset = UTF-8 "); Headers.Insert (" SOAPAction "," http: // sap.com/xi/WebService/soap1.1 "); Headers.Insert (" Authorization "," Basic "+ GetBase64AuthorizationHeader (Felhasználónév, Jelszó)); // FIGYELEM !!! // Nem töltheti ki programozottan a következő fejléceket, mert ez hibához vezet // A platform helyesen fogja kitölteni őket // Fejlécek. Insert ЧГ = ")); // üzenet hossza // Fejlécek. Beszúrás ("Host", "Somesite.ru:8001" ); // Headers. Insert ("Kapcsolat "," Keep-Alive "); // Fejlécek. Beszúrás ("User-Agent", "Apache-HttpClient / 4.1.1 (java 1.5)"); // Csatlakozás Connection = New HTTPConnection ("Somesite.ru/WebService/Some", Felhasználónév, Jelszó, SSL, False); // A címnek https nélkül kell lennie: // // A gyökéroldal szövegének lekérése POST-on keresztül HTTP-kérés c = Új HTTP-kérés ("/ GetCustomer", fejlécek); HTTPRequest.SetBodyFromString (StringSOAP); Eredmény = Connection.CallHTTPMethod ("POST", HTTPRequest);

Ebben az esetben a szappant kézzel kell összegyűjtenünk. Valójában a 2. recept xml-jét csak egy szappanhéjba csomagoljuk, ahol a webszolgáltatás követelményeitől függően tetszés szerint cserélhetjük a szappanunkat.

Ezután a fejléceket ismertetjük a dokumentáció szerint. Egyes szolgáltatások nyugodtan megrágják a kérésünket fejlécek nélkül, itt egy konkrét esetet kell nézni. Ha nem tudja, milyen fejléceket írjon, akkor a legegyszerűbb módja, ha a SoapUI-ban kémkedik a kérés után a RAW lapra váltva.

A Base64 karakterlánc lekérésének függvénye így néz ki (kémkedett):

Funkció GetBase64AuthorizationHeader (felhasználónév, jelszó) Fájlkódolás = Szövegkódolás.UTF8; TemporaryFile = GetTemporaryFileName (); Record = Új szöveges rekord (TemporaryFile, FileCode); Record.Record (Felhasználónév + ":" + Jelszó); Felvétel.Bezárás (); DWData = Új bináris adat (TemporaryFile); Eredmény = Base64String (DWData); DeleteFiles (TemporaryFile); Eredmény = Átlag (Eredmény, 5); Visszatérítési eredmény; EndFunction

Van egy fontos szempont. A HTTPConnection használatakor adja meg a címet a "http: //" és a "https: //" protokollok megadása nélkül, ellenkező esetben fennáll a veszélye, hogy időt veszít egy nyilvánvaló hiba keresésére.

4. recept. Küldés WinHttpRequest-en keresztül

WinHttp = Új COMObject ("WinHttp.WinHttpRequest.5.1"); WinHttp.Option (2, "UTF-8"); WinHttp.Option (4, 13056); // intSslErrorIgnoreFlag WinHttp.Option (6, igaz); // blnEnableRedirects WinHttp.Option (12, igaz); // blnEnableHttpsToHttpRedirects WinHttp.Open ("POST", "https://Somesite.ru/WebService/Some/GetCustomer", 0); WinHttp.SetRequestHeader ("Content-type", "text / xml"); WinHttp.SetCredentials (felhasználónév, jelszó, 0); WinHttp.Send (String SOAP); WinHttp.WaitForResponse (15); XMLResponse = WinHttp.ResponseText ();

Itt lényegében ugyanaz, mint az előző verzióban, de COM objektummal dolgozunk. A kapcsolati karakterláncot teljes egészében feltüntetjük, a protokollal együtt. Különös figyelmet kell fordítani az SSL-tanúsítványhiba-jelzők figyelmen kívül hagyására. Szükség van rájuk, ha SSL-en dolgozunk, de külön tanúsítvány nélkül, mivel ebben a verzióban nem lehet új biztonságos kapcsolatot létrehozni (vagy nem tudom, hogyan). A mechanizmus többi része hasonló az előzőhöz.

A "WinHttp.WinHttpRequest.5.1" mellett használhatja a "Microsoft.XMLHTTP", "Msxml2.XMLHTTP", "Msxml2.XMLHTTP.3.0", "Msxml2.XMLHTTP.6.0" fájlokat is, ha hirtelen nem veszi igénybe. kikapcsolva a WinHttp-n. A módszerek szinte azonosak, csak a paraméterek száma különbözik. Gyanítom, hogy ezen opciók egyike az 1c HTTPRequest objektumban van kódolva.

Jelenleg ezek a receptjeim vannak. Ha újakkal találkozom, mindenképpen kiegészítem a cikket.

Az eredmény feldolgozása

Az 1. receptben leggyakrabban egy kész XDTO objektumot kapunk, és úgy dolgozunk vele, mint egy szerkezettel. Minden más esetben az xml választ XDTO-vá alakíthatja

Ha Result.StatusCode = 200 Akkor XML Read = Új XML olvasás; ReadXML.SetString (Result.GetBodyAsString ()); ObjectResponse = OwnXDTOFactory.ReadXML (ReadXML); Jelentés (ObjectResponse.Body.Response.RESPONSE_ID); Jelentés (ObjectResponse.Body.Response.RESPONSE_TEXT); EndIf;

Itt minden egyszerű.

Konklúzió helyett

1. Kezdje el a webszolgáltatások használatát a SoapUI programmal. Ilyen munkára tervezték, és lehetővé teszi, hogy gyorsan megértse egy adott szolgáltatás működését. Van egy cikk a masteringhez

2. Ha egy nem biztonságos http csatornán keresztül vált a szolgáltatással, és felmerül a kérdés, hogy pontosan mit küld az 1c az üzeneteiben, akkor használhat olyan forgalomszimulálókat, mint a Wireshark, Fiddler és mások. A probléma csak akkor jelentkezik, ha ssl kapcsolatot használ.

3. Ha ennek ellenére a webszolgáltatás https-en keresztül kommunikál, akkor a távoli gépre (bármelyik, a lényeg nem saját magunk) feltesszük az Nginx szervert, amelyre felvesszük a kapcsolatot, ő pedig csomagolja mindent https-ben, és küldje el, ahol szükséges ( fordított proxy ) és adja hozzá a szabványos konfigurációhoz:

Szerver (meghallgat 0.0.0.0:8080; szerver_neve MyServer; hely ~. * (Proxy_pass https://Somesite.ru:8001; proxy_set_header Host $ host; proxy_set_header Engedélyezés "Basic "; proxy_pass_header engedélyezése;))

5. Ha a hitelesítés cookie-k használatával jár, akkor a következőt találtuk

P.S. Ha kérdései vannak, javaslatai vannak a kód javítására, saját receptjei vannak, amelyek eltérnek a leírtaktól, hibákat talált, vagy úgy gondolja, hogy a szerző "cuki" és "nincs helye az 1c-ben", akkor írjon megjegyzéseket, és mi mindent megbeszél.

A téma címe valóban kérdés, hiszen Én magam nem tudom, mi ez, és most először próbálok meg vele dolgozni a cikk keretein belül. Az egyetlen dolog, amit garantálhatok, hogy az alábbi kód működni fog, de a mondataim csak feltételezések és találgatások lesznek arról, hogy én magam hogyan értem mindezt. Akkor gyerünk ...

Bevezetés

Kezdjük azzal, hogy mire jött létre a webszolgáltatás fogalma. Amikor ez a koncepció megjelent, már léteztek olyan technológiák a világon, amelyek lehetővé tették az alkalmazások távoli interakcióját, ahol az egyik program egy másik programban meghívott valamilyen metódust, amelyet egy másik városban vagy akár egy országban található számítógépen futtathattak. Mindezt RPC-nek (Remote Procedure Calling) rövidítjük. Ilyenek például a CORBA technológiák és a Java esetében az RMI (Remote Method Invoking). És úgy tűnik, minden jó bennük, különösen a CORBA, tk. bármilyen programozási nyelven lehet vele dolgozni, de valami mégis hiányzott. Úgy gondolom, hogy a CORBA hátránya, hogy a sajátján keresztül működik hálózati protokollok az egyszerű HTTP helyett, amely minden tűzfalon áthalad. A webszolgáltatás mögött az volt az ötlet, hogy olyan RPC-t hozzunk létre, amely beleragad a HTTP-csomagokba. Így kezdődött a szabvány kidolgozása. Melyek a szabvány alapfogalmai:

1. SZAPPAN... Távoli eljárás hívása előtt le kell írnia ezt a hívást XML fájl e SOAP formátumú. A SOAP egyszerűen egy a webszolgáltatásokban használt XML-jelölések közül. Minden, amit HTTP-n keresztül el akarunk küldeni valahova, először XML SOAP leírássá alakítjuk, majd HTTP csomagba helyezzük, és TCP / IP-n keresztül elküldjük a hálózat másik számítógépére.
2. WSDL... Van egy webszolgáltatás pl. olyan program, amelynek metódusai távolról hívhatók. De a szabvány előírja, hogy ehhez a programhoz csatolni kell egy leírást, ami azt írja, hogy "igen, nem tévedsz - ez tényleg egy webszolgáltatás, és lehet belőle ilyen-olyan metódusokat hívni." Ezt a leírást egy másik XML-fájl képviseli, amelynek más formátuma van, nevezetesen a WSDL. Azok. A WSDL csak egy XML-leíró fájl egy webszolgáltatáshoz, és semmi más.

Miért kérdezed ilyen röviden? És részletesebben ez lehetetlen? Valószínűleg megteheti, de ehhez olyan könyvekhez kell fordulnia, mint a Mashnin T. "Java Web Services". Ott megy az első 200 oldal Részletes leírás a SOAP és WSDL szabványok minden egyes címkéjét. meg kell tennem? Véleményem szerint nem, tk. mindez automatikusan létrejön a Java-ban, és csak a távolról meghívandó metódusok tartalmát kell megírni. Tehát a Java-ban megjelent egy API, például a JAX-RPC. Ha valaki nem tudja, ha azt mondják, hogy a Java-nak van ilyen-olyan API-ja, az azt jelenti, hogy van egy csomag egy osztálykészlettel, amely beágyazza a kérdéses technológiát. A JAX-RPC hosszú ideig változatról verzióra fejlődött, és végül JAX-WS-vé fejlődött. A WS nyilvánvalóan a WebService rövidítése, és azt gondolhatja, hogy ez az RPC egyszerű átnevezése manapság népszerű szóvá. Ez nem így van, hiszen A webszolgáltatások most eltávolodtak az eredeti ötlettől, és nem csak távoli metódusok hívását teszik lehetővé, hanem egyszerűen SOAP formátumú dokumentumüzenetek küldését is. Hogy miért van erre szükség, azt még nem tudom, nem valószínű, hogy a válasz "csak abban az esetben, hirtelen szükség lesz rá". Én magam is szeretnék tanulni tapasztaltabb elvtársaktól. És az utolsó dolog, akkor ott volt a JAX-RS is az úgynevezett RESTful webszolgáltatásokhoz, de ez egy külön cikk témája. Ezen a ponton a bevezető befejezhető, tk. ezután megtanulunk dolgozni a JAX-WS-el.

Általános megközelítés

A webszolgáltatásoknak mindig van egy kliense és egy szerver. A szerver a webszolgáltatásunk, és néha végpontnak is nevezik (például az a végpont, ahová az ügyfél SOAP-üzenetei eljutnak). A következőket kell tennünk:

1. Ismertesse webszolgáltatásunk felületét
2. Valósítsa meg ezt a felületet
3. Indítsa el webszolgáltatásunkat
4. Írjon egy klienst, és távolról hívja fel a kívánt webszolgáltatási módot

A webszolgáltatás elindítható különböző utak: vagy deklarál egy osztályt egy fő metódussal, és futtassa a webszolgáltatást közvetlenül kiszolgálóként, vagy telepítse olyan kiszolgálóra, mint a Tomcat vagy bármi más. A második esetben mi magunk nem futunk új szerverés nem nyitunk másik portot a számítógépen, hanem egyszerűen közöljük a Tomcat servlet konténerrel, hogy "ide írtuk a webszolgáltatási osztályokat, tedd közzé, kérlek, hogy mindenki, aki kapcsolatba lép veled, használja a webszolgáltatásunkat." A webszolgáltatás indításának módjától függetlenül ugyanaz a kliensünk lesz.

szerver

Kezdjük el az ÖTLET-et és alkossunk új projekt Új projekt létrehozása... Adjunk meg egy nevet HelloWebServiceés nyomja meg a gombot Következő, majd a gombot Befejez... A mappában src hozzon létre egy csomagot ru.javarush.ws... Ebben a csomagban létrehozzuk a HelloWebService felületet: package ru. javarush. ws; // ezek annotációk, pl. osztályaink és módszereink megjelölésének módja, // a webszolgáltatás technológiához kapcsolódóan import javax. jws. WebMethod; import javax. jws. Webszolgáltatás; import javax. jws. szappan. SZAPPANKÖTÉS; // azt mondjuk, hogy a felületünk webszolgáltatásként fog működni@Webszolgáltatás // mondjuk, hogy a webszolgáltatás metódusok meghívására lesz használva@SOAPBinding (stílus = SOAPBinding. Stílus. RPC) nyilvános felület HelloWebService ( // azt mondjuk, hogy ez a metódus távolról hívható@WebMethod public String getHelloString (karakterlánc neve); ) Ebben a kódban a WebService és WebMethod osztályok úgynevezett annotációk, és nem tesznek mást, mint a felületünket és annak metódusát webszolgáltatásként jelölik meg. Ugyanez igaz a SOAPBinding osztályra is. Az egyetlen különbség az, hogy a SOAPBinding egy paraméter-annotáció. V ez az eset a style paramétert olyan értékkel használjuk, amely azt mondja, hogy a webszolgáltatás nem dokumentumüzeneteken keresztül fog működni, hanem klasszikus RPC-ként, pl. hogy hívja a módszert. Valósítsuk meg felületünk logikáját, és hozzunk létre egy HelloWebServiceImpl osztályt a csomagunkban. Amúgy megjegyzem, hogy az Impl-ben az osztály vége egy konvenció a Java-ban, amely szerint az interfészek megvalósítását így jelölik (Impl - az implementáció szóból, azaz implementáció). Ez nem követelmény, és szabadon nevezheti az osztályt, amit akar, de a jó forma szabályai megkövetelik: csomag ru. javarush. ws; // ugyanaz a megjegyzés, mint az interfész leírásánál, import javax. jws. Webszolgáltatás; // de itt az endpointInterface paraméterrel használjuk, // webszolgáltatásunk felületének teljes képzésű osztálynevének megadásával@WebService (endpointInterface = "ru.javarush.ws.HelloWebService") public class HelloWebServiceImpl implementálja a HelloWebService-t (@A public String felülbírálása getHelloString (karakterlánc neve) // csak üdvözlés return "Hello," + name + "!" ; )) Indítsuk el webszolgáltatásunkat független szerverként, i.e. Tomcat és alkalmazásszerverek bevonása nélkül (ez egy külön beszélgetés témája). Ehhez a mappában található projektstruktúrában src hozzon létre egy ru.javarush.endpoint csomagot, és abban hozzon létre egy HelloWebServicePublisher osztályt egy fő metódussal: package ru. javarush. végpont; // osztály webszolgáltatásokkal rendelkező webszerver elindításához import javax. xml. ws. végpont; // webszolgáltatásunk osztálya import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher (public static void main (String... args) ( // indítsa el a webszervert az 1986-os porton // és az első argumentumban megadott címen, // elindítja a második argumentumban átadott webszolgáltatást Végpont. közzétenni ( "http: // localhost: 1986 / wss / hello", új HelloWebServiceImpl ()); )) Most indítsuk el ezt az osztályt kattintással Shift + F10... Semmi sem jelenik meg a konzolban, de a szerver fut. Ezt úgy ellenőrizheti, hogy beírja a böngészőbe a http://localhost: 1986 / wss / hello? Wsdl sort. A megnyíló oldal egyrészt bizonyítja, hogy a számítógépünkön (localhost) elindult egy webszerver (http: //) az 1986-os porton, másrészt megmutatja webszolgáltatásunk WSDL leírását. Ha leállítja az alkalmazást, akkor a leírás elérhetetlenné válik, akárcsak maga a webszolgáltatás, így nem ezt tesszük, hanem folytatjuk a kliens írását.

Vevő

A projekt mappában src hozzon létre egy ru.javarush.client csomagot, és abban a HelloWebServiceClient osztályt a fő metódussal: package ru. javarush. ügyfél; // szükséges a wsdl leírásának lekéréséhez és azon keresztül // eléri magát a webszolgáltatást import java. háló. URL; // ilyen művelet akkor történik meg, ha egy URL objektummal dolgozik import java. háló. Rosszul formázott URL-kivétel; // osztályok az xml-ku elemzéséhez wsdl leírással // és elérjük a benne lévő szervizcímkét import javax. xml. névtér. QName; import javax. xml. ws. Szolgáltatás; // webszolgáltatásunk felülete (többre van szükségünk) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient (public static void main (String args) MalformedURLException () // hozzon létre egy hivatkozást a wsdl leírásához URL url= új URL ( "http: // localhost: 1986 / wss / hello? wsdl") ; // Megnézzük a következő konstruktor paramétereit a WSDL leírás legelső tagjában - definíciók // Nézd meg a targetNamespace attribútum 1. argumentumát // lásd a 2. argumentumot a name attribútumban QName qname = new QName ("http: //ws.site/", "HelloWebServiceImplService"); // Most már elérhetjük a szolgáltatás címkét a wsdl leírásban, Szerviz szolgáltatás= Szolgáltatás. létrehozás (url, qname); // majd egészen a beágyazott port címkéig, hogy // kap egy hivatkozást egy tőlünk távoli webszolgáltatás objektumra HelloWebService hello = szolgáltatás. getPort (HelloWebService. osztály); // Hurrá! Most már hívhatja a távoli módszert Rendszer. ki. println (hello. getHelloString ("CodeGym")); )) Maximum megjegyzést tettem a kiírásban szereplő kódhoz. Nincs mit hozzáfűzni, úgyhogy futunk (Shift + F10). Látnunk kell a szöveget a konzolon: Hello, CodeGym! Ha nem látta, valószínűleg elfelejtette elindítani a webszolgáltatást.

Következtetés

Ebben a témában egy rövid kirándulást mutattak be a webszolgáltatásokba. Ismétlem, sok mindent leírtam az én találgatásom a működésével kapcsolatban, ezért nem szabad túlságosan megbíznom bennem. Hálás lennék, ha hozzáértő emberek kijavítanak, mert akkor tanulok valamit. UPD.

Alekszej Bojko

SOAP és XML webszolgáltatások a .Net platformon

Az XML Web Services ilyen szintű kompatibilitást és interoperabilitást kínál az operációs rendszerek között,

olyan platformok és nyelvek, amelyek korábban egyszerűen nem voltak elérhetők.

Andrew Troelsen (MVP (a Microsoft legértékesebb szakembere))

Ha még nem dolgozott XML webszolgáltatásokkal, valószínűleg hallotta már a „SOAP” szót. Ideje megbirkózni ezekkel a fogalmakkal.

Intro

Ha érdeklődik az internet vagy a kisebb hálózatok iránt, akkor valószínűleg előbb-utóbb XML webszolgáltatásokkal találkozik. Az XML webszolgáltatás több, mint egy webalkalmazás, amely információkat bocsát ki a böngészőbe. Ez inkább egy távoli technológia, amely lehetővé teszi a hálózaton lévő objektumok metódusainak és tulajdonságainak meghívását szabványos HTTP-kérésekkel.

A gyakorlatban ez azt jelenti, hogy egy ilyen szolgáltatás ügyfelei különböző nyelveken és különböző operációs rendszerekhez írhatók.

A szolgáltatás és a kliens közötti információ "szállításként" a HTTP GET vagy POST metódusokat használhatja.

És egy másik protokollt is „átfedhet” a tetejére - a SOAP-ot (Simple Object Access Protocol). Ez általában megtörténik, mivel ebben az esetben lehetséges összetett típusok átadása (beleértve a felhasználó által meghatározottakat is). A klasszikus GET és POST metódusok pedig csak listákat, egyszerű tömböket és karakterláncokat támogatnak.

Példa SOAP Interop

A SOAP üzenet egy HTTP-kérelem törzsébe csomagolt XML-dokumentum.

Felsorolás 1. SOAP üzenet felépítése

Az ügyfél és a szolgáltatás közötti interakció a következő:

• a kliens SOAP kérést formál és elküldi a szolgáltatásnak;
• szolgáltatás bekapcsolva távoli számítógép végrehajtja az eljárást és SOAP választ küld.

Például egy SOAP-kérés így nézhet ki, és egy távoli XML webszolgáltatás HelloWorld () metódusát hívja meg:

Lista 2. Egy példa SOAP kérésre

A HelloWorld () metódus a várakozásoknak megfelelően a "Hello world!" karakterláncot adja vissza:

Lista 3. Minta SOAP válasz

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

Helló Világ!

XML webszolgáltatás létrehozása .NET 2.0-ban

Létrehozhat szolgáltatást különböző utak, akkor a Visual Studio 2005-öt fogjuk használni. Kattintson a "Fájl -> Új -> Webhely" elemre, a megnyíló ablakban válassza az "ASP.NET webszolgáltatás" lehetőséget. A létrehozás során megadott címen a következő fájlok és könyvtárak találhatók (lásd 1. ábra).

Elvileg egy szolgáltatás csak egyetlen fájlt tartalmazhat * .asmx kiterjesztéssel. (A * .asmx kiterjesztés a .Net webszolgáltatások jelölésére szolgál.) Ebben az esetben ez nem így van, nézze meg a Service.asmx fájl tartalmát:

Lista 4. A Service.asmx meghatározza külső fájl támogatás

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

A CodeBehind attribútum egy külső fájlt határoz meg az App_Code mappában, amely tartalmazza a HelloWorld () metódust megvalósító kódot:

Listázás 5. Service.cs fájl HelloWorld () módszer megvalósítása

Rendszer használata;

a System.Web használatával;

a System.Web.Services használatával;

Közszolgálat () (

Vissza a "Hello World";

Lehetőség van egyetlen Service.asmx fájl létrehozására támogatási kód nélkül, amely ugyanazokkal a funkciókkal rendelkezik:

Lista 6. Service.asmx külső támogatási kód nélkül

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

Rendszer használata;

a System.Web használatával;

a System.Web.Services használatával;

a System.Web.Services.Protocols használatával;

nyilvános osztály Szolgáltatás: System.Web.Services.WebService

Közszolgálat () (

Nyilvános karakterlánc HelloWorld () (

Vissza a "Hello World";

Nincs erre szükségünk, és nem is fogjuk megtenni.

Amint láthatja, webszolgáltatásunk egyetlen metódusa olyan attribútummal van ellátva, amely tájékoztatja az ASP.NET futási környezetet, hogy ez a metódus elérhető a bejövő HTTP-kérésekhez. Az ezzel az attribútummal nem azonosított tagok nem lesznek elérhetők az ügyfélprogramok számára.

Egy ilyen egyszerű szolgáltatás meglehetősen alkalmas kísérleteinkhez, csak közzé kell tenni.

XML webszolgáltatás közzététele IIS segítségével

Nem az internetes közzétételről beszélünk, hanem arról, hogy megteremtsük a feltételeket szolgáltatásunk helyi számítógépen történő teszteléséhez.

Az első lépés az IIS (Internet Information Server) telepítése. Ehhez nyissa meg a "Programok telepítése és törlése" ablakot, és válassza a "Telepítés" lehetőséget Windows összetevők". (Néhány Windows verziók nem tartalmaz IIS-telepítést, például Windows XP Home Edition-t.)

Jegyzet: IIS szerver jobb a .Net Frameworknél korábban telepíteni, különben a segédprogram futtatásával be kell állítani az IIS-t, hogy támogassa a .Net alkalmazásokat parancs sor aspnet_regiis.exe (a / i jelzővel).

Hozzon létre egy virtuális könyvtárat. Ha Windows XP Pro-t használ, lépjen a "Vezérlőpult -> Felügyeleti eszközök -> Internetes információs szolgáltatások" menüpontra. A megnyíló ablakban válassza a Művelet -> Létrehozás -> Virtuális címtár menüpontot.

Elindul az Új virtuális címtár varázsló. Alias ​​„Soap1”, és adja meg annak a könyvtárnak az elérési útját, ahová a szolgáltatást el szeretné helyezni, például C: \ Soap1. Most másolja oda webszolgáltatásunk tartalmát.

Írja be a http://localhost/soap1/Service.asmx címet a böngésző címsorába, és látnia kell a szolgáltatástesztelési oldalt (lásd: 2. ábra).

SOAP üzenetek megtekintése

A tesztoldal nem teszi lehetővé SOAP üzenetek küldését és olvasását. Emiatt harmadik féltől származó fejlesztést kell használnia, javaslom a soapUI használatát. (Ez egy ingyenes termék, amely a http://www.soapui.org címen érhető el.)

A soapUI telepítése után hozzon létre egy új projektet soap1 néven, hagyja üresen az Initial WSDL mezőt (lásd 3. ábra).

Kattintson a jobb gombbal az újonnan létrehozott projektre, és válassza a "WSDL hozzáadása az URL-ből" lehetőséget. A megnyíló párbeszédpanelen írja be a http://localhost/soap1/Service.asmx?Wsdl címet. Mostantól lehetőségünk van SOAP kéréseket küldeni szolgáltatásunknak, és megtekinteni a kapott válaszokat. (A kéréseket a soapUI automatikusan generálja.)

Mi ez a WSDL? A WSDL dokumentum leírja, hogyan lépnek kapcsolatba az ügyfelek a webszolgáltatással. Leírja, hogy milyen szolgáltatási módok érhetők el a külső meghíváshoz, milyen paramétereket fogadnak el és mit adnak vissza, valamint a távvezérléshez szükséges egyéb információkat. Egy ilyen dokumentumot manuálisan is össze lehet állítani, vagy rábízhatjuk a szerverre a generálását, ehhez elég a * .asmx fájlra mutató URL-hez hozzáadni a Wsdl utótagot.

Szolgáltatásunk WSDL-dokumentumának megtekintéséhez írja be böngészőjében a http://localhost/soap1/Service.asmx?Wsdl címet. A dokumentumban található információkat a soapUI használja fel a SOAP kérések automatikus generálására.

SZAPPAN kiterjesztések

Amint azt valószínűleg észrevette, nem kell törődnie a SOAP-üzenetek megjelenésével egy XML-webszolgáltatás (például egy kliens) létrehozásához. A szükséges metódusokat elég egy attribútummal megjelölni, és az ASP.NET futási környezet a szükséges formátumú csomagokat generálja.

ábrán. A 4. ábra a soapUI program segítségével kapott webszolgáltatás kérését és válaszát mutatja.

Csináljuk meg még egyszer. A kérést a soapUI generálja - amikor valódi klienseket hoz létre a szolgáltatáshoz, akkor sem kell manuálisan formázni a SOAP-csomagokat. Mi sem vettünk részt közvetlenül a szolgálati válasz létrehozásában. Mindez automatikusan történik.

Valószínű azonban, hogy ezeket a csomagokat magának kell módosítania. Például tömörítse vagy titkosítsa a továbbított adatokat. Ez a SOAP Extensions célja.

A SOAP Extensions egy olyan mechanizmus, amely lehetővé teszi a küldött és fogadott SOAP üzenetek tetszőleges módosítását.

SOAP üzenet "útvonal"

A programozás megkezdéséhez figyelembe kell vennie azt az utat, amelyen egy SOAP üzenet megérkezik, mielőtt a megfelelő módszerrel megérkezik és feldolgozza (lásd 5. ábra).

A SOAP üzenet felfogható egy hálózaton továbbított objektumot leíró XML-dokumentumnak. Az így átadott objektum használata előtt vissza kell állítani (vagy ha úgy tetszik, össze kell rakni) ebből a leírásból. Az XML szerializáló ezt a célt szolgálja.

A bejövő csomagokat deszerializáljuk (objektum visszaállítása XML-leírásból), az elküldött csomagokat pedig szerializáljuk (egy objektum XML-leírását hozzuk létre).

ábrán. Az 5. ábra négy olyan pontot mutat (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), ahol elfoghatunk egy SOAP üzenetet a SOAP Extensions segítségével. Módosítsa és küldje tovább.

SOAP kiterjesztés megvalósítása

Kezdésként definiáljunk egy feladatot: tegyük fel, hogy módosítani szeretnénk a webszolgáltatás által küldött SOAP-csomagokat a 7. lista szerint:

Lista 7. Régi és új XML webszolgáltatás válaszok

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

Helló Világ

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

Rejtjelezett szöveg

Akcióterv a SOAP kiterjesztés megvalósításához:

• Hozzon létre egy dll-t a SoapExtension-től örökölt osztállyal.
• Adja hozzá a bin mappát a webszolgáltatásunkhoz, és helyezze oda a létrehozott dll-t.
• Adja hozzá a web.config fájlt a szolgáltatáshoz, és hajtsa végre a szükséges módosításokat.

A bin mappa és a web.config fájl szerepét később tárgyaljuk.

DLL létrehozása SOAP kiterjesztéssel

Hozzon létre egy új "Osztálykönyvtár" projektet SoapExtensionLib néven. Ebben a projektben csak egy osztályt kell megvalósítanunk, amely elvégzi a szükséges módosításokat a SOAP csomagokon. Ennek az osztálynak örökölnie kell a SoapExtension osztályt.

Felsorolás 8. A SoapExtensionből öröklő osztály létrehozása

Rendszer használata;

a System.Web.Services használatával;

a System.Web.Services.Protocols használatával;

a System.IO használatával;

a System.Net használatával;

a System.Xml használatával;

Minden SOAP bővítmény paraméterként kap egy adatfolyamot, amely tartalmazza a hálózaton átadandó objektumot (szerializálás előtt vagy után). És vissza kell adnia egy patakot.

A SOAP kiterjesztést egy „doboznak” tekinthetjük, amely az ábrán látható négy pont (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize) egyikére vagy mindegyikére elhelyezhető. 5. Minden ponton tetszőleges számú ilyen "betét" lehet (lásd 6. ábra).

A ChainStream metódust használják ezen adatfolyamok fogadására.

Felsorolás 9. A ChainStream módszer megvalósítása

nyilvános osztály TraceExtension: SoapExtension

Stream wireStream;

Stream appStream;

// metódus bemeneti paraméterként

// kap egy adatfolyamot, amely az átadott objektumot tartalmazza

Nyilvános felülbírálás Stream ChainStream (Stream adatfolyam)

WireStream = adatfolyam;

AppStream = új MemoryStream ();

Vissza az appStream;

…

A BeforeDeserialize-nél a wireStream tartalmazza a hálózattól kapott SOAP-kérést. Ezt a SOAP-kérést át kell adni az alkalmazásfolyamnak (appStream).

Az AfterSerialize ponton pedig el kell küldenie a hálózatnak küldött SOAP-választ a wireStream adatfolyamba, ami az appStreambe kerül.

Ha mind a négy ponton szálakkal szeretne dolgozni, meg kell valósítania a ProcessMessage metódust.

Felsorolás 10. A ProcessMessage metódus megvalósítása, amely nem módosítja a SOAP üzeneteket

// ProcessMessage elvégzi a kötelező másolatot

// két ponton streamel (BeforeDeserialize és AfterSerialize)

Kapcsoló (üzenet.Stage)

// a BeforeDeserialize pontnál át kell adni

// SOAP kérés a hálózati adatfolyamból (wireStream)

// az alkalmazás adatfolyamához (appStream)

Case SoapMessageStage.BeforeDeserialize:

Másolás (wireStream, appStream);

AppStream.Position = 0;

Szünet;

// az AfterSerialize ponton át kell adni

// SOAP válasz az alkalmazás adatfolyamtól a hálózati adatfolyamhoz

AppStream.Position = 0;

Szünet;

érvénytelen Másolás (Stream innen, Stream ide)

TextReader olvasó = új StreamReader (tól);

TextWriter író = új StreamWriter (hoz);

Writer.WriteLine (reader.ReadToEnd ());

Író.Flush ();

Tekintse a 10. listát üresnek a további kísérletezéshez. A ProcessMessage metódus ezen megvalósításának semmi értelme – a kimenő SOAP-válasz semmilyen módon nem módosul. Javítsuk ki:

Felsorolás 11. A ProcessMessage metódus megvalósítása a SOAP-válasz módosításához

nyilvános felülírás érvénytelen ProcessMessage (SoapMessage üzenet)

Kapcsoló (üzenet.Stage)

Case SoapMessageStage.AfterSerialize:

WriteOutput (üzenet);

Szünet;

// a kód egy részét a helytakarékosság érdekében kivágták

// átírja a SOAP választ

public void WriteOutput (SoapMessage üzenet)

AppStream.Position = 0;

// XML dokumentum létrehozása a folyamból

XmlDocument document = új XmlDocument ();

Document.Load (appStream);

// Az XPath használatához definiálni kell

// NamespaceManager

XmlNamespaceManager nsmgr = new XmlNamespaceManager (document.NameTable);

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

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

// cserélje ki a csomópont tartalmát

ResultNode.InnerText = "titkosszöveg";

// tisztítsa meg a folyamot, és írjon rá egy új SOAP választ

AppStream.SetLength (0);

AppStream.Position = 0;

Document.Save (appStream);

// KÖTELEZŐ INTÉZKEDÉS

// átadja a SOAP választ az alkalmazásfolyamból (appStream)

// a hálózati adatfolyamba (wireStream)

AppStream.Position = 0;

Másolás (appStream, wireStream);

Ezután két metódust kell meghatározni (amelyek közül az egyik túlterhelt, azaz különböző paraméterkészletekkel hívható), amelyekre esetünkben nincs szükség. Ezeket azonban a SoapExtension osztályból való öröklődés szabályai szerint kell meghatároznunk.

Felsorolás 12. Egyéb szükséges módszerek

// Az öröklési szabályoknak megfelelően kell

// definiáljuk ezeket a metódusokat, de semmilyen módon nem használjuk őket

nyilvános felülírási objektum?

GetInitializer (LogicalMethodInfo methodInfo, SoapExtensionAttribute attribútum)

Return null;

nyilvános felülbírálási objektum GetInitializer (WebServiceType típus)

Return null;

nyilvános felülírás érvénytelen Inicializálás (objektum inicializáló)

Visszatérés;

Ennyi, összeállítjuk a projektet. Végül kaptunk egy dll-t SOAP kiterjesztéssel. A SoapExtensionLib.dll teljes listája megtalálható a folyóirat webhelyén a „Forráskód” részben.

Webszolgáltatás konfigurálása a SOAP bővítmény használatára

Nyissa meg újra XML webszolgáltatási projektünket a Visual Studio segítségével. Kattintson a "Webhely -> Referencia hozzáadása" elemre, és válassza ki a korábban létrehozott SoapExtensionLib.dll fájlt.

A Bin mappa automatikusan hozzáadódik a projekthez. Az alkalmazás automatikusan hivatkozik a Bin mappában található * .dll fájlokra.

Most helyezze el a Web.Config fájl következő tartalmát a webszolgáltatási könyvtárba:

Lista 13. A Web.Config fájl

Prioritás = "1"

Csoport = "0" />

Most a szolgáltatásunk felépítése úgy néz ki, mint az ábrán látható. 7.

A Web.Config fájl segítségével tájékoztatjuk az ASP.NET keretrendszert arról, hogy hozzáadtuk az XML Soap Extension webszolgáltatáshoz, amelyet a SoapExtensionLi.dll fájlban található TraceExtension osztályban valósítottunk meg.

Lista 14. A WebServices szakasz a Web.Config fájlban

Prioritás = "1"

Csoport = "0" />

Mint már tudod, sok SOAP kiterjesztést lehet készíteni, és az átadott objektumot hordozó folyam (szerializálás előtt vagy után) mindegyiken keresztül fog menni. A különböző SOAP-bővítmények folyamatának sorrendje a prioritás- és csoportattribútumok használatával van megadva.

Érdemes megjegyezni, hogy a Web.Config ilyen módon történő konfigurálásával tájékoztatjuk a környezetet, hogy az attribútummal megjelölt szolgáltatás minden metódusához a SOAP kiterjesztést hívják meg. Lehetőség van saját attribútum létrehozására és csak azokat a metódusok megjelölésére, amelyekhez a SOAP kiterjesztést kell meghívni.

15. lista. Példa egyéni attribútum használatára

nyilvános karakterlánc HelloWorld () (

Vissza a "Hello World";

Ehhez a SoapExtensionAttribute-ból örökölt osztályt kell hozzáadni a SoapExtensionLi.dll fájlhoz (lásd: 8. ábra).

Következtetés

Ez a cikk az XML webszolgáltatások .Net platformon történő felépítésének és működésének főbb pontjait tükrözi. Remélem, hogy a bemutatott anyag elég lesz ahhoz, hogy szükség esetén mélyebben tanulmányozhassa a témát.

Kapcsolatban áll