Exporter (0) Imprimer
Développer tout

Architecture d'applications pour .NET : conception d'applications et de services

          Avant-Propos
Ch. 1 : Introduction
Ch. 2 : Conception des composants d'une application ou d'un service
Ch. 3 : Politiques de sécurité, de gestion des opérations et de communication
Ch. 4 : Déploiement physique et exigences opérationnelles
          Annexes

Introduction

Résumé : Ce chapitre décrit l'architecture évoluée d'un service ou d'une application .NET distribuée.

Le guide Architecture d'applications pour .NET : conception d'applications et de services est conçu pour aider les développeurs et concepteurs d'applications qui doivent mettre en place des solutions distribuées avec la technologie Microsoft® .NET Framework.

Il vous est destiné si vous devez :

  • concevoir une architecture évoluée pour des applications ou des services ;
  • émettre des recommandations en termes de technologies et produits appropriés pour certains aspects spécifiques de votre application ou service ;
  • prendre des décisions en matière de conception pour répondre aux exigences fonctionnelles et non fonctionnelles (opérationnelles) ;
  • choisir des mécanismes de communication appropriés pour votre application ou votre service.

Ce guide identifie les décisions clés que vous devez prendre en matière de conception lors des phases préliminaires de développement et fournit des directives de conception pour vous aider à choisir entre diverses options. Il vous accompagnera notamment dans le développement d'un modèle de conception globale en présentant une architecture cohérente, constituée de divers types de composants, qui vous aidera à mener à bien votre projet et à profiter des avantages de la plate-forme Microsoft. En outre, bien que ce guide ne soit pas destiné à apporter des directives d'implémentation pour chaque aspect de l'application, il comporte plusieurs références à des guides Microsoft patterns & practices (Modèles et bonnes pratiques), articles MSDN et sites de la communauté Microsoft qui abordent en détails les différents aspects de la conception d'applications distribuées. Ce guide peut vous éclairer sur les principaux problèmes rencontrés lors de la conception d'applications distribuées sur la plate-forme Microsoft.

Ce guide se concentre sur les applications distribuées et les services Web pouvant nécessiter des capacités d'intégration pour des sources de données et services multiples, ainsi qu'une interface utilisateur pour un ou plusieurs équipements.

Ce sujet suppose de bonnes connaissances en développement des composants .NET, ainsi qu'une bonne compréhension des principes de base de la conception d'applications distribuées multi-couches.

Sommaire

Ce guide est divisé en cinq chapitres :

Il est conseillé de lire ces chapitres dans l'ordre, même si chaque chapitre fournit des informations pouvant s'avérer utiles, indépendamment des autres chapitres.

Sommaire

Ce chapitre contient les sections suivantes :

Objectifs de la conception d'applications distribuées

La conception d'une application distribuée implique de prendre des décisions sur son architecture logique et physique, ainsi que sur les technologies et l'infrastructure utilisées pour implémenter ses fonctionnalités. Dans le cadre de cette prise de décisions, vous devez comprendre parfaitement comment les processus métier sont exécutés par l'application (les exigences fonctionnelles), ainsi que les niveaux d'évolutivité, de disponibilité, de sécurité et de maintenabilité (les exigences non fonctionnelles ou opérationnelles).

Votre objectif consiste à concevoir une application qui :

  • résout le problème de gestion posé.
  • traite dès le départ des problèmes de sécurité, en tenant compte des mécanismes d'authentification appropriés, de la logique d'autorisation et de la sécurisation de la communication.
  • offre des performances élevées et qui est optimisée pour des opérations classiques sur les modèles de déploiement.
  • est disponible et flexible, et qui peut être déployée dans des centres de données redondants et à haute disponibilité.
  • s'adapte pour répondre aux exigences attendues et prend en charge un grand nombre d'activités et d'utilisateurs avec le moins de ressources possibles.
  • est facile à gérer, permettant aux opérateurs de déployer, de surveiller et de dépanner l'application, comme prévu par le scénario.
  • est facile à entretenir. Chaque partie de la fonctionnalité doit être localisée et conçue de manière prévisible, selon la diversité des tailles d'application, des qualifications des équipes de développement et des modifications des spécificités techniques et commerciales.
  • fonctionne selon plusieurs scénarios d'application et modèles de déploiement.

Les conseils de conception des chapitres suivants abordent chacun de ces objectifs et traitent des raisons pour lesquelles certaines décisions ont été prises lorsqu'il s'avère nécessaire de comprendre les tenants et les aboutissants.

Services et intégration de services

Avec l'évolution d'Internet et de ses technologies associées, ainsi qu'avec la nécessité pour les entreprises d'intégrer leurs systèmes au-delà des services et des entreprises, le développement de solutions a également évolué. Du point de vue du consommateur, les services sont conceptuellement similaires aux composants classiques, sauf qu'ils encapsulent leurs propres données et ne font pas, à proprement parler, partie de votre application, tout en étant utilisés par votre application. Les applications et les services à intégrer peuvent être développés sur différentes plates-formes, par différentes équipes, selon différents agendas, et peuvent être gérés et mis à jour de manière indépendante. Par conséquent, il est indispensable d'établir une communication entre eux avec le moins de couplage possible.

Cette communication entre les services doit se faire à l'aide de techniques axées sur les messages pour fournir un haut niveau de robustesse et d'évolutivité. Vous pouvez implémenter une communication par messages de manière explicite (par exemple, en écrivant du code permettant d'envoyer et de recevoir des messages Message Queuing) ou vous pouvez utiliser des composants d'infrastructure qui gèrent la communication à votre place de manière implicite (par exemple, en utilisant un proxy de service Web généré par Microsoft Visual Studio® .NET).

Remarque Le terme service est utilisé dans ce guide pour indiquer tout composant logiciel externe qui fournit des services métier. Ceci inclut, entre autres, les services Web XML.

Les services exposent une interface de service vers laquelle sont envoyés tous les messages entrants. La définition de la série de messages à échanger avec un service pour que celui-ci exécute une tâche métier spécifique constitue un contrat. Vous pouvez envisager une interface de service comme une façade qui expose la logique métier implémentée dans le service aux consommateurs potentiels.

Prenons l'exemple d'un logiciel de vente qui permet aux clients de commander des produits. L'application utilise un service d'autorisation de carte de crédit externe pour valider les détails de la carte de crédit du client et autoriser la vente. Une fois les détails de la carte de crédit vérifiés, un service de courrier est utilisé pour organiser la livraison des marchandises. Le schéma de séquence suivant (Figure 1.1) illustre ce scénario.

Processus métier implémenté à l'aide de services

Figure 1.1. Processus métier implémenté à l'aide de services

Dans ce scénario, le service d'autorisation de carte de crédit et le service de courrier jouent tous les deux un rôle dans l'ensemble du processus d'achat. Contrairement aux composants ordinaires, les services existent dans leur propre limite de confiance et gèrent leurs propres données en dehors de l'application. Vous devez, par conséquent, vous assurer qu'une connexion sécurisée et authentifiée est établie entre l'application appelante et le service lorsque vous optez pour une approche axée sur les services dans le développement de vos applications. Vous pourriez également établir une communication en utilisant une approche axée sur les messages, ce qui s'avère davantage adapté à la description des processus métier (parfois appelés transactions métier ou transactions longues) et aux systèmes à couplage lâche, assez répandus en cas de solutions distribuées à grande échelle — en particulier si le processus de gestion implique plusieurs entreprises et diverses plates-formes.

Par exemple, si les communications axées sur les messages sont utilisées dans le processus illustré à la Figure 1.1, l'utilisateur peut recevoir la confirmation de la commande plusieurs secondes ou plusieurs heures après la saisie des informations de vente, en fonction de la réactivité des services d'autorisation et de livraison. Ce type de communication peut également vous permettre de concevoir votre logique métier indépendamment du protocole de transport sous-jacent utilisé entre les services.

Si votre application utilise un service externe, l'implémentation interne du service ne s'applique pas à votre conception—tant que le service exécute sa tâche. Il vous suffit de connaître la fonctionnalité métier fournie par le service et les détails du contrat auquel vous devez adhérer en vue de communiquer avec lui (comme le format de communication, le schéma des données, le mécanisme d'authentification, etc.). Dans l'exemple du logiciel de vente, le service d'autorisation de carte de crédit fournit une interface permettant de transférer les détails de vente et de crédit au service, ainsi qu'une réponse indiquant si la vente a été approuvée ou non. Du point de vue du concepteur du logiciel de vente, ce qui se passe à l'intérieur du service d'autorisation de carte de crédit n'a aucune importance. Sa seule préoccupation est de déterminer les données à envoyer au service, les réponses à recevoir du service et le moyen de communiquer avec le service.

En interne, les services contiennent beaucoup de composants de types identiques aux applications classiques. (Le reste du guide se concentre sur les divers composants et sur leur rôle dans la conception de l'application). Les services contiennent des composants logiques qui orchestrent les tâches métier exécutées, tels que les composants de gestion qui implémentent la logique métier en cours du service et les composants d'accès aux données qui accèdent au magasin de données du service. En outre, les services exposent leur fonctionnalité via des interfaces de service, qui gèrent la sémantique d'exposition de la logique métier sous-jacente. Votre application appellera également d'autres services via les agents de service qui communiquent avec le service au nom de l'application cliente appelante.

Bien que les services axés sur les messages puissent être conçus pour être appelés de manière synchrone, il peut s'avérer avantageux de construire des interfaces de service asynchrone, qui permettent de développer une application distribuée avec une approche à couplage lâche. Le couplage lâche fourni par la communication asynchrone permet de développer des solutions hautement disponibles, évolutives et durables qui sont constituées avec les services existants. Cependant, une conception asynchrone n'apporte pas que des avantages. Cela signifie que votre conception doit prendre en compte certains aspects, comme la corrélation de message, la gestion de la concurrence d'accès optimisé aux données, la compensation du processus métier et l'indisponibilité du service externe.

Remarque Le chapitre 3, «  », traite en détails des questions liées à l'établissement de la communication du service. Politique de sécurité, de gestion des opérations et de communication

Pour obtenir davantage d'informations sur les services et les concepts associés, consultez l'article MSDN « Application Conceptual View » ( Quitter le site MSDN France Site en anglais) (http://msdn.microsoft.com/library/en-us/dnea/html/eaappconland.asp http://msdn.microsoft.com/library/en-us/dnea/html/eaappconland.asp).

Composants et niveaux des applications et services

Il est désormais largement accepté qu'en termes de développement d'applications distribuées, il convient de diviser votre application en composants fournissant des services présentation, métier et données. Les composants qui exécutent des types de fonctions similaires peuvent être regroupés en couches, qui, dans la plupart des cas, sont superposées, afin que les composants situés « au-dessus » d'une certaine couche utilisent ses services et qu'un composant donné utilise la fonctionnalité fournie par les autres composants de sa propre couche et des couches situées « en dessous ».

Remarque Ce guide emploie le terme couche pour se référer à un type de composant et le terme niveau pour se référer aux modèles de distribution physiques.

Cette vision partitionnée d'une application peut également s'appliquer aux services. À un niveau plus élevé, une solution basée sur les services peut être perçue comme une solution composée de plusieurs services, chacun communiquant avec les autres en transférant des messages. De manière conceptuelle, les services peuvent être envisagés comme des composants de la solution globale. Cependant, en interne, chaque service est constitué de composants logiciels, comme pour toute autre application, et ces composants peuvent être regroupés de manière logique en services présentation, métier et données, comme illustré à la Figure 1.2.

Solution axée sur les services

Figure 1.2. Solution axée sur les services

Les points importants à noter à propos de cette figure sont :

  1. Les services sont généralement conçus pour communiquer les uns avec les autres, avec le moins de couplage possible. L'utilisation d'une communication axée sur les messages permet de découpler la disponibilité et l'évolutivité des services, et la conformité aux normes industrielles, telles que les services Web XML, permet l'intégration à d'autres plates-formes et technologies.
  2. Chaque service est constitué d'une application avec ses propres sources de données, sa logique métier et ses interfaces utilisateur. Un service peut avoir la même conception interne qu'une application classique sur trois niveaux, par exemple, les services (2) et (4) dans la figure précédente.
  3. Vous pouvez choisir de développer et d'exposer un service qui ne possède aucune interface utilisateur qui lui est directement associée (service conçu pour être appelé par d'autres applications via une interface de programmation). Ceci est illustré dans le service (3). Notez que les composants qui constituent un service et les composants qui constituent les couches métier d'une application peuvent être conçus de la même manière.
  4. Chaque service encapsule ses propres données et gère les transactions atomiques avec ses propres sources de données.

Il est important de noter que les couches sont simplement des regroupements logiques des composants logiciels qui forment l'application ou le service. Ils permettent de différencier les différents types de tâches exécutées par les composants, facilitant la réutilisation de la conception sans la solution. Chaque couche logique contient un nombre de types de composants discrets regroupés en sous-couches, chaque sous-couche exécutant un type de tâche spécifique. En identifiant les types génériques des composants qui existent dans la plupart des solutions, vous pouvez réaliser un schéma significatif de votre application ou service, puis l'utiliser comme méthodologie de conception.

La Figure 1.3 illustre une vue simplifiée d'une application et de ses couches.

Composants séparés en couches en fonction de leurs rôles

Figure 1.3. Composants séparés en couches en fonction de leurs rôles

Une solution distribuée peut comprendre plusieurs organisations ou couches physiques, auquel cas elle possédera ses propres politiques en ce qui concerne la sécurité de l'application, la gestion des opérations et la communication. Ces unités de confiance ou zones peuvent correspondre à un niveau physique, un centre de données, ou bien un département, une division ou une société ayant de telles politiques. Ces politiques définissent des règles pour l'environnement dans lequel est déployé l'application, mais également la communication des services et des niveaux de l'application. Les politiques englobent l'ensemble de l'application, et la façon dont elles sont implémentées impacte les décisions de conception à chaque niveau. Elles ont également une influence l'une sur l'autre (par exemple, la politique de sécurité peut déterminer certaines règles dans la politique de communication et inversement).

Remarque Pour obtenir davantage d'informations sur la politique de sécurité, de gestion des opérations et de communication, reportez-vous au chapitre 3 «  ». Politique de sécurité, de gestion des opérations et de communication

Exemple de scénario

Pour permettre l'identification de types de composants classiques, ce guide décrit un exemple d'application qui utilise des services externes. Bien qu'il s'agisse d'un exemple spécifique, les recommandations fournies en matière de conception s'appliquent à la plupart des applications distribuées, indépendamment de leur scénario de gestion.

L'exemple de scénario décrit dans ce guide est une extension du logiciel de vente décrit précédemment dans ce chapitre. Dans ce scénario, un détaillant propose à ses clients de commander des produits via Internet ou par téléphone. Les internautes peuvent visiter le site Internet de la société et choisir des produits à partir d'un catalogue en ligne. Les clients peuvent également commander des produits depuis un catalogue envoyé par courrier en téléphonant à un agent qui saisit les détails de la commande grâce à une application basée sur Microsoft Windows. Une fois la commande terminée, les détails de la carte de crédit du client sont vérifiés à l'aide d'un service d'autorisation de carte de crédit externe et la livraison s'effectue par courrier.

La solution proposée pour ce scénario est basée sur divers composants, comme illustré à la Figure 1.4.

Logiciel de vente composé d'un ensemble de composants et services associés

Figure 1.4. Logiciel de vente composé d'un ensemble de composants et services associés

La Figure 1.4 illustre le logiciel de vente qui est constitué de plusieurs composants logiciels regroupés en niveaux logiques selon le type de fonctionnalité fourni. Notez que du point de vue du logiciel de vente, l'autorisation de la carte de crédit et les services de courrier peuvent être perçus comme des composants externes. Cependant, en interne ces services sont implémentés comme des applications classiques et contiennent les mêmes types de composants (bien que les services de ce scénario ne contiennent pas de niveau présentation, mais publient leur fonctionnalité via une interface de service de programmation).

Étape suivante

Ce chapitre vous a présenté les solutions basées sur les services et vous a expliqué comment un service, comme toute autre application, est constituée de plusieurs composants logiciels pouvant être regroupés en niveaux logiques. Les composants qui constituent une application ou un service peuvent être décrits en termes génériques. Une compréhension des différents types de composants généralement utilisés dans les applications distribuées vous permettront de concevoir de meilleures solutions.

Le chapitre 2 «  » décrit des types de composants classiques et fournit des recommandations de conception. Conception des composants d'une application ou d'un service

Commentaires et support client

Des questions, des commentaires ou des suggestions ? Envoyez-nous vos remarques ou questions à devfdbck@microsoft.com ( Quitter le site MSDN France Site en anglais).



Dernière mise à jour le vendredi 21 février 2003



Afficher:
© 2014 Microsoft