Brevet FR2846498A1 — publié le 20040430

La présente invention se rapporte à un procédé de communication entre serveurs ainsi qu'à un dispositif pour sa mise en oeuvre. Dans les systèmes informatiques dits distribués, tels que notamment les 5 systèmes informatiques financiers utilisés par les banques ou encore par les compagnies d'assurance, il existe différents serveurs de natures distinctes destinés à communiquer les uns avec les autres pour gérer et traiter des flux de transactions et d'informations. Un serveur s'entend ici comme la combinaison de matériels informatiques (hardware) et de logiciels 10 appropriés (software). Ainsi, un système informatique financier comporte différents serveurs dits clients (ou encore de front office selon la terminologie anglo- saxonne) interconnectés à différents serveurs dits d'application (ou de back office). Les serveurs d'application sont plus particulièrement destinés à gérer des bases de données et à réaliser des traitements spécifiques encore appelés services. Le terme service est ici défini de façon générale comme tout traitement informatique, ce terme recouvre aussi bien la mise à disposition 20 d'une information particulière comme un numéro de compte, que le calcul d'un solde ou encore un virement. Le système informatique d'une banque comporte généralement un serveur d'application bancaire (exemple: moteur financier commercialisé par la 25 société SAB) qui traite toutes les opérations liées à la gestion de comptes de dépôts, un serveur de crédit qui gère les prêts accordés par la banque à sa clientèle, un serveur boursier de gestion des valeurs mobilières (moteur boursier Investiciel commercialisé par la société SEMA) , un serveur d'assurance, etc. Les serveurs client sont eux destinés à permettre aux employés et aux usagers de la banque d'accéder aux différents serveurs d'application depuis des interfaces et des réseaux de communication spécifiques, encore appelés canaux, pour fournir (opérations de mise à jour, etc.) ou récupérer 5 (opérations d'interrogation, etc.) des données à travers des requêtes appelées appels de services. En effet, chaque requête reçue par un serveur d'application génère l'exécution d'un service correspondant par ce dernier. Comme serveurs client utilisés par le système informatique d'une banque, 10 on peut citer un serveur gérant les ordinateurs équipant les guichets des banques, un serveur GAB/DAB associés aux guichets/distributeurs automatisés, un serveur vocal qui permet aux usagers d'accéder aux serveurs d'application au moyen d'un téléphone, un serveur Web pour accéder à ces serveurs via l'lnternet, un serveur Minitel, un serveur WAP, 15 les serveurs des partenaires de l'organisme financier, etc. Une telle architecture est indispensable pour permettre d'obtenir par simple appel d'un téléphone numérique interrogeant une institution financière telle qu'une banque, le solde d'un compte courant ou bien encore pour imputer 20 d'un compte courant la somme prélevée lors d'un retrait à un distributeur de billets de banque et fournir à son titulaire l'information quant au nouveau solde après cette opération. Historiquement, chacun des serveurs client était directement connecté, au 25 fur et à mesure de sa création, à chacun des serveurs d'application qui le concerne par des liaisons dédiées de type point-à-point. La multiplication des serveurs d'application et des serveurs client liés à l'apparition de nouveau canaux comme l'lnternet, la téléphonie mobile, mais 30 également au développement de nouvelles prestations financières comme l'assurance, rend une telle architecture point à point extrêmement difficile à développer, à gérer, maintenir et sécuriser. Ainsi, la mise en place d'un serveur Web suppose l'écriture complète par les 5 équipes informatiques ayant la charge de développer le système informatique, de l'interface et des travaux d'intégration avec chacun des serveurs d'application auxquels il est connecté et ce, sans pouvoir réutiliser les développements déjà réalisés par exemple pour le serveur Minitel. Depuis quelques années, l'architecture point à point tend à être remplacé par une architecture de type " hub ". La connexion entre les serveurs client et les serveurs d'application se trouve être alors réalisée par l'intermédiaire d'un serveur particulier dit serveur MCMA pour serveur multi-canal et multiapplication (appelé encore middleware dans la terminologie anglo-saxonne) 15 auxquels sont connectés tous les serveurs client et tous les serveurs d'application. Un tel serveur MCMA assure le routage des données entre les serveurs mais également est à même de réaliser un certain nombre de fonctionnalités 20 supplémentaires. Le serveur MCMA fait donc office d'unique serveur d'application pour les serveurs client et d'unique serveur client pour les serveurs d'application. Grâce à cette architecture, le développement d'un nouveau serveur client ne 25 nécessite qu'un seul travail de connexion au serveur MCMA. Le serveur MCMA est alors apte à fournir à ce nouveau serveur client l'ensemble des services disponibles sur les serveurs d'application, selon un procédé de communication choisi. Il en est bien évidemment de même, lorsqu'il s'agit d'ajouter un nouveau serveur d'application. 30 Le document WO-A-98/24040 décrit un tel serveur. Une telle solution permet d'accéder à chaque serveur d'application de manière indépendante des connexions reliant le serveur MCMA aux serveurs client. Toutefois, le procédé de communication proposé entre les serveurs client et les serveurs d'application via le serveur MCMA n'est pas totalement satisfaisant dans la mesure o il est de mise en oeuvre relativement 10 complexe, notamment en ce qui concerne: - la mise en commun de fonctionnalités mises en oeuvre par le serveur MCMA pour le compte des serveurs client. - l'intégration d'un serveur client ayant des contraintes technologiques spécifiques; - les modifications régulières dans les serveurs d'application (évolutions, remplacement, dédoublement, etc.); Par ailleurs le système proposé dans l'art antérieur ne traite pas de l'importlexport de données vers ou provenant des serveurs d'application, 20 dans le cadre d'un projet de migration de données issues d'autres systèmes informatiques par exemple. Traditionnellement, lorsque qu'une migration de données entre deux systèmes informatiques doit se faire (par exemple la migration des clients 25 d'une banque rachetée dans le système informatique de la banque acheteuse). Le procédé de migration consiste à extraire du système informatique source les données sous forme de fichier puis à insérer ses données directement dans les bases de données des différents serveurs d'applications hébergeant des données clients (portefeuille boursier des 30 clients, soldes de comptes etc.). Les programmes d'extraction sont faits de façon spécifique en fonction des possibilités offertes par le système source, ils produisent généralement des fichiers d'extraction textes " à plat " image des tables des bases de données du système de la banque achetée. Les programmes d'extraction sont également faits de façon spécifique pour répartir les données des fichiers d'extraction dans les tables correspondantes des différents serveurs d'applications hébergeant des données clients (portefeuille boursier des clients, soldes de comptes etc. ). Ces travaux de migration se font souvent également dans le cadre de la centralisation au niveau national, des systèmes informatiques (souvent différents) de chaque filiale régionale ou lors de la mise en place de flux de données périodiques avec le système informatique d'une société partenaire 15 (B2B, ex: rachat du fichier client d'une société de vente par correspondance). A chaque migration, les programmes de création des fichiers d'extraction sont à faire, mais la diversité des données à migrer oblige le plus souvent à réécrire les programmes d'insertion des données. La présente invention vise donc à remédier à tous ces inconvénients. Elle porte sur un procédé de communication entre serveurs et sur le système de mise en oeuvre correspondant. La présente invention concerne un procédé permettant de faire communiquer une pluralité de serveurs client possédant chacun des moyens logiciels et matériels spécifiques avec une pluralité de serveurs d'application possédant chacun des moyens logiciels et matériels spécifiques et comprenant chacun au moins une application choisie. 30 Selon ce procédé, les serveurs client sont directement connectés à un unique serveur MCMA lequel est à son tour directement connecté à l'ensemble des serveurs d'application, de sorte que tout appel de service d'un serveur client à destination d'un serveur d'application donné, est 5 d'abord adressé par ledit serveur client au serveur MCMA à charge de ce dernier de le router au serveur d'application concerné et de faire remonter en retour d'éventuelles informations du serveur d'application vers le serveur client. Selon une définition générale de l'invention, le procédé de communication consiste à présenter chaque appel de service sous la forme d'une action qui est une classe en langage de programmation orientée objet, possédant des attributs/champs d'entrée représentant les paramètres de l'appel de service et d'éventuels attributs/champs de sortie représentant le résultat du service 15 destiné à être retourné au dit serveur client et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'application cibles et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA. Le serveur MCMA dès réception de l'action exécute cette dernière en mode 20 synchrone ou asynchrone en déroulant la méthode associée à cette action pour opérer d'éventuels traitements sur les attributs/champs d'entrée et/ou envoyer au(x) serveur(s) d'application cible(s) concerné(s) l'appel de service dans le format et protocole spécifique attendu par ledit ou lesdits serveurs d'application. Chaque serveur d'application appelé opère son traitement et fournit le service attendu, dans son format spécifique, au serveur MCMA, lequel opère alors d'éventuels traitements sur les données ainsi retournées par le ou les serveurs d'application et valorise les attributs de sortie de l'action qui est 30 ensuite remontée au serveur client émetteur. Plusieurs serveurs d'application peuvent être sollicités lors de l'exécution d'une même action. Dans ce cas, les différents serveurs d'application peuvent être appelés successivement ou simultanément en fonction du service fournis. L'utilisation d'action pour communiquer entre les serveurs clients et le serveur MCMA, a l'avantage, dans un contexte de programmation orientée objet, d'être de mise en oeuvre simple et facile o l'on souhaite: bénéficier, grâce à l'héritage entre les classes, d'une mise en 10 commun de fonctionnalités présentes de façon récurrente dans les appels de services et qui peuvent ainsi être mises en couvre de façon simple directement par le serveur MCMA, comme par exemple: l'identification de l'usager, le contrôle d'habilitation, l'audit des appels de service ou encore leur tarification; - uniformiser le procédé de communication avec les serveurs clients; - les modifications régulières dans les serveurs d'applications (remplacement, dédoublement, évolutions). Selon un mode de réalisation particulier de l'invention, chaque action est 20 transférable du serveur client vers le serveur MCMA ou du serveur MCMA vers le serveur client sous la forme de fichiers texte écrits en langage de balisage extensible du type XML ou analogue. D'autres caractéristiques et avantages de l'invention apparaîtront à la 25 lumière de la description détaillée ci-après et des dessins dans lesquels: - la figure 1 est une représentation schématique d'un système informatique mettant en couvre le procédé de communication entre serveurs client et serveurs d'application selon l'invention; - la figure 2 illustre le procédé de communication selon l'invention; et - la figure 3 est un schéma précisant la structure du serveur MCMA mis en oeuvre dans le système informatique de la figure 1. En référence à la figure 1, le système informatique décrit est un système 5 informatique d'une institution financière telle qu'une banque. Ce système informatique référencé 1 fournit une pluralité de services financiers gérés par des serveurs d'application spécialisés et accessibles par les employés ou les usagers à travers une pluralité d'interfaces clients 2. Par exemple, les interfaces clients 2 appartiennent au groupe formé par des téléphones numériques fixes 2a ou mobiles 2b, des guichets automatiques GAB (non représentés), des succursales recevant du courrier 2c ou des télécopies 2d, des bureaux de vente de succursale (non représentés), des distributeurs de billets en libre-service DAB (non représentés), des 15 ordinateurs personnels pour banque à domicile utilisant une connexion de type Internet 2f ou minitel 2g, des télévisions interactives 2e, etc. Ces interfaces clients 2 sont connectées par des réseaux appropriés 3, individualisé en 3-1 à 3-6, à des serveurs client 4, individualisés en 4-1 à 420 6. Les serveurs 4 sont développés de façon spécifique en fonction des possibilités techniques de chaque interface 2 et de chaque réseau 3. Chaque interface et son réseau associé sont encore appelés canal. Le système informatique 1 comprend en outre une pluralité de serveurs 25 d'application 5 comprenant chacun au moins une application choisie 6, individualisée en 6a à 6e. Par exemple, les serveurs sont du type serveur bancaire 5a, serveur boursier 5b, assurance 5c, crédit 5d, ou autre 5e. Par ailleurs, un serveur 7 est intercalé entre les serveurs client 4 et les 30 serveurs d'application 5. Ce serveur de type MCMA (multi-canal et multi- application) est directement commun à l'ensemble des serveurs client 4 et est apte à leur fournir l'ensemble des services disponibles 6 sur les serveurs d'application 5 auxquels il est également connecté, selon un procédé de communication choisi. Il est à noter que de préférence, le serveur MCMA 7 ne sert pas uniquement à router des données des serveurs client vers les serveurs d'application et vice-versa mais également sert à opérer différents traitements, comme par exemple l'identification/authentification de l'utilisateur final et/ou du serveur 10 d'application, la gestion de mode dégradé (par exemple gestion de bases répliquées permettant de fournir des informations malgré l'indisponibilité des serveurs d'application concernés), le contrôle d'habilitation, l'audit des appels de service ou encore leur tarification,... Chaque serveur client adapte l'appel émis par son canal correspondant, comme par exemple le serveur client WAP à partir d'un message émis par un téléphone mobile, sous une forme prédéterminée et l'envoi au serveur MCMA 7 selon un format et protocole attendu par le serveur MCMA 7. Le serveur MCMA propose plusieurs formats et protocoles afin de s'adapter aux contraintes technologiques d'un serveur client 4 et d'un canal 3 quelconque. Les formats proposés par le serveur MCMA 7 peuvent être fichier texte ou binaire " à plat ", fichier XML, sérialisation d'objet (java, C++, Visual Basic, etc.). Les protocoles proposés par le serveur MCMA 7 peuvent 25 être IP, HTTP, CORBA/IIOP, JRMP, DCOM, COM, COM+, etc. Selon l'invention, le procédé de communication entre les serveurs client 4 et les serveurs d'applications 5 du système informatique distribué 1 est articulé autour de la notion d'action. Ce procédé consiste plus particulièrement à 30 présenter chaque appel de service sous la forme d'une action. Une action est une classe en langage de programmation orientée objet (Java, C++, etc.), possédant des attributs/champs d'entrée représentant les paramètres de l'appel de service et d'éventuels attributs/champs de sortie représentant le résultat du service destiné à être retourné audit serveur 5 client et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'application cibles et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA. Ainsi, selon l'invention, à chaque service correspond une action qui 10 encapsule l'appel à destination du ou des serveurs d'application cibles via le serveur MCMA 7 ou encore des traitements mis en oeuvre directement par le serveur MCMA. Le serveur d'application 5 logeant le service cible 6 reçoit l'appel du service 15 cible, émis par le serveur MCMA, selon les formats et protocoles spécifiques du serveur d'application 5 et renvoie la réponse (résultat de service ou erreur) au serveur MCMA toujours selon ses formats et protocoles spécifiques du serveur d'application 5. En référence à la figure 2, le procédé de communication comprend les étapes suivantes: - étape (i), instanciation Il s'agit de créer, par exemple par le serveur minitel 4-6, une instance de 25 classe (selon la terminologie de la programmation orientée objet) de type action qui correspond au service " solde du compte courant N " suite à une demande d'appel (request) émanant d'une interface cliente 2g, en l'occurrence d'un minitel utilisé par un usager lequel souhaite connaître le solde de son compte courant; il - étape (ii), le serveur minitel 4-6 valorise les attributs d'entrée de l'action en fonction des données fournies par l'usager et envoi l'action au serveur MCMA selon le protocole et le format de son choix parmi ceux proposés par ce dernier (" uneAction " est une instance (un objet, une variable) de la 5 classe (du type) " FxAction " (une FxAction est le nom technique qui désigne action générique); - étape (iii), le serveur MCMA 7 reçoit l'action et l'exécute en déroulant la méthode associée. Cette méthode associée a un comportement qui varie en 10 fonction des valeurs de tout ou partie des attributs d'entrées. C'est entre autre ici que peuvent être fournies des fonctionnalités supplémentaires tels que l'identification de l'usager, le contrôle d'habilitation, l'audit des appels de service, etc.; - étape (iv), la couche d'intégration que l'on décrira plus en détail ci après du serveur MCMA 7 est sollicitée par l'action "solde compte courant" pour qu'elle effectue l'appel de service cible correspondant sur le serveur d'application concerné (ici le serveur bancaire 5a) selon les formats et protocoles de communication spécifiques de ce dernier. 20 (entryPoint. invoke(uneAction) est une instruction en langage objet, en l'occurrence c'est l'instruction qui provoque le déroulement de la méthode associée à l'action quelconque " uneAction " dans le serveur MCMA); - étape (v), le serveur d'application exécute le service demandé décrit par 25 l'appel à savoir la lecture ou le calcul du solde du compte et retourne le résultat correspondant au serveur MCMA 7 selon les format et protocole de communication spécifiques du serveur d'application; - étape (vi), la couche d'intégration du serveur MCMA 7 restitue les données 30 résultats fournis par le serveur d'application à la méthode associée à l'action. Celle-ci valorise donc les attributs résultats de l'action, en fonction des données reçues par le serveur d'application 5a. C'est entre autre ici que peuvent être fournies des fonctionnalités supplémentaires tels que l'audit des réponses de service, la tarification, le mode dégradé (ex: en cas 5 d'erreur, lire le solde en base de données répliquées quotidiennement), etc.; - étape (vii), Lorsque la méthode associée à l'action est terminée, le serveur MCMA retourne l'action vers le minitel 2g via le serveur minitel 4-6; - étape (viii), le minitel reçoit et affiche le résultat En se reportant à la figure 3, la structure du serveur MCMA 7 va être plus particulièrement détaillée. De façon préférentielle, l'architecture logicielle du serveur MCMA 7 est notamment constituée de deux couches logicielles distinctes: la couche usage 10 et la couche intégration 12. Selon une définition de l'invention, la couche d'usage 10 est une couche 20 intermédiaire qui complète, simplifie et facilite l'utilisation des services fournis par les serveurs d'applications 5. C'est la couche d'usage 10 qui est utilisée comme interface pour accéder à la couche d'intégration 12 depuis les serveurs client 4. La couche d'usage 10 est constituée notamment de l'ensemble des actions disponibles depuis le serveur MCMA (voir description ci-avant) et de classes de type " objet d'usage ". Un objet d'usage peut être considéré comme une vue d'une ou plusieurs 30 structures de données utilisées par les serveurs d'application 5. Cette vue est une représentation commune à toutes les structures de données équivalentes dans les serveurs d'applications concernées. Par exemple, l'objet d'usage " UsageCompte " pourra être utilisé pour représenter un compte de dépôt d'un serveur bancaire 5a, ou encore un compte titres du serveur bourse 5b. Le mécanisme d'héritage apporté par le concept de classe (programmation orientée objet) permet encore de renforcer la mise en commun des informations. Par exemple, les comptes de dépôt pourront être représentés 10 par des objets d'usage " UsageCompteDepôt " qui héritent des attributs (données membres) de l'objet d'usage " UsageCompte " et qui ne possèdent que les attributs supplémentaires spécifiques à un compte de dépôts par rapport à un compte abstrait et générique " UsageCompte ". Ce dernier pourra également être hérité par plusieurs autre type d'objet d'usage 15 (dit " fils ") tels que " UsageCompteEpargne ", " UsageCompteTitres ", etc. Ainsi une action représentant le service " liste des comptes d'un client " pourra fournir la liste de tous les types de comptes hébergés par tous les serveurs d'applications gérant des comptes. Une telle action possède un attribut de sortie de type " tableau de UsageCompte " qui contiendra, par 20 exemple en résultat pour un client, par polymorphisme (concept de la programmation orienté objet): un compte de dépôt, un compte d'épargne et un compte titres, chacun géré par des serveurs d'applications différents. Ainsi l'ensemble des objets d'usage facilite et simplifie la représentation des 25 structures de données qui sont par définition variables selon le serveur d'application. Les objets d'usage permettent la mutualisation des formats d'échanges entre les serveurs clients et le serveur MCMA quel que soit le serveur d'application concerné. La couche d'usage 10 permet également de stabiliser les formats fournis aux serveurs client en cas de modification dans un serveur d'application 5, ou le remplacement de l'un d'eux par un nouveau serveur d'application. Par exemple, si l'on considère que le serveur bancaire 5a possède une structure 5 de donnée " solde de compte " qui agrège les soldes comptables, valeur et espèce d'un compte, et ces différents soldes sont donc représentés dans la classe " UsageSolde " afin d'être disponibles aux serveurs clients. Le remplacement du serveur bancaire 5a par un nouveau serveur d'application qui ne possède pas de solde espèce, n'entraînera pas de modification de 10 l'objet d'usage " UsageSolde " et donc ne nécessitera pas la modification des serveurs clients. L'information manquante sera soit renseignée à une valeur par défaut, soit calculée par le serveur MCMA. Il est à noter que si le nouveau serveur d'application bancaire possède de 15 nouvelles informations concernant le solde (ex: solde fin de mois précédent), on pourra enrichir l'objet d'usage " UsageSolde " d'un nouvel attribut. La couche d'usage 10, par ces apports en simplification et stabilisation des 20 formats d'échanges avec les serveurs client, facilite ainsi la prise en charge de modifications régulières dans les serveurs d'applications (remplacement, dédoublement, évolutions). Les informations contenues par les classes de données d'usage proviennent 25 des serveurs d'application 5. Par exemple, la donnée solde comptable de l'objet d'usage compte provient du serveur bancaire 5a. Pour valoriser leurs attributs de sortie, les actions de la couche d'usage appellent la couche d'intégration 12 (et la couche de services supplémentaires 11 pour les fonctionnalités du serveur MCMA qui ne sont pas disponibles dans les 30 serveurs d'applications). Ainsi, ce n'est pas la couche d'usage 10 qui est en charge de la communication avec les serveurs d'applications 5 mais la couche d'intégration 12. La couche d'intégration 12 est compartimentée en modules, un module de routage 13 et un module d'intégration 14 pour chaque serveur d'application 5. Le module de routage 13 est le point d'entrée des actions de la couche 10 d'usage 10. Il est chargé de déterminer en fonction des données représentées par un objet d'usage (ex: type de compte, n0 du compte, n0 du client) le ou les serveurs d'applications concernés et donc le ou les module d'intégrations 14 à qui déléguer la communication. Pour chaque module d'intégration 14 concerné, le module de routage 13 fourni l'objet d'usage et 15 le service à appeler dans le serveur d'application. Chaque module d'intégration 14 est chargé de la communication avec un moteur d'application spécifique selon les formats et protocoles attendus par ce serveur d'application. Il est également capable de convertir des structures 20 de données spécifiques provenant du serveur d'application en objet d'usage et inversement. Le travail effectué par chaque composant du serveur MCMA 7 va être illustré dans l'exemple suivant: consultation du compte X d'un client Y sur le 25 serveur d'application 5a. L'action " liste des soldes de tous les comptes d'un client " va d'abord rechercher, via un service dit de " CRM " ( acronyme de Customer Relation Management, c'est-à-dire Gestion de la Relation Client) de la couche de 30 service supplémentaire 11, la liste des numéros de comptes détenus dans la dans la base de données 15. Puis pour chaque numéro de compte, va demander à la couche d'intégration 12 le solde correspondant en lui fournissant un objet d'usage " UsageSolde " avec des soldes non renseignés. Le module de routage 13 va, en fonction du numéro de compte 5 et du type de compte, déterminer le module d'intégration 14 concerné et lui demander de faire l'appel du service cible adéquat en lui fournissant l'objet d'usage vide. Le module d'intégration 14 va appeler le service cible via les formats et protocoles attendus par le serveur d'application concerné, remplir l'objet d'usage avec les résultats fournis par le serveur d'application et 10 retourner l'objet d'usage ainsi renseigné au module du routage 13 qui le lui retournera à l'action demanderesse. Pour transmettre les actions formant appel de service entre les différents serveurs du système informatique 1, on utilise des fichiers écrits de 15 préférence avec un langage de structuration encore appelé langage de balisage extensible, tel que le XML (acronyme anglo-saxon pour extensible Markup Language). Un document structuré est une collection d'ensembles d'informations 20 associés chacun à un type et des attributs, et composés entre eux selon des relations principalement hiérarchiques. Un tel document permet notamment de distinguer les différents sous-ensembles d'informations composant le document. Par opposition, dans un document dit linéaire, les informations de contenu du document sont mélangées aux informations de présentation et 25 de typage. Un document structuré inclut des repères de séparation des différents ensembles d'informations du document. Dans le cas du format XML, ces repères appelées " balises " sont de la forme " " (balise ouvrante) et " " (balise fermante), le premier repère indiquant le début d'un ensemble d'informations nommé " b " et le second la fin de cet ensemble. Contrairement au langage HTML (HyperText Markup Language), le langage 5 XML n'est pas sémantiquement figé. Il permet de définir ses propres balises, ce qui le rend adaptable et donc à même de stocker tout types d'informations. Un document structuré est associé à ce que l'on appelle un schéma de 10 structure ou DTD (Document Type Definition) définissant sous la forme de règles la structure et le type d'information de chaque ensemble d'informations du document. Un schéma est constitué de groupes imbriqués de structures d'ensembles d'informations, ces groupes pouvant être des séquences ordonnées, des groupes d'éléments alternatifs ou des groupes 15 d'éléments nécessaires, ordonnés ou non ordonnés. Les documents XML reçus par les serveurs du système informatique 1 sont traités par une interface de programmation d'application correspondante (API, Application Programming Interface) écrite en langage orienté objet et 20 servant d'analyseur XML (ou XML parser) pour analyser et décoder les balises de ces documents. Ainsi, à chaque action (représentant un service d'usage et les données d'usage utilisées le cas échéant) est associée une description écrite en 25 langage XML. Un tel langage de balisage permet de fournir des formats de données sans se restreindre à une plate-forme technique quelle soit matérielle ou logicielle. De plus, la représentation sous forme de texte écrit en langage XML de chaque action permet de créer simplement, via un simple éditeur de texte, un fichier XML décrivant une ou plusieurs actions d'appel de services. Le résultat de ses actions, également écrit en XML sera également facile à interpréter depuis un simple éditeur de texte. Il est intéressant de s'appuyer sur un langage de balisage extensible du type XML dans le cadre de fonctions d'import/export de données en association 10 avec les demandes d'appel (respectivement attributs d'entrée et attributs de sortie). La mise en oeuvre d'un tel langage de type XML se fait donc en associant une balise XML à chaque action, ces balises contenant elles même une 15 balise pour chaque attribut d'entrée et pour chaque attribut de sortie des actions. Très avantageusement, les attributs d'entrée des actions qui correspondent à des traitements d'écriture, création ou modification de données, sont 20 transférés (injectées/importées) dans les serveurs d'application via le serveur MCMA sous la forme d'un fichier texte écrit en langage de balisage extensible du type XML ou analogue. Ainsi les migrations de données vers un système informatique utilisant un 25 procédé de communication par action et par XML nécessiterons seulement la réécriture de programme d'extraction des données du système source sous forme de fichier d'extraction XML correspondant à des actions du serveur MCMA. De plus, toute création de nouvelle action qui correspond à un traitement d'écriture sera une solution d'importation de données supplémentaire dans le cadre d'une prochaine migration. Par exemple la création d'une nouvelle action, suite à un nouveau besoin d'un serveur client WEB, destiné à la 5 création d'adresse, facilitera les futures importations des adresses email d'un système informatique source ou permettra de compléter le flux de données provenant d'une société partenaire fournissant des données de personnes à prospecter. De même, les attributs de sortie des actions qui correspondent à des traitements de lecture, recherche ou consultation de données sont transférés (extraites/exportées) des serveurs d'application correspondants via le serveur MCMA sous la forme d'un fichier texte écrit en langage de balisage extensible du type XML ou analogue. Les avantages fournis par les actions descriptibles en XML sont donc également valables dans le cadre d'export de données, lors du rachat de la banque ou de la mise en place de flux de données périodiques avec le système informatique d'une société partenaire (B2B). Lorsque que l'action courante (demande d'appel contenant des nouvelles données à écrire dans le service cible demandé) correspond à un service d'écriture dans le système (création, modification, etc.), l'opération est alors dite " import multi-moteur ", car les données dans le fichier XML fournies en 25 entrée sont injectées dans le système via le serveur intermédiaire MCMA 7. Inversement, lorsque que l'action utilisée correspond à un service de lecture dans le système (recherche, consultation, etc.), l'opération est alors dite " export multi-moteur ", car le fichier XML résultat contient une extraction 30 des données du système via le serveur intermédiaire MCMA 7. Un tel importlexport de données en XML a l'avantage de simplifier le traitement des actions dans un environnement informatique à plusieurs serveurs client et plusieurs serveurs de services, via un serveur MCMA 7. Pour illustrer cet aspect de l'invention, considérons l'exemple suivant d'action écrite en langage XML. Message décrivant l'appel de l'action 10 5010328 sYO3u FALSE 15 Ce message XML d'appel contient une seule action, il pourrait cependant en 20 contenir plusieurs en une seule fois (utile dans le cas de migration par exemple). L'action appelée est " Action_ListeSoldesTousComptes " pour le client numéro " 5010328 " qui s'est identifié (présence du code confidentiel crypté). La fonction d'identification n'est pas fournie par l'action " Action_ListeSoldesTousComptes ", mais par l'action " ActionIdentificationClient " dont elle hérite. L'action possède également une option " lire détail du contrat correspondant aux compte demandés " qui n'est pas ici demandée. Message décrivant le résultat de l'action: 5010328 sYO3u M Jean-Paul Carmona FALS E 0. 00 2 10 0 2 01 501032801 01501032801 0.00 0.00 0.00 0.00 0. 00 0.00 19-Aug2002 13:00:00 2 0 0 0.00 30 0.00 0.00 0.00 0. 00 0. 00 35 0. 00 0. 00 0. 00 O.00 O.00 O.0O 5 O.00 O. 00 Ci-dessus le message XML de réponse contient l'action demandée 15 précédemment avec les attributs résultats renseigné. Ici l'attribut de sortie ne donne pour résultat qu'un seul objet d'usage " UsageSolde " (car le client concerné ne possède qu'un seul compte). Les attributs dans l'objet " UsageSolde " représentent des soldes 20 concernant des comptes de dépôt (solde comptable, valeur, etc.) ou titres (portefeuille Investi, plus value latente, etc.) sont tous vides car le compte ne possède pas d'argent. Des informations concernant le compte concerné sont fournies (type, numéro). Les attributs résultat utilisés dans le cadre du mode dégradé (balises " banqueKO ", " titresKO ") sont vides, indiquant que les serveurs d'applications concernés (potentiellement de type banque ou titres) sont opérationnels (sinon, un message d'erreur aurais été renseigné ici, I'action pouvant dans ce cas, en fonction du type de compte, effectuer la recherche 30 de solde dans une base de données de secours via la couche de service supplémentaires 11 du serveur MCMA). Une balise " messageAnomalie " est également présente au niveau de l'objet " UsageSolde " pour décrire le cas échant le problème spécifique à un compte. L'attribut de sortie " cumulValorisation " représente le cumul des soldes (comptables pour les comptes de dépôt ou d'épargne et valorisation titres pour les comptes titres) de tous les comptes du client. C'est une fonctionnalité supplémentaires fournie par l'action car chaque serveur d'application ne connaît pas les positions des comptes gérés par les autres 10 serveurs. Bien évidemment, les modes de réalisation illustrés n'ont été donnés qu'à titre d'exemples et ne sont absolument pas limitatifs de l'ensemble des solutions pouvant être mises en oeuvre grâce à la présente invention. REVENDICATIONS 1. Procédé permettant de faire communiquer à l'intérieur d'un système 5 informatique (1) de type distribué, une pluralité de serveurs client (4) possédant chacun des moyens logiciels et matériels spécifiques avec une pluralité de serveurs d'applications (5) possédant chacun des moyens logiciels et matériels spécifiques et comprenant chacun au moins une application choisie (6), les serveurs clients (4) étant directement connectés à 10 un unique serveur MCMA (7) lequel est à son tour directement connecté à l'ensemble des serveurs d'applications (5), de sorte que tout appel de service d'un serveur client à destination d'un serveur d'application donné, est d'abord adressé par ledit serveur client au serveur MCMA (7) à charge de ce dernier de le router au serveur d'application (5) concerné et de faire 15 remonter en retour d'éventuelles informations du serveur d'application (5) vers le serveur client (4), caractérisé en ce que lesdits serveurs clients (4) présentent les appels de service sous la forme d'actions, ces actions étant des classes en langage de programmation orientée objet qui possèdent une structure de données et une méthode apte à encapsuler l'appel à destination 20 d'un ou plusieurs serveurs d'applications cibles (5) et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA (7). 2. Procédé selon la revendication 1, caractérisé en ce que lesdits serveurs d'applications (5) utilisent une couche logicielle d'intégration et que les 25 serveurs clients (4) utilisent une couche logicielle d'usage (10) déduite de ladite couche d'intégration (12) et en ce que la structure de données d'une action formant appel de service coopère avec ladite couche d'usage (10). 3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que l'action formant appel comprend un identifiant correspondant à l'identifiant du service d'application cible (5), des attributs d'entrée représentant les paramètres de l'appel de service et d'éventuels attributs de 5 sortie représentant le résultat du service destiné à être retourné audit serveur client (4). 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque action formant appel de service est transférée 10 entre serveurs (4 et 5) sous la forme d'un document textuel structuré écrit en langage de balisage extensible du type XML ou analogue. 5. Procédé selon la revendication 3 et la revendication 4, caractérisé en ce que les attributs d'entrée correspondant à un service écriture du type 15 création ou modification sont importés dans les serveurs d'applications correspondants (5) au format d'un fichier XML et ce, via le serveur MCMA (7). 6. Procédé selon la revendication 3 et la revendication 4, caractérisé en ce 20 que les attributs de sortie correspondant à un service lecture du type recherche ou consultation sont exportés des serveurs d'applications correspondants (5) au format d'un fichier XML et ce, via le serveur MCMA (7). 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le système informatique (1) est du type à offrir des services financiers. 8. Procédé selon la revendication 7, caractérisé en ce que les serveurs clients (4) coopèrent avec des interfaces clientes (2) constituées notamment par des téléphones numériques, des guichets automatiques, des succursales, des bureaux de vente de succursale, des terminaux de vente 5 en libre-service, des ordinateurs personnels pour banque à domicile, des télévisions interactives. 9. Procédé selon la revendication 7, caractérisé en ce que les serveurs d'applications (5) appartiennent au groupe formé par des gestionnaires de 10 bases de données clients, des centres téléphoniques financiers, des bases de données financières externes, des applications de type crédit, dépôtépargne, titres, assurance, et finance. 10.Dispositif de communication pour la mise en òuvre du procédé selon 15 l'une quelconque des revendications 1 à 9, et apte à faire communiquer à l'intérieur d'un système informatique (1) de type distribué, une pluralité de serveurs client (4) possédant chacun des moyens logiciels et matériels spécifiques avec une pluralité de serveurs d'application (5) possédant chacun des moyens logiciels et matériels spécifiques et comprenant chacun 20 au moins une application choisie (6), les serveurs client (4) étant directement connectés à un unique serveur MCMA (7) lequel est à son tour directement connecté à l'ensemble des serveurs d'application (5), de sorte que tout appel de service d'un serveur client à destination d'un serveur d'application donné, est d'abord adressé par ledit serveur client au serveur MCMA (7) à 25 charge de ce dernier de le router au serveur d'application concerné et de faire remonter en retour d'éventuelles informations du serveur d'application (5) vers le serveur client (4), caractérisé en ce que lesdits serveurs client (4) sont aptes à présenter les appels de service sous la forme d'action, ces actions étant des classes en langage de programmation orientée objet qui 30 possèdent une structure de données et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'application cibles (5) et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA (7).