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.
|
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
Tรฉlรฉcharger le rapport complet