Exemplu De Arhitectura Soa Cu Explicatii

APROZAR.RO

APROZAR.RO – Arhitectura SOA Posibila arhitectura orientata pe servicii a unui aprozar online Sbirlea Dragos Dumitru

07

2

APROZAR.RO – Arhitectura SOA

1. Privire de ansamblu asupra arhitecturii propuse Deoarece cred in proverbul “O imagine face mai mult decat 1000 de cuvinte” am creat urmatoarea diagrama cu structura de baza a arhitecturii aplicatiei aprozar.ro. Fiecare componenta va fi descrisa in sectiunea urmatoare dar cred ca diagrama va ajuta la intelegerea legaturilor dintre compoenente si a workflowul de baza intre ele.

3

APROZAR.RO – Arhitectura SOA

2. Componentele principale ale arhitecturii Portal – Situl web pe care va intra utilizatorul pentru a isi face comanda. FOloseste majoritatea serviciilor oferite (pentru afisare preturi – partea de orders and sales, petnru afisare stocuri partea de Warehouse, customer care pentru reclamatii si loguri ale tranzactiilor, etc) Firewall – firewall care protejeaza reteaua interna a companiei de acces neautorizat. Ce e in dreapta lui reprezinta ceea ce se afla in interiorul LAN-ului companiei si in stanga ceea ce e conectat la itnernet si are importanta pentru noi. Se permit doar conexiuni la web serverul portal si conexiunea din afara de al serviciul de credit checking deoarece acesta nu este local, ci e accesat prin internet (in general, costa mult prea mult un astfel de serviciu de construit de la 0 si se prefer inchiriearea unui serviciu extern de acest gen.) Identity Mangement - componenta care asigura autentificarea si autorizarea utilizatorilor. Acestea nu trebuie lasate pe seama fiecarui web service, se face centralizat; reprezinta un wrapper peste baza de date de utilizatori. Ofera aceste servicii (autorizare si autentificare ) nu doar pentru clienti, ci si pentru administratorii /operatorii ai aprozar.ro . Management application – aplicatie care permite operatii care nu sunt disponibile clientilor: improspatarea stocului, vederea logurilor, analiza situatiei sistemului pe baza SLA. Aceasta aplicatei nu este acesibila din exteriorul retelei locale aprozarului, pentru securitate si are acces la ea numai personal autorizat strict. Am gandit aplicatia sa lucreze doar cu carti de credit (nu comenzi telefonice, plata la livrare, etc) Daca exista interes se poate adauga si posibilitatea de efectuare comenzi telefonica prin o aplicatie locala (nu accesibila din internet ) la care sa lucreze operatorii telefonici, usor, ca modul a aplicaitei de management sau stand – alone. Se vor folosi toate serviciile déjà existente si se vor vedea cu adevarat avantajele arhitecturii SOA. WebServices: serviciile web locale au fsot desenate cu gri; mai exista un serviciu web utilizat prin internet – cel care permite lucrul cu cartiel de credit. Webserviceurile gandite de mine sunt: Dispatch – se ocupa cu trimiterea propriu-zisa a comenzilor, va fi procesul care interactioneaza cu oamenii de la livrare – se ia outputul acestui serviciu si se livreaza produsele la adresa respective. Necesita deci interventia oamenilor ( “delivery boys” ) Sales Orders – serviciu web realizeaza mangementul si procesarea comenzilor primite (impartirea de produse, indeplinirea cerintelor ca si pachet complet – daca nu gasesc varza nu ii compare nici ceapa si ii offer posibilitatea sa aleaga altceva sau nimic in locul ei), pentru a avea sens rezultatele se bazeaza pe stocul raportat de warehouse management. Preturile pot fi tinute aici intr-o baza de date separata; alta variant ar fi sa fie tinute la warehouse management webservice, dar am optat pentru a le pastra aici deoarece e mai usor sa se implementeze discounturi epntru anumite produse in acest fel.

4

APROZAR.RO – Arhitectura SOA

Warehouse management – webservice care acopera(wrapper peste) baza de date a depozitului de alimente (tine inventarul). Daca exista depozite multiple se va preciza depozitul cel mai apropiat copespunzator cererii unui client(facuta din Portal). In plus, acest serviciu e folosit in Management Application pentru identificarea produselor din care stocul s-a micsorat prea mult si pentru eliminarea din stoc a produselor prea vechi (perisabilitatea este o caracteristica importanta in businessul aprozarelor si daca se poate asigura prin tehnologie prospetimea produselor se castiga un avantaj fata de competitor.) Aceste din urma utilizari necesita deci interventia operatorilor umani. Accounting – webservice ce ofera functiile de contabilitate necesare pentru buna functionare (si legalitate!) a firmei. Credit Checking – serviciu externalizat care ofera validarea cartilor de credit si ( eventual, depinde de serviciile contractate ) efectuarea tranzactiilor propriu-zise. SLA Monitoring + SOA Superviser (le-am grupat impreuna, mi s-a parut mai simplu asa deoarece aplicatia noastra nu are un grad de complexitate atat de ridicat cat sa necesite o componenta SLA separata)–reprezinta componenta care verifica respectarea contractului ( SLA=service level agreement ) fiecarei component a sistemului si in special a celui extern de carti de credit – pentru ca e critic si s-a paltit pt acest serviciu. Se foloseste si pentru monitorizarea timpului de raspuns, activarea load balancing, avertizari, monitorizari generale, analize de stabilitate si performanta (identificare bottlenecks) etc. Customer Care – serviciu web wrapper peste baza de date a statisticilor utilizator, folosita pentru loguri, dar si pentru avertizari se vor folosi si pentru rezolvarea eventualelor plangeri la serviciul clienti. SOA Bus - este componenta middleware care contine toate acele component middleware despre care nu am precizat nimica: delivrare, rutare emsaje, eventual adaptare de la un tip de mesaj la altul, etc. E conectat ca in desen al webserviceuri pe de o parte si aplicatii pe de alta. Business Workflow – componenta care se ocupa de workflow-ul aplicatiei a fost integrate in cele doua aplicatii care apar aici: Management Application si Portal.

3. Functionare Use case simplu pentru Web Site (Portal) , urmarind workflowul din spate: Utilizatorul intra pe site (Portal). Face log-in folosind user si parola (sunt verificate folosind Identity Mangement). Face o comanda si o trimite spre procesare. Portalul cauta un service de procesare a comenzilor si il gaseste cu ajutorul Service Broker care consulta SOA Registry si gaseste Sales Orders. Pentru verificarea de stoc se cauta din nou folosind service broker serviciu de warehouse management si se gaseste. Acesta returneaza datele conform carora se exista in stoc fiecare produs. Order processing trimite cerere de facturare la serviciul de Accounting si acesta verifica datele creditcardului clientului folosind serviciul credit card checking (toate serviciile se gasesc folosind service broker) . Accounting face plata si se face cerere de Livrare la serviciul Dispatch. Tranzactia se logheaza in

5

APROZAR.RO – Arhitectura SOA

baza de date Customer Care. Outputul de la serviciul Dispatch permite operatorilor umani sa ia produsele si sa le trimita cumparatorului. Use caseuri pentru Management Application: 1. Administratorul/operatorul se logheaza in aplicatia de management. Verifica daca au aparut alerte legate de performanta sistemului (sau e anuntat automat ☺ ). Face improspatari de stoc folosind Warehouse Management Service. 2. Un client are o reclamatie de facut. Administratorul se locheaza in plicatia de management. Verifica in baza de date a serviciului Customer Care care situatia si analizand logurile verifica unde a aparut problema. 3. Administratorul e trezit la ora 3 noaptea de alarma de la Aplicatia de Maangement care e instintata de serviciul de monitorizare de indisponibilitatea serviciului de credit card checking. Suna la furniroul acestui serviciu si afla ca au o problema cu alimentarea cu current. Situl in mod automat nu va permite comenzi in aceasta perioada deoarece Service Broker nu va gasi serviciul coresponzator in lista de servicii. 4. Administratorul face log in in aplicatia de management si descopera ca la ora ora 2 noaptea unul din serverele de baza de date a cedat si a fsot automat inlocuit de un altul, deoarece SLA Monitoring a descoperit functionarea necoresponzoare. 5. Datorita unei pene de current s-a inchis tot sistemul. La revenire totul decurge normal , pe masura ce fiecare masina revine la viata – Brokerul le gaseste si sistemuld evine utilizabil imediat ce toate masinile sunt pornite . Se pied comenzile in curs de procesare, dar acestea sunt retinute de Order Processing, impreuna cu stadiul lor de procesare si se pot trata manual, anuntand clientii. 6. Cadere hardware la una din bazele de date. Se foloseste backupul zilnic pentru a readuce baza de date corupta la stare de functionare. Comenzile pierdute sunt de negasit. De accea se foloseste de obicei o schema cu redundant la ssitemele care lucreaza cu informatii importante. In functie de fondurile clientului se poate folosi si aici, daca se suporta hardul additional. 7. Administratorul , uitandu-se in graficile utilizarii oferite de serviciul de SOA Monitoring, observa ca serviciul de credit card checking reprezinta un bottle neck pentru intergul system, motiv pentru care se decide utilizarea unui al doilea furnizor de asemenea servicii. Desi acesta are o alta interfata de lucru, se contruieste un adaptor destul de rapid (difera daor formatul mesajelor trimise si primite) si astfel se integreaza intre servicile existente. Avantajul SOA in acest usecase – usurinta de integrare, posibiliatea de cunoastere exact care e bottleneckul sistemului din timp.

4. Analiza

6

APROZAR.RO – Arhitectura SOA

Testing and reliability Avantajele unei arhitecturi SOA se vad pe partea de reliability destul de repede. Inca din faza de testare black box a componentelor. Cum marea majoritate a lor sunt de fapt web serviceuri si au o interfata clara, standardizata si usor de folosit (si deci de testat) testarea merge mult mai repde; in plus, existand o singura interfata se testeaza o data si se foloseste de mai multe ori (regression testing nu mai e asa dificil ). Decuplarea caracteristica webserviceurilor asigura inca un plus la testare. Stress testingul , concretizat prin rezultate oferite de omponenta de monitorizare va putea oferi inca de la inceput date despre ce componeta va reprezenta bottleneck al sistemului. Aceste rezultate vor putea fi folosite pentru optimizari in cursul dezvolatii si in load – balancing si server farms dupa primul release.

System Recovery Ca orice magazin online, avnad in vedere ca se efectueaza tranzactii monetare informatiile sunt vitale. De aceea recoveryul dupa o problema trebuei sa fie posibil si mai ales simplu si sigur. De aceea am gandit sistemul de Monitoring cu o componenta care se va ocupa de salvarea starii tuturor bazeleor de date. In plus, este nevoie de o baza de date (sau mai bine zis o tabela speciala) in care sa se retina tranzactiile inc urs, pentru ca la o eventual cadere aceste informatii sa nu se piarda – ele nu pot fi retinute doar in memorie. Ce problema intrevad in acest system de backup este sincronizarea backupurilor. Adica trebuie luate datele de la toate sursele (aplicatii+webservice) in mod sincron; nu se paote lua o baza de date de la un webservice acum, si de la altul epste cinci minute, deoarece nefiind sincronizate ele nu vor putea fi folosite la un eventual recovery. Solutia propusa de mine implica o “pauza” in functionarea sistemului , timp in care sa nuse mai accepte cereri noi sis a se paota opri toate workfowurile din system pentru un backup sincronizat. Avand in vedere domeniul de activitate al magazinului nu cred ca ar fi vreo problema ca acest lucru sa se intampla undeva noapte tarziu cand probabil nu face nimeni comenzi la aprozar☺.

Performanta, Load balancing si Scalability Inerent, aplicatiile SOA sunt din punctul de vedere al performantei putin mai slabe decat aplicatiile stand alone (“silo applications”) datorita faptului ca se trimit intre entitati mesaje xml si nu binare ceea ce implica schimuri de date mai lungi ca marime si cu cost de procesare additional pentru parsare si creere de mesaje. De aceea performanta trebuie avuta in vedere mereu. Pentru verificarea ca sistemul suporta load-ul dorit se foloseste monitorizarea asigurata de SOA Superviser + SLA monitoring. Astfel se poate identifica usor ce parte a sistemului este bottleneck si se poate muta pe o masina separata doar acea compoennta. Propun aceasta metoda – cu toate componentele pe cat mai putine masini initial - deoarece aprozarele nu au resurse asa mari ca sa isi permita cheltuieli (mai ales initiale) prea mari si pe masura ce traficul creste, se poate foarte usor muta o componenta pe masina separate – datorita arhitecturii SOA modulare ; daca si dupa mutarea componentelor responsabile de o

7

APROZAR.RO – Arhitectura SOA

eventuala proasta performanta a sistemului se constata ca nu se imbunatateste performanta, am luat in considerare load balancing ca solutie a problemei. Prima si cea mai simpla implementare ar fi un round robin din DNSul firmei (setat astfel incat sa nu faca si clientii caching de adrese ip). Aceasta metoda nu e potrivita arhitecturii SOA deoarece pune sub semnul intrebarii (practice distruge) toata arhitectura de moniorizare a performantei fiind destul de dificil sa se analizeze correct performanta daca se implementeaza load balancing din DNS . De fapt , round-robin fiind tehnica mai mult de load distribution si nu de load balancing nu o vad decat ca o solutie eventual pe termen scurt. Practic, incarcarea nu se mai balanseaza ci se imparte echitabil dpdv al numarului de cereri- ceea ce nu echivaleaza mereu cu incarcarea practica. Software load balancing pare mai potrivit aici deoarece permite si o analiza a performantei si un timp de raspuns mic (la load balancing hardware timpul de raspuns e destul de mare – de ordinal secundelor). Se poate analiza performanta ( in general procentul de CPU utilizat si procentul de RAM utilizat ) fiecarei componete si asigna o noua cerere unei masini care e mai libera. Am propus aici o solutie de load balancing de CPU load mai mult decat de network load balancing (NLD), deoarece datele vor trece in majoritate prin reteaua locala a firmei, unde latimea de banda nu e o problema. Arhitectura orientata pe servicii web permite load balancing separat pe: -

serverul web portal

-

fiecare baza de date (transformat in server farm )

-

fiecare web service

Pentru scalabilitate va ajuta mult sistemul de monitorizare a performantei pentru a stii din timp cand va fi nevoie de investii noi in hardware.

Securitate Avand in vedere specificul de magazine al sistemului securitatea trebuie sa fie pe primul loc. In primul rand, toate serviciile web nu sunt acesibike din exteriorul retelei locale, singurul accesibil din exterior este serverul web (Portalul). In desen nu am desenat si un al doilea firewall in spatele lui – aceasta fiind arhitectura standard de securitate (ca un “senvis” ). Pentru managementul utilizatorilor exista o compoenenta specializata, care se coupa cu verificarea credentialelor utilizatorilor si trmiterea tokenilor de securitate catre service broker care le va forwarda catre fiecare serviciu. Aceasta compoennta se ca ocupa de autentificarea si autorizarea utilizatorilor. Vor exista doua tipuri de contuir – de utilizator si de administrator. Daca se implementeaza si partea de comenzi telefonice va oferi si rolul de operator.

8

APROZAR.RO – Arhitectura SOA

Un risc de securitate identificat este folosirea serviciului extern de validare a cartilor de credit / efectare tranzactii. De aceea se va lucra doar cu acei furnizori de servicii ce asigura o buna securizare a informatiilor vehiculate prin internet.

Dezvoltari ulterioare La partea de dezvoltari ulterioare isi arata beneficiile arhitectura SOA. Se pot adauga oricate alte noi facilitati pentru clienti/administratori. Atata vreme cat aceste noi facilitati se bazeaza pe serviciile deja construite, reutilizarea codului va fi maxima, cat si timpul de dezvoltare si testare. Ca dezolvatari ulterioare propun ca Managmeent aplication sa fie dezoltat intr-un sistem client-server care sa permita procesarea de comenzi telefonice de catre niste operatori.

5. Cateva precizari generale Am pus accentual nu pe descrierea in detaliu a fiecarui web service posibil de implementat ; intr-adevar serviciile identificate de mine, la o analiza mai atenta se pot imparti in si mai multe compoenete. Nu acesta era scopul meu , nu am dorit sa fac un design detaliat al sistemului, ci mai mult sa schitez o arhitectura, evidentiind structura de SOA si locurile unde ajuta SOA sistemul sa functioneze mai bine. Am pus accentual pe asa numita “SOA Governance” deoarece este “cheia” unei arhitecturi orientate pe servicii. Fara o conducere corespunzatoare sisteul nu mai e un instrument ci doar o colectie de mini-servicii. Un alt aspect pe care il puteam imbunatati este separarea intre descrierea directiilor de business si a celor de design propriu-zis, dar cum cele doua se intretes uneori documentul rezultat prin separarea lor ar fi iesit mult prea mare si greu de inteles si mai ales de scris☺.

6. Bibliografie

1. Judith Hurwitz and co., “Service Oriented Architecture for dummies”, Wiley, 2005 2. Lenuta Alboaie, Sabin Buraga, “Servicii Web. Concepte de baza si implementari”, Polirom, 2006 3. Articolul Wikipedia despre SOA si linkurile de acolo. 4. SLA For SOA ( http://www.layer7tech.com/solutions/page.html?id=59 ) 5. SOA Governance ( http://en.wikipedia.org/wiki/SOA_Governance ) 6. SOA Security http://blogs.ittoolbox.com/eai/business/archives/soa-security-architecture-11431 7. SOA Performance (http://devcentral.f5.com/weblogs/macvittie/archive/2007/01/19/2687.aspx

9

APROZAR.RO – Arhitectura SOA

8. Alte articole de pe net