Proiectarea Si Securitatea Orientata pe Servicii Web

Proiectarea Si Securitatea Orientata pe Servicii Web

Byadmin ianuarie 1, 2024

CAPITOLUL I

SERVICII WEB

1.1 Introducere

Într-o eră în care informația devine din ce în ce mai abundentă și din ce în ce mai necesară apare nevoia ca această informație să fie clasificată, ordonată, aranjată. Clasificarea și ordonarea informațiilor este vitală pentru evitarea acumulărilor inutile și nefolositore de informații, pentru perimarea acestora, arhivarea în mod constant și corect etc. Aceste acumulări de informații trebuie să fie strict la obiect, și corect este să avem doar informația care ne este utilă.

Domeniul gestiunii informațiilor abordează problema organizării, stocării și regăsirii în timp util a datelor de care dispunem despre un anumit subiect. Neîndoielnic că fiecare dintre noi ne confruntăm continuu cu această problemă. Agenda personală, cartea de telefon, sunt mijloace simple de organizare, păstrare și regăsire a datelor de care avem nevoie la un moment dat. Această problemă legată de stocarea informațiilor, organizarea și regăsirea lor a fost rezolvată cu ajutorul bazelor de date.

O bază de date este o colecție de informații corelate, referitoare la un anumit subiect sau colectate, organizate și memorate într-un anumit scop. Sistemul care permite colectarea, organizarea, memorarea și regăsirea informațiilor dintr-o bază de date se numește sistem de gestiune a bazelor de date. Acest sistem poate să fie unul convențional în care informațiile sunt stocate pe hârtie, depuse în dosare, registre, rafturi, încăperi, etc., sau poate să fie computerizat, caz în care informațiile sunt păstrate pe suport magnetic în volume, repertorii, fișiere pe suport magnetic. În cazul stocării informațiilor pe suport magnetic, operarea în baza de date se face prin intermediul unor programe.

S-a ajuns astfel la o situație în care fiecare firmă sau instituție trebuie să își dezvolte propriul sistem informatic de gestionare a bazei de date, dat fiind faptul că încă nu există un sistem informatic atât de general și de flexibil încât să se adapteze cerințelor oricărei organizații, cu atât mai mult, pentru o societate comercială, posibilitatea de a lucra nemijocit cu clientul (local, dar și la distanță) este o oportunitate deosebită. Prin realizarea ieșirii pe Internet și dând clientului posibilitatea să găseasca singur, de acasă, toate informațiile, ba mai mult, dând posibilitatea să vizualizeze cataloage de produse, devize și lucrări de referință reprezintă un pas important în realizarea integrării propriilor date și sisteme de afaceri cu alți oameni și alte firme din țară și din străinătate.

Webul a fost inventat în 1989 la Centrul European de Cercetări Nucleare (CERN) din Geneva, Elveția. Propunerea inițială de creare a unei colecții de documente având legături între ele a fost făcută de Tim Berners-Lee în martie 1989. Propunerea a apărut în urma problemelor de comunicare pe care le întâmpinau echipele de cercetători ce foloseau centrul, chiar și folosind poșta electronică.

Primul prototip al acestei colecții (mai întâi în format de text simplu) a apărut nu mult înainte de decembrie 1991, când s-a făcut prima lui demonstrație publică. Studiul a fost continuat prin apariția primei aplicații grafice Mosaic, în februarie 1993, realizată de cercetătorul Marc Andreessen de la centrul universitar National Center for Supercomputing Applications (NCSA) din orașul Urbana-Champaign din statul federal Illinois, SUA.

Un serviciu Web este o metodă de comunicare între două dispozitive electronice din cadrul internetului. Un serviciu web se mai poate defini ca fiind un set de protocoale și standarde folosite pentru schimbul de informații între aplicații sau sisteme. Aplicatiile software realizate în limbaje de programare diferite și care rulează pe diferite platforme pot folosi servicii web pentru a intershimba date pe Internet, într-un mod asemănător comunicării inter-procese pe un singur calculator.

Serviciul Web este bazat pe un set minim de concepte: seviciu, document XML, adresă, plic. În plus, toate serviciile Web trebuie să expună o interfață care este exprimată folosind WSDL (Web Service Definition Language). Mesajele conținute de plic și interfețele WSDL sunt bazate pe XML. O definiție mai formală a unui serviciu Web, bazată pe documentele W3 Consortium, organismul care se ocupă de elaborarea standardului pentru ele. Astfel un serviciu Web este o aplicație identificată printr-un URI (Uniform Resource Identifier) ale cărei interfețe și legături pot fi definite, descrise și descoperite folosind XML și pot interacționa în mod direct cu alte aplicații folosind mesaje bazate pe XML și protocoale Internet standard.

W3C definește "serviciul web" ca "un sistem proiectat pentru a sprijini interoperabilitatea mașină-mașină pentru a interacționa într-o rețea". Acesta are o interfață descrisă într-un format mașină care procesează informații (în special limbajul de descriere a serviciilor web, cunoscut prin acronimul WSDL). Alte sisteme interacționeaza cu serviciul Web prin intermediul mesajelor SOAP, de obicei, transmise prin HTTP, cu o serializare XML împreună cu alte standarde legate de Web.

Figura nr. 1.1 – Funcționarea serviciilor Web

"Big Web services", utilizează Extensible Markup Language (XML), si anume, mesaje care urmaresc standardul SOAP și au fost populare printre întreprinderile tradiționale. În astfel de sisteme, există adesea o descriere care poate fi citită automat de catre serviciile scrise în Web Services Description Language (WSDL). Acesta din urmă nu este o cerință a unui un obiectiv SOAP, dar este o condiție esențială pentru generarea automată a codului client în majoritatea framework-urilor Java .NET SOAP (framework, cum ar fi Apache Axis2, iar ca excepții CXF Apache și Spring).

Termenii de Internet și World Wide Web sunt des utilizați în vorbirea de zi cu zi fără a face mair diferențe între termeni. Totuși Internetul și World Wide Web nu sunt una și aceeași. Internetul este un sistem global de rețele interconectate, iar Web-ul este unul dintre serviciile care face ca internetul să funționeze. Este o colecție de documente text și alte resurse legate prin hyperlinkuri și URL-uri, de obicei accesate de browsere web din servere web. Pe scurt, ne putem gândi la Web ca la o aplicație cu ajutorul căreia Internetul funcționează.

Pentru a vizualiza o pagină pe World Wide Web începem prin tastarea URL-ului paginii într-un browser web sau prin a urma un hyperlink pe pagina respectivă sau resursă.

În primul rând, browserul rezolva porțiunea de nume-server a URL-ului (google.ro) într-o adresă de Protocol Interne utilizând baza de date distribuită global, cunoscută sub denumirea de Domain Name System (DNS). Browserul apoi cere sursa prin transmiterea unei cereri HTTP prin intermediul internetului la calculator, la acea adresă specificată.

Un serviciu Web (SW) expune o interfață de invocare a unei activități de către un client. Un client poate accesa un serviciu Web folosind standarde Internet. Un serviciu web rezolvă următoarele probleme:

interoperabilitate – un SW trebuie să permită comunicarea între orice platforme;

interfețe puternic tipizate – nu trebuie să existe ambiguitate relativ la tipul de date trimise sau primite spre/de la un SW. Aceste tipuri de date ar trebui să se poată mapa rezonabil peste tipurile de date folosite de limbajele procedurale existente;

folosirea standardelor Internet – implementarea unui SW trebuie să se bazeze pe standardele și protocoalele de comunicare deja existente, pentru a evita “reinventarea roții”

acces multilimbaj – un SW nu trebuie să reducă aria limbajelor care le pot utiliza; transparența trebuie să se manifeste atât la nivelul limba- jului în care s-a creat SW, cât și la nivelul clientului;

posibilitate de integrare în orice infrastructură distribuită – un SW nu trebuie să fie strâns cuplat de o anumită infrastructură de comunicare.

Astăzi, Web-ul reprezintă vîrful de lans al dezvoltării tehnologiilor Internet.

Internetul este o comunitate de rețele de calculatoare, un mediu informatic global cu resurse imense și o gamă largă de servicii. Se aproximeaza ca in internet sunt interconectate circa 120.000 rețele, 50 milioane stații de pe toate continemtele, din peste 150 de țări. Cu alte cuvinte internetul este o rețea din mai multe rețele.

Resursele internet sunt construite din:

– servere – calculatoare-gazdă la care se stochează informația și care prestează diverse servicii informatice;

– zeci de milioane de fișiere, baze de date în cadrul serverilor cu informații din cele mai diverse domenii;

– subsistemul de comunicație, ce asigură interconectarea și transferul de date între stații.

1.2 Arhitectura orientată pe servicii

Serviciile Web pot fi, de asemenea, folosite pentru a pune în aplicare o arhitectură orientată pe servicii (SOA), concepte, în cazul în care unitatea de bază a comunicare este un mesaj, mai degrabă decât o operație. Acest lucru este adesea menționat ca "mesaj"-orientat spre servicii.

SOA, serviciile Web sunt acceptate de majoritatea furnizorilor de software și de catre analiștii din industrie. Spre deosebire de serviciile Web RPC, aici accentul este pus pe “contractul” oferit de WSDL, mai degrabă decât pe detaliile care stau la baza implementării.

SOA, ca și arhitectură se bazează pe servicii de orientare, iar principiul fundamental este designul său. În cazul în care un serviciu prezintă o interfață simplă care abstractizeaza de departe complexitatea sa de bază, utilizatorii pot accesa serviciile independente, fără a avea cunoștințe de implementare a platformei de servicii.

Figura nr. 1.2 – Arhitectura serviciilor web

Un serviciu web este un serviciu pus la dispoziție utilizatorilor pe Internet. Multitudinea de protocoale și standarde disponibile începând de la sfârșitul secolului trecut în sfera Internetului au dat posibilitatea comunicării între aplicații pe sisteme aflate la distanțe mari, cu acces la Internet. Astfel, există sisteme ce oferă servicii de informare și procesare a informațiilor care în general sunt independente de platforma hardware; accesul la acestea se face prin servicii web.

Încă de la realizarea primei rețele de calculatoare accesibile prin TCP/IP, numită ARPANET, accesarea de informații rezidente pe un alt calculator decât cel curent și mai ales execuția unor rutine găzduite de altă mașină au devenit foarte importante. Pentru manipularea datelor între calculatoare, au fost inventate o serie de mecanisme și protocoale, parte din ele fiindu-vă descrise în alte cursuri (socket, FTP, HTTP, etc).

Printre marile companii de profil se numără și compania de software IBM care a lansat noi produse si servicii menite sa faciliteze eforturile clientilor de a profita mai rapid si mai usor de tendintele in crestere ale pietei privind adoptarea unei Arhitecturi Orientate pe Servicii (Service Oriented Architecture – SOA). Principalele obstacole care impiedică succesul unei SOA sunt deseori legate de stabilirea modului de a aborda o astfel de arhitectură, astfel încât să se evite costurile suplimentare și să se asigure că investițiile sunt alocate unei strategii de afaceri care va rezista fluctuațiilor pieței și schimbărilor din cadrul companiei.

Pentru a sprijini strategiile bazate pe SOA și pentru a fi centrate pe oameni, versiunea 6.0 a platformei WebSphere Portal integrează IBM Workplace și tehnologii colaborative capabile să faciliteze eforturile utilizatorilor de a dezvolta și implementa aplicații complexe care pot fi adaptate conform industriei căreia li se adresează. Noua platformă are la baza aplicația AJAX (Asynchronous JavaScript and XML) și este capabilă să creeze un mediu mult mai receptiv pentru utilizatori.

Ideea fundamentală a serviciilor Web este integrarea. Acest concept reprezintă un set de tehnologii standard care facilitează interoperabilitatea dintre sisteme heterogene, fie la nivel de organizație, fie pe Internet.

De fapt, serviciile Web sunt o formă de distribuție flexibilă, ieftină și eficientă a resurselor la nivel intra sau inter orginter organizațional, indiferent de tipul de aplicații sau platforme de operare folosite.

CAPITOLUL 2

SOA – SERVICE ORIENTED ARHITECTURE

2.1 Conceptul SOA

SOA (Service Oriented Architecture – Arhitectură software bazată pe servicii) este un tip de arhitectură software care presupune distribuirea funcționalității aplicației în unități mai mici, distincte – numite servicii – care pot fi distribuite într-o rețea și pot fi utilizate împreună pentru a crea aplicații destinate afacerilor. Capacitatea mare cu care pot fi reutilizate aceste servicii în aplicații diferite este o caracteristică a arhitecturilor software bazate pe servicii. Aceste servicii comunică între ele trimițând informații de la un serviciu la altul. SOA este deseori văzută ca o evoluție a programării distribuite si a programării modulare. Arhitectura Orientata pe Servicii (SOA) este un grup de servicii care comunica intre ele. Procesul de comunicare implica atat schimburi simple de date intre un furnizor de servicii si beneficiarul acestora, cat si un sistem complex de sisteme intre doi sau mai multi furnizori. Inter-comunicarea implica gasirea unor legaturi de conectare a doua sau mai multe servicii intre ele.

SOA construieste aplicațiile în afara serviciilor software. Serviciile cuprind în mod intrinsec unități de funcționalitate neasociate și interconectate imprecis, care nu conțin caracteristici de conectivitate. Fiecare serviciu implementează o singură acțiune, de exemplu, completarea unei aplicații on-line pentru un cont, vizualizarea unui extras de cont bancar on-line, plasarea unei rezervări on-line sau unui număr de ordine pentru biletele de avion. În locul apelărilor cuprinse în codul sursă al serviciilor, se folosesc protocoale definite care descriu modul în care unul sau mai multe servicii pot comunica.

Scopul SOA este acela de a facilita conectarea unor părți consistente ale functionalităților, prin utilizarea serviciilor software existente, pentru a putea forma aplicații ad-hoc construite în întregime. Cu cât sunt mai mari sunt aceste părți, cu atat mai puține sunt punctele de interfață necesare implementării seturilor de functionalități. În ceea ce privește costurile periferice ale construirii unei aplicații suplimentare, SOA a demonstrat că acestea sunt scăzute deoarece există toate componentele software necesare pentru a satisface cerințele altor aplicații. În mod ideal, este nevoie doar de organizare pentru a produce noi aplicații.

Dezvoltatorii SOA asociază obiectele individuale SOA prin utilizarea orchestrației. În procesul de orchestrare dezvoltatorul asociază funcționalitatea softului (serviciile), într-un regim non-ierarhic folosind un instrument software care conține o listă completă a tuturor serviciilor disponibile, caracteristicile acestora, precum și mijloacele de a construi o cerere de utilizare acestor surse.

SOA oferă așa numita arhitectură de perspectivă și anume, poate unifica procesele de business prin structurarea aplicațiilor mari sub forma unei colecții de module mai mici, numite servicii. Astfel, grupuri diferite de utilizatori, atât din interiorul unei organizații, cât și din exteriorul acesteia, pot folosi aceste aplicații, dar și noile aplicații mai flexibile și cu o uniformitate mai mare, construite dintr-un conglomerat de servicii.

Fiecare companie are propriile „insule” de active corporative – angajații, furnizorii, partenerii (și informații despre aceștia) sau infrastructura IT existentă – care trebuie conectate și mai apoi puse în slujba atingerii obiectivelor companiei. Una dintre cele mai eficiente și eficace metode de integrare a aplicațiilor este printr-o Arhitectura Orientată pe Servicii (Service Oriented Architecture – SOA). SOA este o abordare de prelucrare distributivă, care implică crearea și administrarea de servicii separate (verificare creditului clientului, crearea unei inregistrări), care poate accesa activele companiei și părți de informații printr-o interfață comună, indiferent de locația sau particularitățile tehnice ale datelor. Aceste servicii sunt evidențiate și administrate într-o manieră de asociere liberă, care este concepută să maximizeze reorganizarea lor și să fie folosite, datorită extensiei lor, în procesele de business.

Baza pentru validarea acestora necesită date suficient de detaliate pentru a descrie nu numai caracteristicile acestor servicii, ci și datele care le conduc. Programatorii au utilizat intens XML în SOA pentru a structura datele pe care apoi le-au învăluit într-o descriere exhaustivă. În mod analog, Web Services Description Language (WSDL) descrie serviciile în sine, în timp ce protocolul SOAP descrie protocoalele de comunicare.

2.2 Principii SOA

Urmatoarele principii definesc regulile de bază pentru dezvoltarea, menținerea și utilizarea SOA:

Reutilizarea, granularitatea, modularitate, componentele și interoperabilitatea.

Conformitatea cu standardele (comune și specifice industriei)

Servicii de identificare și de clasificare, aprovizionare și de livrare, precum și monitorizare și urmărire.

Prima lucrare de cercetare referitoare la orientarea serviciilor dintr-o perspectivă industrială a fost elaborată de către Thomas Erl de la SOA Systems Inc. care a definit 8 principii specifice tuturor platformelor SOA. Aceste principii au fost publicate în “Arhitectura Orientată spre Servicii: Concepte, tehnologie și proiectare”, pe site-ul de cercetare www.soaprinciples.com în septembrie, 2005.

Contract de servicii standardizate – Serviciile aderă la un acord de comunicații, așa cum sunt definite în mod colectiv de către unul sau mai multe servicii de descriere documente.

Cuplajul slab – Servicii de a menține o relație care minimizează dependența și impune numai menținerea unei conștientizări reciproce.

Abstractizarea serviciului – Dincolo de descrierile din contractul de servicii, acestea ascund logica din lumea exterioară.

Serviciu reutilizabil – Logica este împărțită în servicii, cu intenția de a promova reutilizarea.

Autonomia serviciilor – Serviciile dețin controlul asupra logicii pe care o încapsulează.

Granularitate serviciului – O atenție deosebită este acordată design-ului pentru a oferi domeniului de aplicare nivelul optim, dreptul granular al funcționalității de afaceri într-o operațiune de serviciu.

Serviciu cu condișie de apatrid – Serviciu de minimizare a consumului de resurse, de gestionare a informațiilor atunci când este necesar.

Vizibilitatea serviciului – Serviciile sunt completate cu date prin care acestea pot fi descoperite și interpretate în mod eficient.

Componența serviciului – Serviciile în care componentele se comportă ca niște particpanți activi și eficienți, indiferent de mărimea și complexitatea compoziției.

Cheia livrării unor procese de business îmbunătățite se află în armonizarea noilor procese și aplicății cu infrastructura existentă, incluzând tehnologii de genul Enterprise Resource Planning (ERP) și customer relationship management (CRM – reprezintă un set de strategii, politici și tehnologii destinate atragerii, reținerii și fidelizării clienților. Într-un sens larg, CRM include activitățile aferente departamentelor de marketing, vânzări, financiar și suport tehnic relativ la clienți, potențiali clienți, furnizori și parteneri). O soluție eficientă de BPM va susține conceptul și implementarea SOA și aplicațiile adiacente. Orice soluție trebuie să aducă beneficii la final, fără a neglija ceea ce funcționează. Este importantă asigurarea tehnologiei care să permită utilizatorilor să identifice procesele afacerii printr-o notație grafică clară. Vitale sunt și capacitatea de execuție a acelui proces; facilitarea integrării sistemelor deja existente și a pachetele comerciale disponibile; și apoi analizarea și administrarea funcționării împreună a acestor procese. Enterprise Concept folosește o abordare unică și independentă a proceselor care separă logica proceselor afacerii de nivelul aplicațiilor, făcând integrarea mult mai lină și mai adaptabilă modificărilor ulterioare.

Figura nr. 2.1 – Arhitectura sistemelor CRM

O direcție importantă în dezvoltarea sistemelor distribuite și a sistemelor IT pentru servicii este adoptarea arhitecturii orientate pe servicii – SOA (Service Oriented Architecture). Aceasta este capabilă să susțină implicarea unor multiple organizatii furnizoare de servicii si, în același timp, să păstreze independența acestora în ceea ce privește platformele pe care le aleg și a limbajelor în care realizează implementarea. Serviciile software din arhitecturile SOA pot fi executate pe diferite calculatoare, ale diferiților furnizori de servicii, pot fi furnizate local sau externalizate, pot fi implementate în orice limbaj de programare și pot încapsula sisteme moștenite ale diferitelor organizații. De asemenea, ele pot avea diferite modele de plată: disponibilitate gratis, plata prin abonament sau plata la fiecare utilizare.

Aceste servicii pot avea scopuri extrem de variate, precum prelucrarea datelor, raționalizarea, reutilizarea funcționalităților încorporate în sisteme moștenite, sau integrarea activităților efectuate de mai mulți parteneri de afaceri. Arhitecturile permit o distribuire largă a artefactelor software; agilitatea și extensibilitatea pot fi crescute prin folosirea serviciilor descoperite la momentul execuției, adesea folosind tehnologii semantice.

Figura nr. 2.2 – Arhitectura orientată pe servicii

Având în vedere caracteristicile acestor tipuri de arhitecturi se poate spune că SOA prin componentele sale bine coordonate își propune să furnizeze o serie de servicii bussines complexe și bine definite. Astfel de servicii sunt concepute ținând cont de cele mai bune practici în conducerea afacerilor cunoscute sub numele de business process management. Însă pentru o implementare eficientă a SOA trebuie îndeplinite și anumite condiții tehnice referitoare la infrastructură cum ar fi:

Existența componentelor necesare pentru dezvoltarea aplicațiilor personalizate: servicii de date, autentificare și audit, platforme de căutare și notificare;

Platforme de securitate care să permită autorizarea și autentificarea utilizatorilor;

Servicii de date integrate pentru suportul SOA ;

Servicii de tip portal pentru interacțiunea utilizatorilor;

Servicii prezente în mod obișnuit intr-o companie cum ar fi :e-mail,colaborative, LDAP( un protocol aplicație folosit pentru interogarea și modificarea serviciilor de directoare prin intermediul TCP/IP)

Adoptarea conceptului SOA în cadrul unei companii presupune într-adevăr o tranziție. Iar această trecere nu trebuie să fie scopul, ci mijlocul prin care o companie își susține obiectivele și strategiile de business, prin urmare, etapele acestei tranziției către SOA sunt specifice fiecărei companii. Înainte de toate, este necesară o pregătire pentru tranziția către SOA, de acumulare a unor competențe specifice, printre care abilitatea de a măsura stadiul de pregătire a companiei pentru o astfel de adopție și capabilitatea de a identifica și măsura beneficiile pe care SOA le poate aduce către business și IT. De asemenea, trebuie realizată o identificare a inițiativelor de business care pot fi susținute prin adopția SOA. De cele mai multe ori, există înțelegerea greșită că tranziția către SOA presupune achiziția și implementarea unor tehnologii SOA.

Guvernarea SOA este un framework pentru luarea deciziilor și identificarea rolurilor într-o organizație, așa încât să asigure ca acțiunile IT sunt sincronizate cu strategiile companiei. Acest framework este definit de un grup sau un comitet responsabil de crearea regulilor de guvernare, de definirea rolurilor, a procesului de decizie, a responsabilităților persoanelor implicate în luarea deciziilor, a responsabilității rolurilor de execuție.

2.3 Avantajele si riscurile SOA

Avantajele arhitecturii SOA:

Interoperabilitatea intrinsecă între diferite sisteme și limbaje de programare reprezintă baza pentru integrarea de diverse aplicații printr-un protocol de comunicare;

Agregarea datelor și a serviciilor/funcționalităților în scopul realizării și întreținerii fluxurilor de date între toate sistemele/aplicațiile din cadrul soluției integrate.

Principiile arhitecturii SOA definesc atât reguli pentru proiectare, cât caracteristicile specifice unei astfel de arhitecturi:

Abstractizarea, întrucât serviciile ascund logica de procesare și sunt prezentate doar la nivel de interfețe;

Descoperirea serviciilor se realizează prin mecanisme facile, de exemplu prin intermediul unui repozitoriu de servicii;

Cuplarea slabă între module și encapsularea serviciilor, de exemplu prin servicii web;

Granularitate fină până la un nivel relevant din perspectiva utilizatorului, modularitate și interoperabilitate;

Conformarea cu anumite standarde în vederea asigurării schimbului de informații între diverse servicii:

Identificarea, categorisirea, livrarea și monitorizarea serviciilor existente.

Riscuri:

În cadrul procesului de proiectare sunt luate în considerare riscurile unui proiect software în vederea asigurării unui management eficient al riscurilor. Printre acestea se numără:

factori tehnologici: noutatea tehnologică, metodele de dezvoltare, instrumentele de dezvoltare;

factori de design: design defectuos din punct de vedere al complexității, modularizării; depistare erori neprevăzute în specificarea inițială a sistemului;

factori externi: calitatea specificației cerințelor, stabilitatea cerințelor și numărul de modificări ale specificațiilor, calitatea definirii, stabilitatea și disponibilitatea interfețelor externe;

factori de management de proiect: Deficiența de comunicare și de coordonare a activităților, riscuri de planificare printre care: estimarea eronată a resurselor umane, a perioadelor de timp, definirea responsabilităților.

Abordarea Smart SOA oferă avantaje atât pentru afacere, cât și pentru IT, prin extinderea valorii de business a implementării de la proiectele elementare la cele avansate. Abordarea Smart SOA necesită ca fiecare proiect să fie simplu și robust, eliminându-se complexitatea inutilă și construindu-se o fundație solidă pentru dezvoltarea viitoare.

Bazat pe o experiență vastă de lucru cu clienții și partenerii în domeniul aplicării SOA, firma Oracle a dezvoltat Oracle SOA Model de maturitate care oferă factorilor de decizie un punct de referință pentru a evalua nivelul de maturitate SOA al organizației lor.

Modelul Oracle SOA de maturitate pune mai departe oferă un punct vedere realist afacerii și o tehnologie pentru ceea ce este nevoie în cadrul companiei astfel încât adoptarea SOA sa fie realizată cu succes. Acest model are cinci nivele distincte de maturitate SOA, de la nivel 1 – SOA oportunist în care sunt tratate primele proiecte SOA până la nivel 5 de industrializare care este integrat la nivel intern, dar și cu partenerii de afaceri și prin care se pot valorifica noi oportuniăți de afaceri.

Fiecare nivel este în primul rând desemnat de o viziune și o strategie și este asociat cu beneficiile corespunzătoare. O companie poate începe drumul spre SOA cu un nivel de 3 de viziune, care este automatizarea strategică a afacerii, dar și de transformare. În acest caz, sfatul este aceța de a luaîn considerare punerea în aplicare a uneia dintre cele mai bune practici încadrate la nivelurile 1 și 2.

Figura nr. 2.3 – Modelul de maturitate SOA al firmei Oracle

CAPITOLUL 3

SOAP – SIMPLE OBJECT ACCESS PROTOCOL

3.1 Prezentare SOAP

Aplicatiile din ziua de azi comunica folosind Proceduri de Comunicare la Distanta (RPC –Remote Procedure Calls) intre obiecte cum ar fi DCOM si COBRA, dar HTTP nu a fost proiectat pentru acest lucru. RPC reprezinta o problema de compatibilitate si securitate; firewalls-urile si serverele proxy vor bloca in mod normal acest tip de traffic.

Un mod mai bun de comunicare intre aplicatii este prin HTTP, deoarece HTTP este suportat de toate browser-ele si serverele de internet.

SOAP ofera un mod de comunicare intre aplicatii care ruleaza pe sisteme diferite , cu tehnologii si limbaje de programare diferite.

SOAP inseamna 'Simple Object Access Protocol', mai exact este un protocol de apel al unor functii de pe alte servere folosind XML pentru codificarea numelor de functie apelate, parametri si returnarea rezultatelo; acest protocol presupune 3 parți: un înveliș care definește un framework pentru descrierea conținutului unui mesaj și cum se procesează acesta, un set de reguli de codificare pentru instanțe ale unor expresii din aplicații – tipuri de date definite, și o convenție pentru reprezentarea apelurilor și răspunsurilor procedurilor apelate la distanta. SOAP poate fi utilizat in combinație cu o varietate de alte protocoale, in special in combinație cu HTTP.

SOAP este:

un protocol de comunicație;

folosit pentru comunicația între aplicații;

un format pentru trimiterea de mesaje;

proiectat pentru comunicarea în Internet;

independent de platformă:

independent de limbaj.

Acronimul SOAP a fost abandonat odata cu versiunea 1.2 a standardului. Aceasta versiune a devenit o recomandare W3C incepand cu 24.06.2003.

Rareori acest acronim este confundat cu SOA, deși aplicatiile nu au nicio relație.

SOAP a fost proiectat, original, de catre Dave Winer, Don Box, Bob Atkinson si Mohsen Al-Ghosein in 1998 intr-un proiect pentru Microsoft (unde Atkinson si Al-Ghosein lucrau deja la momentul respectiv) ca un protocol de apel.

Dupa introducerea SOAP, a devenit baza pentru mai multe servicii complexe de Web, bazate pe Web Services Description Language (WSDL – Limbajul de Descriere a Serviciilor Web care este un limbaj bazat pe XML ce oferă un model de descriere a serviciilor web) si Universal Description Discovery and Integration (UDDI – ce permite localizarea și publicarea serviciilor). Aceste servicii, in special UDDI, s-au dovedit a fi de un interes scazut, dar o apreciere a acestora oferă o înțelegere mai completă a rolului așteptat de catre SOAP în comparație cu modul în care serviciile web au evoluat de fapt.

3.2 Blocuri de constructie SOAP

Un mesaj SOAP este un document XML normal care conține următoarele elemente (Figura nr. 3.1):

un element Plic care identifică documentul XML drept un mesaj SOAP;

un element Antet care conține informația din antet;

un element de Conținut care conține informația de comunicare și răspuns;

un element Defect care conține erorile și informatiile de status.

Figura nr. 3.1 – Structura SOAP

Reguli de sintaxa:

Regulile de sintaxa cele mai importante in SOAP sunt:

un mesaj SOAP TREBUIE codificat folosind XML;

un mesaj SOAP TREBUIE să folosească spațiul de nume Plic;

un mesaj SOAP TREBUIE să folosească Codificarea spațiul de nume;

un mesaj SOAP NU trebuiă să conțină referinte DTD;

un mesaj SOAP NU trebuie să conțină Porcesarea Instrucțiunilor XML.

Elementul Plic SOAP

Elementul Plic SOAP este elementul rădăcină a unui mesaj SOAP. Elementul Plic SOAP cerut este elementul rădăcină a unui mesaj SOAP. Acest element defineste documentul XML drept un mesaj SOAP. Spațiul de nume definește Plicul drept un Plic SOAP. Dacă este folosit un spațiu de nume diferit, aplicația generează o eroare și nu ia în considerare mesajul.

Stilul de codificare al Atributului

Stilul de codificare al Atributului este folosit pentru definirea tipului de date folosite în document. Acest atribut poate apărea la orice element SOAP, și se aplică conținutului elementului și tuturor elementelor copil. Un mesaj SOAP nu are nici o codificare implicită.

Elementul Defect SOAP

Elementul Defect SOAP conține erorile și informația status pentru un mesaj SOAP, este folosit pentru indicarea mesajelor de eroare. Dacă un element Defect este prezent, trebuie să apară ca un element rezultat al elementului Conținut. Un element Defect poate apărea doar o dată într-un mesaj SOAP.

Elementul Defect SOAP are următoarele sub elemente:

<faultcode> Un cod pentru identificarea defectului

<faultstring> O explicație citibilă a defectului

<faultactor> Informații despre cine a provocat apariția defectului

<detail> Conține erori specifice aplicației relative la elementul Conținut

Figura nr. 3.2 – Protocolul de schimb de mesaje

Coduri Defect SOAP

Valorile Codului Defect definite mai jos trebuiesc folosite în elementul codului defect când sunt descrise defecte:

Tabelul nr. 3.1

O cerere SOAP ar putea fi un POST HTTP sau o cerere HTTP GET. Cereea HTTP POST necesită cel putin două antete HTTP: Conținut-Tip și Conținut-Lungime

Continut-Tip

Antetul Continut-Tip pentru un răspuns/cerere SOAP definește tipul MIME pentru mesajul și codificarea caracterului (opțional) folosit pentru corpul XML al cererii sau al răspunsului.

Conținut-Lungime

Antetul Conținut-Lungime pentru un răspuns/cerere SOAP specifică numărul de byti în corpul cererii sau răspunsului.

3.3 Specificații SOAP și model de procesare

Specificațiile SOAP definesc cadrele de mesaje care constau în:

Modelul de procesare SOAP definește regulile de procesare a unui mesaj SOAP;

Extensibilitatea modelului SOAP definelte conceptele caracteristicilor SOAP și modulelor SOAP;

Protocolul cadru SOAP este baza pentru descrierea regulilor de definire a unui protocol obligatoriu care poate fi utilizat pentru schimbul de mesaje SOAP și noduri SOAP.

Construcția mesajului SOAP definește structura unui mesaj SOAP.

Model de procesare

Modelul de procesare SOAP descrie un model de procesare distribuit, participanții săi, nodurile SOAP, și modul în care un receptor SOAP procesează un mesaj SOAP. Astfel, sunt definite urmatoarele noduri SOAP:

a. Emitator SOAP

Un nod SOAP care transmite un mesaj SOAP

b. Receptor SOAP

Un nod SOAP care accepta un mesaj SOAP

c. Calea mesajului SOAP

Set de noduri SOAP, prin care un singur mesaj SOAP poate trece.

d. Emitatorul initial SOAP (initiatorul)

Expeditorul SOAP care inițiază un mesaj SOAP de la punctul de plecare al unei căi de mesaj SOAP.

e. Intermediarul SOAP

Un intermediar SOAP este atât un receptor și un expeditor SOAP și este vizat din cadrul unui mesaj SOAP. Acesta procesează blocuri antet SOAP orientate catre el și acționează pentru a transmite un mesaj SOAP către un receptor SOAP final.

f. Receptor SOAP final

Receptorul SOAP, care este o destinație finală a unui mesaj SOAP, este responsabil pentru procesarea conținutul SOAP, precum și de orice blocuri SOAP antet orientate catre el. În anumite circumstanțe, este posibil ca un mesaj SOAP sa nu poata ajunge la un receptor SOAP final, de exemplu, din cauza unei probleme la un intermediar SOAP. Un receptor SOAP final nu poate fi, de asemenea, un intermediar SOAP pentru același mesaj SOAP.

3.4 Metode de transport

Atât SMTP și HTTP sunt protocoale valide de aplicare, utilizate ca transport pentru SOAP, dar HTTP a câștigat un grad de acceptare mai larg care funcționează foarte bine cu infrastructura de internet de astăzi, în mod special, HTTP funcționează bine cu firewall-uri de rețea. SOAP poate fi, de asemenea utilizat peste HTTPS (care este protocolul HTTP la același ca la nivel de aplicație, dar utilizează un sub-protocol criptat de transport), fie cu autentificare simpla sau reciprocă.

Acesta este un avantaj major față de alte protocoale, precum GIOP / IIOP sau DCOM care sunt în mod normal filtrate de firewall. SOAP peste AMQP este încă o posibilitate pe care unele implementări o suporta.

3.5 Formatul mesajului SOAP

XML a fost ales ca format de mesaj standard, din cauza utilizării sale pe scară largă de către marile corporații și a eforturilor de dezvoltare „open source”. În plus, o mare varietate de instrumente disponibile gratuite facilitează în mod semnificativ trecerea la o punere în aplicare pe bază SOAP. Sintaxa, oarecum de lungă durată, a XML poate fi atât un avantaj, cât și un dezavantaj. În timp ce promovează lizibilitate pentru om, facilitează de detectarea erorilor, și pentru a evita problemele de interoperabilitate, cum ar fi octet-comandă (Endianness), aceasta poate încetini viteza de procesare și poate fi greoaie. De exemplu, CORBA, GIOP, ICE, și dispozitivele hardware sunt disponibile pentru a accelera procesarea de mesaje XML.

Exemplu de mesaj:

POST /InStock HTTP/1.1

Host: www.google.com

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 299

SOAPAction: "http://www.w3.org/2003/05/soap-envelope"

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Header>

</soap:Header>

<soap:Body>

<m:GetStockPrice xmlns:m="http://www.google.com/stock">

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>

3.6 Avantajele și dezavantajele SOAP

Avantaje:

Prin utilzarea SOAP cu HTTP se permite o mai bună comunicație în spatele unui proxy sau firewall decât presupunea precedenta tehnologie de apel la distanță.

SOAP este destul de versatil pentru a permite utilizarea protocoalelor de transport diferite. Structura de date standard utilizează HTTP ca protocol de transport, dar alte protocoale sunt de asemenea utilizabile (TCP, SNMP).

Dezavantaje:

Deoarece formatul XML este lung, SOAP poate fi destul de lent în comparație cu tehnologiile middleware, cum este CORBA. Aceasta nu constituie o problemă când se trimit numai mesaje scurte.

Când ne bazăm pe HTTP ca protocol de transport, rolurile părților care interacționează sunt stabilite. Doar o parte (clientul) poate utiliza serviciile altuia. Deci, dezvoltatorii trebuie sa utilizeze polling în schimbul notificării în aceste cazuri comune.

Deoarece SOAP dispune de multe implementări SOAP cantinatea de date care poate fi trimisă este limitată.

CAPITOLUL 4

MODELARE SOA – REALIZAREA UNEI APLICAȚII DE TIP CALCULATOR

4.1 Generalități

Arhitecturile orientate spre servicii reprezintă următorul pas în arhitecturile software. SOA este o arhitectură în care funcțiile sunt definite ca servicii independete, cu interfete bine definite. Respectând principiile SOA, câteva standard au fost create și sunt folosite în aceste moment. Cele mai cunoscute sunt însă serviciile web.

Principalele direcții de cercetare în domeniul serviciilor web semantice curpind OWL-S, WSMO sau SESA (Semantically Enabled Service-oriented Architectures)

Figura nr. 4.1 – Arhitectura orientată spre servicii

OWL-S

OWL-S (Ontology Web Language for Services) este un limbaj formal pentru a descrie proprietăți și funcții ale serviciilor. OWL-S extinde OWL pentru a suporta descoperirea serviciilor în funcție de proprietăți, compunere și invocare automată, monitorizarea execuției. OWL-S nu înlocuiește standardele curente pentru servicii web, ci încearcă să adauge capacități semantice. Principalele noțiuni care stau la bază sunt:

Service Profile – caracterizarea unui serviciu web, prin intermediul proprietăților. Este folosit pentru a popula regiștrii de servicii (un serviciu poate avea mai multe profile), descoperire și selecție. Profilul poate conține proprietăți funcționale precum intput, output, pre-condiții, rezultate și proprietăți nefuncționale (proveniență, timp de răspuns, securitate, arie geografică). Service Profile nu impune o reprezentare a serviciului. Folosind subclase OWL a unei clase oferite – ServiceProfile – se pot crea clase specializate de reprezentare a serviciului ce pot fi folosite ca ServiceProfile

Service Model (Process Model) – realizează o descriere interpretabilă a comportamentului serviciului împreună cu un protocol de interacțiune, specificând mesajele abstracte, tipul informațiilor ontologice transmise. Este folosit pentru invocare, compunere, monitorizare. Orice proces are input, output, precondiții și efecte. Procesele pot fi atomice, compuse sau simple.

Un proces reprezintă o transformare dintr-o stare ințială într-o mulțime de posibile stări finale. Starea inițială este definită de un input și precondiții, iar mulțimea stărilor rezultat sunt descrise de o condiție(indică când un rezultat e generat), un output și efecte ale execuției procesului. Un exemplu de proces atomic ce descrie mecanismul de autenficare:

<process:AtomicProcess rdf:ID=”LogIn”>

<process:hasInput rdf:resource=”#AcctName”/>

<process:hasInput rdf:resource=”#Password”/>

<process:hasOutput rdf:resource=”#Ack”/>

<process:hasPrecondition isMember(AccName)/>

<process:hasResult>

<process:Result>

<process:inCondition>

<expr:SWRL-Condition>correctLoginInfo(AccName,Password)</expr:SWRL-Condition>

</process:inCondition>

<process:withOutput rdf:resource=“#Ack“>

</process:withOutput>

<process:hasEffect>

<expr:SWRL-Condition>loggedIn(AccName,Password)</expr:SWRL-Condition>

</process:hasEffect>

</process:Result>

</process:hasResult>

</process:AtomicProcess>

Pe lângă aceste limbaje, WSML oferă o mapare către XML, RDF și OWL, oferind posibilitatea schimbului de ontologii WSMO pe web.

Figura nr. 4.2 – Exemplu de colaborare între servicii web

XML (eXtensible Markup Language) este tot o formă mai simplă de SGML, dar înlătură rigiditatea predecesorului său HTML prin faptul că permite definirea liberă, la alegere, a elementelor de marcare (etichete), conform cu specificul documentului (în acest sens poate fi numit un limbaj cu caracter semantic), și poate reprezenta structura proprie, internă a unui document. XML este adoptat ca standard deschis, de facto, în 1998 de către W3C și devine apoi extrem de răspândit (6). XML este independent de platformă, procesoarele lui sunt ușor de implementat, și este metoda principală de reprezentare a documentelor pentru transmiterea prin Internet. Documentele prezentate în XML pot fi citite atât de om cât și de mașină.

4.2 Realizarea aplicației calculator

Pentru realizarea aplicației calculator am utilizat softul de programare Visual Studio Beta 11. Multe elemente noi din Visual Studio 11 sunt legate de interfață și de modul în care platforma e folosită zilnic – în primul rând există un modul mai bun de indexare ce face mai ușoară regăsirea anumitor informații despre proiecte.

Am utilizat aplicația windows forms și am inceput configurarea ferestrei calculatorului:

<?xml version="1.0" encoding="utf-8" ?>

</startup>

</configuration>

Avem nevoie de 2 ferestre tip text pentru inserarea numerelelor cu care vrem să calculăm; acestea se realizează cu funcția text box din tab-ul common controls.

Figura nr. 4.3 Configurarea ferestrei calculatorului

Public Class Form1

Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click

End Sub

End Class

Pentru operații vom aplica patru butoane, care vor fi acționate printr-un simplu click cu mouse-ul.

Figura nr. 4.4 – Adăugarea celor patru butoane pentru operații de adunare, scădere, înmulțire și împărțire

Pentru afișarea rezultatelor vom aplica două etichete, după cum urmează:

Figura nr. 4.5 – Adăugarea celor două etichete

Pentru a afișa funcțiile butoanelor nu trebuie să le redenumim, ci în aplicație, acestea trebuie să afiseze textul operației pe care o vor efectua. Astfel, în dreapta ferestrei avem câmpul proprietăți în care putem modifica textul butoanelor.

Figura nr. 4.6

Figura nr. 4.6 – Afișarea semnelor pentru operații

În căsuțele de text, vom scrie “0”, iar textul va fi centrat ca în figura de mai jos.

Figura nr. 4.7

Eticheta nr. 2 va afisa rezultatul operației pe care o vom solicita. Pentru aceasta i-am aplicat funcția butonului 1, adica adunarea, astfel:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Label2.Text = Val(TextBox1.Text) + Val(TextBox2.Text)

End Sub

Private Sub Label2_Click(sender As Object, e As EventArgs) Handles Label2.Click

End Sub

End Class

La fel se face și pentru celelalte butoane, dar cu înlocuirea semnelor.

Public Class Form1

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Label2.Text = Val(TextBox1.Text) + Val(TextBox2.Text)

End Sub

Private Sub Label2_Click(sender As Object, e As EventArgs) Handles Label2.Click

End Sub

Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click

Label2.Text = Val(TextBox1.Text) – Val(TextBox2.Text)

End Sub

Private Sub Button3_Click(sender As Object, e As EventArgs) Handles Button3.Click

Label2.Text = Val(TextBox1.Text) * Val(TextBox2.Text)

End Sub

Private Sub Button4_Click(sender As Object, e As EventArgs) Handles Button4.Click

Label2.Text = Val(TextBox1.Text) / Val(TextBox2.Text)

End Sub

End Class

Și după debug, se realizează aplicația tip calculator. Rezultatul este de forma:

The thread 'vshost.LoadReference' (0x14f4) has exited with code 0 (0x0).

'WindowsApplication1.vshost.exe' (Managed (v4.0.30319)): Loaded 'D:\Users\Andreea\Documents\Visual Studio 11\Projects\WindowsApplication1\WindowsApplication1\bin\Debug\WindowsApplication1.exe', Symbols loaded.

'WindowsApplication1.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Runtime.Remoting\v4.0_4.0.0.0__b77a5c561934e089\System.Runtime.Remoting.dll'

The thread '<No Name>' (0xc20) has exited with code 0 (0x0).

The thread 'vshost.RunParkingWindow' (0x1044) has exited with code 0 (0x0).

The thread '<No Name>' (0x10e8) has exited with code 0 (0x0).

The program '[5928] WindowsApplication1.vshost.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).

Figura nr. 4.8

Din tabul Appearance se pot face modificări cu privire la aspectul calculatorului.

Figura nr. 4.9

Figura nr. 4.10

Anexa nr. 1

Codul sursa al calculatorului

<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _

Partial Class Form1

Inherits System.Windows.Forms.Form

'Form overrides dispose to clean up the component list.

<System.Diagnostics.DebuggerNonUserCode()> _

Protected Overrides Sub Dispose(ByVal disposing As Boolean)

Try

If disposing AndAlso components IsNot Nothing Then

components.Dispose()

End If

Finally

MyBase.Dispose(disposing)

End Try

End Sub

'Required by the Windows Form Designer

Private components As System.ComponentModel.IContainer

'NOTE: The following procedure is required by the Windows Form Designer

'It can be modified using the Windows Form Designer.

'Do not modify it using the code editor.

<System.Diagnostics.DebuggerStepThrough()> _

Private Sub InitializeComponent()

Me.TextBox1 = New System.Windows.Forms.TextBox()

Me.TextBox2 = New System.Windows.Forms.TextBox()

Me.Button1 = New System.Windows.Forms.Button()

Me.Button2 = New System.Windows.Forms.Button()

Me.Button3 = New System.Windows.Forms.Button()

Me.Button4 = New System.Windows.Forms.Button()

Me.Label1 = New System.Windows.Forms.Label()

Me.Label2 = New System.Windows.Forms.Label()

Me.SuspendLayout()

'

'TextBox1

'

Me.TextBox1.Font = New System.Drawing.Font("Microsoft Sans Serif", 14.25!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.TextBox1.Location = New System.Drawing.Point(319, 28)

Me.TextBox1.Name = "TextBox1"

Me.TextBox1.Size = New System.Drawing.Size(232, 29)

Me.TextBox1.TabIndex = 0

Me.TextBox1.Text = "0"

Me.TextBox1.TextAlign = System.Windows.Forms.HorizontalAlignment.Center

'

'TextBox2

'

Me.TextBox2.Font = New System.Drawing.Font("Microsoft Sans Serif", 15.75!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.TextBox2.Location = New System.Drawing.Point(319, 69)

Me.TextBox2.Name = "TextBox2"

Me.TextBox2.Size = New System.Drawing.Size(232, 31)

Me.TextBox2.TabIndex = 1

Me.TextBox2.Text = "0"

Me.TextBox2.TextAlign = System.Windows.Forms.HorizontalAlignment.Center

'

'Button1

'

Me.Button1.Font = New System.Drawing.Font("Microsoft Sans Serif", 15.75!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.Button1.Location = New System.Drawing.Point(293, 136)

Me.Button1.Name = "Button1"

Me.Button1.Size = New System.Drawing.Size(60, 28)

Me.Button1.TabIndex = 2

Me.Button1.Text = "+"

Me.Button1.UseVisualStyleBackColor = True

'

'Button2

'

Me.Button2.Font = New System.Drawing.Font("Microsoft Sans Serif", 14.25!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.Button2.Location = New System.Drawing.Point(368, 136)

Me.Button2.Name = "Button2"

Me.Button2.Size = New System.Drawing.Size(60, 28)

Me.Button2.TabIndex = 3

Me.Button2.Text = "-"

Me.Button2.UseVisualStyleBackColor = True

'

'Button3

'

Me.Button3.Font = New System.Drawing.Font("Microsoft Sans Serif", 14.25!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.Button3.Location = New System.Drawing.Point(444, 136)

Me.Button3.Name = "Button3"

Me.Button3.Size = New System.Drawing.Size(60, 28)

Me.Button3.TabIndex = 4

Me.Button3.Text = "x"

Me.Button3.UseVisualStyleBackColor = True

'

'Button4

'

Me.Button4.Font = New System.Drawing.Font("Microsoft Sans Serif", 14.25!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.Button4.Location = New System.Drawing.Point(522, 136)

Me.Button4.Name = "Button4"

Me.Button4.Size = New System.Drawing.Size(60, 28)

Me.Button4.TabIndex = 5

Me.Button4.Text = "/"

Me.Button4.UseVisualStyleBackColor = True

'

'Label1

'

Me.Label1.AutoSize = True

Me.Label1.Font = New System.Drawing.Font("Microsoft Sans Serif", 15.75!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.Label1.Location = New System.Drawing.Point(292, 211)

Me.Label1.Name = "Label1"

Me.Label1.Size = New System.Drawing.Size(115, 25)

Me.Label1.TabIndex = 6

Me.Label1.Text = "Raspuns ="

'

'Label2

'

Me.Label2.AutoSize = True

Me.Label2.Font = New System.Drawing.Font("Microsoft Sans Serif", 15.75!, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Me.Label2.Location = New System.Drawing.Point(441, 211)

Me.Label2.Name = "Label2"

Me.Label2.Size = New System.Drawing.Size(24, 25)

Me.Label2.TabIndex = 7

Me.Label2.Text = "0"

'

'Form1

'

Me.AutoScaleDimensions = New System.Drawing.SizeF(6.0!, 13.0!)

Me.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font

Me.BackColor = System.Drawing.Color.FromArgb(CType(CType(192, Byte), Integer), CType(CType(192, Byte), Integer), CType(CType(255, Byte), Integer))

Me.BackgroundImageLayout = System.Windows.Forms.ImageLayout.Stretch

Me.ClientSize = New System.Drawing.Size(846, 405)

Me.Controls.Add(Me.Label2)

Me.Controls.Add(Me.Label1)

Me.Controls.Add(Me.Button4)

Me.Controls.Add(Me.Button3)

Me.Controls.Add(Me.Button2)

Me.Controls.Add(Me.Button1)

Me.Controls.Add(Me.TextBox2)

Me.Controls.Add(Me.TextBox1)

Me.Cursor = System.Windows.Forms.Cursors.Hand

Me.ForeColor = System.Drawing.SystemColors.HotTrack

Me.Name = "Form1"

Me.Text = "Form1"

Me.ResumeLayout(False)

Me.PerformLayout()

End Sub

Friend WithEvents TextBox1 As System.Windows.Forms.TextBox

Friend WithEvents TextBox2 As System.Windows.Forms.TextBox

Friend WithEvents Button1 As System.Windows.Forms.Button

Friend WithEvents Button2 As System.Windows.Forms.Button

Friend WithEvents Button3 As System.Windows.Forms.Button

Friend WithEvents Button4 As System.Windows.Forms.Button

Friend WithEvents Label1 As System.Windows.Forms.Label

Friend WithEvents Label2 As System.Windows.Forms.Label

End Class

Anexa 2

Fisier RESX

<?xml version="1.0" encoding="utf-8"?>

<root>

<!–

Microsoft ResX Schema

Version 2.0

The primary goals of this format is to allow a simple XML format

that is mostly human readable. The generation and parsing of the

various data types are done through the TypeConverter classes

associated with the data types.

Example:

… ado.net/XML headers & schema …

<resheader name="resmimetype">text/microsoft-resx</resheader>

<resheader name="reader">System.Resources.ResXResourceReader, System.Windows.Forms, …</resheader>

<resheader name="writer">System.Resources.ResXResourceWriter, System.Windows.Forms, …</resheader>

<data name="Name1"><value>this is my long string</value><comment>this is a comment</comment></data>

<value>[base64 mime encoded serialized .NET Framework object]</value>

</data>

<value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>

<comment>This is a comment</comment>

</data>

There are any number of "resheader" rows that contain simple

name/value pairs.

Each data row contains a name, and value. The row also contains a

type or mimetype. Type corresponds to a .NET class that support

text/value conversion through the TypeConverter architecture.

Classes that don't support this are serialized and stored with the

mimetype set.

The mimetype is used for serialized objects, and tells the

ResXResourceReader how to depersist the object. This is currently not

extensible. For a given mimetype the value must be set accordingly:

Note – application/x-microsoft.net.object.binary.base64 is the format

that the ResXResourceWriter will generate, however the reader can

read any of the formats listed below.

mimetype: application/x-microsoft.net.object.binary.base64

value : The object must be serialized with

: System.Runtime.Serialization.Formatters.Binary.BinaryFormatter

: and then encoded with base64 encoding.

mimetype: application/x-microsoft.net.object.soap.base64

value : The object must be serialized with

: System.Runtime.Serialization.Formatters.Soap.SoapFormatter

: and then encoded with base64 encoding.

mimetype: application/x-microsoft.net.object.bytearray.base64

value : The object must be serialized into a byte array

: using a System.ComponentModel.TypeConverter

: and then encoded with base64 encoding.

–>

<xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">

<xsd:import namespace="http://www.w3.org/XML/1998/namespace" />

<xsd:element name="root" msdata:IsDataSet="true">

<xsd:complexType>

<xsd:choice maxOccurs="unbounded">

<xsd:element name="metadata">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="value" type="xsd:string" minOccurs="0" />

</xsd:sequence>

<xsd:attribute name="name" use="required" type="xsd:string" />

<xsd:attribute name="type" type="xsd:string" />

<xsd:attribute name="mimetype" type="xsd:string" />

<xsd:attribute ref="xml:space" />

</xsd:complexType>

</xsd:element>

<xsd:element name="assembly">

<xsd:complexType>

<xsd:attribute name="alias" type="xsd:string" />

<xsd:attribute name="name" type="xsd:string" />

</xsd:complexType>

</xsd:element>

<xsd:element name="data">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />

<xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />

</xsd:sequence>

<xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />

<xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />

<xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />

<xsd:attribute ref="xml:space" />

</xsd:complexType>

</xsd:element>

<xsd:element name="resheader">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />

</xsd:sequence>

<xsd:attribute name="name" type="xsd:string" use="required" />

</xsd:complexType>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:schema>

<value>text/microsoft-resx</value>

</resheader>

</resheader>

<value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>

</resheader>

<value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>

</resheader>

</root>

BIBLIOGRAFIE

1. Teodora Vătuiu, Petre Ciungu, Serviciile WEB – Noi oportunități pentru e-lerning în învățământul preuniversitar, Conferința Națională de Învățământ Virtual, ediția a IV-a, 2006

2. Aplicații pentru structuri GRID, curs online

3. Reș Moreno-Doru, Contribuții la conceperea, proiectarea și implementarea unui sistem informatic integrat de tip ERP, în cadrul unei firme din domeniul industrial, Universitatea “Babeș-Bolyai” Cluj-Napoca, Facultatea de Științe Economice și Gestiunea Afacerilor, 2010

4. http://en.wikipedia.org/wiki/Service-oriented_architecture

5. http://www-01.ibm.com/software/ro/solutions/soa/

6.http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html

7. http://www.enterprise-concept.com/ro/consultanta/abordari-de-consultanta/soa

8. http://en.wikipedia.org/wiki/SOAP

9. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

10. http://webdesign.about.com/od/soap/a/what-is-xml-soap.htm

11. http://www.perfectxml.com/SOAPTutorial.asp

12. http://ro.wikipedia.org/wiki/Cod_sursă

13. Faulkner Information Services, Simple Object Access Protocol (SOAP) for Web Applications, 2001

14. http://searchsoa.techtarget.com/definition/SOAP

15. Robert Daigneau, Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services, Westford, Massachusetts, ISBN-13: 978-0321544209, 2011

16. http://ro.wikipedia.org/wiki/Criptografie

17. http://ro.wikipedia.org/wiki/Funcție_hash

=== proiect ===