Pipe-filter

Pipe-filter

Tableau 2.31: Pattern Pipe-filter Pipe-filter Intention : Organiser les traitements comme un enchainement de tuyau de pipeline Indications d’utilisation. On utilise ce style pour décomposer le traitement de flux de données par des séquences de filtres uniformes : – pour gérer les ressources partagées – pour subdiviser une tâche complexe en une série de tâches simples Structure. Participants – Client : Générateur de message – FilterManager : Gère une liste de filtre – FilterChain : Interface pour uniformiser les filtres – Filter : implémente le traitement du message – Target : destination du message . Ce Pattern représente le principe général de la gestion de métier en processus et le traitement en services. La décomposition nécessite la maitrise des propriétés commune dans le filter et le gestionnaire de la liste des éléments obtenus. 

Broker

Tableau 2.32: Pattern Broker Broker Intention : Organiser le système pour pouvoir distribuer les services via le partage des objets. Indications d’utilisation. On utilise cette architecture pour dispatcher des requêtes dans un système de composants distribués. Structure. Participants – Server : Offre un service – Client : Demandeur de service via une requête – Broker : Joue l’intermédiaire (trader) entre le client et le serveur – Bridge : une couche qui permet de relier des brokers – Server-sideProxy : Une interface qui permet d’accéder au serveur En utilisant ce Pattern, un annuaire de service peut gérer les instances de traitement en cours et optimiser sa relation avec le Bus événement : – identifier les serveurs où s’exécutent les services – créer les événements – gérer l’aboutissement de requête – gérer le proxy – gérer la structure des données

Peer-to-peer

Tableau 2.33: Pattern Peer to peer Peer-to-peer Intention : Créer une organisation qui collabore pour déployer, publier, découvrir et consommer des ressources hétérogènes. Indications d’utilisation. On utilise cette architecture pour diffuser et partager des informations avec réplication entre plusieurs systèmes client/serveur. Structure. Participants – StateManager : Gère les événements et la communication asynchrone entre système – UserInterface : Définit le point d’accès pour gérer les ressources pour un système – Router : Définit le moyen pour relier les systèmes – MessageHandler : Observateur d’événement au niveau de la communication – Scheduler: Plannifier les demandes – ResourceMonitor: Donne l’accès aux ressources – ResourceProvisionService : Donne l’accès aux traitements sur les ressources – SecuritManager: Gère les privilège