Sonic ESB: Programmerbar integrasjon

Trykket for å integrere ulike systemer over hele virksomheten øker jevnt, men å etablere forbindelser mellom systemer, selv de som er designet for integrering, er fortsatt en skremmende oppgave.

Tradisjonelt koblet bedrifter til systemer ved hjelp av punkt-til-punkt-lenker og tilpasset kode. Mer nylig, integrasjonsmeglere - proprietær programvare for å opprette forbindelser mellom flere systemer - dukket opp som en annen løsning. Punkt-til-punkt-tilkoblinger er imidlertid dyre å vedlikeholde, og integrasjonsmeglere har vært dyre å kjøpe.

Sonic ESB er et av et nytt sett med produkter fakturert som enterprise service buss (ESB), lette integrasjonsmeglere basert på standarder som XML og SOAP designet for å fungere i et distribuert miljø.

For bedrifter som ønsker å ta en inkrementell tilnærming til integrasjon av bedriftsapplikasjoner, vil ESB være svært nyttig. Ved hjelp av bussmodellen kan noen få applikasjoner med størst tilbakebetaling integreres først; andre applikasjoner kan brettes inn senere når penger og ressurser blir tilgjengelige. Fordi inngangsbarrierer er lave, kan disse integreringsprosjektene begynne i det små, forvaltes tett og vokse for å møte fremtidige behov.

Sonic ESB 5.0 tilstreber å tilby disse fordelene, ved å kombinere meldinger, ruting, webtjenester og transformasjon av meldinger for å integrere og organisere handlingene til flere sluttprogrammer for Internett-applikasjoner.

Eyeing Sonic’s ESB Architecture

En typisk integrasjonsmegler har et nav og ekerarkitektur. Sonic ESB er derimot bygget på toppen av Sonic Softwares meldingsorienterte mellomvareprodukt, SonicMQ, en JMS-leverandør (Java Message Service) for J2EE-applikasjonsservere. SonicMQ gir Sonic ESB konfigurasjons- og kjøretidsadministrasjon, meldingsmeglere og administrerte containere. Samspillet mellom SonicMQ og ESB er så finkornet og komplett at det er lite rart Sonic Software refererer til dem som en suite.

Fordi Sonic ESB er bygget på en meldingsinfrastruktur, kan bussarkitekturen distribueres over bedriftens LAN eller det globale Internett. Meldingsnoder kan installeres i klynger på flere maskiner for pålitelighet, og disse klyngene kan føderere med klynger andre steder for å gi eksterne integreringspunkter.

I tillegg er en domeneadministrator integrert med systemet og fungerer som en katalog for tjenester distribuert på nettverket.

Containere administrerer sluttpunkter, som deretter administrerer livssyklusen til tjenester som gir ruting, orkestrering av prosessflyt, datatransformasjon og sikkerhet. Disse containerne tilpasser også sluttpunkter til eldre systemer. For eksempel er en J2EE-adapter tilgjengelig for å koble J2EE-baserte systemer til bussen. Tjenestecontainere er vanligvis vert separat fra meldingsserverne, hver av dem er samlokalisert med det eldre systemet som det serverer.

Meldinger ruter seg ved hjelp av en vedlagt reiserute opprettet via administrasjonskonsollen. Innholdsbasert ruting gjøres inne i sluttpunkttjenestene ved hjelp av XPath for å se vedlagte XML-dokumenter og betinget rute basert på innholdet i dokumentet. Transformasjonstjenesten bruker XSLT (eXtensible Style Language Transformation). Sonic Softwares Stylus-produkt lager grafisk XSLT-dokumenter som forvandles fra ett XML-skjema til et annet, men ethvert annet XSLT-verktøy vil også fungere.

Søker integrasjonsarkitekten

Da jeg gikk i andre klasse, hentet et barn i klassen min et elektronikkleketøy som lar deg bygge en radio og andre enkle elektroniske enheter ved å følge de medfølgende skjemaene og klikke blokkene sammen. Da jeg gjennomgikk Sonic ESB, kunne jeg ikke la være å tenke på snap-in-programmer mens jeg manipulerte konfigurasjonen gjennom den GUI-baserte administrasjonskonsollen.

Selv om mye av det du gjør når du konfigurerer Sonic ESB bare manipulerer konfigurasjonsfiler, er sluttresultatet en prosess som manipulerer data. Dette er mer enn bare policybasert konfigurasjon - dette er programmering.

Programmering av Sonic ESB gjøres ikke med en enhetlig notasjon, men innebærer å skrive utdrag av Java og JavaScript sammen med XSLT-, XML-skjemaer og WSDL-filer. Flere forskjellige grafiske verktøy ordner alle disse i en generell konfigurasjon som gir riktig ruting og service for ønsket resultat.

Sonic Software gir et omfattende eksempel på en forsyningskjede i Kom i gang-guiden. Hvis du arbeider gjennom dette eksemplet, vil du få fart på de viktigste modusene for ESB-samhandling og gjøre deg kjent med konseptene og styringsverktøyene som trengs for å konfigurere og bruke bussen.

Da jeg gikk gjennom konfigurasjonsprosessen, ble jeg slått av hvor vanskelig det var å holde rede på alle de forskjellige delene, hva de gjorde og hvordan de passet sammen. Sonic ESBs ledelseskonsoller er så gode som jeg har sett. Men de er ikke programmeringsmiljøer - de tilbyr bare rudimentær støtte for abstraksjon. For eksempel tillater prosessflyten navngivning og innebygging, men ting som er like viktige som betinget flyt er skjult i JavaScript-filer og XSLT.

Flere formater - Java, JavaScript, XSL, XML-skjema og så videre - som beskriver prosess og data er en ekstra belastning. Så selv om bruk av Sonic ESB er en handling av programmering, er det et produkt bygget rundt en klynge av teknologier i stedet for en enkelt godt designet notasjon.

Det er ikke nødvendigvis feilen til Sonic Software. De jobber med verktøyene som kreves av teknologiene og standardene kundene krever. Jeg tviler på at Sonic Software ville være i stand til å drive adopsjonen av en mer ensartet notasjon.

Fordi en ensartet notasjon ikke er tilgjengelig, er det få visuelle signaler for å forstå meldingsflyt, feilforhold og datatransformasjoner. Uten bildene og beskrivelsen i Komme i gang-veiledningen, hadde det faktisk vært vanskelig å forstå strømmen av meldinger i det medfølgende forsyningskjedeeksemplet. Jeg skjønte at når jeg kom i gang, var Kom godt i gang-veiledningen systemarkitekturen; bildene og beskrivelsene i guiden er sannsynligvis de samme som utviklerne av eksemplet brukte mens de opprettet det.

Vellykket bruk av produkter som Sonic ESB vil kreve den samme typen nøye planlegging av utviklere som fungerer som "integrasjonsarkitekter." Verktøyene, teknikkene og modelleringsmetodikkene som er tilgjengelige for integrasjonsarkitekter er fortsatt rudimentære, men Sonic ESB gir et omfattende sett med verktøy som er nødvendige for å implementere integrasjonen når den er planlagt.

Fleksibilitet til en pris

Sonic ESB, kombinert med SonicMQ, gir en standardbasert metode for å integrere både eldre og nye applikasjoner fra hele virksomheten på en måte som er både pålitelig og kostnadseffektiv. Integrering av et sett med systemer med Sonic ESB bør koste mindre enn å bruke proprietære integrasjonsmeglere.

Da vi gjennomgikk SonicXQ, Sonic ESBs forgjenger, konkluderte vi med at “SonicXQ gir utviklere et solid sett med sikre, pålitelige BPM-tjenester (forretningsprosessledelse)” (se “Holde BPM på sporet”, 30. september, side 26).

Det har ikke endret seg. Men mens administrasjonsverktøyene nå er mye forbedret, krever Sonic ESB 5.0 ofte kompleks konfigurasjon. Å få det til å utføre krever betydelig dyktighet innen teknologier som J2EE, meldingsorientert mellomvare, XML, XSLT, XPath, JavaScript og Java.

Dette er prisen på fleksibilitet. Noen verktøy tar sikte på brukervennlighet og kan til og med skryte av at forretningsfolk kan bruke dem til å styre forretningsprosesser. Men ingen av dem gir den nødvendige fleksibiliteten for fullstendig systemintegrasjon. SonicESB tilbyr den fleksibiliteten, men bare hvis du har utviklere og integrasjonsarkitekter som kan dra nytte av det.