Sonic ESB: Programmerbar integration

Trykket for at integrere forskellige systemer på tværs af virksomheden stiger støt, men etablering af forbindelser mellem systemer, selv dem, der er designet til integration, er stadig en skræmmende opgave.

Traditionelt forbandt virksomheder systemer ved hjælp af punkt-til-punkt-links og brugerdefineret kode. For nylig opstod integrationsmæglere - proprietær software til oprettelse af forbindelser mellem flere systemer - som en anden løsning. Punkt-til-punkt-forbindelser er dog dyre at vedligeholde, og integrationsmæglere har været dyre at købe.

Sonic ESB er et af et nyt sæt produkter, der faktureres som enterprise service busser (ESBs), lette integrationsmæglere baseret på standarder som XML og SOAP designet til at arbejde i et distribueret miljø.

For virksomheder, der ønsker at tage en inkrementel tilgang til integration af virksomhedsapplikationer, vil ESB'er være yderst nyttige. Ved hjælp af busmodellen kan et par applikationer med den største tilbagebetaling integreres først; andre applikationer kan foldes ind senere, når penge og ressourcer bliver tilgængelige. Da adgangsbarrierer er lave, kan disse integrationsprojekter starte små, styres tæt og vokse til at imødekomme fremtidige behov.

Sonic ESB 5.0 stræber efter at tilbyde disse fordele ved at kombinere messaging, routing, webservices og meddelelsestransformation for at integrere og orkestrere handlingerne i flere slutprogrammer til internetapplikationer.

Eyeing Sonics ESB-arkitektur

En typisk integrationsmægler har en hub- og egerarkitektur. Sonic ESB er derimod bygget oven på Sonic Softwares meddelelsesorienterede middleware-produkt, SonicMQ, en JMS-udbyder (Java Message Service) til J2EE-applikationsservere. SonicMQ giver Sonic ESB konfigurations- og kørselstidsstyring, messagingmæglere og administrerede containere. Samspillet mellem SonicMQ og ESB er så finkornet og komplet, at det ikke er underligt, at Sonic Software henviser til dem som en suite.

Fordi Sonic ESB er bygget på en messaging-infrastruktur, kan dets busarkitektur distribueres over virksomhedens LAN eller det globale internet. Meddelelsesnoder kan installeres i klynger på flere maskiner for at få pålidelighed, og disse klynger kan føderere med klynger andre steder for at give eksterne integrationspunkter.

Derudover er en domæneadministrator integreret med systemet og fungerer som et bibliotek for tjenester, der er implementeret på netværket.

Containere administrerer slutpunkter, som derefter administrerer livscyklussen for tjenester, der leverer routing, orkestrering af procesflow, datatransformation og sikkerhed. Disse containere tilpasser også slutpunkter til ældre systemer. For eksempel er en J2EE-adapter tilgængelig til at forbinde J2EE-baserede systemer til bussen. Servicecontainere hostes typisk adskilt fra messaging-serverne, der hver er samlokaliseret med det ældre system, som det serverer.

Beskeder ruter sig selv ved hjælp af en vedhæftet rejseplan oprettet via administrationskonsollen. Indholdsbaseret routing udføres inden for slutpunkttjenesterne ved hjælp af XPath til at se vedhæftede XML-dokumenter og betinget rute baseret på dokumentets indhold. Transformationstjenesten bruger XSLT (eXtensible Style Language Transformation). Sonic Softwares Stylus-produkt opretter grafisk XSLT-dokumenter, der omdannes fra et XML-skema til et andet, men ethvert andet XSLT-værktøj fungerer også.

Søger integrationsarkitekten

Da jeg gik i anden klasse, bragte et barn i min klasse et elektroniklegetøj, der lader dig bygge en radio og andre enkle elektroniske enheder ved at følge de medfølgende skemaer og klikke på blokkene sammen. Da jeg gennemgik Sonic ESB, kunne jeg ikke lade være med at tænke på snap-sammen-programmer, da jeg manipulerede dens konfiguration gennem den GUI-baserede styringskonsol.

Selvom meget af det, du laver, når du opretter Sonic ESB, bare manipulerer konfigurationsfiler, er slutresultatet en proces, der manipulerer data. Dette er mere end blot politikbaseret konfiguration - dette er programmering.

Programmering af Sonic ESB udføres ikke med en samlet notation, men involverer at skrive uddrag af Java og JavaScript sammen med XSLT-, XML-skema- og WSDL-filer. Flere forskellige grafiske værktøjer arrangerer alle disse i en samlet konfiguration, der producerer den korrekte routing og service til det ønskede resultat.

Sonic Software leverer et omfattende eksempel på en forsyningskæde i vejledningen Kom godt i gang. Hvis du arbejder igennem dette eksempel, får du fart på de vigtigste tilstande for ESB-interaktion og gør dig bekendt med de koncepter og styringsværktøjer, der er nødvendige for at konfigurere og bruge bussen.

Da jeg gennemgik konfigurationsprocessen, blev jeg ramt af, hvor svært det var at holde styr på alle de forskellige dele, hvad de gjorde, og hvordan de passede sammen. Sonic ESBs ledelseskonsoller er så gode som jeg har set. Men de er ikke programmeringsmiljøer - de tilbyder kun rudimentær support til abstraktion. For eksempel tillader procesflowet navngivning og indlejring, men ting så vigtige som betinget flow er skjult i JavaScript-filer og XSLT.

De flere formater - Java, JavaScript, XSL, XML-skema osv. - der beskriver proces og data er en ekstra byrde. Så selvom brug af Sonic ESB er en programmeringshandling, er det et produkt bygget op omkring en klynge af teknologier snarere end en enkelt veldesignet notation.

Det er ikke nødvendigvis Sonic Software skyld. De arbejder med de værktøjer, der kræves af dem i henhold til de teknologier og standarder, deres kunder kræver. Jeg tvivler på, at Sonic Software ville være i stand til at drive vedtagelsen af ​​en mere ensartet notation.

Da en ensartet notation ikke er tilgængelig, er der få visuelle signaler til forståelse af meddelelsesflow, fejlforhold og datatransformationer. Uden billederne og beskrivelsen indeholdt i vejledningen Kom godt i gang ville det have været vanskeligt at forstå strømmen af ​​meddelelser i det medfølgende forsyningskædeeksempel. Jeg indså, at Kom igang-vejledningen faktisk blev systemarkitekturen vendt indefra og ud; billederne og beskrivelserne i guiden er sandsynligvis de samme, som udviklerne af eksemplet brugte, mens de oprettede det.

Vellykket brug af produkter som Sonic ESB vil kræve den samme form for omhyggelig planlægning af udviklere, der fungerer som “integrationsarkitekter”. De værktøjer, teknikker og modelleringsmetoder, der er tilgængelige for integrationsarkitekter, er stadig rudimentære, men Sonic ESB leverer et omfattende sæt værktøjer, der er nødvendige for at implementere integrationen, når den er planlagt.

Fleksibilitet til en pris

Sonic ESB kombineret med SonicMQ giver en standardbaseret metode til at integrere både ældre og nye applikationer fra hele virksomheden på en måde, der er både pålidelig og omkostningseffektiv. Integrering af et sæt systemer med Sonic ESB skulle koste mindre end at bruge proprietære integrationsmæglere.

Ved gennemgang af SonicXQ, Sonic ESBs forgænger, konkluderede vi, at “SonicXQ giver udviklere et solidt sæt sikre, pålidelige BPM-tjenester (forretningsprocesstyring)” (se “Holde BPM på sporet”, 30. september, side 26).

Det har ikke ændret sig. Men mens styringsværktøjerne nu er meget forbedret, kræver Sonic ESB 5.0 ofte kompleks konfiguration. At få det til at udføre kræver betydelig dygtighed inden for teknologier som J2EE, messaging-orienteret middleware, XML, XSLT, XPath, JavaScript og Java.

Dette er prisen på fleksibilitet. Nogle værktøjer sigter mod brugervenlighed og kan endda prale af, at forretningsfolk kan bruge dem til at styre forretningsprocesser. Men ingen af ​​dem tilbyder den nødvendige fleksibilitet til komplet systemintegration. SonicESB tilbyder den fleksibilitet, men kun hvis du har udviklere og integrationsarkitekter til at drage fordel af det.