-
Notifications
You must be signed in to change notification settings - Fork 0
componenten
In dit hoofdstuk gaan we wat dieper in op de techniek achter integratie. Je kan elk component als een stuk gereedschap zien om een integratievraagstuk mee op te lossen. Aan het eind van het hoofdstuk is de integrate gereedschapkist goed gevuld.
Er zijn honderden soort integratie tools, frameworks, libraries en producten op middleware gebied. Een bekende lijst Capterra Integration Softare. Deze lijst bevat zowel bekende product suites tot kleine tools die zijdelings met data integratie te maken heeft. Het geeft wel een goed beeld van de hoeveelheid software in de markt. In de komende hoofdstukken worden er verschillende voorbeelden geven van software projecten bij een bepaalde middleware component. Soms is lastig te bepalen omdat er soms overlap van functionaliteiten zijn.
Technische integratie bevat middleware componenten die data transporteren zonder zich met de inhoud bezig te houden.
Remote procedure calls zorgen dat systemen een externe (remote) 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 client die een functie op een remote server aanroept en uitvoert. Hierbij kunnen er ook parameters en data worden meegestuurd. In moderne varianten wordt vaak gebruik gemaakt van XML of JSON. In tegenstelling van het uitvoeren van processen binnen een systeem, kan een procedure vastlopen omdat het externe systeem tijdelijk niet beschikbaar is of te langzaam is.
Voorbeelden:
Een gateway is een doorgeefluik tussen twee applicaties. Het knoopt verschillen transportprotocollen aan elkaar en zorgt voor uitwisselen van berichten. Je zou het kunnen vergelijken met de functie van een kraan op een overslagplaats in de haven.
In de simpelste vorm is een file gateway een adapter tussen twee componenten. Een adapter zal meestal actief een bericht ophalen of afleveren. Het wacht tot een bepaalde gebeurtenis en neemt aansluitend actie. Sommige adaptoren worden specifiek geschreven als brug tussen twee componenten. Andere zijn veelzijdig en kunnen allerlei transport protocollen aan. Bijvoorbeeld SFTP, HTTP en JDBC.
File Management
In simpele situaties, lage berichten volumes of veel invloed op technologie kan een adapter afdoende zijn. Zodra het aantal adaptoren en berichtvolumes toenemen, ontstaat er de behoefte aan centraal management en monitoring. In dit geval zijn er adapter frameworks of MFT (Managed File Transfers) nodig. Zij bieden drie functionaliteiten:
- Ondersteuning voor meerdere protocollen en formaten
- Centrale configuratie & management
- Monitoring
Voorbeelden:
Bij kleine bedrijven is deze oplossing voldoende, bij grote bedrijven is dit één van de componenten in combinatie met andere.
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 security, load balancing, caching en throtteling. Meer over het onderwerp API's is te vinden in het laatste hoofdstuk van dit deel.
Voorbeelden:
Een netwerk waar een file en/of API gateway wordt aangeboden tussen organisaties. Meestal worden daarbij standaarden als HL7, Edifact en GS1 gebruikt.
Een broker is een middleware component waarop producers berichten kunnen plaatsen en consumers berichten kunnen ophalen. 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 tussen worden geplaatst. Het is een belangrijk component die applicaties nog meer van elkaar ontkoppelt. De broker laag zorgt voor een generiek endpoint, een generiek protocol en vaak ook voor caching en buffering van berichten. Je zou het kunnen vergelijken met een distributiecentrum.
In basis zijn er twee soorten broker endpoints:
- Queues – Wachtrijen van berichten
- Topics – Endpoint waarop berichten kunnen geplaatst, iedereen die geabonneerd is op dit endpoint krijgt een kopie.
Hoe een endpoint precies werkt is sterk afhankelijk van de technische implementatie van deze concepten. Voorbeelden zijn:
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 integratie platformen in Java zijn gemaakt, zie je JMS Brokers veel terug. Het 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:
In tegenstelling tot JMS en MSMQ is AMQP geen implementatie, maar een protocol. Het geeft de data formaten 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:
MSMQ is een implementatie van message queueing door Microsoft. Het is niet een full-blown broker, maar gebruikt queues (tijdelijke locatie voor opslag van berichten). Het wordt vooral gebruikt binnen Windows en door Bizztalk en .Net applicaties.
Voorbeeld: Bizztalk
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. Bijvoorbeeld het verzamelen van data van sensoren.
Voorbeelden:
Ook ActiveMQ en RabbitMQ hebben ondersteuning voor MQTT
Een STOMP broker implementeert het STOMP protocol (Simple (or Streaming) Text Oriented Message Protocol). Het is vergelijkbaar protocol met HTTP. HTTP is geïmplementeerd bovenop TCP met verschillende acties als GET en POST. Het STOMP protocol is ook bovenop TCP, 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 brokers zijn ontworpen, zodat data in topics wordt verspreid over meerdere nodes. Hierdoor zijn deze gedistribueerde brokers erg schaalbaar en kunnen ze veel data verwerken.
Voorbeelden:
De Apache stichting ondersteund door grote (software) onderneming levert Open source licenties, Rechtsondersteuning, Hosting enzovoorts. Vaak zijn de project geen kant-en-klare eindproducten, maar frameworks en libraries waar meerdere bedrijven aan werken. Deze software is vaak in backend van bedrijven als Facebook en Google actief. Soms worden door combinatie van meerdere Apache project aangevuld met tooling ook als Enterprise producten aangeboden (Red Hat en Cloudera volgen deze weg).
Veel van technische middleware componenten vallen onder de Apache stichting. Meeste bekende is Apache ActiveMQ (en de beoogde opvolger ActiveMQ Artemis). ActiveMQ is een zogenoemde Multi-protocol broker, zoals in ondersteuning voor eerdere genoemde protocollen al duidelijk is geworden. Apache project zijn vaak open source gedoneerd en gesponsord door grote ondernemingen. Voorbeelden zijn Kafka werd ontwikkelt door LinkedIn, Apache Pulsar door Yahoo en RocketMQ door Ali Baba.
Functionele integratie betreft middleware componenten die data inhoudelijk overbruggen.
Dataflow is een stijl van integreren gebaseerd op "flow based programming". Deze stijl is bedacht door J. Paul Morrison in de jaren 70. Het gaat uit van een componenten die databerichten verwerken en dynamisch met elkaar kunnen worden verbonden. Elke component fungeert als een blackbox met input en output. Het is daarom een generieke manier van data processing (ook wel stream processing) die voor verschillende data integratie schakels kan worden ingezet.
Zie: https://en.wikipedia.org/wiki/Flow-based_programming
Voorbeelden:
Apache Nifi en Node-Red zijn beide open source projecten. Nifi kent zijn oorsprong bij de Amerikaanse veiligheidsdienst NSA en Node-Red is vanuit IBM ontwikkelt.
Enterprise Service Bus is een wat verwarrende term. Het heeft niets met bussen te maken die je neemt naar het station. Het heeft ook niets te maken met USB (Universal Serial Bus). USB zet ons in ieder geval op juiste spoor. Onder een bus wordt over het algemeen data uitwisseling tussen hardware componenten verstaan. Bij een service bus gaat het om uitwisseling van data tussen software componenten. Het idee is dat de bus een aantal standaard services binnen een bedrijf (enterprise) biedt, die vanuit verschillende andere software componenten kan worden aangeroepen.
Er kunnen ook meerdere services achter elkaar aangeroepen worden. Afhankelijk van de implementatie/software fabrikant, spreekt men dan over processen, routes of flows. Het aantal type services en combinatie van services zijn beschreven in het boek Enterprise Integration Patterns van Gregor Hohpe and Bobby Woolf.
Dit boek bevat 65 patronen, zoals het filteren en verrijken van data. Een voorbeeld is dat het ERP systeem een bericht met artikelgegevens produceert. Dit bericht wordt verrijkt met gegevens uit het marketingsysteem. Bijvoorbeeld dat de taart heerlijk ambachtelijk gebakken is. Vervolgens worden alle artikelen van het type “taart” naar de taartenwebshop gezet. Gezien de webshop een Engels systeem is, worden de naam in het Engels vertaald, bijvoorbeeld artikelnummer wordt articlenumber en artikelomschrijving wordt ArticleNumber.
De term ESB raakt momenteel wat in onbruik. Meestal wordt er momenteel gewoon over Service Bus gesproken of is het onderdeel van data/integratie platform (Bijvoorbeeld Mule Anypoint).
Voorbeelden:
- CX Messenger
- Mule Anypoint
- Open ESB
- Red Hat Fuse
- ServiceMix
- Shuttle ESB
- SAP (Netweaver) PI, Swarm ESB
- Talend ESB
- TIBCO ActiveMatrix Service Bus
- WS02
- Websphere Service Bus
Speciale vermelding verdienen de frameworks, zoals Apache Camel, Spring Integration en Zato. Dit zijn frameworks, waarmee je Enterprise Integration Patterns in software kan inbouwen. Het dient ook als basis voor verschillende ESB producten. Camel is bijvoorbeeld een basiscomponent voor Apache ServiceMQ, Red Hat Fuse en Talend ESB.
De volgende componenten zijn componenten die ook bedrijfsbreed worden ingezet en daardoor veel gecombineerd worden met data integratie (meestal Dataflows of ESB) als onderdeel van de functionele integratie:
Business Rules Engine voeren geautomatiseerde bedrijfsregels uit. Omdat BRE systemen vaak onafhankelijk werken van applicaties en bedrijfsbreed worden ingezet, is hier veel data verkeer voor nodig.
Workflows zijn net als data flows een serie van stappen die worden uitgevoerd. Bij workflows kan dit door een mens of systeem zijn. Meestal is dit een taak (hoeveelheid) werk dat wordt uitgevoerd. Vaak wordt deze taak genoteerd in een data formaat, zoals XML. Hierdoor kan een bepaald deel van een workflow door een data flow worden uitgevoerd.
Business Process Management systemen zijn applicaties die workflows meestal op basis van BPMN notatie uitvoeren. Een workflow is een serie van stappen om bepaalde werkprocessen vast te leggen en te automatiseren. Vaak bestaan die deels uit handmatige en deels geautomatiseerde stappen. Omdat er veel data wordt ingevoerd en verrijkt, zijn er veel data handelingen voor nodig of is het gekoppeld aan middleware, zoals brokers, gateways of een ESB.
Voorbeelden:
Pipelines zijn gerelateerd aan processen en workflows, maar heeft als 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 worden een aantal (lineaire) stappen doorlopen.
ETL (Extract, Transform and Load) is een voorbeeld van pipeline voor data. Het zijn 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 Data Ware House, waarbij data uit verschillende bronnen data wordt verzameld en hier één coherent geheel wordt gemaakt in de database.
Voorbeelden:
Veel social media, zoals Facebook, LinkedIn en Twitter bieden een API aan. Deze kan je aanroepen vanuit een client, bijvoorbeeld voor je eigen Twitter account. Nu kun je natuurlijk op de website inloggen en een tweet achterlaten "superlekkere taarten", maar je kan dit dus evengoed via de API doen. Je zou bijvoorbeeld je eigen taartenwebsite aan de API van Twitter kunnen koppelen. Omgekeerd kan je bijvoorbeeld ook alle tweets ophalen die over bakken gaan. Die data zou je vervolgens weer op je website kunnen tonen.
Vrijwel alle organisaties stellen hun functionaliteit tegenwoordig beschikbaar via API's. Voorheen deed bijvoorbeeld alleen Twitter dit, tegenwoordig doet ook de bakker om de hoek dit. Het is dus alomtegenwoordig, maar wel echt een andere manier van het bedrijven van integratie. Daarom behandelen we dit onderwerp in een apart hoofdstuk.
API's hebben zowel een technisch als een functioneel aspect. Om API te begrijpen is het zowel nodig om op de technische kant als de business kant van het verhaal in te gaan.
Een API (Application Programming Interface) is:
“A set of clearly defined methods of communication between various software components. A good API makes it easier to develop a computer program all the building blocks, which are then put together by the programmer”. (Wikipedia)
Het gebruik van API’s is dus gegroeid vanuit het modulair opzetten van software. Neem bijvoorbeeld een programmeur die een script schrijft om zijn werk te automatiseren. De acties in het script worden eenvoudigweg onder elkaar uitgevoerd. Om sommige acties op meerdere plekken uit te voeren, maakt de programmeur een generieke functie. Al snel blijkt dat deze functie ook in andere scripts handig is. De verschillende generieke functies verzamelt hij ten slotte in een library die vanuit allerlei scripts aangeroepen kan worden. In basis zit achter elke API dan ook een library met generieke functies.
Een API gaat echter nog een stap verder dan een library. Ten eerste maakt een API een duidelijk verschil tussen functies die publiek toegankelijk zijn en interne functies. Ten tweede abstraheert een API van de implementatie van deze functies door een interface laag er bovenop te leggen. Deze is gericht op de clients die deze functies aanroepen. In zoverre is een API gewoon een lijst van functies die kunnen worden uitgevoerd. De library die het daadwerkelijk uitvoert is de implementatie. Soms zijn er meerdere implementaties van één API.
Al in de jaren 70 werden zo API’s in de programmeertaal C gemaakt. In Java is zelfs het maken van een API onderdeel van de taal zelf. Het maken van een lijst van functies heet daar "interface".
Er kleeft echter een sterk nadeel aan de API’s van programmeertalen. De programma’s die de API’s aanroepen, moeten in dezelfde taal zijn geschreven of er moet een brug tussen beide programmeertalen worden gemaakt. Zo maakt de broker Apache ActiveMQ gebruik van de Java API "JMS". Een library voor queues en topics. De programma’s die deze API aanroept moeten dan of in Java zijn geschreven of gebruiken maken van een bridge.
Een uitweg uit dit probleem is de functies beschikbaar te stellen via het internet. Dit is bekend onder de naam webservices. Het aanroepen van zulke functies lopen via HTTP requests. De eerste webservices maakten gebruik van XML om (SOAP) webservices te definiëren, tegenwoordig zijn REST webservices de standaard. In een REST webservice wordt een HTTP request gedaan op een URI (meestal een HTTP URL). Het response bericht bevat de data als tekst. Meestal in JSON Formaat. Een verzameling van REST webservice endpoints wordt een REST API genoemd.
REST staat voor REpresentational State Transfer. Maar de afkorting brengt ons niet veel verder om begrijpen wat het is. Kortweg is een REST API een architectuur stijl om een via HTTP requests data op te sturen of op te halen. Een HTTP Request bestaat uit de volgende onderdelen
- Actie
- URL
- Headers
- Body (Optioneel)
De meest gangbare acties zijn GET, POST, PUT of DELETE.
Meer achtergrond informatie over REST
Één van de belangrijkste voordelen van REST is dat het gebruik maakt van internetstandaarden. Hiermee is het technologie onafhankelijk. Dit maakt het niet alleen onafhankelijk van infrastructuur, maar ook van programmeertalen. Een aanroep kan vanuit een .Net applicatie gedaan worden op een REST API met daarachter een Java applicatie. Omdat de URI via het internet gebruikt kan de hardware resources overal worden geplaatst en opgeschaald.
Zo zie je dat voor user interfaces een website/webapp de belangrijkste standaard is en voor data interfaces is dit REST. Mendix, dat op de achtergrond simpelweg Java is, heeft bijvoorbeeld bewust gekozen om JMS niet te ondersteunen, maar alleen SOAP en REST (REST is native sinds Mendix 6). Ook bijvoorbeeld Sonic en APEX hebben ondersteuning voor REST.
REST is ook populair, omdat het in basis een beperkt aantal algemene acties bevat, namelijk GET, POST, PUT en DELETE. Deze zijn snel in te bouwen en sluiten goed aan op de database laag. Er kunnen ook meerdere applicaties op dezelfde API aangesloten worden. Meerdere applicaties kunnen bijvoorbeeld een artikel op vragen. Een aanroep is bijvoorbeeld http://example.nl/api/artikel?type=basis. Deze geeft de basis informatie terug. Een andere applicatie kan een uitgebreider verzoek doen.
Net als bij het maken van een database of programma vereist het opzetten van een API veel werk en tuning. Net als bij eerder genoemde technieken, is het verkeerd opzetten later een probleem als zaken niet modulair en consistent zijn. Het nadeel is zelfs nog groter, omdat er meerdere applicaties mee verbonden zijn. Het is geen één op één koppeling, maar de koppeling tussen applicatie en API is wel sterker dan bij bijvoorbeeld interfacing via een ESB.
“REST does not help you organize things. It forces you to use API supported by server-side library you are using. You can organize your application the same way (or better) when you are using non-REST approach. It all depends on how well you organize and document your application. REST will not magically make your application better.”
REST staat er ook om bekend dat het geen duidelijke definities biedt voor acties en foutcodes. Bijvoorbeeld wanneer je POST en PUT moet gebruiken. Buiten GET, POST, PUT en DELETE zijn er ook andere acties, zoals PATCH en TRACE, maar die zijn vaak niet geïmplementeerd en kan je dus ook niet zomaar gebruiken.
Ditzelfde geldt deels ook voor de HTPP code: “Consider, for example, when we might use the 200 OK response code. Should we use it to indicate the successful update of a record, or should we use 201 Created? It seems we really should use a code like 250 Updated but that code doesn’t exist. And can anyone out there explained to me what 417 Expectation failed really means?”
Doordat er niet een heel strikte standaard is, levert het opstellen en debuggen meer tijd op. Een standaard voor REST die steeds meer gebruikt wordt is OData (Open Data Protocol).
Een ander nadeel is dat een API als webservice weinig meer biedt dan het uitwisselen van data. Voor het loggen, bewerken, caching, bufferen enzovoorts is additionele tooling nodig, meestal in de vorm van een API Management platform.
API's zijn zeker niet alleen technische componenten. Het idee erachter is dat je een API als product beschouwd. In een bakkerij bijvoorbeeld heb je de bakkerij zelf waar taarten worden gebakken. Zie dit als "de applicatie". Voor het bakken zijn er natuurlijk allerei grondstoffen nodig. Het aanleveren van die grondstoffen en het logistieke proces hierachter is goed te vergelijken met traditionele integratie. Daar bevinden zich API's echter niet.
API's zijn eerder te vergelijken met de etalage van de winkel. Zie het als een lijst met daarop alle taarten die de bakkerij kan maken. Een klant loopt de winkel langs en ziet in de etalage allerlei taarten staan. Deze taarten (en ze hoeven niet eens echt te zijn) moeten er aantrekkelijk uit zien en overzichtelijk te zijn gepresenteerd.
Het is dus niet zoals traditionele integratie een achtegrondproces. Het is voor de consument. Iemand die een API gebruikt wordt daarom meestal "consumer" genoemd. Om deze redenen is het gebruikelijk om een API te ontwerpen als een product. Meerdere API endpoints moeten consistent en helder zijn voor degene die het gaan gebruiken. Bij REST API wordt dit helder door gebruik te maken van specificaties, zoals
- OpenAPI (tot versie 2.0 ook wel Swagger)
- RAML
- OData
Met behulp van deze specificaties kan de API worden ontworpen en vervolgens ook weer documentatie gegenereerd. Deze documentatie wordt vaak beschikbaar gesteld in een "Developer Portal".
Stel je wilt een groot feest geven en je wilt dat Anneke een aantal taarten maakt. Traditioneel zou je bellen of in de winkel afspreken welke taarten je nodig hebt. Tegenwoordig kan dit helemaal digitaal via de website (user interface) of API (data interface).
Ook bij integraties kwamen vaak projectleider, architecten en developers vaak fysiek bij elkaar voor de afstemming. Bij API' gaat alles digitaal. Een developer publiceert zijn API in het portaal. En andere developer logt in op het portal en onderzoekt de verschillende API's (de etalage). Vervolgens past hij zijn client programma hierop aan.
Op te merken is dat traditionele integratie hier wat flexibeler is. Je hebt namelijk meerdere punten waar je aanpassingen kan doen. Of in één van de applicatie of in de integratie. Bij API's is dit beperkter en ligt dit bij de consumer van de applicatie (maatwerk is vaak onwenselijk).
Samengevat is een API:
- Een digitaal product
- Consumer-oriented
- Self-service
Een API capability betekent dat een organisatie de verschillende aspecten van API's beheerst. Dit zijn enerzijds de verschillende technische componenten die samen een API (Management) Platform maken en anderzijds een "API-driven" benadering in het ontsluiten van functionaliteit.
Stel een fabriek maakt allerlei grondstoffen en benodigdheden voor bakkerijen. De fabriek kan op zoek gaan naar allerlei afnemers. Die afnemers willen natuurlijk weten wat voor type ingredienten en benodigheden zij verkopen we ze kosten. Dit kunnen bakkerijen zij, maar misschien ook groothandels die de productinformatie willen laten zien op hun website. Nu kan de fabriek met elke afnemer een integratie gaan maken, maar het kan ook één API ter beschikking stellen. Alle verschillende afnemers kunnen zo de informatie opvragen die ze willen en integreren in hun eigen systemen. Ook kunen ze API gebruiken om bestellingen te plaatsen.
Het mooie is dus dat er maar één API voor alle afnemers is. Daarnaast is het mooi dat afnemers het kunnen gebruiken zonder tussenkomst van de fabriek. Sterker nog de fabriek hoeft helemaal niets van de afnemer te weten. Zo krijgt de fabriek plotseling orders vanuit heel andere regio's. Uiteraard is het soms vanuit beveiligingsperspectief nodig om verschillende delen van de API specifiek toegang te verlenen.
De API van de fabriek is dus echt een onderdeel van hun product. Door API's als producten te zien werkt data uitwisselen anders. Integraties zijn meer aanbod gedreven componenten, terwijl API's meer vraag-gedreven componenten zijn. Het bedrijfsmodel en de best practices rondom het gebruik van API's worden ook wel API-Economy genoemd.
Als API's een nieuwe standaard wordt (zelfs binnen organisaties) kunnen organisaties en afdelingen makkelijker informatie uitwisselen. Deze vereenvoudiging van de toegang tot informatie, maakt het mogelijk om allerlei nieuwe business modellen hier op te baseren. Vanuit marketing termen wordt ook wel van "enablement" door API's gesproken. Het idee is door een mix en match van allerlei API's, zodat verschillende producten en diensten snel te kunnen ontwikkelen en via veel verschillende kanalen te ontsluiten.
Uiteraard is het technisch niet zo eenvoudig als in business termen is te vatten. Zo zijn er verschillende type API's en allerlei technische componenten om de API economie een beetje te laten draaien.
Vanuit de verschillende behoeftes om API's te consumeren, zijn er verschillende type API's ontstaan. De verschillen in behoefte ontstaan door wie en waarmee een API wordt aangeroepen.
- Wordt een API intern of extern gebruikt?
- Wordt een API door systemen of in processen gebruikt?
- Wordt een API door mobiele app of een webapplicatie gebruikt?
Vanuit deze behoeftes worden er drie lagen onderscheden:
- System API's
Deze API's ontsluiten zogenoemde System of Records, denk aan ERP en CRM systemen. Dit is het laagste niveau. Vaak zijn deze API's alleen intern te benaderen.
- Process API's
De process API's communiceren met meerdere system API's om daaruit een business process te bouwen.
- Experience API's
Een laag boven op de Process API's die API's aanbieden voor een specieke "channel". Denk aan mobile of desktop.
Deze type-terminologie komt van Mulesoft, maar is inmiddels ook door andere aanbieders overgenomen.
API Management tools bevatten ook een API Gateway. Deze kwam al eerder tegen in het hoofdstuk "Technische integratie". Een gateway is een laag tussen de API’s die voor generieke ontsluiting van de data zorgt. Een API gateway bevindt zich tussen clients en services. Het fungeert als een omgekeerde proxy, routerings aanvragen van clients naar Services.
De gateway zorgt ervoor dat een organisatie zelf de regie kan houden, ook al zijn er meerdere API’s van externe leveranciers of standaard applicaties waar geen invloed op is. Een API gateway wordt geconfigureerd in de API Manager. Hierin kan je bijvoorbeeld bepalen: Wie krijgt toegang tot de API, Wat gebeurt er als er iets mis gaat? en Hoe regel je load balancing? Ook logging, versiebeheer en gebruiksstatistieken worden via de API Gateway in de API Manager bijgehouden.
Er zijn meerdere manieren om een API-laag op te bouwen. Zijn er maar enkele API's dan kunnen de API's elkaar gewoon rechtstreeks aanroepen. Zijn er meer API's dan is een stuk beheer noodzakelijk. Het beheer, het API Management, regelt alle zaken rondom de API. Denk hierbij aan publicatie, beveiliging en beheer:
“API management is the process of creating and publishing API’s, enforcing their usage policies, controlling access, nurturing the subscriber community, and collecting and analyzing usage statistics.” (Wikipedia)
Vrijwel alle grote software leveranciers, zoals Microsoft, Google en IBM bieden een API Management product aan. Bekende open source spelers op dit gebied zijn Mule, 3Scale, WS02, TYK en Kong.
API Management zorgt ervoor dat je de regie in het beheer op je interfacing behoudt. Vanuit technisch en beheer oogpunt is het duidelijk waarom je API Management nodig hebt. Je moet immers je omgeving kunnen schalen, maar ook inzichtelijk houden als er iets mis gaat. Er zijn ook nog andere redenen voor API management die in het volgende hoofdstuk aan bod komen.
De belangrijkste componenten voor het uitvoeren van API Management zijn:
- API's (programmatuur)
- API Designer
- API Tester
- API Manager
- API Gateway
- API Portal
In het ontwikkelproces van API's worden de verschillende componenten gebruikt. Eerst de API ontworpen met behulp van de API Designer. Hier komt met name de product-orientatie vandaan. Is de API consistent, gestandaardiseerd en duidelijk? Vervolgens wordt de API geÏmplementeerd in een applicatie. Daarna wordt de API getest (Ziet de etalage er goed uit?). Tenslotte wordt de API technisch ontsloten via een API Gateway en functioneel via een developer portal. De configuratie van de gateway en portal gebeurt in een API manager.
Als je met API’s gaat werken zijn er twee belangrijke vragen:
- Hoe zijn de API’s ontworpen?
- Hoe worden de API’s beheerd?
In het begin liggen deze twee zaken heel dicht bij elkaar. Met name bij maatwerkapplicaties, omdat daar makkelijker afspraken over de inrichting kunnen worden gemaakt. Zodra er meerdere API’s ontstaan en er meerdere applicaties op worden aangesloten, wordt het management ervan steeds belangrijker.
De API Manager zorgt voor
- Traffic management
- Route requests
- Rate limiting
- Throttling
- Authentication
- Exception handling
- API Management
- Policies
- SLA
- Contract Management
- API Versioning
- Security & Governance
- Encryptie/Certificates (Mutual TLS)
- Edge protectiong (Bijvoorbeeld DDoS aanvallen)
- Audit logs
- Analytics & Monitoring
- Troubleshoot & Monitoring
- Function tests
- Logging & Tracing
- Alerts & Notifications
- Combineren van API's
- Interactive API docs
- User Engagement
De API manager configureert de API Gateway. Deze zorgt voor al het data verkeer en data de API Consumer en Provider van elkaar ontkoppelt zijn. Dit staat bekend als het HATEOAS principe (https://en.wikipedia.org/wiki/HATEOAS).
De voordelen en nadelen van een API zijn in grote mate gelijk aan die van middleware (MQ/ESB). Toch zijn ze conceptueel verschillend. Middleware richt zich op een éénduidige manier van het uitwisselen van berichten. Deze worden in de ESB aangepast aan de ontvanger. Dit gebeurt zowel op inhoudelijk (bericht formaat) als op technisch niveau (protocol, eventueel via adaptoren).
Middleware (ESB) voorbeeld
Bij een API is het internet het technische transport. Bij een update zal de aanbieder van de API (webserivce) de afhandeling verzorgen en bij het opvragen zal de ontvanger dit doen. API Management (Gateway) voorbeeld
Dit verschuift ook de manier van interfacen:
“Over the last ten to fifteen years, most of the problems we were trying to solve involved connecting system A to system B. This is integration. The problems most companies are trying to solve today involve time to market for new ideas, and reaching and connecting new devices, new partners, and new market segments. We need more agility to react to fast-changing conditions. We need visibility. These aren't integration problems. But, because we have been solving integration problems for years, it is almost muscle memory to try and view today's exposure and consumption problems as yesterday's integration problems. If you focus on integration, you will sacrifice agility and consumability.”
De verwarring met ESB komt vaak ook omdat er voor API management tools/gateways nodig zijn die ook als een stukje middleware fungeren:
The reason you're getting the concepts jumbled up is that the vendors are selling them in a package. But they are definitely separate concepts. An API Gateway provides a central access point for managing, monitoring, and securing access to your publicly exposed web services. It would also allow you to consolidate services across disparate endpoints as if they were all coming from a single host. For example let's say you had ten different service endpoints that were all part of a single "suite" of services. Rather than informing consumers of your service to use service1.yourcompany.com for one service and service2.yourcompany.com for another and so forth, you can instead have them all point to api.yourcompany.com/service1 or api.yourcompany.com/service2 and the gateway would be responsible for redirecting the requests to the appropriate endpoints.
An ESB is an internal "Bus" that allows applications and services to communicate with each other in an uncoupled fashion. All applications can hook into the bus and they can receive any message that interests them when published by another application. They can also publish their own messages that another application may listen for and respond to. The applications are not responsible for connecting with each other directly, they publish their messages to the bus and all interested parties listen and react. Logically the API Gateway is not a replacement for an ESB but rather an enhancement for a service oriented architecture. differences-between-api-gateways-and-esbs