ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 51
Abonament PDF

Pontențialul unui Enterprise Service Bus

Vlad Vesa
Software Engineer @ TSS Yonder



PROGRAMARE


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.

Problema de care vă puteți lovi

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.

Motive financiare

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.

Un nou model de business

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.

Elemente ce necesită rezolvare tehnică

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>

Compatibilitate cu versiunile anterioare (Backwards compatibility)

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.

Partea distractivă

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

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects