FR 2877116 A1 20060428 FR 0411447 A 20041027 SYSTEME D'APPEL DE SERVICES LOCAUX D'AU MOINS UNE APPLICATION LOCALE A ARCHITECTURE DE MESSAGERIE CLASSIQUE A PARTIR D'AU MOINS UNE APPLICATION DISTANTE A ARCHITECTURE DE MESSAGERIE CLASSIQUE La présente invention se rapporte à un système d'appel de services locaux d'au moins une application locale à architecture de messagerie classique à partir d'au moins une application distante à architecture de messagerie classique. Dans la présente description, qui se rapporte à l'échange d'ordres et de données entre des applications ou systèmes, on dénomme de façon arbitraire l'une d'elles client (ou application distante) et les autres serveurs (ou applications locales), sans qu'elles soient nécessairement éloignées les unes des autres. Pour invoquer des services locaux d'une application à partir d'une autre, par exemple en vue de tester un système par un processus de stimulation et de validation, à partir d'un calculateur, on structure l'application et le calculateur sous forme d'une architecture de type n-tiers (n couches logiques) dont l'une est un middleware (couche intermédiaire) supportant le code CORBA. Une telle solution nécessite donc une modification importante de l'architecture de l'application et du calculateur. Par contre, dans la cas où l'application locale ne comporte pas de middleware supportant le code CORBA, et en particulier lorsque l'on ne peut pas ou ne veut pas modifier l'architecture même de cette application, il n'existe pas de solution connue pour l'invocation des services locaux de l'application. La présente invention a pour objet un système d'appel de services locaux d'au moins une application locale à architecture de messagerie classique à partir d'au moins une application distante à architecture de messagerie classique qui soit simple à réaliser et qui ne nécessite pas la modification de l'architecture de l'application locale ni de celle de l'application distante. Le système conforme à l'invention est caractérisé en ce que l'on munit l'application (les applications) distante(s) et l'application (les applications) locale(s) d'interfaces de communication utilisant des distributions d'objets. Selon un mode de réalisation de l'invention, ces interfaces utilisent le code CORBA. La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel: - la figure 1 est un bloc-diagramme simplifié d'un système conforme à l'invention, la figure 2 est un diagramme simplifié illustrant les principales étapes de la génération de passerelles entre une application distante et une application locale, conformément au procédé de l'invention, et la figure 3 est un diagramme détaillant les différentes actions réalisées par le système de l'invention pour établir la communication entre une application distante et une application locale, conformément au procédé de l'invention. Sur l'exemple simplifié de la figure 1, on a représenté un calculateur 1 ou application distante, communiquant (simultanément ou non) avec deux applications locales différentes 2 et 3. Pour cet exemple, on a représenté deux applications locales, mais il est bien entendu que dans le système de l'invention, l'application distante peut communiquer avec un nombre quelconque d'applications locales. Ces deux applications locales comportent dans l'exemple représenté des calculateurs 2A, 3A, soumis à des tests de validation stimulés par l'application 1, qui est un outil de validation à calculateur, mais il est bien entendu que l'invention n'est pas limitée au déroulement de tests, et qu'elle peut s'appliquer à de nombreuses applications nécessitant des échanges entre calculateurs. Les applications 2 et 3 comportent chacune au moins un calculateur, et leurs calculateurs peuvent mettre en oeuvre des processus identiques ou différents. Par exemple, le calculateur du système 2 peut mettre en oeuvre un processus en code ADA, tandis que le calculateur du système 3 peut mettre en oeuvre un autre processus en code C++. Selon l'invention, on munit chaque application locale d'une passerelle ( gateway en anglais), 4, 5 respectivement. Ces passerelles, dites ici passerelles serveur , sont munies chacune d'une interface CORBA, respectivement 4a, 5a, qui leur permettent de dialoguer avec une interface équivalente la dont est munie l'application distante 1. Ces interfaces comportent, de façon bien connue en soi, des bouchons ( stub en anglais, qui sont des proxys convertissant des appels de fonctions en messages) et des squelettes ( skeletons en anglais, qui sont des adaptateurs convertissant inversement des messages en appels de fonctions). Ces interfaces sont appropriées à la génération d'un code de communication, qui est dans le cas présent le code CORBA. Ainsi, ce code CORBA sert de moyen de communication transparent entre le calculateur de test 1 et les applications locales 2 et 3 soumises à des tests. Ce code est véhiculé par un bus CORBA 100, par lequel transitent donc des objets distribués. On a figuré ces objets par des symboles ORBI, ORB2 et ORB3, ORB4. Ces objets (ou noyaux) sont les vecteurs de transport de messages pour transmettre les appels CORBA effectués entre l'application distante 1 et les applications locales 2 et 3, respectivement. Par contre, les appels Al et A2 transitant dans les deux sens, entre les passerelles 4 et 5 et les calculateurs 2A et 3A respectivement, sont des appels locaux, qui ne sont pas, par hypothèse, en code CORBA. On va expliquer en référence à la figure 2 les différentes étapes nécessaires à la génération d'une passerelle selon l'invention. On part d'un modèle d'interface 6 d'un système soumis aux tests, par exemple le système 2. Un tel modèle est en langage UML dans le cas présent, et il est implanté dans l'application distante, qui a le rôle d'application cliente. Ce modèle est associé à un générateur qui génère du code IDL référencé 8 (Interface Description Language, c'est-à-dire un langage de description d'interfaces), supporté par le code CORBA. La génération de l'implémentation des interfaces générées précédement dans le langage cible de l'application locale se fait par l'intermédiaire des générateurs 'client' et 'serveur' en deux étapes principales référencées 7 et 9. A l'étape 7, le générateur 'client' initie tout d'abord la génération (10) d'un code permettant l'appel du code client. Ce code (11), surcharge le code client 12 (relatif au stub de l'application cliente et généré à l'étape 18a, comme décrit ci-dessous), puis par un autre code client (13) qui est utilisé pour l'initialisation du mécanisme CORBA, et compilé avec ceux-ci, produit la passerelle client 14 (telle que la passerelle la de la figure 1). Cette passerelle 14 est ensuite reliée par un éditeur de liens de l'application cliente 15 à la partie métier 16 de cette application, afin de créer l'exécutable client. A l'étape 8, le générateur IDL génère (17) les interfaces (18) de l'ensemble des applications cliente et serveur(s). Ces interfaces 18 génèrent (18a) du code CORBA, de préférence au moyen de middlewares du commerce (COTS) dédiés CORBA, dans le langage cible (celui de l'application destinée à recevoir ce code, et qui peut être du Java, du C+ +,...). D'une part, les interfaces 18 génèrent le code client 12 mentionné ci-dessus, et d'autre part, elles génèrent un code serveur 20, qui est le skeleton de l'application serveur 19. A l'étape 9, le générateur 'serveur' génère (21) un code serveur (22) dans le langage cible de l'application 19. Ce code 22, comportant les appels de fonctions de l'application 19, surcharge le code 20, et est complété par un code serveur 23 (utilisé pour l'initialisation du processus CORBA). L'ensemble est compilé pour produire la passerelle serveur 24. Cette passerelle 24 est ensuite reliée par un éditeur de liens de l'application serveur 19 à la partie métier 25 de cette application, afin de créer l'exécutable serveur. Sur le diagramme de la figure 3, on a représenté les différentes étapes successives de l'établissement des moyens nécessaires aux communications entre une application distante (ou client, qui est, dans le cas présent, un système de test) 26 et une application locale 27 (ou serveur, qui est, dans le cas présent le système à tester), et en particulier la formation de la passerelle serveur 28. Ces différentes étapes sont les suivantes: El: mise en route du système 27 à tester. E2: démarrage du système de test, qui démarre la passerelle client 29. E3: démarrage du service de nommage 30 ( naming service en anglais) du code CORBA véhiculé par le bus CORBA 31. E4: enregistrement de la passerelle serveur auprès du service de nommage. E5: l'application distante invoque un premier service que doit réaliser le serveur. E6: la passerelle client 29 interroge les services de nommage. E7: les services CORBA procèdent à l'encodage ( marshalling en anglais) des données correspondant au service invoqué, transportent l'invocation ainsi encodée, décodent ces données, et invoquent l'objet réel correspondant à ce service dans la passerelle serveur 28. E8: la passerelle serveur 28 appelle, dans le système testé 27, la fonction relative au service invoqué. E9: le système testé 27 renvoie la réponse à l'invocation de service qu'elle vient de recevoir. E10: les services CORBA procèdent à l'encodage des données, transportent l'invocation ainsi encodée vers le client, décodent les données et les transmettent à la passerelle client 29. El1: la passerelle 29 transmet l'invocation à l'application 28 en appelant le vrai code dans cette application. 20 25 30 REVENDICATIONS 1. Système d'appel de services locaux d'au moins une application locale (2-3, 19, 27) à architecture de messagerie classique à partir d'au moins une application distante (1, 15, 26) à architecture de messagerie classique, caractérisé en ce que l'application (les applications) distante(s) et l'application (les applications) locale(s) comportent des interfaces de communication (la,4,5,14,24,28,29) utilisant des distributions d'objets. 2. Système selon la revendication 1, caractérisé en ce que les interfaces utilisent le code CORBA. 3. Système selon la revendication 1 ou 2, caractérisé en ce que les interfaces sont générées par un générateur IDL.