EP1805613A1 - 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 - Google Patents

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

Info

Publication number
EP1805613A1
EP1805613A1 EP05810944A EP05810944A EP1805613A1 EP 1805613 A1 EP1805613 A1 EP 1805613A1 EP 05810944 A EP05810944 A EP 05810944A EP 05810944 A EP05810944 A EP 05810944A EP 1805613 A1 EP1805613 A1 EP 1805613A1
Authority
EP
European Patent Office
Prior art keywords
application
local
messaging architecture
code
conventional messaging
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05810944A
Other languages
German (de)
English (en)
Inventor
François FERRE
Jérôme VIALLET
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Publication of EP1805613A1 publication Critical patent/EP1805613A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]

Definitions

  • the present invention relates to a local service call system of at least one local application with a standard messaging architecture from at least one remote application with a conventional messaging architecture.
  • n-tiers architecture (n logical layers), one of which is a “middleware"
  • the present invention relates to a local service call system for at least one local application with a standard messaging architecture from at least one remote application with a conventional messaging architecture that is simple to implement and does not require modifying the architecture of the local application or that of the remote application.
  • the system according to the invention is characterized in that the remote application (s) and the local application (s) are provided with communication interfaces using object distributions. . According to one embodiment of the invention, these interfaces use the CORBA code.
  • FIG. 1 is a simplified block diagram of FIG. a system according to the invention
  • FIG. 2 is a simplified diagram illustrating the main steps of generating gateways between a remote application and a local application, in accordance with the method of the invention
  • FIG. 3 is a diagram detailing the various actions performed by the system of the invention for establishing communication between a remote application and a local application, in accordance with the method of the invention.
  • FIG. 1 there is shown a computer 1 or remote application, communicating (simultaneously or not) with two different local applications 2 and 3.
  • two local applications are represented, but it is well understood that in the system of the invention, the remote application can communicate with any number of local applications.
  • These two local applications include in the example shown computers 2A, 3A, subjected to validation tests stimulated by the application 1, which is a validation tool calculator, but it is understood that the invention n ' is not limited to the running of tests, and it can be applied to many applications requiring exchanges between computers.
  • the applications 2 and 3 each comprise at least one computer, and their computers can implement identical or different processes.
  • the computer of the system 2 can implement a process in ADA code
  • the computer of the system 3 can implement another process in C ++ code.
  • each local application is provided with a gateway (gateway) 4, 5 respectively.
  • gateways here called “server gateways”
  • CORBA interface respectively 4a, 5a, which allow them to communicate with an equivalent interface that is provided with the remote application 1.
  • These interfaces include, well known in itself, "plugs"("stub” in English, which are “proxies” converting function calls into messages) and skeletons ("skeletons" in English, which are adapters converting conversely messages to calls functions).
  • These interfaces are suitable for generating a communication code, which in this case is the CORBA code.
  • this CORBA code serves as a means of communication "transparent" between the test computer 1 and the local applications 2 and 3 subjected to tests.
  • This code is carried by a CORBA bus 100, through which transit distributed objects. These objects have been represented by symbols ORB1, ORB2 and ORB3, ORB4. These objects (or nuclei) are the transport vectors messages for transmitting CORBA calls made between the remote application 1 and the local applications 2 and 3, respectively.
  • ORB1, ORB2 and ORB3, ORB4 These objects (or nuclei) are the transport vectors messages for transmitting CORBA calls made between the remote application 1 and the local applications 2 and 3, respectively.
  • the Al and A2 calls in two directions, between the gateways 4 and 5 and the computers 2A and 3A respectively, are local calls, which are not, by hypothesis, in CORBA code.
  • step 7 the generator 'client' first initiates the generation (10) of a code allowing the call of the client code.
  • This code (11) overloads the client code 12 (relative to the stub of the client application and generated in step 18a, as described below), then by another client code (13) which is used to initialization of the CORBA mechanism, and compiled therewith, produces the client gateway 14 (such as the gateway 1a of FIG. 1).
  • This gateway 14 is then linked by a link editor of the client application 15 to the "business" part 16 of this application, in order to create the client executable.
  • the IDL generator generates (17) the interfaces (18) of all client and server (s) applications.
  • These interfaces 18 generate (18a) CORBA code, preferably by means of CORBA dedicated trade middleware (COTS), in the target language (that of the application intended to receive this code, and which may be Java, of C ++, ).
  • COTS CORBA dedicated trade middleware
  • the interfaces 18 generate the client code 12 mentioned above, and on the other hand, they generate a server code 20, which is the "skeleton" of the server application 19.
  • step 9 the generator 'server' generates (21) a server code (22) in the target language of the application 19.
  • This code 22 comprising the function calls of the application 19, overloads the code 20 , and is supplemented by a server code 23 (used for initializing the CORBA process).
  • the set is compiled to produce the server gateway 24.
  • This gateway 24 is then connected by a link editor from the server application 19 to the "business" part 25 of this application, in order to create the server executable.
  • the remote application invokes a first service that the server must perform.
  • the client gateway 29 queries the naming services.
  • the CORBA services proceed to the encoding ("marshalling" in English) of the data corresponding to the invoked service, transport the invocation thus encoded, decode this data, and invoke the real object corresponding to this service in the gateway server 28.
  • the server gateway 28 calls, in the system tested 27, the function relating to the invoked service.
  • the system tested 27 returns the response to the service invocation it has just received.
  • CORBA services encode the data, transport the invocation thus encoded to the client, decode the data and transmit it to the client gateway 29.
  • - EI l the gateway 29 transmits the invocation to the application 28 by calling the real code in this application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention est relative à 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, et elle 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.

Description

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, 3 A, 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 œuvre des processus identiques ou différents. Par exemple, le calculateur du système 2 peut mettre en œuvre un processus en code ADA, tandis que le calculateur du système 3 peut mettre en œuvre 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 ORBl, 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.
- ElO : 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. - EI l : la passerelle 29 transmet l'invocation à l'application 28 en appelant le vrai code dans cette application.

Claims

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.
EP05810944A 2004-10-27 2005-10-26 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 Withdrawn EP1805613A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0411447A FR2877116B1 (fr) 2004-10-27 2004-10-27 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
PCT/EP2005/055563 WO2006045814A1 (fr) 2004-10-27 2005-10-26 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

Publications (1)

Publication Number Publication Date
EP1805613A1 true EP1805613A1 (fr) 2007-07-11

Family

ID=34954579

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05810944A Withdrawn EP1805613A1 (fr) 2004-10-27 2005-10-26 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

Country Status (4)

Country Link
US (1) US20090049116A1 (fr)
EP (1) EP1805613A1 (fr)
FR (1) FR2877116B1 (fr)
WO (1) WO2006045814A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9804899B2 (en) * 2009-07-31 2017-10-31 Ixia Communications using the common object request broker architecture (CORBA)
US9830204B2 (en) * 2013-10-22 2017-11-28 Bae Systems Plc Facilitating communication between software components that use middleware

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4330665B2 (ja) * 1996-10-30 2009-09-16 株式会社リコー クライアントサーバシステムおよび画像処理装置
CA2210755C (fr) * 1997-07-17 2003-12-23 Ibm Canada Limited - Ibm Canada Limitee Creation de mandataires pour la distribution de « beans » et d'objets d'evenements
JP3597356B2 (ja) * 1997-10-20 2004-12-08 富士通株式会社 通信連携情報生成装置、３階層クライアント／サーバシステムおよび通信連携情報生成プログラムを記録した媒体
US6249803B1 (en) * 1997-12-18 2001-06-19 Sun Microsystems, Inc. Method and apparatus for executing code during method invocation
US6542908B1 (en) * 2000-03-22 2003-04-01 International Business Machines Corporation Technique for automatically and transparently transforming software components into software components capable of execution in a client/server computing environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006045814A1 *

Also Published As

Publication number Publication date
WO2006045814A1 (fr) 2006-05-04
FR2877116A1 (fr) 2006-04-28
US20090049116A1 (en) 2009-02-19
FR2877116B1 (fr) 2012-04-27

Similar Documents

Publication Publication Date Title
US8789073B2 (en) Proxy object creation and use
MXPA04002729A (es) Transmision y recepcion de mensajes a traves de un canal de comunicacion y modelo de programacion adaptable.
EP2561656A1 (fr) Api servlet et procédé pour protocole xmpp
US20130013734A1 (en) Information on Demand Process Framework Method to Generate, Manage, Secure, and Deploy Browsers and Applications Accessible Web Services
CN112015578B (zh) 基于事前同步处理和事后异步处理的风控系统和方法
CN109104368B (zh) 一种请求连接方法、装置、服务器及计算机可读存储介质
US7739389B2 (en) Providing web services from a service environment with a gateway
US8990286B2 (en) Integration of web services with a clustered actor based model
CN101977165A (zh) 云模式下的消息传输方法及消息总线系统
US10404826B2 (en) Content based routing architecture system and method
CN101339520A (zh) 一种将ejb接入企业服务总线的方法
WO2009056607A1 (fr) Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement
US8806512B2 (en) Collocation in a Java virtual machine of JSLEE, SIP servlets, and Java EE
CN103391294A (zh) 一种基于服务描述的远程方法调用
WO2006045814A1 (fr) 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
US20080065498A1 (en) Orchestration Engine as an Intermediary Between Telephony Functions and Business Processes
CN109597688A (zh) 在线资源管理方法、装置、存储介质及电子设备
CN110532115B (zh) 用于开发智能合约的系统、方法和装置
CN107995184B (zh) 一种连接器及使用该连接器通讯的方法
US20070143447A1 (en) Methods and systems for providing a structured application
JP2005143100A (ja) モバイル機器からｅｒｐにアクセスする方法
Pakkala et al. A generic communication middleware architecture for distributed application and service messaging
US9479599B2 (en) Reroute of a web service in a web based application
CN108418901A (zh) 基于php的高性能远程过程调用方法
WO2010060926A1 (fr) Procede et systeme pour la transformation de composants logiciel ccm en composant deployables dans un environnement compatible du standard sca

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070427

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080108

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120925