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