WSO2 API Manager 4.0.0
Une plateforme unique pour gérer vos APIs, Intégrer vos applications, et traiter vos évènements.
Après 2,5 ans, la version 3 de WSO2 API Manger tire sa révérence pour laisser la place à la version 4. Et le moins que l’on puisse dire c’est que l’éditeur n’a pas chômé! C’est du lourd, du très lourd! Lisez bien jusqu’à la fin ;)
Si l’on devait résumer les points marquant de cette version:
- Fusion de WSO2 API Manager avec WSO2 Enterprise Integrator
- Exposition d’APIs de streaming avec le support du standard AsyncAPI
- Ajout d’un système de révision des configurations d’API
- Support du multi-domaine pour les gateway
- Fusion de certains profils de déploiement pour le mode distribué
- Changement technologique pour les Microgateway
- WSO2 API Analytics remonté dans le cloud
De l’exposition à l’intégration de vos APIs
Absorption de WSO2 Enterprise Integrator
Le premier changement majeur concerne le périmètre du produit. WSO2 souhaite développer sous la marque WSO2 API Manager l’ensemble de sa stack technologique d’intégration. Exit, donc, WSO2 Enterprise Integrator. WSO2 Micro Integrator (ESB) et WSO2 Streaming Integrator (DS/CEP) seront maintenant distribués à travers le produit WSO2 API Manager.
Catalogue de services
Pour faciliter la gouvernance de l’ensemble, WSO2 ajoute une fonctionnalité de catalogue de service. A chaque fois que vous déployez un flux, sur WSO2 Micro Integrator ou WSO2 Streaming Integrator, celui-ci pourra être automatiquement déclaré au sein du catalogue de service. Et à partir du catalogue vous pourrez d’un simple clique exposer celui-ci à travers une API sur l’API Gateway.
Architecture de l’API Manager
Profils
Les profils de lancement du produit évoluent. Exit key-manager, publisher, devportal et traffic manager.
Il n’y aura maintenant plus que 4 profils possibles :
- default: tous les composants
- gateway-worker: uniquement la gateway
- controle-plane: tous les composants sauf la gateway (traffic-manager désactivable par configuration)
- traffic-manager: traffic manager seul
WSO2 a pensé aux installations existantes en ne supprimant pas de manière abrupte les anciens profils mais en les dépréciant. Vous pouvez les utiliser en ajoutant *-deprecated à la fin des noms des anciens profils.
Déploiement des APIs par évènement
Introduit en 3.2.0, la publication des APIs est maintenant réalisée par défaut sur un modèle évènementiel. Plus concrètement, à chaque fois que vous publiez une API, un évènement est envoyé dans une file du broker de message embarqué. Les différentes gateway, abonnées à cette file, liront l’évènement et iront charger la nouvelle configuration d’API au sein de la base de données.
Le premier intérêt de ce modèle est de pouvoir se passer d’un NFS pour synchroniser vos différentes gateway. Et les équipes WSO2, ayant pensé à tout, ils ont ajouté une étape de synchronisation des configurations avec la base de donnée au démarrage de chaque instance.
Le deuxième intérêt c’est que WSO2 en a profité, pour n’utiliser que des tokens JWT depuis la 3.2.0, et pour remonter la gestion du contrôle d’accès aux apis directement au sein de la gateway. Résultat, en dehors de requêtes d’introspection des tokens, il n’y a plus de requêtes entre gateway et key manager ce qui permet de faire sauter le ratio de 2 gateway pour un key manager qui existait depuis le début du produit. D’où la révision de la liste des profils réalisées par l’éditeur.
Synchronisation des politiques de quota
De même il est à noter que la gestion des politiques de quota est elle aussi remonté en base de données ce qui permet également de se passer de NFS dans ce contexte. Il ne restera plus que la problématique des User Stores secondaires à traiter! ;)
Suppression du proxy Oauth2 au sein du composant gateway
Depuis toujours nous avions l’habitude de requéter l’endpoint Oauth2, pour générer nos tokens, à travers la Gateway. La gateway, en réalité, ne faisait que passe plat vers le Key Manager. Avec la possibilité d’utiliser plusieurs Key Manager externes, depuis la 3.2.0, ce fonctionnement devenait étrange. WSO2 a donc fait le choix de supprimer ce proxy. Il vous faudra dorénavant directement interroger le Key Manager.
APIs évènementielles
Standards de streaming
WSO2 API Manager étend ses capacités d’exposition en intégrant le support des APIs de streaming.
Websocket
Il gérait déjà le Websocket vous me direz?! Oui, mais de manière très limitée, il ne faisait que du proxy. Maintenant vous allez pouvoir gérer les différents canaux, les mapper aux backends et gérer leurs droits de manière individuelle.
WebSub/WebHook
Le standard WebSup (anciennement PubSubHubbub) permettra à une application tierce d’enregistrer un endpoint pour être notifié d’évènements via des requêtes réalisées en POST par l’API Manager.
Server-Sent Events (SSE)
Le standard SSE permettra à une application tierce de recevoir des évènements à travers une connexion HTTP déjà existante. WSO2 API Manager sera en capacité de renvoyer, sur demande, les messages non reçus par le client après une erreur de transport.
Standard de définition AsyncAPI
AsyncAPI, ou A2S pour les intimes c’est un nouveau standard de définition d’interface pour les APIs Asynchrones (créé en 2017 par la société Hitch). Sa spécification est fortement inspirée, et en partie compatible, avec la spécification OpenAPI.
Ce standard vise à remplir un manque de standardisation et de définition des messages échangés criant actuellement dans ce domaine. Contrairement à OpenAPI qui décrit uniquement des interfaces HTTP, AsyncAPI reflète l’hétérogénéité du domaine en permettant la description multi-protocolaire (MQTT, Kafka, Websockets, etc.)
WSO2 API Manager intègre maintenant nativement ce standard pour définir les points d’API évènementielles avec bien sûr tout son outillage.
Gestion des révisions d’API
WSO2 API Manager gère depuis ses débuts le versionnement des APIs. Quand on parle de version d’une API on se réfère à une évolution de son contrat d’interface. Mais qu’en est-il quand on souhaite uniquement faire évoluer ses métadonnées ou sa documentation par exemple? Jusqu’à présent on écrasait les précédentes données à chaque édition et celles-ci étaient disponibles immédiatement.
Pour répondre à ce biais WSO2 vient d’ajouter la notion de révision sur une version d’API. Chaque fois que vous le jugez nécessaire vous pouvez enregistrer l’état actuel de l’API. Vous pouvez déployer explicitement une révision donnée de cette API et si elle ne vous plait pas vous pouvez restaurer la révision précédente. (WSO2 a limité à 5 révisions par API cette fonctionnalité)
Microgateway, Choreo Connect
Les microgateway change de base technologique, elles ne seront plus basées sur le langage Ballerina mais sur le proxy Envoy.
Elles pourront être utilisées en mode autonome, comme actuellement.
Elles pourront en plus être pilotées à distance par l’outil en ligne de commande API Controler ou le Publisher de l’API Manager pour déployer à chaud des APIs.
Il sera également possible de lui demander de réaliser de la découverte de service auprès de Consul.
L’éditeur s’est engagé à travailler sur les fonctionnalités manquantes dans les prochaines versions. À savoir : support des APIs de streaming, support des APIs GraphQL, support des API Products, authentification mutuelle/basique/clé d’api, médiation des messages et quota de bande passante.
Gestion de noms de domaine virtuelle
WSO2 API Manager permettait jusqu’à présent de créer des grappes de gateway, ou Gateway environnement, qui exposaient des APIs (de production, de sandbox ou hybride) sur un même nom de domaine.
WSO2 vient d’ajouter un nouveau niveau d’abstraction pour permettre d’ajouter des vHosts. C’est-à-dire qu’une même gateway peut exposer des APIs avec plusieurs base URL différentes (nom de domaine + path). Ainsi vous pourrez exposer à travers une même gateway 2 APIs : la première sur un domaine vhost1.com et la deuxième sur le domaine vhost2.com.
API Analytics dans le cloud
La partie anaytics du produit fait peau neuve et … migre sur le cloud! De nombreux utilisateurs avaient du mal à gérer la volumétrie d’évènement, et WSO2 souhaitait pouvoir mieux gérer l’évolution de ce composant.
C’est sur la nouvelle plateforme Choreo, de l’éditeur, qu’elle est hébergée. Celle-ci est redondée, régionalisée et garantit la confidentialité des données transmises.
Autres Améliorations relatives à l’exposition d’API
OAuth2 Mutual TLS
WSO2 API Manager implémente maintenant la RFC 8705. Ce sous standard OAuth2 permet à une application de s’authentifier par certificat plutôt que par secret. Il renforce également la sécurité en liant les access tokens générés à ce même certificat. À chaque appel d’API le consommateur devra fournir un access token et son certificat rendant le vol d’access token presque impossible.
Connecteurs vers de nouveaux Key Manager externes
Depuis l’apparition de la fonctionnalité de Key Manager externe, dans la version 3.2.0, WSO2 travaille d’arrache pieds pour fournir des connecteurs avec les serveurs d’autorisation les plus standards sur le marché. A sa sortie WSO2 API Manager intégrait des connecteurs pour WSO2 Identity Server, Keycloak et Okta. Il a ajouté progressivement depuis des connecteurs pour Forgerock, Ping Federate et Auth0.
Génération de Collection Postman
Beaucoup de développeurs utilisent Postman dans leurs tâches quotidiennes. Pour faciliter leur travail WSO2 génère maintenant automatiquement un fichier de définition de collection Postman téléchargeable pour les API RESTful et GraphQL.
Gestion des commentaires
La gestion de commentaire s’enrichit enfin de 2 fonctionnalités majeures :
- la possibilité de répondre à un commentaire
- la possibilité de les modérer directement depuis le publisher
Liens communautaires
Partage d’une API à travers un réseau social
Le partage d’API via les réseaux sociaux, supprimé en version 3.0.0 est ré-introduit dans cette nouvelle version avec des liens de partage Facebook, Twitter, et Reddit.
Exposition des liens communautaires liés à une API
Si vous souhaitez mettre un lien vers le dépôt Github de votre API ou un canal de support Slack c’est maintenant possible.
Autres Améliorations relatives à l’intégration
Ré-écriture du connecteur de fichier
WSO2 a changé complètement l’implémentation de son connecteur de fichier. Toujours basé sur Apache Commons VFS il bénéficie d’une configuration plus simple, de messages d’erreurs plus clairs et de performances améliorées par l’usage de cache. Il permet également en plus des fonctionnalités pré-existantes le verrouillage de fichier, la lecture d’une section précise d’un fichier (ex: ligne 10 à ligne 50) et l’écriture à la suite du contenu existant.
Intégration avec Hashicorp Vault
Vous utilisez Hashicorp? Bonne nouvelle pour vous il est maintenant possible d’utiliser Hashicorp Vault en remplacement du vault embarqué, WSO2 Secured Vault.
Moteur de template FreeMarker
le médiateur PayloadFactory supporte maintenant le moteur de template FreeMarker vous permettant de définir facilement des structures complexes.
<payloadFactory media-type="json" template-type="freemarker">
<format>
<![CDATA[{
"Name": "${payload.user.first_name} ${payload.user.last_name}",
"Age": ${payload.user.age},
"Address": "${payload.user.location.city},${payload.user.location.state.@code}" }]]>
</format>
<args/>
</payloadFactory>Connexion à un Endpoint protégé par OAuth2
Jusqu’à présent pour intégrer un service protégé par OAuth2 vous deviez réaliser une pré-séquence qui allait récupérer un access token pour ensuite pouvoir l’utiliser. C’est maintenant terminé. WSO2 a ajouté le support du standard OAuth2 au sein même de la définition d’un endpoint.
<endpoint name="FoodEP" xmlns="http://ws.apache.org/ns/synapse">
<http method="get" uri-template="http://localhost:9192/service/foodservice">
<authentication>
<oauth>
<clientCredentials>
<clientId>K2RbnGP7VS</clientId> <clientSecret>9zLrZAYR5b</clientSecret> <tokenUrl>http://localhost:8678/token</tokenUrl>
</clientCredentials>
</oauth>
</authentication>
</http>
</endpoint>Call depuis et vers une Property
Il est maintenant possible de dire au mediateur Call d’utiliser une requête définie dans une propriété et d’écrire la réponse de l’appel à un endpoint dans une autre propriété.
<inSequence>
<property name= "SOURCE" expression="$body//INCOMING" type="OM"/>
<log level="custom">
<property name="log" expression="$ctx:SOURCE"/>
</log>
<property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>
<call>
<endpoint name="Sample">
<address uri="BACKEND_URL"></address>
</endpoint>
<source contentType="application/xml" type="property">SOURCE</source>
<target type="property">TARGET</target>
</call>
<log level="custom">
<property name="TARGET PAYLOAD" expression="$ctx:TARGET"/> </log>
<respond/>
</inSequence>Data source Cassandra
En plus des traditionnelles bases de données JDBC, des fichiers CSV et de MongoDB il est maintenant possible d’exposer sous forme de service les données en provenance d’une base Cassandra.
Autres Améliorations relatives au streaming
Support du standard Server-Side-Events (SSE)
Pour permettre une intégration de bout en bout WSO2 à ajouter le support du standard SSE à WSO2 Streaming Integrator.
Génération de contrat AsyncAPI
WSO2 Streaming Integrator est maintenant en capacité de générer automatiquement un contrat AsyncAPI pour les protocoles Websocket, WebSub et SSE. Et bien sûr, il est capable de réaliser son enregistrement au sein du nouveau catalogue de service.
Change Data Capture d’opérations multiple
Jusqu’à présent il n’était possible de capturer qu’un type d’opération quand vous écoutiez votre serveur de base de données. Cette limite est maintenant tombée.
Choreo
Mais au fait c’est quoi Choreo!? C’est le plus gros spoiler de WSO2 depuis longtemps pardi!
Depuis plusieurs mois WSO2 travaille sur la mise en place d’une solution IPaaS. Ouverte en bêta privé en février et en bêta public aujourd’hui elle va vous permettre d’intégrer vos applications et d’exposer vos APIs dans une offre As-A-Service.
Technologiquement cette plateforme est hébergée sur Microsoft Azure, repose sur Ballerina Swan Lake et permet de déployer des conteneurs à la volée.
Choreo remplacera courant 2022 les offres SaaS actuelles ,WSO2 API Cloud et WSO2 Integration Cloud, hébergées sur Amazon AWS.
