Sunteți pe pagina 1din 33

Sisteme Informatice Integrate 1 Aspecte introductive ale integrrii sistemelor informatice Informatizarea, dezvoltarea economic global, specifice secolului

al XX-lea au declanat tendina de organizare a sistemelor informaionale n modele din ce n ce mai complexe. Principiul integrrii deriv din principiul ordinii i organizrii. Prin integrare crete complexitatea, dar i calitatea, pentru c reuniunea sistemelor presupune adugarea de componente evolutive i emergente. Dac organizarea duce la integrare i integrarea duce la complexitate, aceasta din urm determin la rndul ei diversificarea. Din punct de vedere al diversitii, integrarea este efectul evoluiei ciclice i progresive a unui mix de tehnologii i este sprijinit de performanele i de expertiza profesionitilor. La nceput, conotaiile procesului de integrare au fost n principal tehnice i s-a acordat puin importan aspectelor calitative. Noiunea de sistem integrat presupunea aspecte hardware i probleme de interconectare a componentelor calculatoarelor: o suit de echipamente i programe care lucreaz mpreun.n prezent procesul de integrare s-a extins i vizeaz programe, date i comunicaii.[1] Sistemele integrate se refer la sisteme complete, cu procese de afaceri, practici manageriale, interaciuni organizaionale, transformri structurale i managementul cunotinelor. O soluie la problema integrrii o constituie Enterprise Application Integration(EAI) Integrarea aplicaiilor este o abordare strategic de a lega mai multe sisteme informatice, la nivel de informaii i servicii, astfel nct sistemele sunt capabile s fac interschimb de informaie i s asigure o funcionare a proceselor n timp real. Informaia rezultat i fluxul de procese ntre sistemele interne i cele externe ofer unei companii un avantaj strategic clar: capacitatea de a face afaceri n timp real, ntr-o atmosfer condus de evenimente, i cu o laten redus. Integrarea aplicaiilor poate lua mai multe forme, incluznd integrarea intern a aplicaiilor: Integrarea aplicaiilor la nivel de companie sau integrarea extern a aplicaiilor: Integrarea aplicaiilor Business-to-Business. Cele dou tipuri de integrri au multe elemente comune. De exemplu, ntotdeauna vor exista: o transformare de tehnologie care va face diferena ntre semantica aplicaiilor, tehnologia de ruter care prin care se va asigura c informaia ajunge la destinaia corect i reguli de procesare pentru a defini comportamentul de integrare. Un trend clar n evoluia integrrii aplicaiilor este trecerea de la integrarea bazat pe informaie la integrarea bazat pe servicii. Integrarea bazat pe informaii ofer un mecanism ieftin de a integra aplicaii deoarece, n cele mai multe cazuri, nu este nevoie ca aplicaia s fie modificat. Cu toate c, acest tip de integrare ofer o soluie funcional pentru multe domenii ale problematicii de integrare a aplicaiilor, integrarea bazat pe servicii ofer mai mult valoare pe termen lung. Integrarea aplicaiilor este o combinaie a mai multor problematici. Fiecare organizaie are setul su propriu de subiecte de integrare care trebuie adresate. Datorit acestui fapt este aproape imposibil gsirea unei soluii tehnologice unice care s poat fi aplicat universal. Ca urmare, fiecare aplicaie va avea caracteristicile proprii. Cu toate c abordrile integrrii difer de la caz la caz, este posibil crearea unor categorii care vor fi detaliate n seciunea urmtoare. Dintre caracteristicile unui sistem integrat enumerm cteva: Autonomie - majoritatea modelelor structurale i comportamentale pentru un asemenea sistem complex pot fi evidentiate doar ca urmare a operrii sistemului n mediul extern; Incertitudine - comportarea unui sistem complex este probabilistic i nu poate fi predictibil n totalitate sau cunoscut nainte de implementarea sa.Cu ct sistemul este mai complex cu att gradul de incertitudine este mai mare Variabile - un numr excesiv de mare de variabile i inter-relatii ce nu pot fi in totalitate cunoscute, ajustate i controlate

Multiple obiective - elementele constitutive ale sistemului au posibilitatea urmririi ndeplinirii unor obiective proprii, care pot fi dependente sau independente de obiectivele generale ale sistemului.Un singur obiectiv sau un set unitar de obiective este o iluzie pentru un adevrat sistem de sisteme.

Printre avantajele integrrii se pot mentiona: [2] Scalabilitatea - nlocuirea tuturor interfeelor cu una singur care asigur toate punctele de acces la sistemul informaional, administrarea lor facil i posibilitatea adugrii de alte instrumente sau aplicaii; Performana - pachetul de aplicaii ofera sigurana deplin a datelor; Usurina n desfurare - abilitatea de a schimba anumii parametri (numele sursei, numele intei) este esenial; Administrarea centralizat - interfeele sunt administrate automat de la un punct central; Precizie n procesri/zero greeli - abilitatea de a livra datele la int, imediat dup citirea sursei, este foarte important; Eterogenitatea surselor - procesul de transformare a datelor n informaii presupune posibilitatea de a combina date din surse eterogene; Securitatea - aplicaiile prevd standarde ridicate de securitate; Calitatea tehnologic a partenerilor - proiectele de anvergur oblig companiile s dezvolte relaii de afaceri numai cu parteneri care dein deja sisteme integrate; Training - desfurarea de programe de instruire pentru grupurile de utilizatori; Suport nelimitat - 24 de ore din 24, 7 zile din 7, suport telefonic i web cu acces rapid la baza de cunotine a ntreprinderii pentru rezolvarea rapid a problemelor; Grupuri de utilizatori - organizarea unei baze de utilizatori, partajarea experienelor a celor mai bune practici i popularizarea cazurilor reuite i a eecurilor; Referine - deinerea unei platforme integrate reprezint cea mai bun recomandare n lumea afacerilor electronice. 2 Tipuri de integrare Exist patru tipuri (categorii) de integrare a aplicaiilor: Integrare orientat pe informaie; Integrare orientat pe procesele de afaceri; Integrare orientat pe servicii: Integrarea orientat pe portal.

2.1. Integrarea orientat pe informaie Cei care promoveaz abordarea orientat pe informaie pentru integrarea aplicaiilor susin c integrarea trebuie s apar ntre bazele de date (sau proprietari API care produc infomaie) ceea ce nseamn c bazele de date trebuie vzute ca puncte principale de integrare.

Figura 1.1. Schimb de informaie ntre dou aplicaii Soluiile orientate pe informaii pot fi grupate n trei categorii: Replicarea datelor; Federaia datelor; Procesarea interfeei;

Replicarea datelor Replicarea datelor se refer la simpla mutare a datelor ntre dou sau mai multe baze de date. Aceste baze de date pot avea proveniene diferite (Figura 1.2) i pot avea modele diferite. Cerina fundamental pe care trebuie s o ndeplineas o baz de date pentru a putea replica date este s ofere o infrastructur pentru schimbul de date.

Figura 1.2 Replicarea unei baze de date Multe baze de date care includ soluii middleware ofer servicii pentru replicarea datelor. Replicarea serviciilor este realizat prin plasarea unui strat software ntre dou sau mai multe baze de date. Pe de o parte, datele sunt extrase dintr-o baz de date sau din mai multe baze de date i sunt apoi plasate n bazele de date int. Multe dintre aceste soluii ofer servicii de trasfomare precum i abilitatea de a modifica schema i coninutul astfel inct acestea s aib sens pentu baza de date int. Avantajele replicrii bazelor de date sunt simplitatea i costurile sczute. Replicarea este uor de implementat, iar tehnologia este ieftin. Din pcate, aceste avantaje sunt eliminate dac sunt necesare metode ataate datelor. n acest caz, trebuie luat n considerare orientarea bazat pe servicii. Federaia datelor Fedaraia datelor se refer la integrarea mai multor baze de date i modelelor asociate ntr-o singur baz de date, cu un view unificat (Figura 1.3). Practic, federaiile bazei de date reprezint bazele de date virtuale. Software-ul federaiei bazei de date plaseaz un nivel software (middleware) ntre bazele de date distribuite fizic i aplicaiile care vizualizeaz datele. Acest nivel conecteaz bazele de date folosind interfete i mapeaz bazele de date fizice ntr-o baz de date virtual care exist numai n software. Aplicaia folosete aceast baz de date virtual pentru a accesa infromaiile necesare. Federaia bazei de date gestioneaz colectarea i distribuirea datelor, pe msur ce acestea sunt necesare, ctre bazele de date fizice. Avantajul folosirii acestui software este c poate lega tipuri diferite de date ntr-un model unificat care suport schimbul de informaie.

Figura 1.3 Federaia datelor Federaia bazei de date permite accesul la orice baz de date conectat la sistem printr-o singur interfa bine defininit. Aceasta reprezint cea mai elegant soluie pentru integrarea datelor. Spre deosebire de replicare, aceast soluie nu necesit modificri ale aplicaiilor int. Totui, schimbri sunt necesare la

nivelul aplicaiei care susine software-ul bazei de date coninut n federaie. Acest fapt este datorat interfeelor diferite care sunt folosite pentru a accesa un model al bazei de date diferit (baza de date virtual). Procesarea interfeei Soluiile de procesare a interfeei folosesc interfee ale unor aplicaii bine definite pentru a se axa att pe integrarea aplicaiilor pachet ct i a aplicaiilor obinuite (Figura 1.4). Interesul curent n integrarea de tip ERP (Enterprise Resource Planning) (SAP, PeopleSoft i Oracle) a facut acest sector cel mai atractiv n ceea ce privete integrarea de aplicaii.

Figura 1.4 Procesarea interfetei Integratorii susin soluiile bazate pe procesarea interfeei prin oferirea de adaptori care s conecteze ct mai multe aplicaii obinuite sau aplicaii pachet, externaliznd informaia. Aceti adaptori se conecteaz la soluiile tehnologice care includ tehnologii middleware i screen scraper[1] ca puncte de integrare. O integrare eficient a mai multor tipuri de aplicaie definete avantajul principal al utilizrii produselor de integrare a aplicaiilor. n doar cteva zile, este posibil conectarea unei aplicaii SAP R/3 la o aplicaie Oracle, prin intermediul unei soluii de procesare a interfeei care s gestioneze diferenele de shem, coninut i sematica aplicaiei, prin interpretarea informaiei interschimbat ntre sisteme. Dezavantajul folosirii produselor de integrare bazat pe procesarea interfeei este c se acord atenie limitat logicii procesului de afaceri ct i metodelor aparinnd sursei sau sistemelor int. n aceste situaii, se recomand folosirea unei abordri orientate pe servicii. Se prognozeaz c pe viitor, tehnologia de procesare a interfeei va fi capabil s includ i metode. 2.2 Integrare orientat pe procesele de afaceri ntr-o form simpl, integrarea orientat pe procesul de afaceri produce un nivel ce conine un set de procese central-gestionate i uor definite.

Figura 1.5 Integrarea orientat pe procese de afaceri Integrarea orientat pe procesul de afaceri reprezinta mecanismul de gestiune a datelor interschimbate i apelarea proceselor ntr-un mod corect astfel nct s permit gestionarea i execuia proceselor comune care exist n i ntre aplicaii. Integrarea aplicaiilor orientate pe procesul de afaceri ofer un alt strat de procese gestionate central i uor definite care exist deasupra setului curent de procese i date coninute ntrun set de aplicaii. Scopul este de a aduce mpreun procese relevante pentru a obine valoare maxim, susinnd fluxul de informaie i controlul logic ntre aceste procese. Aceste produse vizualizeaz middleware-ul i ofer interfee vizuale uor de folosit pentru legarea acestor procese. n realitate, integrarea procesului de afaceri este un alt nivel de valoare, adugat peste soluiile de integrare a aplicaiilor, soluiile care includ integrarea serverelor, serverele de aplicaii, obiecte distribuite i alte nivele middleware. Integrarea proceselor de afaceri ofer un mecanism pentru legarea proceselor

disparate i pentru a crea soluii proces-proces care automatizea o sarcin o dat ce aceasta a fost realizat manual. Totui, dezavantajul const n faptul c se poate pierde destul de uor viziunea de ansamblu asupra sistemului. n realitate, nici un productor nu a reuit s rezolve aceaste probleme. n ultim instan, soluia va fi o combinaie cu un middleware. Exist multe diferene ntre integrarea de aplicaii tradiional i integrarea bazat pe procesul de afaceri: O singur instan a integrrii procesului de afaceri este echivalent cu mai multe instane ale integrrii aplicaiilor tradiionale; Integrarea aplicaiilor se refer la schimbul de informaii ntre dou sau mai multe sisteme far ca procesele interne s fie vizibile - Integrarea proceselor de afaceri duce la un model de proces i mut informaia ntre aplicaii conform modelului respectiv; Integrarea aplicaiilor este tipic o soluie tactic, motivat de cerinele a dou sau mai multe sisteme de a comunica - Integrarea procesului de afaceri este strategic, gestionnd regulile de afaceri pentru a determina cum ar trebui s interacioneze sistemele astfel nct s susin valoarea afacerii din fiecare sistem folosind un model de afaceri abstract. Integrarea orientat pe procese de afaceri vizualizeaz middleware-ul ca o facilitate care are capacitatea de a echilibra att orientarea pe mesaje ct i middleware-rul tranzacional ca puncte de integrare ntr-un numr neliminat de sisteme surs sau int. De fapt, cele mai multe servere de integrare i de aplicaii ncep s ofere unelte de integrare orientat pe procese de afaceri care susin tehnologia middleware. ntradevr, integrarea orientat pe procese de afaceri ofer interfee vizuale uor de folosit pentru a lega aceste procese. Integrarea orientat pe procese de afaceri este cel mai bine definit prin cteva reguli, ntr-o secven logic pentru a realiza interschimbul de informaie ntre sistemele participante, vizualizarea proceselor pe nivele de aplicaii, i crearea de procese abstracte comune att pentru sistemele interne ct i pentru cele externe. Ca urmare sunt trei servicii majore pe care le ofer acest tip de integrare: vizualizarea proceselor coninute de sistemele n cauz, abstractizarea interfeei i o msur n timp real a performanei procesului de afaceri. Cu toate c mai sunt aspecte care ar putea fi mbuntite, acest tip de integrare este considerat cel mai potrivit tip de integrare, innd cont i de faptul c trebuie perfecionat tehnologia middleware. 2.3. Integrarea orientat pe servicii Integrarea orientat pe servicii permite aplicaiilor s mpart metode comune. Acest proces se realizeaz fie prin definirea unor metode care s poat fi accesate de toate aplicaiile, i ca urmare integrate, sau prin punerea la dispoziie a unei infrastructuri pentru asemenea metode, de exemplu serviciile Web (Figura 1.6). Metodele pot fi accesate fie prin stocarea acestora pe un server central (obiecte distribuite), sau fie printr-un mecanism de servicii Web standard, cum ar fi .NET.

Figura 1.6 Integrarea orientat pe servicii ncercrile de a permite accesul la procese comune au o istorie lung, ncepnd cu arhitectura clientserver. Reutilizarea este un obiectiv valoros. Un set comun de metode ntr-o aplicaie care folosete

reutilizarea reduce redundana metodelor i a aplicaiei. Din pcate, reutilizarea total a fost realizat deocamdat doar la nivel de ntreprindere. n cele mai multe cazuri, limita reutilizrii este datorat unei lipse a unei arhitecturi a companiei i a unui control central. Utilizarea uneltelor i tehnicilor de integrare d acum posibilitatea utilizrii acelorai metode. Mai mult dect att, aceste unelte i tehnici creaz infrastructura care face acest proces s devin realitate. Dezavantajul const n costurile destul de ridicate, avnd n vedere serviciile Web, obiectele distribuite i cadrele tranzacionale. Integrarea orientat pe informaie nu necesit schimbri ale sistemelor surs sau destinaie, pe cnd integrarea orientat pe servicii necesit modificri la aproape toate aplicaiile pentru a beneficia de avantajele acestei paradigme. Cu toate c, probleme ridicate de costuri sunt importante, aplicabilitatea n mai multe domenii ofer acestui tip de integrare un avantaj. Ca urmare, folosirea integrrii orientate pe servicii se recomand a fi folosit doar acolo unde este strict necesar. Modificarea aplicaiilor este adesea o operaiune scump. Pentru a schimba logica aplicaiei, este necesar testarea, integrarea aplicaiei - un proces care cauzeaz o cretere a costurilor n spiral. Aceste costuri apar fie c se lucreaz cu o tehnologie mai veche, CORBA (Common Object Request Broker Architecture), sau cu tehnologii noi ca .NET, ultimul tip de arhitectur bazat pe servicii. nainte de a folosi acest tip de integrare, trebuie nelese foarte bine aspectele legate de oportunitile oferite de acesta i de riscurile implicate. Numai atunci, se poate face o evaluare obiectiv. Posibilitatea de a avea acces la serviciile unei aplicaii i ca urmare posibilitatea integrrii acestor aplicaii reprezint un beneficiu extraordinar. Totui, acest beneficiu este urmat de un risc real mare datorit costurilor de implementare a integrrii bazate pe servicii, deoarece aceste costuri ar putea, n anumite cazuri, s depeasc valoarea creat de integrare. 2.4. Integrarea orientat pe portal Integrarea orientat pe portal permite vizualizarea unei multitudini de sisteme att sisteme interne unor ntreprinderi, ct i sisteme externe printr-o interfat de tip utilizator simplu. Acest tip de integrare aduce un plus de beneficiu datorit evitrii problemelor de integrare, adaptrii interfeei utilizator a fiecrui sistem la o interfa utilizator comun (interfat utilizator agregat) de cele mai multe ori un browser Web (Figura 1.7). Ca rezultat, toate sistemele participante sunt integrate ntr-un browser, chiar dac aplicaiile nu sunt direct integrate n cadrul i ntre mai multe companii.

Figura 1.7 Integrarea orientat pe portal Dac alte tipuri de aplicaii de integrare sunt orientate pe schimbul de informaie n timp real, acest tip de integrare este axat pe externalizarea informaiei provenind din mai multe sisteme i companii ntr-o singur aplicaie cu o singura interfa. Totui, integrarea aplicaiilor, referindu-se la schimbul automat de informaie sau la legarea a doua sau mai multe procese fr ajutorul unui utilizator final, poate aprea la interfaa utilizator. ntradevr, majoritatea exemplelor de schimb de informaie ntr-un B2B se pliaz pe tehnica integrrii orientate pe portal, folosindu-se de transfer digital. Ca urmare, se poate concluziona c dei este diferit, aceast tehnic se potrivete pe problematica integrrii n general.

3. Tehnologia integrrii aplicaiilor Tehnologia de integrare a aplicaiilor se bazeaz pe noiunea de middleware. 3.1. Ce este un middleware? Cea mai bun definiie a unui middleware este cea care definete acest concept n baza funciilor sale. Middleware-ul este un mecanism care permite unei entiti (baz de date sau aplicaie) s comunice cu alt entitate, sau entiti. Cu alte cuvinte, middleware-ul este un tip de software care faciliteaz comunicaia ntre dou sau mai multe sisteme software. 3.2 Modele middleware Exist dou modele de middleware: unul logic i unul fizic. Modelul logic descrie cum are loc transferul de date conceptual, iar modelul fizic descrie metodele precum i tehnologia folosite pentru transferul de informaie. Configuraiile asociate modelui logic sunt: unul la unu, muli la muli, i sincron versus asincron, pe cnd modelului fizic i sunt asociate modele bazate pe mesaje. Middleware-ul unu la unu folosete un pipe simplu pentru a permite unei aplicaii s acceseze alt aplicaie. Exemplu: Fie dou aplicaii A i B. Cnd aplicaia A ncearc s comunice cu aplicaia B, nchide pipe-ul folosind o procedur de apel sau un mesaj. (Figura 1.8)

Figura 1.8 Configuraia unu la unu Aa cum sugereaz numele, middleware-ul muli la muli, leag mai multe aplicaii cu alte aplicaii. Aceast capacitate l face cel mai potrivit pentru integrarea aplicaiilor. n plus, este cel mai puternic middleware logic, deoarece ofer att flexibilitate ct i adaptabilitate problemei integrrii. Sunt mai multe exemple de middleware muli la muli: integrare la nivel de servere, middleware tranzacional (servere aplicaii i monitori TP), i chiar obiecte distribuite. Practic, orice tip de middleware care poate s lucreze cu mai multe de dou aplicaii surs i destinaie n acelai timp poate susine acest model. (Figura 1.9)

Figura 1.9 Configuraia muli la muli Avantajul modelului unu la unu este simplitatea, modelul muli la muli avnd dezavantajul complexitii. Aceast problem este atenuat de noua generaie de middleware.

Middleware-ul asincron face transferul de informaie ntre mai multe aplicaii ntr-un mod asincron ceea ce presupune c software-ul middleware se poate deconecta de la aplicaia surs sau destinaie. Aplicaiile nu sunt dependente de alte aplicaii conectate pentru procesare. Procesul care permite acest lucru are aplicaiile plasate ntr-o coad de ateptare, fiecare cu un mesaj asociat, i fiecare ruleaz independent, rspunsul de la celelalte aplicaii primindu-se mai trziu. Avantajul principal este acela c middleware-ul nu blocheaz celelalte aplicaii din procesare. Mai mult dect att, deoarece middleware-ul se decupleaz de la aplicaie, aceasta poate s continue procesarea, indiferent de stadiul celorlalte aplicaii. Pe de alt parte, middleware-ul sincron, este strns cuplat la aplicaii. Aplicaiile sunt dependente de middleware pentru a procesa unul sau mai multe apeluri funcie pe o aplicaie la distan. Ca rezultat, aplicaia care apeleaz trebuie s opreasc procesarea pentru a atepta aplicaia la distan s rspund. Acest tip de middleware este referit ca unul care blocheaz. Dezavantajul acestui model este cuplarea aplicaiilor la middleware i la aplicaia la distan. 3.3. Tipuri de middleware Middleware-urile au avut o evoluie continu de la apariie. Aceasta duce la apariia unor dificulti de a categorisi middleware-urile. Cu toate acestea, se observ existena a ctorva tipuri de middleware care se pliaz foarte bine pe rezolvarea anumitor tipuri de probleme. Urmtoarele tipuri de middleware vor fi descrise n continuare: RPC, MOM, obiecte distribuite, middleware orientat pe baza de date, middleware tranzacional (include monitori TP i servere de aplicaii) i servere de integrare. RPC (Remote Procedure Calls) reprezint cel mai vechi tip de middleware, uor de neles i folosit. Acesta ofer dezvoltatorilor capacitatea de a apela o funcie dintr-un program i de a o executa ntr-un alt program pe o maina la distan. (Figura 1.10) Pentru dezvoltator, funcia se excut local. Faptul c funcia este executat pe maina la distan este ascuns.

Figura 1.10. Functionarea RPC (Remote Procedure Calls) RPC-urile sunt modele sincron. Pentru ca RPC s fie activat, execuia programului trebuie oprit. n ciuda simplitii, majoriatea RPC-urile nu au o performan foarte bun. Cum majoritatea transferurilor de informaie necesit o reea, un middleware de tip RPC folosete toate resursele reelei. Un RPC tipic necesit 24 de pai distinci pentru a ndeplini cererile. Acest nivel de performan limiteaz beneficiile unui apel RPC ntr-o reea nceat, cum e internetul. Middleware-ul orientat pe mesaje (MOM) este un software care folosete mesaje, uniti de informaie (de tip BYTE) care sunt interschimbate de aplicaii, ca pe un mecanism de a face transfer de informaie de la un punct la altul. Deoarece MOM folosete mesajele pentru a comunica ntre aplicaii, nu este necesar cuplarea aplicaiilor la middleware (se bazeaz pe modelul asincron). Mesajul intr astfel ntr-o coad manager, care hotrte cnd este trimis mesajul la destinaia final. Mesajele care se ntorc la aplicaia apelant vor fi prelucrate cnd aplicaa va avea timp. Dezvoltatorii consider ca utilizarea mesajelor MOM este destul de uor de urmrit i organizat. Mesajele au o structur (schem) i un coninut (date). Se pot asemna cu baz de date cu o singur nregistrare care se mic ntre aplicaii printr-un mecanism de mesaje. Exist dou tipuri de modele pentru MOM: unu la unu i coad de mesaje (MQ). MQ permite fiecrui program participant s lucreze fr a fi ntrerupt de nivelul middleware. Deoarece software-ul MQ (seria MQ de la IBM, MSMQ de la Microsoft)

gestioneaz distribuia de mesaje de la un program la altul, coada manager poate optimiza performana folosind metode de prioritate.

Figura 1.11 Middleware orientat pe mesaje Pericolul ca mesajele s se piard cnd are loc o cdere de sistem exist. Majoritatea software-ului MQ permite ca mesajele s fie declarate ca persistente sau stocate pe disc la anumite intervale de timp, oferind astfel o protecie. Obiectele distribuite sunt clasificate ca fiind middleware, deoarece faciliteaz comunicarea ntre aplicaii. Obiectele distribuite sunt programe-aplicaii de mici dimensiuni care folosesc interfee i protocoale standard pentru comunicare. De exemplu, dac se creeaz un obiect distribuit CORBA care ruleaz pe un sever UNIX i unul care ruleaz pe un server NT, folosind un protocol standard de comunicaie, obiectele pot face interschimb de informaie i funcii (acelai standard CORBA, acelai protocol IIOP (Internet Inter ORB Protocol)). Exist dou tipuri de obiecte distribuite: CORBA i COM (Component Object Model). CORBA este creat de OMG n 1991 i este mai mult un standard dect o tehnologie oferind specificaii pentru crearea unui obiect distribuit. COM este creat de Microsoft i include interfee standard i protocoale de comunicaie. Middleware-ul orientat pe baza de date se refer la orice middleware care faciliteaz comunicaia cu o baz de date, fie cu o aplicaie, fie ntre mai multe baze de date. Dezvoltatorii folosesc acest tip de middleware ca pe un mecanism de extragere a informaiei dintr-o baz de date local sau la distan. De exemplu, pentru a extrage informaia dintr-o baz de date Oracle, dezvoltatorul trebuie s apeleze un middleware orientat pe baz de date pentru logarea la baza de date, cererea de informaie i procesarea informaiei care a fost extras din baza de date (Figura 1.12). Middleware-ul orientat pe baza de date lucreaz cu dou tipuri de baz de baze de date: CLI (Call Level Interface) i middleware nativ pe baza de date. CLI-urile reprezint API-uri comune, care ofer acces la baze de date folosind o interfa comun bine definit. De obicei, CLI lucreaz cu baze de date relaionale. Acesta este cazul i Open Database Connectivity (ODBC) de la Microsoft. ODBC-ul foloeste o interfat pentru a facilita accesul la o baz de date i drivere pentru a gestiona diferenele ntre bazele de date. ODBC-ul ofer un acces simultan, la baze de date multiple arhitectura ODBC presupune existena unui driver manager care sa faciliteze comunicaia ntre diferite baze de date.

Figura 1.12 Middleware orientat pe baze de date JDBC de la JavaSoft este un alt exemplu de CLI. JDBC este o interfa standard care folosete un singur set de metode Java pentru a facilita accesul la baze de date multiple. JDBC seaman cu ODBC i funcioneaz de pe orice aplicaie Java: applet, servlet, JSP, Enterprise JavaBean (EJB). Monitorii TP sunt prima generaie de servere aplicaii ca fel ca i produsele middleware de tip tranzacional. Acestea ofer un mecanism pentru a facilita comunicarea ntre dou sau mai multe aplicaii (Figura 1.13) precum i o locaie pentru logica aplicaiei. Exemple de TP includ Tuxedo de la BEA Systems, MTS de la Microsoft, CICS de la IBM.

Figura 1.13 Monitor TP Monitorii TP se bazeaz pe conceptul de tranzacie o unitate de lucru cu un nceput i un final. Raionamentul este c dac logica aplicaiei este ncapsulat ntr-o tranzacie, atunci tranzacia este fie finalizat sau anulat complet. Dac tranzacia a actualizat resurse aflate la distan (baze de date, cozi), aceste actualizri vor fi anulate de asemenea. TP asigur dou servicii importante. Pe de o parte, TP ofer servicii care garanteaz integritatea tranzaciilor (serviciu de tranzacie), iar pe de alt parte, un monitor TP asigur managementul resurselor i servicii de management pe termen lung (serviciu de aplicaie). Cele dou servicii sunt ortogonale. De asemenea monitorii TP, ofer conectori la resurse ca baze de date, alte aplicaii sau cozi. Aceti conectori necesit o dezvoltare de aplicaie sofisticat pentru a comunica cu tipurile variate de resurse. O dat conectate, aceste tipuri de resurse sunt integrate n tranzacii. Ca urmare, aceti conectori pot fi reconstituii dac apare o cdere de sistem. Serverele de aplicaie definesc segmentul pieei de middleware cu cea mai rapid evoluie. Cu toate acestea, tehnologia serverelor de aplicaii nu este nou (monitorii TP pot fi considerai servere de aplicaii datorit caracteristicilor comune). Majoritatea serverelor de aplicaii sunt middleware Web i proceseaz tranzacii aparinnd aplicaiilor Web. Noutatea acestor servere de aplicaii este c folosesc limbaje moderne ca Java n locul celor tradiionale procedurale ca C i Cobol (ceea ce se ntmpl la monitorii TP).

Figura 1.14 Arhitectura unui server de aplicaie tipic Mai simplu, serverele de aplicaii asigur posibilitatea accesului la alte aplicaii i fac posibil procesarea i resursele necesare connexiunilor. Aceste resurse includ baze de date, aplicaii ERP, i chiar i aplicaii tradiionale de tip mainframe. Serverele de aplicaii ofer interfeei utilizator mecanisme de dezvoltare. n plus, ofer de obicei mecanisme de amplasare a aplicaiilor pe platforma Web. Productorii de servere de aplicaie consider c produsele lor au o tehnologie ce permite rezolvarea problemelor de integrare a aplicaiilor. Ca urmare, serverele de aplicaie ca i monitorii joac un rol important n domeniul integrrii aplicaiilor. Muli dintre productori ncorporeaz tehnologii de gestiune a mesajelor, transformare i rutere inteligente, servicii care sunt native serverelor de integrare. Serverele de integrare reprezint partea de vrf a middleware-urilor pentru integrarea aplicaiilor, sau cel puin potenialul acestei tehnologii. Serverele de integrare pot facilita schimbul de informaie ntre dou

sau mai multe aplicaii surs sau destinaii i poate face diferena ntre semantincele aplicaiei i platforme. Ca urmare, aceast tehnologie se potrivete perfect cu integrarea aplicaiilor.

Figura 1.15 Servere de integrare Serverele de integrare pot aprea n multe aplicaii folosind reguli comune i motoare de rutere. Ele pot transforma schema i coninutul informaiei pe durata transferului ntre aplicaii i baze de date. Serverele de integrare sunt servere care gestioneaz mesaje ntre dou sau mai multe aplicaii surse sau destinaie. n plus, aceste servere transform schemele de mesaje i modific coninutul mesajelor. Serverele de integrare pot avea ntradevr funcii adiionale, incluznd un motor i o interfa de integrare a proceselor precum i un mecanism de management. Importana serverelor de aplicaii este n funcie de poziia ocupat de acestea n cadrul companiei. n general, serverele de integrare nu sunt o tehnologie de dezvoltare a aplicaiilor ci mai degrab sunt o tehnologie care permite comunicarea ntre mai multe aplicaii fr s presupun existena unui schimb de informaii despre natura aplicaiilor ntre care se face schimbul de date. Pe scurt, serverele de integrare gestioneaz informaia ntre baze de date i aplicaii. 4. Standardele de integrare a aplicaiilor n aceast parte a lucrrii sunt detaliate cele mai importante standarde de integrare a aplicatiilor. 4.1. XML, XSLT De la crearea sa, Extensible Markup Language (XML) a fost proiectat ca standard pentru interschimbul de informaie pe Internet. Ca urmare, aplicabilitatea la integrarea aplicaiilor este natural. XML-ul ofer un standard robust, uor de neles pentru schimbul de informaie care nu este doar o alegere consensual ci una unanim. XML-ul poate susine interschimbul de semantici ale aplicaiilor i de informaie. Tot acest proces se realizeaz fr ca aplicaiile destinaie s aib nevoie de informaii despre aplicaiile surs. XML-ul ofer un format comun de schimb de informaie, ncapsulnd att datele ct i metadatele. Acest format permite aplicaiilor i bazelor de date s comunice fr a avea informaii una despre cealalt. Pentru a comunica, sistemul surs reformateaz un mesaj, o informaie, sau o nregistrare ca un XML-text, i mut acea informaie ntr-ul alt sistem care tie s citeasc XML. Valoarea XML-ului rezid din simplitatea lui. Se pot lua cantiti mari de informaie i se pot consolida ntr-un document XML piese semnificative care dau structura i organizarea informaiei. (Figura 1.16)

Figura 1.16 XML- reprezentare simpl text a unor date complexe sau simple Blocul de baz al unui document XML este un elementul definit prin taguri. Un element are un tag de nceput i un tag de final. Toate elementele dintr-un document XML sunt coninute de un element rdcin. XML suport elemente radacina sau elemente n alte elemente de unde rezult c XML-ul poate susine o structur ierarhic. Numele elementelor descriu coninutul elementului, iar structura descrie relaiile dintre elemente. Un document XML este considerat bine format dac poate fi citit de un parser XML i dac formatul su se potrivete cu specificaiile XML. Se pot defini atribute ale elementelor i descrie caracteristici ale elementelor n tagul de nceput. Un parser XML citete documente XML i extrage datele ce urmeaz a fi accesate de alt program. Parserul este o parte component a nivelului middleware. (Figura 1.17) Pentru ca aplicaiile ce folosesc XML s poat fi integrate, ele trebuie s externalizeze informaia sub form de XML. Tehnologia middleware-XML gestioneaz extragerea informaiei din sistemul surs, conversia ei n XML i plasarea informaiei n sistemul destinaie, Tot procesul fiind automat i transparent pentru utilizator. Aa cum s-a mai specificat, XML este bazat pe text, i astfel o informaie care n mod normal poate fi stocat pe 512 KB, se poate mapa ntr-un fiier XML de 20 ori mai mare, acest fapt reprezintnd unul din dezavantajele utilizrii XML (Figura 1.17).

Figura 1.17 Extragerea informaiei prin parser XML Legtura ntre XML i middleware este clar deoarece tehnologia middleware realizeaz partea de transfer efectiv de mesaje care ncapsuleaz XML i se asigur c acele mesaje pot fi nelese de sistemele destinaie. Middleware-ul gestioneaz i interfeele cu aplicaiile surs i destinaie i mut informaia. XML-ul joac un rol mai mic n domeniul integrrii aplicaiilor n cadrul unei companii. Practic, n aceste cazuri sunt alese alte standarde i metode de integrare din motive de eficien. Totui, datorit descentralizrii controlului asupra informaiei, XML devine din ce n ce mai important. Multe companii ca Oracle-PeopleSoft i SAP folosesc acum XML ca interfa nativ pentru sistemele lor. Oracle-PeopleSoft deja a definit un produs, Open Integration Framework, care folosete XML. Mai mult dect att, productorii de sisteme de gestiune e bazelor de date ca Oracle, Sybase i Informix ofer mecanisme care permit XML-urilor s citeasc i s scrie direct n baza de date.

Rolul major al XML este n domeniul integrrii aplicaiilor ntre mai multe companii. Standardele XML ofer valoare suplimentar prin includerea nivelurilor de metadate comune care pot exista ntre unul sau mai muli parteneri membri ai tranzaciei, i chiar prin includerea mesanismelor de trasformare standard ca XSLT. Cele mai relevante standarde XML folosite pentru integrarea aplicaiilor sunt: RosettaNet, XEDI, BizTalk, Extensible Financial Reporting Markup Language (XFRML), XML-Schema, XML Query, i XSLT. . RosettaNet un cadru pentru interschimb de date i procese cu e-business. XEDI se refer la o specificaie care descrie cum trebuie mapat un EDI tradiional la un XML i invers BizTalk este fondat de Microsoft i definete un standard XML pentru XML-uri bazate pe mesaje i metadate. Microsoft ofer i un server BizTalk pentru a susine acest standard. XFRML este un standard definit de American Institute of Certified Public Accountants pentru a defini standarde XML pentru informaii financiare. XML-Schema este un grup de lucru al W3C care descrie un mecanism pentru determinarea structurii unui document XML XML Query Este un alt grup W3C care creeaz un set de operaii comune i sintax pentru a accesa date stocate XML XSLT este un limbaj proiectat s transforme un document XML ntr-un altul, modificnd att schema ct i coninutul procesului. Documentele XML sunt ca nite mesaje. Cum fiecare aplicaie are un set unic de semantici, documentele care circul ntre aplicaii trebuie s fie transformate (Figura 1.18). Att structurile de date, ct i coninutul trebuie s fie corecte din punct de vedere semantic pentru a fi ncrcate n aplicaia int. Dac datele nu au formatul necesar, atunci operaia de actualizare nu va reui.

Figura 1.18 Transformarea documentelor XML prin XSLT n plus, XSLT poate realiza i alte tipuri de procesare de text i operaii de transformare, care includ crearea formatelor de date standard bazate pe text ca PDF-uri sau alte formate. Transformarea unui document XML folosind XSLT necesit doi pai. Primul pas const ntr-o transformare structural, unde datele sunt transformate, de la o structur de intrare la o structur de ieire. Acest pas implic selectarea datelor, gruparea lor, sortarea lor, sau agregarea lor n funcie de necesitile trasnformrii. De exemplu, n cadrul unui document XML se poate face conversia de la dolari americani la franci francezi. Aceast transformare este bazat pe o rat de conversie valutar, fie cu o valoarea statistic sau citit dintr-o baz de date aflat la distan. 4.2. ebXML ebXML este un produs al colaborrii dintre UN/CEFACT i OASIS. Acest standard a fost construit pe baza XML ca i alte standarde Internet i servicii Web. Scopul su este crearea unei infrastructuri pentru comerul electronic bazat pe informaie i procese. ebXML este considerat un standard bun fiind folosit de cei care automatizeaz B2B. Unicitatea ebXML-ului este dat de completitudinea acestuia, adresnd probleme ca: procese; managementul tranzaciilor; semantici; notaii;

securitate; acorduri; standarde legate de transferul de informaie; standarde legate de structurarea informaiei; Cu toate acestea, completitudinea ebXML-ului poate fi considerat un factor ce limiteaz datorit duratei pe care o necesit pentru a se plia pe un domeniu. Standardul ebXML a fost creat pentru a nlocui EDI, sau alte standarde folosite n comerul electronic. El este un sistem de mesaje XML pentru schimbul de informaie i un depozit care permite accesul simultan la informaie. Sistemul de mesaje suport orice tip de date, tranzacii EDI i informaie binar. Mai mult dect att, ebXML suport acorduri de tranzacionare ntre parteneri o funcie fundamental a subsistemeleor partener EDI-ebXML poate fi folosit astfel pentru a reprezenta acordurile de servicii de afaceri. Ca i alte standarde (ebXML-ul nu este un produs) vine cu un set de reguli care permit productorilor de aplicaii i integrare de aplicaii s-si proiecteze produsele pentru a susine acest standard. 4.3. BPEL4WS Business Process Execution Language for Web Services BPEL4WS este practic un limbaj standard pentru integrarea proceselor i se folosete de conceptul proprietilor mesajelor de a identifica datele relevante din mesaje. Folosind acest mecanism, proprietile pot fi vizualizate n dou modaliti: transparent i opac. Datele transparente afecteaz protocoalele de afaceri publice; Datele opace sunt n primul rnd asociate cu sistemele back-end (afecteaz protocoalele de afaceri prin nedeterminare). BPEL4WS definete un model i o gramatic pentru descrierea comportamentului unui proces folosind interaciunile dintre proces i parteneri. Aceste interaciuni cu partenerii apar prin interfeele serviciilor Web, iar structura relaiilor la nivel de interfa exist ntr-o entitate cunoscut ca serviciu link. Misiunea unui proces BPEL4WS este s descrie cum interacioneaz cu aceti parteneri, definind un proces de afaceri i incluznd o logic de coordonare. Cu ajutorul acestui standard, se pot procesa excepiile i defini cum activitile individuale sau compozite dintr-un proces sunt compensate n cazuri n care excepiile apar. Exist dou concepte majore care trebuie evideniate cnd se consider standardul BPEL4WS n contextul integrrii aplicaiilor: Mai nti, un proces BPEL4WS poate defini un protocol de afaceri utilizind conceptul de proces abstract i oferind un mecanism pentru identificarea datelor relevante pentru protocol ca proprieti ale mesajelor care prin folosirea valorilor nondeterministice ascund proprietile private. n al doilea rnd, este posibil ca BPEL4WS s defineasc un proces de afaceri executabil care include logica i starea procesului. Acest mecanism gestioneaz conceptele de integrare a proceselor fundamentale. BPEL4WS exist ca o extensie a mai multor specificaii XML ca: WSDL 1.1 XML Schema 1.0 Xpath 1.0 n esena sa, BPEL4WS este o secven de activiti: 1. apeleaz serviciul Web 2. apelantul ateapt ca mesajul s opereze pe interfaa serviciului pentru a fi apelat de un serviciu extern 3. acesta genereaz un rspuns la o operaie de intrare-ieire 4. ateapt o anumite perioad de timp 5. indic c a aprut o eroare 6. atunci serviciul se ncheie 7. sau nu se ntmpla nimic. BPEL4WS ofer un set de faciliti pentru refacerea sistemului dup apariia unei erori n timpul execuiei unui proces, sau tratrii unei excepii.Acest standard se folosete de capacitile de tratare a excepiilor ncorporate n WSDL. Mai mult dect att, exist noiunea de compensare, n sensul c permite

proiectantului procesului s implementeze aciuni de compensare pentru anumite aciuni ireversibile. Acest aspect este tratat n BPEL4WS folosind noiunea de scop. Scopul este o unitate de lucru pentru compensare. BPEL4WS are potenialul de a deveni un standard bazat pe limbaj pentru integrarea proceselor, i permite crearea modelelor pe o singura tehnologie de integrare aplicaiilor, fr a face transformri asupra codului. 4.4. SOAP, WSDL, UDDL Simple Object Access Protocol (SOAP) definete un format XML bazat pe mesaje care este folosit de aplicaiile bazate pe servicii Web pentru a comunica i interopera ntre ele pe Web. SOAP este un standard pentru codificarea mesajelor n XML i care apeleaz funciile n alte aplicaii. Este analog cu Remote Procedure Calls (RPC) folosit de tehnologii ca DCOM sau CORBA, dar elimin o parte din complexitatea utilizrii acestor interfee. SOAP permite aplicaiilor s apeleze funcii din alte aplicaii, care ruleaz pe alt platforma hardware indiferent de sistemul de operare i limbajul de programare.

Figura 1.19 SOAP ofer mecanisme de comunicare ntre client i server Web Service Description Language (WSDL) este o colecie de metadate despre XML bazat per servicii folosit pentru descrierea scopului unei afaceri i cum se acceseaz electronic serviciile acestora. Bazat pe SOAP, WSDL specific procedurile pentru descoperirea informaiei tehnice i funcionale despre serviciile Web pe Internet. Un document WSDL este descris de un numr de elemente: Definiii tip, pentru elementele de date (n mod normal utiliznd XML Schema) Definiii de mesaje, care comprim unul sau mai multe elemente de date Definiii ale operaiilor, care reprezint descrieri abstracte ale aciunilor care pot fi suportate de serviciu, i care definesc care sunt mesajele de intrare sau de ieire Definiii PortType Definiii de conectare, care descrie conexiunea ntre PortType i protocoale(SOAP, HTTP, GET/POST) Definiii de servicii Ca urmare, se poate spune c WSDL ofer o abordare standard serviciilor Web. De asemenea, WSDL ofer un mecanism automat de generare a proxy-urilor pentru serviciile Web folosind un limbaj standard. Acest standard este analog IDL (Interface Definition Languages) care se gsete att n COM ct i n CORBA. Cu alte cuvinte, este un simplu contract ntre client i server. WSDL definete o gramatic XML pentru descrierea serviciilor reea ca o colecie de puncte finale de comunicaie care pot face transfer de informaie. Definirea serviciilor WSDL ofer o modalitate pentru automatizarea comunicrii ntre aplicaii (Figura 1.20).

Figura 1.20 Definirea serviciilor prin WSDL Universal Description, Discovery and Integration (UDDL) este un standard pentru catalogarea i publicarea descrierilor WSDL asociate serviciilor Web care sunt disponibile pe Internet. ntr-un mod asemntor cutrii informaiei n Pagini Aurii, la fel sistemele de comer pot cuta n registrul UDDL serviciile Web, apoi pot prelua parametrii de interaciune i pot interaciona efectiv cu serviciile Web gsite folosind SOAP.

Figura 1.21 UDDI Specificaiile UDDI intesc s defineasc un mecanism comun pentru publicarea i cutarea informaiei prin servicii Web. Creatorii UDDI (IBM, Microsoft, Ariba) ncearc s creeze un fel pe Pagini Aurii, dar pe internet. Prima generaie de specificaii este acum disponibil pe pia.

5 Etape ale EAI


Paii asociai procesului de integrare a aplicaiilor Procesul n 12 pai pentru integrarea aplicaiilor se bazeaz pe o abordare practic a integrrii aplicaiilor. O serie de activiti care in de proiectarea tradiional a bazelor de date, proiectarea i dezvoltarea aplicaiilor tradiionale sunt refolosite. De multe ori, sunt folosite aceleai abloane de proiectare pentru a conecta aplicaiile ntre ele. Aceast abordare pragmatic se bazeaz pe concepte familiare i termeni ca metadate, scheme, modelare orientat-obiect, analiz i proiectare orientat obiect. Cu toate c acestea nu sunt singurele activiti care trebuie luate n considerare ntr-un proiect de integrarea aplicaiilor, urmtorii pai trebuie urmai: 1. Inelegerea companiei i a domeniului problemei 2. Analiza semnificaiei datelor 3. Analiza semnificatiei proceselor 4. Identificarea tuturor interfeelor aplicaiei 5. Indentificarea tuturor proceselor de afaceri 6. Identificarea scenariilor de transformare a datelor 7. Maparea transferului de informaie 8. Aplicarea tehnologiei 9. Testarea 10. Analiza performanei

11. Definirea valorii 12. Crearea procedurilor de mentenan Este foarte important ca n procesul de integrare, de mare anvergur ntr-un lan colaborativ, organizaia s urmreasc: Abilitatea de a extage i importa date; Capacitatea de a comunica informaii prin intermediul protocoalelor Internet, bineneles cu acoperirea cerinelor necesare de protecie i securitate a datelor; Posibilitatea de a dezvolta noi procese economice n manier dinamic. Integrarea aplicatiilor unei intreprinderi (EAI) nseamn aducerea la un numitor comun a sistemelor i entitilor disparate, care vor fi regndite i modelate mpreuna pentru atingerea obiectivelor organizaiei. Aceste piese care vor fi combinate sunt: Diverse platforme i medii de operare Multiple aplicaii (proprii sau achizitionate cte una sau integrate n suite ERP) Diverse baze de date i sisteme de gestiune a acestora, Uniti organizatorice dispersate teritorial. n literatura de specialitate[1] sunt descrise patru stadii distincte ale procesului de integrare a sistemelor (fiecare dintre acestea se definesc individual, au proprieti, aspecte i complexiti distincte): Etapa 1: Interconectivitatea Etapa 2: Interoperabilitatea Etapa 3: Consistena semantic Etapa 4: Convergena integrrii In cadrul acetor etape exist apte direcii mari: 1. Integrarea hardware, adic interconectivitatea 2. Integrarea software, adic interoperabilitatea 3. Integrarea datelor i a depozitelor de date, adic integrarea semantica 4. Integrarea reelelor de comunicaii, care nseamn interconectivitatea, interoperabilitatea i integrarea semantic 5. Descrierea i integrarea noilor procese de afaceri cu noi performane tehnologice 6. ncorporarea cunotinelor n noile procese de afaceri i n noile tehnologii informaionale 7. Integrarea performanelor umane n procesele electronice de afaceri 5.1.Inteconectivitatea sau integrarea hardware Este etapa elementar i constituie infrastructura celorlalte. Presupune analiza modalitilor prin care echipamente i tehnologii diferite lucreaz mpreun. Sunt incluse, de asemenea, aplicaiile de partajare a perifericelor, transferurile de fiiere, crearea cilor de comunicaie dintre diversele componente. Aplicaiile de baz, funcionalitile i modurile de funcionare, legturile pentru urmtoarele stadii se stabilesc la acest nivel. 5.2.Interoperabilitatea sau integrarea software Vizeaz modalitatea prin care o aplicaie i tehnologia aferent comunic cu alt aplicaie i sunt exploatate functionalitile ambelor platforme. Interoperabilitatea este deosebit de important mai ales n domeniul bazelor de date, unde aplicaiile sunt complexe i se cere compatibilitate intre platforme. Portabilitatea ne permite s scriem soluii ntr-un mediu, apoi s l transferm n alte medii. Standardele de interoperabilitate ne permit s construim legturi ntre aplicaii care funcioneaz pe platforme complet diferite. Este de dorit s se tie ce standarde vor deveni universale (cum ar fi TCP/IP) i care vor eua. Modelul de Maturitate al Standardelor (Standard Maturity Model-SMM) poate fi folosit pentru a determina standardele i a prezice ct timp este necesar unui standard pentru a atinge completitudinea. SMM are 5 niveluri (Tabel):

Modelul de Maturitate al Standardelor Nivelul 5 - Adecvat din punct de vedere funcional Nivelul 4 - Multe aplicaii folosesc versiuni adcvate funcional Nivelul 3 - Este aprobat versiunea standardului adecvat funcional Nivelul 2 - Este propus versiunea 1.0 a standardului Nivelul 1 - Muli recunosc problema. Nivelul 0 - Puini realizeaz c este o problema. La Nivelul 1 al SMM, toat lumea tie c exist o problem, dar soluiile sunt proprietare. La Nivelul 2, vnztorii sau ntreprinderile colaboreaz la noul standard. Standardul nu este complet deoarece exist ntotdeauna lipsuri i ambiguiti n prima ncercare a unui standard, dar aceast versiune incipient este naintat unei instituii de standarde - cum ar fi Consortiumul W3 sau OASIS i comentariile sunt ateptate. La Nivelul 3, standardul a fost revizuit de cteva ori i acum este complet funcional. Se refer la problemele tehnice pentru care a fost propus. La Nivelul 4, cele mai multe aplicaii noi i cele mai noi instrumente implementeaz standardul. Maturitatea complet este atins la Nivelul 5. Aici cele mai multe aplicaii suport standardele de interoperabilitate i cele mai multe platforme folosite suport standardele portabilitii. Singurele standarde legate de servicii Web care au ajuns la Nivelul 5 sunt TCP/IP, HTTP i Secure Socket Layer(SSL).Chiar i XML, care este o piatr de ncercare pentru serviciile Web, este de abia la Nivelul 4 al SMM. Standardele serviciilor Web de baz trec acum (nov 2004) de la Nivelul 3 la Nivelul 4. Acestea includ: Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL) Universal Description, Discovery and Integration (UDDI). Acestea sunt complete din punct de vedere funcional, dar sunt n punctul n care distribuitorii construiesc suport pentru aceste standarde n toate produsele lor noi. Din fericire pentru cei care doresc s anticipeze integrarea plug-and play realizat prin serviciile Web, care au ajuns la nivelul 4, este partea cea mai uoar. Pentru a ajunge la nivelul 5, mii de aplicaii trebuie nlocuite sau prelucrate. Este un proces lung i costisitor i nu se ncheie foarte curnd. Ar putea dura 10, 15 ani pn cnd interoperabilitatea dintre aplicaii care folosesc SOAP, WSDL i UDDI s devin realitate. Aceste standarde ale serviciilor Web de baz permit doar scenariile cele mai simple de interoperabilitate. Standardele care guverneaz recunoaterea evenimentelor, transmiterea mesajelor n condiii de sigurana, logarea, transmiterea mai departe, gestiunea tranzaciilor i alte funcii avansate trebuie de asemenea standardizate nainte de a putea construi cazuri de utilizare mai complicate de interoperabilitate cu serviciile Web standarde. Dar nici atunci nu s-a atins integrarea adevarat. Din momentul n care standardele serviciilor Web devin mature i complete, tot ceea ce s-a obinut este interoperabilitatea plug-and-play. n alte cuvinte, poi transfera n condiii de siguran i securitate cifre i scrisori. Dar aplicaiile surs i destinaie nu sunt neaprat de acord din punct de vedere al semanticii datelor. n aplicaia surs, spre exemplu, itemul greutate poate nsemna greutatea net a itemului, msurat n pounds, dar aplicaia destinaie poate folosi greutatea itemului pentru a indica greutatea brut a itemului, n kg. Nu se poate vorbi despre integrare pn cnd problemele de semantic a datelor nu sunt rezolvate. De asemenea aplicaiile surs i destinaie trebuie s fie de acord cu privire la semantica tranzaciei. Integrarea plug-and-play complet se va produce cnd standardele rezolv att interoperabilitatea relevant ct i problemele de semantic.

5.3. Integrarea datelor i depozitelor de date Cel mai important efort investiional ntr-un proiect de integrare este ndreptat spre implementarea sistemelor de gestiune a bazelor de date i a sistemelor sofisticate de analiz i raportare managerial. Eforturile sunt ndreptate spre raionalizarea datelor, termenelor, scadenelor i planurilor. Accente deosebite sunt acordate accesibilitii datelor i minimizrii erorilor umane n crearea definiiilor standard i a formatelor pentru date. Pentru integrarea semantic nu este suficient simpla implementare a sistemelor de gestiune a bazelor de date, datele trebuie s suporte un proces de raionalizare pentru utilizarea lor cu acuratee. Nevoile critice ale Datelor:[3] Volumul, diversitatea i viteza datelor n organizaii cresc. Volumele de date sunt n cretere odat cu creterea afacerii. Diversitatea datelor crete datorit numrului de aplicaii implementate i din activitatea de achiziie. Viteza datelor crete datorit cererii de procesare n timp real. Pentru a realiza integrarea informaiei corect, e bine s se ia n considerare definirea informaiilor operaionale i financiare care ajut la luarea deciziilor n organizaie. Acest lucru se realizeaz cel mai bine cu ajutorul unor echipe cu diferite funcii i responsabiliti organizaionale variate. n mod obinuit, informaia provenind de la uniti multiple ale organizaiei este reprezentat pe zone de interes i unele uniti sunt implicate n toate domeniile. Acest fapt se va considera critic n determinarea potenialelor lipsuri, redundane i neconsistene. Echipa ar trebui s identifice i s elimine redundane nenecesare i s integreze sursele rmase. Datoria EAI este s realizeze accesibilitatea datelor unei aplicaii din punct de vedere semantic i sintactic pentru o alt aplicatie.[4] Dei nu este singurul factor, costul ridicat al proiectelor de integrare este legat direct de dificultatea integrrii datelor. Nivelul de dificultate are dou componente primare: transportul de date i incompatibilitatea datelor. Cele mai simple cauze ale incompatibilitii datelor sunt sintactice. Prin aspectele sintactice, se neleg pri ale problemei care se refer la format i structur. Spre exemplu, reprezentarea intern sau stocat ntr-un depozit de date poate fi sub forma sirurilor de caractere i sub forma binar n altele. 5.4. Integrarea reelelor de comunicaie Este nivelul cel mai sofisticat, depinde de parcurgerea celor anterioare i presupune mai mult dect integrarea tehnologiilor, aplicaiilor i rationalizarea bazelor de date partajate. Integrarea sistemelor reprezint kilometrul zero al crerii de noi forme organizaionale (ntreprinderea virtual) i naterea unor procese noi de afaceri. Convergena integrrii antreneaz integrarea tehnologiilor cu procesele de afaceri, cu performanele i cunotinele umane.

6. Studiul integrrii a dou aplicaii


Integrarea este un termen aplicat soluiilor software ca divers i avnd rolul de a mbunti procesele prin conectarea sistemelor distincte i independente, conectnd componente pre-definite ntr-o aplicaie complex prin intermediul unor interfee bine definite sau sincronizarea de date aflate n multiple locaii care partajeaz o schem comun. n fiecare din aceste cazuri, soluiile software integreaz sau conecteaz aplicaii, dar similaritatea deseori se ncheie aici. Fiecare din aceste probleme de integrare pot fi deseori rezolvate printr-o soluie diferit. Exist patru factori cheie care pot fi utilizai pentru a ne ghida n alegerea unei soluii: 1. Cuplarea aplicaiilor, care definete apropierea ntre instane ale aplicaiei 2. Starea conexiunii, care definete cerina de conectivitate dintre aplicaii 3. Relaia de ncredere dintre dou aplicaii care determin granularitatea i complexitatea permise de soluia de integrare

4.

Gradul de vizibilitate al schimbrii care definete cantitatea de schimbare vizibil i tolerat de organizaia care meine sistemul integrat.

1. Cuplarea aplicaiilor Cuplarea aplicaiilor definete relaia dintre dou aplicaii din punct de vedere funcional. Factorul deseori dicteaz dac integrarea ar trebui s se produc la nivelul serviciului, procesului sau datelor. Aplicaiile cuplate cu uurin sunt construite fr a ti una de alta i orice integrare se poate produce pe baze predefinite; aceasta necesit presupuneri din partea proiectanilor aplicaiilor despre cum vor interaciona aplicaiile. Spre exemplu o aplicaie care rspunde comenzilor, este posibil s aib nevoie doar de o uoar cuplare cu o aplicaie de expediere, n timp ce o aplicaie de vnzri n echip poate necesita o cuplare strns ntre mai multe aplicaii. n timp ce aplicaia care rspunde comenzilor poate folosi o abordare a integrrii la nivel de proces, integrarea echipei de vnzri ar putea fi mai bine servit printr-o abordare a integrrii la nivel de date. Relaia dintre aplicaii poate fi capturat n descrierea unui serviciu pentru toate interaciunile i manifestrile serviciului n colecia de astazi de standarde legate de Service Oriented Architecture (SOA). Web Service Description Language (WSDL) este primul standard implementat care descire ntr-o form ce poate fi citit de o main serviciile individuale oferite i schema de informaii care vor fi schimbate. Colecia de standarde legate de serviciile Web ndreapt acum abordarea SOA spre integrarea aplicaiilor.La nivelul de date, aceste standarde sunt n general nlocuite de o schem bine definit care permite integrarea foarte strns la nivele diferite. La un nivel intermediar, o aplicaie poate avea nevoie s ofere o abordare la nivel de proces unde serviciile individuale sunt definite i un proces este captat de efortul de integrare. Integrarea la nivelul unui proces a evoluat pentru a suporta o componenta software intermediar care vegheaz asupra conversaiei dintre aplicaii. Conversaia dintre aplicaii este rareori un proces pur, dar deseori este un artifact al arhitecturilor IT i al proiectrii aplicaiei. La acest nivel, efortul de integrare este deseori descris drept integrarea proceselor sau orchestrarea serviciilor i a evoluat n continuare n Enterprise Service Bus (ESB), o abordare deschis fa de standarde, nou. Pentru aplicaiile strns cuplate, consistena schemei este un factor decisiv al integrrii. n loc s predefineti toate punctele de integrare la nivelul serviciului i al procesului, integrarea la nivelul de date permite integrarea mai departe fr s fie nevoie s se efectueze schimbri n ambele aplicaii . Cnd exist distincii majore ntre scheme, un format canonic trebuie schimbat ntre aplicaii, care reprezint deseori un set semnificativ de date disponibile in fiecare aplicaie. Cel mai obinuit caz de integrare la nivel de date este integrarea ntre mai multe instane ale aceleiai aplicaii, care menin un set de date distribuit, dar sincronizat. Aplicaiile de acest tip partajeaz o schem identic; toate documentele i datele persistente sunt stocate n formate identice din punct de vedere logic, chiar dac folosesc baze de date diferite sau subseturi de date. Aplicaiile cu scheme consistente, strns cuplate, necesit o tehnologie de sincronizare a datelor avansat. Integrarea la nivel de date simplific sarcina captrii tuturor interaciunilor posibile care ar fi expuse drept puncte de integrare la nivel de serviciu sau proces i optimizeaz i automatizeaz interaciunea dintre aplicaii . Aceast automatizare este adevrata putere din spatele cuvntului sincronizare pentru aplicaiile strns cuplate. Cuplarea aplicaiilor trebuie s fie considerat n contextul conexiunii dintre aplicaii sau factorul strii de conexiune. 2. Starea conexiunii n timp ce cuplarea aplicaiilor poate s ajute s se determine ce opiuni de integrare au sens, starea conexiunii dintre dou aplicaii trebuie s fie i ea luat n considerare. Dac un set integrat de aplicaii necesit conexiuni active ntotdeauna, atunci setul poate fi gestionat ca o singur aplicaie. Dac orice aplicaie din set eueaz, atunci nici una din aplicaiile individuale nu mai poate fi folosit.

Aceste dependene sunt deseori rezultatul arhitecturilor accidentale care evolueaz n cadrul infrastructurii centrale a organizaiei. Din ce in ce mai mult, este o cerin ca aplicaiile individuale s fie capabile s opereze independent i s supravieuiasc cnd sunt deconectate ocazional. Chiar i mai n cretere este valul de aplicaii care trebuie s opereze ca aplicaii strans conectate cnd sunt conectate, n timp ce n cea mai mare a timpului oferind funcionalitate complet utilizatorilor chiar i atunci cnd sunt deconectate de la reea. Aceast funcionalitate include colectarea sau sincronizarea sarcinilor care trebuie efectuate cnd aplicaia nu e conectat. Aplicaiile care trebuie s opereze deconectate trebuie s menina un set de date n Synchronized Local Storage (SLS) pentru datele de baz folosite de aplicaie pentru a oferi suport pentru funcia aplicaiei. Cnd o aplicaie opereaz deconectat, actualizrile la setul de date trebuie gestionate eficient, astfel nct, cnd sunt conectate mai tarziu s poat fi sincronizate cu alte aplicaii. Seturile de date SLS constau de obicei din fiiere sau date relaionale i permit accesul utilizatorului pentru citire i scriere, chiar i atunci cnd nu sunt conectate la o baz de date centralizat. Pentru datele relaionale, tehnologia de sincronizare sofisticat ofer un suport robust pentru fluxul de date bidirecional necesar s suporte un mediu SLS. Mai depate, cea mai avansat tehnologie de sincronizare permite unui set de date s fie partiionat ntro colecie integrat de instane ale aplicaiei. Partiionarea datelor poate reduce semnificativ cantitatea de date necesare pentru fiecare aplicaie i sincronizare. 3. ncrederea Relaia de ncredere ntre dou aplicaii software este definit de circumstanele oranizaionale care privesc aplicaia. ncrederea este un concept abstract pentru arhitecii software care trebuie luat n considerare n alegerea abordrii de integrare a aplicaiilor, dar trebuie luat n considerare din moment ce poate avea un impact important n detaliile de implementare. S lum n considerare dou afaceri independente care schimb ntre ele informaii financiare critice sau doi furnizori din domeniul sntii care shimb informaii despre pacieni. ncrederea dintre cele dou aplicaii n acest context este ncorporat n capacitatea aplicaiilor de a partaja informaii. La cel mai nalt nivel al ncrederii, setul complet de date poate fi partajat ntre aplicaii, permind acces nelimitat la date n limita granielor dictate de schema de definiie. n timp ce dou organizaii trebuie s aib ncredere una n cealalt pentru a nu abuza una de sistemul celeilalte, fiecare poate avea nevoie s ofere o barier ntre sisteme mcar din motive legale care dicteaz o relaie de ncredere sczut ntre aplicaii. 4. Schimbarea vizibil Schimbarea vizibil este un factor al integrrii care indic angajamentul pe care o organizaie va trebui s l fac pentru a menine soluia de integrare dintre cele dou aplicaii. ntr-un mediu cu schimbri vizibile reduse, trebuie depus puin efort pentru meninerea nivelului de integrare intre dou soluii. ntr-un mediu cu schimbri vizibile ridicate, este necesar o investiie semnificativ pentru a menine nivelurile de integrare. Schimbarea vizibil tinde s fie ridicat in timpul eforturilor integrrii intiale si apoi scade dramatic odat ce integrarea atinge un nivel care rspunde cerintelor organizationale. In aplicatiile in care modelele afacerii dinamice sau reglementrile guvernamentale au un impact important, schimbarea vizibil poate rmane ridicat. Deseori, gradul schimbrii vizibile este dictat de controlul unei singure organizatii asupra intregului sistem. Increderea si schimbarea vizibil sunt legate strans, dar, chiar, in medii cu incredere ridicat, exist extreme de schimbare care ar trebui s conduc abordarea spre integrare.

Pe de o parte este integrarea cu o diversitate de sisteme externe, fiecare putandu-se schimba oricand. Dac suficiente aplicatii sunt integrate, rezultatul poate fi un flux constant de schimbri scumpe care necesit schimbri in toate aplicatiile integrate. Dac schimbarea aplicatiilor sunt multiple instante ale aceleiasi aplicatii, schimbarea unei aplicatii devine aceeasi in toate instantele, astfel reducandu-se dramatic costul atat al realizrii schimbrilor cat si al complexittii desfsurrii. Intr-un mediu cu schimbare vizibil in care aplicatiile sunt ameliorate in mod constant, gradul schimbrii vizibile poate ramaen sczut. Spre exemplu, o aplicatie care este desfsurat in mai multe instante, fiecare din ele fiind integrat intr-o solutie complet, poate experimenta o schimbare considerabil, dar schimbarea este reflectat in toate instantele aplicatiei si ca rezultat, exist o schimbare vizibil minim.Ca efect deoarece integrarea este intre mai multe instante ale aceleiasi aplicatii, schimbarea vizibil este minizat dar provocarea devine cum s actualizezi aplicatia, schema si seturile de date intr-o manier coordonat. Aplicatiile centralizate au o incredere redus cu sistemele externe, o schimbare vizibil redus deoarece sunt mature, o cuplare a aplicatiilor slab (deseori cu mecanisme bazate pe fisiere pentru a importa si exporta date din sistem ctre alte sisteme), si intotdeaunape seama cerintelor conexiunii. Abordarea traditional pentru integrarea aplicatiilor centralizate foloseste Enterprise Information Service (EIS), SOA si din ce in ce mai mult Enterprise Service Bus (ESB) pentru integrare. Cand selectezi o solutie, trebuie s determini cum iti influenteaz decizia factorii de integrare. Astzi aplicatiile distribuite care se desfsoar pe multiple instante in cadrul afacerii globale au incredere ridicat, schimbare vizibil variat (depinzand de locul in care se potrivesc in ciclul lor de viata) si cuplare a aplicatiilor strans din moment ce, deseori, cerinta este s opereze aceeasi aplicatie in mai multe locatii. Aceste aplicatii trebuie s suporte mai mult decat o conexiune mereu active si s ofere o functionare complet in cazul deconectrii mediului. Ca rezultat, necesit un set de date metinut in SLS. Abordarea eforturilor integrrii SLS poate reduce eforturile integrrii deoarece automatizeaz sarcinile altfel greoaie de expunere a functionalittii aplicatiei prin multiple interfete de proces si serviciu. Dac afacerile inteleg factorii cuplarea aplicatiei, starea de conectivitate, relatia de incredere si schimbarea vizibil, vor fi capabil sa identifice mai usor filosofia potrivita din spatele selectiei unei solutii de integrare. Luarea in considerare a acestor factori ajut in procesul de luare a deciziei.

Sisteme informatice integrate 2 -sem2 2008 Titular disciplina: Prof.univ.dr. Zenovic GHERASIM TRUE/FALSE 1. Simple Object Access Protocol (SOAP) defineste un format XML bazat pe mesaje care este folosit de aplicatiile bazate pe servicii Web pentru a comunica si interopera intre ele pe Web. 2. Integrarea orientata pe informatie reprezinta mecanismul de gestiune a datelor interschimbate si apelarea proceselor intr-un mod corect astfel incat sa permita gestionarea si executia proceselor comune care exista in si intre aplicatii. 3. Federatia datelor se refera la integrarea mai multor baze de date si modelelor asociate intr-o singura baza de date, cu un view unificat. 4. Spre deosebire de replicarea datelor, federatia datelor necesita modificari ale aplicatiilor tinta. 5. La sistemele informatice integrate, solutiile de procesare a interfetei folosesc interfete ale unor aplicatii bine definite pentru a se axa atat pe integrarea aplicatiilor pachet cat si a aplicatiilor informatice obisnuite. 6. Un set comun de metode intr-o aplicatie care foloseste reutilizarea mareste redundanta metodelor si a aplicatiei. 7. La integrarea orientata pe servicii, costurile ar putea, in anumite cazuri, sa depaseasca valoarea creata de integrare. 8. Middleware-ul este un mecanism care permite unei entitati (baza de date sau aplicatie) sa comunice cu alta entitate sau entitati. 9. Avantajul modelului middleware unu la unu este complexitatea, modelul middleware multi la multi avand dezavantajul simplitatii.. MULTIPLE CHOICE 1. Printre caracteristicile unui sistem informatic integrat nu se regasesc: a. autonomia si comportamentul probabilistic b. numarul mare de variabile si inter-relatii c. autonomia si urmarirea obiectivelor proprii multiple d. numarul mare de angajati e. date integrate 2. Exista urmatoarele tipuri de integrare: a. integrare orientata pe informatie; b. integrare orientata pe procesele de afaceri c. integrare orientata pe servicii; d. integrare orientata pe portal e. toate variantele prezentate 3. Solutiile integrarii orientate pe informatie pot fi grupate dupa: 1) replicarea datelor; 2) federalizarea datelor; 3) procesarea interfetei; 4) standardele de securitate. Care este combinatia corecta: a. 1+2+3; b. 1+3+4; c. 2+3+4; d. 1+2+4; e. Niciuna dintre variante

4. Printre tipurile de modele middleware se regasesc: 1) Middleware unu la unu; 2) Middleware mai multi la mai multi; 3) Middleware sincron si asincron 4) Middleware unu la multi; 5) Middleware paralel. Care este combinatia corecta: a. 1+2+3; b. 1+3+4; c. 1+2+5; d. 2+4+5; e. 2+3+5 5. Serverele de integrare: a. gestioneaza mesaje intre doua sau mai multe aplicatii; b. transforma schimbul de mesaje c. modifica continutul mesajelor; d. au interfata de integrare si un mecanism de management e. toate variantele prezentate 6. Cele mai importante standarde de integrare a aplicatiilor sunt: a. XML-XSLT; b. ebXML; c. Business Process Executive Language for Web Services d. SOAP; e. toate variantele prezentate 7. EAI (Integrarea aplicatiilor unei intreprinderi) urmareste integrarea: a. diverselor platforme de operare; b. aplicatiilor independente si integrate c. bazelor de date; d. unitatilor organizatorice dispersate teritorial e. toate variantele prezentate 8. In procesul de integrare o organizatie trebuie sa urmareasca: 1) Abilitatea de a extrage si importa date 2) Comunicarea sigura prin intermediul protocoalelor de internet 3) Dezvoltarea dinamica de noi procese economice 4) Reducerea costurilor de productie 5) Minimizarea cererilor de date a. 1+3+4; b. 2+3+5; c. 1+4+5; d. 1+2+3; e. 3+4+5 9. Serverele de aplicatii: a. pot rula tranzactii b. permit reciclarea obiectelor c. poseda Autorecovery System d. ofera incarcare echilibrata e. toate variantele prezentate 10. Un sistem informatic integrat bazat pe Internet foloseste o arhitectura software formata din: a. un sistem de operare b. un server web c. o baza de date d. un limbaj de programare e. toate variantele prezentate 11. Securitatea unui sistem informatic bazat pe Internet vizeaza: a. Utilizarea de licente si certificate digitale (SSL) b. Autentificarea criptata a utilizatorilor pe mai multe nivele aplicatie c. Utilizarea retelelor virtuale private (VPN) d. Protectia bazei de date e. toate variantele prezentate 12. Din punct de vedere al scopului integrarii sistemelor informatice se disting: a. sisteme informatice pentru management (MIS)

b. sisteme informatice pentru automatizarea lucrarilor de birou (OAS) c. sisteme informatice pentru asistarea deciziilor (DSS) d. sisteme informatice pentru procesarea tranzactiilor (TPS) e. toate variantele prezentate 13. Nu sunt metode de proiectare a sistemelor informatice integrate: a. metodele nestructurate b. metodele structurate orientate pe date c. metodele obiectuale d. metode structurate orientate pe functii e. metode structurale orientate pe tipuri 14. In analiza specificatiilor unui sistem informatic se utilizeaza diagrame: a. de clase b. de stari c. de activitati d. de secventa e. toate variantele prezentate 15. Problemele tehnice ale integrarii se datoreaza: a. omogenitatii solutiilor hard b. omogenitatii solutiilor soft c. existentei acelorasi tehnologii d. diversitatii organizatiilor economice e. eterogenitatii solutiilor hard, soft si diversitatii tehnologiilor utilizate 16. Problemele informationale ale integrarii sistemelor informatice sunt datorate: a. inconsistentei datelor b. existentei acelorasi date in sistem c. modului in care sunt dezvoltate aplicatiile informatice d. proceselor de afaceri e. modului de construire a portalurilor 17. Infrastructura de integrare a sistemelor informatice asigura: a. un cadru centralizat, scalabil si gestionabil pentru integrare b. un cadru centralizat, scalabil si gestionabil pentru distribuirea aplicatiilor c. un cadru eficient pentru proiectarea unei noi aplicatii d. dezvoltarea unor noi standarde pentru distribuirea datelor e. realizarea unor noi limbaje pentru descrierea modelului de afaceri 18. Definirea scopului integrarii sistemelor informatice presupune: a. definirea problemei de afaceri care trebuie rezolvata b. proiectarea bazei de date c. elaborarea limbajelor de programare d. implementarea aplicatiilor e. proiectarea interfetelor 19. Unul dintre avantajele pe care o suita de aplicatii informatice integrate trebuie sa le ofere beneficiarilor este: a. cresterea costurilor pe termen lung b. diminuarea eficientei operationale c. recuperarea lenta a investitiilor in IT

d. protectia bazelor de date e. migrarea mai rapida la modele de e-business 20. Cele trei niveluri ale arhitecturii unui sistem ERP sunt: a. baza de date, sesiune, prezentare; b. fisiere, aplicatie, prezentare; c. baza de date, retea, prezentare; d. baza de date, aplicatie, prezentare. e. baza de date, retea, utilizator 21. Care dintre urmatoarele variante nu se regaseste printre strategiile de implementare a sistemelor ERP: a. strategia Big Bang b. strategia integrala c. strategia de parteneriat d. strategia cu riscuri e. strategia paralela 22. Care dintre urmatoarele variante nu se regaseste printre strategiile de tranzitie de la vechiul sistem informatic la noul sistem ERP: a. strategia paralela b. strategia cu riscuri minime c. strategia secventiala d. strategia integrala e. strategia in faze 23. Care dintre urmatoarele variante nu reprezinta o etapa in procesul migrarii datelor: a. export de date b. analiza multidimensionala a datelor extrase c. procesare a datelor d. import in bazele de date destinatie e. conversia datelor extrase 24. Printre tipurile de integrare a aplicatiilor informatice se regaseste: a. integrarea prin replicare b. integrarea prin procese de afaceri c. integrarea prin federalizare d. integrarea prin procesarea interfetei e. Integrarea protocoalelor de retea 25. Care dintre urmatoarele variante nu este un motiv pentru utilizarea unor metodologii de implementare a sistemelor ERP: a. reducerea timpului de implementare b. controlul proceselor c. imbunatatirea calitatii sistemelor d. recuperarea rapida a investitiilor in IT e. urmarirea proceselor 26. Se considera etapele: 1) Analiza preliminara 2) Pregatirea sistemului 3) Migrarea datelor

4) Analiza detaliata 5) Evaluarea sistemului 6) Start : Pilot si Go Live 7) Predarea sistemului 8) Instruirea utilizatorului Cele opt etape ale implementarii unui sistem ERP sunt, in ordinea de realizare: a. 1+2+3+4+5+6+7+8 b. 1+4+3+2+5+6+7+8 c. 1+4+2+3+5+6+7+8 d. 1+4+2+3+8+6+7+5 e. 1+3+2+5+8+6+7+4 27. Complexitatea si costul unui sistem ERP sunt influentate de: a. marimea firmei care necesita informatizare b. infrastructura tehnologica c. specificul de activitate d. gradul de dispersare geografica e. toate variantele de mai sus 28. Printre componentele esentiale ale unui SCM nu se regaseste: a. planul b. produsul c. livrarea d. destinatia e. sursa 29. Deciziile privitoare la SCM se realizeaza pe trei niveluri: a. operational, tactic, executiv b. operational, tactic, strategic c. operational, executiv, strategic d. tactic, mediu, strategic e. tactic, executiv, strategic 30. Dificultati intampinate de aplicatiile SCM: a. timpul de implementare foarte scurt b. rezistenta la dezvoltarea aplicatiilor c. rezistenta interna la schimbari d. securitatea bazei de date e. securitatea retelelor 31. Solutiile de integrare a sistemelor informatice orientate pe informatii pot fi grupate in urmatoarele trei categorii: 1)Replicarea datelor 2)Copierea datelor 3)Federatia datelor 4)Stergerea datelor 5)Procesarea interfetei a. 1+2+3; b. 2+3+4; c. 1+3+5; d. 3+4+5; e. 1+2+4 32. Avantajele replicarii bazelor de date sunt: 1)simplitatea 2)corectitudinea

3)costurile scazute 4)numar nelimitat de inregistrari a. 1+2; b. 1+3; c. 2+4; d. 3+4 33. n realitate, integrarea procesului de afaceri este un alt nivel de valoare, adaugat peste solutiile de integrare a aplicatiilor, solutii care includ: 1)integrarea serverelor 2)obiecte ascunse 3)serverele de aplicatii 4)obiecte distribuite 5)nivelele relevante 6)alte nivele middleware. a. 1+2+3+4; b. 2+3+4+5; c. 1+3+4+6; d. 3+4+5+6; e. 1+3+4+5 34. Integrarea proceselor de afaceri ofera un mecanism: 1)pentru legarea proceselor disparate 2)pentru integrarea mai multor baze de date cu un view unificat 3)pentru a crea solutii proces-proces care automatizeaa o sarcina o data ce aceasta a fost realizata manual 4)pentru simpla mutare a datelor intre doua sau mai multe baze de date a. 1+2; b. 1+3; c. 2+3; d. 2+4; e. 3+4 35. La federatiile de baze de date, nivelul middleware: 1)conecteaza bazele de date folosind interfete 2)conecteaza utilizatorii pentru schimb de mesaje de tip e-mail 3)mapeaza bazele de date fizice intr-o baza de date virtuala care exista numai in software 4)permite ca aplicatia ce foloseste baza de date virtuala sa acceseze informatiile necesare 5)asigura colectarea si distribuirea datelor, pe masura ce acestea sunt necesare, catre bazele de date fizice 6)asigura stocarea temporara a e-mail-urilor a. 1+2+3+4; b. 2+3+4+5; c. 1+3+4+5; d. 2+3+4+6 36. Exista multe diferente intre integrarea de aplicatii traditionala si integrarea bazata pe procesul de afaceri: 1) o singura instanta a integrarii procesului de afaceri este echivalenta cu mai multe instante ale integrarii aplicatiilor traditionale 2) integrarea aplicatiilor se refera la schimbul de informatii intre doua sau mai multe sisteme fara ca procesele interne sa fie vizibile 3) integrarea proceselor de afaceri conduce la un model de proces si muta informatia intre aplicatii conform modelului respectiv 4) integrarea aplicatiilor este tipic o solutie tactica, motivata de cerintele a doua sau mai multe sisteme de a comunica 5) integrarea de aplicatii traditionala nu mai este posibila fara integrarea bazata pe procesul de afaceri 6) integrarea procesului de afaceri este strategica, gestionand regulile de afaceri pentru a determina cum ar trebui sa interactioneze sistemele astfel incat sa sustina valoarea afacerii din fiecare sistem folosind un model de afaceri abstract a. 1+2+3+4+5; b. 2+3+4+5+6; c. 1+2+3+4+6; d. 1+3+4+5+6; e. 1+2+3+4+5+6 37. Cele trei servicii majore pe care le ofera integrarea orientata pe procese de afaceri sunt: 1)vizualizarea proceselor continute de sistemele in cauza 2)abstractizarea interfetei

3)abstractizarea bazei de date 4)o masura in timp real a performantei procesului de afaceri a. 1+2+3; b. 1+2+4; c. 1+3+4; d. 2+3+4; e. 1+2+3+4 38. Exista doua tipuri de modele pentru middleware-ul orientat pe mesaje-MOM: 1)unu la unu 2)unu la multi 3)multi la multi 4)coada de mesaje (MQ) a. 1+2; b. 1+3; c. 2+3; d. 1+4; e. 3+4 39. Un parser XML: 1)citeste documente XML 2)extrage datele ce urmeaza a fi accesate de alt program 3)micsoreaza spatiul de memorie ocupat de un document text 4)este o parte componenta a nivelului middleware a. 1+2+3; b. 1+2+4; c. 2+3+4; d. 1+3+4; e. 1+2+3+4 40. Unicitatea standardului ebXML este data de completitudinea acestuia, adresand probleme ca: 1)procese 2)managementul tranzactiilor 3)semantici 4)notatii 5)securitate 6)acorduri 7)standarde legate de transferul de informatie 8)standarde legate de asistarea deciziei 9)standarde legate de structurarea informatiei a. 1+2+3+4+5+6+7+8; b. 2+3+4+5+6+7+8+9; c. 1+2+3+4+5+6+7+9; d. 1+3+4+5+6+7+8+9 e. 1+2+3+4+5+6+7+8+9 41. Procesul pentru integrarea aplicatiilor (EAI) contine urmatorii 12 pasi: 1. Intelegerea companiei si a domeniului problemei 2. Crearea procedurilor de mentenanta 3. Identificarea tuturor interfetelor aplicatiei 4. Indentificarea tuturor proceselor de afaceri 5. Aplicarea tehnologiei 6. Analiza semnificatiei proceselor 7. Testarea 8. Analiza performantei 9. Maparea transferului de informatie 10. Analiza semnificatiei datelor 11. Identificarea scenariilor de transformare a datelor 12. Definirea valorii Indicati ordinea corecta a celor 12 pasi. a. 1+6+4+10+11+7+2+5+3+9+12+8 b. 1+2+3+4+5+6+7+8+9+10+11+12 c. 1+8+3+9+4+7+11+10+12+2+5+6 d. 1+10+6+3+4+11+9+5+7+8+12+2 e. 1+9+11+12+3+8+4+7+10+2+5+6

COMPLETION 1. ntr-o forma simpla, integrarea sistemelor informatice orientata pe procesul de afaceri produce un nivel ce contine un set de procese central-gestionate si usor ______________. 2. Un trend clar in evolutia integrarii aplicatiilor informatice este trecerea de la integrarea bazata pe informatie la integrarea bazata pe ______________ . 3. Practic, federatiile bazelor de date reprezinta bazele de date ______________. 4. Software-ul federatiei bazelor de date plaseaza un nivel software (______________) intre bazele de date distribuite fizic si aplicatiile care vizualizeaza datele. 5. In cazul integrarii orientate pe portal, toate sistemele participante sunt integrate intr-un _______, chiar daca aplicatiile nu sunt direct integrate in cadrul si intre mai multe companii. 6. Middleware-ul orientat pe baze de date se refera la orice middleware care faciliteaza comunicatia cu o baza de date, cu o ___________ sau intre mai multe baze de date. 7. Majoritatea serverelor de aplicatii sunt middleware Web si proceseaza ___________ apartinand aplicatiilor Web. 8. Serverele de integrare gestioneaza informatia intre baze de date si _______________. 9. Limbajul de marcare extensibil - Extensible Markup Language (XML) - a fost proiectat ca standard pentru interschimbul de informatie pe__________________ . 10. Blocul de baza al unui document XML este un elementul definit prin ___________ . 11. Specificatiile UDDI tintesc sa defineasca un ___________ comun pentru publicarea si cautarea informatiei prin servicii Web. MATCHING Caracteristicile unui sistem informatic integrat sunt, intre altele, urmatoarele: a. Autonomia b. Incertitudinea c. Variabilele d. Obiectivele multiple 1. un numar excesiv de mare de variabile si inter-relatii ce nu pot fi in totalitate cunoscute, ajustate si controlate 2. elementele constitutive ale sistemului informatic au posibilitatea urmaririi indeplinirii unor obiective proprii care pot fi dependente sau independente de obiectivele generale ale sistemului. Un singur obiectiv sau un set unitar de obiective este o iluzie pentru un adevarat sistem de sisteme. 3. majoritatea modelelor structurale si comportamentale pentru un sistem informatic complex pot fi evidentiate doar ca urmare a operarii sistemului in mediul extern 4. comportarea unui sistem informatic complex este probabilistica si nu poate fi predictibila in totalitate sau cunoscuta inainte de implementarea sa. Cu cat sistemul este mai complex cu atat gradul de incertitudine este mai mare.

1. 2. 3. 4. Dintre avantajele integrarii sistemelor informatice se pot mentiona: a. Scalabilitate b. Administrare centralizata c. Calitate tehnologica a partenerilor d. Training e. Grupuri de utilizatori f. Referinte 5. desfasurarea de programe de instruire pentru grupurile de utilizatori 6. organizarea unei baze de utilizatori, partajarea experientelor a celor mai bune practici si popularizarea cazurilor reusite si a esecurilor 7. interfetele sunt administrate automat de la un punct central 8. detinerea unei platforme informatice integrate reprezinta cea mai buna recomandare in lumea afacerilor electronice (e-business) 9. inlocuirea tuturor interfetelor cu una singura care asigura toate punctele de acces la sistemul informational, administrarea lor facila si posibilitatea adaugarii de alte instrumente sau aplicatii informatice 10. proiectele de anvergura obliga companiile sa dezvolte relatii de afaceri numai cu parteneri care detin deja sisteme integrate 5. - 6. - 7. - 8. - 9.- 10. Dintre avantajele integrarii sistemelor informatice se pot mentiona: a. Performanta b. Usurinta in desfasurare c. Precizie in procesari/zero greseli d. Eterogenitatea surselor e. Securitatea f. Suport nelimitat 11. procesul de transformare a datelor in informatii presupune posibilitatea de a combina date din surse eterogene 12. aplicatiile informatice integrate prevad standarde ridicate de securitate 13. pachetul de aplicatii informatice integrate ofera siguranta deplina a datelor 14. abilitatea de a livra datele la tinta, imediat dupa citirea sursei 15. 24 de ore din 24, 7 zile din 7, suport telefonic si web cu acces rapid la baza de cunostinte a intreprinderii pentru rezolvarea rapida a problemelor 16. abilitatea de a schimba anumiti parametri (numele sursei, numele tintei) 11. - 12. - 13. - 14. - 15. - 16. n esenta sa, limbajul standard pentru integrarea proceselor de afaceri prin servicii Web - BPEL4WS- este o secventa de activitati care se succed in ordinea: a. Activitatea 1 b. Activitatea 2

c. Activitatea 3 d. Activitatea 4 e. Activitatea 5 f. Activitatea 6 g. Activitatea 7 17. asteapta o anumita perioada de timp 18. atunci serviciul se incheie 19. apelantul asteapta ca mesajul sa opereze pe interfata serviciului pentru a fi apelat de un serviciu extern 20. indica faptul ca a aparut o eroare 21. sau nu se intampla nimic 22. apeleaza serviciul Web 23. acesta genereaza un raspuns la o operatie de intrare-iesire 17. - 18. - 19. - 20. - 21. - 22. - 23. Un document WSDL (limbajul pentru descrierea serviciilor Web) este descris de un numar de elemente: a. Definitii tip b. Definitii de mesaje c. Definitii ale operatiilor d. Definitii PortType e. Definitii de conectare f. Definitii de servicii 24. care reprezinta descrieri abstracte ale actiunilor care pot fi suportate de serviciu si care definesc care sunt mesajele de intrare sau de iesire 25. care descrie conexiunea intre PortType si protocoale (SOAP, HTTP, GET/POST) 26. colectie de puncte finale de comunicatie care pot face transfer de informatie 27. pentru elementele de date (in mod normal utilizand XML Schema) 28. cuprinde setul acceptat de operatii; fiecare operatie include mesajele de intrare si de iesire ale operatiei 29. care comprima unul sau mai multe elemente de date 24. - 25. - 26. - 27. - 28. - 29. Cele sapte directii mari ale integrarii sistemelor informatice destinate proceselor de afaceri sunt: a. Integrarea hardware b. Integrarea software c. Integrarea datelor si a depozitelor de date d. Integrarea retelelor de comunicatii e. Descrierea si integrarea noilor procese de afaceri f. ncorporarea cunostintelor in noile procese de afaceri g. Integrarea performantelor umane in procesele electronice de afaceri 30. integrarea semantica 31. integrarea cu noi performante tehnologice 32. interconectivitatea, interoperabilitatea si integrarea semantica 33. incorporarea cunostintelor in noile tehnologii informationale 34. interconectivitatea

35. integrarea resurselor umane 36. interoperabilitatea 30. - 31. - 32. - 33. - 34. - 35. - 36. Modelul de maturitate al standardelor (Standard Maturity Model) cuprinde urmatoarele niveluri: a. Nivelul 0 b. Nivelul 1 c. Nivelul 2 d. Nivelul 3 e. Nivelul 4 f. Nivelul 5 37. Multi recunosc problema 38. Este aprobata versiunea standardului adecvata functional 39. Multe aplicatii folosesc versiuni adcvate functional 40. Putini realizeaza ca este o problema 41. Adecvat din punct de vedere functional 42. Este propusa versiunea 1.0 a standardului 37. - - 38. - 39. - 40. - 41. - 42. Exista patru factori cheie care pot fi utilizati pentru a se realiza ghidarea in alegerea unei solutii de integrare: a. Cuplarea aplicatiilor b. Starea conexiunii c. Relatia de incredere dintre doua aplicatii d. Gradul de vizibilitate al schimbarii 43. care defineste cerinta de conectivitate dintre aplicatii 44. care defineste cantitatea de schimbare vizibila si tolerata de organizatia care metine sistemul integrat 45. care defineste apropierea intre instante ale aplicatiei 46. care determina granularitatea si complexitatea permise de solutia de integrare 43. - 44. - 45. - 46. -