„Sonic ESB“: programuojama integracija

Spaudimas integruoti skirtingas sistemas įmonėje nuolat auga, tačiau užmegzti ryšius tarp sistemų, net ir tų, kurios skirtos integracijai, išlieka bauginanti užduotis.

Tradiciškai įmonės sujungė sistemas naudodamos taško-taško nuorodas ir pasirinktinį kodą. Visai neseniai integracijos brokeriai - patentuota programinė įranga, skirta sukurti ryšius tarp kelių sistemų - pasirodė kaip dar vienas sprendimas. Tačiau ryšys tarp taško į tašką yra brangus, o integracijos brokeriai buvo brangūs.

„Sonic ESB“ yra vienas iš naujų produktų rinkinių, už kuriuos atsiskaitoma kaip įmonės paslaugų magistralės (ESB), lengvi integracijos tarpininkai, paremti tokiais standartais kaip XML ir SOAP, skirti dirbti paskirstytoje aplinkoje.

ESB bus labai naudinga įmonėms, norinčioms palaipsniui integruoti įmonių taikomąsias programas. Naudojant magistralės modelį, pirmiausia galima integruoti kelias didžiausio atsipirkimo programas; kitas programas galima suskirstyti vėliau, kai atsiras pinigų ir išteklių. Kadangi patekimo į rinką barjerai yra maži, šie integracijos projektai gali būti pradėti nedideli, būti atidžiai valdomi ir augti, kad atitiktų ateities poreikius.

„Sonic ESB 5.0“ stengiasi pasiūlyti šiuos privalumus, derindamas pranešimų siuntimą, maršruto parinkimą, žiniatinklio paslaugas ir pranešimų transformavimą, kad integruotų ir organizuotų kelių interneto programų galinių taškų veiksmus.

„Eyeing Sonic“ ESB architektūra

Tipiškas integracijos brokeris turi centrinę ir stipinų architektūrą. Kita vertus, „Sonic ESB“ yra sukurtas ant „Sonic Software“ į pranešimą orientuoto tarpinės programinės įrangos produkto „SonicMQ“, JMS („Java Message Service“), teikiančio J2EE programų serverius. „SonicMQ“ teikia „Sonic ESB“ konfigūraciją ir vykdymo laiko valdymą, pranešimų tarpininkus ir valdomus konteinerius. Sąveika tarp „SonicMQ“ ir ESB yra tokia detali ir išsami, kad nenuostabu, kad „Sonic Software“ juos vadina rinkiniu.

Kadangi „Sonic ESB“ yra sukurta ant pranešimų infrastruktūros, jos magistralės architektūrą galima paskirstyti visame įmonės LAN ar visame pasaulyje. Dėl patikimumo pranešimų mazgai gali būti įdiegti į kelių mašinų grupes, o šie klasteriai gali susivienyti su grupėmis kitose vietose ir suteikti nuotolinius integracijos taškus.

Be to, domeno tvarkyklė yra integruota į sistemą ir tarnauja kaip tinkle diegiamų paslaugų katalogas.

Konteineriai valdo galutinius taškus, kurie valdo paslaugų, teikiančių maršrutus, procesų srautų organizavimą, duomenų transformavimą ir saugumą, gyvavimo ciklą. Šie konteineriai taip pat pritaiko taškus senoms sistemoms. Pvz., J2EE adapteris yra prieinamas J2EE pagrįstoms sistemoms prie magistralės. Paslaugų konteineriai paprastai talpinami atskirai nuo pranešimų serverių, kiekvienas jų yra kartu su sena sistema, kuriai ji teikia.

Pranešimai nukreipia patys naudodami pridėtą kelionės programą, sukurtą per valdymo pultą. Turinio nukreipimas atliekamas galutinio taško tarnybose naudojant XPath, kad būtų galima peržiūrėti pridėtus XML dokumentus, ir sąlygiškai nukreipti pagal dokumento turinį. Transformavimo tarnyba naudoja XSLT („eXtensible Style Language Transformation“). „Sonic Software“ „Stylus“ produktas grafiškai sukuria XSLT dokumentus, kurie transformuojasi iš vienos XML schemos į kitą, tačiau veiks ir bet kuris kitas XSLT įrankis.

Ieško integracijos architekto

Kai mokiausi antroje klasėje, mano klasės vaikas atnešė elektronikos žaislą, kuris leido jums sukurti radiją ir kitus paprastus elektroninius prietaisus, vadovaujantis pateiktomis schemomis ir spustelėjus blokus kartu. Peržiūrėdamas „Sonic ESB“, negalėjau nepagalvoti apie sujungiamas programas, nes manipuliuodavau jos konfigūracija per GUI pagrįstą valdymo pultą.

Nors daugybė veiksmų, kuriuos darote, kai nustatote „Sonic ESB“, yra tik manipuliavimas konfigūracijos failais, galutinis rezultatas yra procesas, kuriuo manipuliuojama duomenimis. Tai daugiau nei paprasčiausia politika pagrįsta konfigūracija - tai programavimas.

„Sonic ESB“ programavimas atliekamas ne su vieningu žymėjimu, o rašant „Java“ ir „JavaScript“ fragmentus kartu su XSLT, XML schemomis ir WSDL failais. Keli skirtingi grafiniai įrankiai sutvarko visa tai į bendrą konfigūraciją, kuri sukuria teisingą maršruto parinkimą ir aptarnavimą norimam rezultatui pasiekti.

„Sonic Software“ pateikia išsamų tiekimo grandinės pavyzdį „Darbo pradžios“ vadove. Peržiūrėdami šį pavyzdį galėsite greičiau sužinoti pagrindinius ESB sąveikos būdus ir supažindinti su sąvokomis ir valdymo įrankiais, reikalingais konfigūruoti ir naudoti magistralę.

Vykstant konfigūracijos procesui, mane nustebino, kaip sunku buvo sekti visas skirtingas dalis, ką jos padarė ir kaip jos dera. „Sonic ESB“ valdymo pultai yra tokie pat geri, kaip aš mačiau. Bet jie nėra programavimo aplinka - jie siūlo tik elementarų palaikymą abstrakcijai. Pavyzdžiui, proceso eiga leidžia įvardyti ir įterpti, tačiau tokie pat svarbūs dalykai kaip sąlyginis srautas yra paslėpti „JavaScript“ failuose ir XSLT.

Keli procesai ir duomenys apibūdinantys formatai - „Java“, „JavaScript“, XSL, XML schema ir kt. - yra papildoma našta. Taigi, nors „Sonic ESB“ naudojimas yra programavimo veiksmas, tai yra produktas, sukurtas aplink technologijų grupę, o ne vienas gerai suplanuotas žymėjimas.

Tai nebūtinai yra „Sonic Software“ kaltė. Jie dirba su įrankiais, kurių jiems reikia pagal jų klientų reikalaujamas technologijas ir standartus. Abejoju, ar „Sonic Software“ sugebėtų paskatinti priimti vienodesnį žymėjimą.

Kadangi vienodas žymėjimas nėra prieinamas, pranešimų srautui, klaidų sąlygoms ir duomenų transformacijoms suprasti yra nedaug vaizdinių ženklų. Iš tiesų, be paveikslėlių ir aprašymo, pateikto „Pradžios“ vadove, suprasti pranešimų srautą pateiktame tiekimo grandinės pavyzdyje būtų buvę sunku. Supratau, kad pasisukus iš vidaus, „Pradžios vadovas“ iš tikrųjų buvo sistemos architektūra; vadove esančios nuotraukos ir aprašymai greičiausiai yra tie patys, kuriuos pavyzdžio kūrėjai naudojo kurdami jį.

Norint sėkmingai naudoti produktus, tokius kaip „Sonic ESB“, reikės tokio pat kruopštaus kūrėjų, veikiančių kaip „integracijos architektai“, planavimo. Integracijos architektų turimos priemonės, metodikos ir modeliavimo metodikos vis dar yra elementarios, tačiau „Sonic ESB“ pateikia išsamų priemonių, reikalingų integracijai įgyvendinti, kai tik ji bus suplanuota, rinkinį.

Lankstumas už kainą

„Sonic ESB“ kartu su „SonicMQ“ pateikia standartais pagrįstą metodą, kaip patikimai ir ekonomiškai integruoti tiek senas, tiek naujas programas iš visos įmonės. Sistemų rinkinio integravimas su „Sonic ESB“ turėtų kainuoti pigiau nei naudotis nuosavais integracijos brokeriais.

Peržiūrėję „SonicXQ“, „Sonic ESB“ pirmtaką, mes padarėme išvadą, kad „SonicXQ teikia kūrėjams patikimą saugių ir patikimų BPM (verslo procesų valdymo) paslaugų rinkinį“ (žr. „BPM palaikymas kelyje“, rugsėjo 30 d., 26 psl.).

Tai nepasikeitė. Nors valdymo įrankiai dabar yra žymiai patobulinti, „Sonic ESB 5.0“ dažnai reikia sudėtingos konfigūracijos. Norint, kad jis veiktų, reikia nemažų įgūdžių tokiose technologijose kaip J2EE, į pranešimus orientuota tarpinė programinė įranga, XML, XSLT, XPath, JavaScript ir Java.

Tai yra lankstumo kaina. Kai kuriais įrankiais siekiama palengvinti jų naudojimą ir netgi pasigirti, kad verslo žmonės gali juos naudoti verslo procesams valdyti. Bet nė vienas iš jų nesiūlo lankstumo, būtino visiškam sistemos integravimui. „SonicESB“ siūlo šį lankstumą, tačiau tik tuo atveju, jei turite kūrėjų ir integracijos architektų, kurie juo pasinaudotų.