Ce document a pour objectif de décrire l’architecture technique de la solution proposée dans le cadre du projet de professionnalisation « Plate forme .Net ». Il s’agit d’une solution de gestion de la planification basé sur le modèle de fonctionnement d’une EFPP
1.1.1. Objectif d’une conception d’application distribuée
Lorsqu’on conçoit une application distribuée, il faudra faire des choix particuliers concernant son architecture logique et physique ainsi que les technologies et infrastructures utilisées pour implémenter ses fonctionnalités. Afin de prendre ces décisions de façon effective, il faut avoir une compréhension claire des processus métiers que l’application réalisera (ses spécifications fonctionnelles), ainsi que le niveau d’échelonnabilité, de disponibilité, la sécurisation, la maintenabilité exigée (les spécifications non fonctionnelles et les spécifications opérationnelles).
Notre objectif au travers ce document est donc :
Concevoir une application qui solutionne la problématique métier adressée : la gestion de la planification au sein des EFPP
Prendre en compte les considérations de sécurité nécessaires pour implémenter les mécanismes adéquats d’authentification, la logique d’autorisation ainsi que la communication sécurisée.
D’effectuer la conception nécessaire pour l’obtention d’un haut niveau de performance ainsi qu’un modèle de développement et de déploiement optimisé
Concevoir une architecture de solution échelonnable de façon à ce que la solution puisse supporter un grand nombre d’activités et d’utiliser avec un usage minimaliste des ressources.
Concevoir une architecture d’une solution concevable, gérable et mesure de façon à pouvoir gérer les problèmes éventuels qui surviendraient lors de l’utilisation de l’application
Concevoir une architecture de solution maintenable dans laquelle chaque unité fonctionnelle ait un emplacement prédictible ainsi qu’une conception qui prend en compte divers types d’applications, et des spécifications métier et techniques changeantes
1.1.2. Services et intégration de service
L’approche service s’est rapidement impose par le fait qu’elle propose au processus métier de s’affranchir aisément des frontières physiques des entreprises dans lesquelles ils sont consommés.
Du point de vue du consommateur du service, ce dernier est semblable à un composant traditionnel, excepté le fait qu’ils encapsulent leurs propres données et que d’un point de vue stricte ils ne font pas partie de notre application.
Du fait que les applications et les services qui les consomment sont généralement définis, développés, maintenus et mis à jours de façon indépendante les uns des autres, il est donc important que le couplage entre les deux soit aussi faible que possible.
Il est recommandé d’implémenter la communication entre services en utilisant la technique basée sur les messages afin d’assurer un haut niveau de robustesse et d’échelonabilité. Vous pouvez mettre en place une communication par message de façon très explicite (par exemple en écrivant du code pour MSMQ), ou vous pouvez utiliser des composants d’infrastructure qui gèrent la communication implicitement pour vous (par exemple les proxys générés par Visual Studio .Net).
Le principe d’utilisation d’un service est le suivant : un service expose une interface qui définit le contrat d’utilisation des méthodes que le service met à votre disposition, c’est – à – dire que chaque méthode du service définit son mode d’appel, ses paramètres ainsi que sa valeur de retour : on parle de signature de la méthode.
1.1.3. Composants et tiers dans les applications et services
Les composants sont utilisés pour décomposer chaque couche en éléments cohérents et logiques. On admet généralement un empilement des couches dans le sens Présentation à Données en passant par la couche des services.
Le schémas présenté sur la page suivante illustre l’architecture multitiere adoptée pour cette solution.
1.1.1. Objectif d’une conception d’application distribuée
Lorsqu’on conçoit une application distribuée, il faudra faire des choix particuliers concernant son architecture logique et physique ainsi que les technologies et infrastructures utilisées pour implémenter ses fonctionnalités. Afin de prendre ces décisions de façon effective, il faut avoir une compréhension claire des processus métiers que l’application réalisera (ses spécifications fonctionnelles), ainsi que le niveau d’échelonnabilité, de disponibilité, la sécurisation, la maintenabilité exigée (les spécifications non fonctionnelles et les spécifications opérationnelles).
Notre objectif au travers ce document est donc :
Concevoir une application qui solutionne la problématique métier adressée : la gestion de la planification au sein des EFPP
Prendre en compte les considérations de sécurité nécessaires pour implémenter les mécanismes adéquats d’authentification, la logique d’autorisation ainsi que la communication sécurisée.
D’effectuer la conception nécessaire pour l’obtention d’un haut niveau de performance ainsi qu’un modèle de développement et de déploiement optimisé
Concevoir une architecture de solution échelonnable de façon à ce que la solution puisse supporter un grand nombre d’activités et d’utiliser avec un usage minimaliste des ressources.
Concevoir une architecture d’une solution concevable, gérable et mesure de façon à pouvoir gérer les problèmes éventuels qui surviendraient lors de l’utilisation de l’application
Concevoir une architecture de solution maintenable dans laquelle chaque unité fonctionnelle ait un emplacement prédictible ainsi qu’une conception qui prend en compte divers types d’applications, et des spécifications métier et techniques changeantes
1.1.2. Services et intégration de service
L’approche service s’est rapidement impose par le fait qu’elle propose au processus métier de s’affranchir aisément des frontières physiques des entreprises dans lesquelles ils sont consommés.
Du point de vue du consommateur du service, ce dernier est semblable à un composant traditionnel, excepté le fait qu’ils encapsulent leurs propres données et que d’un point de vue stricte ils ne font pas partie de notre application.
Du fait que les applications et les services qui les consomment sont généralement définis, développés, maintenus et mis à jours de façon indépendante les uns des autres, il est donc important que le couplage entre les deux soit aussi faible que possible.
Il est recommandé d’implémenter la communication entre services en utilisant la technique basée sur les messages afin d’assurer un haut niveau de robustesse et d’échelonabilité. Vous pouvez mettre en place une communication par message de façon très explicite (par exemple en écrivant du code pour MSMQ), ou vous pouvez utiliser des composants d’infrastructure qui gèrent la communication implicitement pour vous (par exemple les proxys générés par Visual Studio .Net).
Le principe d’utilisation d’un service est le suivant : un service expose une interface qui définit le contrat d’utilisation des méthodes que le service met à votre disposition, c’est – à – dire que chaque méthode du service définit son mode d’appel, ses paramètres ainsi que sa valeur de retour : on parle de signature de la méthode.
1.1.3. Composants et tiers dans les applications et services
Les composants sont utilisés pour décomposer chaque couche en éléments cohérents et logiques. On admet généralement un empilement des couches dans le sens Présentation à Données en passant par la couche des services.
Le schémas présenté sur la page suivante illustre l’architecture multitiere adoptée pour cette solution.
Commentaires