Platformă de e-learning și curriculă e-content pentru...

Platformă de e-learning și curriculă e-content

pentru învățământul superior tehnic

Programul Operațional Sectorial Creșterea Competitivității Economice - POS CCE

Proiect nr. 154/323 cod SMIS – 4428 cofinanțat de prin Fondul European de

Dezvoltare Regională “Investiții pentru viitorul dumneavoastră”.

Platformă de e-learning și curriculă e-content

pentru învățământul superior tehnic

� Integrarea sistemelor informatice

20. Importanța serviciilor Web

Platformă de e-learning și curriculă e-content pentru

învățământul superior tehnic

Importanta SOA

� Exista o cerere uriasa pentru dezvoltarea si implementarea sistemelor de tip

SOA.

3ISI – Integrarea sistemelor informatice

SOA.

� Metodele OOAD (Object Oriented Analysis and Design) curente nu adreseaza

cele 3 elemente cheie ale unui SOA: servicii, fluxuri, componente.

� Este nevoie sa fie adresate explicit tehnicile si procesele necesare pentru a

identifica, specifica si realiza serviciile, fluxurile si structura lor.



Stil arhitectural si principii

� SOA descrie un set de sabloane pentru a crea servicii slab cuplate care,

datorita separarii interfetelor, implementarilor si protocoalelor, furnizeaza o

mare flexibilitate in receptivitatea la cerintele actuale de business functionale


mare flexibilitate in receptivitatea la cerintele actuale de business functionale

si non-functionale:

�performanta

�securitate

�scalabilitate



Serviciu web

� o resursa software cu o descriere externa

� descrierea este disponibila pentru cautarea, conectarea, invocarea de catre

un consumator de servicii


un consumator de servicii

� furnizorul de servicii realizeaza implementarea descrierii serviciului si livreaza

cerinte QoS (Quality of Service) consumatorului de servicii.

� serviciile ar trebui in mod ideal sa fie conduse de politici declarative, astfel

incat sa suporte un stil arhitectural reconfigurabil



Model conceptual al SOA




Model conceptual al SOA

� Coceptul este bazat pe un stil arhitectural care defineste un model de

interactiune intre trei parti primare:

�furnizorul de servicii: publica descrierea unui serviciu si furnizeaza implementarea

acelui serviciu


acelui serviciu

� un consumator de servicii:

•poate folosi un URI (Uniform Resource Identifier) pentru descrierea directa a

serviciului

•poate gasi descrierea serviciului intr-un registru de servicii si apoi poate sa se

conecteze si sa invoce acel serviciu

�Brokerul de servicii furnizeaza si mentine registrul de servicii (desi in ziua de azi

registrele publice nu mai sunt in voga)



Nivelurile unei SOA




Nivelurile unei SOA

� Nivelul operational

�format din aplicatiile deja existente, “mostenite”

�include aplicatii de tip CRM (Customer Relationship Management) si ERP


�include aplicatii de tip CRM (Customer Relationship Management) si ERP

(Enterprise Resource Planning), implementari ale sistemului mai vechi, orientate

obiect, aplicatii inteligente

� Nivelul componentelor intreprinderii:

�foloseste de obicei aplicatii server pentru a implementa componentele, gestiunea

volumului de munca si echilibrarea traficului



Nivelurile unei SOA

� Nivelul de servicii:

�cuprinde serviciile fondate si expuse: pot fi descoperite sau legate static si apoi

invocate

�furnizeaza un mecanism prin care se realizeaza servicii la rulare, folosind

functionalitatea data de interfata


functionalitatea data de interfata

�interfetele sunt exportate ca descrieri de servicii si expuse pentru a fi folosite; ele

pot exista izolate sau ca servicii compuse

� Nivelul de compunere a proceselor:

�compunerea serviciilor expuse la nivelul anterior

�serviciile sunt “impachetate” intr-un flux si astfel actioneaza impreuna ca o singura

aplicatie; aceste aplicatii suporta cazuri de utilizare si procese specifice



Nivelurile unei SOA

� Nivelul prezentare sau acces

� Nivelul integrare

�permite integrarea serviciilor prin introducerea unui set de capabilitati de baza:

rutare inteligenta, medierea protocoalelor si alte mecanisme de transformare, de

obicei descrise ca ESB (Enterprise Service Bus)


obicei descrise ca ESB (Enterprise Service Bus)

�Web Services Description Language (WSDL) specifica conectarea, ceea ce implica o

locatie la care serviciul este furnizat; pe de alta parte, un ESB furnizeaza un

mecanism de specificare a locatiei independenta pentru integrare

� Nivelul QOS:

�furnizeaza capabilitati necesare pentru a monitoriza, gestiona, mentine QOS:

securitate, performanta, valabilitate

�este un process de background



Procesul de modelare a arhitecturii orientate pe servicii





� Consta in trei pasi generali: identificare, specificare, realizare a serviciilor,

componentelor si fluxurilor.

� Identificarea serviciilor


� Identificarea serviciilor

�descompunerea domeniului in ariile si subsistemele sale, incluzand

descompunerea proceselor sau fluxului in subprocese si cazuri de utilizare

� Clasificarea serviciilor

�aceasta clasificare ar trebui sa fie realizata ca o ierarhie, care sa reflecte natura

compusa a serviciilor: acestea ar trebui compuse din componente mai fin granulate




� Analiza subsistemelor

�specifica interdependentele dintre subsisteme

�cazurile de utilizare sunt expuse ca servicii in interfata subsistemului

� analiza unui subsistem presupune crearea de modele ale obiectelor pentru a


� analiza unui subsistem presupune crearea de modele ale obiectelor pentru a

reprezenta designul si taskurile interne ale subsistemelor continute

� Specificare componentelor

�detaliile componentelor care implementeaza serviciile: date, reguli, servicii,

profiluri configurabile

�trimiterea de mesaje si specificatiile evenimentelor




� Alocarea serviciilor

� consta in asignarea serviciilor subsistemelor care au fost identificate.

�de obicei se face presupunerea ca subsistemele au o corespondenta 1-1 cu

componentele intreprinderii.


de obicei se face presupunerea ca subsistemele au o corespondenta 1-1 cu

componentele intreprinderii.

� Realizarea serviciilor :

�se hotaraste care subservicii vor fi folosite pentru a realiza un anumit serviciu si

care servicii vor fi construite de la baza

� include integrare, transformare folosind servicii web



Principii de design ale aplicatiilor orientate pe servicii

� Dezvoltarea aplicatiilor orientate pe servicii (Service-Oriented Development of

Applications = SODA) este o metoda sau abordare care construieste aplicatii


Applications = SODA) este o metoda sau abordare care construieste aplicatii

folosind servicii software.

� SODA este compatibila cu limbaje de programare variate, mai ales orientate

obiect.




� Crearea cu succes a aplicatiilor orientate pe servicii presupune:

�deciderea a caror functionalitati are sens sa fie expuse ca servicii

�separarea si modularizarea logicii de business pentru a facilita refolosirea si


�separarea si modularizarea logicii de business pentru a facilita refolosirea si

flexibilitatea

�folosirea de servicii slab cuplate pentru a putea fi dezvoltate rapid cand cerintele

se schimba

�proiectarea unei granularitati potrivite a serviciilor

�planificarea si implementarea tuturor pasilor SODA




Deciderea a caror functionalitate sa fie expusa ca un serviciu:

� aproape orice tip de logica de business poate fi implementata sau expusa ca

un serviciu web in SOA, de la o singura, triviala functie pana la o aplicatie


un serviciu web in SOA, de la o singura, triviala functie pana la o aplicatie

complexa

�este nevoie ca datele sa fie private?

�functionalitatea bazata pe logica de business se poate schimba frecvent?

�este nevoie ca datele sa fie partajate intre departamente sau locatii ale unei

intreprinderi sau cu parteneri externi?




Separarea si modularizarea logicii de interfata serviciului

� evitarea construirii logicii direct in implementarea serviciului

� proiectarea fiecarui serviciu pentru a expune un bloc modular de logica care

calculeaza o functie discreta


calculeaza o functie discreta

� protejeaza clientul de functionalitati schimbatoare in logica businessului si

faciliteaza implementarea rapida a regulilor schimbate in serviciu

� implementarea unui serviciu ar trebui sa contina doar apelul catre logica de

business pentru a lua datele de care are nevoie in a converti sau asambla

datele returnate intr-un format specificat, cel mai adesea bazat pe XML




Servicii slab cuplate

� probabil cel mai critic element intr-un sistem SOA

� are impact direct asupra agilitatii aplicatiei: abilitatea de a fi scalata usor,


� are impact direct asupra agilitatii aplicatiei: abilitatea de a fi scalata usor,

usurinta in schimbare, de incredere

� cuplarea stransa presupune ca daca functia A este foarte dependenta de

functia B, schimbarile asupra uneia determina schimbari si asupra celeilalte

� cuplarea slaba evita cat mai multe dependente posibile la toate nivelele

aplicatiei, permitand componentelor si serviciilor sa opereze fara sa fie nevoie

de informatii de la alte componente sau servicii




Proiectarea unei granularitati potrivite a serviciilor

� granularitate fina: presupune efectuarea unei singure, simple functii


� granularitate aspra: presupune efectuarea unei functii complete

� Regula importanta: construirea unei serii de obiecte si componente de

nivel scazut, cu granularitate fina si apoi construirea unui serviciu granulat

aspru din acestea.




� un serviciu granulat fin poate fi folosit de multe ori, dar poate cauza si un

overhead mare la rulare

� un serviciu granulat aspru care incapsuleaza un proces complet va fi cel mai


� un serviciu granulat aspru care incapsuleaza un proces complet va fi cel mai

folositor celor care planifica o aplicatie completa si va avea nevoie de o

singura accesare a bazei de date la rulare

� Serviciile care sunt prea aspru granulate pot fi limitate in refolosire. Trebuie

sa existe in mod clar un echilibru intre cele doua.

Platformă de e-learning și curriculă e-content pentru...

Documents

Transcript of Platformă de e-learning și curriculă e-content pentru...