Când sunteți fericitul posesor al unei aplicații de 30 de ani, volumul de date este enorm. Baza de date este compusă din sute de tabele cu date statice sau dinamice. Unele tabele pot să înregistreze mii de intrări lunar. Să spunem că lucrăm cu o aplicație distribuită cu un container clasic al unei aplicații web.
Evident, încercați să țineți pasul cu noile tehnologii și faceți migrarea spre framework-uri noi iar și iar cu același scop în minte: "...data viitoare vor fi mai ușor de implementat a, b, c..". Apoi ajungi la un punct în care aplicația voastră este compusă din module inteligente pentru care chiar și Robert C. Martin v-ar da de băut, pentru o implementare SRP.
În cadrul colaborării business to business, poți să îți extinzi modelul de business extrăgând date din sistemul tău într-un mod inteligent. Voi prezenta cum se poate realiza acest lucru.
Când componentele trebuie să colaboreze, se ajunge la dezbaterea dacă ar trebui să folosiți un Service Bus sau nu. Acest articol oferă explicații despre EAI, ESB și puțin SOA. Sunt câteva articole foarte bune care scot în evidență faptul că ESB trebuie tratat cu grijă.
Dacă sunteți owner-ul modulelor care trebuie să colaboreze aveți deja tot ce vă trebuie. Componentele ascultă de voi cei care stabiliți modelul de colaborare. În acest punct, ESB ar putea aduce muncă suplimentară dacă nu este aplicat corespunzător.
Să zicem că ați atins un punct critic în care deserviți multe businessuri și mulți clienți, dintre care unii doresc funcționalități adaptate ce nu pot fi vândute altor clienți. Vă faceți socotelile și constatați că este improbabil să dezvoltați așa ceva.
Acum aveți o problemă. Dacă nu vă mișcați suficient de repede, clientul va alege între a construi software-ul de unul singur sau a apela la competiție.
Exemplu: Când vreți să exportați date financiare din sistemul vostru către alte destinații externe, trebuie să acordați atenție la ce date transmiteți și în ce format. Nu aveți expertiză financiară, deci s-ar putea să aveți nevoie de ajutor. De asemenea, nu veți dezvolta module financiare voi înșivă.
Cum veți aborda problema? Clientul are nevoie de cantități mici din datele voastre într-o funcționalitate nouă, iar pe aceasta o puteți construi singuri.
Infrastructura simplificată arată asemănător acestei imagini. Acest model se poate multiplica la nivelul zecilor sau al sutelor. Pentru a simplifica lucrurile, am păstrat aici doar trei stații a trei clienți diferiți. Am putea avea scheme multiplicate de sute sau mii de ori.
Vom vorbi de situația în care soluția ESB deschide noi posibilități din perspectiva businessului.
Există două opțiuni:
A. Permiteți-i să ceară informații sistemului vostru când dorește sau când poate.
B. Trimiteți-i evenimente când se întâmplă ceva cu lucrul pe care dorește să-l controleze.
În ambele situații, puteți defini un acord la nivel de serviciu (SLA și puteți crea un plan de plăți bazat pe uzul efectiv.
Dacă doriți să aplicați aceeași strategie, trebuie dat răspuns la o serie de întrebări.
Cum se trimit evenimentele de la Station A1 … An la sediul Clientului A?
Creați un nivel Service Bus între servere și clienți. Astfel, acest ESB facilitează colaborarea dintre serverele și clienții voștri, nu între componentele arhitecturii. Nu este nimic rău în a face componentele să colaboreze printr-un BUS asemănător, dar acesta este un subiect de discuție diferit. Puteți stabili multe instanțe ESB (cu/fără load balancere) pentru a evita problema single point of failure.
Cum îi permitem Clientului A să ceară informații de la servere specifice?
Fiecare request poate fi parsat și dat mai departe unor ținte specifice. Logica din spatele acestui lucru poate fi plasată direct în ESB cu XQueries. Parsați request-ul, decideți spre care terminal să meargă, dați-l mai departe și așteptați răspunsul. Aceasta e o privire de ansamblu a capacităților de routing ale unui ESB. Strategiile de routing pot fi combinate cu extrageri de la terminalele bazelor de date bazate pe conținutul din header-ul request-ului. Fiecare server trebuie să aibă un canal de comunicare cu ESB.
Cum dezvoltați servicii specifice doar pentru un singur client dar cu capacitatea de a fi extensibile în cazul în care echipa de vânzări mai vinde ceva?
Haideți să separăm cele două probleme: serviciul intern și definiția internă; serviciul extern și definiția externă. Utilizați capacitate ESB 'de a transforma'. Pentru a face 'extensia' propriu-zisă sau pentru 'a reutiliza' serviciul, s-ar putea să fie nevoie să faceți mici retușuri în instanța ESB și să adăugați noi terminale și routing-uri. Reutilizarea, în acest context, înseamnă că veți putea crea noi definiții și servicii externe în timp ce acelea interne rămân neschimbate.
Cum dezvoltați servicii specifice pentru clienți multipli?
Există mai multe opțiuni. Ați putea opta pentru varianta de la răspunsul anterior. Dacă aveți nevoie de ceva specific, dați numele potrivit serviciului și tratați-l ca pe un serviciu standard. De exemplu FinanceForClientXService_V1.
Cum poți face serviciul independent de schimbările mesajelor trimise/primite din partea clientului?
Aici vă ajută transformările. Un ESB poate opera transformări asupra mesajelor, de la definiții interne până la definiții externe. Acest lucru se întâmplă în anumite limbaje, precum XQuery, dar puteți opta pentru a trimite mesajul 'modificat' direct prin ESB.
Cum faceți față abonamentelor pentru servicii comune pentru clienți multipli?
Ați putea construi un business întreg din datele extrase din vechile date. Calea cea mai ușoară ar fi să creați o bază de date pe bază de abonament (nume client, serviciu, perioadă de expirare, etc.) și să 'consultați' baza de date la fiecare request.
Cum abordați problema versiunilor multiple ale unui serviciu? Clientul A s-ar putea să dorească mai mult de la serviciul vostru în timp ce Clientul B nu dorește să mai plătească nimic adițional.
În aceste situații aveți nevoie de versionare inteligentă. ServiceX_v1, ServiceX_v2 ar putea fi același serviciu din perspectivă funcțională, având doar unul sau mai multe câmpuri diferență în livrarea mesajelor. Din perspectiva ESB, acestea pot fi tratate drept servicii diferite. Totuși, este posibil să se definească un serviciu proxy intern și unul extern pentru același serviciu. Serviciul Proxy extern se comportă ca și cum știe doar 'definiția externă' în timp ce Proxy-ul intern știe doar 'definiția internă'.
Nu sunt acestea similare cu ceea ce propune SOA?
În SOA pur, serviciile au "surse de date" destinate lor. Aceasta nu este o regulă. Este dificil să migrezi sistemele spre arhitecturi pure SOA. SOA se poate folosi de un service bus, dar mutăm punctul de intersecție între servicii, de la move app server la ESB.
Cum se conectează un client la ESB? Cum se conectează serverul aplicației la ESB?
De exemplu, se poate conecta prin HTTP. Totul este o colaborare între servicii web - Application server -> ESB -> Client. Toate părțile trebuie să aibă terminalele serviciilor disponibile. Acest fapt determină o configurare statică a terminalelor. Terminalele nu se schimbă atât de mult, deci nu va fi foarte greu să se mențină acele terminale. Toate părțile vor trebui să își configureze modul de definire a mesajelor cu nume și tipuri, independent. Mai există și problema securității, dar nu voi intra în detalii deoarece nu sunt specifice ESB. Folosim protocolul HTTP, deci ssl, https și certificatele sunt răspunsul. Acestea se configurează ușor în soluțiile ESB.
Transformări ESB
Partea frumoasă a ESB este că puteți adăuga transformări. Nu contează ce nume dau clienții unui câmp dintr-un mesaj. Poate fi orice, chiar și un tip diferit. Totuși, trebuie să știți exact cum arată interfața. Interfețele client și interfețele voastre trebuie să fie cunoscute de ESB.
Interfața voastră va fi similară cu:
<envelope>
<someObject>
<objectName>some value
</objectName>
<someObject>
</envelope>Pentru Clientul A va fi transformat în:
<envelope>
<someObject>
<myObjectName>some value
</myObjectName>
<someObject>
</envelope>Similar, pentru Clientul B va fi:
<envelope>
<someObject>
<nameOfObject>some value
</nameOfObject >
<someObject>
</envelope>Problema compatibilității cu versiunile anterioare sau versiunile multiple ale aceluiași serviciu se poate soluționa tratând fiecare serviciu ca un nou serviciu, ca de exemplu ServiceForFinance_V1 și ServiceForFinance_V2 și așa mai departe. Fiecare are un mod propriu de definire a mesajelor. Fiecare client poate utiliza ambele versiuni. În același timp, nu trebuie dat build la V2 pentru a face tot ce face V1 + alte elemente adiționale. Pot avea funcționalități cu totul diferite.
Să vorbim acum de partea distractivă. Am prezentat două posibilități: a lăsa clientul să ceară informația și a informa clientul când ceva s-a schimbat.
În ceea ce privește partea a doua, când le prezinți clienților schimbările, începe adevărata distracție. Nu te poți baza niciodată pe aparatura, infrastructura clienților, dar nici pe capacitatea lor de a-ți răspunde la mesaje, de a le stoca și de a le procesa, dacă un client are multe stații pe teren. Clienții au viteze de procesare diferite.
Aveți nevoie de o metodă de a configura notificările de evenimente în funcție de capabilitatea clientului.
Să zicem că Clientul A poate primi 100 mesaje pe secundă, în timp ce Clientul B poate primi doar 50, iar Clientul C doar 2.
În acest punct, soluția ESB pe care o alegeți devine foarte importantă. Trebuie să puneți mesajele într-o coadă de așteptare și să le prioritizați (throttle).
Majoritatea ESB engines au această capacitate. Am văzut throttler-uri interne care funcționează foarte bine.
Distracția continuă. Adăugați logging serviciilor voastre și veți putea crea dashboard-uri cu soluții precum Splunk (log farm indexer) pentru a putea vedea cine folosește ce și când. Vă puteți permite acele tool-uri, iar unele necesită mai mult development decât altele. Interesante sunt lucrurile mari pe care le puteți construi cu ele. Trebuie să aveți cunoștințe tehnice foarte bune pentru a le folosi deoarece nimic nu se întâmplă prin magie.
Există multe alte feature-uri ale ESB care vor fi discutate într-un articol viitor.
Cum ați rezolva această problemă?
Trimiteți-mi impresiile voastre la vlad dot vesa at tss-yonder.com