Programmēšana

Sonic ESB: programmējama integrācija

Spiediens integrēt atšķirīgas sistēmas visā uzņēmumā nepārtraukti pieaug, taču savienojumu izveidošana starp sistēmām, pat tām, kas paredzētas integrācijai, joprojām ir biedējošs uzdevums.

Tradicionāli uzņēmumi savienoja sistēmas, izmantojot saites starp punktu un pielāgotu kodu. Pavisam nesen kā vēl viens risinājums parādījās integrācijas brokeri - patentēta programmatūra savienojumu izveidošanai starp vairākām sistēmām. Tomēr savienojumu no punkta uz punktu uzturēšana ir dārga, un integrācijas brokeru pirkšana ir bijusi dārga.

Sonic ESB ir viens no jauniem produktu komplektiem, par kuriem tiek iekasēti rēķini kā uzņēmuma apkalpošanas autobusi (ESB), vieglas integrācijas brokeri, kuru pamatā ir tādi standarti kā XML un SOAP, kas paredzēti darbam sadalītā vidē.

Uzņēmumiem, kas vēlas pakāpeniski izmantot uzņēmumu lietojumprogrammu integrāciju, ESB būs ārkārtīgi noderīgi. Izmantojot kopnes modeli, vispirms var integrēt dažas lietojumprogrammas ar vislielāko atmaksāšanos; citus līdzekļus var salocīt vēlāk, kad kļūst pieejama nauda un resursi. Tā kā ienākšanas barjeras ir zemas, šie integrācijas projekti var sākties maz, tos var cieši vadīt un augt, lai tie atbilstu nākotnes vajadzībām.

Sonic ESB 5.0 cenšas piedāvāt šīs priekšrocības, apvienojot ziņojumapmaiņu, maršrutēšanu, tīmekļa pakalpojumus un ziņojumu pārveidošanu, lai integrētu un organizētu vairāku interneta lietojumprogrammu galapunktu darbības.

Eyeing Sonic's ESB arhitektūra

Tipiskam integrācijas brokerim ir centrmezgls un spieķu arhitektūra. Savukārt Sonic ESB ir veidots virs Sonic Software uz ziņām orientēta starpprogrammatūras produkta SonicMQ, JMS (Java Message Service) nodrošinātāja J2EE lietojumprogrammu serveriem. SonicMQ nodrošina Sonic ESB konfigurācijas un izpildlaika pārvaldību, ziņojumapmaiņas brokerus un pārvaldītos konteinerus. Mijiedarbība starp SonicMQ un ESB ir tik smalka un pilnīga, ka nav brīnums, ka Sonic Software tos sauc par komplektu.

Tā kā Sonic ESB ir veidota uz ziņojumapmaiņas infrastruktūru, tā kopnes arhitektūru var izplatīt visā uzņēmuma LAN vai globālajā internetā. Lai nodrošinātu uzticamību, ziņojumapmaiņas mezglus var instalēt kopās vairākās mašīnās, un šīs kopas var apvienoties ar kopām citās vietās, lai nodrošinātu attālās integrācijas punktus.

Turklāt domēna pārvaldnieks ir integrēts sistēmā un kalpo kā direktorijs tīklā izvietotajiem pakalpojumiem.

Konteineri pārvalda galapunktus, kas pēc tam pārvalda to pakalpojumu dzīves ciklu, kas nodrošina maršrutēšanu, procesu plūsmas orķestrēšanu, datu pārveidošanu un drošību. Šie konteineri arī pielieto galapunktus mantotajām sistēmām. Piemēram, lai savienotu kopnes ar J2EE balstītas sistēmas, ir pieejams J2EE adapteris. Pakalpojumu konteineri parasti tiek mitināti atsevišķi no ziņojumapmaiņas serveriem, katrs no tiem atrodas vienlaikus ar mantoto sistēmu, kuru tas apkalpo.

Ziņojumi maršrutē paši, izmantojot pievienoto maršrutu, kas izveidots, izmantojot vadības konsoli. Satura maršrutēšana tiek veikta galapunkta pakalpojumos, izmantojot XPath, lai skatītu pievienotos XML dokumentus, un nosacīti maršrutē, pamatojoties uz dokumenta saturu. Transformācijas pakalpojums izmanto XSLT (eXtensible Style Language Transformation). Sonic Software izstrādājums Stylus grafiski izveido XSLT dokumentus, kas pārveidojas no vienas XML shēmas uz citu, taču derēs arī jebkurš cits XSLT rīks.

Meklēju integrācijas arhitektu

Kad es mācījos otrajā klasē, kāds manas klases bērns ienesa elektronikas rotaļlietu, kas ļāva jums izveidot radio un citas vienkāršas elektroniskas ierīces, sekojot līdzi pievienotajām shēmām un kopā noklikšķinot uz blokiem. Pārskatot Sonic ESB, es nevarēju domāt par apvienotajām programmām, kad es manipulēju ar tās konfigurāciju, izmantojot GUI balstītu pārvaldības konsoli.

Lai gan liela daļa no tā, ko jūs darāt, iestatot Sonic ESB, ir tikai manipulācijas ar konfigurācijas failiem, gala rezultāts ir process, kas manipulē ar datiem. Tas ir vairāk nekā vienkārši uz politiku balstīta konfigurācija - tā ir programmēšana.

Programmēšana Sonic ESB netiek veikta ar vienotu apzīmējumu, bet ietver Java un JavaScript fragmentu rakstīšanu kopā ar XSLT, XML shēmām un WSDL failiem. Vairāki dažādi grafiskie rīki visus šos sakārto vispārējā konfigurācijā, kas nodrošina pareizu maršrutēšanu un apkalpošanu vēlamajam rezultātam.

Sonic Software rokasgrāmatā Darba sākšana sniedz visaptverošu piegādes ķēdes piemēru. Izmantojot šo piemēru, jūs varēsit apgūt galvenos ESB mijiedarbības veidus un iepazīstināt ar kopnes konfigurēšanai un lietošanai nepieciešamajiem jēdzieniem un pārvaldības rīkiem.

Kad es izgāju cauri konfigurācijas procesam, mani pārsteidza tas, cik grūti bija izsekot visām dažādajām daļām, to, ko viņi darīja un kā viņi sader kopā. Sonic ESB vadības konsoles ir tik labas, cik esmu redzējis. Bet tās nav programmēšanas vides - tās piedāvā tikai elementāru atbalstu abstrakcijai. Piemēram, procesa plūsma ļauj nosaukt un iegult, bet tikpat svarīgas lietas kā nosacītā plūsma tiek paslēptas JavaScript failos un XSLT.

Vairāki formāti - Java, JavaScript, XSL, XML shēma un tā tālāk -, kas apraksta procesu un datus, ir papildu slogs. Tātad, lai gan Sonic ESB izmantošana ir programmēšanas darbība, tas ir produkts, kas veidots ap tehnoloģiju kopu, nevis vienu labi izstrādātu apzīmējumu.

Tas ne vienmēr ir Sonic Software vaina. Viņi strādā ar rīkiem, kurus viņiem prasa viņu klientu pieprasītās tehnoloģijas un standarti. Es šaubos, vai Sonic Software spētu veicināt dažu vienveidīgāku apzīmējumu pieņemšanu.

Tā kā vienots apzīmējums nav pieejams, ziņojumu plūsmas, kļūdu apstākļu un datu transformāciju izpratnei ir maz vizuālu norādījumu. Patiešām, bez attēliem un apraksta, kas ietverti darba sākšanas rokasgrāmatā, ziņu plūsmas izpratne sniegtajā piegādes ķēdes piemērā būtu bijusi sarežģīta. Es sapratu, ka pagriezts no iekšpuses uz āru, darba sākšanas rokasgrāmata faktiski bija sistēmas arhitektūra; ceļvedī redzamie attēli un apraksti, visticamāk, ir tie paši, kurus piemēra izstrādātāji izmantoja, veidojot to.

Lai veiksmīgi izmantotu tādus produktus kā Sonic ESB, izstrādātājiem, kas darbojas kā “integrācijas arhitekti”, būs nepieciešama šāda veida rūpīga plānošana. Integrācijas arhitektiem pieejamie rīki, paņēmieni un modelēšanas metodika joprojām ir elementāri, taču Sonic ESB sniedz visaptverošu rīku komplektu, kas nepieciešams integrācijas ieviešanai, tiklīdz tā ir plānota.

Elastība par cenu

Sonic ESB apvienojumā ar SonicMQ nodrošina uz standartiem balstītu metodi gan mantoto, gan jauno lietojumprogrammu integrēšanai visā uzņēmumā gan uzticamā, gan rentablā veidā. Sistēmu kopas integrēšanai ar Sonic ESB vajadzētu maksāt mazāk nekā ar patentētu integrācijas brokeru izmantošanu.

Pārskatot SonicXQ, Sonic ESB priekšteci, mēs secinājām, ka “SonicXQ nodrošina izstrādātājiem drošu, uzticamu BPM (biznesa procesu vadības) pakalpojumu kopumu” (sk. “BPM uzturēšana uz ceļa”, 30. septembris, 26. lpp.).

Tas nav mainījies. Bet, lai gan pārvaldības rīki tagad ir daudz uzlaboti, Sonic ESB 5.0 bieži prasa sarežģītu konfigurāciju. Lai tas darbotos, ir nepieciešamas ievērojamas prasmes tādās tehnoloģijās kā J2EE, uz ziņojumapmaiņu orientēta starpprogrammatūra, XML, XSLT, XPath, JavaScript un Java.

Šī ir elastības cena. Dažu rīku mērķis ir ērta lietošana un pat lepojas, ka biznesa cilvēki tos var izmantot biznesa procesu pārvaldībai. Bet neviens no tiem nepiedāvā elastību, kas nepieciešama pilnīgai sistēmas integrācijai. SonicESB piedāvā šo elastību, taču tikai tad, ja jums ir izstrādātāji un integrācijas arhitekti, lai to izmantotu.

Rezultātu karte Vadāmība (15.0%) Lietošanas ērtums (10.0%) Atbalsts (10.0%) Mērogojamība (25.0%) Savietojamība (25.0%) Uzticamība (15.0%) Kopējais rādītājs (100%)
Sonic ESB 5.05.06.07.09.09.09.0 7.9
$config[zx-auto] not found$config[zx-overlay] not found