Transferarea fișierelor către serviciul web

În dezvoltarea sa, protocoalele de servicii Web au parcurs un drum lung, începând cu întrebări foarte simple cu parametri simpli și terminând cu sprijinul deplin al limbilor moderne orientate pe obiecte. Specificații XML-RPC (remote procedure apel la XML), care este, probabil, una dintre cele mai timpurii forme de servicii web, susținute numai tipuri simple - siruri de caractere, numere întregi, expresii logice, etc. Următorul pas a fost apariția în SOAP a regulilor de codare pentru obiecte. În final, ultimul pas - îmbunătățirea codului binar - a fost introdus în documentul consorțiului W3C "SOAP with attachments".

Inițial, "SOAP with attachments" a fost propus ca o extensie la SOAP 1.1, iar astăzi această tehnologie este susținută în majoritatea instrumentelor SOAP. În ciuda faptului că investițiile nu sunt acceptate încă în versiunea oficială a W3C SOAP versiunea 1.2 este în prezent în curs de desfășurare în vederea includerii acestora în acest document (noțional) viitorul apropiat.

Serviciu Web și date binare

Cu toate acestea, utilizarea codării textului are propriile "laturi întunecate", iar XML nu are o modalitate eficientă de a include date binare. Așa cum recomandăm consorțiul W3C XML Schema (W3C XML Schema), datele binare trebuie să fie codate folosind codul Base-64 sau hexazecimal. Din păcate, dimensiunea datelor codificate cu un cod de șase biți (Base-64) este de o dată și jumătate mai mare decât dimensiunea datelor necriptate. Dimensiunea datelor convertite în sistemul de bază cu baza 16 este de două ori mai mare decât cea originală. O astfel de cheltuială este acceptabilă în cazul fragmentelor mici de date binare, dar pentru seturi de date mari o astfel de abordare este inacceptabilă.

Cu toate acestea, datele binare sunt utile pentru multe aplicații, de exemplu:

Pentru sistemele de securitate, aveți nevoie de chei, semne de grătar, certificate, datele în sine codificate.
Aplicațiile multimedia utilizează fotografii, muzică și filme.
În unele aplicații, utilizarea reprezentării XML este ineficientă, de exemplu, în cazul CAD (Automated Design) sau Automated Manufacturing (CAM).
Există mii de formate de fișiere care au apărut înainte de XML - formatele procesoarelor de text, foi de calcul, fonturi, grafice vectoriale etc.

Deși crearea XML-versiuni ale acestor formate de fișiere este posibil (similar cu formatul SVG (Scalable Vector Graphics, Scalable Vector Graphics) pentru grafică vectorială), există date binare pentru o lungă perioadă de timp și cu greu își pierd popularitatea lor.

În sfârșit, există probleme cu XML în sine! De exemplu, includerea unui document XML într-un alt document XML nu este o sarcină trivială (o soluție sintactic corectă se bazează pe secțiunile CDATA și trecerea la alte simboluri).

MIME și codul de bază 64

Pentru a evita neînțelegerile frecvente, subliniem faptul că MIME nu necesită utilizarea obligatorie a codării de bază 64. Mai precis, implementările HTTP nu codifică incluziunile; ele sunt criptate numai de clienții de e-mail pentru a ocoli restricțiile SMTP (deci atunci când se compară cu XML, nu există avantaje).

Prin urmare, pentru a implementa cerințele tuturor acestor aplicații, serviciile web trebuie să sprijine în mod eficient datele binare. Soluția propusă este SOAP cu atașamente, care, dacă încercați să spunem pe scurt, șterge informațiile binare din sarcina utilă XML și o salvează direct în cererea HTTP ca MIME multipart / conținut înrudit.

Astfel, atunci când proiectați un serviciu Web care utilizează date binare, trebuie utilizată una din următoarele abordări:

Dacă setul de date este mic, puteți utiliza codul Base-64 pentru sarcina utilă XML; aeriene pentru piese mici de date nu este o problemă gravă.
Dacă setul de date este semnificativ, includerea este singura alegere practică.

Lista 1 prezintă o solicitare SOAP cu un parametru codificat cu un cod pe șase biți, în care adresa elementului merită o atenție deosebită.

Lista 1. Parametrul din sistemul radix cu baza 64r

Implementarea incluziunilor

Dezvoltatorii Java pot utiliza incluziuni utilizând JAX-RPC (Java API pentru RPC bazat pe XML) și SAAJ (SOAP API cu includeri pentru Java). Cititorul ar trebui să acorde atenție abrevierii SAAJ: JAX-RPC acceptă includeri (a se vedea, de exemplu, Subiecte înrudite). Diferența dintre JAX-RPC și SAAJ este în nivelul de abstractizare, nu în funcționalitate.

JAX-RPC este un API la nivel înalt, este mai abstract decât SAAJ. JAX-RPC se ascunde în spatele stratului RMI (Remote Method Invocation, tehnologia pentru construirea de aplicații distribuite în specificația limbajului Java) majoritatea aspectelor SOAP orientate pe protocol. Dezvoltatorul se ocupă cu obiecte Java, iar preprocesorul le transformă în noduri SOAP. Pentru a reprezenta incluziunile, JAX-RPC utilizează clasele java.awt.Image și javax.activation.DataHandler.

SAAJ este mai aproape de protocol. În ceea ce privește crearea SOAP-mesaje folosind SAAJ necesită mai mult efort decât cu JAX-RPC (și, în consecință, nu oferă link-uri automate la WSDL), în cele mai multe cazuri va JAX-RPC. Cu toate acestea, aspectele de nivel scăzut sunt mai convenabile pentru a ilustra modul în care încorporările funcționează cu adevărat. Listarea 2 este o cerere SOAP cu includere. Această solicitare cere serverului să redimensioneze fotografia; Deoarece dimensiunea fișierului foto este mare, utilizarea includerii este mai preferabilă.

Listare 2. Comutați parametrul

Următorul Listing 3 demonstrează crearea unei solicitări SOAP. Această solicitare cere serverului să redimensioneze imaginea. Pentru a implementa această procedură, trebuie să efectuați următoarea secvență de acțiuni:

Serviciul oferă un răspuns cu o imagine a cărei dimensiuni au fost modificate și această imagine este reprezentată ca o includere. Pentru ao extrage, puteți testa SOAP pentru o defecțiune (adică eroare). Dacă nu există probleme, includerea ar trebui extrasă ca fișier și apoi procesată.

Listing 3. Utilizarea SAAJ

Merită menționat faptul că în lista 3, includerea este în afara mesajului XML. Această abordare îmbunătățește productivitatea.

În ceea ce privește performanța, luați în considerare Listarea 4, care prezintă o mai generală (și în mod semnificativ mai scurt) JAX-RPC Listarea 3. Precompilatorul generează adaptor JAX-RPC (ciot), care simplifică foarte mult de codificare. În acest caz, obiectul DataHandler este trecut ca parametru de metodă. și JAX-RPC generează automat această includere.

Listarea 4. JAX-RPC mai eficientă

concluzie

Alegerea este bun, și SOAP vă oferă posibilitatea de a alege atunci când se lucrează cu date binare: Puteți să-l codifica fie folosind codul de bază 64 în sarcina utilă XML, care este o soluție bună pentru seturi mici de date, sau pentru a atașa fișiere necriptate binare mai mari la această solicitare.