Architecture distribuée

Dans l'architecture distribuée, les composants sont présentés sur différentes plates-formes et plusieurs composants peuvent coopérer entre eux sur un réseau de communication afin d'atteindre un objectif ou un but spécifique.

  • Dans cette architecture, le traitement de l'information ne se limite pas à une seule machine mais est réparti sur plusieurs ordinateurs indépendants.

  • Un système distribué peut être démontré par l'architecture client-serveur qui forme la base des architectures multi-niveaux; les alternatives sont l'architecture de courtage telle que CORBA et l'architecture orientée services (SOA).

  • Il existe plusieurs frameworks technologiques pour prendre en charge les architectures distribuées, notamment .NET, J2EE, CORBA, les services Web .NET, les services Web AXIS Java et les services Globus Grid.

  • L'intergiciel est une infrastructure qui prend en charge de manière appropriée le développement et l'exécution d'applications distribuées. Il fournit un tampon entre les applications et le réseau.

  • Il se trouve au milieu du système et gère ou prend en charge les différents composants d'un système distribué. Des exemples sont les moniteurs de traitement des transactions, les convertisseurs de données et les contrôleurs de communication, etc.

Middleware comme infrastructure pour système distribué

La base d'une architecture distribuée est sa transparence, sa fiabilité et sa disponibilité.

Le tableau suivant répertorie les différentes formes de transparence dans un système distribué -

Sr.No. Transparence et description
1

Access

Masque la manière dont les ressources sont accessibles et les différences de plate-forme de données.

2

Location

Masque l'emplacement des ressources.

3

Technology

Cache les différentes technologies telles que le langage de programmation et le système d'exploitation à l'utilisateur.

4

Migration / Relocation

Masquez les ressources susceptibles d'être déplacées vers un autre emplacement en cours d'utilisation.

5

Replication

Masquez les ressources qui peuvent être copiées à plusieurs endroits.

6

Concurrency

Masquez les ressources qui peuvent être partagées avec d'autres utilisateurs.

sept

Failure

Cache l'échec et la récupération des ressources de l'utilisateur.

8

Persistence

Masque si une ressource (logiciel) est en mémoire ou sur disque.

Avantages

  • Resource sharing - Partage des ressources matérielles et logicielles.

  • Openness - Flexibilité d'utilisation du matériel et des logiciels de différents fournisseurs.

  • Concurrency - Traitement simultané pour améliorer les performances.

  • Scalability - Augmentation du débit en ajoutant de nouvelles ressources.

  • Fault tolerance - La possibilité de continuer à fonctionner après une panne.

Désavantages

  • Complexity - Ils sont plus complexes que les systèmes centralisés.

  • Security - Plus sensible aux attaques externes.

  • Manageability - Plus d'efforts requis pour la gestion du système.

  • Unpredictability - Réponses imprévisibles en fonction de l'organisation du système et de la charge du réseau.

Système centralisé vs système distribué

Critères Système centralisé Système distribué
Économie Faible Haute
Disponibilité Faible Haute
Complexité Faible Haute
Cohérence Facile Haute
Évolutivité Pauvres Bien
La technologie Homogène Hétérogène
Sécurité Haute Faible

Architecture client-serveur

L'architecture client-serveur est l'architecture de système distribué la plus courante qui décompose le système en deux principaux sous-systèmes ou processus logiques -

  • Client - C'est le premier processus qui émet une requête vers le deuxième processus, c'est-à-dire le serveur.

  • Server - C'est le deuxième processus qui reçoit la demande, l'exécute et envoie une réponse au client.

Dans cette architecture, l'application est modélisée comme un ensemble de services fournis par des serveurs et un ensemble de clients qui utilisent ces services. Les serveurs n'ont pas besoin de connaître les clients, mais les clients doivent connaître l'identité des serveurs et le mappage des processeurs aux processus n'est pas nécessairement 1: 1

L'architecture client-serveur peut être classée en deux modèles en fonction de la fonctionnalité du client -

Modèle de client léger

Dans le modèle de client léger, tout le traitement de l'application et la gestion des données sont assurés par le serveur. Le client est simplement responsable de l'exécution du logiciel de présentation.

  • Utilisé lorsque les systèmes hérités sont migrés vers des architectures client-serveur dans lesquelles le système hérité agit comme un serveur à part entière avec une interface graphique implémentée sur un client

  • Un inconvénient majeur est qu'il impose une lourde charge de traitement à la fois sur le serveur et sur le réseau.

Modèle épais / gros client

Dans le modèle de client lourd, le serveur est uniquement responsable de la gestion des données. Le logiciel sur le client implémente la logique d'application et les interactions avec l'utilisateur du système.

  • Le plus approprié pour les nouveaux systèmes C / S où les capacités du système client sont connues à l'avance

  • Plus complexe qu'un modèle de client léger notamment pour la gestion. Les nouvelles versions de l'application doivent être installées sur tous les clients.

Avantages

  • Séparation des responsabilités telles que la présentation de l'interface utilisateur et le traitement de la logique métier.

  • Réutilisabilité des composants du serveur et potentiel de concurrence

  • Simplifie la conception et le développement d'applications distribuées

  • Il facilite la migration ou l'intégration d'applications existantes dans un environnement distribué.

  • Il utilise également efficacement les ressources lorsqu'un grand nombre de clients accède à un serveur hautes performances.

Désavantages

  • Manque d'infrastructure hétérogène pour faire face aux changements d'exigences.

  • Complications de sécurité.

  • Disponibilité et fiabilité limitées du serveur.

  • Testabilité et évolutivité limitées.

  • Gros clients avec présentation et logique métier ensemble.

Architecture multiniveau (architecture n-tiers)

L'architecture multiniveau est une architecture client-serveur dans laquelle les fonctions telles que la présentation, le traitement des applications et la gestion des données sont physiquement séparées. En séparant une application en niveaux, les développeurs ont la possibilité de modifier ou d'ajouter une couche spécifique, au lieu de retravailler l'ensemble de l'application. Il fournit un modèle par lequel les développeurs peuvent créer des applications flexibles et réutilisables.

L'utilisation la plus générale de l'architecture à plusieurs niveaux est l'architecture à trois niveaux. Une architecture à trois niveaux est généralement composée d'un niveau de présentation, d'un niveau d'application et d'un niveau de stockage de données et peut s'exécuter sur un processeur séparé.

Niveau de présentation

La couche de présentation est le niveau le plus élevé de l'application par lequel les utilisateurs peuvent accéder directement, comme une page Web ou une interface graphique du système d'exploitation (interface utilisateur graphique). La fonction principale de cette couche est de traduire les tâches et les résultats en quelque chose que l'utilisateur peut comprendre. Il communique avec d'autres niveaux afin de placer les résultats au niveau navigateur / client et à tous les autres niveaux du réseau.

Niveau d'application (logique métier, niveau logique ou niveau intermédiaire)

Le niveau Application coordonne l'application, traite les commandes, prend des décisions logiques, évalue et effectue des calculs. Il contrôle la fonctionnalité d'une application en effectuant un traitement détaillé. Il déplace et traite également les données entre les deux couches environnantes.

Niveau de données

Dans cette couche, les informations sont stockées et extraites de la base de données ou du système de fichiers. Les informations sont ensuite renvoyées pour traitement, puis renvoyées à l'utilisateur. Il inclut les mécanismes de persistance des données (serveurs de base de données, partages de fichiers, etc.) et fournit une API (Application Programming Interface) au niveau application qui fournit des méthodes de gestion des données stockées.

Advantages

  • Meilleures performances qu'une approche client léger et est plus simple à gérer qu'une approche client lourd.

  • Améliore la réutilisabilité et l'évolutivité - à mesure que la demande augmente, des serveurs supplémentaires peuvent être ajoutés.

  • Fournit une prise en charge multi-thread et réduit également le trafic réseau.

  • Fournit maintenabilité et flexibilité

Disadvantages

  • Testabilité insatisfaisante en raison du manque d'outils de test.

  • Fiabilité et disponibilité des serveurs plus critiques.

Style architectural du courtier

Broker Architectural Style est une architecture middleware utilisée dans l'informatique distribuée pour coordonner et permettre la communication entre les serveurs enregistrés et les clients. Ici, la communication d'objet a lieu via un système middleware appelé courtier de demande d'objet (bus logiciel).

  • Le client et le serveur n'interagissent pas directement l'un avec l'autre. Le client et le serveur ont une connexion directe à son proxy qui communique avec le médiateur-courtier.

  • Un serveur fournit des services en enregistrant et en publiant leurs interfaces avec le courtier et les clients peuvent demander les services au courtier de manière statique ou dynamique par recherche.

  • CORBA (Common Object Request Broker Architecture) est un bon exemple d'implémentation de l'architecture de courtier.

Composantes du style architectural du courtier

Les composants du style architectural du courtier sont traités dans les chapitres suivants:

Broker

Le courtier est responsable de la coordination de la communication, telle que la transmission et l'envoi des résultats et des exceptions. Il peut s'agir d'un service orienté appel, d'un courtier orienté document ou message auquel les clients envoient un message.

  • Il est responsable du courtage des demandes de service, de la localisation d'un serveur approprié, de la transmission des demandes et du renvoi des réponses aux clients.

  • Il conserve les informations d'enregistrement des serveurs, y compris leurs fonctionnalités et services, ainsi que les informations de localisation.

  • Il fournit des API permettant aux clients de demander, aux serveurs de répondre, d'enregistrer ou de désenregistrer des composants de serveur, de transférer des messages et de localiser des serveurs.

Stub

Les stubs sont générés au moment de la compilation statique, puis déployés du côté client qui est utilisé comme proxy pour le client. Le proxy côté client agit comme un médiateur entre le client et le courtier et offre une transparence supplémentaire entre eux et le client; un objet distant apparaît comme un objet local.

Le proxy masque l'IPC (communication inter-processus) au niveau du protocole et effectue le marshaling des valeurs de paramètres et le désassemblage des résultats du serveur.

Skeleton

Le squelette est généré par la compilation de l'interface de service, puis déployé côté serveur, qui est utilisé comme proxy pour le serveur. Le proxy côté serveur encapsule les fonctions de mise en réseau de bas niveau spécifiques au système et fournit des API de haut niveau pour assurer la médiation entre le serveur et le courtier.

Il reçoit les demandes, décompresse les demandes, démarshale les arguments de la méthode, appelle le service approprié et rassemble également le résultat avant de le renvoyer au client.

Bridge

Un pont peut connecter deux réseaux différents basés sur différents protocoles de communication. Il sert d'intermédiaire à différents courtiers, notamment les courtiers DCOM, .NET remote et Java CORBA.

Les ponts sont des composants facultatifs qui masquent les détails de l'implémentation lorsque deux courtiers interagissent et prennent des demandes et des paramètres dans un format et les traduisent dans un autre format.

Broker implementation in CORBA

CORBA est un standard international pour un Object Request Broker - un middleware pour gérer les communications entre les objets distribués définis par OMG (object management group).

Architecture orientée services (SOA)

Un service est un composant de fonctionnalité métier bien défini, autonome, indépendant, publié et disponible pour être utilisé via une interface de programmation standard. Les connexions entre les services sont effectuées par des protocoles orientés messages communs et universels tels que le protocole de service Web SOAP, qui peut fournir des demandes et des réponses entre les services de manière lâche.

L'architecture orientée services est une conception client / serveur qui prend en charge une approche informatique axée sur l'entreprise dans laquelle une application se compose de services logiciels et de consommateurs de services logiciels (également appelés clients ou demandeurs de services).

Caractéristiques de SOA

Une architecture orientée services offre les fonctionnalités suivantes -

  • Distributed Deployment - Exposez les données d'entreprise et la logique métier sous la forme d'unités de fonctionnalité sans état, couplées, découvrables, structurées, basées sur des normes, à gros grains et sans état, appelées services.

  • Composability - Assemblez de nouveaux processus à partir de services existants qui sont exposés avec une granularité souhaitée via des interfaces de réclamation bien définies, publiées et standard.

  • Interoperability - Partagez les capacités et réutilisez les services partagés sur un réseau, quels que soient les protocoles sous-jacents ou la technologie de mise en œuvre.

  • Reusability - Choisissez un fournisseur de services et accédez aux ressources existantes exposées en tant que services.

Fonctionnement SOA

La figure suivante illustre le fonctionnement de SOA -

Advantages

  • Un couplage lâche d'orientation-service offre une grande flexibilité aux entreprises pour utiliser toutes les ressources de service disponibles, quelles que soient les restrictions de plate-forme et de technologie.

  • Chaque composant de service est indépendant des autres services en raison de la fonctionnalité de service sans état.

  • L'implémentation d'un service n'affectera pas l'application du service tant que l'interface exposée n'est pas modifiée.

  • Un client ou tout service peut accéder à d'autres services indépendamment de leur plate-forme, de leur technologie, de leurs fournisseurs ou de leurs implémentations linguistiques.

  • Réutilisabilité des actifs et des services puisque les clients d'un service n'ont besoin de connaître que ses interfaces publiques, la composition du service.

  • Le développement d'applications métier basées sur SOA est beaucoup plus efficace en termes de temps et de coût.

  • Améliore l'évolutivité et fournit une connexion standard entre les systèmes.

  • Utilisation efficace et efficiente des «services aux entreprises».

  • L'intégration devient beaucoup plus facile et améliore l'interopérabilité intrinsèque.

  • Complexité abstraite pour les développeurs et dynamiser les processus métier au plus près des utilisateurs finaux.