4. De belangrijkste integratieconcepten
Van afkorting tot afkorting
Het loopt goed met de taarten en cakes van Aleksandra. Haar zus dringt er nu echt op aan om hier een business van te maken. Maar daar komt ineens een hoop bij kijken. Voordat ze van alles gaat kopen, stelt ze eerst een businessplan op.
Aleksandra kon niet veel spullen uit Oekraïne meenemen. Gelukkig heeft ze van allerlei buren en de gemeente verschillende keukengereedschappen gekregen. Een aantal spullen zal echter geprofessionaliseerd moeten worden. Gereedschap voor het bakken, een oven en een diepvrieskist.
Aleksandra gaat bij het opleidingsinstituut voor bakkers in Zaandam, de Bakery Institute, te rade voor wat ze allemaal nodig heeft. Daarnaast zal ze een eenmanszaak moeten oprichten. Dus zal ze iets moeten leren over zaken doen in Nederland. Over belastingen, verzekeringen en marketing. Een bevriende ondernemer heeft beloofd haar wegwijs te maken in het Nederlandse regeltjesdoolhof.
De gereedschapskist van een integratiespecialist
Iedereen heeft wel een mening klaar staan. Zo heeft iedereen wel een mening over de cakes die Aleksandra bakt. En haar zus over hoe je geld verdient met een business. En zo zijn er ook 18 miljoen meningen over het Nederlands voetbalelftal. Toch moeten er ook professionals zijn die verder kijken dan alleen de mening. Die echt kennis hebben van de concepten om professioneel resultaten te kunnen boeken.
Aleksandra heeft kennis van bakken. Haar vriend van ondernemen. En Louis van Gaal van voetbal. Welke kennis heb je nodig als integratiespecialist? In dit hoofdstuk gaan we dieper in op de techniek achter integratie. Je kunt elk technisch component als een stuk gereedschap zien om een integratievraagstuk mee op te lossen. Aan het eind van het hoofdstuk is je gereedschapskist goed gevuld.
Producten
Er zijn honderden soorten integratie-tools, frameworks, libraries en producten. Een bekende lijst is Capterra Integration Sofware. Deze lijst bevat zowel bekende product suites als kleine tools die zijdelings met data integratie te maken hebben.
De lijst geeft wel een goed beeld van de hoeveelheid softwarepakketten in de markt, die enorm is. Het zijn er honderden, maar dat maakt het ook onoverzichtelijk wat je met de verschillende tools en producten kunt. Er worden in de beschrijvingen een hoop begrippen en afkortingen gebruikt, maar de vraag is wat die betekenen. Laten we het uitzoeken.
Technische integratie
Technische integratie bevat middleware componenten die data transporteren zonder zich met de inhoud bezig te houden. De data blijft onveranderd.
We behandelen drie categorieën technische integratieecomponenten:
- Remote Procedure Calls
- Gateways
- Brokers
Elke categorie en enkele subcategorieën worden besproken. Ook wordt er telkens een aantal voorbeelden genoemd. Aan het eind van het boek is er per categorie een meer complete voorbeeldlijst te vinden met links naar de betreffende software.
RPC
Remote procedure calls (RPC) zorgen dat systemen een externe functie laten uitvoeren. Doordat systemen elkaars processen uitvoeren, is er sprake van integratie tussen meerdere systemen. Dit is eigenlijk de traditionele manier om systemen met elkaar te integreren.
Een RPC call wordt geïnitieerd door een cliënt die een functie op een externe server aanroept en uitvoert. Hierbij kunnen er ook parameters en data worden meegestuurd. Zodra de procedure is uitgevoerd wordt een resultaat of bevestiging teruggestuurd. In moderne varianten wordt vaak gebruik gemaakt van XML of JSON.
In tegenstelling tot het uitvoeren van processen binnen een systeem, kan bij een remote procedure het proces vastlopen, omdat het externe systeem tijdelijk niet beschikbaar is of te langzaam is.
Een Remote Procedure Call is als een bestelling in een restaurant. Je geeft op wat je wilt eten en drinken. Dan wacht je even en dan wordt het eten geserveerd. Meestal gaat het goed, maar er gaan soms ook wat dingen mis in de keuken.
Voorbeelden RPC Software:
Gateways
Een gateway is een doorgeefluik tussen twee applicaties. Het knoopt verschillende transportprotocollen aan elkaar en zorgt voor het uitwisselen van berichten. Je zou het kunnen vergelijken met de functie van een kraan op een overslagplaats in de haven.
De kraan hevelt een container over van het ene transportmiddel naar het andere. Bijvoorbeeld van een schip naar een trein. Een gateway kan bijvoorbeeld bestanden verplaatsen van een SFTP-server naar een HTTP- webservice.
File gateway
In de simpelste vorm is een file gateway een adapter tussen twee componenten. Een file adapter zal meestal actief een bestand ophalen of afleveren. Hij wacht tot een bepaalde gebeurtenis plaatsvindt en neemt aansluitend actie. Sommige adapters worden specifiek geschreven als brug tussen twee protocollen. Andere zijn veelzijdig en kunnen allerlei transportprotocollen aan, bijvoorbeeld SFTP, HTTP en JDBC.
File Management
In simpele situaties, bij lage berichtvolumes of bij veel invloed op de gebruikte technologie, kan een adapter als file gateway afdoende zijn. Zodra het aantal adapters en berichtvolumes toenemen, ontstaat de behoefte aan centraal management en monitoring. In dit geval zijn er adapter frameworks of MFT (Managed File Transfers) systemen nodig.
MFT’s bieden de volgende drie functionaliteiten:
- Ondersteuning voor meerdere protocollen en formaten
- Centrale configuratie & management
- Monitoring
Voorbeelden:
Bij kleine bedrijven is een MFT-oplossing vaak voldoende voor alle integratie, bij grote bedrijven is dit één van de componenten in combinatie met andere.
API Gateway
Een API Gateway ontkoppelt API’s. Al het verkeer tussen de API of eenvoudigweg het aanroepen van API’s gaat langs deze gateway. De API Gateway zorgt daarbij voor onder andere security, load balancing en caching. Meer over het onderwerp API’s is te vinden in het volgende hoofdstuk.
Voorbeelden:
B2B-netwerk
Een netwerk waar een file en/of API gateway wordt aangeboden tussen organisaties (business 2 business). Meestal worden standaarden als HL7, Edifact en GS1 ondersteund.
Brokers
Een gateway is alleen een doorgeefluik tussen twee componenten. In de management tools van file gateways wordt wel aangegeven hoeveel en naar wie iets gaat, maar niet hoe en wat. Hiervoor kan er een broker worden gebruikt. Een broker is een middleware component waarop producers berichten kunnen plaatsen en consumers berichten kunnen ophalen.
Een broker is een belangrijke component die applicaties nog meer van elkaar ontkoppelt. De brokerlaag zorgt voor een generiek endpoint, een generiek protocol en vaak voor caching en buffering van berichten. Je zou het kunnen vergelijken met een distributiecentrum. Aan de ene kant leveren fabrikanten goederen, terwijl winkels deze weer ophalen. Het distributiecentrum zorgt tussentijds voor de verdeling en opslag.
In basis zijn er twee soorten broker endpoints:
- Queue — Endpoint met een wachtrij van berichten. Als er geen antwoord nodig is het Point-to-Point anders Request-and-Reply.
- Topic — Endpoint waarop berichten kunnen geplaatst, iedereen die geabonneerd is op dit endpoint krijgt een kopie (Publish-Subscribe).
Hoe een endpoint precies werkt, is sterk afhankelijk van de technische implementatie van deze concepten. Hier volgen enkele voorbeelden.
JMS Broker
Een JMS broker is een implementatie van de JMS (Java Message Service) API. Deze library heeft ondersteuning voor zowel queues als topics. Omdat er veel integratieplatformen in Java zijn gemaakt, zie je JMS Brokers veel terug in product suites. Denk aan producten als Tibco, Websphere, Oracle Fusion en Mule.
JMS is een krachtige library, maar wel sterk gebonden aan Java en de implementatie van de broker. Zo heb je altijd een client library nodig om met een JMS broker te koppelen. Dit hoeft niet perse in Java te zijn, maar clients in andere programmeertalen zijn schaars.
Voorbeelden:
MSMQ
MSMQ is een implementatie van message queueing door Microsoft. Het is geen full-blown broker, maar gebruikt queues (tijdelijke locatie voor opslag van berichten). Het wordt vooral gebruikt binnen Windows, door Bizztalk en .Net applicaties.
Voorbeeld: Bizztalk
AMQP Broker
In tegenstelling tot JMS en MSMQ is AMQP geen implementatie, maar een protocol. Het geeft de dataformaten aan waaraan een broker of applicatie moet voldoen die dit protocol implementeert. Er zijn daarom ook implementaties en clients in allerlei programmeertalen. AMQP is over het algemeen wat uitgebreider in de mogelijkheden van queues en topics dan JMS. Voor alle verschillen, zie het artikel Understanding the differences between AMQP & JMS
Voorbeelden:
MQTT Broker
MQTT is een lichtgewicht broker die van topics uitgaat. Het is ontworpen om zo min mogelijk bandbreedte te gebruiken, waardoor deze broker veelal in gebruik is in IOT (Internet of Things). Bijvoorbeeld het verzamelen van data van sensoren.
Voorbeelden:
Ook ActiveMQ en RabbitMQ hebben ondersteuning voor MQTT.
STOMP Broker
Een STOMP broker implementeert het STOMP protocol. STOMP staat voor Simple (ook wel Streaming) Text Oriented Message Protocol. Het is vergelijkbaar met HTTP. HTTP is geïmplementeerd bovenop TCP met verschillende acties als GET en POST. Het STOMP protocol is ook bovenop TCP geïmplementeerd, maar voegt een aantal acties toe die specifiek zijn voor message orientated middleware, zoals SEND en SUBCRIBE.
Voorbeelden:
Ook ActiveMQ en RabbitMQ hebben ondersteuning voor STOMP.
Streaming broker
Streaming brokers zijn zodanig ontworpen dat data in topics wordt verspreid over meerdere nodes. Hierdoor zijn deze gedistribueerde brokers erg schaalbaar en kunnen ze veel data verwerken.
Voorbeelden:
In het hoofdstuk Queueing vs Streaming broker gaan we dieper in op hoe brokers werken en wat de verschillen zijn.
Apache
Veel technische middleware componenten vallen onder de Apache Foundation. De meest bekende projecten zijn Apache Kafka, Apache ActiveMQ en Apache Camel.
De Apache Foundation is een stichting die wordt ondersteund door grote (software) bedrijven. Zij levert open source-licenties, rechtsondersteuning, hosting enzovoorts. Alle projecten van de Apache foundation zijn te vinden op apache.org.
Vaak zijn de Apache-projecten geen kant-en-klare eindproducten, maar frameworks en libraries waar meerdere bedrijven aan werken. Deze software is vaak in een backend van bedrijven als Facebook en Google actief. Soms wordt een combinatie van meerdere Apache-projecten aangeboden als commercieel product (Red Hat en Cloudera zijn bekende bedrijven die producten van de Apache Foundation in hun portfolio hebben).
Functionele integratie
Functionele integratie betreft middleware componenten die data inhoudelijk overbruggen.
De belangrijkste categorieën zijn:
- DataFlow
- ESB
Dataflow
Dataflow is een stijl van integreren gebaseerd op “flow based programming”. Deze stijl is bedacht door J. Paul Morrison in de jaren 70 en gaat uit van componenten die databerichten verwerken en dynamisch met elkaar kunnen worden verbonden. Elk component werkt als een blackbox met input en output. Het is daarom een generieke manier van data processing (ook wel stream processing) die voor verschillende data- integratieschakels kan worden ingezet.
Zie: https://en.wikipedia.org/wiki/Flow-based_programming
De bekendste dataflow middlewares zijn Apache NiFi, Spring Cloud Data Flow en Node-Red. Alle drie de projecten zijn open source. NiFi kent zijn oorsprong bij de Amerikaanse veiligheidsdienst NSA, Spring Cloud Data Flow bij VMWare en Node-Red is oorspronkelijk bij IBM ontwikkeld.
Voorbeelden:
ESB
Enterprise Service Bus is een wat verwarrende term. Het heeft niets te maken met bussen die je naar het station neemt. Het heeft ook niets te maken met USB (Universal Serial Bus). USB zet ons in ieder geval op het juiste spoor. Onder een bus wordt over het algemeen data-uitwisseling tussen hardwarecomponenten verstaan. Bij een service bus gaat het om uitwisseling van data tussen softwarecomponenten.
Het idee is dat de bus een aantal standaard services binnen een bedrijf (enterprise) biedt, die vanuit verschillende andere softwarecomponenten kan worden aangeroepen.
Er kunnen ook meerdere services achter elkaar aangeroepen worden. Afhankelijk van de implementatie/softwarefabrikant, spreekt men dan over processen, routes of flows. Het aantal typen services en combinaties van services zijn beschreven in het boek Enterprise Integration Patterns van Gregor Hohpe and Bobby Woolf.
De term ESB raakt momenteel wat in onbruik. Meestal wordt er nu gewoon over Service Bus gesproken of is het onderdeel van een integratieplatform (Bijvoorbeeld Mule Anypoint).
Voorbeelden:
ESB Frameworks
Speciale vermelding verdienen frameworks, zoals Apache Camel, Spring Integration en Zato. Dit zijn frameworks waarmee je Enterprise Integration Patterns in software kunt inbouwen. Ze dienen ook als basis voor verschillende ESB-producten. Apache Camel is bijvoorbeeld een basiscomponent van Apache ServiceMix, Red Hat Fuse en Talend ESB.
Aan integratie gerelateerde software
Kenmerkend voor middleware is dat deze vaak domein-overstijgend is. De volgende componenten zijn componenten die ook organisatiebreed worden ingezet en daardoor veel gecombineerd worden met dataintegratie als onderdeel van de functionele integratie:
BRE
Business Rules Engine voeren geautomatiseerde bedrijfsregels uit. Omdat BRE-systemen vaak onafhankelijk werken van applicaties en bedrijfsbreed worden ingezet, is hier veel dataverkeer voor nodig.
Workflows zijn net als dataflows series van stappen die worden uitgevoerd. Bij workflows kan dit door een mens of systeem zijn. Meestal is het een langlopend proces met een aantal taken (hoeveelheid werk) dat wordt uitgevoerd. Vaak worden deze taken genoteerd in een dataformaat, zoals XML. Hierdoor kan een bepaald deel van een workflow door een data integratie worden uitgevoerd.
BPM
Business Process Management-systemen zijn applicaties die workflows op basis van de BPMN-notatie uitvoeren. Net als een workflow is een BPM workflow een serie van stappen om bepaalde werkprocessen vast te leggen en te automatiseren. Vaak bestaan die deels uit handmatige en deels uit geautomatiseerde stappen. Omdat er veel data wordt ingevoerd en verrijkt, zijn er veel datahandelingen voor nodig of is het systeem gekoppeld aan middleware, zoals brokers, gateways of een ESB.
Voorbeelden:
Pipelines
Pipelines zijn gerelateerd aan processen en workflows, met het verschil dat er altijd een resultaat is, bijvoorbeeld een software build of deployment (Continuous Delivery Pipeline). Meestal wordt een pipeline gestart door een mens of een gebeurtenis en wordt een aantal (lineaire) stappen doorlopen.
ETL
ETL (Extract, Transform and Load) is een voorbeeld van een pipeline voor data. Het is een aantal stappen om data geschikt te maken om in een standaard formaat te worden opgeslagen, gecombineerd en geanalyseerd. Meestal is dit data voor een datawarehouse, waarbij data uit verschillende bronnen wordt verzameld om hier één coherent geheel te vormen.
Voorbeelden:
En nu de hamvraag?
De vraag die is ons rest, welke tool gebruik ik nu waarvoor? Deze vraag is lastig (zo niet onmogelijk) om algemeen te beantwoorden. Het is namelijk afhankelijk van bijvoorbeeld:
- organisatiegrootte
- type technologieën
- kennis in de organisatie en de markt
- architectuurvisie
- tech trends
Heel grofweg kan wel aangegeven worden dat kleinere organisaties voldoende hebben aan een MFT-product of een iPaaS (integration Platform as a Service). Grotere organisaties hebben vaak een combinatie van:
- MFT (Files sync and sharing)
- API Management (API’s)
- ESB/Broker (Integraties)
- iPaaS (Cloud integraties)
- Gateways (Koppelingen)
In het vervolg gaan we dieper in op de verschillende technologieën, zodat het steeds duidelijk wordt, welke middleware en concepten waarvoor gebruikt worden.
Inhoudsopgave:
