Interneti arenedes tekkis vajadus luua hajutatud rakendusi. Arvutisse installitud rakendused kasutavad tavaliselt selles hostitud teeke. Ühte teeki saab kasutada mitu programmi. Kas veebis on võimalik majutada raamatukogude analooge, et erinevad saidid saaksid neile helistada? Selgub, et jah.
Ettevõtted pakuvad oma lehtedel mitmesugust teavet. Näiteks avaldab Fordi ettevõte oma veebisaidil http://www.Ford.com teavet mudelite ja hindade kohta. Selle ettevõtte edasimüüja soovib seda teavet oma veebisaidil saada. Veebiteenus võimaldab tarbijasaidil hankida teavet teenusepakkuja saidilt. Tarbijasait kuvab selle teabe oma lehtedel. Selle teabe genereerimiseks kasutatav kood kirjutatakse üks kord, kuid seda saavad kasutada paljud tarbijad. Andmed on esitatud lihttekstina, nii et neid saab kasutada olenemata platvormist.
Veebiteenuseid kasutatakse laialdaselt nii töölaua- kui ka Interneti-rakendustes. Need ei ole iseenesest rakendused, vaid rakenduste andmeallikad. Neil puudub kasutajaliides. Veebiteenuseid ei pea kasutama üle veebi – need võivad olla osa projektist, milles neid kasutatakse.
Veebiteenused on funktsioonid ja andmed, mida pakuvad välisrakendused, mis suhtlevad teenustega standardsete protokollide ja andmevormingute kaudu. Veebiteenused on rakenduskeelest ja platvormist täiesti sõltumatud. Veebiteenuste tehnoloogia on Microsofti programmeerimismudeli nurgakivi. NET.
See on edasine areng komponentide programmeerimine CORBA ja DCOM. Selliste komponentide kasutamiseks on aga vaja need registreerida tarbija süsteemis. See pole veebiteenuste jaoks vajalik. Komponendid töötavad hästi kohalikes võrkudes. HTTP-protokoll ei sobi kaugprotseduurikõnede (RPC) jaoks. Isegi sama organisatsiooni sees erinevad Operatsioonisüsteemid, mis saab suhelda ainult HTTP kaudu.
Mitmel korral üritati luua suhtluskeelt heterogeensete süsteemide vahel - DCOM, CORBA, RMI, IIOP. Need ei pälvinud üldist heakskiitu, kuna igaüks neist oli reklaamitud eri tootja poolt ja oli seetõttu seotud konkreetse tootja tehnoloogiaga. Keegi ei tahtnud aktsepteerida kellegi teise standardit. Selle dilemma lahendamiseks on mitmed ettevõtted nõustunud töötama välja müüjast sõltumatu standardi HTTP kaudu sõnumite edastamiseks. 2000. aasta mais pöördusid IBM, Microsoft, HP, Lotus, SAP, UserLand ja teised W3C poole ja esitasid SOAP-i sellise standardi kandidaadina. SOAP muutis rakenduste arendamise revolutsiooni, ühendades kaks Interneti-standardit, HTTP ja XML.
SEEP
Veebiteenustega suhtlemiseks kasutatakse XML-il põhinevat SOAP-protokolli. Võimalik oleks kasutada ka lihtsalt XML-i, kuid see on liiga lõtv formaat, milles iga dokument loob tegelikult oma keele. SEEP on konventsioon XML-dokumendi vormingu kohta, teatud elementide ja nimeruumide olemasolu kohta selles.
SOAP võimaldab teil avaldada ja tarbida keerulisi andmestruktuure, nagu DataSet. Samal ajal on seda lihtne õppida. Praegune versioon SEEP-1.2.
SOAP on lihtsa objekti juurdepääsu protokoll. SOAP on loodud selleks, et hõlbustada rakenduste suhtlemist HTTP kaudu. See on spetsiaalne platvormist sõltumatu Interneti-sõnumite vorming. SOAP-sõnum on lihtsalt tavaline XML-dokument. Standard
Lüüriline osa.
Kujutage ette, et olete rakendanud või rakendate teatud süsteemi, mis peaks olema väljastpoolt kättesaadav. Need. seal on kindel server, millega peate suhtlema. Näiteks veebiserver.
See server võib teha palju toiminguid, töötada andmebaasiga, täita mõnda kolmanda osapoole päringut teistele serveritele, teha arvutusi jne. elada ja võib-olla areneda tema tuntud stsenaariumi järgi (st arendajate stsenaariumi järgi). Inimesel pole huvitav sellise serveriga suhelda, sest ta ei pruugi osata/taha anda ilusaid lehti piltide ja muu kasutajasõbraliku sisuga. See on kirjutatud ja töötab ja väljastab selle päringutele andmeid, hoolimata sellest, et need on inimloetavad, klient tegeleb nendega ise.
Teised süsteemid, mis sellele serverile juurde pääsevad, saavad sellelt serverilt saadud andmeid juba oma äranägemise järgi käsutada – töödelda, koguda, oma klientidele väljastada jne.
Noh, üks selliste serveritega suhtlemise võimalustest on SOAP. SOAP XML sõnumsideprotokoll.
Praktiline osa.
Veebiteenus (see on see, mida server pakub ja mida kliendid kasutavad) võimaldab suhelda serveriga hästi struktureeritud sõnumites. Fakt on see, et veebiteenus ei aktsepteeri andmeid. Kõik reeglitele mittevastavad sõnumid tagastab veebiteenus veaga. Viga tuleb muide ka selge ülesehitusega xml kujul (mida ei saa kirja teksti kohta tõele öelda).
WSDL (veebiteenuste kirjelduskeel). Reegleid, mille järgi veebiteenuse jaoks sõnumeid koostatakse, kirjeldatakse samal viisil kasutades xml ja neil on ka selge struktuur. Need. kui veebiteenus pakub võimalust meetodi kutsumiseks, peab see võimaldama klientidel teada saada, milliseid parameetreid selle meetodi jaoks kasutatakse. Kui veebiteenus ootab parameetrina Method1 meetodi stringi ja string peab kandma nime Param1, siis need reeglid täpsustatakse veebiteenuse kirjelduses.
Parameetritena saab edastada mitte ainult lihtsaid tüüpe, vaid ka objekte, objektide kogumeid. Objekti kirjeldus taandatakse objekti iga komponendi kirjelduseks. Kui objekt koosneb mitmest väljast, siis kirjeldatakse iga välja, mis tüüpi see on, nimi (mis on võimalikud väärtused). Väljad võivad olla ka komplekstüüpi ja nii edasi, kuni tüüpide kirjeldus lõpeb lihtsatega - string, tõeväärtus, number, kuupäev... Mõni konkreetne tüüp võib aga osutuda lihtsaks, oluline on, et kliendid saavad aru, millised väärtused võivad neis sisalduda.
Klientidele piisab veebiteenuse url-i teadmisest, alati on läheduses wsdl, mille abil saab aimu meetoditest ja nende parameetritest, mida see veebiteenus pakub.
Millised on kõigi nende kellade ja vilede eelised:
- Enamikus süsteemides toimub meetodite ja tüüpide deklareerimine automaatrežiim. Need. piisab sellest, kui serveris olev programmeerija seda ütleb seda meetodit saab helistada veebiteenuse kaudu ja wsdl-i kirjeldus genereeritakse automaatselt.
Automaatne kinnitamine.
- xml valideerimine. xml peab olema hästi vormistatud. kehtetu xml - kohe viga kliendile, las ta ise välja mõtleb.
- skeemi valideerimine. xml-il peab olema kindel struktuur. xml ei vasta skeemile - kohe viga kliendile, las ta ise välja mõtleb.
- andmete valideerimise viib läbi seebiserver, et andmetüübid ja piirangud vastaksid kirjeldusele.
- Autoriseerimist ja autentimist saab rakendada eraldi meetod. algselt. või kasutades http autoriseerimist.
- Veebiteenused võivad töötada nii seebiprotokolli kui ka http kaudu, st hankimispäringute kaudu. See tähendab, et kui parameetritena kasutatakse lihtsaid andmeid (ilma struktuurita), võite lihtsalt helistada tavalisele saidile www.site.com/users.asmx/GetUser?Name=Vasia või postitus. Kuid see pole alati ja igal pool.
- ... vaata wikipediast
Selge struktuuriga kirjeldus on loetav igale seebikliendile. Need. olenemata veebiteenusest saab klient aru, milliseid andmeid veebiteenus vastu võtab. Selle kirjelduse järgi saab klient ehitada oma sisemise objektiklasside struktuuri nn. sidumine" ja. Selle tulemusena peab veebiteenust kasutav programmeerija kirjutama midagi sellist (pseudokood):
NewUser:=TSoapUser.Create("Vasya","Pupkin","admin"); seep.AddUser(Uuskasutaja);
Samuti on palju miinuseid:
- Ebamõistlikult suur sõnumi suurus. No siin on xml-i olemus selline, et formaat on üleliigne, mida rohkem silte, seda rohkem kasutut infot. Pluss seep lisab selle liiasust. Sisevõrgusüsteemide puhul on liikluse probleem vähem terav kui Interneti puhul, nii et seep kohalikud võrgud rohkem nõudlust, eriti Sharepointil on seebi veebiteenus, millega saate edukalt suhelda (ja mõned piirangud).
- Veebiteenuse kirjelduse automaatne muutmine võib murda kõik kliendid. Noh, see on nagu iga süsteemi puhul, nii et kui tagasiühilduvust vanade meetoditega ei toetata, kukub kõik ära ...
- Mitte miinus, vaid miinus. Kõik meetodi kutsetoimingud peavad olema aatomipõhised. Näiteks alamd-ga töötades saame alustada tehingut, sooritada mitu päringut, seejärel tagasipööramine või kinnistamine. Seebiga tehinguid ei toimu. Üks palve, üks vastus, vestlus on lõppenud.
- Serveri poolel oleva kirjeldusega tegelemine (kas kõik on minu poolt õigesti kirjeldatud?), Kliendil oleva (mis mulle siia kirjutati?) Võib olla päris keeruline. Oli mitmeid kordi, kui pidin tegelema kliendi poolega ja veenma serveri programmeerijat, et ta on andmeid valesti kirjeldanud, kuid ta ei saanud neist üldse midagi aru, sest automaatne genereerimine ja tema justkui ei peaks, see on tarkvara küsimus. Ja viga oli loomulikult meetodi koodis, programmeerija lihtsalt ei näinud seda.
- Praktika näitab, et veebiteenuste arendajad on nende veebiteenuste kasutajatest kohutavalt kaugel. Vastuseks igale soovile (kehtib väljastpoolt) võib tulla arusaamatu tõrge "Viga 5. Kõik on halvasti". Kõik oleneb arendajate südametunnistusest :)
- Ma olen kindel, et ma ei mäletanud midagi...
Näiteks on avatud belavia veebiteenus:
- http://86.57.245.235/TimeTable/Service.asmx - sisenemispunkt, seal on ka tekstiline meetodite kirjeldus kolmandate osapoolte arendajatele.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl vastuvõetud ja tagastatud andmete meetodite ja tüüpide kirjeldus.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList – konkreetse meetodi kirjeldus koos näitega xml päringu ja xml vastuse tüübist.
Saate käsitsi luua ja saata päringu, näiteks:
POST /TimeTable/Service.asmx HTTP/1.1 Host: 86.57.245.235 Sisutüüp: text/xml; charset=utf-8 Sisu pikkus: pikkus SOAPAction: "http://webservices.belavia.by/GetAirportsList"
vastus saab olema:
HTTP/1.1 200 OK Kuupäev: esmaspäev, 30. september 2013 00:06:44 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-versioon: 4.0.30319 Vahemälu juhtimine: privaatne, max -age=0 sisutüüp: tekst/xml; charset=utf-8 Sisu pikkus: 2940
ZY Varem avati Aerofloti veebiteenus, kuid pärast seda, kui 1C lisas 8ku-s seebi toe, installis hunnik 1c beetatestijaid selle edukalt. Nüüd on seal midagi muutunud (ma aadressi ei tea, huvi korral võib otsida).
ZZY lahtiütlemine. Ta rääkis leibkonna tasandil. Sa võid juua.
Vastutusest loobumine:Sellel teemal on kirjutatud palju artikleid ja nagu te muidugi arvasite, on see veel üks. Võib-olla õpite sellest midagi uut, kuid siin pole kirjeldatud midagi ülisalajast, mida te ei saaks ise googeldada. Ainult märkmed isiklikust kogemusest.
Sissejuhatus
Arvestame ainult olukorraga, kui on olemas kolmanda osapoole veebiteenus ja ülesandeks on andmevahetuse sisseseadmine.
Teenuse struktuur on failis kirjeldatud WSDL(ing. Web Services Description Language)
Failile pääseb kõige sagedamini ligi lingi kaudu, kus asub veebiteenuse enda sisenemispunkt. Kirjutasin "kõige sagedamini", sest on erandeid. Näiteks SAP-põhine veebiteenus ei avalda wsdl-i ja seda saab laadida ainult rakendusest endast.
Ja nii, meil on veebiteenuse kirjeldus, sisselogimine, parool. Ühendame.
// Määrake ServiceNamespace'i URL = "http://Somesite.ru" seaded; Kasutajanimi = "TestUser"; Parool = "q1w2e3"; LocationWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "Some ServiceName"; ConnectionPointName = "SomeService_Port"; // SSL-ühenduse loomine = Uus SecureConnectionOpenSSL(); WSDdefinitsioon = uus WSDdefinitsioon(asukohtWSDL,SSL); WSProxy = Uus WSProxy(WSDdefinitsioon, teenusenimeruumi URL, teenusenimi, ühenduspunkti nimi, SSL); WSProxy.User = Kasutajanimi; WSProxy.Password = Parool;
Hästi! Oleme veebiteenusega ühenduse loonud! Teoreetiliselt on see iga vahetusvõimaluse aluseks, kuna see võimaldab teil luua andmestruktuuri objekt põhineb wsdl-l ja sellise objektiga töötamine on rõõm.
Mõelge XML-ile, mille SoapUI meile annab
Nüüd kirjeldame seda programmiliselt
// Looge objekt ja täitke see andmetega OwnXDTOFactory = WSDefinition.XDTOFactory; RootType = OwnFactoryXDTO.Type(URLServiceNamespace, "ESITAMINE"); RootObject = OwnFactoryXDTO.Create(RootType); RootObject.ID = "4356"; ClientType = OwnFactoryXDTO.Type(URLServiceNamespace, "KLIENT"); ClientObject = OwnFactoryXDTO.Create(ClientType); ClientObject.CLIENT_ID = "121212"; ClientObject.SEX = "M"; // F - naine, M - meessoost ClientObject.CLIENT_BIRTHDAY = "19900111"; // Kliendi autode automaattüüp = CustomFactoryXDTO.Type(URLServiceNamespace, "CARS"); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Mercedes"; AutoObject.MODEL = "GLS"; ClientObject.CARS.Add(AutoObject); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Audi"; AutoObject.MODEL = "TT"; ClientObject.CARS.Add(AutoObject); RootObject.CUSTOMER.Add(ClientObject);
Andmed edukalt lõpetatud. Nüüd peame nad saatma.
Just sel hetkel kerkib esile palju nüansse. Proovime kaaluda iga.
Retsept 1. Kogu XDTO objekti saatmine
Tulemus = WSProxy.AddCustomers(RootObject);
Jääb vaid tulemust töödelda, et teenus tagastas meile ja kõik. Nõus, et see on väga mugav!
Kuid praktikas pole see alati nii. Näiteks 1c ei saa xml-is teatud siltide eesliitega hakkama, kui juurmärgendi nimeruum erineb alammärgendite omast. Sellistel juhtudel peate seebi käsitsi koguma. Samuti pidin tegelema veebiteenustega, mis eeldavad parameetrina puhast xml-i. Hullumeelsus, aga sellegipoolest pole seda liiga raske teha.
Retsept 2. Puhta xml-i saatmine parameetrina
XMLRecordParameters = NewXMLRecordParameters("UTF-8", "1.0", Tõene); MyXML = uus XMLWriter; MyXML.SetString(XMLRecordParameters); MyXML.WriteDeclarationXML(); KohandatudXDTOFactory.WriteXML(MyXML, RootObject); StringXML = MyXML.Close(); Kui DeleteNamespaceDescription then AttemptFirstTagInString = StrGetString(XMLString,2); RootTagName = RootObject.Type().Nimi; XMLString = StrReplace(XMLString, FirstTagInString, "<"+ИмяКорневогоТэга+">"); Erand //ErrorDescription() EndTry; EndIf; Result = WSProxy.AddCustomers(XML String);
Kui te ei eemalda nimeruumi, mille 1s vaikimisi lisab, on see muutunud enamaks kui 5 koodirida. Enamasti mähkin xml-teisenduse funktsiooni, kuna tavaliselt kutsume rohkem kui ühte meetodit.
Retsept 3. Saada natiivse HTTP-päringu kaudu.
SOAP string = "Selle valiku korral peame seebi käsitsi valmistama. Sisuliselt mähime retsepti 2 xml-i lihtsalt seebiümbrisesse, kus vastavalt veebiteenuse nõudmistele saame oma seepi oma südameasjaks muuta.
Järgmisena kirjeldame päiseid vastavalt dokumentatsioonile. Mõned teenused närivad meie päringu hõlpsalt ilma päisteta, siin peate vaatama konkreetset juhtumit. Kui te ei tea, milliseid päiseid ette kirjutada, on kõige lihtsam viis taotlust SoapUI-s piiluda, lülitudes vahekaardile RAW.
Base64 stringi hankimise funktsioon näeb välja järgmine (piilutud):
Funktsioon GetBase64AuthorizationHeader(kasutajanimi, parool) FileEncoding = TextEncoding.UTF8; TempFile = GetTemporaryFileName(); Record = New TextWrite(TemporaryFile, FileEncoding); Write.Write(Kasutajanimi+":"+Parool); Record.Close(); BinData = uued kahendandmed (TempFile); Tulemus = Base64String(DvData); Kustuta failid (TempFile); Tulemus = keskmine(tulemus,5); Tagastamise tulemus; Lõppfunktsioonid
On oluline punkt. HTTPConnectioniga töötades määrake aadress ilma protokolle "http://" ja "https://" määramata, vastasel juhul võite raisata aega ilmse vea otsimisele.
Retsept 4. Saatmine WinHttpRequesti kaudu
WinHttp = Uus 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("Sisutüüp", "tekst/xml"); WinHttp.SetCredentials(kasutajanimi, parool, 0); WinHttp.Saada(SOAP String); WinHttp.WaitForResponse(15); XMLResponse = WinHttp.ResponseText();Siin on tegelikult sama, mis eelmises versioonis, kuid me töötame COMO-objektiga. Määrame ühenduse stringi täielikult koos protokolliga. Erilist tähelepanu tuleks pöörata ainult SSL-sertifikaatide vigade ignoreerimise lippudele. Neid on vaja, kui töötame SSL-i kaudu, kuid ilma konkreetse sertifikaadita, kuna selle valikuga pole võimalik uut turvalist ühendust luua (või ma ei tea, kuidas). Ülejäänud mehhanism on sarnane eelmisele.
Lisaks "WinHttp.WinHttpRequest.5.1" saate kasutada ka "Microsoft.XMLHTTP", "Msxml2.XMLHTTP", "Msxml2.XMLHTTP.3.0", "Msxml2.XMLHTTP.6.0", kui see äkki ei võta WinHttp-s välja lülitatud. Meetodid on peaaegu samad, erinev on ainult parameetrite arv. Ma kahtlustan, et üks neist valikutest on ühendatud 1c HTTPRequest objekti sees.
Hetkel on need kõik retseptid, mis mul on. Kui uutega kokku puutun, täiendan kindlasti artiklit.
Tulemuse töötlemine
Retseptis 1 saame kõige sagedamini valmis XDTO objekti ja töötame sellega struktuurina. Kõigil muudel juhtudel saate teisendada xml-vastuse XDTO-ks
Kui Result.StatusCode = 200, siis XMLReader = Uus XMLReader; ReadingXML.SetString(Result.GetBodyAsString()); ResponseObject = OwnFactoryXDTO.ReadXML(ReadingXML); Report(ObjectResponse.Body.Response.RESPONSE_ID); Report(ObjectResponse.Body.Response.RESPONSE_TEXT); EndIf;
Siin on kõik lihtne.
Järelduse asemel
1. Alustage veebiteenustega töötamist SoapUI programmiga. See on mõeldud selliseks tööks ja võimaldab teil kiiresti mõista, kuidas konkreetne teenus töötab. On artikkel, mida õppida
2. Kui vahetate teenusega ebaturvalise http kanali kaudu ja tekib küsimus, mida täpselt 1s teie sõnumites saadab, siis võite kasutada liikluse nuusutajaid nagu Wireshark, Fiddler jt. Probleem ilmneb ainult siis, kui kasutate ssl-ühendust.
3. Kui veebiteenus siiski suhtleb https kaudu, siis installime Nginxi serveri kaugmasinasse (mis tahes, mis kõige tähtsam, mitte omaette), millega võtame ühendust ja see omakorda pakib kõik sisse https ja saada see õigesse kohta ( vastupidine puhverserver ) ja lisage standardsele konfiguratsioonile:
Server ( kuulata 0.0.0.0:8080; serveri_nimi MinuServer; asukoht ~ .* ( proxy_pass https://Somesite.ru:8001; proxy_set_header Host $host; proxy_set_header Autoriseerimine "Basic
5. Kui autentimine hõlmab küpsiste kasutamist, leiti järgmine
P.S. Kui teil on küsimusi, ettepanekuid koodi täiustamiseks, teil on oma retsepte, mis erinevad kirjeldatutest, leiate vigu või arvate, et autor on "vale" ja ta "ei kuulu 1-sse", siis kirjutage kommentaaridesse ja arutame kõike.
Teema pealkiri on tõesti küsimus, sest Ma ise ei tea, mis see on ja proovin esimest korda selle artikli raames sellega töötada. Ainus, mida võin garanteerida, on see, et allolev kood töötab, kuid minu fraasid on ainult oletused ja oletused selle kohta, kuidas ma ise sellest kõigest aru saan. Nii et lähme...
Sissejuhatus
Alustada tuleb sellest, milleks veebiteenuste kontseptsioon loodi. Selle kontseptsiooni ilmumise ajaks olid maailmas juba olemas tehnoloogiad, mis võimaldasid rakendustel distantsilt suhelda, kus üks programm võis mõnes teises programmis mõne meetodi välja kutsuda, mille sai seejärel käivitada teises linnas või isegi riigis asuvas arvutis. Kõik see on lühendatud kui RPC (Remote Procedure Calling – kaugprotseduurikõne). Näited hõlmavad CORBA tehnoloogiaid ja Java puhul RMI-d (Remote Method Invoking – kaugmeetodi kutsumine). Ja nendes tundub kõik hästi olevat, eriti CORBA-s, sest sellega saab töötada mis tahes programmeerimiskeeles, aga midagi jäi siiski puudu. Usun, et CORBA miinuseks on see, et see toimib läbi mõne oma võrguprotokollid tavalise HTTP asemel, mis pääseb läbi mis tahes tulemüüri. Veebiteenuse idee oli luua selline RPC, mis lükataks HTTP-pakettidesse. Nii algas standardi väljatöötamine. Millised on selle standardi põhimõisted:- SEEP. Enne kaugprotseduuri helistamist peate seda kõnet kirjeldama XML-fail e SOAP-vormingus. SOAP on vaid üks paljudest veebiteenustes kasutatavatest XML-märgistustest. Kõik, mida tahame HTTP kaudu kuhugi saata, muudetakse esmalt XML SOAP kirjelduseks, seejärel pannakse HTTP paketti ja saadetakse TCP / IP kaudu võrgus teise arvutisse.
- WSDL. On olemas veebiteenus, st. programm, mille meetodeid saab eemalt kutsuda. Kuid standard nõuab, et sellele programmile tuleb lisada kirjeldus, mis ütleb, et "jah, te ei eksinud - see on tõesti veebiteenus ja sealt saate kutsuda selliseid ja selliseid meetodeid." Seda kirjeldust esindab teine XML-fail, millel on erinev vorming, nimelt WSDL. Need. WSDL on lihtsalt XML-fail, mis kirjeldab veebiteenust ja ei midagi muud.
Üldine lähenemine
Veebiteenustel on alati klient ja server. Server on meie veebiteenus ja seda nimetatakse mõnikord ka lõpp-punktiks (nt lõpp-punkt, kuhu jõuavad kliendi SOAP-sõnumid). Peame tegema järgmist.- Kirjeldage meie veebiteenuse liidest
- Rakendage see liides
- Käivitage meie veebiteenus
- Kirjutage klient ja helistage eemalt soovitud veebiteenuse meetodile
Server
Käivitage IDEA ja looge uus projekt Loo uus projekt. Määrake nimi tereteenus ja vajutage nuppu Edasi, seejärel nuppu Lõpetama. Kaustas src luua pakett et.javarush.ws. Selles paketis loome HelloWebService'i liidese: pakett ru. javarush. ws; // need on annotatsioonid, st. viis meie klasside ja meetodite märkimiseks, // mis on seotud veebiteenuste tehnoloogiaga importida javaxi. jws. WebMethod; importida javaxi. jws. veebiteenus; importida javaxi. jws. seep. SOAPBinding; // me ütleme, et meie liides töötab veebiteenusena@WebService // öelda, et meetodite kutsumiseks kasutatakse veebiteenust@SOAPBinding(style = SOAPBinding.Style.RPC) avalik liides HelloWebService( // ütleme, et seda meetodit saab kaugjuhtimisega kutsuda@WebMethod public String getHelloString(Stringi nimi) ; ) Selles koodis on WebService ja WebMethod klassid nn annotatsioonid ega tee muud, kui märgivad meie liidese ja selle meetodi veebiteenuseks. Sama kehtib SOAPBinding klassi kohta. Ainus erinevus on see, et SOAPBinding on parameetritega märkus. AT sel juhul stiiliparameetrit kasutatakse väärtusega, mis näitab, et veebiteenus ei hakka tööle mitte dokumendisõnumite kaudu, vaid klassikalise RPC-na, st. meetodi kutsumiseks. Rakendame oma liidese loogikat ja loome oma paketis HelloWebServiceImpl klassi. Muide, märgin ära, et Impl-ga lõppev klass on Javas konventsioon, mille järgi liideste juurutamine on nii määratud (Impl - sõnast implementatsioon, st implementatsioon). See ei ole nõue ja võite vabalt nimetada klassi, mida soovite, kuid head kombed nõuavad seda: pakett ru. javarush. ws; // sama märkus mis liidese kirjeldusel, importida javaxi. jws. veebiteenus; // kuid siin kasutatakse seda parameetriga endpointInterface, // mis näitab meie veebiteenuse liideseklassi täisnime@WebService(endpointInterface= "en.javarush.ws.HelloWebService") avalik klass HelloWebServiceImpl rakendab HelloWebService'i ( @Override public String getHelloString (stringi nimi) ( // lihtsalt tervitus tagasi return "Tere, " + nimi + "!" ; ) ) Käitame oma veebiteenust eraldiseisva serverina, st. ilma Tomcati ja rakendusserverite osaluseta (see on eraldi arutelu teema). Selleks kausta projekti struktuuris src loome paketi ru.javarush.endpoint ja loome selles klassi HelloWebServicePublisher meetodiga main: package ru. javarush. lõpp-punkt; // klass veebiteenustega veebiserveri käivitamiseks importida javaxi. xml. ws. lõpp-punkt; // meie veebiteenuse klass import en. javarush. ws. helloebserviceimpl; public class HelloWebServicePublisher( public static void main(String. . . args)( // käivitage veebiserver pordis 1986 // ja esimeses argumendis määratud aadressil, // käivitage teises argumendis edasi antud veebiteenus lõpp-punkt. avalda ( "http://localhost:1986/wss/hello", uus HelloWebServiceImpl () ); ) ) Nüüd käivitage see klass, klõpsates Tõstuklahv+F10. Konsoolis ei kuvata midagi, kuid server töötab. Saate seda kontrollida, tippides oma brauserisse http://localhost:1986/wss/hello?wsdl. Avatud leht ühelt poolt tõestab, et meie arvutis (localhost) töötab pordil 1986 veebiserver (http://), teisalt aga näitab meie veebiteenuse WSDL kirjeldust. Kui peatate rakenduse, muutub kirjeldus kättesaamatuks, nagu ka veebiteenus ise, seega me seda ei tee, vaid liigume edasi kliendi kirjutamise juurde.Klient
Projekti kaustas src loome paketi ru.javarush.client ja selles klassi HelloWebServiceClient põhimeetodiga: pakett ru. javarush. klient; // vaja wsdl kirjelduse saamiseks ja selle kaudu // jõuda veebiteenusesse ise importida java. net. URL; // selline erand ilmneb URL-i objektiga töötamisel importida java. net. ValformedURLException; // klassid, mida sõeluda xml koos wsdl kirjeldusega // ja sirutuge selles oleva teenusesildi poole importida javaxi. xml. nimeruum. Qname; importida javaxi. xml. ws. teenus; // meie veebiteenuse liides (me vajame rohkem) import en. javarush. ws. helloebteenus; public class HelloWebServiceClient( public static void main(String args) viskab MalformedURLException( // looge link wsdl kirjeldusele url= uus url( "http://localhost:1986/wss/hello?wsdl") ; // Järgmise konstruktori parameetreid vaatame kõige esimeses WSDL-i kirjeldussildis – definitsioonid // vaadake atribuudi targetNamespace esimest argumenti // 2. argument look atribuudis name QName qname = uus QName ("http://ws.site/" , "HelloWebServiceImplService" ) ; // Nüüd jõuame teenuse märgendini wsdl-i kirjelduses, Teenindusteenus= teenus. loo (url, qname) ; // ja seejärel sellesse pesastatud pordisildile, nii et // saada viide meist kaugel asuvale veebiteenuse objektile HelloWebService tere = teenus. getPort(HelloWebService.class) ; // Hurraa! Nüüd saate helistada kaugmeetodile Süsteem. välja. println(tere. getHelloString("JavaRush" ) ) ; ) ) Andsin kirjes olevale koodile maksimaalselt kommentaare. Mul pole midagi lisada, nii et käivitage (Shift + F10). Peaksime nägema konsoolis teksti: Tere, JavaRush! Kui te seda ei näinud, unustasite tõenäoliselt veebiteenuse käivitada.Järeldus
Selle teema raames tehti põgus ekskursioon veebiteenustesse. Jällegi, suur osa sellest, mida ma kirjutasin, on minu oletus selle toimimise kohta ja seetõttu ei tohiks mind liiga palju usaldada. Oleksin tänulik, kui teadlikud inimesed Mind parandatakse, sest siis ma õpin midagi. UPD.Aleksei Boiko
SOAP- ja XML-veebiteenused .Netis
XML-i veebiteenused pakuvad operatsioonisüsteemide osas teatud taset koostalitlusvõimet ja koostalitlusvõimet,
platvormid ja keeled, mis varem lihtsalt polnud saadaval.
Andrew Troelsen (Microsofti MVP kõige väärtuslikum professionaal)
Kui te pole veel XML-i veebiteenustega töötanud, olete ilmselt kuulnud sõna "SOAP". On aeg nende mõistetega tegeleda.
sissejuhatus
Kui olete huvitatud Internetist või väiksematest võrkudest, puutute tõenäoliselt varem või hiljem kokku XML-i veebiteenustega. XML-veebiteenus on midagi enamat kui lihtsalt veebirakendus, mis suudab brauserisse teavet kuvada. Pigem on see kaugtehnoloogia, mis võimaldab standardsete HTTP-päringute abil helistada võrgus oleva objekti meetoditele ja omadustele.
Praktikas tähendab see, et sellise teenuse kliente saab kirjutada erinevates keeltes ja erinevate operatsioonisüsteemide jaoks.
Teenuse ja kliendi vahelise teabe "transpordina" saate kasutada HTTP-meetodit GET või POST.
Ja peale saate "kehtestada" veel ühe protokolli - SOAP (Simple Object Access Protocol). Tavaliselt tehakse seda, kuna sel juhul on võimalik edastada keerulisi tüüpe (sh kasutaja määratletud). Ja klassikalised GET- ja POST-meetodid toetavad ainult loendeid, lihtsaid massiive ja stringe.
SEEBI kommunikatsiooni näide
SOAP-sõnum on HTTP-päringu kehasse paigutatud XML-dokument.
Nimekiri 1. SOAP sõnumi struktuur
Kliendi ja teenuse vaheline suhtlus on järgmine:
- klient vormistab SOAP päringu ja saadab selle teenusele;
- teenus sisse lülitatud kaugarvuti teostab protseduuri ja saadab SOAP-vastuse.
Näiteks võib SOAP-i päring, mis kutsub XML-i kaugveebiteenuse meetodit HelloWorld(), välja näha järgmine:
Nimekiri 2. SEEBI taotluse näidis
Meetod HelloWorld() tagastab ootuspäraselt stringi "Tere maailm!":
Loetelu 3. SEEBI vastuse näidis
Xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
XML-veebiteenuse loomine .NET 2.0-s
Saate luua teenuse erinevaid viise, kasutame Visual Studio 2005. Klõpsake "File -> New -> Web Site", avanevas aknas valige "ASP.NET web Service". Loomisel määratud aadressilt leiate järgmised failid ja kataloogid (vt joonis 1).
Põhimõtteliselt võib teenus sisaldada ainult ühte *.asmx-faili. (Laiendit *.asmx kasutatakse .Neti veebiteenuste tähistamiseks.) Sel juhul see nii ei ole, vaadake faili Service.asmx sisu:
Nimekiri 4. Service.asmx määratleb väline fail toetus
<%@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" class="Service" %>
Atribuut CodeBehind määrab kaustas App_Code asuva välise faili, mis sisaldab HelloWorld() meetodit rakendavat programmikoodi:
Loetelu 5. Fail Service.cs, mis rakendab HelloWorld() meetodit
süsteemi kasutamine;
kasutades System.Web;
kasutades System.Web.Services;
avalik teenistus ()
Tagasi "Tere maailm";
Ilma tugikoodita on võimalik luua üks fail Service.asmx, millel on samad funktsioonid:
Nimekiri 6. Service.asmx ilma välise tugikoodita
<%@ WebService Language="C#" class="Service" %>
süsteemi kasutamine;
kasutades System.Web;
kasutades System.Web.Services;
kasutades System.Web.Services.Protocols;
avaliku klassi teenus: System.Web.Services.WebService
avalik teenistus ()
Avalik string HelloWorld() (
Tagasi "Tere maailm";
Meil pole seda vaja ja me ei tee seda.
Nagu näete, on meie veebiteenuse üksik meetod tähistatud atribuudiga, mis teavitab ASP.NET käituskeskkonda, et see meetod on sissetulevate HTTP-päringute jaoks saadaval. Selle atribuudiga tähistamata liikmed ei ole kliendiprogrammidele saadaval.
Selline lihtne teenus sobib meie katseteks üsna hästi, jääb üle vaid see avaldada.
XML-veebiteenuse avaldamine IIS-i abil
See ei puuduta Internetis avaldamist, vaid tingimuste loomist meie teenuse testimiseks kohalikus arvutis.
Esmalt installige IIS (Interneti teabeserver). Selleks avage aken "Programmide lisamine või eemaldamine" ja valige "Install Windowsi komponendid". (Mõned Windowsi versioonid ei nõua IIS-i installimist, näiteks Windows XP Home Edition.)
Märge: IIS server parem on installida varem kui .Net Framework, vastasel juhul peate utiliidi käivitades konfigureerima IIS-i .Neti rakendusi toetama käsurida aspnet_regiis.exe (koos lipuga /i).
Looge virtuaalne kataloog. Kui kasutate Windows XP Pro, minge "Juhtpaneel -> Haldustööriistad -> Interneti-teabeteenused". Avanevas aknas vali "Action -> Create -> Virtual Directory".
Käivitub virtuaalse kataloogi loomise viisard. Määrake varjunimeks Soap1 ja määrake tee kataloogi, kuhu soovite teenuse paigutada, näiteks C:\Soap1. Nüüd kopeerige sinna meie veebiteenuse sisu.
Tippige oma brauseri aadressiribale http://localhost/soap1/Service.asmx ja te peaksite nägema teenuse testlehte (vt joonis 2).
SOAP-sõnumite vaatamine
Testleht ei luba SOAP-sõnumeid saata ega lugeda. Sel põhjusel peate kasutama kolmanda osapoole arendust, soovitan kasutada soapUI-d. (See on tasuta toode, mis on saadaval aadressil http://www.soapui.org.)
Kui soapUI on installitud, looge uus projekt nimega soap1, jättes välja Algse WSDL-i tühjaks (vt joonis 3).
Paremklõpsake vastloodud projektil ja valige "Lisa WSDL URL-ist". Avanevas dialoogiboksis sisestage http://localhost/soap1/Service.asmx?wsdl. Nüüd on meil võimalus saata oma teenusele SOAP-päringuid ja vaadata saadud vastuseid. (SoapUI genereerib taotlused automaatselt.)
Mis see WSDL on? WSDL-dokument kirjeldab, kuidas kliendid saavad veebiteenusega suhelda. See kirjeldab, millised teenindusmeetodid on väliskõne jaoks saadaval, milliseid parameetreid nad võtavad ja mida tagastavad, samuti muud kaugjuhtimiseks vajalikku teavet. Sellise dokumendi saab koostada käsitsi või usaldada selle genereerimise serverile, selleks piisab *.asmx failile osutava URL-i lisamisest ?wsdl järelliide.
Meie teenuse WSDL-dokumendi vaatamiseks sisestage oma brauserisse http://localhost/soap1/Service.asmx?wsdl. SoapUI kasutab selle dokumendi teavet SOAP-päringute automaatseks genereerimiseks.
SEEBI laiendused
Nagu olete ehk märganud, ei pea te XML-i veebiteenuse (nagu klient) loomiseks muretsema SOAP-sõnumite vormi pärast. Piisab soovitud meetodite märkimisest atribuudiga ja ASP.NET käituskeskkond ise koostab soovitud vormingus paketid.
Joonisel fig. Joonisel 4 on kujutatud soapUI programmi abil saadud veebiteenuse päring ja vastus.
Kordame seda uuesti. Päringu genereerib soapUI - teenusele tõelisi kliente luues ei pea te ka SOAP-pakette käsitsi vormindama. Samuti ei osalenud me otseselt teenindusvastuse loomises. Kõik see toimub automaatselt.
Siiski on tõenäoline, et peate neid pakette ise muutma. Näiteks edastatavate andmete tihendamiseks või krüpteerimiseks. See on SOAP Extensions eesmärk.
SOAP Extensions on mehhanism, mis võimaldab suvaliselt muuta vastuvõetud ja saadetud SOAP-sõnumeid.
SOAP-teate tee
Programmeerimise alustamiseks peame arvestama teed, mida SOAP-sõnum läbib enne selle vastuvõtmist ja vastava meetodiga töötlemist (vt joonis 5).
SOAP-sõnumit võib pidada XML-dokumendiks, mis kirjeldab võrgu kaudu edastatavat objekti. Enne sel viisil läbitud objekti kasutamist tuleb see selle kirjelduse järgi taastada (või soovi korral kokku panna). Seda eesmärki täidab XML-serialiseerija.
Sissetulevad paketid deserialiseeritakse (objekti taastamine XML-kirjeldusest) ja saadetud paketid serialiseeritakse (objekti XML-kirjelduse loomine).
Joonisel fig. Joonisel 5 on näidatud neli punkti (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), kus saame SOAP-laiendite abil SOAP-teate pealt kuulata. Muutke seda ja saatke edasi.
SEEBI laienduse juurutamine
Esmalt defineerime ülesande: oletame, et tahame muuta veebiteenuse saadetud SOAP-pakette, nagu on näidatud loendis 7:
Nimekiri 7. "Vanad" ja uued XML-i veebiteenuste vastused
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"> Šifreeritud tekst
SOAP-laienduse rakendamise tegevuskava:
- Loome dll-i klassiga, mis pärib SoapExtensionilt.
- Lisame prügikasti kausta oma veebiteenusesse ja paneme loodud dll sinna.
- Lisage teenusesse fail web.config ja tehke selles vajalikud muudatused.
bin kausta ja faili web.config rollist tuleb juttu hiljem.
DLL-i loomine SOAP-laiendiga
Looge uus "Klassi raamatukogu" projekt nimega SoapExtensionLib. See projekt peab rakendama ainult ühte klassi, mis teeb meile vajalikke SOAP-pakette. See klass peab olema tuletatud klassist SoapExtension.
Loetelu 8. Klassi loomine, mis pärib SoapExtensionist
süsteemi kasutamine;
kasutades System.Web.Services;
kasutades System.Web.Services.Protocols;
kasutades System.IO;
kasutades System.Neti;
kasutades System.Xml;
Iga SOAP-laiendus võtab parameetrina vastu võrgu kaudu edastatud objekti sisaldava voo (enne või pärast serialiseerimist). Ja peab oja tagasi saatma.
SOAP-laiendit võib pidada "külgribaks", mille saab paigutada ühte või kõigisse neljast punktist (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), mis on näidatud joonisel 2. 5. Selliseid "vahetükke" võib igas punktis olla suvaline arv (vt joonis 6).
Nende voogude hankimiseks kasutage meetodit ChainStream.
Nimekiri 9. ChainStream meetodi rakendamine
avalik klass TraceExtension: SoapExtension
Stream wireStream;
VoogesitusrakendusStream;
// meetod sisendparameetrina
// hangib läbitud objekti sisaldava voo
Avalik alistamine Stream ChainStream (voo voog)
WireStream = voog;
AppStream = new MemoryStream();
tagasta appStream;
…
Punktis BeforeDeserialize sisaldab wireStream võrgust saadud SOAP-päringut. See SOAP-i päring tuleb edastada rakenduse voogu (appStreami voogu).
Ja AfterSerialize punktis peate WireStreamile edastama võrku saadetud SOAP-vastuse, mis asetatakse rakendusse AppStream.
Kõigis neljas punktis lõimedega töötamiseks peate rakendama meetodi ProcessMessage.
Nimekiri 10. ProcessMessage meetodi rakendamine, mis ei muuda SOAP-sõnumeid
// ProcessMessage, mis teeb kohustusliku koopia
// voogesitus kahes punktis (BeforeDeserialize ja AfterSerialize)
Lüliti (sõnum.etapp)
// punktis BeforeDeserialize tuleb läbida
// SOAP-i päring võrguvoost (wireStream)
// rakenduse voogu (appStream)
Case SoapMessageStage.BeforeDeserialize:
Kopeeri(wireStream, appStream);
AppStream.Position = 0;
murda;
// punktis AfterSerialize tuleb läbida
// SOAP-vastus rakenduse lõimest võrgulõimele
AppStream.Position = 0;
murda;
tühine kopeerimine (voogesitamine, voogesitus asukohta)
TextReaderi lugeja = uus StreamReader(from);
TextWriter writer = new StreamWriter(to);
Writer.WriteLine(reader.ReadToEnd());
Writer.Flush();
Loendit 10 võib edasiste katsete jaoks võtta tühjaks. Sellel ProcessMessage meetodi rakendamisel pole mõtet - väljaminevat SOAP-vastust ei muudeta mingil viisil. Parandame selle:
Loetelu 11. SOAP-vastust muutva meetodi ProcessMessage juurutamine
avalik alistamine tühine ProcessMessage (SoapMessage sõnum)
Lüliti (sõnum.etapp)
Case SoapMessageStage.AfterSerialize:
WriteOutput(sõnum);
murda;
// osa koodist lõigatud ruumi säästmiseks
// kirjutage SOAP-vastus ümber
public void WriteOutput (SoapMessage sõnum)
AppStream.Position = 0;
// loo voost XML-dokument
XmlDocument document = new XmlDocument();
Document.Load(appStream);
// XPathi kasutamiseks peate defineerima
// Nimeruumihaldur
XmlNimiruumihaldur nsmgr = new XmlNamespaceManager(document.Nimetabel);
Nsmgr.AddNamespace("seep", "http://schemas.xmlsoap.org/soap/envelope/");
XmlNode ResultNode = document.SelectSingleNode("//soap:Body", nsmgr);
// asendab sõlme sisu
ResultNode.InnerText = "šifreeritud tekst";
// tühjendage voog ja kirjutage sellele uus SOAP-vastus
AppStream.SetLength(0);
AppStream.Position = 0;
Document.Save(appStream);
// VAJALIK TEGEVUS
// edastab SOAP-i vastuse rakenduse voost (appStream)
// võrguvoogu (wireStream)
AppStream.Position = 0;
Copy(appStream, wireStream);
Järgmiseks peame määratlema kaks meetodit (millest üks on ülekoormatud, st seda saab kutsuda erinevate parameetrite komplektidega), mida meie puhul pole vaja. Kuid me peame need määratlema vastavalt pärimisreeglitele klassist SoapExtension.
Loetelu 12. Muud kohustuslikud meetodid
// Pärimisreeglite kohaselt peame
// defineerime need meetodid, kuid me ei kasuta neid mingil moel
avalik alistamise objekt ?
GetInitializer (LogicalMethodInfo methodInfo, SoapExtensionAttribute atribuut)
tagastama null;
avalik alistamise objekt GetInitializer (tüüp WebServiceType)
tagastama null;
avalik alistamine tühine Initialize (objekti lähtestaja)
tagastamine;
Kõik, me koostame projekti. Lõpuks saime SOAP Extension dll. Täielik SoapExtensionLib.dll loend on saadaval ajakirja veebisaidi jaotises Lähtekood.
Veebiteenuse konfigureerimine SOAP-laiendiga töötamiseks
Avage meie XML-veebiteenuse projekt Visual Studio abil uuesti. Klõpsake "Veebisait -> Lisa viide" ja valige varem loodud SoapExtensionLib.dll.
Kaust Bin lisatakse projekti automaatselt. Rakendus viitab automaatselt kaustas Bin asuvatele *.dll-failidele.
Nüüd pange fail Web.Config järgmise sisuga veebiteenuste kataloogi:
Nimekiri 13. Web.Config fail
Prioriteet = "1" Group="0" />
Nüüd näeb meie teenuse struktuur välja selline, nagu on näidatud joonisel fig. 7. Faili Web.Config abil teavitame ASP.NET keskkonda, et oleme lisanud XML Soap Extension veebiteenusele, mis on realiseeritud failis SoapExtensionLi.dll asuvas klassis TraceExtension. Loetelu 14. Web.Config faili jaotis webServices Prioriteet = "1" Group="0" />
Nagu te juba teate, saate teha mitu SOAP-laiendit ja läbitud objekti (enne või pärast serialiseerimist) kandev voog läbib neist igaüks. Järjestus, milles voog läbib erinevaid SOAP-laiendeid, määratakse prioriteedi- ja rühmaatribuutide abil. Väärib märkimist, et sellisel viisil Web.Configi konfigureerides teavitame keskkonda, et meie SOAP-laiendus kutsutakse iga atribuudiga märgitud teenindusmeetodi puhul. Võimalik on luua oma atribuut ja märkida sellega ainult need meetodid, mille jaoks on vaja kutsuda SOAP Extension. Loetelu 15. Kohandatud atribuudi näide avalik string HelloWorld() ( Tagasi "Tere maailm"; Selleks lisage faili SoapExtensionLi.dll failist SoapExtensionAttribute päritud klass (vt joonis 8). Järeldus See artikkel kajastab XML-i veebiteenuste loomise ja toimimise põhipunkte .Neti platvormil. Loodan, et esitatud materjalist piisab, et saaksite vajadusel teemat põhjalikumalt uurida. Kokkupuutel
