WO2006045814A1 - 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 Download PDF

Info

Publication number
WO2006045814A1
WO2006045814A1 PCT/EP2005/055563 EP2005055563W WO2006045814A1 WO 2006045814 A1 WO2006045814 A1 WO 2006045814A1 EP 2005055563 W EP2005055563 W EP 2005055563W WO 2006045814 A1 WO2006045814 A1 WO 2006045814A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
local
messaging architecture
code
conventional messaging
Prior art date
Application number
PCT/EP2005/055563
Other languages
English (en)
Inventor
François FERRE
Jérôme VIALLET
Original Assignee
Thales
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 filed Critical Thales
Priority to EP05810944A priority Critical patent/EP1805613A1/fr
Priority to US11/718,231 priority patent/US20090049116A1/en
Publication of WO2006045814A1 publication Critical patent/WO2006045814A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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.
PCT/EP2005/055563 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 WO2006045814A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05810944A 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
US11/718,231 US20090049116A1 (en) 2004-10-27 2005-10-26 System for calling for local services of at least one local application with a conventional messaging architecture from at least one remote application with a conventional messaging architecture

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
FR0411447 2004-10-27

Publications (1)

Publication Number Publication Date
WO2006045814A1 true WO2006045814A1 (fr) 2006-05-04

Family

ID=34954579

Family Applications (1)

Application Number Title Priority Date Filing Date
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

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)
CA2928316C (fr) * 2013-10-22 2021-12-21 Bae Systems Plc Facilitation de la communication entre des composants logiciels utilisant un intergiciel

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6230160B1 (en) * 1997-07-17 2001-05-08 International Business Machines Corporation Creating proxies for distributed beans and event objects
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

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4330665B2 (ja) * 1996-10-30 2009-09-16 株式会社リコー クライアントサーバシステムおよび画像処理装置
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6230160B1 (en) * 1997-07-17 2001-05-08 International Business Machines Corporation Creating proxies for distributed beans and event objects
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 (3)

* Cited by examiner, † Cited by third party
Title
"Cigee C/C++->CORBA: A generator for CORBA components from legacy C++ code", 7 April 2004 (2004-04-07), b-novative Hompebage, XP002339245, Retrieved from the Internet <URL:http://web.archive.org/web/20040407145343/http://www.b-novative.com/products/cigee/cpp_corba/cigee_cpp_corba.html> [retrieved on 20050804] *
OBJECT MANAGEMENT GROUP: "CORBA Specification", COMMON OBJECT REQUEST BROKER: ARCHITECTURE AND SPECIFICATION, July 1995 (1995-07-01), XP002157374 *
TEINIKER E ET AL: "Local components and reuse of legacy code in the CORBA component model", EUROMICRO CONFERENCE, 2002. PROCEEDINGS. 28TH SEPT. 4-6, 2002, PISCATAWAY, NJ, USA,IEEE, 4 September 2002 (2002-09-04), pages 4 - 9, XP010612121, ISBN: 0-7695-1787-0 *

Also Published As

Publication number Publication date
FR2877116A1 (fr) 2006-04-28
FR2877116B1 (fr) 2012-04-27
US20090049116A1 (en) 2009-02-19
EP1805613A1 (fr) 2007-07-11

Similar Documents

Publication Publication Date Title
US8789073B2 (en) Proxy object creation and use
CN108449418A (zh) 一种混合云平台管理系统及方法
US8332524B2 (en) Information on demand process framework to generate, manage, secure, and deploy browsers and application accessible web services
US8032894B2 (en) Service bus architecture
CN103580937A (zh) 一种Web 服务模拟的方法及其系统和服务代理系统
CN103001815B (zh) 测试数据的获取方法、装置及系统
MXPA04002729A (es) Transmision y recepcion de mensajes a traves de un canal de comunicacion y modelo de programacion adaptable.
WO2011133471A1 (fr) Api servlet et procédé pour protocole xmpp
CN110380919A (zh) 区块链请求的处理方法、装置、电子设备及可读存储介质
US7940916B2 (en) Orchestration engine as an intermediary between telephony functions and business processes
CN109104368A (zh) 一种请求连接方法、装置、服务器及计算机可读存储介质
CN109451014A (zh) 一种WebService代理系统及其透明代理方法
CN112015578A (zh) 基于事前同步处理和事后异步处理的风控系统和方法
CN101977165A (zh) 云模式下的消息传输方法及消息总线系统
US20050114437A1 (en) Providing web services from a service environment with a gateway
US8990286B2 (en) Integration of web services with a clustered actor based model
US8200749B2 (en) Data processing method for generating service interface descriptions
CN108876608B (zh) 一种区块链应用方法及系统
Hellerstein et al. ETE: A customizable approach to measuring end-to-end response times and their components in distributed systems
CN103391294A (zh) 一种基于服务描述的远程方法调用
EP1805613A1 (fr) Systeme d&#39;appel de services locaux d&#39;au moins une application locale a architecture de messagerie classique a partir d&#39;au moins une application distante a architecture de messagerie classique
EP2208134A1 (fr) Systeme pour le deploiement de composants logiciels sur des unites de calcul limitees en capacite de traitement
US20170353581A1 (en) Content based routing architecture system and method
US8806512B2 (en) Collocation in a Java virtual machine of JSLEE, SIP servlets, and Java EE
US7165118B2 (en) Layered message processing model

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV LY MD MG MK MN MW MX MZ NA NG NO NZ OM PG PH PL PT RO RU SC SD SG SK SL SM SY TJ TM TN TR TT TZ UG US UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SZ TZ UG ZM ZW AM AZ BY KG MD RU TJ TM AT BE BG CH CY DE DK EE ES FI FR GB GR HU IE IS IT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11718231

Country of ref document: US

Ref document number: 2005810944

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005810944

Country of ref document: EP