Intégration et Généricité: Modèle ADROIT

Les approches des web services sont des approches de connectivité des EAI.

Ardissono L. Goy A. et Petron G. dans le livre intitulé « Enabling Conversations with web services » [I.10] définissent l'approche web services comme une  approche basée sur les modèles théoriques de la gestion du dialogue.

L'approche web services a un objectif qui est définit dans le livre « Semantic Web Enabled Web Services. » de D. fensel C. Bussler et A. Maedche [I.11] comme étant de transformer le Web en un dispositif distribué de calcul où les programmes (services) peuvent interagir de manière intelligente en étant capables de se découvrir automatiquement, de négocier entre eux et de se composer en des services plus complexes.

Les approches des MOM sont des approches de transport des EAI.

Dans un article intitulé « Approche coopérative de l'adaptabilité des applications mobiles basées sur MobileJMS » de Mejdi Kaddour et Laurent Pautet [I.12] montrent que le faible couplage entre les entités communicantes dans un MOM, en terme de disponibilité et de logique fonctionnelle, permet d'incorporer à un système d'information global les applications et les données patrimoniales de l'entreprise, et ouvre la voie à de nouveaux types d'accès comme le Web.

EII a trois dispositifs principaux :

Ø C'est une infrastructure de logiciel, pas une application. EII soutient la création des applications comme portails d'entreprise qui montrent et analysent des données combinées à travers des sources de données.

Ø L'EII est un logiciel simple qui donne une large étendue des applications sur la deuxième rangée d'une architecture e-business qui accède à des bases de données et des systèmes de fichiers fonctionnant sur la troisième rangée sans données de réplique.

Ø Elle fournit une approche intégrée. EII fournit une infrastructure commune sur ce que tous les liens peuvent être construits.

L' EDI a trois approches qui sont défini par Denis Gerard et J-R Caron [I.13]  

Ø L'EDI en mode autonome est la forme la plus simple à mettre en place. Les applications d'EDI fonctionnent sans liens avec les autres applications de l'entreprise. L'EDI en mode autonome se concrétise de façon plus courante sous trois formes : le formulaire électronique, la télécopie à EDI et le bureau de service. 

Ø Le mode intégré suggère une harmonisation entre les applications existantes et le logiciel d'EDI. L'EDI, en mode intégré, entraîne une automatisation de certaines tâches. L'application d'EDI peut converser avec les applications de l'utilisateur.

Ø L'EDI en mode intégré et transformation se distingue du mode intégré non pas sur le plan du matériel ou du logiciel, mais plutôt par le fait que l'EDI est intégré aux processus d'affaires de l'entreprise.

Olivier Grenet dans « la connectivité des logiciels doit s'appuyer sur des standards afin d'assurer l'interopérabilité des systèmes » montre le caractère presque indispensable de XML au sein des SGBDR [I.14] en ces termes : « Le développement croissant des contenus XML a incité les SGBDR de dernière génération à intégrer au moins des fonctions d'importation/exportation d'XML et au mieux à stocker et gérer nativement les données XML.

Le datawarehouse ou entrepôts de données a trois principales approches : OLAP, MOLAP et ROLAP.

Ø Le concept OLAP (On Line Analytical Processing) repose sur une base de données multidimensionnelle, destinée à exploiter rapidement les dimensions d'une population de données. La plupart des solutions OLAP reposent sur un même principe : restructurer et stocker dans un format multidimensionnel les données issues de fichiers plats ou de bases relationnelles.

Ø Les outils MOLAP sont conçus exclusivement pour l'analyse multidimensionnelle, avec un mode de stockage optimisé par rapport aux chemins d'accès prédéfinis.. MOLAP agrège tout par défaut.  

Ø Les outils ROLAP superposent au dessus des SGBD/R bidimensionnels un modèle qui représente les données dans un format multidimensionnel.

Dans l'article « Une démarche de conception générique », Michel Chokron et M. Des Rochers [I.15] ont précisé que la technique de conception des ERP nécessite l'existence d'une architecture de base à partir de laquelle l'ERP et ses différentes options sont établis. Cette architecture de base devrait être le commun dénominateur de l'architecture des systèmes des entreprises clientes car ainsi on minimiserait l'effort de paramétrage.

Dans leur recherche, Losavio et al. [I.16], étendent un modèle conceptuel d'intégration d'outils CASE pour avoir une conception unique et cohérente au niveau des processus et des services dans une organisation. 

	Intégration montante	Intégration arrière			Intégration frontale
	"Upward"	Backward			"Forward"
Processus
Exemple :	Planification de l'approvisionnement	Approvisionnement			Approvisionnement avec les
Gestion de	de la haute direction	Pour les producteurs			fournisseurs, et vendeurs
l'approvisionnement
Services	. Systèmes d'aide à la décision	Outils CASE			. Systèmes de gestion
	. Systèmes à base de	Systèmes			des données clients
	connaissances	Patrimoniaux ERP			. Systèmes de gestion
	. Systèmes d'audit ou				des données fournisseurs
	d'assurance qualité				. Systèmes de e-commerce
					entre entreprise
					. Systèmes de e-commerce
					entre vendeur et client
Technologie	Matériel
	Logiciel
	BD
	Technologie de communication

D'un autre côté, dans l'article de Toussaint P.J. [I.17], l'intégration centrée sur les applications utilise deux groupes de technologies. L'approche Middleware applicatif qui est une démarche d'intégration fondée sur l'utilisation d'un Middleware consistant à modifier les produits existants pour permettre leur inter fonctionnement via une plateforme d'intégration.

Ainsi l'EAI assure trois fonctionnalités, en effet c'est à la fois : un service de connectivité des applications Middleware, un gestionnaire de processus workflow, un transformateur de données. 

Pour interconnecter plusieurs applications à travers les EAI, les web services ont des technologies telles que : SOAP, WSDL, UDDI, WSFL, WSCL, ebXML.

P. kellert et F. Toumani [I.4] ont montré que du point de vue technique, la description d'un web service inclut tous les détails nécessaires à l'interaction avec le service comme, par exemples, le format des messages, les signatures des opérations, le protocole de transport et la localisation du service. Les web services s'appuient sur des mécanismes et des protocoles standards et sont donc indépendants des langages de programmation (Java, J#, C++, Perl, C#, etc.), du modèle objet (COM, EJB, etc.) ainsi que des plates-formes d'implémentation (J2EE, .NET, etc.). 

Dans sa thèse sur « la conception d'une plate-forme électronique basée sur les rapports commerciaux de vente de produits de luxe », Nikia Filipovic [I.18] montrent les principaux protocoles, technologies et standards dans les web services

Ø The simple Object access Protocol (SOAP) combine XML et Multipart Internet Mail Extensions (MIME) pour créer un "extensible packaging format". Message SOAP peut être transporté par beaucoup de mécanismes de transport, comprenant http, SMTP et le transport traditionnel des messages.

Ø The Web Services Description Language(WSDL) est un vocabulaire XML utilisé pour décrire les Web Services. Il définit les opérations, les types de données et "binding information". Artefact.

Ø Universal Description, Discovery, and Integration (UDDI) fournit le modèle pour organiser, régistrer et accéder l'information sur les web services.

Ø The Web service Flow Language (WSFL) et le Web Service Collaboration Language (WSCL) sont concernés par la description du workflow entre les services, ainsi leurs rapports peuvent être encapsulés faisant la partie de l'application.

Ø Electronic Business XML(ebXML) fournit le framework pour e -commerce qui inclut le "inter-application workflow" et la description et la découverte des services. Il utilise le SOAP comme le mécanisme du transport mais n'utilise pas directement WSDL, UDDI ou WSFL.

Pour transporter les messages entre applications les MOM utilisent des technologies telles

que [I.19] :

Ø Le modèle de programmation des invocations distantes : l'entité appelante (client), avant de demander un service à une autre entité (serveur), doit connaître l'existence d'un tel serveur capable de satisfaire/exécuter sa requête et doit obtenir sa référence.

Ø Le modèle d'une architecture basée sur des événements : les composants coopèrent par l'envoi et la réception d'événements, un type spécial de messages. L'émetteur du message (la source) transmet un message à un aiguilleur de message qui se charge de le distribuer à tous les composants ayant déclaré leur intérêt dans la réception de ce message. Ce type d'infrastructure s'appelle souvent MOM (Message Oriented Middleware).

Modèles de programmation 

  Les solutions d'EII s'adossent à différents modes d'interfaçage pour s'affranchir de l'hétérogénéité technologique des serveurs de données de l'entreprise. Il peut s'agir de connecteurs (JDBC, ODBC ou encore JCA) ou encore de web services (interfaces SOAP/WSDL).

La transmission à l'application de données structurées selon un format normalisé peut se faire de diverses façons selon Lucy Bottomley [I.20] et les méthodes les plus couramment utilisées sont les suivantes :

Ø EDI direct ou point à point : L'EDI direct assure une liaison directe entre deux ordinateurs.

Ø Réseau à valeur ajoutée (RVA) : Le RVA met à la disposition de l'abonné une boîte aux lettres électronique permettant l'enregistrement et la retransmission des messages, et un certain nombres de services supplémentaires.

Ø Internet : Le réseau Internet constitue une méthode rapide et peu coûteuse à laquelle on pourrait éventuellement faire appel pour la livraison des messages par courrier électronique ou par transfert de fichiers.

Selon mounir Fegas [I.21], les documents XML sont représentés par un ensemble de leurs paths et sous-paths, qui sont classées par longueur. Cette représentation nous permet d'aplatir ces documents, tout en conservant leurs structures.

 Sur le plan conceptuel, un document XML a deux parties:

Ø le document proprement dit, obligatoirement présent,

Ø une description formelle optionnelle, appelée Document Type Definition (DTD).

Cette description contient les règles syntaxiques que doit respecter le document. Tout se passe comme pour un programme que l'on écrit dans un langage de programmation: le langage a une grammaire qui décrit les structures syntaxiques permises pour un programme et les mots réservés que l'on emploiera.

Les outils APL de Veys [I.22] utilisent une mesure de ratio d'interaction qui crée des domaines selon le degré d'échanges d'information de part et d'autre des fonctions. Elle comprend une étape d'analyse de l'organisation et de sondage auprès des utilisateurs sur les processus d'affaires, les classes de données et les unités organisationnelles. Cette méthode de conception d'architecture ne cherchait pas à créer un modèle générique. »

Le logiciel d'EAI offre par ailleurs [I.23] un ensemble de composants architecturaux qui facilite grandement les échanges entre les bases de données. Parmi ces composants figurent les services de transformation de données, la sécurisation et la fiabilisation des échanges, l'utilisation de connecteurs standard d'accès aux sources de données.

Dans leur recherche, Losavio et al. étendent [I.16] un modèle conceptuel d'intégration d'outils CASE pour avoir une conception unique et cohérente au niveau des mécanismes dans une organisation. 

Mécanismes
Architecture	Styles architecturaux	Patrons
	. Invocation par évènements	. Courtier
	. Niveaux en couche	. Réflexion
	. Dépôts d'archives	. Façade d'encapsulation
		. Intercepteur

L. Avignon et T. Brethes dans « Le livre blanc de l'EAI- Intégration des applications d'entreprise » [I.24] citent trois principales architectures EAI, par ordre d'importance décroissant dans les systèmes actuels qui sont :  

Ø Le transfert de fichier représente l'immense majorité des flux d'information. Quand deux applications communiquent, le premier mécanisme mis en oeuvre consiste à extraire une partie de l'information contenue dans l'application, puis, pour chaque destinataire, la formater et la transmettre.

Ø Les systèmes d'extraction orientés datawarehouse ( Extract -Transform-Load : ETL) constituent une avancée dans le domaine puisqu'ils prennent en charge la gestion d'un dictionnaire mettant en relation les données sources (qui peuvent être sous différentes formes : fichiers, bases relationnelles, etc.) et les données cibles du datawarehouse.

Ø Les systèmes de réplication SGBDR sont optimisés pour répliquer en mode fil de l'eau ou en mode batch des données issues de SGBDR.  »

L'architecture de référence des web services s'articule autour des trois rôles suivants [I.4]:

Ø Le fournisseur de service : correspond au propriétaire du service. D'un point de vue technique, il est constitué par la plate-forme d'accueil du service.

Ø Le client : correspond au demandeur de service. D'un point de vue technique, il est constitué par l'application qui va rechercher et invoquer un service. L'application cliente peut être elle-même un web service.

Ø L'annuaire des services : correspond à un registre de descriptions de services offrant des facilités de publication de services à l'intention des fournisseurs ainsi que des facilités de recherche de services à l'intention des clients. »

Client

Recherche/localisation

Lier ( bind)/connecter

Invovation

service/méthodes

Fournisseurs de services

Implémentation

Déploiement

Description et

publication

Annuaire de

Service

(e.g. UDDI)

2 - Rechercher WSDL

4 - Invoquer (SOAP)

1 - Publier (WSDL)

3 - Lier/

connecter

Architecture des services web

Philippe Laumay dans « Déploiement d'un bus à message sur un réseau à grande échelle » [I.25] montre qu'il existe trois types d'architectures qui assurent une modularité de déploiement des MOM sur n'importe quel type de topologie réseau et applicative :

Ø La topologie hub and spoke est une architecture centralisée représentée par un seul serveur représentant le MOM.

Ø La topologie snow flake est une architecture distribuée représentée par un ensemble de serveurs interconnectés (mais pas complètement maillés).

Ø La topologie en Bus est une architecture distribuée représentée par un ensemble de serveurs interconnectés à la manière d'un LAN (c'est à dire un graphe de serveurs complètement maillés). »

On peut citer trois types d'architecture MOM : Hub and spoke, Snow flake, Bus.

L'architecture hub and spoke est appelée ainsi car elle se présente comme une roue de vélo, où tous les rayons (spoke) sont reliés au même moyeu central (hub). Cette architecture est constituée d'un serveur principal unique qui centralise tous les messages .

L'envoi de message est très simple à réaliser, l'émetteur lance son message au serveur central (broker) puis celui-ci le transmet dans la boîte aux lettres du destinataire. 

Le deuxième type d'architecture est appelée snow flake à cause de sa topologie en flocon de neige (voir Figure ). Contrairement à l'architecture précédente, ici le gestionnaire de messages est distribué sur plusieurs sites. Le MOM est donc représenté par un ensemble de serveurs qui constitue le gestionnaire global, chaque serveur étant une partie (un sous-module, une subdivision, etc.) de l'ensemble. Lorsqu'un client (une application) s'adresse au gestionnaire de messages il s'adresse en fait à l'un des "serveurs de messages". L'émetteur envoi un message au gestionnaire de messages via un serveur appelé point d'accès, puis le message est transmis par le serveur soit directement au destinataire si celui-ci est associé au même serveur, soit à un autre serveur auquel est associé le destinataire. 

Dans le livre « MTS & MSMQ » de Alex Hormer et D. Sussman [I.26] et dans l'article « A case for Message Oriented Middleware » de G. Banavar [I.27], les auteurs disent que la topologie de l'architecture « Snow flake » permet de réaliser plus facilement une application à grande échelle. Dans l'architecture précédente, le passage à l'échelle était limité à cause du nombre restreint de clients associés à l'unique serveur gestionnaire de messages. Dans cette configuration, il est aisé de relier un grand nombre de serveur et de déployer les clients sur ces différents sites. Ainsi tous les clients ne s'adresseront pas toujours au même serveur.

P. Reiss a dans son article « Connecting Tools Using Message Passing in the Field Environment » [I.28] dit que l'architecture en Bus est la plus récente des architectures répartie, elle est employée dans les MOM les plus récents. Le modèle de bus à messages n'est pas forcément une architecture définie au niveau physique. Le bus logiciel est en fait une vision logique d'une architecture distribuée dont le but est d'acheminer les messages à leurs destinataires. La vision réelle de l'architecture d'un bus est une architecture snow flake qui serait complètement maillée.

L'architecture d'une solution EDI est constituée de 3 composants [I.29] :

Ø Le système d'information. Celui-ci représente l'ensemble des applications amenées à échanger des messages.

Ø Les logiciels EDI, ou traducteurs. Leur principal rôle est d'assurer la transformation des

données d'un format applicatif, propre à l'entreprise, à un format d'échange standard, reconnu

par le partenaire.

Ø Les interfaces de communication. Ceux-ci permettent l'envoi et la réception de messages EDI sous différents protocoles et sur différents réseaux.

XML (eXtensible Markup Language) est similaire à HTML (HyperText Markup Language), dans le sens où il utilise un système de balises ouvrantes/fermantes. Cependant, XML va beaucoup plus loin dans la définition des règles syntaxiques associées au langage, et constitue un langage stricte et standardisé pouvant être réutilisé et adapté aux besoins spécifiques d'applications.

XSL

WSDL

SOAP

UDDI

Web services

EAI

Quelques langages de l'univers XML

XQUERY

BPML

Les constituants de base d'un document XML sont les « éléments », et les « attributs » [I.30] .

Un document XML est dit `bien-formé' s'il respecte le formalisme XML (éléments-attributs) et les règles associées (encodage ...)

 Le Model Driven Architecture (MDA) [I.31] est une démarche de développement proposée par l'OMG. Elle permet de séparer les spécifications fonctionnelles d'un système des spécifications de son implémentation sur une plate-forme donnée.

Cécile Bourreau dans son mémoire « Développement sur l'ERP libre OfbizNéogia » explique que [I.32] l'utilisation de l'ERP est très marquée dans le monde industriel avec la gestion de stocks et de fabrication, mais également dans les activités tertiaires avec la gestion de commandes et les sites E-commerces. Actuellement le marché des ERP est dominé par des applications de type propriétaires tel que SAP, BAAN, ORACLE, etc. Cependant il immerge de nouvelles technologies basées sur les logiciels Libres comme les projets GNU Enterprise, Ofbiz ou bien Compiere.

L'intégration au niveau des processus métier, également appelée BPI ( Business Process

Integration), permet de concevoir des processus métier et de les relier aisément aux applications sous-jacentes.

L'intégration au niveau des applications est un bon départ en vue d'une exposition des API métier des applications en tant que web services.

L'intégration de la couche métier n'est cependant pas toujours une tâche aisée. En effet, toutes les applications ne fournissent pas des API métiers. La notion de couche n'existe pas et les seules interfaces qu'elles exposent sont constituées par des grilles d'écran.

  Pour mettre en évidence l'utilisation des web services, Mathieu Nicolescu [I.33] dit qu'une entreprise qui veut mettre en place un système de messagerie au sein de son intranet, voire par la suite Internet pourra donc opter pour la technologie des web services en développant le serveur de messagerie en web service .NET. L'avantage est que l'application cliente pourra être développée sous n'importe quel langage.

IBM a conçu une plateforme nommée  WebSphere Everyplace qui permet l'accès des utilisateurs mobiles aux données de l'entreprise. Cette plate-forme est conçue comme une extension du serveur d'application WebSphere qui intègre la spécification JMS. Parmi les points intéressants de cette technologie est sa capacité à fournir l'accès à des utilisateurs utilisant des protocoles de communications différentes ( GPRS, SMS, WAP, Wifi, Bluetooth ...). Everyplace utilise pour cela des services pour l'adaptation du contenu suivant les capacités et les formats de données pris en charges par les terminaux mobiles.

Pierre-Yves Fourmond [I.34] montre comment  les Middleware Orientés Message sont très utilisés dans le domaine de l'EAI (Enterprise Application Integration).

Les autres secteurs utilisateurs de MOM incluent, par exemple, le datawarehouse, les messageries inter-bancaires ainsi que la diffusion d'informations. 

L'EII est utilisé dans des projets impliquant la consolidation de données ( dans le cas de la relation clientèle ou plus généralement lors de la mise en oeuvre d'un portail d'entreprise. Il est encore utilisé dans le champ de la Business Intelligence (BI) - qui effectue des traitements divers (prédictifs, multidimensionnels, etc.) sur des données issues en général de systèmes internes variés - en vue de proposer des rapports de suivi de l'activité de l'entreprise. 

 Le développement des EDI est présenté comme devant apporter l'ouverture contrôlée des systèmes d'information internes aux communautés des professionnels du droit et aux grands partenaires de l'institution judiciaire, l'accès sécurisé en consultation et mise à jour aux bases de données (casier judiciaire, fichier national des détenus, statistiques), l'enrichissement des fonctions d'accueil et de renseignement, les moyens d'une mise en place d'un accueil de proximité, de juridictions spécialisées, de travail déporté, en accompagnement des décisions qui interviendraient au titre de la réforme de la carte judiciaire, et ceux d'une alimentation automatique du fichier de jurisprudence. 

Mounir FEGAS [I.21] illustre l'utilisation de l'intégration à travers Oracle qui proposera en 1999, avec Oracle 8i, une offre d'interopérabilité XML intéressante. On pourra stocker des documents XML dans la base de données, accéder à ses éléments, effectuer des conversions entre modèles XML et relationnel.

Dans son mémoire intitulé « Mise en place d'un système d'information décisionnel dans un environnement médical », A.S.T Sané comment l'intégration peut être utilisé dans le domaine médical en ces termes [I.35] « les besoins du corps médical en terme de reporting - requêtes, statistiques, analyse de données peuvent être vus selon deux grands métiers : la gestion., la recherche.

L'intégration en général pourrait être représentée sur le schéma ci-dessous