Annexe 1 – Termes de Référence de la Mission

Rapport – Décembre 2008 ProGenia

Nom et Prénoms Fonction

DGB

CODJIA A. Bertrand DGB

ADJAHO Toussaint DPB

BOTON Paul Directeur des Dépenses en Capital

DOSSOU Côme Coordonnateur SIGFiP

BOTON Paul Directeur des Dépenses en Capital

ADONON Brice B Equipe SIGFiP / DGB

BEKPON François Equipe SIGFiP / DGB

DOI

CODJIA Ignace DOI

LAHAMY Armel SGP/DOI

DGTCP

ASSOGBA A. Françoise DGATCP

ADJAHI Dieudonné Maurice Coordonnateur National ASTER

LOKONON Pascal Equipe ASTER / DGTCP

ABENIN Antoine Equipe ASTER / DGTCP

DOSSA Thierry Equipe ASTER / DGTCP

GBOTOUNOU S. Pauline Equipe ASTER / DGTCP

ADEGBINDIN Affoussatou Equipe ASTER / DGTCP

ALIKON Pierre V. Equipe ASTER / DGTCP

AGUESSY K. Anastasie Equipe ASTER / DGTCP

DENAKPO Vincent Chef Cellule Informatique DGTCP

ACACKPO Paul Cellule Informatique DGTCP

KELOME Patrick Cellule Informatique DGTCP

Contrôle Financier

ABOUDOU G. Solange CF

DGDDI DGDDI

SOGNON DGI

HOUENOU Delphin CSI

BEHANZIN Luc SI/DGDDI

Rapport – Décembre 2008 ProGenia

DGID

HOUINSAVI Antoine Responsable Takwe

Rapport – Décembre 2008 ProGenia

Marché

ƒ Un marché convoité par de très nombreux acteurs 9 IBM CrossWords

9 webMethods 9 Tibco

9 SeeBeyond 9 Vitria 9 Microsoft 9 Sungard 9 Oracle

9 Sybase e-Biz Integrator NEON 9 Peregine Integration

9 Bea Weblogic Integration 9 STC

9 Software AG 9 Mercator 9 eWebIT

ƒ Quelques Outils d’EAI : Les produits phares du marché WebSphere Business Integration d’IBM.

Principes et structure de l'offre

Le principe de la solution

Si IBM parle désormais de la solution WebSphere Business Integration, un rapide examen de la structuration technique de l'offre montre que cette offre comprend toujours deux serveurs d'intégration: WebSphere Interchange Server (ex-Crossworlds Interchange Server) et WebSphere MQ Integrator Broker (ex-MQSeries Integrator). Le rapprochement des offres emprunte en fait d'autres voies que celle de la fusion des deux moteurs. En l'occurrence, IBM a choisi de fédérer les deux offres en leur faisant partager les mêmes outils de développement et d'administration ainsi que les mêmes adaptateurs. Question légitime:

comment IBM justifie la cohabitation de deux moteurs d'intégration ? La réponse est aujourd'hui très claire. Les représentants d'IBM estiment que les projets EAI entrent dans deux grandes catégories bien distinctes: les projets d'intégration par les données et les projets d'intégration par les processus. Dans la logique de Big Blue, ces deux types d'intégration renvoient à des contraintes bien différentes qui justifient le maintien de deux moteurs d'intégration. Ou plutôt de trois moteurs, puisque l'exécution du workflow appelle lui aussi un moteur spécifique.

Rapport – Décembre 2008 ProGenia

Les composants d'exécution

WebSphere

Interchange Server

Anciennement nommé Crossworlds Interchange Server, ce serveur d'intégration est exploité dans le contexte d'une approche top-down, centrée donc sur l'intégration par les processus.

WebSphere MQ Integrator Broker

Anciennement nommé MQSeries Integrator, ce moteur prend en charge la logique d'intégration par les données.

WebSphere MQ Workflow

Comme son nom l'indique, ce moteur exécute la logique des processus qui incluent potentiellement des activités humaines.

Les composants de conception

WebSphere Studio Workbench

Environnement principal de l'offre, fondé sur Eclipse, il ouvre accès à des perspectives qui diffèrent en fonction du moteur d'intégration utilisé. Les outils incontournables sont là pour mettre en correspondance les modèles de données, spécialiser les flux techniques et mener des tests. En quelque sorte, ces perspectives à l'offre d'EAI ce que WSAD (Webpshere Studio Application Development) est au serveur d'applications.

WebSphere Business Integration Modeler

Véritable outil dédié de BPM, le modeler permet de modéliser mais aussi de simuler les processus. Deux précisions. Primo, les processus élaborés ici seront ensuite exécutés par WebSphere MQ Workflow et/ou WebSphere Interchange Server. Secundo, ce Modeler n'est pas livré " en standard " avec le moteur d'intégration, il s'agit d'un produit à part entière qui sera donc acquis distinctement.

Les composants de connexion et de spécialisation

WebSphere Business Integration Adapters

Sans surprise, la bibliothèque d'adaptateurs est suffisamment riche pour couvrir la très grande majorité des besoins : connexions aux ERP, aux SGBDR et à des ressources plus techniques (moniteurs transactionnels par exemple), etc.

WebSphere Business Integration

Collaborations

Les collaborations regroupent des dictionnaires, des règles et des modèles de processus spécifiquement conçus pour des univers métier (télécom, distribution, assurance…). Elles correspondent à des packages verticaux ou horizontaux qui accélèrent le paramétrage de la plate-forme.

Les composants d'administration

Les composants d'administration La palette des outils est classique mais complète et

Rapport – Décembre 2008 ProGenia

(par exemple pour identifier des erreurs et pour rejouer des interactions) ou encore de contrôler à distance les composants d'intégration.

Notons la présence d'un outil de BAM (Business Activity Monitor), WebSphere Business Integration Monitor qui permet de disposer de tableaux de bord pour suivre en temps réel l'état des processus et relever des indicateurs de performance.

Biztalk Server de Microsoft. Né à la fin de l'année 2000, Biztalk Server a marqué l'arrivée de Microsoft sur un marché de l'EAI bien occupé alors par des " Pure Players ". Si à son arrivée le produit semblait assez nu (il lui manquait tout simplement des connecteurs !), il a depuis sensiblement évolué.

Le tableau suivant détaille les cinq outils principaux qui composent l'offre Microsoft.

Les cinq outils principaux de la plate-forme Biztalk Server 2002

Biztalk

Orchestration Designer

Sous ce nom se cache l'interface de l'outil Visio utilisée ici par Microsoft pour modéliser les processus qui sont orchestrés par Biztalk. Une interface à deux visages : la fenêtre de gauche est dédiée à la conception du processus métier tandis que dans la fenêtre de droite est destinée à la traduction de ce processus métier en flux techniques. Attention, l'outil n'est pas seulement là pour aider à concevoir visuellement les processus ; une fois ce travail achevé, un fichier est produit au format XLANG afin d'être exécuté par le serveur d'orchestration.

Biztalk Messaging Manager

Avec l'Orchestration Designer, le Messaging Manager représente l'un des piliers fondamentaux de la plate-forme. C'est en effet à travers cet outil qu'est paramétré l'ordonnancement des opérations techniques, de la réception d'un document source à l'émission du document cible. Ce que, dans le jargon de Biztalk, Microsoft nomme le " Channel ". Ce Channel une fois configuré présente des ports qui lui permettent ensuite d'être manipulé à travers l'Orchestration Designer.

Biztalk Mapper

Comme son nom l'indique assez bien, le " Mapper " a pour vocation de définir les règles de transformation de données d'un schéma source à un schéma cible. Un outil qui, dans le cadre de Biztalk, est particulièrement bien réussi en termes d'ergonomie. L'éventail des opérations de transformation (matérialisée sous la forme de " functoïds ") est large. En outre, il semble assez simple d'ajouter à la palette ses propres functoïds (développés en Vbscript, Jscript ou en .NET).

Biztalk Editor C'est avec lui que seront définis les schémas correspondant à des documents XML, EDI ou autres, schémas qui pourront ensuite être utilisés

Rapport – Décembre 2008 ProGenia

à travers le mapper.

Biztalk

Administration

Cet outil offre notamment d'accéder à différentes queues de message (Work, Scheduled, Retry…) où sont stockés les documents en fonction de leur statut.

A ces 5 outils, il faut encore ajouter des fonctions d'administrations qui représentent l'une des principales nouveautés de la version 2002 de Biztalk Server. Le déploiement des serveurs Biztalk peut en effet être opéré depuis Application Center avec une bonne granularité tandis que la plate-forme globale (De Windows Server à Biztalk en passant par SQL Server) pourra être supervisée via Operations Manager.

Voilà pour les outils principaux de Biztalk Server 2002. Bien entendu le produit ne serait pas complet sans une bibliothèque de connecteurs. Sur ce sujet, Microsoft affirme disposer aujourd'hui d'environ 350 AIC (Application Integration Component). Microsoft en fournit 4 directement (pour SAP, MQSeries, SQL Server et pour les Web Services) auxquels il faut ajouter des packages verticaux présentés sous la forme d'accélérateurs métiers pour Rosettanet (électronique), HIPAA (Santé) et FSA (Finance Swift). L'essentiel des AIC est proposé par des partenaires, notamment par iWay et Attuinity. Point important : Microsoft assure le support pour l'ensemble des AIC.

webMethods Integration Server de la société webMethods. Depuis le rachat d'Active Software en mai 2000, webMethods affiche une ambition claire : proposer une plate-forme d'intégration globale capable de fédérer l'ensemble des îlots applicatifs de l'entreprise (des mainframes aux applications J2EE) et derrière laquelle s'effacent les distinctions techniques habituelles entre flux A to A (internes) et B to B. Une ambition qui demandait de fusionner deux plates-formes d'intégration - celle de webMethods et celle d'Active - et une multitude d'outils.

Les différents composants de la plate-forme webMethods peuvent être classés dans quatre groupes.

Les composants d'exécution

webMethods Integration Server

Composant principal de la plate-forme webMethods, l'Integration Server peut être comparé à la fois à un super-connecteur et à un petit chef d'orchestre.

Environnement d'exécution, l'Integration Server héberge un ou plusieurs adapteurs. En d'autres termes, un adapteur, dans la nouvelle architecture webMethods, est forcément associé à un Integration Server. Il faut noter que les fonctions de l'Integration Server sont modulables (via des packages) afin de maîtriser l'empreinte mémoire.

Rapport – Décembre 2008 ProGenia

car, dans le cadre de l'exécution d'un processus, il embarque l'intelligence nécessaire pour situer les traitements dont il a la charge dans le processus.

Autrement dit, la plate-forme webMethods distribue l'exécution des processus aux serveurs d'intégration concernés.

Enfin, l'Integration Server présente deux caractéristiques fortes. Primo, il se conforme au modèle JCA (standard J2EE pour les connecteurs inter-applicatifs) et dispose d'un adapteur pour JBoss afin d'interagir avec des EJB. Dans le courant de l'année, l'intégration avec JBoss sera plus intime et permettra de travailler avec les EJB sur un mode bidirectionnel, en synchrone et en asynchrone. Secundo, l'Integration Server embarque un procédé de stockage temporaire afin de disposer de sa propre gestion des queues de message. Une fonction qui permet de gérer par exemple des interruptions de communication avec le broker.

webMethods Broker

Le broker s'occupe de router les messages échangés entre les Integration Server sur un mode asynchrone et dans un modèle publish/subscribe. Les Integration Server sont en quelque sorte les clients du broker. A noter qu'il est possible désormais d'installer une plate-forme d'intégration webMethods en se passant du broker. En effet, si tous les adapteurs nécessaires sont hébergés dans un seul Integration Server, celui-ci peut gérer localement les échanges de message. Une précision toutefois : la mise en œuvre du moteur de workflow, pour prendre en compte les interactions humaines dans le cadre des processus, nécessite le déploiement du broker. Notons qu'une licence du broker en runtime est fournit avec le Workflow.

webMethods Workflow Server

Tout comme l'Integration Server, le Workflow Server peut être considéré comme un client du broker. Il exécute les tâches qui, dans le cadre d'un processus, relèvent d'une interaction humaine. A cette fin, le Workflow Server s'abonne aux documents qui appellent une interaction humaine et publie via le broker le résultat de ces interactions.

Les composants de connexion

webMethods Adapters

Exécutés par l'Integration Server, les adapteurs exposent à la plate-forme d'intégration les données et les services de l'application dont ils ont la charge. Les premiers adapteurs disponibles dans le cadre de la V6 concernent notamment la connectique JDBC, SAP, Siebel et JDE.

webMethods Mainframe

Dans la plate-forme webMethods, l'accès aux applications mainframe (CICS ou IMS/DC) représente une connectique particulière puisqu'il ne s'exécute pas sur l'Integration Server. Ce dernier passe ses requêtes à un "

composant mainframe " qui à son tour dialogue avec l'application cible. Si le connecteur mainframe s'apparente à un connecteur particulier, en

Rapport – Décembre 2008 ProGenia

revanche il se paramètre bien depuis l'outil Developer.

webMethods Trading Networks

Exécuté sur l'Integration Server, ce module est spécialisé dans le traitement de documents XML et de fichiers plats. C'est par son intermédiaire que la plate-forme webMethods peut interpréter des sémantiques issues de standards comme ebXML, RosettaNet (pour l'électronique), CIDX (pour la Chimie) ou encore EDI et Swift.

Les composants de conception

webMethods Modeler

C'est avec le Modeler que les différentes étapes d'un processus ainsi que les documents échangés sont définis de façon visuelle. Une fois le modèle défini, des schémas d'exécution sont générés pour chaque étape et déployés sur les Integration Server (et Workflow Server) impliqués.

webMethods Developer

Outil dédié à l'intégrateur technique, le Developer permet de paramétrer et de tester les flux techniques. Le Developper fournit une interface unique, pour les différents adapteurs, pour les différents adapteurs, pour l'invocation de services Web, etc.

webMethods Workflow Designer

Depuis le Modeler, une interaction humaine est vue comme une tâche spécifique définie par l'entremise du Workflow Designer. Un outil à travers lequel, rôles, tâches et circuits sont définis. Les interactions avec l'utilisateur sont gérées depuis des interfaces clientes Java ou HTML.

Les composants d'administration

webMethods Administrator

L'Administrator consolide au sein d'une unique interface Web l'accès aux consoles de configuration et d'administration des différents serveur d'intégration et, point important, de leurs adapteurs.

webMethods Monitor

Le Monitor permet d'observer les statuts des processus, services et documents traités à travers la plate-forme. C'est depuis cet outil qu'un exploitant peut par exemple suspendre un processus ou resoumettre un document.

webMethods Manager

Conçu autour du standard OMI (Open Management Interface), co-développé par webMethods et HP, le Manager comprend à la fois des interfaces et une console pour superviser les différents composants de la plate-forme d'intégration (Integration Server, Broker…) dans une perspective de gestion de la qualité de service. Surtout, OMI ouvre cette supervision à des outils tels que HP Open View, CA Unicenter ou encore BMC Patrol.

Rapport – Décembre 2008 ProGenia

(Extract, Transformation and Loading) en jouant notamment la carte des standards Java. En 2001, à l'heure où les plates-formes EAI s'imposent dans le paysage de l'intégration logicielle, l'éditeur affiche à son tour des ambitions dans ce domaine, jouant sur un angle d'attaque du marché cohérent avec sa technologie. A savoir celui de "l'intégration par les données", par opposition aux pure players de l'EAI, qui se veulent plus centrés sur l'intégration par les processus.

La plate-forme de Sunopsis appartient donc à ces solutions que l'on classe habituellement dans la catégorie (plus ou moins bien nommée) des "EAI tactiques". Au-delà des débats théoriques (voire sémantique), un fait s'impose : la solution de Sunopsis répond à des besoins d'intégration d'applications - même si cette intégration est très orientée données.

Principes et structure de l'offre

Parce qu'elle est centrée sur l'intégration des données, la solution de Sunopsis oblige à abandonner les schémas habituellement utilisés pour analyser et structurer une plate-forme d'EAI traditionnelle. Il n'est en effet point question ici de serveur d'intégration ou de broker.

La logique est tout autre : au lieu d'exploiter un moteur d'intégration au sein duquel s'opèrent les opérations de transformation et de routage, Sunopsis v3 s'appuie sur les capacités de traitement des applications source et cible.

Le concept clef à saisir ici est celui d'espace de travail. Quand un traitement est élaboré à travers Sunopsis, le développeur précise l'espace de travail dans lequel il va s'exécuter. Cet espace peut être réservé dans l'espace de l'application source, de l'application cible ou éventuellement dans le "Memory Engine" de la solution. Concrètement, des tables temporaires sont créées dans les applications concernées (bases de données, progiciels…).

Autrement dit, Sunopsis distribue le traitement des opérations auprès des applications concernées et s'appuie à cette fin sur leurs capacités natives (SQL, PL/SQL, Java, etc.). In fine donc, tout se termine avec Sunopsis par des traitements SQL. Conséquence directe : les performances des intégrations élaborées à travers Sunopsis dépendent directement des performances des applications sources et cibles et non de celles d'un moteur d'intégration qui s'interposerait entre ces éléments.

Côté transport, si, dans l'esprit Sunopsis, les applications initient et prennent en charge elles-mêmes les échanges de données, elles peuvent aussi publier leurs messages dans un MOM.

Pour la connectique, précisons que la solution s'appuie sur les standards Java : JDBC en premier lieu, mais aussi JMS et JCA.

Pour comprendre la structure de la plate-forme, distinguons les principaux outils proposés et les composants mis en œuvre.

Rapport – Décembre 2008 ProGenia

Les outils

Sunopsis Topology Manager

Cet outil est utilisé pour identifier l'architecture physique, puis logique du système d'information. Bref, il s'agit ici d'identifier et de référencer l'ensemble des ressources. C'est aussi à l'aide du Topology Manager que sont définis des contextes de développement, de recette, de production, etc.

Il est ensuite très simple d'indiquer dans quel contexte l'on souhaite travailler.

Sunopsis Designer

Comme son nom l'indique, le designer est l'outil de développement principal. Ici, l'essentiel s'orchestre via des glisser-déposer. Données sources et données cibles sont glissées dans une fenêtre afin d'être mises ensuite en correspondance. Des déclencheurs sont paramétrés (modification d'une données, arrivée d'un email, publication d'un fichier dans un répertoire, arrivée d'un message dans une queue…), des contrôles sont définis et les opérations de mapping (transformation) sont précisées.

Pour chaque traitement, un espace de travail est nommé.

Sunopsis Security

Cet outil permet d'éditer les habilitations des différents utilisateurs de la plate-forme.

Sunopsis Designer

Comme son nom l'indique, le designer est l'outil de développement principal. Ici, l'essentiel s'orchestre via des glisser-déposer. Données sources et données cibles sont glissées dans une fenêtre afin d'être mises ensuite en correspondance. Des déclencheurs sont paramétrés (modification d'une données, arrivée d'un email, publication d'un fichier dans un répertoire, arrivée d'un message dans une queue…), des contrôles sont définis et les opérations de mapping (transformation) sont précisées.

Pour chaque traitement, un espace de travail est nommé.

Sunopsis Operator

Outil destiné à l'exploitant, ce module permet à l'opérateur de planifier, surveiller, et de diagnostiquer les problèmes d'exécution.

Les principaux composants mis en œuvre

Les référentiels

Sunopsis distingue le référentiel maître (forcément unique) et les référentiels de travail, tous hébergés sur un SGBDR. A titre d'exemple, un agent peut embarquer localement un référentiel dit de travail afin de limiter les risques d'une rupture de communication avec le référentiel maître.

Les modules de connaissance

Au nombre d'une quarantaine, ils s'apparentent à des méta-modèles de données. Ces modèlent décrivent la logique qui permettra de générer ensuite des scripts dans des langages propres à chaque application. Les principaux SGBDR et ERP du marché sont aujourd'hui couverts par ces modules de connaissance.

Les agents

Dans la philosophie de Sunopsis, les agents doivent être vus comme des ordonnanceurs. En effet, ces agents ne véhiculent pas les données (même si cette possibilité existe) : ils exécutent des scénarios qui créent (et

Rapport – Décembre 2008 ProGenia

et à mesure des traitements demandés. Et ce sont les applications qui s'échangent les données, quelque sorte en direct. A noter qu'un agent peut faire appel aux scénarios associés à un autre agent.

Le Memory Engine

La plate-forme dispose de son propre moteur de transformation Java qui peut donc être exploité comme un espace de travail intermédiaire entre les données source et cible, même si ce n'est pas vraiment l'esprit de la solution. Ce Memory Engine s'avère notamment utile quand les applications sources et cibles ne possèdent pas de capacités de transformation. L'éditeur indique que l'emploi du Memory Engine est préférable quand le volume de chaque échange à traiter est faible car tout s'opère en mémoire. En revanche, pour de grandes volumétries (plus de 10 000 lignes par minute), le recours aux environnements sources et/ou cibles apporte plus de performances.

Le journal

Toutes les opérations (création d'un espace de travail, transformation, publication d'un message, etc.) sont historisées dans un journal, stocké dans le référentiel auquel l'agent est connecté en permanence.

Vitria Businessware 4 de Vitria. Vitria s'est dès l'origine concentré sur une approche très top-down de l'EAI, donnant une large place au BPM (Business Process Management). Un axe de travail que l'éditeur a maintenu depuis la première commercialisation de sa plate-forme Businessware, en 1998.

Businessware 4, la nouvelle itération de sa plate-forme, s'inscrit pleinement dans les tendances fortes du moment. Résultat, le terme "EAI", déjà peu utilisé auparavant par Vitria, disparaît quasiment de l'argumentaire. Businessware est avant tout présentée comme une plate-forme d'intégration de processus capable de travailler avec différents modèles technologiques (EAI, J2EE, Web Services, etc). Assez naturellement, la mise en conformité de la solution avec les standards J2EE et avec les standards des Web Services représente une autre évolution de la plate-forme. Enfin, la version 4 met fortement l'accent sur le maintien de la cohérence de la représentation du projet tout au long de son cycle de vie (conception, test, déploiement, administration…).

Principes et structure de l'offre

Le référentiel

Au sein de la plate-forme Vitria, le référentiel principal (pour la conception et l'exécution) est un annuaire Ldap. Ce choix facilite évidemment le stockage des informations relatives aux droits des utilisateurs de la plate-forme. Par défaut, l'accès à ce référentiel s'effectue via l'API Java JNDI. Il faut noter que Vitria livre avec sa solution une

Rapport – Décembre 2008 ProGenia

version de l'annuaire de Sun limitée à cet usage. Cependant, l'utilisation de IBM Directory Server 4.1 ou de Microsoft ActiveDirectory est possible.

Businessware Modeling Environnement

Environnement de développement principal de la plate-forme, cet outil est utilisé pour définir de bout en bout le modèle d'intégration. Tous les services et composants qui participent à ce modèle sont regroupés dans un

"projet". Cette vue projet est maintenue à travers les interfaces de tests, de déploiement et d'administration. C'est à travers cet outil également que la prise en compte des standards apparaît clairement. En effet, l'intégrateur a la possibilité d'associer un modèle d'intégration (ou une partie de ce modèle) à un proxy pour le rendre invocable depuis un appel de type RMI/IIOP ou Web Service. A l'inverse, un modèle d'intégration Businessware peut recourir à RMI-IIOP pour appeler un traitement hébergé sur un serveur d'applications J2EE.

Businessware Automator

Outil d'exécution des processus métiers (modélisés dans BME), Businessware Automator s'appuie sur une modélisation UML. Ce qui n'interdit pas cependant de récupérer des modèles UML générés depuis d'autres outils.

Businessware Transformer

Comme son nom l'indique, le Transformer est l'outil par lequel les modèles de données sont mis en correspondance. C'est avec lui que l'utilisateur pourra notamment tirer parti des "Common Business Objects", nom donné par Vitria à des dictionnaires dans lesquels sont pré-établies des transformations de données (par exemple de SAP à Oracle Applications).

Ces CBO sont livrés dans les Vitria Collaborative Application, des packages verticaux.

Businessware Server

Le serveur d'exécution de la plate-forme est écrit en Java. Cependant, hors de question ici de le faire fonctionner sur un serveur d'applications du marché (Websphere, Weblogic…). Vitria a préféré pour l'heure s'en tenir à son propre container Java. Au chapitre de la robustesse, notons que la persistance de toutes les instances de processus est effectuée dans une base de données.

Businessware Communicator

Sous ce nom se cache le gestionnaire de messages asynchrones de Vitria.

Techniquement, Businessware 4 se distingue de la mouture précédente par la dissociation désormais établie entre cette couche transport et le reste de la plate-forme. Rappelons que, jusqu'à la version 3, Businessware s'appuyait sur un bus de communication propriétaire (même s'il faisait appel au modèle Corba). Ce middleware est toujours présent dans la version 4 mais n'est plus incontournable. Tout d'abord, cette couche transport peut-être en quelque sorte court-circuitée en utilisant des proxies pour utiliser directement des protocoles tels que Http, RMI, SOAP, SMTP, POP3, etc. Ensuite, il s'avère possible de recourir à un autre MOM

Dans le document Audit du Système d Information de la Chaîne des Dépenses Publiques (Page 111-128)