Integrarea aplicațiilor pentru întreprinderi - Enterprise application integration

Integrarea aplicațiilor pentru întreprinderi ( EAI ) este utilizarea software-ului și a principiilor arhitecturale ale sistemelor informatice pentru a integra un set de aplicații informatice pentru întreprindere .

Prezentare generală

Integrarea aplicațiilor pentru întreprinderi este un cadru de integrare compus dintr-o colecție de tehnologii și servicii care formează un middleware sau „cadru middleware” pentru a permite integrarea sistemelor și aplicațiilor într-o întreprindere.

Multe tipuri de software de afaceri, cum ar fi aplicații de gestionare a lanțului de aprovizionare , sisteme ERP , aplicații CRM pentru gestionarea clienților, aplicații de business intelligence , salarizare și sisteme de resurse umane de obicei nu pot comunica între ele pentru a partaja date sau reguli de afaceri. Din acest motiv, astfel de aplicații sunt uneori denumite insule de automatizare sau silozuri de informații . Această lipsă de comunicare duce la ineficiențe, în care datele identice sunt stocate în locații multiple sau procesele directe nu pot fi automatizate.

Integrarea aplicațiilor pentru întreprinderi este procesul de legare a unor astfel de aplicații într-o singură organizație, pentru a simplifica și automatiza procesele de afaceri în cea mai mare măsură posibilă, evitând în același timp să facă schimbări ample la aplicațiile existente sau la structurile de date. Aplicațiile pot fi conectate fie la back-end prin API - uri, fie (rar) la front-end ( GUI ).

În cuvintele firmei de cercetare Gartner : „[EAI este] partajarea nelimitată a datelor și a proceselor de afaceri între orice aplicație conectată sau surse de date din întreprindere.”

Diferitele sisteme care trebuie legate între ele pot locui pe sisteme de operare diferite , pot utiliza diferite soluții de baze de date sau limbaje pentru computer sau diferite formate de dată și oră sau ar putea fi sisteme vechi care nu mai sunt acceptate de furnizorul care le-a creat inițial. În unele cazuri, astfel de sisteme sunt denumite „ sisteme de țevi ”, deoarece constau din componente care au fost blocate împreună într-un mod care face foarte dificilă modificarea lor în vreun fel.

Îmbunătățirea conectivității

Dacă integrarea se aplică fără a urma o abordare EAI structurată, conexiunile punct-la-punct cresc într-o organizație. Dependențele sunt adăugate în mod improvizat, rezultând o structură complexă, care este dificil de întreținut. Acest lucru este denumit în mod obișnuit spaghetti, o aluzie la echivalentul de programare al codului spaghetti . De exemplu:

Numărul de conexiuni necesare pentru a avea conexiuni complet punct-la-punct, cu $n$ puncte, este dat de (a se vedea coeficientul binomial ). Astfel, pentru ca zece aplicații să fie complet integrate punct-la-punct, sunt necesare conexiuni punct-la-punct. ${\ displaystyle {\ tbinom {n} {2}} = {\ tfrac {n (n-1)} {2}}}$ ${\ displaystyle {\ tfrac {10 \ times 9} {2}} = 45}$

Cu toate acestea, numărul de conexiuni în cadrul organizațiilor nu crește în funcție de pătratul numărului de puncte. În general, numărul de conexiuni la orice punct este independent de numărul de alte puncte dintr-o organizație ( Experiment de gândire : dacă se adaugă un punct suplimentar organizației dvs., îl cunoașteți? Crește numărul de conexiuni altele fără legătură? punctele au?). Există un număr mic de puncte de „colectare” pentru care acest lucru nu se aplică, dar acestea nu necesită modele EAI pentru gestionare.

EAI poate crește, de asemenea, cuplarea între sisteme și, prin urmare, crește costurile și costurile de gestionare.

EAI nu se referă doar la partajarea datelor între aplicații, ci se axează și pe partajarea atât a datelor de afaceri, cât și a proceselor de afaceri. Un analist middleware care participă la EAI se va uita deseori la sistemul de sisteme .

Scopuri

EAI poate fi utilizat în diferite scopuri:

Integrarea datelor : asigură faptul că informațiile din mai multe sisteme sunt menținute consecvente. Aceasta este, de asemenea, cunoscută sub numele de integrarea informațiilor întreprinderii (EII).
Independența furnizorului: extrage politicile sau regulile comerciale din aplicații și le implementează în sistemul EAI, astfel încât, chiar dacă una dintre aplicațiile comerciale este înlocuită cu o aplicație diferită a furnizorului, regulile comerciale nu trebuie să fie reimplementate.
Fațadă comună: un sistem EAI poate face front-end la un grup de aplicații, oferind o singură interfață de acces consistentă la aceste aplicații și protejând utilizatorii de a învăța să folosească diferite pachete software.

Modele

Această secțiune descrie modele comune de proiectare pentru implementarea EAI, inclusiv modele de integrare, acces și durata de viață. Acestea sunt modele abstracte și pot fi implementate în multe moduri diferite. Există multe alte modele utilizate în mod obișnuit în industrie, variind de la modele de proiectare abstractă la nivel înalt la modele de implementare foarte specifice.

Modele de integrare

Sistemele EAI implementează două modele:

Mediere (intracomunicație): Aici, sistemul EAI acționează ca intermediar sau intermediar între mai multe aplicații. Ori de câte ori apare un eveniment interesant într-o aplicație (de exemplu, se creează informații noi sau se finalizează o nouă tranzacție) este notificat un modul de integrare în sistemul EAI. Modulul propagă apoi modificările către alte aplicații relevante.
Federație (inter-comunicare): În acest caz, sistemul EAI acționează ca fațada generală a mai multor aplicații. Toate apelurile de evenimente din „lumea exterioară” către oricare dintre aplicații sunt front-end de sistemul EAI. Sistemul EAI este configurat să expună doar informațiile relevante și interfețele aplicațiilor subiacente către lumea exterioară și efectuează toate interacțiunile cu aplicațiile subiacente în numele solicitantului.

Ambele tipare sunt adesea utilizate simultan. Același sistem EAI ar putea menține mai multe aplicații sincronizate (mediere), în timp ce deservesc cererile utilizatorilor externi împotriva acestor aplicații (federație).

Modele de acces

EAI acceptă atât modele de acces asincron (foc și uitare), cât și sincron, primul fiind tipic în cazul medierii și cel din urmă în cazul federației.

Modele de viață

O operațiune de integrare ar putea fi de scurtă durată (de exemplu, păstrarea sincronizată a datelor în două aplicații ar putea fi finalizată într-o secundă) sau de lungă durată (de exemplu, unul dintre pași ar putea implica interacțiunea sistemului EAI cu o aplicație de flux de lucru uman pentru aprobare a unui împrumut care durează ore sau zile pentru finalizare).

Topologii

Există două topologii majore: hub și spiță și autobuz . Fiecare are propriile sale avantaje și dezavantaje. În modelul cu hub și spițe, sistemul EAI se află în centru (hub) și interacționează cu aplicațiile prin spițe. În modelul de magistrală, sistemul EAI este magistrala (sau este implementat ca modul rezident într-o magistrală de mesaje deja existentă sau middleware orientat către mesaje ).

Majoritatea întreprinderilor mari folosesc rețeaua zonată pentru a crea o apărare stratificată împotriva amenințărilor orientate spre rețea. De exemplu, o întreprindere are în mod obișnuit o zonă de procesare a cardului de credit (conformă cu PCI), o zonă non-PCI, o zonă de date, o zonă DMZ pentru accesul proxy al utilizatorului extern și o zonă IWZ către accesul proxy al utilizatorului intern. Aplicațiile trebuie să se integreze în mai multe zone. Modelul Hub și vorbitor ar funcționa mai bine în acest caz.

Tehnologii

În implementarea fiecărei componente ale sistemului EAI sunt utilizate mai multe tehnologii:

Autobuz / hub: Acest lucru este de obicei implementat prin îmbunătățirea produselor middleware standard ( server de aplicații , magistrală de mesaje) sau implementat ca program autonom (de exemplu, nu folosește niciun middleware), acționând ca propriul middleware.
Conectivitatea aplicației: Busul / hub-ul se conectează la aplicații printr-un set de adaptoare (denumite și conectori ). Acestea sunt programe care știu cum să interacționeze cu o aplicație de afaceri subiacentă. Adaptorul realizează comunicare unidirecțională (unidirecțională), efectuând cereri de la hub împotriva aplicației și notificând hub-ul atunci când are loc un eveniment de interes în aplicație (o nouă înregistrare introdusă, o tranzacție finalizată etc.). Adaptoarele pot fi specifice unei aplicații (de exemplu, construite pe baza bibliotecilor client ale furnizorului de aplicații) sau specifice unei clase de aplicații (de exemplu, pot interacționa cu orice aplicație printr-un protocol de comunicație standard, cum ar fi SOAP , SMTP sau Action Message Format (AMF) )). Adaptorul ar putea locui în același spațiu de proces ca magistrala / hub-ul sau se poate executa într-o locație la distanță și poate interacționa cu hub-ul / magistrala prin protocoale standard din industrie, cum ar fi cozile de mesaje, serviciile web sau chiar să utilizeze un protocol proprietar. În lumea Java, standarde precum JCA permit crearea de adaptoare într-un mod neutru pentru furnizori.
Formatarea și transformarea datelor: Pentru a evita ca fiecare adaptor să convertească date în / din orice alte formate de aplicații, sistemele EAI stipulează de obicei un format de date independent de aplicație (sau comun). Sistemul EAI oferă, de obicei, și un serviciu de transformare a datelor pentru a ajuta la conversia între formatele specifice aplicației și formatele comune. Acest lucru se face în doi pași: adaptorul convertește informațiile din formatul aplicației în formatul comun al autobuzului. Apoi, se aplică transformări semantice pe aceasta (convertirea codurilor poștale în nume de orașe, împărțirea / îmbinarea obiectelor dintr-o aplicație în obiecte din celelalte aplicații și așa mai departe).
Module de integrare: Un sistem EAI ar putea participa la mai multe operațiuni de integrare simultane la un moment dat, fiecare tip de integrare fiind procesat de un modul de integrare diferit. Modulele de integrare se abonează la evenimente de tipuri specifice și notificări de proces pe care le primesc atunci când apar aceste evenimente. Aceste module ar putea fi implementate în diferite moduri: pe sistemele EAI bazate pe Java , acestea ar putea fi aplicații web sau EJB-uri sau chiar POJO-uri care sunt conforme cu specificațiile sistemului EAI.
Suport pentru tranzacții: Atunci când este utilizat pentru integrarea proceselor, sistemul EAI oferă, de asemenea, consistență tranzacțională între aplicații, executând toate operațiunile de integrare în toate aplicațiile într-o singură tranzacție distribuită globală (folosind protocoale de comitere în două faze sau compensând tranzacțiile ).

Arhitecturi de comunicare

În prezent, există multe variante de gândire cu privire la ceea ce constituie cea mai bună infrastructură, modelul componentelor și structura standardelor pentru integrarea aplicațiilor pentru întreprinderi. Se pare că există consens că patru componente sunt esențiale pentru o arhitectură modernă de integrare a aplicațiilor de întreprindere:

Un broker centralizat care se ocupă de securitate, acces și comunicare. Acest lucru poate fi realizat prin intermediul serverelor de integrare (cum ar fi Serviciile de integrare a zonei School Interoperability Framework (SIF) Zone) sau prin software similar, cum ar fi modelul Enterprise Service Bus (ESB) care acționează ca un manager de servicii.
Un model de date independent bazat pe o structură de date standard, cunoscut și sub numele de model de date canonice . Se pare că XML și utilizarea foilor de stil XML au devenit de facto și, în unele cazuri, de drept standard pentru acest limbaj de afaceri uniform.
Un conector sau model de agent în care fiecare furnizor, aplicație sau interfață poate construi o singură componentă care poate vorbi nativ acelei aplicații și comunica cu brokerul centralizat.
Un model de sistem care definește API-urile, fluxul de date și regulile de implicare în sistem, astfel încât componentele să poată fi construite pentru a interfața cu acesta într-un mod standardizat.

Deși au fost explorate alte abordări, cum ar fi conectarea la baza de date sau la nivelul interfeței cu utilizatorul, acestea nu au fost găsite la scară sau nu pot fi ajustate. Aplicațiile individuale pot publica mesaje către brokerul centralizat și se pot abona pentru a primi anumite mesaje de la acel broker. Fiecare aplicație necesită o singură conexiune la broker. Această abordare de control central poate fi extrem de scalabilă și extrem de evoluabilă .

Integrarea aplicațiilor pentru întreprinderi este legată de tehnologiile middleware, cum ar fi middleware orientat către mesaje ( MOM ), și de tehnologiile de reprezentare a datelor, cum ar fi XML sau JSON . Alte tehnologii EAI implică utilizarea serviciilor web ca parte a arhitecturii orientate spre servicii ca mijloc de integrare. Integrarea aplicațiilor pentru întreprinderi tinde să fie centrată pe date. În viitorul apropiat, va include integrarea conținutului și procesele de afaceri .

Capcanele implementării

În 2003 s-a raportat că 70% din toate proiectele EAI eșuează. Majoritatea acestor defecțiuni nu se datorează software-ului în sine sau dificultăților tehnice, ci din cauza problemelor de gestionare. Președintele european al Consorțiului de integrare, Steve Craggs, a prezentat cele șapte capcane principale întreprinse de companiile care utilizează sisteme EAI și a explicat soluțiile la aceste probleme.

Schimbare constantă: însăși natura EAI este dinamică și necesită manageri dinamici de proiect pentru a gestiona implementarea lor.
Lipsa de experți EAI : EAI necesită cunoașterea multor aspecte și aspecte tehnice.
Standarde concurente: în domeniul EAI, paradoxul este că standardele EAI în sine nu sunt universale.
EAI este o paradigmă a instrumentelor: EAI nu este un instrument, ci mai degrabă un sistem și ar trebui implementat ca atare.
Construirea de interfețe este o artă: soluția tehnică nu este suficientă. Soluțiile trebuie negociate cu departamentele utilizatorilor pentru a ajunge la un consens comun cu privire la rezultatul final. Lipsa consensului în ceea ce privește proiectarea interfeței duce la eforturi excesive de mapare între cerințele de date ale diferitelor sisteme.
Pierderea detaliilor: informațiile care păreau neimportante într-o etapă anterioară pot deveni cruciale ulterior.
Responsabilitate: Deoarece atât de multe departamente au multe cerințe contradictorii, ar trebui să existe o responsabilitate clară pentru structura finală a sistemului.

Pot apărea alte probleme potențiale în aceste domenii:

Lipsa unei coordonări centralizate a activității EAI.
Cerințe emergente: implementările EAI ar trebui să fie extensibile și modulare pentru a permite schimbări viitoare.
Protecționism: aplicațiile ale căror date sunt integrate adesea aparțin diferitelor departamente care au motive tehnice, culturale și politice pentru a nu dori să partajeze datele lor cu alte departamente

Languages

In other projects