Bibliographie de Master de Recherche Informatique "Logicielles et Méthodes Formelles" (ENST-Bretagne)

Transcription

1 Bibliographie de Master de Recherche Informatique "Logicielles et Méthodes Formelles" (ENST-Bretagne) Sujet de stage Description de la vue applicative de l'urbanisation des services télécom Et élaboration d'une démarche associée Najat AL GADOUM Février 2005

2 Introduction L'arrivée des nouvelles technologies a bouleversé les besoins des entreprises. Celles-ci sont confrontées à une mondialisation de l économie qui les oblige à augmenter leur réactivité et à offrir toujours plus de services à valeur ajoutée, plus rapidement et bien sûr en moindre coût. Les entreprises se retrouvent donc obligé de s'adapter à leur environnement social, concurrentiel et technologique, et de se libérer de l'inertie de leurs systèmes d'information d'anciennes génération s'ils veulent assurer leur survie. Cette révolution des nouvelles technologies d un côté et les bouleversements de l économie traditionnelle liés à la globalisation des échanges, de l autre côté, ont entraîné les Directions Informatiques dans un vaste mouvement d ouverture et de refonte progressive des systèmes informatiques. Ces chantiers se sont concrétisés par le lancement de nombreux projets de développement de nouvelles applications, d ouverture du système d informations aux différents acteurs de l environnement de l entreprise, d intégration d outils de plus en plus nombreux et des processus métier au sein d un flux applicatif unifié, et ont souvent nécessité des réflexions de fond sur les méthodes de travail et l urbanisation des systèmes. Dans le même cadre, dans l objectif de répondre à la complexité grandissante des systèmes informatiques et nouvelles contraintes de développement des systèmes d information, l OMG (Object Management Group) a défini une nouvelle orientation nommé MDA (Model Driven Architecture) [12]. Cette nouvelle architecture présente un niveau supérieur d abstraction en insistant sur des approches à modèles au lieu des approches à objet tel est le cas dans OMA (Object Management Architecture). MDA préconise l élaboration de modèles de plus haut niveau d abstraction et l utilisation d approches transformationnelles pour aller vers des plates-formes techniques. Nous allons définir, à travers cet article, les concepts liés à cette nouvelle démarche de développement et de refonte des systèmes d information (Urbanisation, Architecture, Composant, frameworks ). Dans un second lieu, nous allons introduire la technologie des services web et l'architecture Orienté Services. Enfin nous allons faire un aperçu sur l'approche MDA et ses principes. stage. Nous conclurons cet article en faisant le lien entre ce qui précède et notre sujet de

3 La maîtrise des processus de développement reste aujourd hui un enjeu capital pour les entreprises, confrontées aux évolutions technologiques, aux demandes des marchés et à la complexité croissante des systèmes. La mise en place d un processus de développement logiciel depuis le recueil des besoins jusqu au déploiement s avère donc indispensable, et chaque entreprise doit se construire une stratégie pour s offrir les moyens, les outils et les méthodes les plus adaptés à ses besoins. L ensemble de ces outils et méthodes entre dans le cadre d un nouveau concept nommé «Urbanisation». 1. Urbanisation: Pourquoi faire? L urbanisation et d une manière plus générale la rationalisation du système d information sont devenues des préoccupations majeures de toutes les Directions des Systèmes d'information. Entre un parc applicatif de plus en plus vaste, comprenant des applications anciennes, dont la connaissance se perd parfois avec le renouvellement des effectifs, et les contraintes opérationnelles toujours dures, l importance de cette optimisation est devenue indéniable. Le club URBA-SI définit l'urbanisation comme suit: "Urbaniser c est organiser la transformation progressive et continue du système d information visant à le simplifier, à optimiser sa valeur ajoutée et à le rendre plus réactif vis à vis des évolutions stratégiques de l entreprise tout en s appuyant sur les opportunités technologiques du marché. L urbanisme définit des règles ainsi qu un cadre cohérent, stable et modulaire auquel les différentes parties prenantes se réfèrent pour toute décision d investissement dans le système d informations". Les projets d urbanisation et de rationalisation concernent l architecture et les méthodes. Qui dit visibilité dit architecture, et si on cherche la cohérence on pense aux méthodes. Ainsi ces deux notions, architecture et méthodes, sont donc essentielles dans le cadre de l'urbanisation. La création et l utilisation de framework, la mise en œuvre de composants, les réflexions sur l architecture des nouvelles applications ou d'évolution d'applications, sont autant d outils qu une Direction des Systèmes d Information devra maîtriser et savoir utiliser dans le cadre d un processus de développement repensé et adapté à ces nouvelles façons de concevoir les applications. Nous allons présenter par la suite quelques caractéristiques de ces différents outils et leurs intérêts dans le cadre de l'urbanisation. a. Rôle de l Architecture Dans les phases préliminaires du développement d une application ou de la refonte d un système d information, la définition de l architecture technique consiste à faire les choix de la technologie (vue infrastructure 1 ) et de l organisation de composants logiciels (vue organique 2 ) les plus adaptés aux besoins et aux contraintes de l entreprise. 1 Décrit comment les fonctions (services et réseaux) du service télécom sont techniquement réalisées au sein d'éléments de l'infrastructure existante ou au sein de nouveaux éléments devant y être introduits. 2 Décrit la répartition des fonctions(services et réseaux) nécessaires à la réalisation d'un services télécom au sein d'organes de services et /ou organes réseaux.

4 Ces choix sont ensuite relayés au sein des projets par les architectes qui guident la conception et permettent la transformation d un modèle fonctionnel (vue usage 3 + vue fonctionnelle 4 ) en application performante robuste (vue applicative) [Principe de MDA, voir section 3] b. Approche Composant En l'absence d'une structuration et d'une méthodologie rigoureuse, il est impossible de maîtriser les nouveaux développements vu la complexité des applications informatiques d'aujourd'hui. Dans ce domaine, les approches de type mainframe, ou même l approche par objet ont montré un certain nombre de limites. Le problème de l approche objet réside dans la difficulté qu il y a à gérer les dépendances dans les modèles objets des grandes applications alors que le problème des applications «mainframe» provient de leur aspect trop monolithique. L approche composant devient de plus en plus adoptée. Cela est dû principalement à trois facteurs : Une formalisation plus rigoureuse de l approche. La plus grande facilité à maîtriser le développement de systèmes d information complexes. L arrivée en force de nouvelles technologies telles que les Web Services (la technologie cible pour notre sujet de stage (voir plus loin)). Les deux approches les plus abouties ont été formulées par Peter Herzum et Olivier Simms[1]d un côté et Paul Allen[13] de l autre. Ces deux approches méthodologiques intègrent fortement la notion de composant dans la totalité du cycle de vie du développement logiciel (depuis l analyse des besoins jusqu au déploiement). L approche composant apporte une grande facilité à découper les applications complexes en composants autonomes, indépendants et maîtrisables. Indépendants dans la mesure où un composant peut exister indépendamment des autres composants et communiquer avec eux via une interface, ce qui fait que le changement d'un composant n'influe pas les autres. L apport de la notion d interface de composant est de ce point de vue vraiment fondamental puisqu elle permet de séparer réellement l utilisation d un composant de son implémentation. Enfin l implantation en masse de nouvelles technologies apporte une grande simplification dans la mise en œuvre technique de cette approche. On peut aujourd hui, grâce notamment aux web services, adopter une démarche composant radicale permettant de définir l interface des composants de façon vraiment indépendante de la technologie dans laquelle le composant sera développé (J2EE,.Net, CORBA ) 3 Décrit les fonctionnalités proposées aux utilisateurs d'un service télécom 4 Décrit commment les fonctions (services et réseaux) nécessaires à la réalisation d'un service télécom sont réparties entre différents éléments fonctionnels.

5 La figure suivante, tiré du livre Component-Based Development for the Enterprise [1] par Peter Herzum, Oliver Sims, qui représente l'évolution vers les composants dans l'industrie: Figure 1:Evolution vers les composants dans l'industrie c. Intérêt des Frameworks Quand on n'a pas besoin de redéfinir, et qu'il suffit de réutiliser, on obtient un gain non seulement en temps de développement, mais aussi en coût et encore plus en cohérence des applications développées. En effet, les frameworks constituent un socle technique commun aux applications et de nombreux problèmes récurrents peuvent trouver une solution dans un framework technique utilisé par tous les développements. Citons par exemple : la réalisation de la couche de présentation, la gestion de la persistance, la configuration et l administration des applications, la gestion des erreurs et aide à l exploitation, l utilisation d XML pour les échanges de données, les tests la simulation d interfaces, etc. Parce qu il sera intégré aux autres développements, la réalisation d un framework technique exige une qualité de conception, de documentation, une robustesse et des performances exemplaires. Par là même, le projet de création et de maintenance des frameworks est un projet transverse impliquant les méthodes et l architecture dans une vision d urbaniste, et donc participe à une rationalisation globale du Système d Informations. Dans l'industrie ces frameworks sont issus du commerce. Les entreprises utilisent donc ceux ci au lieu de développer des frameworks propriétaires. D'après ce que nous avons vu, savoir positionner les technologies dites «urbanisantes» est devenu donc incontestablement l un des enjeux quotidiens des architectes des systèmes d information. L intérêt est de tirer mieux parti de ces solutions technologiques avec une démarche visant à garantir la portabilité de la stratégie de l entreprise sur le système d information.

6 Nous allons présenter dans la suite l'urbanisation telle qu'elle est vue par Marc Boullier [directeur technique à la SSII Vistali] D'après Boullier, l urbanisation s associe à deux autres concepts : Orchestration et intégration. En effet, le périmètre d un projet d urbanisation est celui de l ensemble du système d information d une entreprise ou de celui d une entité métier. Des modèles architecturaux d orchestration sont mis en œuvre sur les tâches, les processus ou les données, et enfin l intégration des composants techniques du système d information pour les rendre interopérables. Autrement dit l urbanisation cible l enjeu métier (ou stratégie de l'entreprise), l orchestration est une proposition architecturale pour y répondre, et l intégration désigne un domaine opérationnel et les technologies qui en permettront la mise en œuvre. Plusieurs acronymes viennent ensuite se greffer sur ces concepts et sont pris par les acteurs du marché pour décrire leurs offres. C est là que certaines mutations technologiques ont pu provoquer le sentiment d une certaine confusion, car en effet : Les serveurs d application.net et J2EE [2] s enrichissent et se complètent pour faciliter la construction d applications. Ils supportent les standards et ont intégré des technologies de brokering et de gestion des messages asynchrones. Ils ont désormais fait évoluer leur plateforme de développement pour la doter de capacités à exploiter ces nouvelles fonctionnalités. Les initiatives de standardisation des web services proposent de normaliser plusieurs aspects directement liés à la gestion et à l intéropérabilité des composants du système d information. Ils proposent peu à peu des protocoles et des modèles couvrant l ensemble du périmètre d un système d exploitation : (IHM, sécurité, invocation de composants, accès aux données, référentiel de services, etc.)... d. Les enjeux de l urbanisation Les enjeux de l urbanisation, toujours d'après Marc Boullier, nécessitent des solutions permettant de répondre aux besoins stratégiques d agilité d entreprise : rendre possible la mise à disposition rapide de nouveaux environnements de travail pour les utilisateurs (portail d entreprise), supporter de nouveaux processus de collaboration transverses aux organisations (Business Process Management), et piloter l activité et la performance de l entreprise (Business Activity Monitoring et Business Process Performance Management). Les enjeux de l orchestration quant à elle, nécessite de pouvoir gérer les référentiels de services métiers à l échelle de l entreprise tout en donnant la capacité aux architectures de s adapter, monter en charge et faciliter le déploiement de nouveaux processus. Aujourd hui, les éditeurs spécialistes de l orchestration proposent des solutions techniques capable d implémenter des annuaires UDDI [11] de services et de processus supportant des fonctionnalités de déploiement, de load balancing, et plus généralement la scalabilité aussi bien technique qu organisationnelle. Un exemple de solution permettant d implémenter des architectures de services à l échelle de l entreprise est ESOA (Entreprise Service Oriented Architecture). Par ailleurs, les enjeux de l intégration des différents composants du système d information s appuient désormais sur les standards issus des web services, introduits

7 naturellement à mesure que l entreprise déploie les nouvelles générations de serveurs d application, et de progiciels. Les enjeux associés à l exécution des services et à l évolution du périmètre des standards des web services, permettent d envisager une normalisation du socle d exécution des web services sur deux types de «systèmes d exploitation» pour services : les serveurs d application.net ou J2EE. Ils supportent l exécution des services métiers, développés en interne ou proposés par des offreurs de progiciels intégrés. Aujourd'hui, les services web paraissent être une technologie d actualité. Ils ont montré leur force en matière d'interoporabilité des applications. Nous allons montrer un aperçu sur cette nouvelle technologie et ses apports pour le développement des nouvelles applications. Nous rappelons que les web services entrent dans le cadre d'une nouvelle architecture nommé Service Oriented Architecture. 2. Service Oriented Architecture: caractéristiques générales a. Définition d'un service web La définition d un service web [4] varie d une personne à l autre. Néanmoins, la plupart des gens du domaine informatique sont d'accord avec la définition d'un service Web, représentant une ressource de l'information ou processus métier (business process), auquel peuvent accéder d autres applications, via le Web, et qui communique en utilisant des protocoles standards d Internet. Une deuxième façon de définir un service web est d'analyser les deux mots qui le composent: Le Web se réfère à un immense espace d'information qui permet l'accès aux ressources web. Une ressource web est un type de structure électronique tel qu'un fichier, un réseau, un processeur, une application ou un service. Chaque ressource web est définie par un URI (Uniform Ressource Identifier) et est accessible via les protocoles web. Un service est une ressource qui expose ses fonctionnalités à travers une interface. Ceci signifie qu'il est conçu pour être consommé par le logiciel plutôt que par des personnes. La méthode d'invocation et les résultats possibles de cette invocation sont décrits selon un contrat. Un service web est donc un service qui est identifié par un URI et peut être accédé par des applications via des protocoles du Web conformément au contrat qui décrit son interface. Ce qui distingue les web services des autres applications basées sur le Web est le fait que les services web ont été conçus pour supporter la communication inter applications.les autres applications supportent la communication homme à homme (messagerie instantanée) ou bien la communication homme à application (navigateurs). Les web services, quant à eux, ont été conçus pour assurer une communication entre applications sans l assistance humaine. Les services web sont applicables à tous types d environnement de gestion de réseau ; et peuvent supporter business-to-business, business-to-consumer, department-to-department, ou les interactions de peer-to-peer.

8 Comme tout composant, les services en général (et les services web en particulier) représentent des fonctionnalités qui peuvent être réutilisées sans connaître les détails dont le service est implémenté. Les web services indiquent l ensemble de standards qui assurent l interopérabilité entre les services, surtout quand ces services sont destinés à être accessible sur des protocoles standards du Web. Nous représentons ici quelques concepts qu inclut l approche des web services accessible sur l'internet, les services web communiquent à travers des protocoles web indépendants des plates formes, facilitant ainsi l'intégration d'environnements hétérogènes. Dans ce cas on peut appliquer l'approche MDA pour cibler une plateforme donnée (voir section 3) Les standards des services web définissent l interface et le protocole de communication qui peuvent être invoqués à partir d'une application cliente ou peuvent être fournis à travers un serveur. Le langage de définition des services web (WSDL) ajoute une couche d'abstraction entre l implémentation et l interface, en fournissant une application faiblement couplée dont résulte une flexibilité future. Bien que les services Web soient nouveaux, du point de vue architecture, ils sont basés sur les principes de conception des middlewares établis pour la communication inter applications. Le concept associé à ces principes de conception est l'architecture Orientée Services (SOA) [4] [3].Si, en plus, les applications communiquent à travers le web, alors dans ce cas une convergence de SOA et le web permet d'étendre cette architecture vers ce qu'on appelle Architecture des Services Web (WSA) [4]. Aujourd hui la plupart des services web sont implémentés en utilisant un ensemble de technologies des middlewares d'internet qui inclut : XML [5] (Extensible Markup Language) : qui offre un mécanisme neutre vis-à-vis de la plate forme pour représenter les données. SOAP [9] [10] (Simple Object Access Protocol): qui définit le protocole de communication des données pour les services web. WSDL [6][7][8] (Web Services Description Language) : qui décrit le service web. UDDI [11] (Universal Description, Discovery, and Integration) : qui offre le moyen de publier et de découvrir le service web. b. Architecture Orientée Service: Principe Le concept de service est le mot-clef pour comprendre les services web. En effet, l'environnement des services web est conforme à l'architecture Orientée Services. La figure 2 représente les rôles conceptuels et les opérations d'un SOA. Les trois rôles basics sont : le Fournisseur du service (service provider), le Consommateur de service (service consumer) et le Courtier de service (service broker). Le service provider met le service à disposition et publie le contrat qui décrit son interface. Il enregistre alors le service chez un service broker.

9 Le service broker donne au service consumer les directions pour trouver le service ainsi que le contrat de service. Le service consumer utilise le contrat pour lier le client au service. Figure 2: les trois rôles conceptuels et opérations d'un service orienté architecture c. Les composants de l'architecture SOA Pour que les trois rôles conceptuels accomplissent les trois opérations conceptuelles qui leurs sont attribuées, un service orienté architecture doit fournir trois composants d'architecture: Transport: le composant de transport représente les formats et les protocoles utilisés pour communiquer avec le service. Le format de données spécifie les types de données et les formats des flux des octets utilisés pour coder les données dans les messages. Le protocole de liaison spécifie le mécanisme utilisé pour packager les données dans le message. Le protocole de transfert spécifie les sémantiques de l'application qui contrôlent le transfert du message. Le protocole de transport exécute le transfert de message. Description: le composant de description représente le langage de description utilisé pour décrire le service. La description fournie l'information nécessaire pour se lier à un service. Le langage de description doit fournir, au minimum, un moyen pour spécifier le contrat de service, en incluant les opérations qu'il exécute et les paramètres ou messages qu'il échange. Le langage de description est de format lisible par la machine et qui peut être traité par un compilateur pour produire le code de communication, tel que les proxys client, les skeletons et les stubs du serveur. Les fragments de code générés permettent d'automatiser la connexion entre le code de l'application et le processus de communication, isolant ainsi l'application de la complexité des middlewares sous-jacents. Discovery: le composant de découverte représente le mécanisme utilisé pour enregistrer ou publier un service et pour trouver un service et sa description. Ces trois fonctions sont rendues en utilisant les protocoles standards d'internet comme les présente la figure suivante.

10 Figure 3: architecture conceptuel de SOA avec SOAP, WSDL, et UDDI Si l urbanisation des systèmes d information se présente comme un moyen indispensable pour assurer une optimisation du développement des systèmes d information performants flexibles et si le Web rend le WSA complètement indépendant du langage et de la plate forme, alors les services web peuvent être développés en utilisant n importe quel langage, et peuvent être déployés sur n importe quelle plate forme (de l appareil le plus minuscule jusqu au plus grand ordinateur). L approche MDA quant à elle constitue une approche technique très répandue dans le domaine du développement logiciel qui peut jouer un rôle primordiale dans l'urbanisation et la mise en œuvre des services web. Dans cette dernière partie de l article, nous allons mettre en exergue cette approche, en rappelant ses caractéristiques et ses principes. 3. Model Driven Architecture (MDA) a. MDA : Objectif L'initiative MDA [12] introduit un important changement dans la conception de l'architecture dans le domaine du développement logiciel. En effet, l'évolution rapide des supports technologiques nécessite des méthodes pour rendre les éléments stables du logiciel métier indépendants des plates-formes techniques. MDA intervient dans cette optique et a été conçue afin de séparer les contraintes fonctionnelles des contraintes techniques. b. MDA : Principe de base L'approche MDA est basée sur trois types de modèles: Les PIMs (Platform Independant Model): des modèles indépendants des plates-formes techniques et qui représentent les diverses entités d'un système en terme fonctionnel.

11 Les PSMs (Platform Specific Models): des modèles spécifiques combinant les entités d'un système des éléments des plates-formes techniques. Ils permettent également de générer du code exécutable pour les plates-formes. Les PDMs (Platform Description Language): décrivent les plateformes techniques cibles. Le principe du MDA consiste en plusieurs transformations de modèles pour produire des PSMs à partir des PIMs. Pour ce, la nouvelle approche de l'omg préconise quatre type de transformations: 1. PIM vers PIM: Ces transformations visent à enrichir, filtrer ou spécialiser le modèle pendant le cycle de développement sans nécessiter d informations dépendantes d une plate-forme. Les transformations PIM vers PIM sont généralement utilisées pour le raffinement de modèle. 2. PIM vers PSM: c'est la transformation principale du processus qui a lieu une fois que les PIMs sont complets et prêts à être immergés dans les plates-formes techniques. Ces transformations devraient être automatisées dans la plupart des cas, il est donc nécessaire de définir et de généraliser les règles régissant cette opération. 3. PSM vers PSM: Ces transformations s appliquent sur un modèle spécifique et donnent un autre modèle spécifique à la même plate-forme. Elles sont utilisées pour la réalisation et le déploiement de composants. La génération de code, la compilation, la mise en paquetages, l initialisation et la configuration font parties de ce type de transformation. 4. PSM vers PIM: Ces transformations doivent permettre d obtenir un modèle indépendant à partir d une implantation existante sur une plate-forme spécifique. Bien que celles-ci ne fassent pas directement partie du processus MDA, elles doivent permettre d intégrer des applications existantes afin de pouvoir les utiliser dans un processus MDA. Ce sont certainement les transformations les plus difficiles à automatiser. Très idéalement, le résultat de cette transformation devrait correspondre à la transformation inverse PIM vers PSM. La figure suivante présente le principe MDA.

12 Figure 4:MDA principe et transformation de modèles En adoptant l'approche MDA, nous pouvant alors, à partir d'une architecture indépendante de toute plate-forme fournir un modèle correspondant à une plate-forme donnée.

13 Conclusion A travers cet article, nous avons fait un tour d'horizon sur les différents concepts utilisés de près ou de loin dans notre projet et dont l'urbanisation constitue le noyau. Notre projet consiste, dans un premier temps à faire une analyse des métamodèles décrivant les vue usage, fonctionnelle, organique et infrastructure. En parallèle, nous analyserons l'architecture des services web et réaliserons un métamodèle associé. A partir de ces deux activités nous allons faire une analogie entre les concepts utilisés dans les premiers métamodèles et le métamodèle de l'architecture des web services afin d'en déduire les correspondances. Dans un second lieu, avec l'aide de la maîtrise d'ouvrage, nous allons faire une étude de processus d'urbanisation de description de l'architecture existante et l'adaptons aux services web qui constituent notre architecture cible. Enfin, nous allons proposer des règles d'urbanisation pour les services web, phase de notre travail où nous ferons appel à l'approche MDA.

14 Références [1] Component-Based Development for the Enterprise par Peter Herzum,Oliver Sims accessible sur le site [2] Services Web avec J2EE et.net Ecrit par Libero Maesano, Christian Bernard et Xavier Le Galles [3] Service-Oriented Architecture: A field guide to integrating XML and Web services Ecrit par Thomas Erl. [4] Introduction to Web Services Architecture: accessible sur le site [5] Extensible Markup Language (XML) 1.0 (Third Edition): accessible sur le site [6] Web Services Description Language (WSDL) 1.1 accessible à : [7] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language : accessible à [8] Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions : accessible à : [9] Simple Object Access Protocol (SOAP) 1.1 : accessible sur le site [10] SOAP Version 1.2 Specification Assertions and Test Collection: accessible sur le site [11] UDDI Version 2.04 API Specification UDDI Committee Specification, 19 July 2002: accessible sur le site htm [12] La démarche MDA: Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* accessible sur le site [13] Realizing ebusiness with Components, Auteur: Paul ALLEN, un résumé de ce livre est accessible sur le site Wesley/ X/RealizingeBusinesswith.aspx