Communication Inter-Services : API REST, Messagerie et Événements

Dans le monde des architectures microservices, les services sont conçus pour être autonomes et faiblement couplés. Cependant, pour qu'une application distribuée fonctionne comme un tout cohérent, ces services doivent inévitablement communiquer entre eux. La manière dont ils échangent des informations est cruciale pour la performance, la résilience, la scalabilité et la maintenabilité de l'ensemble du système.

Cette leçon explorera les stratégies principales de communication inter-services, en détaillant leurs principes, leurs avantages, leurs inconvénients et leurs cas d'utilisation spécifiques. Nous nous concentrerons sur l'API REST pour la communication synchrone, et sur les mécanismes de messagerie et d'événements pour la communication asynchrone.

1. Introduction à la Communication Inter-Services

Une architecture microservices décompose une application monolithique en un ensemble de services plus petits, indépendants et faiblement couplés, chacun responsable d'une capacité métier spécifique. Pour réaliser des fonctionnalités complexes, ces services doivent souvent collaborer en échangeant des données ou en se notifiant de changements d'état.

Les objectifs principaux de la communication inter-services sont :

• Échange de Données : Un service a besoin d'informations gérées par un autre service.
• Coordination des Flux : Des actions dans un service déclenchent des processus dans d'autres services.
• Propagation d'État : Maintenir la cohérence des données à travers différents services.
• Résilience : Assurer que le système continue de fonctionner même si un service est temporairement indisponible.

Il existe deux paradigmes de communication principaux :

• Synchrone : L'émetteur attend une réponse immédiate du récepteur. Si le récepteur est lent ou indisponible, l'émetteur est bloqué ou rencontre une erreur.
• Asynchrone : L'émetteur envoie un message et ne s'attend pas à une réponse immédiate. Le récepteur traitera le message quand il sera prêt. Cela permet une meilleure résilience et un découplage plus important.

Nous allons maintenant plonger dans les implémentations concrètes de ces paradigmes.

2. API REST : La Communication Synchrone Par Excellence

L'API REST (Representational State Transfer) est le style d'architecture le plus répandu pour la communication synchrone dans les microservices. Elle s'appuie sur le protocole HTTP et les principes de conception Web pour permettre aux services de s'appeler mutuellement via des requêtes/réponses.

2.1 Principes de REST

• Ressources : Tout est considéré comme une ressource (ex: un utilisateur, une commande, un produit), identifiée par une URL unique (URI).
• Opérations Standard : Les méthodes HTTP (GET, POST, PUT, DELETE, PATCH) sont utilisées pour manipuler ces ressources.
  • GET : Récupérer une ressource.
  • POST : Créer une nouvelle ressource.
  • PUT : Mettre à jour (remplacer) une ressource existante.
  • DELETE : Supprimer une ressource.
  • PATCH : Mettre à jour partiellement une ressource.
• Communication Sans État (Stateless) : Chaque requête du client vers le serveur doit contenir toutes les informations nécessaires à la compréhension de la requête. Le serveur ne stocke aucune information de session entre les requêtes.
• Architecture Client-Serveur : Le client et le serveur sont découplés.
• Cacheable : Les réponses peuvent être mises en cache pour améliorer les performances.

2.2 Avantages de l'API REST

• Simplicité et Familiarité : Basée sur HTTP, largement comprise et supportée par de nombreux outils et frameworks.
• Facilité de Débogage : Les requêtes et réponses HTTP sont faciles à inspecter.
• Interfaçage Direct : Permet une interaction immédiate et directe entre services.
• Large Adoption : Grande communauté, abondance de bibliothèques et de ressources.

2.3 Inconvénients de l'API REST

• Couplage Fort (Tight Coupling) : L'appelant doit connaître l'adresse et l'interface du service appelé. Si le service appelé est indisponible, l'appelant est bloqué.
• Latence : Chaque appel HTTP entraîne une latence réseau. Si un service doit appeler plusieurs autres services séquentiellement, cela peut devenir un goulot d'étranglement.
• Gestion des Erreurs et des Temps Morts : Nécessite des mécanismes robustes de retry (réessai), de timeout (délai d'attente) et de circuit breaker (coupe-circuit) pour gérer les pannes réseau ou de service.
• Versionnage : Gérer les évolutions d'API peut être complexe et nécessiter des stratégies de versionnage (/v1/, /v2/).

2.4 Cas d'Utilisation Typiques

• Requêtes Synchrones : Quand un service a besoin d'une réponse immédiate d'un autre service pour continuer son exécution (ex: un service de commande a besoin de vérifier la disponibilité d'un produit auprès d'un service de stock).
• Opérations CRUD : Création, lecture, mise à jour, suppression de ressources.
• Faible Volume de Communication : Pour des interactions ponctuelles ou ne nécessitant pas une scalabilité extrême de la communication.

2.5 Exemple de Code : Service de Produits et Consommateur

Imaginons un Service de Commande qui a besoin de récupérer les détails d'un produit depuis un Service de Produits.

# product_service.py (Service de Produits)
from flask import Flask, jsonify

app = Flask(__name__)

products_db = {
    "P001": {"name": "Laptop Pro", "price": 1200.00, "stock": 50},
    "P002": {"name": "Mouse Ergo", "price": 25.50, "stock": 200}
}

@app.route('/products/<product_id>', methods=['GET'])
def get_product(product_id):
    product = products_db.get(product_id)
    if product:
        return jsonify(product), 200
    return jsonify({"error": "Product not found"}), 404

if __name__ == '__main__':
    # Lance le service sur http://127.0.0.1:5000
    app.run(port=5000)

Pour exécuter ce service, enregistrez le code ci-dessus sous product_service.py et lancez-le avec python product_service.py.

# order_service_consumer.py (Service de Commande)
import requests

def get_product_details(product_id):
    """
    Récupère les détails d'un produit via l'API REST du service de produits.
    """
    product_service_url = f"http://127.0.0.1:5000/products/{product_id}"
    try:
        response = requests.get(product_service_url, timeout=5) # Timeout de 5 secondes
        response.raise_for_status() # Lève une exception pour les codes d'erreur HTTP (4xx ou 5xx)
        return response.json()
    except requests.exceptions.HTTPError as err:
        print(f"HTTP error occurred: {err} - Status Code: {err.response.status_code}")
        return None
    except requests.exceptions.ConnectionError as err:
        print(f"Connection error occurred: {err} - Product Service might be down.")
        return None
    except requests.exceptions.Timeout as err:
        print(f"Timeout occurred: {err} - Product Service took too long to respond.")
        return None
    except requests.exceptions.RequestException as err:
        print(f"An unexpected error occurred: {err}")
        return None

if __name__ == '__main__':
    product_id = "P001"
    details = get_product_details(product_id)
    if details:
        print(f"Détails du produit '{product_id}': {details}")
    else:
        print(f"Impossible de récupérer les détails pour le produit '{product_id}'.")

    product_id_not_found = "P999"
    details_not_found = get_product_details(product_id_not_found)
    if not details_not_found:
        print(f"Tentative de récupération d'un produit inexistant '{product_id_not_found}' a échoué comme prévu.")

Pour exécuter le consommateur, enregistrez le code ci-dessus sous order_service_consumer.py et lancez-le avec python order_service_consumer.py après avoir démarré le service de produits.

Cet exemple montre comment le order_service_consumer effectue une requête GET synchrone au product_service pour obtenir des informations. Il inclut une gestion basique des erreurs pour les problèmes réseau ou serveur.

3. Messagerie : La Communication Asynchrone par File d'Attente

La messagerie, souvent mise en œuvre via des "message brokers" (courtiers de messages) comme RabbitMQ, Apache Kafka, ou Amazon SQS, permet une communication asynchrone et découplée entre les services. Au lieu d'appeler directement un autre service, un service producteur envoie un message à une file d'attente (queue), et un ou plusieurs services consommateurs peuvent récupérer et traiter ce message ultérieurement.

3.1 Principes de la Messagerie

• Producteurs (Producers) : Services qui créent et envoient des messages au courtier de messages.
• Consommateurs (Consumers) : Services qui se connectent au courtier de messages pour lire et traiter les messages.
• Files d'Attente (Queues) : Tampons où les messages sont stockés temporairement jusqu'à ce qu'ils soient consommés.
• Message Broker : Le serveur intermédiaire qui gère les files d'attente, l'acheminement des messages et assure leur persistance.

3.2 Avantages de la Messagerie

• Découplage Fort : Le producteur n'a pas besoin de connaître l'existence ou la disponibilité du consommateur. Il envoie simplement le message et passe à autre chose.
• Résilience Accrue : Si un consommateur est en panne, les messages s'accumulent dans la file d'attente et seront traités une fois le consommateur de nouveau disponible. Le producteur n'est pas affecté.
• Scalabilité : Plusieurs consommateurs peuvent lire à partir de la même file d'attente, permettant le traitement parallèle des messages et la montée en charge.
• Gestion de la Charge (Load Balancing/Back Pressure) : Les courtiers de messages peuvent répartir les messages entre les consommateurs disponibles. Si les consommateurs sont surchargés, les messages restent dans la file d'attente, évitant la saturation.
• Persistance des Messages : Les messages peuvent être stockés de manière durable sur disque pour résister aux pannes du courtier lui-même.

3.3 Inconvénients de la Messagerie

• Complexité Accrue : Ajout d'une nouvelle composante (le message broker) à l'architecture, ce qui augmente la complexité opérationnelle et de développement.
• Latence (Éventuelle) : Le traitement n'est pas immédiat. C'est de l'asynchrone, ce qui implique une consistance éventuelle.
• Débogage Plus Difficile : Les flux de messages sont moins directs que les appels REST.
• Ordonnancement et Idempotence : Assurer l'ordre des messages et gérer les traitements idempotents (traiter un message plusieurs fois ne produit pas d'effets secondaires indésirables) peut être un défi.

3.4 Cas d'Utilisation Typiques

• Tâches de Longue Durée : Décharger des opérations coûteuses qui n'ont pas besoin d'une réponse immédiate (ex: traitement d'image, génération de rapports).
• Notifications : Envoyer des e-mails, des SMS, ou des notifications push en arrière-plan.
• Traitement en Lots (Batch Processing) : Regrouper des opérations similaires pour un traitement efficace.
• Audit et Journalisation : Enregistrer des événements pour l'audit sans impacter la performance du service principal.
• Communication Interne Fiable : Assurer que les messages sont livrés même en cas de pannes temporaires.

3.5 Exemple de Code : Commande et Traitement de Paiement

Imaginons qu'un Service de Commande publie un message "Commande Passée" et qu'un Service de Paiement le consomme pour initier le processus de paiement. Nous utiliserons RabbitMQ avec la bibliothèque pika en Python.

(Assurez-vous qu'un serveur RabbitMQ est en cours d'exécution, par exemple via Docker: docker run -d --hostname my-rabbit --name some-rabbit -p 5672:5672 -p 15672:15672 rabbitmq:3-management)

# order_service_producer.py (Service de Commande)
import pika
import json
import time

def publish_order_placed_event(order_details):
    connection = None
    try:
        # Connexion à RabbitMQ
        connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
        channel = connection.channel()

        # Déclaration d'une file d'attente (la crée si elle n'existe pas)
        # durable=True rend la file d'attente persistante (sur disque)
        channel.queue_declare(queue='order_queue', durable=True)

        message = json.dumps(order_details)

        # Publication du message
        channel.basic_publish(
            exchange='',         # Exchange par défaut (directement à la file d'attente)
            routing_key='order_queue',
            body=message,
            properties=pika.BasicProperties(
                delivery_mode=2, # Rend le message persistant (sur disque)
            )
        )
        print(f" [x] Envoyé '{message}'")

    except pika.exceptions.AMQPConnectionError as e:
        print(f"Erreur de connexion à RabbitMQ: {e}. Assurez-vous que RabbitMQ est en cours d'exécution.")
    finally:
        if connection:
            connection.close()

if __name__ == '__main__':
    print("Service de Commande (Producteur de messages)")
    order_id_counter = 1
    while True:
        order = {
            "order_id": f"ORD-{order_id_counter:04d}",
            "customer_id": "CUST-123",
            "items": [
                {"product_id": "P001", "quantity": 1, "price": 1200.00},
                {"product_id": "P002", "quantity": 2, "price": 25.50}
            ],
            "total_amount": 1251.00,
            "status": "PLACED"
        }
        publish_order_placed_event(order)
        order_id_counter += 1
        time.sleep(5) # Envoie une nouvelle commande toutes les 5 secondes

Pour exécuter le producteur, enregistrez sous order_service_producer.py et lancez python order_service_producer.py.

# payment_service_consumer.py (Service de Paiement)
import pika
import json
import time

def callback(ch, method, properties, body):
    """
    Fonction de rappel appelée quand un message est reçu.
    """
    order_details = json.loads(body)
    print(f" [x] Reçu '{order_details['order_id']}'")
    
    # Simuler un traitement de paiement
    print(f"     Traitement du paiement pour la commande {order_details['order_id']}...")
    time.sleep(2) # Simuler un travail de 2 secondes
    print(f"     Paiement pour {order_details['order_id']} traité avec succès.")
    
    # Accuser réception du message pour qu'il soit retiré de la file d'attente
    ch.basic_ack(delivery_tag=method.delivery_tag)

def start_consuming():
    connection = None
    try:
        connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
        channel = connection.channel()

        # S'assurer que la file d'attente existe (importante si le consommateur démarre avant le producteur)
        channel.queue_declare(queue='order_queue', durable=True)

        # Ne pas envoyer plus d'un message à la fois à un consommateur donné
        # jusqu'à ce qu'il ait accusé réception du message précédent.
        channel.basic_qos(prefetch_count=1)

        # Commencer à consommer les messages
        channel.basic_consume(queue='order_queue', on_message_callback=callback)

        print(' [*] En attente de messages. Pour quitter, appuyez sur CTRL+C')
        channel.start_consuming()

    except pika.exceptions.AMQPConnectionError as e:
        print(f"Erreur de connexion à RabbitMQ: {e}. Assurez-vous que RabbitMQ est en cours d'exécution.")
    except KeyboardInterrupt:
        print("Arrêt du consommateur.")
    finally:
        if connection:
            connection.close()

if __name__ == '__main__':
    print("Service de Paiement (Consommateur de messages)")
    start_consuming()

Pour exécuter le consommateur, enregistrez sous payment_service_consumer.py et lancez python payment_service_consumer.py.

Cet exemple montre comment le Service de Commande publie des messages dans order_queue et comment le Service de Paiement les consomme. Le producteur ne se soucie pas de qui consomme le message ni quand. Le consommateur traite les messages quand il est prêt, et les messages persistent même si le consommateur est arrêté et redémarré.

4. Événements : La Communication Asynchrone par Événement

La communication basée sur les événements est une forme spécialisée de messagerie, axée sur la propagation des faits et des changements d'état. Au lieu d'envoyer des commandes ou des données spécifiques à un destinataire, un service publie un événement (un fait qui s'est produit), et d'autres services s'abonnent à ces événements s'ils sont intéressés. C'est le principe du publish-subscribe.

4.1 Principes des Événements

• Événement (Event) : Une notification immuable d'un fait qui s'est produit dans le passé (ex: OrderPlaced, UserRegistered, ProductPriceChanged). Un événement ne contient que les données nécessaires pour décrire ce qui s'est passé.
• Publication (Publishing) : Un service "émet" un événement vers un courtier d'événements (souvent un message broker configuré pour le publish-subscribe, ou une plateforme de streaming d'événements comme Apache Kafka).
• Abonnement (Subscribing) : D'autres services "écoutent" et réagissent aux événements qui les intéressent.
• Event Bus / Stream : Le mécanisme central qui permet la diffusion des événements aux abonnés.

4.2 Distinctions entre Messagerie et Événements

Bien que souvent implémentés avec les mêmes technologies (RabbitMQ, Kafka), il y a une différence conceptuelle :

• Messagerie (Queues) : Souvent pour des commandes (ex: "traite cette commande", "envoie cet email"). Un message est généralement destiné à un seul consommateur spécifique (ou un groupe de consommateurs partageant une tâche). La consommation retire le message de la queue.
• Événements (Pub/Sub) : Représentent des faits (ex: "une commande a été passée", "un utilisateur a été créé"). Un événement peut être consommé par plusieurs abonnés, chacun agissant indépendamment sur cet événement. L'événement est diffusé et ne disparaît pas nécessairement après une seule consommation.

4.3 Avantages des Événements

• Découplage Extrême : Les éditeurs d'événements n'ont aucune connaissance des abonnés, et vice-versa.
• Extensibilité : Facile d'ajouter de nouveaux services qui réagissent à des événements existants sans modifier les services existants.
• Chorégraphie de Microservices : Permet aux services de coordonner des flux de travail complexes de manière décentralisée, sans qu'un service central ne les orchestre.
• Audit et Replay : Les journaux d'événements peuvent servir à des fins d'audit, de débogage ou même de reconstitution de l'état (Event Sourcing).

4.4 Inconvénients des Événements

• Complexité de la Conception : Demande une réflexion approfondie sur la structure des événements, l'ordonnancement, la cohérence éventuelle et l'idempotence.
• Débogage des Flux : Difficile de suivre un flux de travail qui s'étend sur plusieurs services et événements.
• Dépendance à l'Infra : Nécessite une infrastructure d'événements robuste (Kafka est souvent privilégié pour cela).
• Duplication de Données : Les services peuvent avoir besoin de répliquer des données pour réagir aux événements, ce qui pose des questions de cohérence.

4.5 Cas d'Utilisation Typiques

• Propagation de Changement d'État : Lorsqu'un service modifie une donnée métier importante et que d'autres services doivent en être informés (ex: ProductPriceUpdated).
• Architecture Réactive : Quand les services doivent réagir aux événements en temps réel.
• Event Sourcing et CQRS : Architectures où les événements sont la source de vérité et les vues de données sont construites à partir de ceux-ci.
• Intégration de Systèmes Hétérogènes : Connecter des systèmes legacy ou externes via un bus d'événements.

4.6 Exemple de Code : Publication/Souscription d'Événements

Continuons avec RabbitMQ, mais cette fois en utilisant un exchange de type fanout pour diffuser les événements à tous les consommateurs intéressés.

# user_service_event_publisher.py (Service Utilisateur)
import pika
import json
import time
import uuid

def publish_user_created_event(user_details):
    connection = None
    try:
        connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
        channel = connection.channel()

        # Déclaration de l'exchange de type 'fanout'
        # Un exchange de type 'fanout' diffuse les messages à toutes les files d'attente qui lui sont liées.
        channel.exchange_declare(exchange='user_events', exchange_type='fanout', durable=True)

        event_data = {
            "event_type": "UserCreated",
            "timestamp": time.time(),
            "user_id": user_details["id"],
            "username": user_details["username"],
            "email": user_details["email"]
        }
        message = json.dumps(event_data)

        channel.basic_publish(
            exchange='user_events',
            routing_key='', # Pas de routing_key pour un fanout exchange
            body=message,
            properties=pika.BasicProperties(
                delivery_mode=2, # Message persistant
            )
        )
        print(f" [x] Envoyé événement UserCreated: '{message}'")

    except pika.exceptions.AMQPConnectionError as e:
        print(f"Erreur de connexion à RabbitMQ: {e}. Assurez-vous que RabbitMQ est en cours d'exécution.")
    finally:
        if connection:
            connection.close()

if __name__ == '__main__':
    print("Service Utilisateur (Éditeur d'Événements)")
    user_counter = 1
    while True:
        user_id = str(uuid.uuid4())
        user = {
            "id": user_id,
            "username": f"user_{user_counter}",
            "email": f"user_{user_counter}@example.com"
        }
        publish_user_created_event(user)
        user_counter += 1
        time.sleep(10) # Envoie un nouvel événement toutes les 10 secondes

Pour exécuter le producteur, enregistrez sous user_service_event_publisher.py et lancez python user_service_event_publisher.py.

# notification_service_event_subscriber.py (Service de Notification)
import pika
import json
import time

def callback(ch, method, properties, body):
    event = json.loads(body)
    if event.get("event_type") == "UserCreated":
        print(f" [Notification Service] Reçu événement UserCreated: {event['user_id']} ({event['username']})")
        # Simuler l'envoi d'un email de bienvenue
        print(f"     Envoi d'un email de bienvenue à {event['email']}...")
        time.sleep(1) # Simuler un travail
        print(f"     Email de bienvenue envoyé pour {event['user_id']}.")
    
    ch.basic_ack(delivery_tag=method.delivery_tag)

def start_consuming():
    connection = None
    try:
        connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
        channel = connection.channel()

        # Déclaration de l'exchange (important si le consommateur démarre avant le producteur)
        channel.exchange_declare(exchange='user_events', exchange_type='fanout', durable=True)

        # Déclaration d'une file d'attente temporaire et exclusive pour ce consommateur.
        # Quand le consommateur se déconnecte, la file est automatiquement supprimée.
        # C'est typique pour les souscriptions d'événements où chaque abonné reçoit tous les événements.
        result = channel.queue_declare(queue='', exclusive=True) 
        queue_name = result.method.queue

        # Lier la file d'attente à l'exchange
        channel.queue_bind(exchange='user_events', queue=queue_name)

        print(' [*] Service de Notification en attente d\'événements UserCreated. Pour quitter, appuyez sur CTRL+C')
        channel.basic_qos(prefetch_count=1)
        channel.basic_consume(queue=queue_name, on_message_callback=callback)
        channel.start_consuming()

    except pika.exceptions.AMQPConnectionError as e:
        print(f"Erreur de connexion à RabbitMQ: {e}. Assurez-vous que RabbitMQ est en cours d'exécution.")
    except KeyboardInterrupt:
        print("Arrêt du consommateur du service de notification.")
    finally:
        if connection:
            connection.close()

if __name__ == '__main__':
    start_consuming()

Pour exécuter ce souscripteur, enregistrez sous notification_service_event_subscriber.py et lancez python notification_service_event_subscriber.py.

Vous pouvez lancer un deuxième souscripteur (par exemple, un analytics_service_event_subscriber.py similaire) pour voir comment les deux services reçoivent le même événement UserCreated de manière indépendante.

5. Choisir la Bonne Stratégie

Le choix de la stratégie de communication dépend des besoins spécifiques de l'interaction entre les services. Il n'y a pas de solution unique, et la plupart des architectures microservices utilisent une combinaison de ces approches.

5.1 Critères de Décision

• Besoin d'une Réponse Immédiate ?
  • Oui : API REST (synchrone).
  • Non : Messagerie ou Événements (asynchrone).
• Tolérance au Couplage ?
  • Faible tolérance (besoin de découplage fort) : Messagerie ou Événements.
  • Tolérance acceptable (interactions directes) : API REST.
• Résilience Requise ?
  • Très élevée (le service appelé peut être indisponible) : Messagerie ou Événements.
  • Moyenne (gestion des erreurs avec retries, circuit breakers) : API REST.
• Scalabilité de la Communication ?
  • Horizontalement (plusieurs consommateurs) : Messagerie ou Événements.
  • Verticalement (requêtes individuelles) : API REST.
• Nature de l'Interaction ?
  • Requête/Réponse, CRUD : API REST.
  • Commandes, tâches lourdes, notifications : Messagerie.
  • Propagation d'état, faits métier, intégration : Événements.

5.2 Approches Hybrides

Il est très courant de voir des systèmes combiner ces approches :

• Un Service de Commande peut utiliser API REST pour valider le stock avec le Service de Produits (requête synchrone).
• Une fois la commande validée, il peut publier un message "Commande Placed" via Messagerie à un Service de Paiement (asynchrone, longue durée).
• En même temps, il peut publier un événement "OrderCreated" via Événements à un Service d'Analyse et à un Service de Notification (asynchrone, pub/sub).

6. Conclusion

La communication inter-services est au cœur des architectures microservices. Maîtriser les différentes stratégies – API REST, Messagerie et Événements – et comprendre quand les utiliser est fondamental pour concevoir des systèmes distribués robustes, évolutifs et performants.

• API REST brille pour les interactions synchrones, directes et les opérations CRUD, mais introduit un couplage et nécessite une gestion rigoureuse des défaillances.
• La Messagerie offre un découplage fort et une résilience accrue pour les communications asynchrones, idéales pour les tâches de fond et la gestion de la charge.
• Les Événements poussent le découplage encore plus loin, permettant la chorégraphie des services et la propagation efficace des changements d'état à travers l'ensemble du système.

Le choix éclairé entre ces paradigmes, et leur combinaison judicieuse, est une compétence clé dans le développement d'applications basées sur les microservices. N'oubliez pas que l'observabilité (logs, traces, métriques) est primordiale pour déboguer et monitorer ces systèmes distribués complexes.