FR2848759A1 - Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre - Google Patents

Abstract

Procédé et dispositif de communication entre une pluralité de serveurs client (4) et une pluralité de serveurs d'applications (5), les serveurs clients (4) étant connectés à un unique serveur MCMA (7) lequel est à son tour 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 remonter en retour d'éventuelles informations du serveur d'application (5) vers le serveur client (4), caractérise en ce qu'il comprend au moins une chaîne de conversion entrante et/ou sortante apte à convertir les appels écrits en langage et format du serveur MCMA en langage et format attendus par le serveur client (4) et/ou le serveur d'application (5) et à convertir les réponses du serveur client (4) et/ou du serveur d'application (5) écrites en langage et format du serveur client et/ou serveur d'application en réponse écrites en langage et format du serveur MCMA.

Description

PROCEDE DE COMMUNICATION ENTRE SERVEURS AVEC CONVERSION DE FORMAT DES

DONNEES ET DISPOSITIF POUR

SA MISE EN OEUVRE

La présente invention se rapporte à la communication entre serveurs à l'intérieur d'un système informatique dit distribué, tel que notamment un système informatique financier utilisé 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 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 25 mise à disposition 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 30 commercialisé par la 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 clients 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 10 à jour, etc.) ou récupérer (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 clients utilisés par le système informatique d'une banque, 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 20 téléphone, un serveur Web pour accéder à ces serveurs via l'Internet, un serveur Minitel, un serveur WAP, les serveurs des partenaires de l'organisme financier, etc. Une telle architecture est indispensable pour permettre d'obtenir par 25 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 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. 30 Depuis quelques années, la connexion entre les serveurs clients et les serveurs d'applications se trouve être réalisée par l'intermédiaire d'un serveur particulier dit serveur MCMA pour serveur multi-canal et multi- application (appelé encore middleware dans la terminologie 5 anglo- saxonne) auxquels sont connectés tous les serveurs client et tous les serveurs d'applications.

Un tel serveur MCMA assure le routage des données entre les serveurs mais également est à même de réaliser un certain nombre 10 de fonctionnalités supplémentaires. Le serveur MCMA fait donc office d'unique serveur d'application pour les serveurs clients et d'unique serveur client pour les serveurs d'applications.

Grâce à cette architecture, le développement d'un nouveau serveur 15 client ne 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'applications, selon un procédé de communication choisi. Il en est bien évidemment de même, lorsqu'il s'agit d'ajouter un nouveau 20 serveur d'application.

Le document WO-A-98/24040 décrit un tel serveur.

Une telle solution permet d'accéder à chaque serveur d'application de 25 manière indépendante des connexions reliant le serveur MCMA aux serveurs client.

Toutefois, le procédé de communication proposé dans l'art antérieur entre les serveurs clients et les serveurs d'applications via le serveur 30 MCMA n'est pas totalement satisfaisant dans la mesure o il est de mise en oeuvre relativement complexe ou inadaptée, notamment en ce qui concerne: la mise en commun de fonctionnalités mises en oeuvre par le serveur MCMA pour le compte des serveurs clients; - l'import/export de données vers ou provenant des serveurs d'applications, dans le cadre d'un projet de migration de données issues d'autres systèmes informatiques par exemple; les modifications régulières dans les serveurs d'application (évolutions, remplacement, dédoublement, etc.). 10 Par ailleurs, le système proposé dans l'art antérieur ne traite pas de l'intégration d'un serveur client et/ou d'un serveur d'application ayant une technologie différente de celle du serveur MCMA, notamment en ce qui concerne le langage, le format ou encore le 15 protocole de communication qui sont généralement différents du format du serveur MCMA.

Traditionnellement, lorsque qu'une adaptation d'une l'interface cliente doit être réalisée au format, au langage et au protocole 20 attendus par le serveur MCMA, l'équipe informatique chargée de cette adaptation développe des programmes dits intermédiaires ou " middleware " dédiés à cette adaptation.

Or, l'équipe informatique chargée de l'interface cliente peut être 25 différente de celle en charge du serveur MCMA. Il en est de même du serveur d'application dont le développement peut être spécifique.

Il en résulte des temps de développement des programmes intermédiaires relativement longs et coteux. De plus, la 30 maintenance du système résultant est relativement plus complexe, tout comme l'identification des composants responsables de disfonctionnement ou de réduction des performances du système.

La présente invention remédie à ces inconvénients.

Elle porte sur un procédé, et un dispositif pour sa mise en oeuvre, de communication entre une pluralité de serveurs clients et une pluralité de serveurs d'applications comprenant chacun au moins une application choisie, les serveurs clients étant connectés à un 10 unique serveur MCMA lequel est à son tour connecté à l'ensemble des serveurs d'applications, 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 à charge de ce dernier de le router au serveur d'application concerné et de 15 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é utilise une chaîne de conversion entrante et/ou sortante apte à convertir les 20 appels écrits en langage et format du serveur MCMA en langage et format attendus par le serveur client et/ou d'application et à convertir les réponses du serveur client et/ou du serveur d'application écrites en langage et format serveur client et/ou serveur d'application en réponse écrites en langage et format du serveur 25 MCMA.

Un tel procédé permet ainsi d'encadrer, faciliter, et simplifier le travail d'intégration d'un système externe client (interface cliente) et/ou d'un système externe d'application (serveur d'application) en dépit des différences de format, langage et protocole entre les serveurs clients et/ou d'application et le serveur MCMA.

Selon un autre aspect de l'invention, chaque chaîne de conversion 5 entrante ou sortante (le serveur MCMA pouvant avoir des chaines de conversions entrante et/ou des chaînes de conversion sortantes) comprend: - un connecteur entrant ou sortant, intégré au serveur MCMA, - un branchement client ou d'application, intercalé entre le 10 connecteur entrant ou sortant et le serveur client ou d'application, et apte à communiquer dans le langage, le format et le protocole du serveur MCMA, et - un élément d'intégration formant adapteur/convertisseur relié au branchement client ou d'application d'une part et au 15 serveur client ou d'application d'autre part, ledit convertisseur étant apte à convertir les appels ou réponses écrits en langage et format MCMA en langage et format attendus par le serveur client ou d'application et inversement.

De préférence, le langage et le format du serveur MCMA sont du type fichier texte écrit en langage de balisage extensible du type XML ou analogue. En pratique, les langage, format et protocole du serveur client et/ou 25 du serveur d'application appartiennent au groupe formé par les fichiers texte ou binaire " à plat ", sérialisation d'objet du type java, C++, Visual Basic, ou analogues et les protocoles IP, HTTP, CORBA/IIOP, JRMP, DCOM, COM, COM+ ou analogues.

Selon un autre aspect de l'invention, chaque chaîne de conversion entrante ou sortante est apte à communiquer selon un protocole de communication selon lequel chaque appel de service est présenté sous la forme d'une action qui est une classe en langage de 5 programmation orientée objet, possédant des attributs/champs d'entrée représentant les paramètres de l'appel du service destiné à être retourné audit serveur client et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'applications cibles et/ou à prévoir d'éventuels traitements assurés par le serveur 10 MCMA.

En pratique, le serveur MCMA dès réception de l'action exécute cette dernière en mode synchrone ou asynchrone en déroulant la méthode associée à cette action pour opérer d'éventuels traitements sur les 15 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 via la chaîne de conversion sortante correspondante.

Chaque serveur d'application appelé opère son traitement et fournit le service attendu, dans son format spécifique, au serveur MCMA, via la chaîne de conversion sortante correspondante, le serveur MCMA opérant alors d'éventuels traitements sur les données ainsi retournées par le ou les serveurs d'application et valorise les 25 attributs de sortie de l'action qui est ensuite remontée au serveur client émetteur, le cas échéant via la chaîne de conversion entrante correspondante. Plusieurs serveurs d'application peuvent être sollicités lors de 30 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 5 le serveur MCMA, a l'avantage, dans un contexte de programmation orientée objet, d'être de mise en oeuvre relativement simple et facile o l'on souhaite: - bénéficier, grâce à l'héritage entre les classes, d'une mise en commun de fonctionnalités présentes de façon récurrente dans 10 les appels de services et qui peuvent ainsi être mises en oeuvre 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 (par exemple pour des contrôles de fonctionnement, de performances, ou encore pour leur 15 tarification); - uniformiser le procédé de communication avec les serveurs clients D'autres caractéristiques et avantages de l'invention (comme par 20 exemple la simplification/fiabilisation des modifications régulières dans les serveurs d'applications: remplacement, dédoublement, évolutions) apparaîtront à la lumière de la description détaillée ciaprès et des dessins dans lesquels: - la figure 1 est une représentation schématique d'un système 25 informatique mettant en oeuvre le procédé de communication entre serveurs clients et serveurs d'applications selon l'invention; - la figure 2 illustre le procédé de communication selon l'invention; - 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; - la figure 4 représente schématiquement une chaîne de 5 conversion entrante et une chaîne de conversion sortante selon l'invention; et - la figure 5 est une liste de connecteurs et de branchements selon l'invention.

En référence à la figure 1, le système informatique décrit à titre d'exemple est le système informatique d'une institution financière et plus précisément d'une banque. Ce système informatique référencé i 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 15 usagers à travers une pluralité d'interfaces clients 2.

Par exemple, les interfaces clients 2 peuvent être 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 20 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 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 41 à 4-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 5 serveurs d'application 5, tels que par exemple, un serveur bancaire 5a, un serveur boursier 5b, un serveur d'assurance 5c, un serveur de crédit 5d, ou autre 5e. Chacun de ces serveurs 5 met en oeuvre comprenant chacun au moins une application spécifique 6, respectivement référencée 6a à 6e.

Par ailleurs, un serveur 7 est intercalé entre les serveurs clients 4 et les serveurs d'applications 5. Ce serveur 7, appelé MCMA (acronyme pour Multi Canal et Multi Application) est commun à l'ensemble des serveurs clients 4 et apte à leur fournir l'ensemble des applications 15 disponibles 6 sur les serveurs d'applications 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 clients vers les 20 serveurs d'applications 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 client, la gestion de mode dégradé (par exemple gestion de bases répliquées permettant de fournir des informations malgré 25 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 4 adapte l'appel émis par son canal 30 correspondant, comme par exemple le serveur client WAP à partir il 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 7 propose plusieurs formats et protocoles afin de s'adapter aux contraintes technologiques d'un serveur client 4 et d'un réseau 3 quelconque. Les formats proposés par le serveur MCMA 7 peuvent être fichier binaire (sérialisation d'objet java, ou C++, Visual Basic, etc.) ou texte " à plat ", fichier XML. 10 Les protocoles proposés par le serveur MCMA 7 peuvent être IP, HWTP, CORBA/IIOP, JRMP, DCOM, COM, COM+, etc. Les moyens mis en oeuvre pour permettre la communication entre les 15 serveurs clients et le serveur MCMA 7 comprennent des modules logiciels constituant une chaîne de conversion dite "entrante" qui sera détaillée ultérieurement.

Le procédé de communication entre les serveurs client 4 et les 20 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 à présenter chaque appel de service sous la forme d'une action.

Pour rappel, 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 client et une méthode 30 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 7.

Ainsi, à chaque service correspond une action qui encapsule l'appel à 5 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 7.

Le serveur d'application 5 logeant le service cible 6 reçoit l'appel du 10 service cible, émis par le serveur MCMA 7, 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 7 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 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 25 souhaite connaître le solde de son compte courant; é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 7 selon le protocole et le format de son choix 30 parmi ceux proposés par ce dernier (" uneAction " est une instance (un objet, une variable) de la 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 5 déroulant la méthode associée. Cette méthode associée a un comportement qui varie en 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.; 10 - é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) 15 selon les formats et protocoles de communication spécifiques de ce dernier. (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 7); - étape (v), le serveur d'application exécute le service demandé décrit par l'appel à savoir la lecture ou le calcul du solde du compte et retourne le résultat correspondant au serveur MCMA 7 selon le format et le protocole de communication spécifiques du serveur 25 d'application; - étape (vi), la couche d'intégration du serveur MCMA 7 restitue les données résultats fournis par le serveur d'application à la méthode associée à l'action. Celle-ci valorise donc les attributs résultats de 30 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 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 7 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: une couche usage 10 et une couche intégration 12. Il est à noter que la couche d'intégration peut être entièrement résidente dans le serveur MCMA 7 comme décrit à la figure 3 ou bien encore résider en partie 20 dans le serveur MCMA 7 et en partie dans un ou plusieurs serveurs d'intégration comme illustré à la figure 4.

La couche d'usage 10 est une couche intermédiaire qui complète, simplifie et facilite l'utilisation des services fournis par les serveurs 25 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 7 (voir description ciavant) et de classes de type " objet d'usage ".

Un objet d'usage peut être considéré comme une vue d'une ou plusieurs 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 10 " 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 15 (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 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 20 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 (dit " fils ") tels que " UsageCompteEpargne ", " UsageCompteTitres ", etc. Ainsi une action représentant le service 25 " 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 exemple en résultat pour un client, par polymorphisme (concept de la 30 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 5 représentation des 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 7 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 15 bancaire 5a possède une structure 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 Sa par un nouveau serveur d'application qui ne 20 possède pas de solde espèce, n'entraînera pas de modification de 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 7.

Il est à noter que si le nouveau serveur d'application bancaire possède de 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 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 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 10 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 7 qui ne sont pas disponibles dans les 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 deux sous20 systèmes: un sous-système de routage 13 et un sous-système d'intégration 14 comprenant des modules logiciels formant des chaînes de conversion, dites "sortantes", avec chacun des serveurs d'application 5. Seuls ont été représentés les modules 14a et 14b correspondant respectivement aux serveurs bancaire Sa et boursier 25 5b Le sous-système de routage 13 est le point d'entrée des actions de la couche 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, n' 30 du compte, n0 du client) le ou les serveurs d'applications concernés et donc le ou les modules d'intégrations 14 à qui déléguer la communication. Pour les modules d'intégration 14 concernés, le sous-système de routage 13 fourni l'objet d'usage et le service à appeler dans le serveur d'application.

Les modules d'intégration 14 constituant une chaîne de conversion sortante sont donc chargés de la communication avec un serveur d'application spécifique 5 selon les formats et protocoles attendus par ce serveur d'application. Ils sont également capables de convertir 10 des structures de données spécifiques provenant du serveur d'application en objet d'usage et inversement. Une telle chaîne de conversion sortante sera plus détaillée ultérieurement.

Le travail effectué par chaque composant du serveur MCMA 7 va être 15 illustré dans l'exemple suivant: consultation du compte X d'un client Y sur le 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 20 Relation Management, c'est-à-dire Gestion de la Relation Client) de la couche de service supplémentaire 11, la liste des numéros de comptes détenus 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 25 " UsageSolde " avec des soldes non renseignés. Le sous-système de routage 13 va, en fonction du numéro de compte et du type de compte, déterminer la chaîne de conversion sortante du soussystème d'intégration 14 concernée et lui demander de faire l'appeldu service cible adéquat en lui fournissant l'objet d'usage vide. Le 30 sous-système 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 retourner l'objet d'usage ainsi renseigné au soussystème de 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 préférence avec un langage de structuration encore appelé langage de balisage extensible, tel que le XML (acronyme anglo-saxon 10 pour extensible Markup Language).

Un document structuré est une collection d'ensembles d'informations associés chacun à un type et des attributs, et composés entre eux selon des relations principalement hiérarchiques. Un tel document 15 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 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 " <b> " (balise ouvrante) et " </b> " (balise fermante), le premier repère indiquant le début d'un ensemble d'informations nommé " b " et le 25 second la fin de cet ensemble.

Contrairement au langage HTML (HyperText Markup Language), le langage 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 30 tout types d'informations.

Un document structuré est associé à ce que l'on appelle un schéma de structure ou DTD (Document Type Definition) définissant sous la forme de règles la structure et le type d'information de chaque 5 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 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 servant d'analyseur XML (ou XML parser) 15 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 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 5 du type XML dans le cadre de fonctions d'import/export de données en association 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 10 associant une balise XML à chaque action, ces balises contenant elles même une 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 15 correspondent à des traitements d'écriture, création ou modification de données, sont transférés (injectées/importées) dans les serveurs d'application via le serveur MCMA 7 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 procédé de communication par action et par XML nécessiteront 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 7. 25 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 30 d'un serveur client WEB, destiné à la 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 7 sous la forme d'un fichier 10 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 15 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 20 à 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 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 des données du système via le serveur intermédiaire MCMA 7.

Un tel import/export 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.

Selon l'invention, les communications entre les serveurs clients 4 et le serveur MCMA 7 d'une part, et entre le serveur MCMA 7 et les serveurs d'application 5 d'autre part, utilisent des chaînes de conversion logicielle, appelées respectivement entrantes et sortantes 10 par référence au serveur MCMA 7. Le seul invariant de ces chaînes de conversion est l'utilisation de messages XML représentant des actions pour communiquer avec le serveur MCMA 7.

Chaque chaîne de conversion entrante est apte à assurer la 15 communication entre un serveur client donné 4 et le serveur MCMA 7 selon un protocole de communication choisi.

Une chaîne de conversion entrante se compose de différents modules implémentés sur le serveur client 4 et sur le serveur MCMA 7. 20 Côté serveur client 4 on a un module adapteur client et un module de branchement client Le module adapteur client adapte les messages du format spécifique 25 au serveur client au format XML du serveur MCMA 7. Le module adapteur client est chargé, suite a une demande (message au format spécifique du serveur client) initiée par le module fonctionnel du serveur client (par " module fonctionnel ", on entend le module fournissant le coeur des fonctionnalités propres à ce serveur client, 30 par exemple si le serveur client est un serveur WEB, ce module fournis les fonctionnalités propres à un serveur WEB et gère des données propres à un serveur WEB), de la création de messages XML correspondants pour envoi au serveur MCMA 7 d'une action formant appel de service, et inversement, de l'analyse des messages XML 5 résultat retourné par le serveur MCMA 7 pour les reconvertir en message dans un format reconnu par le serveur client ou en erreur le cas échéant. Ce module n'est pas chargé de l'échange des messages XML. Le module de branchement client (ou PLUG IN) 22 est chargé de la communication 21 avec un connecteur entrant (ou connecteur IN) 20 du serveur MCMA 7. Ce module est écris dans la technologie du serveur client. Il est chargé de l'échange de messages XML avec un seul type de connecteur entrant du serveur MCMA 7 via un seul type 15 de protocole. Il n'est chargé que de l'échange des messages XML, pas de leur création à l'envoi ou de leur analyse à la réception.

Côté serveur MCMA 7 on a donc un connecteur entrant 20, encapsulé dans le serveur MCMA 7 et écris dans la technologie du 20 serveur MCMA 7. Ce connecteur comprend un module de communication et un module de conversion.

Le module de communication est adapté pour communiquer avec des " branchements clients " (PLUG IN) utilisant le même protocole (en 25 effet, plusieurs branchements clients, écris chacun dans une technologie différente comme VisualBasic ou Java par exemple, peuvent être compatibles avec un même connecteur entrant s'ils s'appuient sur le même protocole de communication).

Le module de conversion convertit un message XML en objet (au sens de la programmation orienté objet) de type action, dans la technologie du serveur MCMA 7 et inversement, ce module est communément appelé le " parseur XML ".

Chaque chaîne de conversion sortante est apte à assurer la communication entre un serveur d'application 5 et le serveur MCMA 7 selon un protocole de communication choisi.

Une chaîne de conversion sortante se compose de différents modules implémentés sur le serveur MCMA 7 et sur un serveur distinct dit appelé serveur d'intégration 28.

Côté serveur MCMA 7, on a un connecteur sortant d'intégration (ou 15 connecteur OUT) 24, encapsulé dans le serveur MCMA 7 et écris dans la technologie du serveur MCMA 7. Ce connecteur comprend un module de communication et un module de conversion.

Le module de communication est adapté pour communiquer avec des 20 branchements serveur d'intégration (ou PLUG OUT) 26 utilisant le même protocole (en effet, plusieurs branchements serveur d'intégration, écris chacun dans une technologie différente comme C ou COBOL par exemple, peuvent être compatibles avec un même connecteur entrant s'ils s'appuient sur le même protocole de 25 communication); Le module de conversion d'un objet (au sens de la programmation orienté objet) de type action, dans la technologie du serveur MCMA 7, en message XML et inversement. C'est le même module " parseur 30 XML " que celui utilisé dans le " connecteur entrant " si le même format XML est utilisé (note: un serveur MCMA 7 peut disposer de plusieurs formats XML différents: canonique, compacte, etc.) Côté serveur d'intégration 28 on a donc un module de branchement, 5 serveur d'intégration (ou PLUG OUT) 26, un module convertisseur et un module de branchement serveur d'application.

Le module de branchement serveur d'intégration 26 est chargé de la communication 23 avec un connecteur sortant d'intégration 24 du 10 serveur MCMA 7, ce module de branchement serveur est encapsulé dans le serveur d'intégration, est écris dans la technologie du serveur d'intégration, il est chargé de l'échange de messages XML avec un seul type de connecteur sortant du serveur MCMA 7 via un seul type de protocole, il n'est chargé que de l'échange des messages XML, pas 15 de leur analyse à la réception de l'appel ou de leur création à l'envoi de la réponse.

Le module convertisseur convertit les messages au format XML du serveur MCMA 7 en messages dans le format spécifique au serveur 20 d'application dont le serveur d'intégration à la charge, le module convertisseur est chargé de l'analyse des messages XML représentant des actions formant appels de service émis par le serveur MCMA 7 pour les convertir en message formant appel de services dans le format spécifique du serveur d'application dont le serveur 25 d'intégration à la charge, et inversement, de la création de messages XML à retourner au serveur MCMA 7 comme résultat d'appel de service (ce résultat, ou cette erreur le cas échéant, a été fourni initialement par le serveur d'application dont le serveur d'intégration à la charge), ce module n'est pas chargé de l'échange des messages. 30 Le module de branchement serveur d'application est chargé de la communication des messages avec le serveur d'application dont le serveur d'intégration à la charge via un protocole de communication spécifique à ce serveur d'application, il n'est chargé que de l'échange 5 des messages, pas de leur création à l'envoi ou de leur analyse à la réception.

Selon le protocole de communication choisi pour la chaîne entrante ou sortante, chaque appel de service est présenté sous la forme d'une 10 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 du service destiné à être retourné audit serveur client et une méthode apte à encapsuler l'appel à destination d'un serveur cible et/ou à prévoir d'éventuels traitements assurés par le 15 serveur MCMA 7.

Le serveur cible (serveur MCMA 7, en cas de chaîne entrante, serveur d'application en cas de chaîne sortante) en réponse à une action, est apte à exécuter cette dernière en mode synchrone ou asynchrone en 20 déroulant la méthode associée à cette action. Pour un même message XML l'action correspondante n'est pas la même si elle se trouve dans le serveur MCMA 7 ou dans le serveur d'intégration. La méthode associée ne fera donc pas le même travail selon que l'on se trouve dans la chaîne de conversion entrante (action du serveur MCMA 7) 25 ou la chaîne de conversion sortante (action du serveur d'intégration).

Ainsi pour la chaîne de conversion entrante, le message XML correspond à une action du serveur MCMA 7, la méthode correspondante est exécutée dans le serveur MCMA 7. Elle permet 30 généralement d'opérer d'éventuels traitements sur les attributs/champs d'entrée et/ou d'envoyer au(x) serveur(s) d'application cible(s) concerné(s) l'appel de service via la chaîne de conversion sortante correspondante pour qu'elle retransmette le service au serveur d'application correspondant. Lorsqu'il reçoit le 5 résultat de l'appel service, le serveur MCMA 7, via la méthode de l'action en cours d'exécution, 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 ensuite remontée au serveur client émetteur, via la chaîne de conversion entrante 10 correspondante et au format choisi par ce dernier.

Dans le cas d'une chaîne de conversion sortante, le message XML correspond à une action du serveur d'intégration, la méthode correspondante est exécutée dans le serveur d'intégration. Elle 15 permet généralement de convertir le message XML en en message formant appel de services dans le format spécifique du serveur d'application dont le serveur d'intégration à la charge, puis de l'envoyer à ce serveur d'application via le protocole spécifique du serveur d'application pour qu'il fournisse le service. Lorsqu'il reçoit le 20 résultat de l'appel service, le serveur d'intégration, via la méthode de l'action en cours d'exécution, reconverti le message résultat au format spécifique du serveur d'application dont il a la charge, en message résultat au format XML du serveur MCMA 7 et le lui retourne. Pour réaliser son travail, le serveur d'intégration s'appuie 25 sur les modules présentés ci-dessus lors de la description des composants de la chaîne de conversion sortante.

En pratique, la chaîne de conversion entrante permet à un serveur client 4 ayant des formats et langage spécifiques de communiquer avec le serveur MCMA 7 dont le langage et le format sont différents de ces langage et format spécifiques.

Par exemple, considérons que le serveur client 4 est un serveur Web 5 dynamique écris en ASP.Net, pour accéder aux serveurs d'application via l'Internet. Le serveur client 4 utilise pour format des messages XML qui sont différent du format XML du serveur MCMA 7, et considérons que côté serveur MCMA 7, écrit par exemple en Java, le connecteur entrant 20 utilise le protocole SOAP. 10 La chaîne de conversion entrante correspondante nécessite donc le développement coté serveur client d'un module d'adaptation client pour transformer les messages XML du serveur client en messages au format XML du serveur MCMA 7 et inversement. Le serveur client 15 4 hébergera également un module de branchement client 22 écris en ASP.Net et utilisant le protocole SOAP afin de communiquer avec connecteur entrant 20 pour envoyer le message XML créé par le module d'adaptation client et récupérer la réponse du serveur MCMA 7. Le serveur MCMA 7 peut également comprendre des chaînes de conversion logicielle sortantes.

Par exemple, considérons que le serveur d'application 5 est un 25 serveur d'application bancaire écris en COBOL, il utilise pour format des messages textes à plat avec des données délimitées par des caractères spéciaux comme le "; " (format CSV). Le serveur d'application bancaire utilise également pour ses communications avec des systèmes clients, le protocole IP de la façon suivante: 30 chaque message texte envoyé ou reçus par le serveur d'application bancaire est précédé d'une entête composée de 6 chiffres alignés à droite et complétés par des chiffres zéros à gauche si nécessaire puis d'un espace (blanc, caractère ASCII 32). Cette entête donne la taille du message texte qui suit (nombre d'octets à lire, après le blanc), par 5 exemple: " 003585 datal;data2; ... ". Considérons par ailleurs que côté serveur MCMA 7 (écris par exemple en C++ ), le connecteur sortant 24 utilise le protocole IIOP.

La chaîne de conversion sortante correspondante nécessite donc le 10 développement d'un serveur d'intégration indépendant écrit par exemple en Java pour adapter les appels émis par le serveur MCMA 7 en XML via le protocole IIOP en appels de messages textes au format CSV via le protocole IP de la façon décrite précédemment et inversement. Le serveur d'application 5, tout comme le serveur 15 MCMA 7, ne subira aucune modification. Pour effectuer son travail, le serveur d'intégration 28 héberge le " module de branchement serveur d'intégration " 26 écris en Java et utilisant le protocole IIOP afin de communiquer avec connecteur sortant 24 pour recevoir les messages XML formant appel de service émis par le serveur MCMA 7. 20 Le coeur du serveur d'intégration est le module convertisseur, écris en Java, chargé de convertir les messages XML du serveur MCMA 7 en message texte au format CSV attendu par le serveur d'application bancaire 5. Enfin, le serveur d'intégration doit être complété par le développement d'un module de branchement serveur d'application, 25 écris en Java et utilisant le protocole IP (de la façon décrite précédemment) afin de communiquer avec le serveur d'application bancaire pour envoyer le message texte CSV créé par le module convertisseur et récupérer la réponse du serveur d'application bancaire. Le module " convertisseur " du serveur d'intégration ou le module " d'adaptation client " du serveur client peuvent en fonction du langage utilisé et des formats à convertir s'appuyer sur des produits du marché des outils de développement de progiciel informatique pour faciliter leur travail.

Par exemple, la conversion XML vers fichiers à plat et vice versa peut être mise en place en s'appuyant sur un parseur XSLT " Xalan " de l'organisme Open Source " Apache ". Autre cas de figure: la 10 conversion d'un format XML vers un autre format XML, ou vers des tables de base de données, peut être mise en place par un convertisseur qui s'appuie sur le produit " Liquid Data ", vendu par société " BEA ".

D'une manière générale, l'exécution des appels de service est du type synchrone ou asynchrone. Les connecteurs entrants 20 et/ou sortants 24 sont synchrones ou asynchrones.

En référence à la figure 5, une liste répertorie les différents format et 20 langage susceptibles d'être convertis par les chaînes de conversion selon l'invention.

Chaque connecteur du serveur MCMA 7, qu'il soit entrant ou sortant, est associé à un protocole qui peut appartenir au groupe 25 formé par les protocoles IP, HTTP, CORBA/IIOP, JRMP, DCOM, COM, COM+, SOAP ou analogues.

A chaque connecteur peuvent être associé des branchements client ou serveur d'intégration, dédié au protocole du connecteur et écris dans l'un des langages appartenant au groupe formé par Java, C++, Visual Basic, COBOL, PHP, PERL ou analogues.

De façon préférentielle, le choix du connecteur associé à un serveur 5 d'application ce fait par paramétrage du serveur MCMA 7. Ce paramétrage indique les informations tels que le connecteur sortant utilisé et les données nécessaires pour que celui-ci établisse une connexion au serveur d'intégration. Par exemple, un connecteur sortant IP disposera de paramètres de connexions IP tels que 10 l'adresse IP et le port du serveur d'intégration et le délai à partir duquel il considère que le serveur d'intégration ne répondra plus (time out).

Exemple de définition de ces paramètres dans un fichier au format INI de Microsoft Windows (cas ou le serveur MCMA 7 serais écris par 15 exemple en Visual Basic) [TCPIP OUT] Host26= 192.5.60.183 Port26=6868 TimeOut26=5 Les chaînes de conversion logicielles selon l'invention permettent de réduire les cots d'intégration et d'exploitation du serveur MCMA 7 avec les serveurs clients et les serveurs d'applications en: - structurant les modalités d'intégration d'un serveur client quelconque avec le serveur MCMA 7 (XML représentant une action formant appel de service fournis par le serveur MCMA 7, branchement client, connecteur entrant); - structurant les modalités d'intégration du serveur MCMA 7 avec un serveur d'application quelconque (XML représentant une action formant appel de service attendu par le serveur MCMA 7, connecteur sortant, branchement serveur d'intégration, serveur d'intégration); - mutualisant les couches de communications coté serveur MCMA 7 5 (réutilisation des connecteurs entrant pour tous les serveurs clients, réutilisation des connecteurs sortant pour tous les serveurs d'applications); - préparant les travaux d'adaptation des serveurs clients (les 10 branchements clients sont déjà fournis par l'équipe de développement du serveur MCMA 7, ils sont testés pour le langage utilisé par le serveur client le protocole et le connecteur entrant choisi); - préparant le développement du serveur d'intégration (le branchement serveur d'intégration fournis la souche de départ du serveur d'intégration.

En pratique, il est préférable que les branchements client 22 et les 20 branchements serveur d'intégration d'application 26 soit développés par la même équipe informatique que celle chargée du développement des connecteurs du serveur MCMA 7. Si en fonction du langage avec lequel est écris le serveur client ou le serveur d'intégration, le branchement client n'existe pas, c'est cette équipe 25 qui est la mieux placée pour réalisée ce nouveau module (enrichissement du " kit d'intégration " du connecteur correspondant et donc enrichissement du serveur MCMA 7). Pour les mêmes raisons, si en fonction du protocole choisi le connecteur entrant ou sortant n'existe pas, c'est l'équipe chargée du développement du 30 serveur MCMA 7 qui doit développer le connecteur manquant ainsi que le premier branchement correspondant pour le tester (enrichissement du kit d'intégration du serveur MCMA 7).

L' équipe informatique chargée du développement des connecteurs 5 entrants, des connecteurs sortant, des branchements clients et des branchements serveur, mettra avantageusement en place des fonctionnalités de trace (création de fichier de log) lors des émissions/réception de messages pour faciliter l'identification du composant responsable de dysfonctionnement en cas de panne ou 10 l'identification du composant " goulet d'étranglement " en cas de problèmes de performances.

Ainsi les développements spécifiques (réalisés par une équipe de projet d'intégration) nécessaires à l'intégration d'un serveur client ou 15 d'un serveur d'application avec le serveur MCMA 7 sont réduits au minimum: pour l'intégration d'un nouveau serveur client: développement du module d'adaptation client et développement du code " glue " entre 20 ces deux modules et le troisième module fonctionnel; - pour l'intégration d'un nouveau serveur d'application: développement du module convertisseur, développement du module de branchement serveur d'application et développement du code 25 " glue " entre ces trois modules.

Ces développements spécifiques sont également fiabilisés par la réutilisation de connecteurs et de branchements existant déjà éprouvés. 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.

Claims (1)

REVENDICATIONS
1. [1] Procédé permettant de faire communiquer à l'intérieur d'un système informatique (1) de type distribué, une pluralité de serveurs 5 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 au moins une application choisie (6), les serveurs client (4) étant directement connectés à un unique serveur MCMA lequel est à 10 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 à charge pour ce dernier de le router au serveur d'application concerné et de faire 15 remonter en retour d'éventuelles informations du serveur d'application vers le serveur client, caractérisé en ce que chaque appel de service entre un serveur client (4) et le serveur MCMA (7) coopère avec une première chaîne de conversion des langages et des formats et/ou en ce que chaque appel de service entre le serveur 20 MCMA (7) et un serveur d'application (5) coopère avec une seconde chaîne de conversion des langages et des formats, ladite seconde chaîne de conversion étant distincte de ladite première chaîne de conversion. [2] Procédé selon la revendication 1, caractérisé en ce que lesdits serveurs client (4) présentent les appels de service sous la forme d'action, 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 d'un ou plusieurs serveurs d'application cibles (5) et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA (7).

   [3] Procédé selon la revendication 1, caractérisé en ce que chaque 5 action formant appel de service est transférée entre serveurs sous la forme d'un document textuel structuré écrit en langage de balisage extensible du type XML ou analogue.

   [4] Procédé selon la revendication 1, caractérisé en ce que l'action 10 formant appel comprend un identifiant correspondant à l'identifiant du service cible, des attributs d'entrée représentant les paramètres de l'appel de service et d'éventuels attributs de sortie représentant le résultat du service destiné à être retourné audit serveur client [5] Procédé selon la revendication 4, caractérisé en ce que les attributs d'entrée correspondant à un service écriture du type création ou modification sont importés dans les serveurs d'application correspondants (5) au format d'un fichier XML et ce, via le serveur MCMA (7).

   [6] Procédé selon la revendication 4, caractérisée en ce que les attributs de sortie correspondant à un service lecture du type recherche ou consultation sont exportés des serveurs d'application correspondants (5) au format d'un fichier XML et ce, via le serveur 25 MCMA (7).

   [7] Procédé selon la revendication 1, caractérisé en ce que lesdits serveurs d'application utilisent une couche logicielle d'intégration et que les serveurs client utilisent une couche logicielle d'usage déduite 30 de ladite couche d'intégration et en ce que la structure de données de d'une action formant appel de service coopère avec ladite couche d'usage. [8] Procédé selon l'une quelconque des revendications précédentes, 5 caractérisé en ce que le système informatique (1) est du type à offrir des services financiers.

   [9] Procédé selon la revendication 8, caractérisé en ce que les serveurs client (4) coopèrent avec des interfaces clientes (2) 10 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 en libre-service, des ordinateurs personnels pour banque à domicile, des télévisions interactives.

   [10] Procédé selon la revendication 8, caractérisé en ce que les serveurs d'application (5) appartiennent au groupe formé par des gestionnaires de 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, titre, assurance, et 20 finance.

   [11] Procédé selon la revendication 1, caractérisé en ce que les langage, format et/ou protocole du serveur client (4) et/ou du serveur d'application (5) appartiennent au groupe formé par les 25 fichiers texte ou binaire " à plat ", XML, sérialisation d'objet du type java, C++, Visual Basic, Perl, COBOL, PHP ou analogues et les protocoles IP, HTTP, CORBA/IIOP, JRMP, DCOM, SOAP ou analogues. [12] Procédé selon la revendication 1, caractérisé en ce que chaque chaîne de conversion entrante comprend un module d'adaptation et un module de branchement client (22) intégré au serveur client (4) et un connecteur entrant (20) associé intégré au serveur MCMA (7).

   [13] Procédé selon les revendications 3 et 12, caractérisé en ce que ledit module d'adaptation client adapte les messages du format spécifique au serveur client (4) au format XML du serveur MCMA (7) et inversement, en ce que ledit module de branchement client (22) 10 échange les messages XML avec le serveur MCMA (7) selon un seul type de protocole et en ce que ledit connecteur entrant (20) intégré au serveur MCMA (7) est apte à échanger des messages selon le protocole dudit branchement client (22) et opère la conversion des messages XML en objet de type action dans la technologie du serveur 15 MCMA (7) et inversement.

   [14] Procédé selon la revendication 1, caractérisé en ce que chaque chaîne de conversion sortante utilise un serveur d'intégration (28) interposé entre le serveur MCMA (7) et le serveur d'application (5) 20 correspondant.

   [15] Procédé selon la revendication 1, caractérisé en ce que chaque chaîne de conversion sortante comprend un connecteur sortant (24) intégré au serveur MCMA (7) et un branchement serveur 25 d'intégration (26) et un module convertisseur intégrés au serveur d'intégration (28).

   [16] Procédé selon les revendications 3 et 15, caractérisé en ce que ledit module convertisseur adapte les messages du format spécifique 30 au serveur d'application (5) au format XML du serveur MCMA (7) et inversement, en ce que ledit branchement serveur d'intégration (26) échange les messages XML avec le serveur MCMA (7) selon un seul type de protocole et en ce que ledit connecteur sortant entrant (24) intégré au serveur MCMA (7) est apte à échanger des messages selon 5 le protocole dudit branchement serveur d'intégration (26) et opère la conversion des messages XML en objet de type action dans la technologie du serveur MCMA (7) et inversement.

   [17] Dispositif de communication entre une pluralité de serveurs 10 client (4) et une pluralité de serveurs d'applications (5) comprenant chacun au moins une application choisie (6), les serveurs clients (4) étant connectés à un unique serveur MCMA (7) lequel est à son tour connecté à l'ensemble des serveurs d'applications (5), de sorte que tout appel de service d'un serveur client à destination d'un serveur 15 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 remonter en retour d'éventuelles informations du serveur d'application (5) vers le serveur client (4), caractérisé en ce qu'il comprend au moins une chaîne de conversion 20 entrante et/ou sortante apte chacune à convertir les appels écrits en langage et format du serveur MCMA en langage et format attendus par le serveur client (4) et/ou le serveur d'application (5) et à convertir les réponses du serveur client (4) et/ou du serveur d'application (5) écrites en langage et format du serveur client et/ou 25 serveur d'application en réponse écrites en langage et format du serveur MCMA.

   [18] Dispositif selon la revendication 19, caractérisé en ce que chaque chaîne de conversion entrante et/ou sortante est apte à 30 communiquer avec un serveur client (4) et/ou un serveur d'application (5) selon un protocole de communication selon lequel chaque appel de service est présenté 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 5 paramètres de l'appel du service destiné à être retourné audit serveur client et une méthode apte à encapsuler l'appel à destination d'un ou plusieurs serveurs d'applications cibles et/ou à prévoir d'éventuels traitements assurés par le serveur MCMA.

   [19] Dispositif selon la revendication 18, caractérisé en ce que le serveur MCMA, en réponse à une action, est apte à exécuter cette dernière en mode 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) 15 d'application cible(s) concerné(s) l'appel de service dans le format et protocole spécifiques attendus par ledit ou lesdits serveurs d'application via la chaîne de conversion entrante et/ou sortante correspondante, chaque serveur d'application appelé opérant le traitement et fournissant le service attendu, dans son format 20 spécifique, au serveur MCMA, via la chaîne de conversion sortante correspondante tandis que le serveur MCMA opérant 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 ensuite remontée au serveur client émetteur, via la chaîne de 25 conversion entrante correspondante.