Les couches d’abstraction d’une SOA

Les couches d’abstraction d’une SOA

Partenaires industriels

Ce projet de recherche inclut un partenariat industriel avec la Corporation d’Hébergement du Québec (CHQ). La CHQ est une société d’État provincial existant depuis 1999. La mission de la CHQ est d’offrir des services en génie-conseil aux établissements du réseau de la santé. Les projets de construction touchant les hôpitaux doivent respecter des normes très spécifiques et ce sont les spécialistes de la CHQ (architectes, ingénieurs) qui vérifient la conformité des travaux. La CHQ assure aussi le financement à court et long terme des travaux, au nom du ministère de la Santé et des Services sociaux du Québec (MSSS). Finalement, la CHQ offre un service d’expertise en gestion et suivi de contrat de construction. La CHQ emploie approximativement 130 employés. Elle s’est dotée d’une équipe en TI de cinq personnes (Corporation d’hébergement du Québec, 2010). Les analystes programmeurs de la CHQ sont expérimentés. Ils possèdent plusieurs années d’expérience en programmation, mais également en analyse et en gestion des bases de données. Ils connaissent bien la plateforme et les outils de développement de Microsoft. Puisque c’est une petite équipe, les processus liés au développement sont légers. Leur imputabilité couvre toutes les étapes du développement dans lesquelles ils sont impliqués. La CHQ possède plusieurs systèmes d’information qui ont été développés ou acquis au cours des dernières années. Ces systèmes communiquent entre eux de différentes façons. Dans certains cas, ce sont des liens ODBC. Autrement, ce sont des modules programmés et intégrés directement dans les applications. Certains systèmes propriétaires majeurs, comme le système de comptabilité, ne sont pas intégrés aux autres systèmes. Il n’existe pas de connectique permettant cette interopérabilité. 7 La CHQ a orienté ses choix technologiques vers les produits Microsoft au cours des dernières années, que ce soit pour le développement ou les systèmes d’exploitation des postes de travail et des serveurs ainsi que des bases de données. C’est un environnement relativement homogène. Cependant, certains systèmes patrimoniaux importants, comme le système de comptabilité, reposent sur des technologies propriétaires différentes. Elle impartit certains services, comme l’hébergement du site Web ainsi que l’hébergement d’un portail extranet. L’infrastructure réseau est administrée par le MSSS alors que la CHQ gère ses serveurs applicatifs et ses serveurs de bases de données. La CHQ n’applique pas un processus spécifique pour son développement. L’équipe des TI a élaboré au fil du temps une approche qui s’apparente à un développement itératif et incrémental. Les propositions de projets sont soumises au coordonnateur des TI. Le coordonnateur assigne un analyste au projet. Les exigences logicielles sont relevées par l’analyste. Ensuite, un prototype non fonctionnel est réalisé afin de reproduire le comportement attendu. Le client valide les exigences à l’aide du prototype. Une fois les exigences raffinées, le processus métier est programmé. Lorsque la fonctionnalité est approuvée, un nouveau prototype est construit pour la fonctionnalité suivante, jusqu’à la réalisation complète du projet. Les tests sont effectués manuellement tout au long du développement par les clients et les programmeurs. Les tests unitaires ne sont pas utilisés à la CHQ. Le suivi des demandes de modifications se fait à l’aide d’un outil développé par le MSSS. Les utilisateurs peuvent y accéder et saisir leurs demandes de changements. C’est l’analyste et le client qui gère les priorités de ces demandes. Le coordonnateur n’intervient qu’en dernier recours.

La couche des services

La couche des services se retrouve entre la couche d’affaires et la couche applicative. Elle correspond aux couches de « messagerie » et de « service » de la Figure 1.2 La couche des services peut elle-même être subdivisée en plusieurs sous-couches..Il y a tout d’abord la couche des services applicatifs. Les services applicatifs permettent d’interagir avec la couche applicative. Les services applicatifs seront utilisés par d’autres services de plus haut niveau. Ce sont les seuls services qui seront associés à une technologie particulière, celle de l’application avec laquelle ils interagissent. La couche des services d’affaires permet de réaliser les activités automatisables des processus d’affaires. Ces services sont, grâce aux services applicatifs, indépendants de la technologie. On peut subdiviser la couche des services d’affaires en deux autres sous-couches. La couche des services d’affaires entités représente généralement les entités du domaine d’affaires. Les services de tâches regroupent des opérations faisant interagir des services d’affaires entités ou d’autres services de tâches. Il pourra finalement y avoir une couche d’orchestration, optionnelle, qui aura pour mission de diriger le fonctionnement de plusieurs services d’affaires afin de réaliser un flux de travail plus complexe. Elle correspond à la couche « intégration »

La chorégraphie

La chorégraphie permet la gestion des échanges entre plusieurs acteurs différents (partenaires, clients, fournisseurs). La chorégraphie inclut toutes les parties et offre une vue globale d’un flux de travail (Guilbault, 2007). Par exemple, le processus complet d’une commande, en incluant les actions et les messages échangés entre le client et le fournisseur. 17 Pour une PME, la chorégraphie peut être complexe à mettre en place. Cela implique que la PME interagit avec d’autres organisations et que ces participants ont un intérêt commun à chorégraphier leurs relations, par exemple, à l’aide de services Web. Dans le contexte d’une SOA, les services Web peuvent être utilisés aussi bien à l’intérieur d’une entreprise qu’avec d’autres entreprises (B2B ou Business-to-Business) ou encore avec ses clients (B2C ou Business-to-Customer). Mais implémenter une chorégraphie dans l’entreprise peut avoir un impact très important. Comme pour l’orchestration, on attendra d’avoir atteint une certaine expertise avec l’architecture SOA et les technologies utilisées. Il n’est pas nécessaire de restreindre la chorégraphie à un processus entier. En effet, une organisation pourra offrir ou consommer des services provenant d’une autre entité pour l’aider à réaliser une certaine tâche sans pour autant chorégraphier l’ensemble du processus d’affaires. La Figure 1.4 illustre la distinction entre la chorégraphie et l’orchestration. Dans ce cas-ci, il y a deux organisations ayant chacune un processus d’affaires distinct. Par exemple l’orchestration pour la commande d’une pièce et l’orchestration pour le traitement d’une commande de pièce. La chorégraphie serait l’intégration des deux processus. Si on suit cet exemple, l’action de commander une pièce déclenche automatiquement le processus de traitement d’une commande.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
CHAPITRE 1 REVUE DE LA LITTÉRATURE
1.1 Introduction
1.2 L’architecture orientée services
1.2.1 Les couches d’abstraction d’une SOA 1.3 Les types de processus
1.3.1 L’orchestration
1.3.2 La chorégraphie
1.3.3 La collaboration
1.4 Les services Web
1.4.1 XML
1.4.2 XSD
1.4.3 WSDL
1.4.4 SOAP
1.4.5 Les extensions WS-*
1.4.6 Services Web REST
1.4.7 UDDI
1.5 Les organismes de standardisation
1.5.1 L’OASIS
1.5.2 Le W3C
1.5.3 Le WS-I
1.6 Les cadres d’architecture d’entreprise
1.6.1 TOGAF
1.6.2 Le cadre de Zachman
1.6.3 Le processus unifié d’entreprise
1.7 Les méthodologies SOA
1.7.1 SOMA et SOAD d’IBM
1.7.2 SOA RQ de SUN
1.7.3 SOAF
1.7.4 La méthodologie SOA de Thomas Erl
1.8 Les méthodologies de développement
1.8.1 UP et RUP
1.8.2 SCRUM
1.8.3 Extreme Programming
1.8.4 OpenUP
1.9 Eclipse Process Framework Composer
1.10 Conclusion
CHAPITRE 2 APPROCHE POUR LA RÉALISATION DE LA MÉTHODE
2.1 Introduction
2.2 Approche
2.2.1 Identification des trois méthodologies
2.2.2 Intégration des méthodologies candidates
2.2.3 Documentation des méthodologies candidates
2.3 Conclusion
CHAPITRE 3 RÉALISATION DE LA MÉTHODE
3.1 Introduction
3.2 Identification des méthodologies candidates
3.3 Description des disciplines d’entreprise
3.3.1 La discipline de modélisation d’affaires
3.3.2 La discipline de gestion du portefeuille
3.3.3 La discipline d’architecture d’entreprise
3.3.4 La discipline de réutilisation stratégique
3.4 Description des activités pour le développement d’une SOA
3.4.1 L’activité d’analyse orientée services
3.4.2 L’activité de conception orientée services
3.5 Description des phases d’OpenUP
3.5.1 La phase d’initialisation
3.5.2 La phase d’élaboration
3.5.3 La phase de construction
3.5.4 La phase de transition
3.6 Intégration des méthodologies
3.6.1 EUP et SOA
3.6.1.1 L’analyse orientées services et EUP
3.6.1.2 La conception orientée services et EUP
3.6.2 OpenUP et SOA
3.6.2.1 La phase d’initialisation et l’analyse orientée services
3.6.2.2 La phase d’élaboration et la conception orientées services
3.7 Conclusions
CHAPITRE 4 EXPÉRIMENTATION DE LA MÉTHODOLOGIE
4.1 Introduction
4.2 Les outils utilisés
4.2.1 Microsoft Visual Studio 2008
4.2.2 Windows Communication Foundation
4.3 Exécution des activités d’entreprises
4.3.1 Modélisation d’affaires de l’entreprise
4.3.2 Gestion du portefeuille
4.3.3 Architecture d’entreprise
4.3.4 Stratégie de réutilisation
4.4 Projet d’intégration d’un service provenant d’un fournisseur externe
4.4.1 La phase d’initialisation
4.4.2 La phase d’élaboration
4.5 Projet de développement d’un service à l’interne
4.5.1 La phase d’initialisation
4.5.2 La phase d’élaboration
4.6 Conclusions
CHAPITRE 5 DISCUSSION
5.1 Introduction
5.2 Rappel des contributions
5.3 Limites de l’expérimentation
5.4 Recommandations
CONCLUSION
ANNEXE I WSDL DU SERVICE WEB IManageImmeuble
ANNEXE II SOAP – RECHERCHER UN IMMEUBLE PAR ADRESSE
ANNEXE III SOAP – RECHERCHER UN IMMEUBLE PAR IDENTIFIANT
ANNEXE IV SCHÉMA XSD – CONTRAT DE DONNÉES POUR IManageImmeuble.
ANNEXE V DÉFINITION DE LA CLASSE MANAGEIMMEUBLE
ANNEXE VI DÉFINITION DE L’INTERFACE IMANAGEIMMEUBLE
ANNEXE VII DÉFINITION DE L’INTERFACE IGETDATA
ANNEXE VIII DÉFINITION DE LA CLASSE GETDATA
ANNEXE IX CODE GÉNÉRÉ POUR INTERFACER AVEC LA BASE DE
DONNÉES
ANNEXE X CODE SOURCE POUR LA GESTION DES FACTURES AVEC UN
SERVICE WEB
RÉFÉRENCES

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *