Interopérabilité des applications pour l administration électronique

Transcription

1 Interopérabilité des applications pour l administration électronique Intégration efficace des applications existantes par le biais des architectures orientées services (SOA Service-oriented Architectures) Livre blancs Version préliminaire 1.0 Auteurs Uwe Holzmann-Kaiser Philipp Martin Majid Salehi Dr. Michael Tschichholz Dr. Oliver Fox Fraunhofer Institute for Open Communication Systems FOKUS Berlin, May 2006

2 Préambule Ce livre blanc est le résultat des recherches menées par le Laboratoire Fraunhofer FOKUS en Allemagne sur l'administration publique en ligne, ou administration électronique. Il présente les idées collectées tout au long du déroulement d'un projet prototype mené à des fins d'expérimentation. Le scénario retenu est la création d un service «Obtention d un certificat de naissance». Il doit servir de modèle ou d application générique pour illustrer l'évolution d un simple concept jusqu à la mise en œuvre de solutions afin de considérer les différent aspects de l interopérabilité et de l intégration des processus entre différentes organisations. Le scénario a pris en compte une large gamme de produits, comme des logiciels Open Source, spécifiés par les partenaires cités ci-dessous qui ont collaboré avec le laboratoire FOKUS afin de mettre en évidence les différents aspects de l'interopérabilité et de la gestion de processus. Application de l État civil : AutiSta, Verlag für Standesamtwesen GmbH, Application du Registre des habitants : Meso, HSH Softund Hardware Vertriebs GmbH, Application du Registre des entreprises : migewa, Naviga GmbH, Serveur de formulaires : FormsForWeb, Lucom GmbH, Kit de démarrage pour le gouvernement électronique Microsoft Microsoft Deutschland GmbH, Microsoft Office Édition Professionnelle 2003, InfoPath, Windows,.Net, etc. : Microsoft Corporation, Oracle BPEL Process Manager, ORACLE Corporation, OpenOffice.org Writer, Fraunhofer FOKUS souhaite remercier toutes les entreprises partenaires et les représentants de OpenOffice.org pour leur aide importante dans la mise en œuvre du scénario retenu et dans la rédaction de ce livre blanc. La contribution des auteurs ne reflète pas nécessairement les opinions des entreprises associées dans ce projet. Fraunhofer FOKUS n accepte aucune responsabilité quant à l exactitude des informations contenues dans ce document. FOKUS Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee Berlin, Allemagne Toute reproduction ou diffusion, partielle ou complète, de ce livre blanc, sous quelque forme que ce soit, y compris sous forme électronique, nécessite une permission écrite préliminaire de la part de Fraunhofer FOKUS. Copyright Fraunhofer Institute FOKUS, août 2005 Tous droits réservés. Toutes les marques citées dans ce document sont la propriété des entreprises correspondantes et sont déposées par leurs propriétaires respectifs : Adobe PDF Adobe Systems Incorporated; BEA Weblogic BEA Systems, Inc.; Jakarta Apache Tomcat, The Apache Software Foundation; Java, J2EE Sun Microsystems, Inc; MacOS Apple Computer, Inc.; WebSphere IBM Corporation; etc.. 2

3 Sommaire Le Laboratoire Fraunhofer FOKUS pour l administration électronique 7 Résumé 9 1 Introduction Objectifs Étendue Définitions de termes Groupes cibles 15 2 Scénarios métier pour des tests d interopérabilité entre applications Scénarios de départ pour le test du Service aux citoyens Scénario 1: Interopérabilité des applications Concepts pour l intégration des systèmes anciens Scénario 2: Processus métier distribué au-delà des frontières techniques et organisationnelles 20 3 Présentation des technologies déployées Technologies de plateforme pour l administration électronique, orientées service Microsoft E-Government Starter Kit pour l administration publique Oracle BPEL Process Manager (technologie J2EE) Technologies des applications de l administration publique Registre des habitants (application Meso) Registre de l état civil (application AutiSta) Registre des entreprises (application Migewa) Services fondamentaux Service de formulaires (FormsForWeb) Service de paiement électronique dans EGSK 27 Fraunhofer Institute FOKUS Berlin, août

4 4 Mise en œuvre des scénarios d interopérabilité Définition des interfaces de services Web Intégration du modèle des applications anciennes Intégration d Autista, l application du registre de l état civil Intégration du Registre des habitants Meso (intégration de base de données) Intégration du Registre des entreprises Migewa Mise en œuvre de processus métier distribués au-delà des frontières techniques et organisationnelles 37 5 Expérience obtenue de ces tests Leçons apprises et recommandations Expérience pratique Faciliter l interopérabilité entre les applications de l administration Mise en œuvre efficace des interfaces et des adaptateurs de services Web Intégration efficace des applications anciennes Prise en charge des processus métier multi domaines Comparaison des temps de développement entre les technologies d intégration des applications existantes Intégration avec Microsoft EGSK Intégration avec Oracle BPEL Process Manager Prise en charge de SSL et documentation de la plateforme Disponibilité d outils Principales recommandations 45 6 Abréviations 47 7 Glossary 49 8 Références 61 4 Fraunhofer Institute FOKUS Berlin, août 2005

5 Liste des illustrations Figure 1 Demande d un certificat de naissance auprès du registre de l état civil. 17 Figure 2 Infrastructure du laboratoire pour des scénarios d interopérabilité entre applications. 19 Figure 3 Processus métier coopératif distribué au-delà des frontières techniques et organisationnelles. 20 Figure 4 Architecture mise en place pour les tests d interopérabilité. 23 Figure 5 Implémentation des interfaces services Web. 29 Figure 6 Intégration des applications existantes de l administration publique. 31 Figure 7 Diagramme de la séquence UML du flux d information. 34 Figure 8 Utilisation de services Web pour la transformation de données et l intégration d application. 35 Figure 9 Exemple de mise en œuvre avec une technologie de miroir. 35 Figure 10 Interopérabilité des applications au-delà des frontières techniques et organisationnelles. 37 Figure 11 Présentation des standards web SOA 54 Fraunhofer Institute FOKUS Berlin, août

6 6 Fraunhofer Institute FOKUS Berlin, août 2005

7 Le Laboratoire Fraunhofer FOKUS pour l administration électronique L administration électronique a besoin d une vision pour le futur et d une concurrence sur le marché mais elle a aussi besoin d une coopération concertée et d une collaboration efficace entre toutes les parties prenantes. Avec son laboratoire dédié à l administration électronique, Fraunhofer FOKUS fournit une plateforme qui remplit simultanément plusieurs rôles : un atelier, une vitrine et un nœud de compétences pour une administration électronique innovante, en Allemagne et dans toute l Europe. En tant que partenaire résolument indépendant de toute marque et neutre vis-à-vis de tout produit, le Laboratoire Fraunhofer FOKUS promeut les facteurs de réussite sur lesquels se fonde une administration publique moderne : Permettre une intégration rationnelle des processus de l administration via une interopérabilité établie entre les systèmes informatiques déployés. Assurer les échanges de données indépendamment des médias utilisés, via des formats d échange standards et établis. Promouvoir une sélection libre de produits par l utilisation de produits et de composants Open Source utilisant des interfaces ouvertes et exploitant des standards ouverts. Le Laboratoire pour l administration électronique de Fraunhofer FOKUS développe, évalue et démontre l interopérabilité entre les systèmes informatiques en étudiant les différentes technologies des fournisseurs, qui reposent sur des standards Open Source et des interfaces ouvertes ; ces études concernent l'interopérabilité des documents, des applications et des plateformes ; développe des solutions (prototypes) et diffuse les résultats de ses recherches dans les environnements applicatifs ; élabore des propositions pour des architectures innovantes dans le secteur de l administration électronique ; fournit une vitrine à des fins de démonstration et de présentations ; constitue un centre pour des services de formation et de conseil. Depuis l automne 2004, le Laboratoire pour l administration électronique de Fraunhofer FOKUS a été particulièrement engagé dans l évaluation de l interopérabilité et de l intégration d une large gamme de technologies, de plateformes et de produits disparates, incluant des technologies déjà mises en œuvre dans l administration électronique, des produits en provenance de différents fournisseurs et des développements réalisés dans le secteur de l Open Source. Des scénarios applicatifs et des jeux de tests ont été mis en œuvre pour démontrer que l interopérabilité entre les systèmes hétérogènes de l administration électronique peut être garantie à condition d exploiter des architectures orientées services et des interfaces et des standards ouverts. Cela s applique notamment aux cas critiques où des composants de la solution contiennent à la fois des standards et des interfaces ouverts pour des applications spécialisées (comme XMeld ou XBau). Fraunhofer Institute FOKUS Berlin, août

8 Les conclusions de cette évaluation sont publiées dans divers documents traitant les divers aspects de l interopérabilité. Livres blancs Interopérabilité des documentspour l administration électronique Partage des informations stockées dans des documents, avec les applications centrales de l'administration électronique, août 2005 Interopérabilité des applications dans l administration électronique Intégration efficace des applications existantes par le biais des architectures orientées services (SOA), août 2005, ce document. Brochures Simple and Cost-effective Process Integration through Service-oriented Architectures and BPEL Process Management, août 2005 (en anglais) Travailler ensemble pour une administration électronique coopérante Le Laboratoire pour l administration électronique de Fraunhofer FOKUS est un modèle réussi de réseau impliquant les principales parties prenantes dans l administration électronique, et dépassant le cadre de chaque organisation ou entreprise. Par son large spectre de services apportant de nombreux avantages, le Laboratoire offre à ses partenaires et à ses associés une plateforme de grande valeur pour travailler dans le domaine de l administration électronique. Le programme de coopération du Laboratoire pilote des projets de développement pour évaluer des produits et des solutions, ou pour adapter des systèmes propriétaires à des interfaces ouvertes. Il est avant tout conçu pour développer au maximum le potentiel de synergie en exploitant pleinement l expertise de tous les partenaires, et de l équipe FOKUS elle-même. Les avantages de ce travail en réseau sont particulièrement intéressants. Être un partenaire du Laboratoire en administration électronique signifie : accéder aux expertises, aux applications et aux technologies de pointe ; contacter des développeurs, des concurrents, des hommes politiques, des partenaires potentiels et des prospects ; accéder à tous les avantages d un marketing et de relations publiques de qualité professionnelle ; réaliser des économies en partageant des ressources ; participer à des comités réfléchissant à la conception d une administration électronique en Allemagne. Les partenaires du Laboratoire pour l administration électronique Fraunhofer FOKUS sont parties prenantes dans l'administration électronique et à l'écoute de stratégies communes et standards. Ils reconnaissent tous le besoin de solutions et de standards ouverts qui transcendent le fournisseur traditionnel et les frontières technologiques et organisationnelles. Rejoignez-nous! Devenez partenaire! 8 Fraunhofer Institute FOKUS Berlin, août 2005

9 Executive Summary Ce livre blanc sur l interopérabilité entre les applications pour l administration électronique est consacré à l analyse technique de l interopérabilité, à l utilisation des concepts d architectures orientées services, et à la technologie des services Web. L objectif est l intégration des applications existantes dans l administration et la mise en œuvre de processus métier, au-delà des frontières techniques et organisationnelles. Deux aspects principaux sont analysés : La capacité des plateformes de l administration électronique à prendre en charge la définition et la mise en œuvre de services Web, afin de fournir les fonctions spécifiques des services fondamentaux et des applications existantes dans l administration. La capacité de la technologie des services Web à mettre en œuvre les différents types d adaptateurs qui permettront d accéder aux services fournis par les applications existantes dans les sites centraux de l administration électronique. Suite à nos diverses expériences, nous avons remarqué les points suivants : L implémentation d adaptateurs pour les services Web est une approche efficace pour «envelopper» les applications anciennes et existantes avec des interfaces ouvertes. L intégration d applications propriétaires dans les technologies des services Web fondées sur des standards est simple à mettre en œuvre. Les procédures de l administration connectées au Microsoft Solutions Platform E- Government Starter Kit ou à Oracle BPEL Process Manager via des services Web peuvent interopérer avec d autres procédures de l administration existantes sur d autres plateformes. Des processus métier multi domaines peuvent être mis en œuvre de façon relativement efficace lorsqu ils reposent sur des concepts d architectures orientées services, des technologies de services Web et sur le langage BPEL (Business Process Execution Language) qui sait traiter des flux de processus distribués dynamiques. Le déploiement de standards ouverts internationaux comme XML, les services Web et le standard XÖV 1 spécifique aux applications de l administration 1 En Allemagne, un ensemble de standards spécifiques aux applications de l administration est en cours de développement pour définir les processus métier distribués, un modèle d information utilisant XML et l utilisation dans la plupart des cas du protocole de communication OSCI qui permet l emploi de signatures numériques. Les premiers standards incluent le Registre des Fraunhofer Institute FOKUS Berlin, août

10 électronique en Allemagne, permet à des composants en provenance de fournisseurs différents de fonctionner comme des modules indépendants. Ensemble, ces modules créent des infrastructures rationnelles pour l administration électronique. Principaux résultats Les applications anciennes du registre des naissances (AutiSta) et des habitants (Meso) ont été intégrées en utilisant le Microsoft Solutions Platform E-Government Starter Kit 2.0 (.NET/BizTalk2004) et Oracle BPEL Business Process Manager (J2EE) connectés via des services Web. Les scénarios de base démontrent l intégration du processus entre plateformes et entre organisations, ainsi que l utilisation de BPEL. Résultat 1 L intégration d applications propriétaires en utilisant les technologies des services Web fondées sur des standards est simple et rapide à mettre en œuvre. Les interfaces du service ouvert peuvent facilement être exploitées par d autres composants, indépendamment de la technologie (J2EE ou.net) sous-jacente. Résultat 2 Les applications anciennes connectées aux plateformes de l administration électronique et basées sur une architecture orientée service (SOA Service Oriented Architecture) sont capables de coopérer avec des applications mises en œuvre sur d autres plateformes et utilisant elles aussi des standards ouverts comme les services Web. Résultat 3 L interopérabilité entre des plateformes qui utilisent des technologies différentes (Microsoft BizTalk 2004 et Oracle BPEL Process Manager) est réalisée de manière efficace en utilisant la technologie des services Web. Résultat 4 Des structures de processus complexes peuvent être facilement décrites au niveau technique en utilisant BPEL. Il est possible de concevoir des processus particulièrement flexibles pour l utilisation de services externes. La combinaison des standards BPEL, habitants (XMeld), celui des entreprises (XGewerbe) et certaines applications pour l administration, comme la justice (XJustiz), la construction (XBau), etc. 10 Fraunhofer Institute FOKUS Berlin, août 2005

11 XML et services Web autorise une définition et une mise en œuvre efficace de processus métier distribués. Principales recommandations L utilisation des technologies des services Web fondées sur des architectures orientées services (SOA) constitue la meilleure façon de développer des solutions d administration électronique dans des environnements informatiques hétérogènes. Ces technologies permettent la réalisation de flux rationnels dans l administration publique et dans le secteur de l informatique, qui transcendent les frontières traditionnelles technologiques et organisationnelles. La technologie fondamentale pour la réalisation de flux entre organisations est disponible aujourd hui. Elle est prise en charge par de nombreux fournisseurs. Le Laboratoire Fraunhofer FOKUS l évalue dans le Microsoft Solution Platform E- Government Starter Kit qui repose sur la technologie de BizTalk Server Oracle BPEL Process Manager constitue une autre solution qui a aussi été exploitée pour réaliser des scénarios d intégration entre plateformes. Même en utilisant ces outils, les procédures de l administration requièrent toujours une définition des flux ainsi que la standardisation en XML des modèles de données et des structures de données. En Allemagne, la standardisation XML pour diverses procédures spécialisées est réalisée par des standards XÖV spécifiques. Dans un futur proche, le principal problème viendra de la sécurisation des échanges de données entre les utilisateurs et les systèmes centraux via des plateformes ouvertes. La technologie autorise l'emploi de signatures électroniques, comme le protocole de transport allemand OSCI et certains standards XÖV, ainsi que l emploi de solutions de gestion des identités pour le public. De prochains travaux sont déjà planifiés pour analyser ces problèmes relatifs à la sécurité au sein du Laboratoire pour l administration électronique Fraunhofer FOKUS. Note : Ce document a été traduit de l anglais : English Preview Version 1.0, août Une nouvelle version est disponible en allemand et en anglais : version 2.0, mai 2006 et peut être demandée à l adresse suivante : Fraunhofer Institute FOKUS Berlin, août

12 12 Fraunhofer Institute FOKUS Berlin, août 2005

13 1 Introduction 1.1 Objectifs L objectif de Fraunhofer FOKUS consiste à évaluer les technologies et les architectures récentes de l administration électronique, en coopération avec ses partenaires industriels au sein du Laboratoire pour l administration électronique. Puis, il s agira de diffuser les résultats sur ces tests d interopérabilité via des livres blancs et des ateliers. Dans le contexte de l interopérabilité entre applications, les potentiels et les limitations de la technologie des services Web et de l architecture orientée services (SOA) seront explorés par le biais de plusieurs scénarios d essai au sein du Laboratoire Fraunhofer FOKUS. Les objectifs spécifiques ci-dessous ont été ciblés dans nos premiers scénarios de tests sur l interopérabilité entre applications. Ils devaient : introduire l interopérabilité entre applications, c est-à-dire étudier l échange rationnel et simple d informations entre des applications et des composants d infrastructure de l administration électronique (développés avec les technologies J2EE et.net) ; étudier l utilisation des technologies SOA (déjà proposées par de nombreux fournisseurs) pour une intégration efficace ; évaluer la capacité des plateformes de l administration électronique à prendre en charge la définition et la mise en œuvre de services Web et d autres interfaces pour intégrer les fonctions spécifiques des services fondamentaux et des applications existantes de l administration ; évaluer la capacité de la technologie des services Web à mettre en œuvre les différents types d adaptateurs qui permettront d accéder aux services fournis par les applications existantes dans les sites centraux de l administration électronique. 1.2 Étendue La première version du livre blanc dédié à l interopérabilité entre les applications pour l administration électronique a été centrée sur l analyse technique de l interopérabilité. Cela recouvre l utilisation des concepts d architecture orientée services et la technologie des services Web afin d intégrer les applications existantes de l administration, et pour mettre en œuvre des processus métier au-delà des frontières techniques et organisationnelles. Cette version de ce livre blanc reflète l expérience acquise lors de la mise en œuvre et de l évaluation des premiers scénarios au sein du Laboratoire Fraunhofer FOKUS. Il ne couvre pas les aspects suivants de l interopérabilité entre applications (ces aspects seront traités dans de prochaines versions) : Problèmes relatifs à la sécurité lorsque l intégration des sites centraux est réalisée via des réseaux publics Fraunhofer Institute FOKUS Berlin, août

14 Problèmes relatifs à l utilisation des signatures numériques et du protocole OSCI Bien que la sécurité constitue un problème majeur dans le contexte de l'administration électronique, la première mise en œuvre de scénarios ne prend en compte ni le standard allemand OSCI de sécurité ni l utilisation du composant de bureau de poste virtuel actuellement en cours de développement dans le projet BundOnline En effet, ces composants intermédiaires étaient encore en cours de développement à la fin 2004, alors que le premier scénario d essai était initialisé. L évaluation des problèmes de sécurité et l intégration du composant du bureau de poste virtuel seront incluses dans de futures versions de ce livre blanc. D autres livres blancs édités par Fraunhofer FOKUS apporteront des détails sur les exigences des administrations au sujet de l administration électronique, sur les standards, les architectures, les plateformes et les technologies mises en œuvre. Les premiers résultats de l évaluation de l utilisation de systèmes bureautiques compatibles XML sont communiqués dans le livre blanc «Document Interoperability for cooperative egovernment» [Doc-Interop] diffusé par Fraunhofer FOKUS. 1.3 Définitions de termes Cette section définit les principaux termes et concepts utilisés dans ce livre blanc de l interopérabilité entre applications. L interopérabilité désigne la capacité des systèmes des technologies de l information et de la communication (TIC), et des processus métier qu ils mettent en œuvre, d échanger des données et de permettre le partage d informations et de connaissances [IDABC-EIF]. Trois axes doivent être considérés : organisationnel, sémantique et technique. Ce Livre blanc analyse les aspects techniques de l interopérabilité définis par l EICTA comme «la capacité pour deux (ou plusieurs) réseaux, systèmes, équipements, applications ou composants d échanger des informations entre eux et d exploiter les informations ainsi échangées» [EICTA-1]. L interopérabilité des applications dans le contexte d une architecture d administration électronique implique la capacité à échanger des informations (un transfert de données qui peut être sémantiquement interprété) entre des unités fonctionnelles (les composants de l architecture) s exécutant sur des plateformes différentes et exploitant des technologies différentes. Cela sous-entend l utilisation de standards du marché ou de protocoles de communication et de description de données largement répandus. Les principes généraux des concepts d une architecture orientée services (SOA) reposent sur l idée que des systèmes informatiques, des logiciels, des équipements et des services s intégreront et dialogueront entre eux, même s ils n étaient pas conçus pour cela au départ. Les composants hétérogènes d un système d administration publique sont des «boîtes noires», faiblement couplées et communiquant via des services reposant sur des interfaces ouvertes. Une architecture SOA est notamment mise en œuvre en utilisant des services Web. Les applications sont construites comme des ensembles de services coopérants et réutilisables, chaque service étant 14 Fraunhofer Institute FOKUS Berlin, août 2005

15 responsable d une ou de plusieurs tâches, processus métier ou services d'information clairement identifiés. La technologie des services Web repose sur des standards ouverts et est indépendante de la plateforme (.NET, J2EE). Elle est prise en charge par de nombreux acteurs du marché et par la communauté Open Source. Les services Web peuvent être combinés les uns aux autres de différentes manières pour créer des processus métier rationnels. Ces processus assurent l interaction entre les citoyens, les entreprises, les employés et d autres domaines organisationnels à tous les niveaux administratifs. Les services Web intégrés ou ceux offerts par des composants modulaires d applications peuvent être décrits, publiés, situés et invoqués via un intranet ou par Internet. BPEL (Business Process Execution Language) pour les services Web est un langage fondé sur XML, conçu pour permettre le partage de tâches dans un environnement informatique distribué même entre organisations différentes en utilisant une combinaison de services Web. Écrit par des développeurs de BEA Systems, IBM et Microsoft, BPEL combine des constructions du langage de flux WSFL (Web Services Flow Language) des services Web d IBM avec la spécification XLANG de Microsoft. Avec BPEL, un programmeur décrit de manière formelle (abstraite) un processus métier qui prend place sur le Web de telle façon que des entités différentes puissent réaliser une ou plusieurs étapes du processus. Au-delà des descriptions des flux, BPEL sait aussi décrire la connectivité des services réels. Le chapitre 8 donne d autres définitions et le chapitre 7 regroupe certaines abréviations. 1.4 Groupes cibles Le lectorat ciblé par ces livres blancs et par les résumés publiés par Fraunhofer FOKUS est constitué par les responsables des projets de l administration électronique, à tous les niveaux du gouvernement allemand, les administrations des états membres, les organismes de l Union européenne et les responsables des entreprises et des organisations non gouvernementales (ONG) engagées dans des projets d'administration électronique. Une autre cible regroupe les fournisseurs de services, les fournisseurs de solutions, les intégrateurs de systèmes intéressés par l interopérabilité de leurs produits dans le contexte de l administration électronique. Les groupes cibles doivent être familiarisés avec les concepts et les opportunités des standards ouverts, des interfaces ouvertes, des architectures orientées services et des tests d intégration et d interopérabilité. Ils doivent avoir une idée des avantages que les technologies SOA peuvent apporter en termes d intégration dans les systèmes hétérogènes de l administration électronique. Les résumés sont plutôt destinés aux responsables et aux dirigeants tandis que les livres blancs, plus techniques, sont écrits pour les responsables de projets et les décideurs. Fraunhofer Institute FOKUS Berlin, août

16 16 Fraunhofer Institute FOKUS Berlin, août 2005

17 2 Scénarios métier pour des tests d interopérabilité entre applications Ce chapitre présente les scénarios d'essais initiaux, réalisés dans le Laboratoire Fraunhofer FOKUS et choisis en coopération avec nos partenaires industriels. Ces scénarios visent à démontrer les opportunités offertes par les standards ouverts, ainsi que les capacités des architectures orientées services et de leurs technologies associées. Les concepts sous-jacents peuvent être adaptés à de nombreux autres scénarios. Ils sont exploitables par des administrateurs, des intégrateurs de systèmes et des fournisseurs de l administration, pour mettre en œuvre, de façon plus efficace et moins onéreuse qu auparavant, des solutions complexes destinées à l administration électronique. 2.1 Scénarios de départ pour le test du Service aux citoyens Un ensemble de scénarios test a été mis en œuvre pour analyser l interopérabilité, l utilisation des architectures SOA, les services Web, l intégration des applications anciennes et l'implémentation de processus métier au-delà des limites techniques et organisationnelles. Cela a nécessité la mise en place de deux villes virtuelles au sein du laboratoire. Tous les scénarios d essais spécifiques font référence au premier scénario de service général offert aux citoyens : certificats de résidence, d état civil, de naissance, de mariage et de décès. Figure 1 Demande d un certificat de naissance auprès du registre de l état civil. Un ensemble de processus métier a été implémenté dans le laboratoire FOKUS. Les processus sont semblables à ceux présents dans le monde réel. La figure 1 montre le flux des informations pour le processus «Demande d un certificat de naissance». Fraunhofer Institute FOKUS Berlin, août

18 Dans un processus administratif, il existe généralement différents rôles tels que «citoyen» et «employé administratif» (agent). Ces rôles sont en rapport avec des utilisateurs, des plateformes de services de l administration, un ou plusieurs systèmes centraux (comme les registres d état civil, des habitants et des entreprises), et avec des composants fondamentaux comme les services de formulaires et de paiement électronique (figure 1). Dans ce scénario, le flux d information circule ainsi : un citoyen a besoin d un certificat de naissance. Il formule sa demande. Pour cela, de nombreux moyens sont à sa disposition : butineur Web, logiciels bureautiques et clients légers. Le fait de remplir un formulaire et de l envoyer au service de l administration démarre le processus. Après une étape d authentification et d autorisation, la plateforme du service initialise le processus administratif en respectant les règles métier. L employé administratif reçoit le formulaire du citoyen, et le valide ou non. Après approbation, l application envoie une demande au serveur de paiement. Le citoyen doit alors fournir les données de sa carte de crédit. La demande est ensuite transmise au système central qui émet le certificat de naissance. Enfin, le certificat est envoyé soit par voie postale soit via Internet sous la forme d un document électronique. 2.2 Scénario 1: Interopérabilité des applications Concepts pour l intégration des systèmes anciens Le scénario repose sur le processus «Demande d un certificat de naissance» décrit à la section précédente. Les composants de ce scénario ont été conçus afin d évaluer l utilisation des plateformes de l administration et l intégration des applications anciennes avec l utilisation des services Web, les systèmes de gestion des flux et les technologies d exécution métier. Le premier scénario met en scène diverses technologies d accès (Microsoft Word 2003 Professionnel, OpenOffice Writer, interfaces Web ASP.NET ou JSP) qui font office de systèmes frontaux pour fournir les formulaires, les mécanismes de validation et ceux de gestion des erreurs. L intégration entre le service frontal et le système central couvre les problèmes suivants : Concevoir des pages de formulaires (système frontal) afin d inclure des fonctions spécifiques telles que la prise en charge de schémas XSD pour des validations automatiques (Microsoft InfoPath). Intégrer des fonctionnalités de base (côté client) et d authentification de l utilisateur (par exemple l ajout de formulaires pour les informations de paiement par l utilisateur). Connecter le client à la plateforme de l administration tout en respectant des conditions transactionnelles (par exemple l affichage des résultats en mode 18 Fraunhofer Institute FOKUS Berlin, août 2005

19 duplex), des conditions de sécurité (par exemple l utilisation d OSCI) ou des détails techniques (par exemple la pile des protocoles). Intégrer des mécanismes d approbation pour une pré-validation des données transmises par l employé administratif. Intégrer des processus de transformation de données afin de faire correspondre les données de l utilisateur avec le format propriétaire utilisé par l application centrale. Intégrer l'application centrale en utilisant une technologie d'adaptateur de service Web en ligne, tout en spécifiant l'interface. Figure 2 Infrastructure du laboratoire pour des scénarios d interopérabilité entre applications. Pour ce scénario, deux plateformes destinées à l administration publique et fournies par des partenaires du laboratoire Fraunhofer FOKUS, ont été exploitées : la solution Microsoft E-Government Starter Kit et celle d Oracle, BPEL Business Process Manager. Le système du registre d état civil «AutiSta» et celui du registre des citoyens, «Meso», ont été choisis en tant qu applications de l administration. Le chapitre 4 décrit en détail la technologie utilisée dans ces scénarios. Le scénario démontre : comment des adaptateurs de type services Web peuvent être définis et mis en œuvre sur diverses technologies, pour créer les services requis dans le but d intégrer des applications anciennes de l administration dans un processus métier distribué ; comment des applications anciennes spécifiques peuvent être adaptées ou «ouvertes» pour fournir les fonctionnalités requises au niveau de l'interface du service Web. Fraunhofer Institute FOKUS Berlin, août

20 Sur la figure 2, les ellipses mettent en évidence deux centres d intérêt : les interfaces du service Web, fournies par les adaptateurs des applications centrales existantes, et développées pour offrir les fonctions des applications de l administration ; les options pour l intégration des différentes applications de l administration via les adaptateurs d application, développés pour offrir à l environnement extérieur des fonctions internes des applications de l administration via les interfaces des services Web. La section 5.3 montre comment ces aspects ont été évalués dans le scénario d essai. 2.3 Scénario 2: Processus métier distribué au-delà des frontières techniques et organisationnelles Dans le second scénario, nous avons construit deux administrations distinctes afin de montrer comment l interopérabilité fonctionne quand deux municipalités différentes sont impliquées dans un processus métier distribué. Nous avons choisi deux environnements différents sur le plan technologique, avec des plateformes distinctes. Figure 3 Processus métier coopératif distribué au-delà des frontières techniques et organisationnelles. La municipalité A est équipée avec une infrastructure J2EE et Oracle BPEL Process Manager. La municipalité B est pourvue d une infrastructure.net et du Microsoft E- Government Starter Kit avec BizTalk2004. La loi allemande stipule que seule la ville de naissance d une personne est autorisée à émettre un certificat de naissance. Si le citoyen est né dans la ville B et habite dans la ville A, les deux villes doivent échanger des informations dans le cadre de l application «Demande de certificat de naissance». 20 Fraunhofer Institute FOKUS Berlin, août 2005

21 La section 3 décrit le scénario de transfert plus en détail. Elle montre comment la technologie actuelle des services Web comme traduction de l'architecture SOA peut servir à connecter deux flux locaux à travers les frontières de domaines, ce qui conduit à la réalisation d un processus multi domaine. Fraunhofer Institute FOKUS Berlin, août

22 22 Fraunhofer Institute FOKUS Berlin, août 2005

23 3 Présentation des technologies déployées Cette section présente les technologies et les produits utilisés dans les scénarios tests du Laboratoire Fraunhofer FOKUS. Ces composants et produits sont en rapport avec l architecture de l administration électronique de référence qui est développée par Fraunhofer FOKUS et décrite dans la figure ci-dessous. Figure 4 Architecture mise en place pour les tests d interopérabilité. La liste suivante répertorie les composants utilisés dans l environnement de l administration électronique des premiers scénarios. Ces composants sont décrits plus en détail dans les prochaines sections. Service Web et architecture SOA destinés aux plateformes de l administration électronique Microsoft E-Government Starter Kit 2.0 (.NET, Biztalk2004) Oracle BPEL Process Manager (J2EE) Applications de l administration Registre des habitants (Fachverfahren Einwohnerwesen Meso) Registre de l état civil (Fachverfahren Personenstandswesen AutiSta) Registre des entreprises (Fachverfahren Gewerberegister Migewa). Ce composant fait partie de l environnement du laboratoire mais n est pas utilisé dans le scénario de demande d acte de naissance. Fraunhofer Institute FOKUS Berlin, août

24 Services élémentaires Serveur de formulaires FormsForWeb (Lucom) Clients (utilisateurs) Ils sont décrits plus en détail dans le livre blanc «Interopérabilité des documents» [Doc-Interop]. Butineur Web Microsoft Office Word Édition Professionnelle 2003 Writer d OpenOffice.org 3.1 Technologies de plateforme pour l administration électronique, orientées service Microsoft E-Government Starter Kit pour l administration publique Ce Microsoft E-Government Starter Kit a été spécialement développé pour l administration publique allemande, pour les niveaux local (villes), régional (Länder) et national. Son approche intégrée en fait la solution de plateforme idéale pour toutes les organisations publiques qui souhaitent mettre en œuvre des services électroniques interdépartementaux. Les applications spécialisées existantes peuvent être connectées au Web et leurs services, incorporés dans un intranet ou Internet. En utilisant le Starter Kit et les technologies serveur Microsoft appropriées, l interopérabilité peut être obtenue entre administrations et entreprises. Divers environnements systèmes et des applications spécialisées peuvent être intégrés pour donner naissance à des environnements informatiques hétérogènes communicants. Tout cela est rendu possible par l utilisation de standards internationalement reconnus et des services Web. De concert avec les technologies serveur Microsoft appropriées, le Starter Kit permet la mise en place de services électroniques interdépartementaux sécurisés. Ainsi, des processus de gestion automatisés, l intégration d applications spécialisées ou l échange de données avec d autres autorités ou des entreprises peuvent être développés dans des délais très courts grâce au Starter Kit. Capable de monter en charge, le Starter Kit peut parfaitement servir de base pour des services d administration électronique supplémentaires. Le Starter Kit constitue une solution qui utilise des technologies éprouvées comme Microsoft BizTalk Server 2004 pour l intégration d applications et l orchestration, Microsoft SQL Server 2000 pour des stockages fiables et évolutifs, et.net 1.1 comme plateforme de développement et d exécution d applications. 24 Fraunhofer Institute FOKUS Berlin, août 2005

25 3.1.2 Oracle BPEL Process Manager (technologie J2EE) Oracle BPEL Process Manager est un logiciel servant à décrire les processus en langage BPEL (Business Process Execution Language). Un outil de conception est fourni pour décrire l orchestration du processus métier. La plus grande partie de travail s'effectue ainsi de façon graphique. Pour communiquer avec des services et des applications centrales durant l exécution du processus, plusieurs interfaces sont fournies, incluant des services Web, l architecture de connecteur Java, une messagerie et des services de messages Java. Un outil de contrôle affiche les processus en cours d exécution et gère les tâches de gestion. Entièrement écrit en Java, ce logiciel est fondé sur des descriptions de service WSDL et peut s'exécuter sur la grande majorité des serveurs d'applications Technologies des applications de l administration publique Les scénarios d essais mis en œuvre au Laboratoire d administration électronique Fraunhofer FOKUS à Berlin, se concentrent sur deux applications importantes pour les municipalités en Allemagne : le registre de l état civil et le registre des habitants. Un service orienté transaction a aussi été mis en œuvre au sein du laboratoire pour le registre des entreprises. Ce dernier n'est pas exploité dans le scénario des certificats de naissance mais il est important dans le cadre de l'intégration des systèmes anciens. Les prochaines sections présentent ces applications, au cœur des tests sur l interopérabilité. Ces applications, spécifiques à l Allemagne, ont été choisies pour les tests en raison des différents concepts d intégration qu elles suggèrent, ces concepts pouvant ensuite être exploités dans des approches d intégration plus générales pour de nombreuses autres applications. Les fonctionnalités et principes décrits ici ne sont liés à aucun produit spécifique. Dans les scénarios de démonstration, toutes les applications centrales peuvent être remplacées par des solutions proposées par d autres fournisseurs Registre des habitants (application Meso) Meso est une application de type client-serveur conçue pour être déployée dans les bureaux de l état civil. Le client Meso est une application Windows qui exploite les fonctionnalités proposées par les systèmes d exploitation modernes et par les suites bureautiques. L application serveur (fonctionnant sur Windows ou Linux) exploite des bases de données relationnelles pour enregistrer les données des habitants et en garantir l intégrité. Meso est équipé d interfaces pour un logiciel de finances, pour le processus de certification des habitants (comme AutiSta), et pour d'autres applications exploitant la définition de schéma XML ouvert, «XMeld», qui permet l intégration interprocessus au sein de procédures administratives. Fraunhofer Institute FOKUS Berlin, août

26 Comme il est également nécessaire d'intégrer les services encapsulés fournis par les bureaux de l'état civil dans de nombreux autres processus du secteur public ou des entreprises, Meso représente le candidat idéal pour nos tests Registre de l état civil (application AutiSta) AutiSta est une application centrée sur les processus de certification de l état civil des habitants. Au-delà de la gestion des certificats de naissance, de mariage et de décès, l application peut aussi prendre en charge des problèmes relatifs aux successions et aux unions civiles. AutiSta fournit des fonctionnalités fondamentales comme la gestion des recherches et des listes, l analyse des résultats de traitements, et la gestion des statistiques internes à destination de plusieurs établissements gouvernementaux. Des interfaces pour des services comme les autorités fiscales ou les hôpitaux ont aussi été mises en place en exploitant des standards ouverts XML. Nous avons choisi AutiSta pour nos scénarios d intégration en raison de son utilisation généralisée au sein de l'administration allemande. De nombreuses idées, apparues lors des tests, pourraient facilement être transférées dans des scénarios du monde réel Registre des entreprises (application Migewa) Migewa repose sur une architecture client-serveur pour enregistrer les entreprises dans les sites centraux de l administration. Il s agit d une application Windows, simple à utiliser, qui présente les données des entreprises sous la forme de listes détaillées ou d arborescences. Elle accepte de nombreux clients. Des interfaces ont été créées pour la comptabilité, l enregistrement des habitants et des systèmes d informations géographiques. Une utilisation indépendante des systèmes frontaux est rendue possible par l utilisation d un schéma XML, XGewerbe, qui standardise dans toute l'allemagne la définition de l'interface. 3.3 Services fondamentaux Les prochaines sections présentent les composants fondamentaux utilisés dans les tests sur l interopérabilité Service de formulaires (FormsForWeb) La solution FormsForWeb de Lucom est la technologie mise en œuvre au niveau fédéral dans le composant «Form Server» déjà implémenté dans le contexte de l initiative Bund Online Elle fournit une interface à un service de formulaires qui permet aux habitants, aux entreprises et aux administrations d obtenir des informations pour des processus 26 Fraunhofer Institute FOKUS Berlin, août 2005

27 métier. XML est largement mis à contribution afin de simplifier les processus d'entrée des informations. La technologie FormsForWeb propose des masques de saisie, un support en ligne et une validation des données, même durant la saisie. Le client de FormsForWeb se résume à un butineur Web. Il exploite des masques d écran comparables aux formulaires papier standards. Il envoie des requêtes aux plateformes de l administration électronique, aux systèmes d exécution des processus et aux applications de l administration. Il vérifie la cohérence des données avant traitement. L application FormsForWeb s'intègre dans des infrastructures Web. Elle fonctionne sur n importe quel serveur Web ou serveur d application qui prend en charge la plateforme Java (J2EE). Elle stocke les données du formulaire dans n importe quelle base de données SQL équipée du pilote JDBC idoine. L'application est aussi pourvue d'une interface de service Web XML qui permet des échanges bidirectionnels de données avec des composants externes. D autres modules Java s intégreront dans FormsForWeb pour adapter ou étendre ses fonctionnalités. Dans le scénario d essai, FormsForWeb représente une des technologies d accès Service de paiement électronique dans EGSK L interface de paiement électronique dans Microsoft EGSK est un service fondamental qui peut être intégré dans tout nouveau processus. Elle permet l acquisition des données relatives au paiement pour un utilisateur qui sollicite un service payant. Parmi les paiements possibles, citons le débit direct, le transfert interbancaire après notification du montant, et l envoi de facture. Le module génère des reçus imprimables et fournit à l utilisateur des informations sur l état de son règlement. Des identificateurs de transactions permettent au module de s intégrer dans divers services financiers externes. Grâce à la journalisation des transactions SQL, des interfaces avec des systèmes de paiement tiers ont été réalisées, à la fois sous la forme de services Web et de partage de données. Dans la version initiale du test, les services de paiement électronique ont uniquement été simulés. De futurs essais intégreront totalement ces services, y compris la «Zahlungsverkehrsplattform» (plateforme de transaction de paiement), un composant développé dans le cadre de l initiative BundOnline Fraunhofer Institute FOKUS Berlin, août

28 28 Fraunhofer Institute FOKUS Berlin, août 2005

29 4 Mise en œuvre des scénarios d interopérabilité Ce chapitre décrit les concepts pour l intégration des applications anciennes en utilisant des services Web. La section 4.1 décrit les concepts généraux pour la définition des services Web et des structures d informations XML. La section 4.2 répertorie et analyse les concepts généraux pour l intégration des applications anciennes. Suite aux tests décrits au chapitre 3, l intégration des applications AutiSta et Meso est décrite en détail. Le scénario de test pour l intégration de l application Migewa est également abordé. La section 4.3 décrit la mise en œuvre des processus métier distribués entre deux organisations (deux municipalités), l une exploitant la technologie.net (Microsoft EGSK 2.0 / Biztalk2004), l autre utilisant J2EE (Oracle BPEL Business Process Manager). 4.1 Définition des interfaces de services Web La figure 5 décrit l environnement de test au sein du laboratoire Fraunhofer FOKUS. L arc de cercle met en évidence les interfaces services Web pour les adaptateurs des applications anciennes. Ces interfaces permettent l accès aux fonctions des applications de l administration, cet accès étant nécessaire pour réaliser des processus métier distribués. Figure 5 Implémentation des interfaces services Web. Afin de développer un adaptateur service Web pour intégrer des applications anciennes dans un environnement d administration électronique, plusieurs étapes sont nécessaires. Nous en donnons un aperçu dans la liste ci-dessous. Des conseils détaillés sortent du cadre de ce livre blanc. Cette liste décrit les principales étapes qu un intégrateur devrait suivre. Identification du contexte général du processus métier Fraunhofer Institute FOKUS Berlin, août

30 Éclatement du processus en unités fonctionnelles plus petites Identification des standards techniques (par exemple OSCI) et spécifiques à l administration (par exemple XÖV, XMeld, et XGewerbe) Identification et définition des services devant être fournis par des composants informatiques spécifiques, en utilisant si possible la définition de service standard XÖV Spécification de l interface du service Web (fonction, arguments, résultats) Technologie retenue (.NET ou J2EE) Identification des logiciels existants Codage et mise en œuvre du service Web Test et déploiement Pour des projets d intégration spécifique, ces étapes doivent être affinées et adaptées en conséquence. Les prochains paragraphes présentent de façon générale le processus de développement standard pour des composants logiciels. Phase d identification des besoins Cette phase facilite la compréhension du processus métier lui-même. L objectif principal est l identification et la définition des besoins du processus afin de traduire ces besoins en cahier des charges pour le service Web, en modélisant les informations et l aspect fonctionnel. Les problèmes techniques ne sont pas à prendre en considération à ce stade. Phase de conception Cette phase décrit de façon très détaillée l interface du service Web. Elle se situe au tout début du processus de développement. Les éléments et les types de données appropriés sont définis, ainsi que le mode d interaction des services Web (par exemple synchrone ou asynchrone, RPC ou document). Des techniques de définition de structures, comme des schémas XML, renforcent les définitions pour les éléments de données transactionnelles. Des critères spécifiques à la plateforme sont aussi pris en compte afin de simplifier le codage futur (par exemple, choisir des types de données compatibles avec la plateforme choisie). Phase de codage La phase de codage et de débogage est comparable à celle d un processus de développement standard en informatique. Elle couvre la génération de proxys client en utilisant WSDL pour la plateforme choisie. 30 Fraunhofer Institute FOKUS Berlin, août 2005

31 Phase de test et de déploiement Les tests côté client sont effectués sur différentes plateformes, principalement pour tester l intégrité des fichiers WSDL et l interopérabilité des différents types de données et structures. Idéalement, les clients doivent être testés sur toutes les plateformes cibles possible. Les tests des fonctionnalités d un service Web utilise des cas standards issus d autres processus de développement. L étape finale consiste à passer une commande via le service Web et à exécuter quelques autres tests après déploiement pour vérifier que le service est pleinement opérationnel. 4.2 Intégration du modèle des applications anciennes Cette section décrit un ensemble d options spécifiques pour l intégration d applications anciennes fondée sur l environnement actuel d essai du Laboratoire FOKUS. Objectifs Évaluation de l intégration d une application existante via des services Web avec un adaptateur.net et EGSK 2.0, fourni à l origine dans la distribution EGSK 2.0. Intégration d une application existante via des services Web avec un adaptateur J2EE et EGSK 2.0. Évaluation de l intégration d une application existante via des services Web avec un adaptateur J2EE et Oracle BPEL Process Manager (qui utilise J2EE). La figure 6 décrit l environnement de test pour cette section au sein du laboratoire Fraunhofer FOKUS. L ellipse montre que l intégration des applications existantes est obtenue par la mise en place d adaptateurs spécifiques à chaque application, développés pour fournir les fonctions internes de ces applications via des services Web ouverts, comme l exige des processus d administration distribués. Dans l environnement d essai du laboratoire Fraunhofer FOKUS, différentes applications de l administration ont été intégrées via des services Web dans deux plateformes différentes, l une exploitant.net, l autre J2EE. Des adaptateurs ont été mis en œuvre pour fournir des services à des processus métier multi domaines via des interfaces de services Web, ouvertes et bien définies. En outre, diverses options sont disponibles pour ouvrir les applications existantes à des processus métier spécifiques. Cette approche par adaptateur de type service Web permet à d autres applications d accéder facilement aux fonctions et aux données des applications de l administration, en déployant des services Web qui s appuient sur des protocoles standardisés et des interfaces ouvertes. Les méthodes d intégration des applications ne se limitent pas aux quatre décrites cidessous. C est en raison des systèmes que nous utilisons dans le Laboratoire FOKUS que nous n avons pris en compte que ces quatre méthodes dans ce livre blanc. Fraunhofer Institute FOKUS Berlin, août

32 Les applications standards en Allemagne au niveau local comme AutiSta et Migewa emploient une technique de «corbeille». Dans ce cas, l application existante lit un fichier de requête ou d entrée (par exemple un fichier plat, XML ou CSV) dans un dossier. L adaptateur de type service Web doit transformer la requête dans le format attendu par l application cible, avant de placer le fichier résultant dans la «corbeille». La deuxième méthode que nous avons testée consiste à exploiter un accès direct à une base de données. Dans ce cas, l application fournit une interface à une base de données (propriétaire ou standard en open source), comme c est le cas pour Meso, l application du registre des habitants. Figure 6 Intégration des applications existantes de l administration publique. La troisième méthode exploite les interfaces disponibles de protocoles anciens comme CORBA et adapte ces protocoles à un service Web. Cette option est intéressante car de nombreuses implémentations CORBA existent encore, ce qui signifie qu une classe CORBA est déjà existante pour créer un service Web facilement et à moindre coût. La quatrième méthode concerne les applications fournies avec leurs propres API (interfaces de programmation) propriétaires, «enveloppées» dans des bibliothèques écrites en C. Dans ce cas, ces bibliothèques doivent être compilées sur la plateforme cible spécifiée, pour devenir des fonctions locales fournissant ainsi une voie d intégration des fonctionnalités de l application dans le cadre de travail de l utilisateur. Les services Web offrent de nombreux avantages vis-à-vis de toutes les autres voies d intégration. Le protocole standardisé SOAP et des fonctionnalités comme WSDL peuvent être facilement implémentés dans presque tous les langages de programmation de haut niveau. Idéalement, l application cible ancienne devrait offrir 32 Fraunhofer Institute FOKUS Berlin, août 2005

33 une interface de service Web, encapsulant ses fonctionnalités en utilisant les standards XÖV publics prédéfinis. Si ce n est pas le cas, l application exploitant par exemple une communication via le système de fichiers, par des canaux nommés ou des files d attente de messages (cas fréquent), un adaptateur de type service Web peut alors envelopper les fonctions proposées par l application et les exposer via des interfaces XÖV standards. L idée consiste à envoyer les données de la requête sous la forme d un appel de méthode d un service Web, appel effectué au niveau de l adaptateur de l application. Les échanges de données s effectuent via l interface locale de l application cible. Des services Web mis en œuvre sur les plateformes.net et J2EE peuvent exploiter toutes les possibilités de ces plateformes. Les données peuvent être transformées, extraites ou manipulées de nombreuses manières, la logique de l adaptateur pouvant être placées dans un service Web spécifique. Idéalement, le format de transfert devrait être XML compte tenu de la richesse des API XML à la fois dans.net et J2EE. Les prochaines sections décrivent en détail deux options mises en œuvre dans notre Laboratoire Intégration d Autista, l application du registre de l état civil Ce scénario décrit l intégration de l application du registre d état civil, AutiSta. Un adaptateur pour service Web est livré pour cette application dans le Microsoft E- Government Starter Kit. Le concept est le suivant : le citoyen produit une requête XML fondée sur un schéma XSD, en utilisant une des technologies client décrites ci-dessus. La requête est transmise à la plateforme de l administration électronique qui agit comme un répartiteur en effectuant les tâches suivantes : Accepter la requête via un service Web et extraire les arguments transmis. Organiser le flux du traitement en intégrant diverses fonctions de base comme les mécanismes d approbation ou les modules de paiement. Transformer les données de l utilisateur (la «charge utile») dans le format d importation propriétaire de l application cible. Faire appel à l adaptateur de l application cible pour lui transmettre la requête dans un format compatible. Dans EGSK 2.0, l adaptateur de l application AutiSta est implémenté dans un service Web.NET. Pour prouver le concept d interopérabilité, nous avons simplement changé l adaptateur et nous l avons adapté à un environnement J2EE par reverse engineering (ingénierie inverse). Il n a pas été nécessaire de définir une nouvelle interface pour cet adaptateur J2EE. Puisque nous avions déjà produit un fichier WSDL à partir du service Web.NET d origine, les phases Identification des besoins et Conception du processus de développement ont été réalisées très simplement. Avec un schéma XSD couvrant tous Fraunhofer Institute FOKUS Berlin, août

34 les messages XML d'appel, nous n'avons eu aucun problème à faire fonctionner le service avec les données transmises. Figure 7 Diagramme de la séquence UML du flux d information. Et comme nous connaissions bien le schéma, nous aurions pu facilement le mettre en œuvre en exploitant les API XML de J2EE. L adaptateur doit principalement effectuer les tâches suivantes : Accepter la requête en provenance de la plateforme de l administration électronique, et en extraire les arguments de l appel. Transformer le message XML structuré afin de tenir compte des différences de versions dans le format d importation d AutiSta. Placer le fichier résultant dans le dossier d'importation d'autista. L intégration du nouvel appel de service dans le flux de traitement approprié de BizTalk s est fait très facilement : nous avons eu juste besoin d une description du service dans le format WSDL et d une URL correspondante pour signaler le nouveau service au système. Le standard ouvert de service Web encapsule la plateforme (.NET / J2EE) de notre nouveau service. 34 Fraunhofer Institute FOKUS Berlin, août 2005

35 Le modèle d intégration de la figure 8 montre comment des services Web standardisés dotent des plateformes différentes d une excellente interopérabilité. Figure 8 Utilisation de services Web pour la transformation de données et l intégration d application. Une approche similaire a été déployée pour connecter le système ancien à Oracle BPEL Process Manager Intégration du Registre des habitants Meso (intégration de base de données) Des applications qui ne fournissent que des services traitant des informations sans processus transactionnels complexes peuvent s intégrer avec des applications existantes en accédant au même entrepôt de données. L intégration de l application ancienne «Meso» (gestion du Registre des habitants) en constitue un bon exemple. Figure 9 Exemple de mise en œuvre avec une technologie de miroir. Cette façon d intégrer des applications existantes est très simple à mettre en œuvre. Les requêtes élémentaires sur la base de données peuvent être encapsulées dans des objets DAO (Data Access Objects) et exécutées sur la plupart des plateformes car des pilotes pour bases de données existent dans pratiquement tous les langages de haut Fraunhofer Institute FOKUS Berlin, août

36 niveau. La plupart des bases de données prennent en charge un modèle complexe rôle/utilisateur qui permet de mettre en œuvre la sécurité en appliquant des restrictions de type «lecture seule» ou des règles d accès plus complexes. Des contraintes légales et des obligations de sécurité du réseau impliquent le renforcement de ce dispositif, jugé insuffisant. Une base de données en miroir doit être utilisée afin de respecter les contraintes légales. Les données peuvent ainsi être transformées et filtrées lors du processus de mise en miroir afin de créer une vue restreinte des données, réservée aux accès externes. Le miroir évite aussi l'apparition de goulets d'étranglement sur la base de données principale. La base de données miroir et l interface de service Web sont employées pour connecter l'application Meso à Oracle BPEL Process Manager Intégration du Registre des entreprises Migewa Cette section décrit une troisième intégration développée par le Laboratoire FOKUS mais ne faisant pas partie du scénario de demande d un certificat de naissance. L intégration de l application Migewa ressemble beaucoup à la technique d intégration utilisée pour AutiSta décrite ci-dessus. Migewa gère un dossier de fichiers XML comme une «corbeille» pour importer les données à traiter. Le format de ces données est dérivé de la définition du schéma XML public XGewerbe et enveloppe les trois variantes possibles : a) enregistrement d une entreprise, b) suppression d une entreprise, et c) modification des données d une entreprise. Un autre service offert par Migewa consiste bien sûr à fournir des informations sur une entreprise enregistrée. Cela n est pas représenté dans le schéma XGewerbe mais a été mis en œuvre en utilisant un schéma auto défini dérivé des définitions XGewerbe. Malgré la grande complexité du formulaire de l application frontale de Migewa et du XML associé, nous n avons rencontré aucun problème pour connecter notre frontal avec BizTalk Server. Nous avons principalement inclus le schéma externe XGewerbe (défini par les normes DIN) dans le schéma EGSK Microsoft et nous avons déclaré le nouvel espace de noms dans le schéma. BizTalk Server gère la requête lors du processus d enregistrement et la transmet à l'application Migewa. En raison de l existence de quelques différences mineures entre le format d importation de Migewa et la spécification XGewerbe, nous avons dû transformer les données transactionnelles en utilisant le mappeur BizTalk, un outil qui génère rapidement des règles de transformation XSL à partir d'une application graphique frontale. L adaptation de Migewa à Oracle BPEL Process Manager devrait s effectuer facilement puisque les définitions de schémas et l implémentation du service Web ont déjà été réalisées pour EGSK de Microsoft. 36 Fraunhofer Institute FOKUS Berlin, août 2005

37 4.3 Mise en œuvre de processus métier distribués au-delà des frontières techniques et organisationnelles Comme nous l avons expliqué à la section 1.1, nous avons développé un scénario entre deux municipalités afin d analyser la mise en œuvre de processus multidomaines, en exploitant la technologie des services Web. Dans ce contexte de coopération entre deux villes, il n est pas nécessaire de fournir chaque service d une municipalité à l autre ville. Une municipalité peut devenir un centre de compétences pour une application spécifique et fournir, par conséquent, un service à plusieurs municipalités de sa région. Bien que nous ayons mis en œuvre ce scénario entre deux municipalités, les mêmes étapes s appliqueraient à différentes entités administratives participant à un scénario d intégration. Ce scénario met en évidence trois aspects importants : Mise en œuvre de processus métier entre municipalités Utilisation de deux applications de l administration publique dans un même processus distribué Utilisation de différentes technologies de plateformes dans un même processus distribué Figure 10 Interopérabilité des applications au-delà des frontières techniques et organisationnelles. Dans une première étape, nous avons défini les structures de données et les processus locaux à chaque municipalité, utilisés lors des demandes de certificats de naissance. Pour faciliter les futurs échanges d information, nous avons défini un schéma XML Fraunhofer Institute FOKUS Berlin, août

38 unique pour toutes les données nécessaires à l exécution du processus. Ce schéma est utilisé par nos deux villes virtuelles. En appliquant un seul schéma, nous évitons la transformation des structures d information lors du passage de données d une ville à l autre. Nous recommandons le choix d un schéma standardisé (XÖV) ou l entente autour d un schéma commun chaque fois que cela est possible. Puis nous avons analysé les processus de chaque municipalité pour identifier où et quand l échange d'informations entre les deux villes est nécessaire. Nous avons décidé de transmettre une «requête» au début du processus. Mais nous aurions pu choisir un autre instant dans le processus. En fait, ce choix dépend de la tâche à accomplir. Nous avons vu précédemment que la technologie employée pour la plateforme (.NET ou J2EE) ne constitue pas un problème lorsqu il s agit d échanger des informations via des services Web. Puisque les deux plateformes proposent des interfaces de services Web, nous pouvons donc employer ces services pour échanger des informations à n importe quel moment au cours du processus. Même l utilisation de langages différents pour décrire le processus ne crée pas de problème d'interopérabilité. Voici les étapes à suivre pour assurer l interopérabilité entre deux organisations : Définir le processus administratif. Identifier les tâches à accomplir, les flux, les diverses fonctions à mettre en œuvre et la prise en charge des sources externes. Utiliser un schéma public standard (par exemple le standard XÖV en Allemagne) chaque fois que cela est possible. Sinon, définir votre propre schéma avec vos partenaires afin de simplifier au maximum l échange d informations. Employer les interfaces exportées par les services pour accomplir la tâche. Si de telles interfaces ne sont pas disponibles, employer les techniques décrites précédemment pour créer des adaptateurs. Définir des interfaces de services Web pour votre propre processus si vous souhaitez offrir certaines de ses fonctions au monde extérieur. Finalement, étudier l utilisation d un environnement d exécution afin de bénéficier d une plus grande souplesse lors de nouvelles créations, de modifications et de transformations. Dans le cadre de notre scénario, cette stratégie fonctionne dans les deux sens : de la technologie Microsoft.NET vers celle d Oracle, J2EE/BPEL, et vice versa. Les langages de description de processus utilisés sont à la fois capables de prendre en charge les erreurs et d'annuler/inverser des actions terminées («compensation»). L analyse du fonctionnement entre deux entités administratives est actuellement en cours d évaluation, l idée étant de parvenir à échanger des descriptions de processus abstraites. Cela conduira à la réutilisation des descriptions de processus qu il suffira d adapter aux interfaces des services locaux pour que ces processus deviennent disponibles de façon dynamique. Il s agira là d une grande avancée : nous ne nous contentons pas de standardiser des structures de données XML mais aussi des définitions de processus en utilisant le langage ouvert et très répandu qu'est BPEL. 38 Fraunhofer Institute FOKUS Berlin, août 2005

39 5 Expérience obtenue de ces tests Leçons apprises et recommandations Cette section résume l expérience que nous avons acquise lors de nos essais et de nos tests au sein du Laboratoire Fraunhofer FOKUS. Ces conclusions devraient être prises en considération à tous les niveaux de la planification et de la mise en œuvre de projets d administration électronique. Nous décrivons ici nos principales conclusions en faisant référence aux résultats que nous avons obtenus lors de nos expérimentations. 5.1 Expérience pratique Faciliter l interopérabilité entre les applications de l administration L utilisation des services Web permet une interopérabilité efficace entre diverses plateformes, entre services fondamentaux et entre applications de l'administration. L interopérabilité reste efficace même lorsque les applications et les plateformes emploient des technologies différentes (comme Java et.net). Les deux plateformes testées celle de Microsoft, E-Government Starter Kit (EGSK), et celle d Oracle, BPEL Process Manager, prennent toutes deux en charge l'approche SOA (Service-Oriented Architecture) et reconnaissent les standards utilisés pour les services Web. Les applications de l administration liées aux plateformes compatibles SOA peuvent dialoguer entre elles en utilisant des standards ouverts, comme les technologies des services Web, même si les technologies des plateformes sont différentes Mise en œuvre efficace des interfaces et des adaptateurs de services Web L implémentation d adaptateurs pour les services Web est une approche efficace pour «envelopper» les applications anciennes et existantes avec des interfaces ouvertes. L adaptateur joue un rôle comparable à une passerelle entre Internet et les interfaces propriétaires des différentes applications. Les fonctions de l application existante sont ainsi proposées et exposées sous forme de services. Cela correspond aux concepts de l'architecture SOA et nous recommandons cette approche lorsqu'il s'agit d'intégrer des applications dans un environnement hétérogène, avec des systèmes faiblement couplés. Les interfaces de services Web des différents composants peuvent être facilement réutilisées pour créer des processus métier distribués. L implémentation de la technologie des services Web à la fois dans.net et dans J2EE constitue un avantage important. Il est ainsi possible de coupler des systèmes et des composants, indépendamment de leurs fondements technologiques. Par conséquent, les intégrateurs de systèmes devraient prendre en compte les concepts suivants : Fraunhofer Institute FOKUS Berlin, août

40 Introduire des Services Web Le Web a connu un succès phénoménal en permettant des interactions simples entre les personnes via des ordinateurs, à l'échelle d'internet. Le protocole HTTP et le langage HTML, utilisés aujourd'hui par tous les butineurs, ont montré qu il était possible de projeter des interfaces utilisateurs sur une large gamme d appareils, pour un coût modique. Un facteur de la réussite de HTTP et HTML a été leur relative simplicité ; ces deux standards fonctionnant en mode texte, ils pouvaient être facilement déployés sur de nombreux systèmes d exploitation et environnements de programmation. [MSDN1] Définir en premier le schéma XSD Définir les types de données en XSD garantit l interopérabilité des types de données. Évitez les DataSets et les classes spécifiques à certains langages ou à certaines plateformes car vous aurez besoin de développer des mécanismes de sérialisation personnalisés pour chaque client utilisant une technologie différente. Consultez «Top Ten Tips for Web Services Interoperability» (en anglais) [Guest]. Puis créer et modifier le WSDL Ne définissez pas des types de données propres à votre plateforme dans WSDL. Évitez les types de données liés à une plateforme dans vos interfaces et vos messages. Dans certains cas, EGSK utilise des types de données spécifiques comme la classe XMIDocument. Dans notre scénario, nous avons utilisé d autres interfaces pour transmettre la requête sous la forme d une chaîne XML. Consultez «Improve interoperability between J2EE technology and.net, Part 1» (en anglais) [Ye] Intégration efficace des applications anciennes Fournir des services spécifiques aux applications de l'administration pour des processus métier distribués (c'est-à-dire intégrer des applications propriétaires) s effectue assez simplement en utilisant la technologie des services Web. Actuellement, bon nombre de procédures administratives sont liées aux plateformes de l administration électronique via des interfaces fondées sur des standards (XÖV), adaptées aux procédures spécifiques de l administration et utilisant des messages XML définis. En raison de la complexité croissante des processus modernes de l administration, chaque fournisseur de logiciels destiné au marché public doit désormais obligatoirement offrir une gamme d interfaces pour ses produits. Voici quelques questions qui devraient permettre de clarifier le processus de prise de décision concernant l'intégration des applications existantes afin de prendre en charge des processus distribués : Le logiciel prend-il en charge dès sa conception des interfaces ouvertes? Ces interfaces sont-elles accessibles via Internet? 40 Fraunhofer Institute FOKUS Berlin, août 2005

41 S il n existe pas d interfaces ouvertes ou si leurs fonctionnalités ne correspondent pas aux besoins, existe-t-il une interface propriétaire qui permettrait d «envelopper» les fonctions internes sous la forme d un service Web? Si aucune interface n est prise en charge par l application, est-il possible de créer un adaptateur de service Web capable de manipuler directement l entrepôt de données de l application? Prise en charge des processus métier multi domaines La meilleure méthode pour mettre en œuvre des processus multi-domaines consiste à exploiter une architecture SOA, des services Web et des technologies d exécution de processus métier. En effet, cette approche est souple et très simple à implémenter. Un échange de données entre des domaines organisationnels différents de l administration publique devrait rester simple à réaliser en utilisant des interfaces ouvertes de services Web, tant que les plateformes de l administration sont compatibles avec les services Web. Si des interfaces de services Web ont déjà été mises en place sur les applications existantes, dans les domaines organisationnels concernés, seuls les flux doivent être adaptés ; il sera peut-être aussi nécessaire de mapper les formats XML via des transformations XSL. Si des systèmes de gestion de processus BPEL existent dans les deux domaines, une définition de processus BPEL d une organisation peut être réutilisée dans l autre. La mise en œuvre de services d administration électronique prenant en charge des processus métier transactionnels multi domaines requiert des concepts et des solutions dépassant le cadre de ce livre blanc. Une telle mise en œuvre implique une authentification au niveau fédéral, une grande sécurité, une fiabilité à toute épreuve, une gestion des identités et une gestion des transactions avec possibilité de retour en arrière. Tous ces points sont actuellement en cours de discussion au sein d organismes de standardisation tels que W3C ou OASIS, ceci concerne des spécifications comme WS-Security, WS-Coordination, WS-Transaction et WS-ReliableMessaging. Ces aspects seront probablement examinés dans le laboratoire Fraunhofer FOKUW lors de futurs travaux sur l interopérabilité entre plateformes. Les processus multi domaines du secteur public couvrent à la fois l interaction entre les communes et l interaction entre différents départements d une ville. Fraunhofer Institute FOKUS Berlin, août

42 5.1.5 Comparaison des temps de développement entre les technologies d intégration des applications existantes Au cours de cette étude, presque toutes les tâches ont été réalisées à la fois en Java et avec.net. Ces deux technologies sont très bien adaptées pour mettre en œuvre des environnements interopérables sur la base de standards ouverts comme XML, les services Web et BPEL. Quelques petites différences apparaissent en termes de flexibilité et de vitesse de développement. Le choix de la plateforme de connectivité joue sur le temps de développement nécessaire à l'intégration des applications existantes. L environnement J2EE propose une grande diversité d IDE (environnements de développements intégrés, comme Eclipse, JBuilder) et une large gamme d API pour des besoins classiques comme des services Web (Xerces, Sun Java XML API, Apache Xpath)..Le Framework.NET s appuie un IDE unique (Visual Studio.NET) qui propose des outils pour prendre en charge la plupart des implémentations.net habituelles et des API recommandées. À la lumière de notre expérience avec les deux plateformes, le principal avantage en termes de temps de développement pour la plateforme.net réside dans la façon de guider les développeurs pas à pas. Par exemple, en ce qui concerne XML,.NET offre un accès très rapide à ses technologies. La plupart des problèmes d implémentation peuvent être résolus avec la bibliothèque System.XML, en utilisant XPath. En revanche, dans J2EE, la première étape consiste à identifier l API la plus à même de répondre au problème XML spécifique posé. Puis cette API doit être ajoutée à l entrepôt des classes avant que le développeur puisse se familiariser avec les méthodes spécifiques à cette implémentation. En tout, cela prend plus de temps pour résoudre le problème que dans un environnement.net. Le même problème se pose lorsqu il s agit de choisir le serveur applicatif pour exécuter le nouveau service Web. IBM Websphere, BEA Weblogic ou Jakarta Tomcat? Avec J2EE, le choix est vaste. Cela confère de la flexibilité mais peut se révéler une gêne lorsqu il s agit de développer rapidement un scénario d intégration. Un autre problème concernant l utilisation des différentes API Java est leur manque d intégration. La plupart des API gérant un même problème ne s intègrent pas l'une à l'autre en raison d'une absence d'interfaces standardisées. Ainsi, les API sont incompatibles et restent difficiles à utiliser dans des environnements complexes et distribués Intégration avec Microsoft EGSK Au cœur de la technologie Microsoft E-Government Starter Kit, BizTalk Server permet au développeur d intégrer très rapidement des applications existantes et des flux. Notre expérience repose principalement sur l intégration d interfaces fournies par des services Web. Nous avons réalisé une intégration inter-plateforme de services Web J2EE et d interfaces utilisateurs fondées sur J2EE. Nous avons constaté que EGSK, 42 Fraunhofer Institute FOKUS Berlin, août 2005

43 combiné avec BizTalk Server, assurait une bonne prise en charge des services d'intégration et des nouvelles structures de processus à partir de services Web. Des flux peuvent être étendus et configurés avec un effort minimal. L'implémentation et l'intégration de périphériques mobiles utilisant.net Compact Framework sont tout aussi simples à réaliser. Microsoft ou plusieurs partenaires EGSK ont réalisé les adaptateurs répertoriés cidessous, pour les applications existantes, en utilisant le Microsoft E-Government Starter Kit : Service d information du registre des habitants Registre des entreprises Gestion des requêtes pour les certifications des habitants Rapport d erreur Gestion des requêtes pour les autorisations de stationnement Gestion des requêtes pour le registre de l'état fédéral Gestion des salles de sports Inscription à la garderie Gestion des requêtes pour les autorisations spéciales de stationnement Gestion des zones constructibles Gestion des requêtes pour les autorisations de pêche Pour obtenir des informations complémentaires, consultez [EGSK1] Intégration avec Oracle BPEL Process Manager Oracle Process Manager permet un développement simple et rapide de solutions fondées sur une architecture SOA et visant à assurer l intégration de processus entre plateformes. Lors de la mise en œuvre de nos scénarios de démonstration, nous avons réalisé un flux simple avec Oracle BPEL en utilisant plusieurs services Web sur diverses plateformes (comme Axis,.NET, OC4J). Nous avons constaté que la mise en place d un processus qui intègre plusieurs services Web s effectue très rapidement. Les services à intégrer sont exposés via des définitions WSDL. Plusieurs types de liaison comme SOAP, EJB, JMS, Java, sont pris en charge par le gestionnaire de processus. Nous les avons testés avec succès dans notre scénario. La console de gestion du moteur au cœur d Oracle Process Manager utilise les protocoles Web. Il est donc facile d administrer le moteur à distance en utilisant un simple butineur. Fraunhofer Institute FOKUS Berlin, août

44 5.1.8 Prise en charge de SSL et documentation de la plateforme En termes de sécurité, le serveur IIS de Microsoft est d'un bon niveau lorsqu'il est configuré pour exploiter SSL. Si vous souhaitez déployer une application sécurisée par SSL avec Tomcat dans un environnement Java, vous devrez réaliser davantage d opérations manuellement, ce qui allonge les temps de test et de déploiement. Par la machine virtuelle Java sous-jacente, le serveur Tomcat charge lourdement le système, ce qui diminue les performances à chaque connexion SSL entrante. La documentation des plateformes J2EE et.net est sur le Web. Les deux plateformes proposent des documentations semblables, bien structurées et complètes, offrant aux développeurs un véritable support Disponibilité d outils Comme nous l avons mentionné précédemment, un des grands avantages à développer sur la plateforme.net avec Visual Studio réside dans les nombreux assistants graphiques à la disposition du programmeur. Presque toutes les tâches, comme ajouter des services Web ou des ressources locales, déployer des applications Web ou mettre en œuvre SSL, sont prises en charge par des outils très pratiques, qui guident le programmeur pas à pas. Dans le monde Java, il existe aussi de nombreuses méthodes pour créer de puissants IDE modulaires, par exemple Eclipse. Tous les grands IDE (environnements de développement) aident le programmeur dans toutes les tâches quotidiennes d un développement moderne : Débogage Test Développement d applications distribuées Intégration de service et de système Documentation Gestion du cycle de développement Les produits ci-dessous peuvent être considérés comme des options pour développer des applications distribuées exploitant des services Web : Visual Studio.NET 2003 Borland JBuilder 2005 Enterprise Eclipse 44 Fraunhofer Institute FOKUS Berlin, août 2005

45 5.2 Principales recommandations L utilisation d architectures orientées services (SOA) permettent la réalisation de flux rationnels dans l administration publique et dans le secteur de l informatique, qui transcendent les frontières traditionnelles technologiques et organisationnelles. Les technologies à la base de la réalisation de flux entre organisations, comme XML, les services Web et les systèmes d exécution de processus (BPEL) sont toutes disponibles aujourd hui et prises en charge par de nombreux fournisseurs de plateformes. L utilisation de systèmes de gestion fondés sur BPEL autorise une description souple et portable des flux des processus, ce qui permettra dans le futur des déploiements d un nouveau type, indépendants des éditeurs. Même en utilisant ces outils, les procédures de l administration requièrent toujours une définition des flux ainsi que la standardisation sous XML des modèles de données et des structures de données. En Allemagne, la standardisation XML pour diverses procédures spécialisées est réalisée via la standardisation XÖV. Fraunhofer Institute FOKUS Berlin, août

46 46 Fraunhofer Institute FOKUS Berlin, août 2005

47 6 Abréviations API AutiSta CORBA CTL DCE DCOM DIN DRM ebxml EGSK UE IBF TIC IDABC IDE IP IPR IPSEC ISV OSCI OSS PDF RAND Application Programing Interface (interface de programmation d application) Application centrale gérant le registre de l'état civil Common Request Broker Architecture Complex text Layout Distributed Computer Environment (environnement informatique distribué) Distributed Component Object Model (modèle objet pour composant distribué) Deutsches Institut für Normung (organisme de normalisation allemand) Digital Rights Management (gestion des droits numériques) Electronic Business XML E-Government Starter Kit (kit Microsoft) Union européenne Information Bridge Framework Technologies de l information et de la communication Interoperable Delivery of European egovernment Services to Public Administration, Businesses and Citizens (fourniture interopérable de services européens d administration électronique pour l administration publique, les entreprises et les citoyens) Integrated Development Environment (environnement de développement intégré) Internet Protocol Intellectual Property Rights (droits de propriété intellectuelle) IP Security Protocol (protocole de sécurité sur IP) Independent Software Vendor (éditeur de logiciels) Online Service Computer Interface Open Source Software (logiciel en open source) Portable Document Format (Adobe) Reasonable and Non-Discriminatory terms Fraunhofer Institute FOKUS Berlin, août

48 RMI SDK SOA SOAP SSL UNO VBA WSDL WS-I XBau XDomea XDP XGewerbe XJustiz XMeld XML XÖV XSD XSLT Remote Method Invocation (appel de méthode à distance) Software Development Kit (kit de développement logiciel) Service-Oriented Architecture (architecture orientée service) Simple Object Access Protocol Secure Session Layer (couche session sécurisée) Universal Network Objects (objets réseaux universels) Visual Basic pour Applications Web Services Definition Language Web Services Interoperability Organization Standard allemand utilisé par l administration électronique pour les applications de gestion des permis de construire Standard allemand pour l échange électronique de documents administratifs XML Data Package Standard allemand utilisé par l administration électronique pour le Registre des entreprises Standard allemand pour l échange électronique de documents administratifs Standard allemand utilisé par l administration électronique pour le Registre des habitants Extensible Markup Language Ensemble de standards allemands fondés sur XML et destinés aux applications de l administration XML Schema Definition Extensible Style sheet Language Transformation 48 Fraunhofer Institute FOKUS Berlin, août 2005

49 7 Glossary Ce glossaire définit les principaux termes utilisés en interopérabilité et dans les technologies relatives aux architectures orientées services (SOA), au middleware (logiciel intermédiaire) et aux technologies XML. Ces définitions ont été extraites de diverses sources fiables. Le glossaire contient également des définitions de termes utilisés dans les scénarios décrits dans ce document. Ce glossaire ne prétend pas donner une vue complète de toutes les facettes de l interopérabilité ni une introduction aux solutions d interopérabilité ou aux concepts. Il explique des termes techniques et conceptuels qui peuvent paraître abscons au lecteur néophyte. Administration électronique Il s agit de la traduction officielle française de egovernment. Ce terme décrit l ensemble des transactions des processus métiers entre les différentes branches de l administration publique, via l informatique et les supports électroniques. Commerce électronique Il s agit de la traduction de ebusiness. Ce terme décrit l'ensemble des processus métier mis en œuvre sur Internet et qui utilisent des plateformes à plusieurs niveaux et des technologies comme XML et les services Web. De nombreux concepts appliqués à l intégration des applications existant dans le secteur public sont dérivés de l intégration d applications dans le secteur des entreprises. Définition de l interopérabilité et de standards ouverts Interopérabilité Capacité des systèmes ou des unités à fournir des services à, et à accepter des services d autres systèmes ou unités ; et utilisation des services ainsi échangés de façon à leur permettre de travailler ensemble avec efficacité. État obtenu par des systèmes et des équipements électroniques de communication lorsqu ils parviennent à échanger directement et de façon satisfaisante des informations ou des services entre eux et entre leurs utilisateurs. Le degré d interopérabilité devrait être défini lorsqu on fait référence à des cas spécifiques. Pour en savoir plus : L interopérabilité désigne la capacité des systèmes informatiques et des processus métier qu ils mettent en œuvre, d échanger des données et de permettre le partage d informations et de connaissances [IDABC-EIF]. Trois axes doivent être considérés : L interopérabilité organisationnelle : Cet aspect de l interopérabilité définit les objectifs métier, modélise les processus et conduit à la collaboration des administrations qui souhaitent échanger des informations tout en possédant des Fraunhofer Institute FOKUS Berlin, août

50 structures et des processus internes différents. De plus, l interopérabilité organisationnelle cherche à répondre aux demandes des utilisateurs en rendant les services disponibles, facilement identifiables, accessibles et conçus pour les utilisateurs. L interopérabilité sémantique : Il s agit de vérifier que le sens précis des informations échangées est compréhensible par toute autre application qui n était pas conçue à l origine pour cet objectif. L interopérabilité sémantique permet à des systèmes de combiner des informations reçues avec d autres ressources et de les traiter de façon pertinente. L interopérabilité sémantique est par conséquent un pré-requis pour la fourniture multilingue de services à l utilisateur. L interopérabilité technique : Cet aspect de l interopérabilité couvre les problèmes techniques des liaisons entre services et systèmes informatiques. Il inclut des aspects importants comme des interfaces ouvertes, des services d interconnexion, l intégration des données, le middleware (logiciel intermédiaire), la présentation et l échange des données, l accessibilité et les services de sécurité. l EICTA (European Information & Communications Technology Industry Association) définit ainsi l interopérabilité technique : Capacité pour deux ou plusieurs réseaux, systèmes, équipements, applications ou composants à échanger des informations entre eux et à utiliser l information ainsi échangée [EICTA-1]. Interopérabilité des applications Dans le contexte d une architecture d administration électronique, l interopérabilité des applications implique la capacité à échanger des informations (un transfert de données qui peut être sémantiquement interprété) entre des unités fonctionnelles (les composants de l architecture) s exécutant sur des plateformes différentes et exploitant des technologies différentes. Cela sous-entend l utilisation de standards du marché ou de protocoles de communication et de description de données largement répandus. Interopérabilité des documents L interopérabilité des documents décrit la capacité des systèmes bureautiques (applications des postes de travail, suites bureautiques) à partager les informations stockées dans des documents, avec les applications de l administration électronique. Des schémas XML personnalisés sont utilisés pour décrire les types d'informations à échanger entre des entités coopérantes. Portabilité des documents La portabilité des documents décrit l échange d un document entre deux systèmes de traitement sans perdre ni le contenu ni les informations de style et de présentation. 50 Fraunhofer Institute FOKUS Berlin, août 2005

51 Alors que la portabilité des documents se concentre sur le transfert des styles et du contenu d un format de document vers un autre lors de l échange de documents entre des applications différentes, l interopérabilité des documents se restreint, quant à elle, à l échange du contenu uniquement, entre processus de l administration électronique. Standards ouverts Suivant la demande d interopérabilité entre systèmes techniques hétérogènes, plus particulièrement ces dernières années, le rôle joué par les standards ouverts est devenu plus important. «Standard ouvert» ne signifie pas que seul le résultat final est ouvert libre de droits et généralement accessible (incluant l accès aux spécifications techniques exactes) mais également l intégralité du processus de standardisation. En théorie, tout individu peut faire des suggestions. Les propositions font l objet de discussions publiques, suivant une procédure structurée en plusieurs étapes jusqu'à ce qu un large consensus soit accepté. Dans l ensemble, ces larges débats publics entre experts conduisent à des solutions techniques très sophistiquées. À notre époque, alors que les échanges de données, d informations et de connaissances entre individus, entreprises et autorités croît en importance, les standards ouverts jouent un rôle de plus en plus essentiel. Les standards ouverts offrent à tous les fournisseurs de logiciels la même base de travail. Ils permettent l intégration fiable et à moindre coût des systèmes hétérogènes et encouragent l indépendance vis-à-vis d un éditeur particulier. La résolution de la Global Standards Collaboration (GSC) de septembre 2005 ( stipule que les standards ouverts devraient «inclure les éléments fondamentaux suivants Le standard est développé et/ou approuvé et maintenu par un processus collaboratif basé sur le consensus, Un tel processus est transparent, Les tiers intéressés ou affectés matériellement ne sont pas exclus d un tel processus, Le standard est sujet aux règles de propriété intellectuelle de type RAND (Reasonnable and Non Discriminatory - raisonnable et non discriminatoire) et FRAND (Fair, Reasonable, and Non-Discriminatory juste, raisonnable et non discriminatoire) qui n obligent pas, mais peuvent permettre, au choix du propriétaire des droits, d offrir des licences de propriété intellectuelle sans compensation, Le standard est publié et rendu disponible au public sous conditions raisonnables (pouvant inclure des frais raisonnables ou gratuitement).» Fraunhofer Institute FOKUS Berlin, août

52 Interfaces ouvertes Les interfaces basées sur des standards ouverts permettent le déploiement de technologies hétérogènes (CORBA, J2EE, Microsoft.NET) et de produits d éditeurs différents tout en assurant et maintenant un support informatique de bout en bout pour les processus d entreprise. De cette manière, l utilisateur est libre de choisir la meilleure solution de son point de vue. Quelle que soit la technologie utilisée, ces interfaces sont appelées «interfaces ouvertes» lorsque les données échangées (par exemple sous la forme d un schéma XML) et l interface elle-même - dans le cas d un Web Service (au sens de la spécification WSDL) -sont entièrement documentées et que cette documentation est disponible gratuitement auprès du public. Logiciel Open Source «C est un modèle qui devrait simplifier l utilisation commerciale des logiciels Open Source. Les sources sont disponibles gratuitement et sont libres de droits de licence. La reproduction, diffusion et modification sont autorisées sans que toutefois la dernière instance du logiciel ne soit obligatoirement disponible sous les mêmes conditions de licence.» La version 1.9 de la définition détaillée d un logiciel Open Source (OSD Open Source Definition Définition de logiciel Open Source) comprend 10 critères. Ces critères règlent principalement les questions liés à la libre redistribution, l accès au code source, les modifications, l intégrité du code source, la non discrimination de personnes, groupes ou champs d application, la distribution libre de licences, la non spécificité des licences aux produits, la non restriction des licences à d autres logiciels et les licences neutres technologiquement. Programme de partage des sources En regard des modèles de licence Open Source, certains éditeurs offrent également des programmes de licence qui permettent le déploiement et la mise à jour du code source. Par exemple, le programme de licence de Microsoft consiste en trois éléments : Microsoft Permissive License (MS-PL) Ce modèle de licence autorise le titulaire de la licence à lire, modifier et redistribuer le code source. Microsoft Community License (MS-CL) Ce modèle de licence a été développé dans l optique de la réalisation de projets. Il fonctionne fichier par fichier ; en d autres termes, lorsqu un fichier utilisé 52 Fraunhofer Institute FOKUS Berlin, août 2005

53 contient des sources sous licence MS-CL, la licence s applique à l ensemble du fichier. Cela implique que le fichier ne peut être redistribué que sous licence MS- CL. Ce modèle est similaire à la Mozilla Public License. Microsoft Reference License (MS-RL) La MS-RL est la plus restrictive de ces licences puisqu elle autorise uniquement le titulaire à accéder au code, sans droit de modification ni de redistribution. Elle est principalement destinée aux bibliothèques de développement existantes. Des informations complémentaires sur ces types de licences peuvent être consultées à l adresse suivante : elicenses.mspx Termes techniques relatifs au middleware et à la technologie XML Technologies Middleware et architectures orientées service Service-Oriented Architectures (SOA) Le terme service-oriented architecture (architecture orientée service - SOA) est associé à un concept d intégration innovant basé sur un ensemble de standards internationaux acceptés par la plupart des fabricants. Le but de ce standard est d améliorer l interopérabilité des systèmes logiciels hétérogènes tout en réduisant de façon significative le niveau élevé actuel des coûts d intégration. SOA est basé sur des protocoles Internet et des modèles de données établis comme HTTP et XML auxquels s ajoutent d autres standards. Un des paradigmes clé, représentant une des bases de SOA, est son orientation service qui permet le couplage lâche, via des interfaces de service ouvertes, de composants informatiques hétérogènes basé sur des Web Services Les fonctions, séquences, formats de données et coûts des services autonomes sont connus en externe, permettant l indépendance vis-à-vis des plates-formes et l interopérabilité des services, tandis que les détails de leur implémentation ne le sont pas. L orchestration (mise en séquence des processus) des services à couplage lâche peut être effectué grâce à des langages de description de processus comme BPEL (Business Process Execution Language). Ces dernières années, l utilisation de la technologie des Web Services pour décrire ces interfaces de service s est imposée d elle-même. Associée aux concepts SOA, la technologie des Web Services est devenue la solution de choix de tous les secteurs du e-commerce et de l administration électronique parce qu elle entraine des économies substantielles dans les coûts d intégration. Fraunhofer Institute FOKUS Berlin, août

54 Figure 11 Présentation des standards web SOA. Une description détaillée de SOA et de la technologie des Web Services appliqués à l administration électronique peut être trouvée dans [Bitkom-1] et dans les documents listés dans la partie «Références». Technologie des Web Services La technologie des Web Services est exclusivement basée sur des standards ouverts tels que XML, WSDL et SOAP, ce qui la rend indépendante des éditeurs, des technologies middleware comme J2EE ou.net et des langages de programmations comme Java ou C#. La majeure partie des langages de programmation et des environnements de développement intègrent à présent des éléments supportant les standards tels que XML, WSDL et les Web Services. Les applications et les services ad hoc peuvent être rendus disponibles, enregistrés sur Internet et dans un intranet comme des Web Services qui peuvent être localisés et utilisés par d autres applications. 54 Fraunhofer Institute FOKUS Berlin, août 2005

55 Java Le langage de programmation associé à J2EE. Java a été introduit par Sun Microsystems en Il s agit d un langage de programmation orienté objet, semblable au C dans sa syntaxe. Une des principales caractéristiques de l environnement Java réside dans le fait qu'une application compilée est écrite dans un code intermédiaire, indépendant du code assembleur de la plateforme cible. Ce code doit être exécuté par la machine virtuelle Java. Cette fonctionnalité rend en théorie Java portable et l'application est indépendante de la plateforme. Java 2 Enterprise Edition (J2EE) Terme général décrivant la famille de spécifications proposée par Sun pour le commerce électronique. J2EE est une plateforme d exécution fondée sur Java et créée par Sun Microsystems. Elle sert à développer, déployer et gérer à l échelle d une entreprise, des applications à plusieurs niveaux côté serveur. J2EE reprend les fonctionnalités de J2SE et lui ajoute la communication distribuée, le contrôle des threads, une architecture capable de monter en charge et la gestion des transactions. Java Server Pages Technologie J2EE employée avec les Servlets Java pour constituer le modèle de programmation de la couche présentation. Servlets Java Technologie J2EE employée avec les Java Server Pages pour constituer le modèle de programmation de la couche présentation. Machine virtuelle Java Module d exécution responsable de l interprétation du code intermédiaire Java. Apache Axis Apache Axis est une implémentation du protocole SOAP. Axis est essentiellement un moteur SOAP, un cadre pour construire des processeurs SOAP tels que des clients, des serveurs, des passerelles, etc. La version actuelle d Axis est écrite en Java mais une version C++ pour le côté client est actuellement en cours de développement. Fraunhofer Institute FOKUS Berlin, août

56 C# C# est un langage de programmation dérivé du C++. Par ses fonctionnalités et son style, il ressemble à Java. C# est orienté objet et conçu pour améliorer le processus de développement d applications Web sophistiquées. Il s appuie sur les nombreuses classes du Framework pour XML et pour l intégration de services Web fondés sur XML. Cela simplifie le développement d'applications distribuées. C# gère la cohérence des types, le nettoyage de la mémoire, les versions des sources et s intègre parfaitement dans l environnement de développement Visual Studio.NET. Pour en savoir plus : Terme général désignant la plateforme de développement de Microsoft. Microsoft.NET Framework est un environnement pour l élaboration, le déploiement et l exploitation de services Web XML et d autres applications. Il se compose de trois parties principales : La CLR (Common Language Runtime), les classes du Framework et ASP.NET. Un autre élément, le Microsoft.NET Compact Framework, le complète. Il s agit d un ensemble d interfaces de programmation permettant aux développeurs de travailler pour les équipements mobiles, comme les Smartphones et les PDA (assistants numériques personnels). Consultez la bibliothèque MSDN à l adresse Solutions.NET pour les développeurs à l adresse Visual Studio.NET Visual Studio.NET est l IDE (environnement de développement intégré) de Microsoft pour.net. BizTalk Server Un produit de la gamme Microsoft Server System qui apporte une solution de gestion des flux pour les processus métier. Microsoft BizTalk Server assure l intégration d applications et d organisations via Internet. Avec son architecture fondée sur l échange de messages, le serveur sait gérer différents types de fichiers (XML, EDI, fichiers plats) en utilisant divers mécanismes de transport et d adaptation (SOAP, FTP, SMTP, MSMQ). Les flux d informations et le processus lui-même peuvent être facilement conçus (c est la phase d orchestration) par le biais d une interface graphique intégrée dans Visual Studio.NET. Il est possible d'éclater le processus de conception en deux parties : d une part l'analyse et le développement des flux, et d autre part, une phase plus technique : la mise en œuvre 56 Fraunhofer Institute FOKUS Berlin, août 2005

57 des différents ports et interfaces pour connecter les applications et les organisations. Un moteur XSL interne prend en charge les transformations entre les différents formats de données à échanger. Il permet l'intégration de nombreux systèmes sans écrire une seule ligne de code. BPEL BPEL (Business Process Execution Language) pour les services Web est un langage fondé sur XML, conçu pour permettre le partage de tâches dans un environnement informatique distribué même entre organisations différentes en utilisant une combinaison de services Web. Écrit par des développeurs de BEA Systems, IBM et Microsoft, BPEL combine des constructions du langage de flux WSFL (Web Services Flow Language) des services Web d IBM avec la spécification XLANG de Microsoft. Avec BPEL, un programmeur décrit de manière formelle (abstraite) un processus métier qui prend place sur le Web de telle façon que des entités différentes puissent réaliser une ou plusieurs étapes du processus. Au-delà des descriptions des flux, BPEL sait aussi décrire la connectivité des services réels. Pour en savoir plus : OSCI OSCI (Online Service Computer Interface) est un standard allemand pour l administration électronique. Il couvre un ensemble de protocoles répondant aux besoins de sécurité de l administration, et il est développé par le groupe de travail OSCI. Son objectif consiste à prendre en charge des transactions sous la forme de services Web et d en permettre leur exécution via Internet. OSCI Transport 1.2 est la partie responsable des tâches d échanges dans le domaine de la sécurité. L existence d un intermédiaire central qui peut apporter des services à valeur ajoutée sans compromettre la confidentialité des données métier est une des principales caractéristiques de la sécurité des processus utilisant OSCI. En tant que protocole de transmission sécurisé, il permet de relier des transactions en ligne (tout en étant en conformité avec la loi allemande sur la signature électronique). OSCI Transport prend en charge les communications asynchrones via un intermédiaire, ainsi que le chiffrement de bout en bout pour les transmissions confidentielles de données. OSCI Transport standardise à la fois les contenus des messages, et les fonctions de transport et de sécurité. Il repose sur des standards internationaux (par exemple, XML Signature, DES, AES, RSA et X.509). Les principaux critères ayant été pris en compte pour la version 1.2 de OSCI Transport sont : Référence à des standards ouverts (SOAP, XML Signature, XML Encryption). Indépendance technique, c est-à-dire transmission utilisant des protocoles techniques de communication sans imposer de contraintes spécifiques liées à une plateforme ou à un langage de programmation. Fraunhofer Institute FOKUS Berlin, août

58 Possibilité d évolution des niveaux de sécurité (signatures évoluées, signatures accréditées, en fonction des besoins des applications). Pour en savoir plus : SOAP Simple Object Access Protocol SOAP est un protocole allégé pour l échange d informations dans un environnement décentralisé et distribué. C est un protocole fondé sur XML, composé de trois parties : une enveloppe qui définit un cadre pour décrire ce qui existe dans un message et comment le traiter, un ensemble de règles de codage pour exprimer les types de données définis par les applications, et une convention pour représenter les messages en entrée et en sortie. «Part 1 : Messaging Framework» définit, en utilisant XML, un cadre de messages extensible contenant une construction de messages pouvant être échangée via une large gamme de protocoles sous-jacents. La partie 2 définit des éléments connexes pouvant être utilisés avec le cadre de message SOAP. Pour en savoir plus : WSDL Web Service Description Language WSDL est un format XML pour décrire des services réseau comme des ensembles de points terminaux traitant des messages qui contiennent des informations orientées document ou procédure. Les opérations et les messages sont décrits de façon abstraite, puis liés à un protocole réseau concret et à un format de message pour définir un point terminal. Des points terminaux concrets en rapport les uns avec les autres sont combinés pour former des points terminaux abstraits, ou services. WSDL est extensible, ce qui permet la description de points terminaux et de leurs messages indépendamment des formats des messages et des protocoles réseaux utilisés pour communiquer. Toutefois, les seules liaisons décrites dans le document du W3C expliquent comment utiliser WSDL en conjonction avec SOAP 1.1, HTTP GET/POST et MIME. Pour en savoir plus : WSS Web Service Security La spécification WS-Security définit des améliorations des messages SOAP afin d apporter trois fonctionnalités : échange des informations de sécurité, intégrité des messages et confidentialité des messages. L ensemble des spécifications de sécurité pour les services Web inclut : Web Services Security SOAP Message Security 1.0 (WS-Security 2004), Web Services Security Username Token Profile 1.0, Web Services Security X.509 Certificate Token Profile, et deux schémas XML. Pour en savoir plus : 58 Fraunhofer Institute FOKUS Berlin, août 2005

59 XML extensible Markup Language XML (extensible Markup Language) est un format texte simple, flexible, et dérivé de SGML (ISO 8879). Conçu à l origine pour répondre aux besoins de la publication électronique de documents à grande échelle, XML joue aussi un rôle de plus en plus important dans l échange de nombreuses données, notamment sur le Web. Pour en savoir plus : XSD XML Schema Definition / Relax-NG Les schémas XML décrivent les vocabulaires partagés et permettent aux machines de comprendre les règles définies par les auteurs des documents. Les schémas définissent la structure, le contenu et la sémantique des documents XML. Pour en savoir plus : Relax-NG est un langage de description de schéma qui constitue une alternative à XSD. Relax-NG représente de façon moins complexe un schéma XML et constitue une description compacte non XML. Pour en savoir plus : XSL extensible Stylesheet Language Cette spécification définit les fonctions et la syntaxe du langage XSL (extensible Stylesheet Language), un langage décrivant les feuilles de style. Elle se compose de deux parties principales : Un langage pour transformer les documents XML. Un vocabulaire XML pour spécifier la sémantique du formatage. Une feuille de style XSL spécifie la présentation d une classe de documents XML en décrivant comment une instance de la classe est transformée en document XML via le vocabulaire de formatage. Pour en savoir plus : XPath / XQuery XML est un langage de balisage polyvalent, capable de baliser le contenu de diverses sources de données, y compris des documents structurés ou semi-structurés, des bases de données relationnelles et des entrepôts d objets. XPath est un langage permettant de retrouver certaines parties d'un document XML. Il est conçu pour être utilisé de concert avec XSLT et XPointer. Pour en savoir plus : XQuery est un langage s appliquant sur de nombreux types de sources de données XML. Il utilise de façon intelligente la structure XML d un document et peut exprimer des requêtes sur toutes sortes de données, qu elles soient physiquement stockées en XML ou vues en XML via un logiciel intermédiaire. Pour en savoir plus : Fraunhofer Institute FOKUS Berlin, août

60 XForms XForms est une application XML qui représente la prochaine génération de formulaires pour le Web. En séparant le langage traditionnel XHTML en trois parties : XForms, données et interface utilisateur, il devient possible de séparer la présentation d un document de son contenu. Cela facilite la réutilisation, permet un typage fort, réduit le nombre de sollicitations du serveur, tout en offrant une indépendance par rapport au matériel et en réduisant le nombre de lignes de script à écrire. XForms n est pas un type de document autonome. Il a été conçu pour être utilisé concomitamment à d autres langages de balisage comme XHTLM ou SVG. Pour en savoir plus : 60 Fraunhofer Institute FOKUS Berlin, août 2005

61 8 Références Cette section regroupe des références classées par thèmes. Interopérabilité et standards [Appl-Interop] [Bitkom-1] [Corbisier] [Doc-Interop] Uwe Holzmann-Kaiser (éditeur), «Application Interoperability for egovernment», Fraunhofer Institute FOKUS, août 2005 Leitfaden Web Services, BITKOM-Arbeitskreis, «Application Development & Integration Technology», décembre 2004 (en allemand) RoAnn Corbisier (Editor), «Application Interoperability: Microsoft.NET and J2EE» ; RoAnn Corbisier, Microsoft Platform Architecture Group, Microsoft, 2003 Kay-Uwe Schmidt (éditeur), «Document Interoperability for use in egovernment», Fraunhofer Institute FOKUS, août 2005 [EICTA-1] EICTA Interoperability white paper, Version 1, janvier 2005 [EICTA-2] [Fishenden] [IDABC-EIF] [OSCI] [SAGA] [SIGA] [XÖV] EICTA Comments to IDA s European Interoperability Framework, Version 1.0, novembre 2004 Jerry Fishenden, Government Interoperability Enabling the delivery of e-services, A Whitepaper, px IDABC, European Interoperability Framework for Pan-European egovernment Service, Version 1.0, novembre 2004 Transport 1.2 Spezifikation, (en allemand) Standards and Architectures for e-government Applications, Version2.0, KBSt, 2003, BSI, Sichere Integration von egovernment-anwendungen, Projektgruppe E-Government im Bundesamt für Sicherheit in der Informationstechnik (BSI), (en allemand) Standards XML de l administration publique allemande, (en allemand) Fraunhofer Institute FOKUS Berlin, août

62 Standards et organismes [WS-I] [W3C] [IETF] [OASIS] Web Services Interoperability Organization (WS-I) World Wide Web Consortium (W3C) Internet Engineering Task Force (IETF) Organization for the Advancement of Structured Information Standards (OASIS) Architecture orientée services (SOA : Service-Oriented Architecture) [Brown] [Guest] [MSDN1] [Tidwell] [SOA] [Ye] Paul Brown, Fivesight, BPEL for Programmers and Architects Simon Guest, Top Ten Tips for Web Services Interoperability, An Introduction to the Web Services Architecture and Its Specifications, understaning/advancedwebservices/default.aspx?pull=/librar y/enus/dnwebsrv/html/introwsa.asp Doug Tidwell, IBM Developer Relations, Business Processes in a Service-Oriented Architecture enda/082504/pdf/bpelandsoas.pdf Definitions on Service_Oriented_Architectures Wangming Ye, Improve interoperability between J2EE technology and.net, Part Fraunhofer Institute FOKUS Berlin, août 2005

63 Plateformes pour l administration électronique [MS-EGSK] [Oracle BPEL] Microsoft Solutions Platform E-Government Starter Kit (EGSK) ult.mspx Liste des adaptateurs disponibles pour EGSK, log.mspx Oracle BPEL Process Manager, html Produits IDE [VS] Informations produit sur Visual Studio.NET [ECL] Informations produit pour Eclipse [JB] Informations produit sur Borland JBuilder Fraunhofer Institute FOKUS Berlin, août

64

65

66 Le Fraunhofer Institute FOKUS est le membre fondateur du Fraunhofer egovernment Center. Il fait aussi partie du groupe Fraunhofer ICT. Cette version préliminaire 1.0 du livre blanc «Interopérabilité des applications dans l administration électronique» présente les premiers résultats de nos recherches sur l interopérabilité. Ces recherches se sont concentrées sur l intégration de diverses technologies et produits, au sein du Laboratoire pour l administration électronique Fraunhofer FOKUS. La série de livres blancs diffusés par Fraunhofer FOKUS aborde divers sujets comme l'interopérabilité, l'intégration de processus, les architectures d'administration électronique, etc. Ces documents sont en permanence revus et modifiés afin d intégrer de nouvelles conclusions, des développements en cours, et les résultats les plus récents. Ils incitent les acteurs impliqués dans l administration électronique à étendre le débat. Nous recevons des contributions de la part de l administration publique, des fournisseurs, des comités, des associations professionnelles et des instituts scientifiques dont les points de vue et les conclusions contribuent à toujours améliorer la qualité de nos livres blancs. N hésitez pas à participer en envoyant vos contributions par courriers électroniques adressés à l éditeur de ce document. FOKUS Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee Berlin Éditeur Uwe Holzmann-Kaiser [email protected]