Exemplu de Arhitectura SOA cu explicatii

APROZAR.RO

07

APROZAR.RO –

Arhitectura SOA Posibila arhitectura orientata

pe servicii a unui aprozar online

Sbirlea Dragos Dumitru

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.


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.


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


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 use-

case – usurinta de integrare, posibiliatea de cunoastere exact care e bottleneckul sistemului din

timp.

4. Analiza


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


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.


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


8. Alte articole de pe net

Exemplu de Arhitectura SOA cu explicatii

Documents

Transcript of Exemplu de Arhitectura SOA cu explicatii