Web services java, partea 1 servicii web java în anul următor

Aflați despre structurile de servicii Web schimbate pentru dezvoltarea Java

Anul următor va aduce modificări semnificative în structura serviciilor Web. Pentru dezvoltatorii din Java ™, aceste schimbări înseamnă atât noile modele de servicii Web, cât și apariția unei noi funcționalități bazate pe servicii Web. În prima parte a publicațiilor dedicate serviciilor Web Java, Denis Sosnoski va lua în considerare aceste schimbări viitoare și va ajuta cititorul să navigheze în ele.







Denis Sosnoski. Consultant, Sosnoski Software Solutions, Inc.

Dennis Sosnoski este fondatorul și specialistul principal al companiei de consultanță în tehnologie Java Sosnoski Software Solutions, Inc. specializată în predarea și consultarea problemelor privind serviciile XML și Web. Are mai mult de 30 de ani de experiență în designul de software profesional, specializat în tehnologiile XML și Java de la server. Denis este dezvoltatorul principal al sistemului integrat cu codul sursă JiBX XML Data Binding. pe baza tehnologiei claselor Java și a sistemului JibxSoap conectat la serviciile Web. precum și sistemele de servicii Web Apache Axis2. El a fost, de asemenea, unul dintre experții lor în dezvoltarea specificațiilor JAX-WS 2.0.

Pregătirea solului

Au trecut șase ani de la lansarea specificației SOAP 1.0. Cu mult înainte ca specificațiile SOAP să apară, dezvoltatorii au făcut schimb de mesaje XML prin intermediul protocoalelor Internet, dar introducerea SOAP a promis formalizarea acestei tehnici și a asigurat o mai bună interoperabilitate. SOAP a oferit, de asemenea, oportunități de extindere ușoară, astfel încât funcțiile de nivel superior să poată fi adăugate la infrastructură pentru a îmbunătăți schimbul de mesaje XML în viitor. Specificația WSDL, publicată la scurt timp după SOAP, a introdus o vizualizare standardizată a metadatelor serviciului Web. Vânzătorii de software importanți au realizat rapid potențialul SOAP și WSDL, iar în următorii ani se pare că serviciile Web bazate pe SOAP ar fi tehnologia viitorului.

Provocări SOAP și WSDL

În ciuda răspândirii rapide a SOAP + WSDL în industrie, există o serie de probleme care împiedică realizarea SOAP a popularității pe care mulți o așteaptă. Prima astfel de problemă este interoperabilitatea. Deși interoperabilitatea a reprezentat piatra de temelie a recursului SOAP, implementarea sa nu a respectat așteptările. Inițial, aceasta a fost din cauza orientării Web-servicii în stilul RPC / codificat (de asemenea cunoscute ca rpc / ENC), în cazul în care modelul de obiect este convertit în XML și apoi restaurat la capătul de recepție. Această conversie automată în două direcții face ca rpc / enc ușor de utilizat (atâta timp cât utilizați structuri de date relativ simple pe care le suportă), dar rezultatul este că XML nu este potrivit pentru alte scopuri. În plus, diferențele în sprijinul limbajelor și platformelor de programare duc la incompatibilitatea implementărilor de software.

Acum, atunci când dezvoltați servicii Web, este o idee bună să refuzați utilizarea stilului rpc / enc în favoarea stilului document / literal (doc / lit). În doc / lit, formatele de mesaje XML sunt definite de schema W3C XML. Teoretic, această mișcare ar trebui să elimine orice probleme de interoperabilitate, deoarece schema definește structura reală a XML, iar tipul de procesare a acestui XML este lăsat pe platforme. Aproape diferite niveluri de suport pentru o schemă W3C extrem de complexă dau naștere la o serie de alte probleme de interoperabilitate.

Problemele de compatibilitate atât pentru rpc / enc, cât și pentru doc ​​/ lit mai mult dezvoltate sunt complicate de lipsa recunoașterii mesajului. Acest lucru este valabil mai ales pentru doc ​​/ lit, în care mediul integrat acceptă diferite standarde pentru scheme de conținut diferit fără a specifica elementele lipsă. Chiar și în cazul în care diferite medii suportă anumite funcții ale circuitelor, implementarea acestora este adesea incompletă și cauzează probleme de interoperabilitate atunci când sunt utilizate. O parte a tranziției la doc / lit a fost datorată dorinței de a utiliza scheme standard de întreprindere sau industriale. Proiectarea unor astfel de scheme nu ia în considerare, de obicei, utilizarea lor în serviciile Web, astfel încât acestea au deseori caracteristici funcționale care sunt slab suportate de mediile SOAP.

Un alt domeniu de îngrijorare pentru serviciile Web SOAP constă în îmbinarea constantă a extensiilor de tip over-the-way cu procesarea de bază SOAP - straturi suplimentare de procesare care se aplică unei game largi de servicii Web. Proiectarea SOAP facilitează adăugarea unor astfel de extensii, dar acestea beneficiază de obicei numai atunci când sunt suportate de mai multe medii. Această condiție necesită cooperare între toate ramurile, ceea ce este dificil de realizat. Chiar și extensiile cele mai fundamentale, pentru funcții precum conectivitate și securitate, au fost dezvoltate de mai mulți ani și nu sunt încă suportate de toate mediile.

Alternativă la SOAP

Altele decât cele descrise în secțiunea anterioară, problemele cu interoperabilitatea și standardizarea, limitarea SOAP servicii Web practic, SOAP cadre ele însele sunt adesea complexe pentru a configura și dificil de utilizat. Această combinație de beneficii limitative și complexitate semnificativă încurajează mulți dezvoltatori să caute alternative mai simple pentru SOAP. Majoritatea "mișcării rezistenței" SOAP este asociată cu tehnologia REST. Strict vorbind, REST este formalizarea regulilor de bază ale protocolului HTTP, care se aplică serviciilor Web. În practică, mișcarea REST adesea lasă deoparte formalizare și cuprinde orice lucru care transferă documentele XML peste HTTP, fără un înveliș SOAP, în esență, cooptării ideea schimbului de documente XML, SOAP direct care au precedat.

REST este mult mai puțin pretențios decât SOAP. REST limitate inerent la utilizarea HTTP ca un strat de transport (deși abordări similare pot fi utilizate pentru alte protocoale de transfer de date), în timp ce SOAP este teoretic de transport-agnostic (deși desfășurate pe scară largă folosind protocolul de transmitere a datelor HTTP). REST nu are modalități directe de a adăuga extensii de infrastructură - dar numai atunci când SOAP începe cu adevărat să permită adăugarea unor astfel de extensii, această restricție poate fi considerată un dezavantaj.

Din moment ce REST este mai puțin pretențios decât SOAP, nu este nevoie să utilizați niciun cod de cadru pentru a implementa un client sau server, astfel încât dezvoltatorii nu trebuie să înțeleagă complexitatea infrastructurii. Un factor coerent este că aceștia trebuie să implementeze direct procesarea HTTP și XML, însă mulți procesatori sunt deja familiarizați cu aceste tehnologii. Procesarea XML directă poate fi chiar un avantaj, deoarece permite dezvoltatorilor să aleagă dintr-o gamă mai largă de instrumente de procesare decât infrastructura SOAP propusă.







Deci, nu este timpul să vă luați la revedere SOAP și să treceți la o alternativă mai simplă - REST? Poate că acest lucru este practic posibil pentru multe tipuri de aplicații de servicii Web, așa că nu voi refuza imediat această idee. Cu toate acestea, există alte aplicații, în special la nivel corporativ, care necesită mai degrabă agnosticism de infrastructură și de transport, pe care SOAP promite doar să-l dezvolte. Tranziția către REST va însemna că pentru aceste aplicații va fi necesar să se pună în aplicare în mod direct funcții precum securitatea, tranzacțiile și coordonarea, deoarece acestea nu vor beneficia de o infrastructură. Cele mai multe aplicații ale întreprinderilor vor prefera să facă fără servicii Web, mai degrabă decât să-și petreacă astfel de eforturi pentru a nu depăși aceste dificultăți.

Dar, ca și în filme, deși situația pare a fi cu adevărat fără speranță pentru SOAP, există o șansă de mântuire asociată cu apariția unor noi infrastructuri de generații. Aceste infrastructuri permit dezvoltarea unor noi capabilități SOAP, punerea la dispoziție a întregii game de aplicații de servicii Web SOAP, îmbunătățind în mod semnificativ interoperabilitatea serviciilor Web doc / ll.

Importanța Indigo

Deși această serie este dedicată tehnologiilor Java, prima infrastructură nouă pe care o voi discuta este dezvoltată de concurentul principal al tehnologiilor Java: Microsoft® .NET. Aceasta este noua infrastructură Windows Communication Foundation (WCF), cunoscută și sub numele de Indigo. Inițial, Indigo făcea parte din versiunea "Longhorn" pentru Windows, a cărei lansare a fost planificată în ultimii ani. Dar Microsoft a anunțat că, sub forma WCF, va fi disponibil și pentru versiunile mai vechi de Windows. Este de așteptat ca WCF, de îndată ce va deveni disponibilă, va înlocui infrastructura .NET.

Importanța WCF (Indigo) pentru întreaga servicii web mondiale constă în faptul că Microsoft controlează marea majoritate a PC-ului (acest lucru nu este un control complet - la fel ca mulți alți oameni, eu, de exemplu, folosind Linux®, și Mac-urile sunt, de asemenea, populare - dar mai mult de 90% ). Această aliniere înseamnă că, atunci când Microsoft intră pe piață cu o nouă infrastructură, are un efect copleșitor asupra altor companii și a produselor lor. Tehnologiile suportate de Microsoft sunt suportate automat de alte infrastructuri și nu sunt acceptate de Microsoft se pot baza numai pe utilizarea minoră, cu condiția ca sistemele Microsoft să fie excluse, atât din partea clientului, cât și din partea serverului.

Sun și standardele Java

JAX-RPC 1.0 a fost standardul inițial pentru serviciile Web din Java. Deși JAX-RPC a fost conceput ținând cont de faptul că diferite implementări ale protocoalelor pot fi folosite în implementarea efectivă a serviciilor Web, în ​​practică a fost utilizată doar pentru serviciile SOAP. Dezvoltarea mai multor versiuni diferite ale JAX-RPC, cel mai utilizat pe scară largă din care a fost, probabil, Apache Axis de infrastructură, urmată de o implementare de referință, incluse ca parte a pachetului software Java Developer servicii web distribuite de Sun Microsystems.

Până când a fost dezvoltat JAX-RPC 1.0, mulți oameni au crezut că stilul SOAP rpc / enc era cel mai convenabil și mai util pentru serviciile Web. Specificația JAX-RPC 1.0 necesită suport de bază atât pentru stilul rpc / enc și stilul doc / lit, dar nu a necesitat suportul mai multor elemente de schemă. Acest lucru a avut un efect secundar nefavorabil, care a fost exprimat în faptul că SOAP doc / lit (care se bazează pe scheme) a devenit de fapt un software de clasa a doua.

Atât JAX-WS 2.0 cât și JAXB 2.0 au fost pregătite pentru includerea în versiunea post-Java 5 a specificației J2SE. Adăugarea acestor componente, ca parte a JVM instalare standard crește, fără îndoială popularitatea lor în rândul dezvoltatorilor, deoarece va elimina necesitatea de a include aceste infrastructuri destul de greoaie în cadrul aplicației în sine. Reversul includerii lor în JVM standard, (în plus față de creșterea dimensiunii fișierului de boot) poate deveni o dificultate în a determina versiunea în caz de nevoie pentru a efectua depanare de lucru pe care le-am văzut deja în cazul componentelor, cum ar fi JAXP.

Tranziția la interoperabilitate

JAX-WS 2.0 suportă direct XOP / MTOM, dar nu și alte tehnologii WCF noi. Cu toate acestea, în cadrul acordului lui Sun cu privire la interoperabilitatea cu Microsoft, a fost anunțată dezvoltarea versiunilor Java cu cod sursă deschisă a altor tehnologii care fac parte din WCF. Aceste produse software vor fi dezvoltate ca parte a mega-proiectul „GlassFish“, care include toate tehnologiile care sunt folosite ca parte a server de aplicații Sun (inclusiv JAX-WS 2.0 și 2.0 implementările de referință JAXB).

Apache Approach

Proiectul Apache este strâns legat de activitatea de servicii Web de mai mulți ani, axându-se în principal pe dezvoltarea platformelor Java. Platforma actuală a Apache pentru serviciile Java SOAP Web este infrastructura axei a treia generație. Axa este folosită pe scară largă de către dezvoltatorii care o descarcă și o utilizează direct, sau ca un motor SOAP încorporat pentru mai multe servere de aplicații diferite. Axa este considerată cea mai răspândită platformă pentru serviciile Java SOAP Web.

Rezolvarea problemei cu Axa2

Axa 2 este descendentul Axei. Este proiectat ca server de procesare SOAP ușor (deși, ca și JAX-WS 2.0, Axis2 include și un suport REST), care poate fi extins în mai multe moduri. Spre deosebire de Axa originală, Axis2 în mod deliberat nu constrâns să pună în aplicare orice API-ul special (deși unele niveluri de suport pentru JAX-WS 2.0 planificat cu un înveliș în jurul valorii de codul de bază Axis2). Axa 2 a fost în curs de dezvoltare pentru mai mult de un an și va dobândi în curând statutul de produs software.

Una dintre cele mai convenabile caracteristici ale Axis2 este modelul obiect AXIOM folosit pentru mesaje SOAP. Modelele obiect XML există pentru atâta timp cât XML însuși, derivând din standardul DOM vechi de la W3C. Diferența dintre AXIOM și alte modele de obiecte XML se datorează faptului că flexibilitatea sa este oferită de noile forme de parser XML, ceea ce face posibilă construirea unui model de obiect la cerere. Aceasta înseamnă că plătiți pentru construirea unui model de obiect numai pentru acele fragmente ale documentului XML, acces la care este posibil numai prin intermediul modelului de obiect.

O altă caracteristică a Axis2 este sprijinul pentru legarea datelor care pot fi schimbate. Această proprietate vă permite să alegeți cea mai simplă modalitate de a lucra cu conținutul XML al documentelor dvs. SOAP prin acordarea codului generat pentru a utiliza abordarea aleasă. Opțiunile posibile sunt utilizarea directă a AXIOM; Utilizați o metodă simplă de legare a datelor similară axei inițiale; sau utilizați o schemă specială de legare a datelor, cum ar fi XMLBeans, JiBX sau JAXB 2.0.

Extensia axei 2

Deși Axa 2 este încă dezvoltată în mod activ, există deja o serie de proiecte care implementează tehnologii de extindere a SOAP pe axa 2. Aceste proiecte includ toate tehnologiile majore susținute de WCF, precum și câteva extensii pe care Microsoft intenționează să le includă în aplicațiile de extensii pentru extensii (cu alte cuvinte, livrate contra cost). Arhitectura Axis2 simplifică dezvoltarea unor astfel de aplicații utilizând o componentă numită modul.

Ligi inferioare

Pe lângă dezvoltarea companiilor cu nume mari precum Sun și Apache, există și diverse proiecte inovatoare de servicii Web în domeniul tehnologiilor open source. Unul dintre ele este propriul proiect JibxSoap, motorul SOAP și REST, construit pe infrastructura mea de legare a datelor XML de la JiBX. Principalul avantaj al JibxSoap este viteza sa - în testele timpurii el aproape a egalat Java RMI atunci când utilizează mesaje standard SOAP. XFire este un alt motor SOAP care vă permite să alegeți infrastructura de legare a datelor; XFire prezintă, de asemenea, performanțe excelente. Atât JibxSoap cât și XFire pot dobândi statutul de produs software anul viitor.

O privire în viitor

  • Articolul original: Servicii Web Java, Partea 1: Anul viitor în serviciile Web Java.
  • Aflați mai multe despre infrastructura serviciilor Web JibxSoap, construită pe legarea datelor XML JiBX.
  • Harta tehnologică a standardelor - evaluarea impactului și importanței standardelor și specificațiilor la dezvoltarea serviciilor SOA și Web.
  • Secțiunea SOA și serviciile Web găzduiește sute de articole și tutoriale pentru nivelele inițiale, intermediare și avansate pentru dezvoltarea de aplicații de servicii Web.

Obțineți produse și tehnologii

  • Verificați starea JAX-WS și obțineți specificațiile din pagina Comunității Java: crearea și operarea software-ului. apoi mergeți la java.net pentru a descărca cea mai recentă versiune de implementare de referință.
  • Obțineți cea mai nouă documentație pentru Apache Axis2 și descărcări.
  • Testați infrastructura serviciilor XFire Web selectând infrastructura de legare a datelor pe cont propriu.
  • Obțineți instrumentele pentru dezvoltarea de aplicații și middleware din DB2®, Lotus®, Rational®, Tivoli® și WebSphere®. Puteți descărca gratuit versiunile de evaluare ale produselor sau puteți alege o versiune pentru software-ul de evaluare software pentru Linux® sau Windows® developerWorks.






Articole similare

Trimiteți-le prietenilor: