Sonic ESB: Ohjelmoitava integraatio

Paine erilaisten järjestelmien integroimiseksi koko yritykseen kasvaa tasaisesti, mutta yhteyksien luominen järjestelmien välillä, jopa integrointiin suunnitellut, on edelleen pelottava tehtävä.

Perinteisesti yritykset liittivät järjestelmiä käyttämällä pisteestä pisteeseen -linkkejä ja mukautettua koodia. Viime aikoina integraatiovälittäjät - oma ohjelmisto yhteyksien luomiseen useiden järjestelmien välillä - nousivat esiin toisena ratkaisuna. Pisteestä pisteeseen -yhteyksien ylläpito on kuitenkin kallista, ja integraatiovälittäjien ostaminen on ollut kallista.

Sonic ESB on yksi uusista tuotteista, joita laskutetaan yrityspalvelubusseina (ESB), kevyinä integraatiovälittäjinä, jotka perustuvat XML: n ja SOAP: n kaltaisiin standardeihin, jotka on suunniteltu toimimaan hajautetussa ympäristössä.

Yrityksille, jotka haluavat lähestyä yrityssovellusten integrointia, ESB: t ovat erittäin hyödyllisiä. Väylämallia käyttämällä voidaan ensin integroida muutama suurin takaisinmaksuaikainen sovellus; muut sovellukset voidaan taittaa myöhemmin, kun rahaa ja resursseja tulee saataville. Koska markkinoille pääsyn esteet ovat vähäiset, nämä integraatioprojektit voivat aloittaa pieninä, niitä voidaan hoitaa tiiviisti ja ne voivat kasvaa vastaamaan tulevia tarpeita.

Sonic ESB 5.0 pyrkii tarjoamaan nämä edut yhdistämällä viestit, reitityksen, verkkopalvelut ja viestien muunnoksen useiden Internet-sovellusten päätepisteiden toimintojen integroimiseksi ja orkestroimiseksi.

Eyeing Sonicin ESB-arkkitehtuuri

Tyypillisellä integraatiovälittäjällä on napa- ja pinnaarkkitehtuuri. Sonic ESB puolestaan ​​on rakennettu Sonic Softwaren viestikeskeisen välituotetuotteen, SonicMQ: n, J2EE-sovelluspalvelimien JMS (Java Message Service) -palvelun, päälle. SonicMQ tarjoaa Sonic ESB: lle kokoonpanon ja ajonaikaisen hallinnan, viestinvälittäjät ja hallitut säilöt. SonicMQ: n ja ESB: n väliset vuorovaikutukset ovat niin hienojakoisia ja täydellisiä, että ei ole ihme, että Sonic Software viittaa niihin sarjana.

Koska Sonic ESB on rakennettu viestintäinfrastruktuurille, sen väyläarkkitehtuuri voidaan jakaa yrityksen lähiverkon tai maailmanlaajuisen Internetin yli. Viestintäsolmut voidaan asentaa useiden koneiden klustereihin luotettavuuden varmistamiseksi, ja nämä klusterit voivat yhdistää klustereita muissa paikoissa tarjoamaan etäintegraatiopisteitä.

Lisäksi verkkotunnuksen hallinta on integroitu järjestelmään ja toimii hakemistona verkossa käyttöön otetuille palveluille.

Säiliöt hallitsevat päätepisteitä, jotka hallitsevat sitten palvelujen elinkaarta, jotka tarjoavat reitityksen, prosessivirran orkestroinnin, tiedonmuunnoksen ja suojauksen. Nämä säiliöt mukauttavat myös päätepisteet vanhoihin järjestelmiin. Esimerkiksi J2EE-sovitin on käytettävissä J2EE-pohjaisten järjestelmien kytkemiseksi väylään. Palvelusäiliöitä isännöidään tyypillisesti erillään viestipalvelimista, jotka kukin sijaitsevat yhdessä sen palveleman vanhan järjestelmän kanssa.

Viestit reitittävät itsensä käyttämällä hallintakonsolin kautta luotua oheista reittiä. Sisältöpohjainen reititys tehdään päätepisteiden sisällä käyttäen XPath-ohjelmaa, jotta voidaan tarkastella liitteenä olevia XML-asiakirjoja ja reitittää ehdollisesti asiakirjan sisältöön. Muunnospalvelu käyttää XSLT: tä (eXtensible Style Language Transformation). Sonic Softwaren Stylus-tuote luo graafisesti XSLT-asiakirjoja, jotka muuttuvat yhdestä XML-skeemasta toiseen, mutta myös kaikki muut XSLT-työkalut toimivat.

Integraatioarkkitehdin etsiminen

Kun olin toisessa luokassa, luokkani lapsi toi elektroniikkalelun, jonka avulla voit rakentaa radion ja muita yksinkertaisia ​​elektronisia laitteita seuraamalla mukana olevia kaavioita ja napsauttamalla lohkoja yhteen. Tarkastellessani Sonic ESB: tä en voinut olla ajattelematta yhdistäviä ohjelmia, kun manipuloin sen kokoonpanoa GUI-pohjaisen hallintakonsolin kautta.

Vaikka suurin osa Sonic ESB: n määrityksessä tekemästänne vain manipuloi asetustiedostoja, lopputulos on prosessi, joka manipuloi tietoja. Tämä on muutakin kuin yksinkertaisesti käytäntöpohjainen määritys - tämä on ohjelmointi.

Sonic ESB: n ohjelmointi ei ole tehty yhtenäisellä merkinnällä, vaan siihen sisältyy Java- ja JavaScript-katkelmien kirjoittaminen yhdessä XSLT-, XML-skeemojen ja WSDL-tiedostojen kanssa. Useat erilaiset graafiset työkalut järjestävät nämä kaikki kokonaiskokoonpanoon, joka tuottaa oikean reitityksen ja palvelun halutulle tulokselle.

Sonic Software tarjoaa kattavan esimerkin toimitusketjusta Aloitusoppaassa. Tämän esimerkin avulla saat nopeutta ESB-vuorovaikutuksen tärkeimmistä moodeista ja tutustut väylän määritykseen ja käyttöön tarvittaviin käsitteisiin ja hallintatyökaluihin.

Konfigurointiprosessin aikana hämmästyin siitä, kuinka vaikeaa oli seurata kaikkia eri osia, mitä he tekivät ja kuinka ne sopivat yhteen. Sonic ESB: n hallintakonsolit ovat yhtä hyviä kuin olen nähnyt. Mutta ne eivät ole ohjelmointiympäristöjä - ne tarjoavat vain alkeellista tukea abstraktiolle. Esimerkiksi prosessivirta sallii nimeämisen ja upottamisen, mutta yhtä tärkeät asiat kuin ehdollinen kulku piilotetaan JavaScript-tiedostoissa ja XSLT: ssä.

Prosessia ja tietoja kuvaavat useat muodot - Java, JavaScript, XSL, XML-skeema ja niin edelleen - ovat ylimääräinen taakka. Joten vaikka Sonic ESB: n käyttö on ohjelmointitoimenpide, se on tuote, joka on rakennettu teknologiajoukon ympärille, eikä yksi hyvin suunniteltu notaatio.

Se ei välttämättä ole Sonic Softwaren vika. He työskentelevät työkaluilla, joita heiltä vaaditaan asiakkaiden vaatimien tekniikoiden ja standardien mukaan. Epäilen, että Sonic Software pystyisi ajamaan jonkin yhtenäisemmän notaation käyttöönottoa.

Koska yhtenäinen merkintätapa ei ole käytettävissä, viestivirran, virhetilanteiden ja tiedonmuunnosten ymmärtämiseen on vain vähän visuaalisia vihjeitä. Ilman aloitusoppaassa olevia kuvia ja kuvausta viestien kulun ymmärtäminen annetussa toimitusketjun esimerkissä olisi ollut vaikeaa. Tajusin, että se kääntyi nurinpäin, Aloitusopas oli itse asiassa järjestelmän arkkitehtuuri; oppaan kuvat ja kuvaukset ovat todennäköisesti samat, joita esimerkin kehittäjät käyttivät sitä luodessaan.

Sonic ESB: n kaltaisten tuotteiden onnistunut käyttö edellyttää samanlaista huolellista suunnittelua kehittäjiltä, ​​jotka toimivat "integraatioarkkitehdeina". Integraatioarkkitehtien käytettävissä olevat työkalut, tekniikat ja mallintamismenetelmät ovat edelleen alkeellisia, mutta Sonic ESB tarjoaa kattavan joukon työkaluja, joita tarvitaan integraation toteuttamiseksi, kun se on suunniteltu.

Joustavuus hintaan

Sonic ESB yhdistettynä SonicMQ: iin tarjoaa standardeihin perustuvan menetelmän sekä vanhojen että uusien sovellusten integroimiseksi eri puolilta yritystä luotettavalla ja kustannustehokkaalla tavalla. Joukon järjestelmiä integroimalla Sonic ESB: n pitäisi maksaa vähemmän kuin omien integraatiovälittäjien käyttäminen.

Tarkastellessamme Sonic ESB: n edeltäjää SonicXQ, päädyimme siihen, että "SonicXQ tarjoaa kehittäjille vankan joukon turvallisia, luotettavia BPM (business process management) -palveluja" (katso "BPM: n pitäminen tiellä", 30. syyskuuta, sivu 26).

Se ei ole muuttunut. Vaikka hallintatyökaluja on nyt paljon parannettu, Sonic ESB 5.0 vaatii usein monimutkaisen määrityksen. Sen suorittaminen vaatii huomattavaa taitoa tekniikoissa, kuten J2EE, viestintäkeskeinen väliohjelmisto, XML, XSLT, XPath, JavaScript ja Java.

Tämä on joustavuuden hinta. Jotkut työkalut pyrkivät helppokäyttöisyyteen ja ylpeilevät jopa siitä, että liikemiehet voivat käyttää niitä liiketoimintaprosessien hallintaan. Mutta mikään niistä ei tarjoa järjestelmän täydelliseen integrointiin tarvittavaa joustavuutta. SonicESB tarjoaa tuon joustavuuden, mutta vain, jos sinulla on kehittäjiä ja integraatioarkkitehteja hyödyntämään sitä.