Veel organisaties die een digitale transformatie ondergaan, hebben een dringende behoefte om hun applicaties, gegevens en apparaten met elkaar te verbinden. Vaak bestaat hun pad naar succes uit het overstappen op een API-geleide integratiestrategie. API’s vervullen een specifieke rol binnen de integratiebenadering van een organisatie. Ze maken het mogelijk om gegevens uit systemen te ontsluiten, gegevens in processen samen te voegen of een ervaring te leveren. Gebeurtenisgestuurde API’s maken deel uit van een technologiemix die een organisatie helpt een concurrentievoordeel te behalen met realtime integratie. In deze blogpost bespreken we hoe het Anypoint Platform van MuleSoft ondersteuning biedt voor gebeurtenisgestuurde architectuur en hoe het wordt gebruikt in combinatie met de API-gestuurde connectiviteitsaanpak.
Dimensies van evenementen
- Programmatisch: voornamelijk programmatische communicatiebenadering van aard, d.w.z. bedoeld voor communicatie tussen applicatiecomponenten.
- Betekenis: een gebeurtenis beschrijft een statuswijziging die heeft plaatsgevonden in een toepassingscomponent, die optreedt als de gebeurtenisproducent.
- Dynamische aard: Een gebeurtenis beschrijft iets dat al is gebeurd.
- Granulariteit: een gebeurtenis is meestal bedoeld voor één goed gedefinieerde statuswijziging.
- Synchroniciteit: Gebeurtenissen worden asynchroon uitgewisseld en daardoor worden de gebeurtenisproducent en de consument in de tijd ontkoppeld.
- Communicatiepad: Gebeurtenissen worden door een gebeurtenisproducent naar een bestemming gestuurd voor b.v. wachtrij, onderwerp, berichtuitwisseling, afhankelijk van het berichtenparadigma, en worden vervolgens ontvangen door gebeurtenisconsumenten van die bestemming.
- Broker: Voor het uitwisselen van evenementen is een berichtenmakelaar nodig, zoals of b.v. Anypoint MQ, Kafka, ActiveMQ of RabbitMQ.
- Contract: Het contract voor een evenement is de combinatie van bestemming en type evenement (gegevens) en kan worden beschreven door een AsyncAPI-definitie.
Gebeurtenis gestuurde architectuur en API-geleide connectiviteit werken samen
MuleSoft definieert API-geleide connectiviteit door de lens van een drieledige benadering. Deze drie lagen bestaan uit ervarings-API’s, proces-API’s en systeem-API’s.
Hoewel applicatiecomponenten die gebeurtenissen uitwisselen op dezelfde manier kunnen worden georganiseerd, is dit echter geen inherent onderdeel van een gebeurtenis gestuurde architectuur.
API-geleide connectiviteit beperkt communicatiepatronen volgens de drie niveaus (in wezen van boven naar beneden), terwijl applicatiecomponenten die gebeurtenissen uitwisselen niet aan dezelfde communicatiepatroon beperkingen hoeven te voldoen.
Een gebeurtenis gestuurde architectuur vereist een message broker als een extra component van de technologie-architectuur, waarbij alle applicatiecomponenten, die gebeurtenissen uitwisselen, het eens moeten worden over dezelfde message broker.
De API-gecentreerde activa die zijn gepubliceerd voor zelfbedieningsconsumptie definiëren API-geleide connectiviteit in applicatienetwerken. API-implementaties hebben doorgaans goed gedefinieerde statische afhankelijkheden van andere API’s of backend-systemen.
Laten we eens kijken naar een paar scenario’s die elementen uit gebeurtenisgestuurde architectuur nodig hebben.
- Integratie met SaaS-applicaties: ze zijn sterk afhankelijk van benaderingen van een gebeurtenisgestuurde architectuur om hoge beschikbaarheid en schaalbaarheid te garanderen (bijv. gebeurtenisgestuurde architectuur op het Salesforce Customer 360 Platform).
- Internet of Things: het enorme aantal gebeurtenissen dat vanaf apparaten wordt gestreamd, moet in realtime en op schaal toegankelijk zijn, wat synchrone API’s voor verzoeken en antwoorden alleen onredelijk maakt.
- Fouttolerantie: een systeem luistert naar meldingen wanneer transacties of bestellingen in een eCommerce-systeem zijn geannuleerd of mislukt.
- Vermijd polling: Verwerk meldingen (bijv. een bestelling is bijgewerkt), beslis welke actie moet worden ondernomen en stuur het juiste antwoord naar een backend-systeem in plaats van constant te zoeken naar wijzigingen.
- Verouderde systemen: ze moeten de meldingen verwerken, maar hebben problemen met de betrouwbaarheid.
Het onderstaande voorbeeld toont het gebruik van de Kafka-connector die wordt gebruikt voor het consumeren en produceren van gebeurtenissen voor het behandelen van onderwerpen (gebeurtenisgestuurd) terwijl de API-geleide connectiviteitsbenadering wordt gevolgd.
De voordelen van het combineren van gebeurtenisgestuurde architectuur met API-geleide connectiviteit
Met een gecombineerde aanpak kunt u proces- en systeem-API’s hergebruiken voor toekomstige gebruiksscenario’s zonder transformatielogica en connectiviteit met backend-systemen te hoeven herschrijven.
Bovendien kunt u berichtenwachtrijen gebruiken om geen berichtverlies te garanderen en de betrouwbaarheid en robuustheid van uw IT-applicaties te vergroten.
Er kan een ander hulpmiddel worden toegevoegd om de situaties te dekken waarin synchrone API’s voor verzoeken en antwoorden mogelijk niet optimaal zijn.
Op zoek naar API-gestuurde inkomsten?
Onze 25+ jaar integratie-ervaring in projecten binnen elke denkbare sector, gecombineerd met een sterke samenwerking met MuleSoft, stellen ons in staat uw organisatie door elke API-gerelateerde uitdaging te begeleiden. Op zoek naar hulp? Neem gerust contact met ons op, dan kijken we hoe we elkaar kunnen helpen.