Attīstoties internetam, ir radusies nepieciešamība izveidot izplatītas lietojumprogrammas. Datorā instalētās lietojumprogrammas parasti izmanto tajā esošās bibliotēkas. Vairākas programmas var izmantot vienu bibliotēku. Vai bibliotēku analogus var ievietot internetā, lai dažādas vietnes varētu tos izsaukt? Izrādās, jā.
Uzņēmumi savās lapās sniedz dažādu informāciju. Piemēram, savā vietnē http://www.Ford.com uzņēmums Ford publicē informāciju par modeļiem un cenām. Šī uzņēmuma izplatītājs vēlētos, lai šī informācija būtu arī viņa tīmekļa vietnē. Tīmekļa pakalpojums ļauj patērētāja vietnei izgūt informāciju no pakalpojumu sniedzēja vietnes. Patērētāju vietne šo informāciju parāda savās lapās. Kods šīs informācijas ģenerēšanai tiek uzrakstīts vienreiz, taču to var izmantot daudzi patērētāji. Dati tiek parādīti vienkāršā tekstā, tāpēc tos var izmantot neatkarīgi no platformas.
Tīmekļa pakalpojumi tiek plaši izmantoti gan darbvirsmas, gan interneta lietojumprogrammās. Tās nav pašas lietojumprogrammas, bet gan lietojumprogrammu datu avoti. Viņu trūkst lietotāja interfeiss... Tīmekļa pakalpojumi nav jāizmanto tīklā — tie var būt daļa no projekta, kurā tie tiek izmantoti.
Tīmekļa pakalpojumi ir funkcionalitāte un dati, kas paredzēti izmantošanai ārējām lietojumprogrammām, kas mijiedarbojas ar pakalpojumiem, izmantojot standarta protokolus un datu formātus. Tīmekļa pakalpojumi ir pilnībā neatkarīgi no valodas un platformas. Tīmekļa pakalpojumu tehnoloģija ir Microsoft programmēšanas modeļa stūrakmens. TĪKLS.
Šis tālākai attīstībai komponentu programmēšana CORBA un DCOM. Taču, lai izmantotu šādas sastāvdaļas, tās ir jāreģistrē patērētāja sistēmā. Tas nav nepieciešams tīmekļa pakalpojumiem. Komponenti labi darbojas lokālajos tīklos. HTTP nav attālās procedūras izsaukuma (RPC) protokols. Pat vienas organizācijas ietvaros, atšķirīgi OS kas var sazināties tikai, izmantojot HTTP.
Ir veikti vairāki mēģinājumi izveidot saziņas valodu starp heterogēnām sistēmām - DCOM, CORBA, RMI, IIOP. Tie nesaņēma vispārēju izplatīšanu, jo katru no tiem reklamēja dažādi ražotāji un tāpēc tie bija saistīti ar konkrēta ražotāja tehnoloģijām. Neviens negribēja pieņemt kāda cita standartu. Lai pārvarētu šo dilemmu, vairāki uzņēmumi ir vienojušies izstrādāt piegādātāju ziņā neitrālu standartu ziņojumapmaiņai, izmantojot HTTP. 2000. gada maijā IBM, Microsoft, HP, Lotus, SAP, UserLand un citi vērsās pie W3C un izvirzīja SOAP kā kandidātu šādam standartam. SOAP radīja apvērsumu lietojumprogrammu izstrādē, apvienojot divus interneta standartus - HTTP un XML.
ZIEPES
Lai mijiedarbotos ar tīmekļa pakalpojumiem, tiek izmantots uz XML balstīts SOAP protokols. Jūs varētu izmantot tikai XML, taču tas ir pārāk brīvs formāts, kurā katrs dokuments faktiski veido savu valodu. ZIEPES ir konvencija par XML dokumenta formātu, par noteiktu elementu un nosaukumvietu klātbūtni tajā.
SOAP ļauj publicēt un patērēt sarežģītas datu struktūras, piemēram, datu kopu. Tajā pašā laikā to ir viegli iemācīties. Pašreizējā versija ZIEPES - 1.2.
SOAP apzīmē vienkāršu objektu piekļuves protokolu. SOAP ir izstrādāts, lai atvieglotu lietojumprogrammu saziņu, izmantojot HTTP. Tas ir īpašs no platformas neatkarīgs ziņojumapmaiņas formāts internetā. SOAP ziņojums ir parasts XML dokuments. Standarta
Liriskā daļa.
Iedomājieties, ka esat ieviesis vai tiek ieviesta noteikta sistēma, kurai vajadzētu būt pieejamai no ārpuses. Tie. ir noteikts serveris, ar kuru jums ir jāsazinās. Piemēram, tīmekļa serveris.
Šis serveris var veikt daudzas darbības, strādāt ar datu bāzi, veikt dažus trešo pušu pieprasījumus citiem serveriem, veikt kaut kādus aprēķinus utt. dzīvot un, iespējams, attīstīties pēc viņa labi zināmā scenārija (t.i., pēc izstrādātāju scenārija). Cilvēks nav ieinteresēts sazināties ar šādu serveri, jo viņš var nespēt / nevēlēties dot skaistas lapas ar attēliem un citu lietotājam draudzīgu saturu. Tas ir rakstīts un darbojas, lai strādātu un izsniegtu tai datus uz pieprasījumiem, nerūpējoties, ka tie ir cilvēkiem lasāmi, klients ar tiem tiks galā pats.
Citas sistēmas, atsaucoties uz šo serveri, ar no šī servera saņemtajiem datiem jau var rīkoties pēc saviem ieskatiem – apstrādāt, uzkrāt, izsniegt saviem klientiem utt.
Viena no iespējām sazināties ar šādiem serveriem ir SOAP. SOAP xml ziņojumapmaiņas protokols.
Praktiskā daļa.
Tīmekļa pakalpojums (to nodrošina serveris un ko izmanto klienti) ļauj sazināties ar serveri skaidri strukturētos ziņojumos. Fakts ir tāds, ka tīmekļa pakalpojums nepieņem nekādus datus. Uz jebkuru ziņojumu, kas neatbilst noteikumiem, tīmekļa pakalpojums atbildēs ar kļūdu. Kļūda, starp citu, būs arī xml formātā ar skaidru struktūru (kas gan neatbilst patiesībai ziņojuma tekstā).
WSDL (Web Services Description Language). Noteikumi, pēc kuriem tiek apkopoti ziņojumi tīmekļa pakalpojumam, ir aprakstīti tādā pašā veidā izmantojot xml un tiem ir arī skaidra struktūra. Tie. ja tīmekļa pakalpojums nodrošina iespēju izsaukt metodi, tam ir jāinformē klienti, kādi parametri tiek izmantoti šai metodei. Ja tīmekļa pakalpojums kā parametru sagaida metodi Method1 virkni un virknei jābūt nosauktai Param1, šie noteikumi tiks norādīti tīmekļa pakalpojuma aprakstā.
Kā parametrus var nodot ne tikai vienkāršus tipus, bet arī objektus, objektu kolekcijas. Objekta apraksts tiek reducēts līdz katras objekta sastāvdaļas aprakstam. Ja objekts sastāv no vairākiem laukiem, tad katram laukam ir aprakstīts kāds tips, nosaukums (kādas iespējamās vērtības). Lauki var būt arī kompleksa tipa un tā tālāk, līdz tipu apraksts beidzas ar vienkāršiem - virkne, Būla, skaitlis, datums... Tomēr daži konkrēti veidi var izrādīties vienkārši, svarīgi, lai klienti varētu saprast, kādas vērtības tajos var ietvert.
Klientiem pietiek zināt tīmekļa pakalpojuma url, tur vienmēr būs wsdl, pēc kura var gūt priekšstatu par metodēm un to parametriem, ko šis tīmekļa pakalpojums nodrošina.
Kādas ir visu šo zvanu un svilpienu priekšrocības:
- Lielākajā daļā sistēmu metožu un veidu apraksts notiek automātiskais režīms... Tie. pietiek, ja programmētājs uz servera to pasaka šī metode var izsaukt, izmantojot tīmekļa pakalpojumu, un wsdl apraksts tiks ģenerēts automātiski.
Automātiska apstiprināšana.
- xml validācija. xml ir jābūt labi izveidotam. nederīgs xml - nekavējoties kļūda klientam, ļaujiet viņam to izdomāt.
- shēmas validācija. xml ir jābūt noteiktai struktūrai. xml neatbilst shēmai - uzreiz kļūda klientam, lai saprot.
- datu validāciju veic ziepes-serveris, lai datu tipi, ierobežojumi atbilstu aprakstam.
- Var ieviest autorizāciju un autentifikāciju atsevišķa metode... natively. vai izmantojot http autorizāciju.
- Tīmekļa pakalpojumi var darboties gan, izmantojot ziepju protokolu, gan http, tas ir, izmantojot saņemšanas pieprasījumus. Tas ir, ja parametri ir vienkārši dati (bez struktūras), tad varat vienkārši izsaukt parasto get www.site.com/users.asmx/GetUser?Name=Vasia vai post. Tomēr tas nav visur un ne vienmēr.
- ... skaties wikipedia
Labi strukturētu aprakstu var izlasīt jebkurš ziepju klients. Tie. Neatkarīgi no tīmekļa pakalpojuma klients sapratīs, kādus datus tīmekļa pakalpojums pieņem. Saskaņā ar šo aprakstu klients var izveidot savu iekšējo objektu klašu struktūru, t.s. saistošs "un. Rezultātā programmētājam, kas izmanto tīmekļa pakalpojumu, ir jāieraksta kaut kas līdzīgs (pseidokods):
NewUser: = TSoapUser.Create ("Vasya", "Pupkin", "odmin"); ziepes.AddUser (NewUser);
Ir arī daudz mīnusu:
- Nepamatoti liels ziņojuma izmērs. Nu šeit jau pati xml būtība ir tāda, ka formāts ir lieks, jo vairāk tagu, jo vairāk nederīgas informācijas. Turklāt ziepes palielina savu atlaišanu. Iekštīkla sistēmām trafika problēma ir mazāk aktuāla nekā internetam, tāpēc ziepes par lokālie tīkli vairāk pieprasīts, jo īpaši Sharepoint ir ziepju tīmekļa pakalpojums, ar kuru jūs varat veiksmīgi (un ar dažiem ierobežojumiem) sazināties.
- Automātiska tīmekļa pakalpojuma apraksta maiņa var sabojāt visus klientus. Nu, tas ir kā jebkurai sistēmai, ja netiek atbalstīta atgriezeniskā savietojamība ar vecajām metodēm, viss nokritīs ...
- Nevis mīnuss, bet mīnuss. Visām metožu izsaukšanas darbībām jābūt kodolīgām. Piemēram, strādājot ar apakšnodaļu, mēs varam sākt darījumu, izpildīt vairākus pieprasījumus, pēc tam veikt atcelšanu vai apņemšanos. Nav darījumu ar ziepēm. Viens pieprasījums, viena atbilde, saruna beigusies.
- Var būt diezgan grūti saprast aprakstu par to, kas atrodas servera pusē (vai es visu pareizi aprakstīju?), Kas ir uz klienta (kas man šeit bija rakstīts?). Bija vairākas reizes, kad man nācās saskarties ar klienta pusi un pārliecināt servera programmētāju, ka viņa dati ir nepareizi aprakstīti, un viņš vispār neko nevarēja saprast, jo automātiskā ģenerēšana un viņam it kā nevajadzētu, tas ir programmatūras bizness. Un kļūda dabiski bija metodes kodā, programmētājs to vienkārši neredzēja.
- Prakse rāda, ka tīmekļa pakalpojumu izstrādātāji ir šausmīgi tālu no cilvēkiem, kuri izmanto šos tīmekļa pakalpojumus. Atbildot uz jebkuru pieprasījumu (derīgs no ārpuses), var parādīties nesaprotama kļūda "Kļūda 5. Viss ir slikti". Viss atkarīgs no izstrādātāju sirdsapziņas :)
- Laikam vēl joprojām kaut ko neesmu atcerējusies...
Piemēram, atvērtais tīmekļa pakalpojums belavia:
- http://86.57.245.235/TimeTable/Service.asmx - ieejas punkts, ir arī teksta apraksts par metodēm trešo pušu izstrādātājiem.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl saņemto un atgriezto datu metožu un veidu apraksts.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - konkrētas metodes apraksts ar xml pieprasījuma un xml atbildes piemēru.
Varat manuāli izveidot un nosūtīt pieprasījumu, piemēram:
POST /TimeTable/Service.asmx HTTP / 1.1 Host: 86.57.245.235 Content-Type: text / xml; charset = utf-8 Content-Length: garums SOAPAction: "http://webservices.belavia.by/GetAirportsList"
atbilde nāks:
HTTP / 1.1 200 OK Datums: Pirmdiena, 2013. gada 30. septembris 00:06:44 GMT Serveris: Microsoft-IIS / 6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Kešatmiņas kontrole: privāta, maks. -age = 0 Satura veids: teksts / xml; rakstzīmju kopa = utf-8 Satura garums: 2940
Shl Iepriekš tika atvērts Aeroflot tīmekļa pakalpojums, taču pēc tam, kad 1C pievienoja ziepju atbalstu 8k, vairāki 1c beta testētāji to veiksmīgi nolika. Tagad tur kaut kas ir mainījies (adreses nezinu, var meklēt, ja interesē).
ZZY Atruna. Viņš man teica mājsaimniecības līmenī. Jūs varat spert.
Atruna:Par šo tēmu ir rakstīts daudz rakstu, un, kā jūs, protams, uzminējāt, šis ir nākamais. Varbūt jūs no tā uzzināsit kaut ko jaunu, taču šeit nav aprakstīts nekas īpaši slepens, ko pats nevarētu Google. Tikai piezīmes no personīgās pieredzes.
Ievads
Mēs izskatīsim tikai situāciju, kad ir trešās puses tīmekļa pakalpojums un uzdevums ir izveidot datu apmaiņu.
Pakalpojuma struktūra ir aprakstīta failā WSDL(Tīmekļa pakalpojumu apraksta valoda angļu valodā)
Fails visbiežāk ir pieejams no saites, kur atrodas paša tīmekļa pakalpojuma ieejas punkts. Es rakstīju "visbiežāk", jo ir izņēmumi. Piemēram, uz SAP balstīts tīmekļa pakalpojums nepublicē wsdl, un to var iegūt, tikai izlādējot to no pašas lietojumprogrammas.
Un tā, mums ir tīmekļa pakalpojuma apraksts, pieteikšanās, parole. Sazināsimies.
// Definējiet URLServiceNameSpace iestatījumus = "http://Somesite.ru"; UserName = "TestUser"; Parole = "q1w2e3"; LocationWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "SomeServiceName"; ConnectionPointName = "SomeService_Port"; // Izveidot SSL savienojumu = New SecureConnection OpenSSL (); WSDefinition = jauna WSDdefinīcija (LocationWSDL, SSL); WSProxy = jauns WSProxy (WSDefinition, ServiceNameSpace URL, ServiceName, ConnectionPointName, SSL); WSProxy.User = Lietotājvārds; WSProxy.Password = Parole;
labi! Mēs esam izveidojuši savienojumu ar tīmekļa pakalpojumu! Teorētiski tas ir jebkuras maiņas iespējas pamatā, jo tas ļauj jums izveidot datu struktūras objekts pamatojoties uz wsdl, un strādāt ar šādu objektu ir prieks.
Apsveriet XML, ko mums sniedz SoapUI
Tagad aprakstīsim to programmatiski
// Izveidojiet objektu un aizpildiet to ar datiem XDTOFactory = WSDefinition.XDTOFactory; RootType = CustomXDTO.Type (ServiceNameSpace URL, "IESNIEGŠANA"); RootObject = MyXDTOFactory.Create (RootType); RootObject.ID = "4356"; ClientType = CustomXDTO.Type (ServiceNameSpace URL, "KLIENTS"); ClientObject = OwnXDTOFactory.Create (ClientType); ClientObject.CLIENT_ID = "121212"; ClientObject.SEX = "M"; // F — sieviete, M — vīrietis ClientObject.CLIENT_BIRTHDAY = "19900111"; // Klientu automašīnas 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);
Dati ir veiksmīgi aizpildīti. Tagad jums tie ir jānosūta.
Tieši šajā brīdī rodas daudzas nianses. Mēģināsim izskatīt katru.
Recepte 1. Visa XDTO objekta nosūtīšana
Rezultāts = WSProxy.AddCustomers (RootObject);
Atliek tikai apstrādāt rezultātu, ka pakalpojums mums atgriezās un viss. Piekrītu, ka tas ir ļoti ērti!
Bet praksē tas ne vienmēr notiek. Piemēram, 1c netiek galā ar noteiktu tagu prefiksu pievienošanu iekš xml, ja saknes taga nosaukumvieta atšķiras no pakārtotajiem tagiem. Šādos gadījumos ziepes ir jāsavāc manuāli. Man nācās saskarties arī ar tīmekļa pakalpojumiem, kas gaida tīru xml kā parametru. Ārprāts, bet tomēr tas nav pārāk grūti.
2. recepte. Clean xml nosūtīšana kā parametrs
XMLWriteParameters = jauni XMLWriterParameters ("UTF-8", "1.0", True); MyXML = jauns XML ieraksts; MyXML.SetString (XMLWriter opcijas); MyXML.WriteXMLDeclaration (); MyXDTOFactory.WriteXML (MyXML, RootObject); XML virkne = MyXML.Close (); If DeleteNamespaceDescription Then Attempt FirstTagVSrow = StrGetString (XMLString, 2); RootTagName = RootObject.Type (). Nosaukums; XMLString = StringReplace (XMLString, FirstTagVS virkne, "<"+ИмяКорневогоТэга+">"); Izņēmums // DescriptionErrors () EndTry; EndIf; Result = WSProxy.AddCustomers (XML virkne);
Ja nenoņemsit nosaukumvietu, ko 1c pievieno pēc noklusējuma, tā ir kļuvusi par vairāk nekā 5 koda rindiņām. Biežāk es iesaiņoju xml konversiju funkcijā, jo parasti izsaucu vairākas metodes.
3. recepte. Vietējā HTTP pieprasījuma nosūtīšana.
StringSOAP = "Šajā gadījumā mums būs jāsavāc ziepes manuāli. Faktiski mēs vienkārši iesaiņojam xml no 2. receptes ziepju čaulā, kur atkarībā no tīmekļa servisa prasībām varam mainīt savas ziepes, kā mums patīk.
Tālāk mēs aprakstam galvenes saskaņā ar dokumentāciju. Daži servisi mierīgi sakošļās mūsu pieprasījumu bez galvenēm, šeit jāskatās konkrēts gadījums. Ja nezināt, kādas galvenes rakstīt, vienkāršākais veids ir izspiegot pieprasījumu SoapUI, pārejot uz cilni RAW.
Base64 virknes iegūšanas funkcija izskatās šādi (izspiegot):
Funkcija GetBase64AuthorizationHeader (lietotājvārds, parole) FileCoding = TextCode.UTF8; TemporaryFile = GetTemporaryFileName (); Ieraksts = jauns teksta ieraksts (TemporaryFile, FileCode); Record.Record (lietotājvārds + ":" + parole); Ierakstīt.Aizvērt (); DWData = jauni bināri dati (TemporaryFile); Rezultāts = Base64String (DWData); DeleteFiles (TemporaryFile); Rezultāts = vid. (rezultāts, 5); Atmaksas rezultāts; EndFunction
Ir svarīgs punkts. Strādājot ar HTTPConnection, norādiet adresi, nenorādot protokolus "http: //" un "https: //", pretējā gadījumā jūs riskējat tērēt laiku, meklējot acīmredzamu kļūdu.
4. recepte. Sūtīšana, izmantojot WinHttpRequest
WinHttp = jauns COMObject ("WinHttp.WinHttpRequest.5.1"); WinHttp.Option (2, "UTF-8"); WinHttp.Option (4, 13056); // intSslErrorIgnoreFlag WinHttp.Option (6, true); // blnEnableRedirects WinHttp.Option (12, patiess); // blnEnableHttpsToHttpRedirects WinHttp.Open ("POST", "https://Somesite.ru/WebService/Some/GetCustomer", 0); WinHttp.SetRequestHeader ("Content-type", "text / xml"); WinHttp.SetCredentials (lietotājvārds, parole, 0); WinHttp.Send (String SOAP); WinHttp.WaitForResponse (15); XMLResponse = WinHttp.ResponseText ();Šeit būtībā tas pats, kas iepriekšējā versijā, bet mēs strādājam ar COM objektu. Mēs norādām savienojuma virkni pilnībā kopā ar protokolu. Īpaša uzmanība jāpievērš tikai ignorēt SSL sertifikāta kļūdu karogus. Tie ir nepieciešami, ja strādājam ar SSL, bet bez īpaša sertifikāta, jo šajā opcijā nav iespējams izveidot jaunu drošu savienojumu (vai es nezinu, kā). Pārējais mehānisms ir līdzīgs iepriekšējam.
Tāpat papildus "WinHttp.WinHttpRequest.5.1" varat izmantot "Microsoft.XMLHTTP", "Msxml2.XMLHTTP", "Msxml2.XMLHTTP.3.0", "Msxml2.XMLHTTP.6.0", ja pēkšņi tas neaizņem. izslēgts pakalpojumā WinHttp. Metodes ir gandrīz vienādas, atšķiras tikai parametru skaits. Man ir aizdomas, ka viena no šīm opcijām ir iekodēta objektā 1c HTTPRequest.
Šobrīd šīs ir visas receptes, kas man ir. Ja tikšu pie jauniem, noteikti papildināšu rakstu.
Rezultāta apstrāde
1. receptē mēs visbiežāk iegūstam gatavu XDTO objektu un strādājam ar to kā ar struktūru. Visos citos gadījumos varat pārveidot xml atbildi par XDTO
Ja Result.StatusCode = 200, tad XMLReader = Jauns XMLReader; ReadXML.SetString (Result.GetBodyAsString ()); ObjectResponse = OwnXDTOFactory.ReadXML (ReadXML); Pārskats (ObjectResponse.Body.Response.RESPONSE_ID); Pārskats (ObjectResponse.Body.Response.RESPONSE_TEXT); EndIf;
Šeit viss ir vienkārši.
Secinājuma vietā
1. Sāciet darbu ar tīmekļa pakalpojumiem, izmantojot programmu SoapUI. Tas ir paredzēts šādam darbam un ļaus ātri saprast, kā darbojas konkrētais pakalpojums. Apgūšanai ir raksts
2. Ja veicat apmaiņu ar pakalpojumu, izmantojot nedrošu http kanālu un rodas jautājums, ko tieši 1c sūta jūsu ziņojumos, varat izmantot satiksmes sniffers, piemēram, Wireshark, Fiddler un citus. Problēma radīsies tikai tad, ja izmantojat SSL savienojumu.
3. Ja tomēr tīmekļa pakalpojums sazinās caur https, tad mēs uz attālās mašīnas (jebkura, galvenais nav uz mūsu pašu) ievietojam Nginx serveri, ar kuru mēs sazināsimies, un tas, savukārt, iepakos visu https un nosūtiet kur nepieciešams ( apgrieztais starpniekserveris ) un pievienojiet standarta konfigurācijai:
Serveris (klausieties 0.0.0.0:8080; servera_nosaukums MyServer; atrašanās vieta ~. * (Proxy_pass https://Somesite.ru:8001; proxy_set_header Host $ host; proxy_set_header Autorizācija "Pamata
5. Ja autentifikācija ietver sīkdatņu izmantošanu, tika konstatēts sekojošais
P.S. Ja jums ir jautājumi, ieteikumi koda uzlabošanai, jums ir savas receptes, kas atšķiras no aprakstītajām, esat atradis kļūdas vai domājat, ka autors ir "smuks" un viņam "nav vietas 1c", tad rakstiet komentārus un mēs visu apspriedīs.
Tēmas nosaukums patiešām ir jautājums, jo Es pats nezinu, kas tas ir, un pirmo reizi mēģināšu ar to strādāt šī raksta ietvaros. Vienīgais, ko varu garantēt, ka zemāk esošais kods darbosies, bet manas frāzes būs tikai pieņēmumi un minējumi par to, kā es pats to visu saprotu. Tātad iesim...
Ievads
Mums jāsāk ar to, kam tika radīta tīmekļa pakalpojumu koncepcija. Līdz šī koncepta parādīšanās brīdim pasaulē jau pastāvēja tehnoloģijas, kas ļāva aplikācijām mijiedarboties no attāluma, kur viena programma varēja izsaukt kādu metodi citā programmā, kuru varēja palaist datorā, kas atrodas citā pilsētā vai pat valstī. Tas viss ir saīsināts kā RPC (Remote Procedure Calling). Piemēri ietver CORBA tehnoloģijas un Java — RMI (Remote Method Invoking). Un tajos it kā viss ir labi, it īpaši CORBA, tk. ar to var strādāt jebkurā programmēšanas valodā, bet kaut kā tomēr pietrūka. Es uzskatu, ka CORBA trūkums ir tas, ka tas darbojas, izmantojot dažus no tiem tīkla protokoli vienkārša HTTP vietā, kas pārmeklēs jebkuru ugunsmūri. Tīmekļa pakalpojuma ideja bija izveidot RPC, kas ielīmētu HTTP paketes. Tā sākās standarta izstrāde. Kādi ir šī standarta pamatjēdzieni:- ZIEPES... Pirms attālinātās procedūras izsaukšanas jums ir jāapraksta šis izsaukums XML fails e SOAP formāts. SOAP ir vienkārši viens no daudzajiem XML marķējumiem, ko izmanto tīmekļa pakalpojumos. Viss, ko mēs vēlamies kaut kur nosūtīt, izmantojot HTTP, vispirms tiek pārvērsts par XML SOAP aprakstu, pēc tam tiek ievietots HTTP paketē un nosūtīts uz citu datoru tīklā, izmantojot TCP / IP.
- WSDL... Ir interneta serviss t.i. programma, kuras metodes var izsaukt attālināti. Bet standarts prasa šai programmai pievienot aprakstu, kurā teikts, ka "jā, jūs nekļūdāties - tas tiešām ir tīmekļa serviss un no tā var izsaukt tādas tādas metodes." Šis apraksts ir attēlots ar citu XML failu, kam ir cits formāts, proti, WSDL. Tie. WSDL ir tikai XML apraksta fails tīmekļa pakalpojumam un nekas cits.
Vispārēja pieeja
Tīmekļa pakalpojumiem vienmēr ir klients un serveris. Serveris ir mūsu tīmekļa pakalpojums, un to dažreiz sauc par beigu punktu (piemēram, galapunktu, uz kuru tiek nosūtīti SOAP ziņojumi no klienta). Mums ir jāveic šādas darbības:- Aprakstiet mūsu tīmekļa pakalpojuma saskarni
- Ieviesiet šo saskarni
- Sāciet mūsu tīmekļa pakalpojumu
- Uzrakstiet klientu un attālināti izsauciet nepieciešamo tīmekļa pakalpojuma metodi
Serveris
Sāksim IDEJU un radīsim jauns projekts Izveidot jaunu projektu... Ievadīsim vārdu HelloWebService un nospiediet pogu Nākamais, pēc tam pogu Pabeigt... Mapē src izveidot paketi ru.javarush.ws... Šajā pakotnē mēs izveidosim HelloWebService saskarni: pakotne ru. javarush. ws; // tās ir anotācijas, t.i. veids, kā atzīmēt mūsu klases un metodes, // saistībā ar tīmekļa pakalpojumu tehnoloģiju importēt javax. jws. WebMethod; importēt javax. jws. WebService; importēt javax. jws. ziepes. ziepju iesiešana; // mēs sakām, ka mūsu saskarne darbosies kā tīmekļa pakalpojums@WebService // sakiet, ka tīmekļa pakalpojums tiks izmantots metožu izsaukšanai@SOAPBinding (stils = SOAPBinding. Stils. RPC) publiskā saskarne HelloWebService ( // mēs sakām, ka šo metodi var izsaukt attālināti@WebMethod publiskā virkne getHelloString (virknes nosaukums); ) Šajā kodā WebService un WebMethod klases ir tā sauktās anotācijas un nedara neko citu, kā tikai atzīmē mūsu saskarni un tā metodi kā tīmekļa pakalpojumu. Tas pats attiecas uz SOAPBinding klasi. Vienīgā atšķirība ir tā, ka SOAPBinding ir parametru anotācija. V šajā gadījumā stila parametrs tiek lietots ar vērtību, kas saka, ka tīmekļa pakalpojums darbosies nevis caur dokumentu ziņojumiem, bet gan kā klasiskais RPC, t.i. lai izsauktu metodi. Ieviesīsim mūsu saskarnes loģiku un savā pakotnē izveidosim HelloWebServiceImpl klasi. Starp citu, es atzīmēju, ka Impl klases beigas ir Java konvencija, saskaņā ar kuru saskarņu ieviešana tiek apzīmēta šādā veidā (Impl - no vārda implementācija, t.i. implementācija). Tā nav obligāta prasība, un jūs varat brīvi nosaukt klasi, kā vēlaties, taču labas formas noteikumi to prasa: pack ru. javarush. ws; // tā pati anotācija, kas aprakstot saskarni, importēt javax. jws. WebService; // bet šeit izmantots ar parametru endpointInterface, // norādot mūsu tīmekļa pakalpojuma saskarnes pilnībā kvalificēto klases nosaukumu@WebService (endpointInterface = "ru.javarush.ws.HelloWebService") publiskā klase HelloWebServiceImpl ievieš HelloWebService (@Override public String getHelloString (virknes nosaukums) // vienkārši atdod sveicienu atgriezties "Sveiki," + vārds + "!" ; )) Sāksim mūsu tīmekļa pakalpojumu kā neatkarīgu serveri, t.i. neiesaistot nekādus Tomcat un aplikāciju serverus (šī ir atsevišķas diskusijas tēma). Lai to izdarītu, projekta struktūrā mapē src izveidosim pakotni ru.javarush.endpoint un tajā izveidosim HelloWebServicePublisher klasi ar galveno metodi: pack ru. javarush. galapunkts; // klase, lai palaistu tīmekļa serveri ar tīmekļa pakalpojumiem importēt javax. xml. ws. galapunkts; // mūsu tīmekļa pakalpojuma klase importa ru. javarush. ws. HelloWebServiceImpl; publiskā klase HelloWebServicePublisher (publisks static void main (String... args) ( // startējiet tīmekļa serveri portā 1986 // un adresē, kas norādīta pirmajā argumentā, // sākt otrajā argumentā nodoto tīmekļa pakalpojumu Gala punkts. publicēt ( "http:// localhost: 1986 / wss / sveiki", jauns HelloWebServiceImpl ()); )) Tagad palaidīsim šo klasi, noklikšķinot Shift + F10... Konsolē nekas neparādās, bet serveris darbojas. To var pārbaudīt, pārlūkprogrammā ierakstot rindiņu http:// localhost: 1986 / wss / hello? Wsdl. Lapa, kas tiek atvērta, no vienas puses, pierāda, ka mūsu datorā (localhost) ir startējis tīmekļa serveris (http: //) ar portu 1986, un, no otras puses, parāda mūsu tīmekļa pakalpojuma WSDL aprakstu. Ja apturēsiet lietojumprogrammu, apraksts kļūs nepieejams, kā arī pats tīmekļa pakalpojums, tāpēc mēs to nedarīsim, bet turpināsim rakstīt klientam.Klients
Projekta mapē src izveidojiet pakotni ru.javarush.client un tajā HelloWebServiceClient klasi ar galveno metodi: pakotne ru. javarush. klients; // nepieciešams, lai iegūtu wsdl aprakstu un caur to // sasniedz pašu tīmekļa pakalpojumu importēt javu. tīkls. URL; // šāda izpilde notiks, strādājot ar URL objektu importēt javu. tīkls. MalformedURLException; // klases, lai parsētu xml-ku ar wsdl aprakstu // un sasniedziet tajā esošo pakalpojuma tagu importēt javax. xml. nosaukumvieta. QName; importēt javax. xml. ws. Apkalpošana; // mūsu tīmekļa pakalpojuma saskarne (mums ir nepieciešams vairāk) importa ru. javarush. ws. HelloWebService; publiskā klase HelloWebServiceClient (public static void main (String args) izmet MalformedURLException ( // izveido saiti uz wsdl aprakstu URL URL= jauns URL ( "http: // localhost: 1986 / wss / sveiks? wsdl") ; // Mēs skatāmies uz nākamā konstruktora parametriem WSDL apraksta pašā pirmajā tagā - definīcijas // skatiet 1. argumentu atribūtā targetNamespace // skatiet 2. argumentu atribūtā name QName qname = jauns QName ("http: //ws.site/", "HelloWebServiceImplService"); // Tagad mēs varam sasniegt pakalpojuma tagu wsdl aprakstā, Servisa serviss= Serviss. izveidot (url, qname); // un pēc tam līdz ligzdotajam porta tagam, lai // iegūt saiti uz tīmekļa pakalpojumu objektu, kas atrodas attālināti no mums HelloWebService sveiki = pakalpojums. getPort (HelloWebService. klase); // Urā! Tagad jūs varat izsaukt attālo metodi Sistēma. ārā. println (sveiki. getHelloString ("CodeGym")); )) Es sniedzu maksimālos komentārus par kodu sarakstā. Man nav ko piebilst, tāpēc palaist (Shift + F10). Mums vajadzētu redzēt tekstu konsolē: Sveiki, CodeGym! Ja jūs to neredzējāt, iespējams, esat aizmirsis palaist tīmekļa pakalpojumu.Secinājums
Šajā tēmā tika prezentēta īsa ekskursija uz tīmekļa pakalpojumiem. Atkal liela daļa no tā, ko esmu uzrakstījis, ir mans minējums par to, kā tas darbojas, un tāpēc tam nevajadzētu pārāk uzticēties. Es būtu pateicīgs, ja zinoši cilvēki viņi mani izlabos, jo tad es kaut ko iemācīšos. UPD.Aleksejs Boiko
SOAP un XML tīmekļa pakalpojumi .Net platformā
XML Web Services piedāvā šāda līmeņa saderību un savietojamību starp operētājsistēmām,
platformas un valodas, kas iepriekš vienkārši nebija pieejamas.
Endrjū Troelsens (MVP (Microsoft Microsoft vērtīgākais profesionālis))
Ja vēl neesat strādājis ar XML tīmekļa pakalpojumiem, droši vien esat dzirdējis vārdu “SOAP”. Ir pienācis laiks tikt galā ar šiem jēdzieniem.
Ievads
Ja jūs interesē internets vai mazāki tīkli, iespējams, ka agrāk vai vēlāk saskarsities ar XML Web Services. XML tīmekļa pakalpojums nav tikai tīmekļa lietojumprogramma, kas var izvadīt informāciju pārlūkprogrammā. Drīzāk tā ir attālināta tehnoloģija, kas ļauj tīklā izmantot objekta metodes un īpašības, izmantojot standarta HTTP pieprasījumus.
Praksē tas nozīmē, ka šāda pakalpojuma klienti var tikt rakstīti dažādās valodās un dažādām operētājsistēmām.
Kā informācijas "transportu" starp pakalpojumu un klientu varat izmantot HTTP GET vai POST metodes.
Un jūs varat "pārklāt" vēl vienu protokolu - SOAP (Simple Object Access Protocol). Parasti tas tiek darīts, jo šajā gadījumā ir iespējams nodot sarežģītus tipus (ieskaitot lietotāja definētus). Un klasiskās GET un POST metodes atbalsta tikai sarakstus, vienkāršus masīvus un virknes.
Piemērs SOAP Interop
SOAP ziņojums ir XML dokuments, kas iesaiņots HTTP pieprasījuma pamattekstā.
Saraksts 1. SOAP ziņojuma struktūra
Mijiedarbība starp klientu un pakalpojumu ir šāda:
- klients noformē SOAP pieprasījumu un nosūta to dienestam;
- pakalpojums ieslēgts attālais dators izpilda procedūru un nosūta SOAP atbildi.
Piemēram, SOAP pieprasījums varētu izskatīties šādi, izsaucot attālā XML tīmekļa pakalpojuma HelloWorld () metodi:
2. saraksts. SOAP pieprasījuma piemērs
HelloWorld () metode, kā paredzēts, atgriež virkni "Sveika pasaule!":
3. saraksts. SOAP atbildes paraugs
Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns: xsd = "http://www.w3.org/2001/XMLSchema">
XML tīmekļa pakalpojuma izveide .NET 2.0
Jūs varat izveidot pakalpojumu Dažādi ceļi, izmantosim Visual Studio 2005. Noklikšķiniet uz "File -> New -> Web Site", atvērtajā logā izvēlieties "ASP.NET web Service". Izveidošanas laikā norādītajā adresē jūs atradīsiet šādus failus un direktorijus (skat. 1. att.).
Principā pakalpojums var saturēt tikai vienu failu ar paplašinājumu * .asmx. (Paplašinājums * .asmx tiek izmantots, lai apzīmētu .Net tīmekļa pakalpojumus.) Šajā gadījumā tas tā nav, skatiet Service.asmx faila saturu:
4. saraksts. Service.asmx definē ārējais fails atbalsts
<%@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" class="Service" %>
Atribūts CodeBehind norāda ārēju failu, kas atrodas mapē App_Code un kurā ir kods, kas ievieš HelloWorld () metodi:
5. saraksts. Service.cs fails, kurā tiek ieviesta HelloWorld () metode
izmantojot sistēmu;
izmantojot System.Web;
izmantojot System.Web.Services;
Valsts dienests () (
Atgriezties "Sveika pasaule";
Ir iespējams izveidot vienu Service.asmx failu bez atbalsta koda, kam ir tāda pati funkcionalitāte:
Saraksts 6. Service.asmx bez ārējā atbalsta koda
<%@ WebService Language="C#" class="Service" %>
izmantojot sistēmu;
izmantojot System.Web;
izmantojot System.Web.Services;
izmantojot System.Web.Services.Protocols;
publiskās klases pakalpojums: System.Web.Services.WebService
Valsts dienests () (
Publiskā virkne HelloWorld () (
Atgriezties "Sveika pasaule";
Mums tas nav vajadzīgs, un mēs to nedarīsim.
Kā redzat, vienīgā metode mūsu tīmekļa pakalpojumā ir atzīmēta ar atribūtu, kas informē ASP.NET izpildlaiku, ka šī metode ir pieejama ienākošajiem HTTP pieprasījumiem. Dalībnieki, kas nav identificēti ar šo atribūtu, nebūs pieejami klientu programmām.
Šāds vienkāršs pakalpojums ir diezgan piemērots mūsu eksperimentiem, atliek tikai to publicēt.
XML tīmekļa pakalpojuma publicēšana, izmantojot IIS
Mēs nerunājam par publicēšanu internetā, bet gan par apstākļu radīšanu mūsu pakalpojuma testēšanai vietējā datorā.
Pirmais solis ir IIS (Internet Information Server) instalēšana. Lai to izdarītu, atveriet logu "Pievienot vai noņemt programmas" un atlasiet "Instalēt Windows komponenti". (Daži Windows versijas neietver IIS instalāciju, piemēram, Windows XP Home Edition.)
Piezīme: IIS serveris labāk ir instalēt agrāk nekā .Net Framework, pretējā gadījumā jums būs jākonfigurē IIS, lai atbalstītu .Net lietojumprogrammas, palaižot utilītu komandrinda aspnet_regiis.exe (ar karogu / i).
Izveidojiet virtuālo direktoriju. Ja izmantojat Windows XP Pro, dodieties uz "Vadības panelis -> Administratīvie rīki -> Interneta informācijas pakalpojumi". Atvērtajā logā atlasiet Darbība -> Izveidot -> Virtuālais direktorijs.
Tiks startēts Jaunā virtuālā direktorija vednis. Alias Soap1 un norādiet ceļu uz direktoriju, kurā vēlaties ievietot pakalpojumu, piemēram, C: \ Soap1. Tagad nokopējiet tur mūsu tīmekļa pakalpojuma saturu.
Pārlūkprogrammas adreses joslā ierakstiet http: //localhost/soap1/Service.asmx, un jums vajadzētu redzēt pakalpojuma testēšanas lapu (skatiet 2. attēlu).
SOAP ziņojumu skatīšana
Testa lapa neļauj sūtīt un lasīt SOAP ziņojumus. Šī iemesla dēļ jums būs jāizmanto trešās puses izstrāde, es iesaku izmantot soapUI. (Šis ir bezmaksas produkts, kas pieejams vietnē http://www.soapui.org.)
Pēc soapUI instalēšanas izveidojiet jaunu projektu ar nosaukumu soap1, atstājot lauku Sākotnējais WSDL tukšs (skatiet 3. attēlu).
Ar peles labo pogu noklikšķiniet uz jaunizveidotā projekta un atlasiet "Pievienot WSDL no URL". Atvērtajā dialoglodziņā ievadiet http://localhost/soap1/Service.asmx?Wsdl. Tagad mums ir iespēja nosūtīt SOAP pieprasījumus mūsu pakalpojumam un skatīt saņemtās atbildes. (Pieprasījumus automātiski ģenerēs soapUI.)
Kas tas par WSDL? WSDL dokumentā ir aprakstīts, kā klienti mijiedarbojas ar tīmekļa pakalpojumu. Tajā ir aprakstīts, kādas servisa metodes ir pieejamas ārējai izsaukšanai, kādus parametrus tās pieņem un ko atgriež, kā arī cita informācija, kas nepieciešama attālināšanai. Šādu dokumentu var noformēt manuāli, vai arī varat uzticēt tā ģenerēšanu serverim, lai to paveiktu, pietiek ar Wsdl sufiksu pievienot vietrādim URL, kas norāda uz * .asmx failu.
Lai skatītu mūsu pakalpojuma WSDL dokumentu, pārlūkprogrammā ievadiet http://localhost/soap1/Service.asmx?Wsdl. Informācija no šī dokumenta tiek izmantota soapUI, lai automātiski ģenerētu SOAP pieprasījumus.
SOAP paplašinājumi
Kā jūs, iespējams, pamanījāt, XML tīmekļa pakalpojuma (kā arī klienta) izveidei nav jāuztraucas par SOAP ziņojumu izskatu. Pietiek atzīmēt nepieciešamās metodes ar atribūtu, un ASP.NET izpildlaiks ģenerē vajadzīgā formāta pakotnes.
attēlā. 4 parāda tīmekļa pakalpojuma pieprasījumu un atbildi, kas saņemta, izmantojot programmu soapUI.
Darīsim to vēl vienu reizi. Pieprasījumu ģenerē soapUI – veidojot pakalpojumam reālus klientus, arī nav nepieciešams manuāli formatēt SOAP paketes. Mēs arī tieši nepiedalījāmies dienesta atbildes veidošanā. Tas viss notiek automātiski.
Tomēr, visticamāk, šīs pakotnes jums būs jāmaina pašam. Piemēram, saspiest vai šifrēt pārsūtītos datus. Tas ir SOAP paplašinājumu mērķis.
SOAP paplašinājumi ir mehānisms, kas ļauj patvaļīgi modificēt sūtītos un saņemtos SOAP ziņojumus.
SOAP ziņojums "ceļš"
Lai sāktu programmēšanu, ir jāņem vērā ceļš, pa kuru SOAP ziņojums tiek saņemts un apstrādāts ar atbilstošo metodi (sk. 5. attēlu).
SOAP ziņojumu var uzskatīt par XML dokumentu, kas apraksta objektu, kas tiek pārraidīts tīklā. Pirms šādā veidā nodotā objekta izmantošanas tas ir jāatjauno (vai, ja vēlaties, jāsamontē) no šī apraksta. Šim nolūkam kalpo XML serializators.
Ienākošās paketes tiek deserializētas (objekta atjaunošana no XML apraksta), un nosūtītās tiek serializētas (veidojot objekta XML aprakstu).
attēlā. 5 ir parādīti četri punkti (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), kuros mēs varam pārtvert SOAP ziņojumu, izmantojot SOAP paplašinājumus. Pārveidojiet to un nosūtiet tālāk.
SOAP paplašinājuma ieviešana
Sākumā definēsim uzdevumu: pieņemsim, ka mēs vēlamies modificēt tīmekļa pakalpojuma nosūtītās SOAP paketes, kā parādīts 7. sarakstā:
7. saraksts. Vecās un jaunās XML tīmekļa pakalpojumu atbildes
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"> Šifrēts teksts
Rīcības plāns SOAP paplašinājuma ieviešanai:
- Izveidojiet dll ar klasi, kas mantota no SoapExtension.
- Pievienojiet bin mapi mūsu tīmekļa pakalpojumam un ievietojiet tajā izveidoto dll.
- Pievienojiet pakalpojumam failu web.config un veiciet tajā nepieciešamās izmaiņas.
Vēlāk apspriedīsim bin mapes un faila web.config lomu.
DLL izveide ar SOAP paplašinājumu
Izveidojiet jaunu "Klases bibliotēkas" projektu ar nosaukumu SoapExtensionLib. Šajā projektā mums ir jāievieš tikai viena klase, kas veiks mums nepieciešamās SOAP pakotņu modifikācijas. Šai klasei ir jābūt mantotai no SoapExtension klases.
Uzskaitījums 8. Klases izveide, kas manto no SoapExtension
izmantojot sistēmu;
izmantojot System.Web.Services;
izmantojot System.Web.Services.Protocols;
izmantojot System.IO;
izmantojot System.Net;
izmantojot System.Xml;
Katrs SOAP paplašinājums kā parametru saņem straumi, kurā ir objekts, kas jānodod tīklā (pirms vai pēc serializācijas). Un tai ir jāatgriež straume.
SOAP paplašinājumu var uzskatīt par "kastīti", kuru var novietot vienā vai visos četros punktos (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize), kas parādīti attēlā. 5. Katrā punktā šādu "ieliktņu" var būt jebkāds skaits (skat. 6. att.).
Šo straumju saņemšanai tiek izmantota metode ChainStream.
Uzskaitījums 9. ChainStream metodes ieviešana
publiskā klase TraceExtension: SoapExtension
Stream wireStream;
Straumēt appStream;
// metode kā ievades parametrs
// iegūst straumi, kurā ir nodots objekts
Publiski ignorēt Stream ChainStream (straumes straume)
WireStream = straume;
AppStream = jauna MemoryStream ();
Atgriezt appStream;
…
Vietnē BeforeDeserialize WireStream satur saņemto SOAP pieprasījumu no tīkla. Šis SOAP pieprasījums ir jānosūta lietojumprogrammas straumei (appStream).
Un AfterSerialize brīdī jums ir jānosūta tīklam nosūtītā SOAP atbilde uz WireStream, kas tiks ievietota appStream.
Lai strādātu ar pavedieniem katrā no četriem punktiem, ir jāievieš ProcessMessage metode.
Uzskaitījums 10. ProcessMessage metodes ieviešana, kas nemaina SOAP ziņojumus
// ProcessMessage veic obligāto kopiju
// straumē divos punktos (BeforeDeserialize un AfterSerialize)
Slēdzis (Message.Stage)
// punktā BeforeDeserialize jums jānokārto
// SOAP pieprasījums no tīkla straumes (wireStream)
// uz lietojumprogrammas straumi (appStream)
Case SoapMessageStage.BeforeDeserialize:
Kopēt (wireStream, appStream);
AppStream.Position = 0;
Pārtraukums;
// punktā AfterSerialize ir jānokārto
// SOAP atbilde no lietojumprogrammas straumes uz tīkla straumi
AppStream.Position = 0;
Pārtraukums;
nederīga kopēšana (straumēt no, straumēt uz)
TextReader lasītājs = jauns StreamReader (no);
TextWriter rakstītājs = jauns StreamWriter (uz);
Writer.WriteLine (reader.ReadToEnd ());
Rakstnieks.Flush ();
Padomājiet par 10. sarakstu kā tukšu vietu turpmākiem eksperimentiem. Šādai ProcessMessage metodes ieviešanai nav nekādas jēgas - izejošā SOAP atbilde netiek nekādā veidā pārveidota. Labosim šo:
Uzskaitījums 11. ProcessMessage metodes ieviešana SOAP atbildes modificēšanai
publiska ignorēšana Void ProcessMessage (Ziepju ziņojums)
Slēdzis (Message.Stage)
Case SoapMessageStage.AfterSerialize:
WriteOutput (ziņa);
Pārtraukums;
// daļa koda tika izgriezta, lai ietaupītu vietu
// pārrakstīt SOAP atbildi
public Void WriteOutput (Ziepju ziņojums)
AppStream.Position = 0;
// izveidojiet XML dokumentu no straumes
XmlDocument document = jauns XmlDocument ();
Document.Load (appStream);
// Lai izmantotu XPath, jums ir jādefinē
// NamespaceManager
XmlNamespaceManager nsmgr = jauns XmlNamespaceManager (document.NameTable);
Nsmgr.AddNamespace ("ziepes", "http://schemas.xmlsoap.org/soap/envelope/");
XmlNode ResultNode = document.SelectSingleNode ("// ziepes: Body", nsmgr);
// nomainiet mezgla saturu
ResultNode.InnerText = "šifrētais teksts";
// iztīriet straumi un uzrakstiet tai jaunu SOAP atbildi
AppStream.SetLength (0);
AppStream.Position = 0;
Document.Save (appStream);
// OBLIGĀTA DARBĪBA
// nodot SOAP atbildi no lietojumprogrammas straumes (appStream)
// tīkla straumē (wireStream)
AppStream.Position = 0;
Kopēt (appStream, wireStream);
Tālāk jums jādefinē divas metodes (no kurām viena ir pārslogota, tas ir, to var izsaukt ar dažādām parametru kopām), kuras mūsu gadījumā nav vajadzīgas. Tomēr mums tie ir jādefinē saskaņā ar mantojuma noteikumiem no SoapExtension klases.
Uzskaitījums 12. Citas nepieciešamās metodes
// Saskaņā ar mantojuma noteikumiem mums ir
// definē šīs metodes, bet mēs tās nekādā veidā neizmantojam
publisks ignorēšanas objekts?
GetInitializer (LogicalMethodInfo methodInfo, SoapExtensionAttribute atribūts)
Return null;
publiska ignorēšanas objekts GetInitializer (tips WebServiceType)
Return null;
publiskā ignorēšana spēkā neesošs Inicializēt (objekta inicializētājs)
Atgriezties;
Tas arī viss, mēs sastādām projektu. Beidzot mēs saņēmām dll ar SOAP paplašinājumu. Pilnu SoapExtensionLib.dll sarakstu var atrast žurnāla tīmekļa vietnes sadaļā "Avota kods".
Web pakalpojuma konfigurēšana darbam ar SOAP paplašinājumu
Atkal atveriet mūsu XML tīmekļa pakalpojuma projektu, izmantojot Visual Studio. Noklikšķiniet uz "Tīmekļa vietne -> Pievienot atsauci" un atlasiet iepriekš izveidoto SoapExtensionLib.dll.
Mape Bin tiks automātiski pievienota projektam. Programma automātiski atsaucas uz * .dll failiem, kas atrodas mapē Bin.
Tagad ievietojiet šādu saturu Web.Config failā tīmekļa pakalpojumu direktorijā:
Saraksts 13. Web.Config fails
Prioritāte = "1" Grupa = "0" />
Tagad mūsu pakalpojuma struktūra izskatās kā parādīta attēlā. 7. Mēs izmantojam Web.Config failu, lai informētu ASP.NET ietvaru, ka esam pievienojuši tīmekļa pakalpojumam XML Soap Extension, kas ir ieviests TraceExtension klasē, kas atrodas SoapExtensionLi.dll failā. Saraksts 14. Web.Config faila sadaļa WebServices Prioritāte = "1" Grupa = "0" />
Kā jūs jau zināt, var izveidot daudzus SOAP paplašinājumus, un straume, kas satur nodoto objektu (pirms vai pēc serializācijas), iet cauri katram no tiem. Secība, kādā straume plūst caur dažādiem SOAP paplašinājumiem, tiek norādīta, izmantojot prioritātes un grupas atribūtus. Ir vērts atzīmēt, ka, konfigurējot Web.Config šādā veidā, mēs informējam vidi, ka mūsu SOAP paplašinājums tiks izsaukts katrai pakalpojuma metodei, kas atzīmēta ar atribūtu. Ir iespējams izveidot savu atribūtu un atzīmēt ar to tikai tās metodes, kurām nepieciešams izsaukt SOAP paplašinājumu. 15. saraksts. Pielāgota atribūta izmantošanas piemērs publiska virkne HelloWorld () ( Atgriezties "Sveika pasaule"; Lai to izdarītu, failam SoapExtensionLi.dll pievienojiet klasi, kas mantota no SoapExtensionAttribute (skatiet 8. attēlu). Secinājums Šajā rakstā ir atspoguļoti galvenie punkti par XML tīmekļa pakalpojumu izveidi un darbību .Net platformā. Es ceru, ka iesniegtā materiāla būs pietiekami, lai vajadzības gadījumā varētu iesaistīties padziļinātā tēmas izpētē. Saskarsmē ar
