Aplicatii client-server - Tehnologia serviciilor web

Aplicatii client-server - Tehnologia serviciilor web

Web services cu SOAP si JAVA

1. Introducere [1]

In istoria dezvoltarii software, noi abordari aduc deseori in practica uzuala idei neexploatate in trecut. De fiecare data cand o idee este revizuita, succesele si esecurile anterioare devin informatii nepretuite in imbunatatirea conceptului si in realizarea unei implementari mai bune.

Calculul centralizat cu mainframe-urile sale si cu terminalele asociate acestora au aparut in ultima perioada deghizate in servere de aplicatii si clienti "thin".

Adevarul este ca o idee buna e o idee buna, indiferent daca este una noua sau nu. Acesta este si cazul aplicatiilor distribuite. Conceptul nu este nou, dar este revizuit in mod constant. Infrastructuri si tehnologii precum Internetul, browserele web, si protocoalele asociate lor ne-au permis sa aducem calculul distribuit la un nou nivel.

Etapa cea mai recenta in domeniul aplicatiilor client-server o constituie serviciile web. Serviciile web sunt functii pe partea de server ce au publicat mecanismele de interfata necesare pentru accesarea resurselor de calcul ale acestora.

Sisteme distribuite RPC si orientate pe mesaje

Sistemele distribuite exista in general ca entitati cuplate slab ce comunica intre ele pentru a realiza anumite task-uri. Unul din cele mai comune modele folosit in software-ul distribuit este apelul de procedura la distanta (RPC). Unul din motivele pentru popularitatea sistemelor RPC este faptul ca sintaxa acestora se aseamana foarte mult cu sintaxa standard de apel de functie-metoda, cu care programatorii sunt atat de familiarizati. Tehnologii precum Java RMI, Microsoft COM si CORBA folosesc acest model.

Alt model raspandit in cadrul calculului distribuit este transferul de mesaje. Spre deosebire de modelul RPC, acest model nu emuleaza sintaxa apelurilor de functii. In schimb, mesajele sunt pasate intre parti. Aceste mesaje pot servi la decuplarea intr-o oarecare masura a nodurilor sistemului distribuit; sistemele bazate pe mesaje se dovedesc deseori a fi mai flexibile decat sistemele bazate pe RPC.

Avand in vedere caracteristicile celor 2 modele, varianta cea mai buna o reprezinta o solutie ce le combina. Pentru aceasta este necesara definirea unui format al datelor ce poate descrie aceste date si in acelasi timp conformandu-se la un set de reguli ce guverneaza acea descriere.

1.2. Formatul de descriere a datelor

Pentru a intelege acest concept consideram urmatorul exemplu. Avem de proiectat un sistem distribuit bazat pe transfer de mesaje, ce are ca scop livrarea preturilor actiunilor pe bursa. Sa presupunem ca exista 2 formate de exprimare a pretului. Primul format utilizeaza notatia zecimala standard, de exemplu 84.5. Al doilea format foloseste fractii, deci aceeasi valoare va fi reprezentata ca 84 ½. Un format al datelor prin care acestea sunt descrise trebuie sa aiba o modalitate de a indica care format este folosit pentru reprezentarea pretului. Acest concept se utilizeaza atat pentru structura generala a mesajului, cat si pentru partile sale constituente. Astfel se obtine flexibilitatea necesara pentru a descrie continutul mesajului.

Pentru ca formatul de descriere a datelor sa fie cu adevarat util, este nevoie de un limbaj pentru descrierea datelor. Nu ne referim aici la un limbaj de programare ci la un limbaj capabil sa exprime aceasta descriere. Este necesar un nou mod de descriere si formatare a acestor mesaje, cu o gramatica specifica. Aceasta noua gramatica va dicta regulile standard ce guverneaza formatul acestor mesaje.

XML

De fiecare data cand folosim un browser web, utilizam in mod implicit un format de descriere a datelor. HTML este un exemplu bun de format standard pentru descrierea datelor; acesta este destul de flexibil datorita elementelor sale de descriere. De exemplu, culoarea si fontul utilizat pentru o anumita parte a textului sunt descrise impreuna cu textul in sine. Acest tip de descriere a datelor se numeste limbaj de marcaje. Continutul este incorporat in instructiuni ce il descriu. Acest lucru a dus la un nivel ridicat de acceptare al acestui format. Dar HTML nu este suficient de flexibil pentru a cuprinde continut ce nu a fost anticipat de proiectantii sai. Cu alte cuvinte, HTML nu este extensibil.

XML (limbaj de marcaje extensibil) este exact formatul de care este nevoie. XML este un limbaj ierarhic, bazat pe tag-uri, exact ca HTML. Diferenta majora o constituie extensibilitatea completa. Acest limbaj permite descrierea de continut ce este specific aplicatiilor intr-un format standard, fara ca proiectantii limbajului sa fi anticipat acest continut. XML defineste regulile ce trebuiesc urmate pentru a indeplini task-ul, fara sa impuna un format specific acestui continut.

2. Protocolul SOAP [1]

Una din cele mai recente cercetari din domeniul calculului distribuit a condus la crearea unei specificatii wire-level numita Simple Object Access Protocol (SOAP).

Protocolul este relativ usor, bazat pe XML si este proiectat pentru schimbul de informatii intr-un mediu de calcul distribuit. Nu exista un concept al unui server central in SOAP; toate nodurile sunt considerate egale. Protocolul este alcatuit din mai multe parti.

Prima parte o constituie plicul (sau invelisul), folosita pentru a descrie continutul unui mesaj si unele indicii despre cum poate fi procesat mesajul.

A doua parte este alcatuita din reguli de codificare a instantelor tipurilor de date definite de utilizator. Aceasta este una din cele mai importante parti ale SOAP - extensibilitatea.

Ultima parte descrie aplicabilitatea invelisului si regulile de codificare a datelor pentru reprezentarea apelurilor RPC si a raspunsurilor, inclusiv folosirea HTTP ca protocol de transport.

Stilul de calcul distribuit RPC este cea mai frecventa exploatare SOAP in Java, dar nu este singura. Orice protocol de transport poate fi folosit pentru a schimba mesaje SOAP, chiar daca HTTP este singurul descris in specificatii. Au existat numeroase discutii despre folosirea SMTP, BEEP, JXTA si a altor protocoale pentru transmiterea mesajelor SOAP.

SOAP     difera de RMI, CORBA si COM prin faptul ca se concentreaza pe continut, decuplandu-se efectiv atat de implementare cat si de protocolul de transport. Adevarul este ca SOAP este incapabil sa existe de unul singur, dincolo de abstractul specificatiei. Pentru a beneficia de SOAP trebuie sa existe implementari reale. La ora actuala exista multe implementari ale SOAP, dintre care unele sunt scrise in Java (Apache SOAP de la Apache, GLUE de la 'The Mind Electric'). Exista desigur si implementarea Microsoft, in cadrul platformei .NET.

Mesajul SOAP

Toate mesajele SOAP sunt impachetate intr-un document XML numit plic (sau invelis), care este un container structurat ce contine mesajele SOAP. Metafora este sugestiva deoarece se grupeaza intr-un plic tot ce este necesar pentru executarea unei operatii; plicul este apoi trimis unui receptor, ce il deschide si reconstruieste continutul original astfel incat poate executa operatia ceruta. Continutul invelisurilor SOAP, conform specificatiilor SOAP permit atat emitorului cat si receptorului sa schimbe mesaje intr-un limbaj neutru: de exemplu, expeditorul poate fi scris in Python si receptorul poate fi scris in Java sau C#. Niciuna din parti nu este afectata de limbajul in care a fost scrisa cealalta, deoarece ambele programe (emitator, receptor) interpreteaza in acelasi mod plicul.

Legatura HTTP

Specificatia SOAP necesita o implementare SOAP ce utilizeaza HTTP pentru transportul continutului SOAP XML; de aceea nu este nici o coincidenta faptul ca toate implementarile SOAP existente suporta HTTP. Desigur, diversele implementari pot suporta si alte protocoale de transport, desi specificatia SOAP nu le descrie. Nu exista nimic legat de incarcatura SOAP care sa interzica transportul mesajelor folosind protocoale de transport precum SMTP, FTP, JMS sau chiar protocoale private. In fond,

tipuri alternative de transport sunt frecvent discutate si cateva chiar au fost implementate. SOAP poate fi folosit pentru schimburi de mesaje de tipul cerere/raspuns, cum ar fi RPC, dar si pentru schimburi unidirectionale precum SMTP. Majoritatea implementarilor Java ale SOAP au inclus tipurile de mesaje RPC. HTTP este o alegere naturala pentru un schimb RPC deoarece permite ca cererea si raspunsul sa fie parti integrante a unei singure tranzactii.

Cererea HTTP

Primul mesaj SOAP arata ca o cerere RPC. Desi este destul de simplu el va contine toate elementele cerute de un mesaj SOAP care foloseste un trasport HTTP.

Continutul XML al mesajului este inclus intr-o cerere HTTP POST. Urmatorul mesaj cere serverului sa returneze temperatura curenta in grade Celsius de la locatia serverului:

POST /LocalWeather HTTP/1.0

Host: www.mindstrm.com

Content-Type: text/xml; charset='utf-8'

Content-Length: 328

SOAPAction: 'WeatherStation'

<SOAP-ENV:Envelope

xmlns:SOAP-ENV='https://schemas.xmlsoap.org/soap/envelope/'

SOAP-ENV:encodingStyle='https://schemas.xmlsoap.org/soap/encoding/'>

<SOAP-ENV:Body>

<m:GetCurrentTemperature xmlns:m='WeatherStation'>

<m:scale>Celsius</m:scale>

</m:GetCurrentTemperature>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Cererea HTTP SOAP foloseste metoda HTTP POST. Desi pachetul SOAP poate fi transportat folosind alte metode cum ar fi HTTP GET, HTTP definit in specificatiile SOAP cere utilizarea metodei POST. POST specifica si numele serviciului accesat. In acest exemplu sunt trimise date la /LocalWeather, la hostul specificat mai tarziu in headerul HTTP.

Raspunsul HTTP

Un mesaj cerere RPC conduce de obicei la un raspuns HTTP corespunzator. Desigur daca serverul nu reuseste sa extraga informatia din headerele HTTP, el poate raspunde cu un tip de eroare HTTP. Dar presupunand ca headerele sunt procesate corect ne asteptam ca sistemul sa raspunda cu un mesaj SOAP. Raspunsul HTTP la cererea RPC pentru exemplul anterior se prezinta astfel:

HTTP/1.0 200 OK

Content-Type: text/xml; charset='utf-8'

Content-Length: 359

<SOAP-ENV:Envelope

xmlns:SOAP-ENV='https://schemas.xmlsoap.org/soap/envelope/'

SOAP-ENV:encodingStyle='https://schemas.xmlsoap.org/soap/encoding/'>

<SOAP-ENV:Body>

<m:GetCurrentTemperatureResponse xmlns:m='WeatherStation'>

<m:temperature>26.6</m:temperature>

</m:GetCurrentTemperatureResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Campurile din headerul raspunsului HTTP sunt, in cea mai mare parte similare celor din cerere. Codul 200 din prima linie a headerului raspunsului indica ca serverul a fost capabil sa proceseze pachetul SOAP XML. Nu mai e nevoie de nici un alt camp in headerul HTTP. Corelatia intre cerere si raspuns este realizata de faptul ca HTTP POST este implicit un mecanism cerere/raspuns. Se trimite cererea si se primeste raspunsul printr-o singura tranzactie.

2.5. Invelisul SOAP

Invelisul SOAP reprezinta tot continutul XML pentru o cerere sau un raspuns SOAP. Nivelul 'invelis' (envelope) este elementul XML de cel mai inalt nivel din mesaj si trebuie sa fie prezent pentru ca mesajul sa fie considerat valid. Asadar, invelisul reprezinta documentul XML ce contine mesajul SOAP. Invelisul poate contine un element de header optional care daca este prezent, trebuie sa fie primul subelement al invelisului. Plicul trebuie sa contina un element de body. Daca plicul contine subelementul 'header', atunci subelementul 'body' trebuie sa apara imediat dupa header; in restul cazurilor 'body' va fi primul subelement al invelisului.

Un plic SOAP impachetat si transportat folosind HTTP este similar cu un plic de hartie trimis prin serviciul de posta. Plicul SOAP corespunde plicului postal; headerul SOAP (daca este prezent) si corpul SOAP sunt continutul plicului; iar headerele HTTP corespund adresei fizice ce este specificata pe exteriorul plicului.

3. Servicii Web [2]

Un serviciu web este o bucata de logica de business, plasata la o locatie din Internet, ce este accesibila prin protocoale Internet cum ar fi HTTP sau SMTP. Folosirea unui serviciu web poate fi la fel de simpla ca logarea pe un site sau complexa precum facilitarea unei negocieri intre mai multi parteneri de afaceri.

Un serviciu web prezinta o serie de caracteristici comportamentale:

Bazat pe XML

Prin folosirea XML ca nivel de reprezentare a datelor pentru toate protocoalele si tehnologiile de servicii web, aceste tehnologii pot fi interoperabile la nivelul de baza al acestora. Ca transport de date, XML elimina orice dependenta intre protocol si retea, sistemul de operare sau platforma de calcul.

Cuplare slaba

Un consumator de servicii web nu este legat de acel serviciu web in mod direct; interfata serviciului web se poate schimba in timp fara a compromite abilitatea clientului de a interactiona cu serviciul. Intr-un sistem cuplat strans logica clientului si cea a serverului sunt strans legate, fapt ce implica ca daca interfata unuia se schimba si interfata celuilalt va trebui updatata. Adoptand o arhitectura cuplata slab conduce la realizarea unor module software mai flexibile ce permit o integrare mai simpla a diverselor sisteme.

Suporta apeluri de proceduri la distanta (RPC)

Prin folosirea unui protocol bazat pe XML, serviciile web permit clientilor sa invoce proceduri, functii si metode asupra unor obiecte aflate la distanta. Aceste proceduri 'remote' definesc parametrii de intrare si iesire pe care un serviciu web trebuie sa-i suporte. Dezvoltarea component orientata realizata prin intermediul JavaBean-urilor de nivel enterprise (EJB-uri) si al componentelor .NET, a devenit din ce in ce mai mult in ultimii ani o parte a aplicatiilor complexe. Ambele tehnologii sunt distribuite si accesibile printr-o varietate de mecanisme RPC. Un serviciu web suporta RPC prin furnizarea de servicii proprii, in mod echivalent cu cele oferite de o componenta traditionala, sau prin traducerea cererilor in apeluri catre un EJB sau o componenta .NET.

Suporta schimbul de documente

Unul din avantajele cheie al XML-ului, prezentat in capitolul 2, este modul sau generic de reprezentare nu numai a datelor, ci si a documentelor complexe. Aceste documente pot fi simple, cum ar fi reprezentarea unei adrese, sau pot fi complexe, cum ar fi reprezentarea unei carti. Serviciile web suporta schimbul transparent de documente pentru a facilita integrarea la nivelul logicii de business.

Tehnologiile principale ale serviciilor web

O serie de tehnologii legate de serviciile web au fost introduse si vor mai aparea si altele in anii ce vor urma. Aceste tehnologii sunt:

Simple Object Access Protocol (SOAP) - prezentat in capitolul 2

Web Service Description Language (WSDL)

WSDL este o tehnologie XML ce descrie interfata unui serviciu web intr-un mod standardizat. WSDL standardizeaza modul in care un serviciu web reprezinta extern parametrii de intrare si iesire a unui apel, modul de reprezentare al structurii functiei, natura invocarii (numai intrare, intrare/iesire). WSDL permite diversilor clienti sa inteleaga in mod automat cum sa interactioneze cu un serviciu web.

Universal Description, Discovery, and Integration (UDDI)

UDDI ofera un registru global de servicii web pentru publicarea, descoperirea si integrarea de servicii web. UDDI este utilizat pentru a descoperi servicii web disponibile prin cautarea de nume, identificatori, categorii sau specificari implementate de serviciile web. UDDI furnizeaza o structura pentru reprezentarea logicii de business, a relatiilor de business, serviciilor web, specificatiilor de tip metadate si punctelor de acces la serviciile web.

Arhitectura orientata pe servicii (SOA)

Modelul serviciilor web descrie o arhitectura puternic distribuita, numita arhitectura orientata pe servicii (SOA). Un serviciu web poate comunica cu procese si functii de sine statatoare sau poate participa intr-un proces complex de business. Un serviciu web poate fi publicat, localizat si invocat in cadrul intreprinderii sau oriunde pe web. arhitectura orientata pe servicii este utila atat pentru folosirea in Internet cat si pentru utilizarea intr-un intranet al unei companii sau al unui grup de parteneri de afaceri.

Servicii web intr-o arhitectura SOA complexa

4. Dezvoltarea de servicii Web pe platforma .NET [3]

Pe platforma .NET, System.Web.Services este spatiul de nume in care sunt incluse toate clasele necesare pentru crearea serviciilor web. Cele 3 subspatii de nume ale System.Web.Services sunt: Description, Discovery si Protocols.

Spatiul de nume System.Web.Services.Description

Acest spatiu de nume contine clasele necesare pentru a descrie un serviciu web folosind Microsoft SDL (limbajul de definire a serviciilor), o implementare Microsoft a standardului WSDL. Visual Studio .NET foloseste aceste clase pentru a crea fisierul de extensie .disco sau .vsdisco. Multe subclase ale acestui spatiu de nume specifica legaturi: MessageBinding, OperationBinding, OutputBinding si altele.

Spatiul de nume System.Web.Services.Discovery

SystemWeb.Services.Discovery consta in clase ce permit utilizatorilor de servicii sa localizeze serviciile web disponibile. In VS.NET, cand se creeaza o referinta web, aceste clase gasesc fisierele .vsdisco ce descriu servicii web.

Spatiul de nume System.Web.Services.Protocols

Acest spatiu de nume consta din clase ce sunt folosite pentru a defini protocoalele ce permit transmiterea de mesaje prin HTTP intre serviciile web ASP.NET si clientii acestora. Aceste clase sunt deseori implicate in formatarea, legarea si setarea mesajelor SOAP.

5. Dezvoltarea de servicii web pe platforma J2EE [2]

Serviciile web folosesc platforme de lucru standard pentru a extinde domeniul unei aplicatii. Totusi, un serviciu web nu este aplicatia in sine. Serviciul web trebuie sa fie implementat intr-o infrastructura de aplicatii ce ofera fiabilitate, disponibilitate, servicii de calitate, securitate si alte necesitati critice la nivelul intreprinderii.

Platforma J2EE incearca sa defineasca tocmai o asemenea infrastructura. De aceea, daca serviciile web si Java pot fi utilizate impreuna, iar J2EE reprezinta varianta Java a infrastructurii aplicatiilor, este important de vazut modul de functionare al serviciilor web sub aceasta platforma.

5.1. SOAP si J2EE

Deoarece SOAP este fundamentul interoperabilitatii si al serviciilor web, intelegerea modului de lucru intre J2EE si serviciile web revine la analiza modului de lucru intre SOAP si J2EE. SOAP este un protocol de transport ce este plasat deasupra altor protocoale de transport cum ar fi HTTP, FTP si SMTP. J2EE suporta aceste protocoale prin intermediul servletilor. De aceea, este normal ca servletii si tehnologia JSP sa devina punctul de intrare in platforma J2EE pentru serviciile web.

In primul rand, servletii sunt responsabili cu extragerea continutului SOAP din cadrul pachetelor primite prin retea. Continutul SOAP trebuie sa fie apoi parsat pentru ca servlet-ul sa obtina acces la elementele si atributele continute in documentul SOAP. Un servlet trebuie sa contina logica pentru: parsarea invelisului SOAP, validarea formatului mesajului, validarea XML, parsarea rapida a XML, legatura XML-Java.

Avand in vedere modul in care WSDL, JAXM si JAX-RPC definesc comportamentul serviciilor web, patru tipuri fundamentale de mesaje pot fi transportate prin SOAP:

Cerere/raspuns

Solicitare/raspuns

Unidirectional

Notificare

Aceste tipuri de mesaje duc la o provocare tehnica pentru arhitectii serverelor de aplicatii deoarece servletii au fost initial proiectati sa lucreze cu un comportament de tip cerere/raspuns. Un servlet ce suporta servicii web trebuie sa suporte in mod evident un comportament obisnuit cerere/raspuns; totusi, acesta trebuie sa suporte si comportament de tipul solicitare/raspuns si alte invocari initiate de server.

Dupa ce un servlet parseaza mesajul SOAP, acesta trebuie sa faca o invocare RPC sau sa livreze mesajul XML catre alta resursa, cum ar fi o destinatie JMS. Inainte de procesarea mesajului de urmatoarea resursa, servletul trebuie sa determine care este aceasta. Cum poate servletul realiza acest lucru? Un servlet are cateva optiuni in determinarea urmatorului pas al procesului:

Campul SOAPAction header

Acest camp poate contine informatii care indica destinatia JMS sau EJB ce trebuie apelata, sau poate contine informatii necesare pentru realizarea unui lookup intr-o tabela de rutare a serviciilor web pe care un server de aplicatii o suporta.

Determinarea prin WSDL

Daca serverul de aplicatii stie carui fisier WSDL ii apartine mesajul de intrare, fisierul WSDL poate fi util in indicarea modului de mapare intre destinatiile EJB, JMS si

mesajele SOAP. Un server de aplicatii poate oferi instrumente pentru maparea definitiilor de mesaje dintr-un fisier WSDL la resursele disponibile in cadrul serverului.

Continutul mesajului SOAP

Headerul si corpul mesajului SOAP pot contine informatii esentiale ce ajuta servletul in determinarea modului de rutare a mesajului.

Maparea informatiilor din header

Conversia informatiilor din headerul HTTP sau a elementelor din headerul SOAP in proprietati JMS pentru o filtrare pe partea de server poate fi de dorit, in special daca un raspuns la o cerere va fi manevrat asincron sau intr-un moment ulterior.

Apeluri RPC

Maparea apelurilor de servicii web la EJB-uri este importanta deoarece EJB-urile furnizeaza platforma de lucru necesara pentru implementarea de logica de business fiabila si de un grad inalt de disponibilitate. EJB-urile furnizeaza accesul la o serie de tehnologii enterprise si ofera o modalitate portabila de incapsulare a logicii de business necesara pentru interactionarea cu acestea. Maparea SOAP la EJB-uri este realizata prin intermediul unui generator de handlere SOAP.

In cazul unui EJB de tip sesiune fara stare, generatorul de handlere SOAP creeaza servletul ce serveste ca handler SOAP, creeaza descriptorii necesari deployment-ului si genereaza orice WSDL necesar pentru maparea mesajelor SOAP la un EJB. Generatorul de cod creeaza de asemenea orice legatura Java-XML ce trebuie sa existe. Acest proces permite dezvoltatorilor de EJB-uri sa se ocupe numai de crearea EJB-urilor ce implementeaza logica de business, nefiind nevoie sa se ocupe de semantica dezvoltarii SOAP. Se ofera astfel o tranzitie lina de la o paradigma la alta.

Apeluri de tip mesaj

O notiune importanta pentru interconectarea componentelor unui sistem web o reprezinta maparea unui punct final WSDL la o coada sau topic JMS (serviciul de mesagerie Java). Topicul sau coada pot fi un MDB (bean de mesaje) sau un client JMS de sine statator inregistrat ca ascultator.

Invocarea SOAP-JMS poate incepe in doua moduri. In primul mod, un mesaj SOAP trimis de client incepe un scenariu de tip cerere/raspuns sau o invocare unidirectionala ce face ca un mesaj JMS sa fie plasat la destinatie. In al doilea model, un mesaj este plasat intr-o destinatie JMS ce este monitorizata de un handler SOAP extern. Orice mesaj initiat de un client JMS este convertit in mesaj SOAP si livrat folosind un model de tip solicitare-raspuns.

Standardul Java Web Service (JWS)

Un nou standard propus pentru serviciile web este Java Web Service (JWS), implementat de BEA Systems.

JWS este un format proiectat pentru a usura munca pe platforma J2EE a dezvoltatorilor non-Java. La baza specificatiei JWS sta ideea conform careia dezvoltatorii nu creeaza componente J2EE. Acestia construiesc un serviciu web, si o singura clasa Java reprezinta implementarea serviciului web. Clasa Java are un numar de tag-uri JavaDoc simple, predefinite, ce indica implementari de comportament diferite ale serviciului web. Bazat pe valoarea tag-urilor JavaDoc inserate in clasa Java, un generator de cod creeaza toate componentele J2EE necesare implementarii serviciului.

Sistemul JWS JavaDoc contine tag-uri ce reprezinta o serie de comportamente ale serviciilor web, incluzand metode fara stare, metode cu stare si invocari asincrone. Provocarea ramasa implementarilor JWS este generarea de componente J2EE ce furnizeaza comportamentul descris de tag-urile JavaDoc intr-o maniera fiabila.

Propunerea JWS este interesanta deoarece ofertantii de instrumente se pot adapta prototipului BEA foarte usor. Conceptul de deployment al serviciului web este complet ascuns programatorului. Scopul este o platforma de lucru pentru dezvoltarea serviciilor web cu J2EE intr-un mod similar lucrului cu Visual Basic.

6. Concluzii

Serviciile web ofera un mediu distribuit in care aplicatii si componente de aplicatii diverse pot comunica intre ele cu usurinta intr-o maniera independenta de platforma si de limbajul de programare. Aceasta interoperabilitate aduce eterogenitate in lumea aplicatiilor distribuite.

Bibliografie

Robert Englander - "Java and SOAP", editura O'Reilly

David Chappell, Tyler Jewell - "Java Web Services", editura O'Reilly

3. David Jorgensen - "Developing .NET Web Services with XML", editura Syngress