FR2853974A1

FR2853974A1 - Procede de generation d'une interface de communication a distance pour des informations basees sur un cadre de description de ressources (rdf)

Info

Publication number: FR2853974A1
Application number: FR0404048A
Authority: FR
Inventors: Richard Friedman; Joseph J Snyder; Jason A Kinner
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2003-04-17
Filing date: 2004-04-16
Publication date: 2004-10-22
Also published as: US20040210914A1

Abstract

La spécification peut décrire un procédé de lecture, par un programme compilateur (20), d'une source d'entrée basée sur un cadre de description de ressources (RDF) (22, 24), génération d'une mise en oeuvre (26) par le compilateur pour accéder aux informations codées en se basant sur le modèle de RDF, et génération d'une interface (16, 18) pour permettre l'accès à distance aux informations codées basées sur le modèle de RDF sur un parmi plusieurs systèmes et/ou protocoles possibles.

Description

CONTEXTE

Un cadre de description de ressources (RDF),

tel que défini par le World Wide Web Consortium (W3C), peut être un modèle pour stocker des informations. Plus 5 particulièrement, le modèle de RDF peut être conçu pour stocker des informations concernant des informations, des METADATA. Dans le modèle RDF, les METADATA sont regroupées en utilisant un triplet logique. Dans sa forme la plus simple, le triplet peut comprendre un 10 sujet, un prédicat et un objet. Par exemple, l'énoncé "Leslie a 34 ans" peut être divisé en le triplet: sujet = Leslie, prédicat = âge, et objet = "34". Ainsi, le prédicat qui relie le sujet "Leslie" à l'objet "34" peut être la propriété 'âge'. En termes plus 15 techniques, le triplet du modèle de RDF peut être défini par une ressource (sujet), une propriété (prédicat) et un objet. Bien que dans l'exemple simple fourni ci-dessus, la ressource était "Leslie", dans le modèle de RDF, une ressource peut être un élément 20 quelconque auquel on peut affecter un Universal Resource Identifier (Identifiant Universel de Ressources) (URI). Un exemple de la ressource à laquelle on peut affecter un URI est un document posté sur le World Wide Web. Un document avec un URI peut 25 être aussi simple qu'une image numérique, ou peut être aussi complexe qu'une série de commandes lues par un navigateur Web pour créer une page Web consultable.

Le modèle de RDF peut ne pas définir des propriétés ou prédicats; en remplacement, le modèle de 30 RDF peut définir uniquement la relation du stockage de METADATA sous la forme d'un triplet. Ainsi, la population générale peut être libre de définir une série quelconque de propriétés pouvant être appropriées pour leur genre de sujets particulier. Chacun de ces ensembles de propriétés définies peut être appelé schéma, schéma de RDF ou "espace de nom".

Bien que la population générale puisse être libre de définir des schémas de RDF, il existe des 5 schémas définis précédemment et disponibles publiquement pour des ressources particulières. Par exemple, une organisation a créé le schéma de METADATA "Dublin Core", orienté vers les propriétés de document Internet, tels que des documents Web consultables avec 10 un navigateur Web, des images postées sur le Web, et analogue. Le schéma de "Dublin Core" peut définir quinze propriétés, telles que le titre, l'auteur, le diffuseur, un autre agent (tel que des éditeurs, transcripteurs ou illustrateurs ayant effectué une 15 contribution intellectuelle significative), la date, le type d'objet et analogue. Toutefois, d'autres schémas peuvent être créés, dans lesquels des propriétés, bien qu'étant apparemment les mêmes, ont des significations différentes. Ainsi, par exemple, selon le schéma de 20 "Dublin Core", 'Date' peut avoir une signification particulière, à savoir, la date de publication. Dans d'autres schémas, 'Date' peut être définie selon d'autres manières, par exemple la date de création de l'oeuvre.

Le modèle de RDF, ainsi que les divers schémas qui ont été produits ou peuvent être produits, peuvent ne pas être un langage de programmation. En remplacement, les informations de MEDATA peuvent être codées en "extensible Markup Language" (XML). Pour que 30 les METADATA soient utiles, les programmes d'utilisateur peuvent devoir accéder aux METADATA. Par exemple, un programme de moteur de recherche peut devoir rechercher dans l'ensemble des METADATA pour tenter d'identifier un document basé sur des critères 35 de recherche. Dans certains cas, les METADATA, codées dans un cadre de RDF, peuvent être disponibles sur la même machine que le moteur de recherche. Toutefois, dans d'autres cas, les METADATA peuvent résider à une certaine distance physique ou logique, que ce soit sur 5 le même ordinateur ou sur un ordinateur situé dans une autre partie du monde. Ainsi, ce qui peut être nécessaire dans la technique est un aménagement de communication pour accéder aux METADATA.

RÉSUMÉ DE CERTAINS DES MODES DE RÉALISATION PRÉFÉRÉS Les problèmes indiqués ci-dessus peuvent être résolus en grande partie par un procédé qui peut comprendre la lecture d'une source d'entrée basée sur un cadre de description de ressources (RDF) par un 15 premier compilateur, la génération d'une interface de programme d'application (API) basée sur la source d'entrée de RDF par le premier compilateur, et la génération d'au moins une partie d'une interface de communication à distance par un second compilateur, 20 pour permettre un accès à distance à l'API.

D'autres modes de réalisation de l'invention peuvent comprendre un support lisible par un ordinateur comprenant un programme exécutable adapté à exécuter des tâches telles que la lecture d'une source d'entrée 25 s'appuyant sur un RDF, la génération d'une liste de fonctions agissant sur les propriétés de la source d'entrée s'appuyant sur un RDF, la génération d'un ensemble de mises en oeuvre basées sur les propriétés de la source d'entrée s'appuyant sur un RDF et la 30 génération d'au moins une partie d'une interface de communication à distance pour permettre un accès à distance aux mises en oeuvre.

BRÈVE DESCRIPTION DES DESSINS Pour une description détaillée des modes de réalisation de l'invention, il va maintenant être fait référence aux dessins annexés, dans lesquels: la figure 1 peut illustrer, sous forme de schéma par blocs, l'interaction effective entre un client distant et un serveur selon des modes de réalisation de l'invention; la figure 2 peut illustrer un schéma par 10 blocs plus détaillé des composants dans une communication client/serveur selon des modes de réalisation de l'invention i la figure 3 peut illustrer l'interaction des divers composants pour être utilisée avec "Enterprise 15 JavaBeansTM,", en tant que système de communication à distance, selon des modes de réalisation de l'invention; la figure 4 peut illustrer l'interaction des divers composants pour être utilisée avec un système 20 "Common Object Broker Architecture" (CORBA), en tant que système de communication à distance, selon des modes de réalisation de l'invention; et la figure 5 peut illustrer l'interaction des divers composants pour être utilisée avec un "Simple 25 Object Access Protocol" (SOAP), selon des modes de réalisation de l'invention.

NOTATION ET NOMENCLATURE

Certains termes sont utilisés dans l'ensemble 30 de la description et des revendications qui suivent pour se référer à des composants de systèmes particuliers. Comme le comprendra un homme de l'art, les entreprises d'informatique et de logiciels peuvent se référer à un composant par des noms différents. Ce 35 document n'a pas pour but de faire la distinction entre des composants dont les noms diffèrent, mais pas la fonction. Dans l'explication et dans les revendications qui suivent, les termes "comportant" et "comprenant" sont utilisés d'une façon ouverte et ainsi, doivent 5 être interprétés comme signifiant "comportant, mais sans y être limité...".

DESCRIPTION DÉTAILLÉE

La description suivante est orientée vers 10 divers modes de réalisation de l'invention. Bien qu'un ou plusieurs de ces modes de réalisation puissent être préférés, les modes de réalisation décrits ne doivent pas être interprétés ou par ailleurs utilisés comme limitant la portée de la description, y compris des 15 revendications, sauf spécification contraire. De plus, un homme de l'art comprendra que la description qui suit a une application large et l'explication d'un mode de réalisation quelconque n'est destinée qu'à être un exemple de ce mode de réalisation et n'est pas destinée 20 à suggérer que la portée de la description, y compris les revendications, est limitée à ce mode de réalisation.

Les modes de réalisation de la présente invention peuvent être orientés vers l'interopérabilité 25 logicielle sous-jacente pour l'accès par des applications distantes (physiquement ou logiquement) à des METADATA codées sous le modèle de RDF. La figure 1 peut illustrer, sous forme d'un schéma par blocs à haut niveau, l'interaction effective entre un exemple 30 d'application distante (application financière 10) et ses METADATA d'informations de compte cible 12. Avant de poursuivre, on comprendra que l'application financière illustrée sur la figure 1 peut être uniquement un simple exemple des systèmes possibles 35 pour utiliser les modes de réalisation de l'invention, et ainsi, ne doit pas être considérée comme limitant le caractère applicable des modes de réalisation de l'invention. Dans le système de la figure 1, l'application financière 10 peut accéder aux 5 informations de compte 12 sur un réseau de communication 11, tel que le "World Wide Web", comme illustré par une ligne en tirets 14.

La figure 2 peut illustrer un schéma par blocs plus détaillé des modes de réalisation de la 10 présente invention. En particulier, bien que l'exemple d'application financière 10 puisse effectivement communiquer avec les informations de compte 12, comme illustré par la ligne en tirets 14, il peut être nécessaire que la communication traverse plusieurs 15 couches de systèmes et/ou protocoles, par exemple, dans une communication client/serveur. Au sens large, l'application distante, par exemple l'application financière 10, peut faciliter la communication désirée à travers un squelette 16. Comme le nom peut 20 relativement le suggérer, le squelette 16 peut constituer un cadre pour la communication. Les squelettes 16 pouvant être utilisés dans les modes de réalisation de l'invention sont présentés ci-dessous plus complètement.

Toujours en référence à la figure 2, dans des modes de réalisation de l'invention, le squelette 16 peut faciliter la communication de l'application distante par communication avec une interface 18, qui peut elle-même accéder à des informations dans les 30 METADATA codées sous le modèle RDF, METADATA s'appuyant sur le RDF. Dans le système illustré sur la figure 2, les METADATA s'appuyant sur le RDF peuvent être les informations de compte 12, et l'interface 18 peut constituer l'interface pour l'objet compte. Les 35 METADATA s'appuyant sur le RDF (par exemple, les informations de compte 12) et l'interface 18 peuvent constituer ensemble ce qui est appelé un "tronçon" 19.

Ainsi, les applications à distance peuvent accéder à des informations au moyen de squelettes et de tronçons.

La demande en cours de numéro de série déposée le et intitulée, "METHOD OF GENERATING AN APPLICATION PROGRAM INTERFACE FOR RESOURCE DESCRIPTION FRAMEWORK (RDF) BASED INFORMATION", (No. de référence client 100203208-1 (No. de registre du mandataire 216210 04500)), qui est attribuée en commun avec cette spécification, peut présenter un compilateur de RDF prenant comme entrée un document source à base de RDF et peut produire une interface de programme d'application (API) et une mise en oeuvre associées, 15 toutes deux pouvant être sous forme de langage natif. À partir de l'API et de la mise en oeuvre, les programmeurs (et les applications qu'ils créent) peuvent ainsi accéder aux METADATA dans des sources de METADATA s'appuyant sur le RDF. Toutefois, dans les cas 20 o les applications distantes peuvent devoir accéder à des sources de METADATA s'appuyant sur le RDF, il peut y avoir une nécessité pour une abstraction supplémentaire pour faciliter la communication.

En se référant maintenant à la figure 3, des 25 modes de réalisation de l'invention plus spécifiques peuvent être illustrés. En particulier, les modes de réalisation de l'invention peuvent comprendre un compilateur de RDF 20, qui peut être un programme exécutable programmé dans un langage de programmation 30 disponible quelconque. Le compilateur 20 peut être conçu et codé de façon qu'il prenne comme données d'entrées une source d'entrée de RDF, telle qu'un schéma de RDF 22 ou un document de METADATA s'appuyant sur le RDF 24. À partir d'une ou plusieurs de ces 35 sources d'entrées, le compilateur 20 peut produire une API 26 à partir des propriétés de RDF définies dans la source d'entrée, et peut également produire un ensemble de mises en oeuvre de langage natif 28. Pour une description plus détaillée de cet aspect des modes de 5 réalisation de l'invention, il peut être fait référence au brevet indiqué ci-dessus, intitulé "METHOD OF

GENERATING IMPLEMENTATIONS FOR RESOURCE DESCRIPTION

FRAMEWORK (RDF) BASED INFORMATION".

Dans divers modes de réalisation de 10 l'invention, le compilateur 20 peut ainsi créer une partie du tronçon 19 (en particulier, l'interface 18) (figure 2), et peut également produire au moins une partie d'un squelette 16. En se référant de nouveau à la figure 3, le compilateur 20 des modes de réalisation 15 de l'invention peut, outre la génération d'une API 26 et de la mise en oeuvre 28, produire dans au moins certains modes de réalisation, un objet "Enterprise JavaBeansTM,, (EJB) 30. L'EJB peut être une technologie de composant logiciel pour création de systèmes. Plutôt 20 qu'un programmeur démarre avec une page vierge, code un système complet, puis débogue ce système, l'EJB peut permettre au programme de réunir des "composants" logiciels précédemment écrits et testés pour exécuter la tâche désirée. L'EJB peut également être une 25 technologie de composant source ouverte, permettant ainsi l'intégration de composants tiers pour former un système global. Un tel système de développement logiciel réduit ainsi le temps global de développement et de test. Pour obtenir davantage d'informations 30 concernant l'EJB, il peut être fait référence au projet final proposé "Enterprise JavaBeansTM", disponible à http://java.sun.com/products/ejb/docs.html.

Toujours en référence à la figure 3, dans au moins certains modes de réalisation de l'invention, le 35 compilateur 20 peut créer un objet EJB à base de langage Java 30, pouvant faire partie du squelette 16.

À partir de l'objet EJB, le système EJB peut créer la mise en oeuvre EJB 32. La combinaison de l'objet EJB 30 et de la mise en oeuvre EJB 32 peut ainsi former le 5 squelette 16, par l'intermédiaire duquel une application distante s'appuyant sur EJB, telle que, mais sans y être limité, une application financière 10, peut communiquer vers un tronçon 19.

Comme expliqué dans le brevet attribué en 10 commun indiqué ci-dessus, le compilateur 20 peut produire l'API en langage natif 26 et la mise en oeuvre en langage natif 28 dans un quelconque parmi une diversité de langages de programmation non connus ou créés ultérieurement. Ces langages peuvent inclure, 15 mais sans y être limité, Java, C++, C# (C sharp), et analogue. L'objet EJB 30 peut être créé par le compilateur 20 en Java. Ainsi, on peut utiliser pour produire l'API en langage natif 26, la mise en oeuvre en langage natif 28 et l'objet EJB en langage Java 30, 20 soit un simple compilateur 20, soit des compilateurs différents (par exemple, lorsque les composants du tronçon en langage natif 19 utilisent un langage autre que Java). L'API 26 et la mise en oeuvre 28, une fois compilées, peuvent donner accès aux METADATA s'appuyant 25 sur le RDF 24 par l'application distante par l'intermédiaire du système EJB.

En se référant maintenant à la figure 4, d'autres modes de réalisation de la présente invention peuvent être présentés. En particulier, la figure 4 30 peut présenter les METADATA s'appuyant sur le RDF 24 ou le schéma de RDF 22 comme source d'entrée vers le compilateur 20. Le compilateur peut ainsi créer l'API en langage natif 26 et la mise en oeuvre en langage natif 28. Le compilateur 20 peut également créer des 35 parties du squelette 16, en particulier un document de contrôle à base de "Common Object Request Broker Architecture" (CORBA) 34, pouvant être dans un format "Interface Definition Language" (IDL). La CORBA, beaucoup plus que l'EJB, peut être un système basé sur 5 une technologie de composant pour communication de données vers et depuis des clients et des objets. Bien que dans certains cas les clients et les objets puissent résider sur le même ordinateur, la norme peut permettre de façon transparente une communication sur 10 des distances physiques ou logiques. Pour obtenir davantage d'informations concernant la norme CORBA, il peut être fait référence à la spécification CORBA, disponible à http://www.omg. org/technology/documents/formal/corba_2. 15 htm.

Dans la partie appropriée des modes de réalisation de la présente invention, le côté objet (serveur) dans un système conforme à CORBA, peut définir des services et des informations disponibles 20 par un document de contrôle CORBA en IDL. IDL peut être une interface fonctionnelle indépendante du langage de programmation. Le protocole de communication sousjacent pour un système CORBA peut être un protocole InternetInterORB (IIOP), bien que les systèmes basés 25 sur CORBA soient obligatoirement limités à ce protocole. D'après le document de contrôle CORBA en IDL, le système CORBA peut produire une mise en oeuvre CORBA basée sur Java pour le transport de messages.

Dans des modes de réalisation de la présente invention, 30 et en se référant à la figure 4, le compilateur 20 peut produire un document de contrôle CORBA en IDL 34, en se basant sur sa source d'entrée, par exemple un schéma de RDF 22 ou des METADATA s'appuyant sur le RDF 24. Le système CORBA sous-jacent peut ensuite produire la mise 35 en oeuvre CORBA à base de Java 36 pour faciliter la Il communication depuis un client, tel qu'une application financière 10. Le compilateur 20 peut avoir la fonctionnalité requise pour produire les composants en langage natif ainsi que le document IDL, ou un second compilateur peut être utilisé.

En se référant maintenant à la figure 5, d'autres modes de réalisation de la présente invention peuvent être présentés. En particulier, la figure 5 peut représenter les METADATA s'appuyant sur le RDF 24 10 ou le schéma de RDF 22, comme source d'entrée vers le compilateur 20. Le compilateur peut ainsi créer l'API en langage natif 26 et la mise en oeuvre en langage natif 28. Le compilateur 20 peut également créer des parties du squelette 16, en particulier l'interface 15 Simple Object Access Protocol (SOAP) 38, basée sur ses sources d'entrée. Le SOAP peut être un protocole à base de messages pour l'échange d'informations entre les clients et les objets (entre des homologues en terminologie SOAP). Pour d'autres informations 20 concernant le SOAP, il peut être fait référence à la spécification SOAP disponible à http://www.w3.org/TR/SOAP.

Ainsi, des modes de réalisation de la présente invention, en particulier le compilateur 20, 25 peuvent produire l'interface SOAP 38, en format XML. Un serveur SOAP (non représenté sur la figure 5) lit l'interface SOAP 38 et agit effectivement pour mettre en oeuvre un accès à distance en appelant les API appropriées 26 (et ainsi, leur mise en oeuvre 28) en se 30 basant sur les requêtes fournies au serveur SOAP depuis les clients distants. Ainsi, des systèmes distants, tels qu'une application financière 10, peuvent communiquer avec les METADATA s'appuyant sur le RDF 24, quel que soit le type de système distant mis en oeuvre 35 en utilisant le protocole SOAP.

L'explication ci-dessus est destinée à illustrer les principes et divers modes de réalisation de la présente invention. Un grand nombre de variantes et de modifications apparaîtront aux hommes de l'art 5 après compréhension complète de la description cidessus. Il est voulu que les revendications suivantes soient interprétées comme englobant toutes ces variantes et modifications.

Claims

R E V E N D I C A T I O N S

1. Procédé comprenant: la lecture d'une source d'entrée (22, 24) basée sur un cadre de description de ressources (RDF), par un premier compilateur (20) ; la génération d'une interface de programme d'application (API) (26) basée sur la source d'entrée à base de RDF (22, 24) par le premier compilateur (20) ; et la génération d'au moins une partie d'une interface de communication à distance (16, 18) par un second compilateur pour permettre l'accès à distance à l'API (26).

2. Procédé selon la revendication 1, dans lequel la génération d'au moins une partie d'une interface de communication à distance comprend en outre, la génération d'un fichier objet Enterprise JavaBeansTM (30).

3. Procédé selon la revendication 1, dans lequel la génération d'au moins une partie d'une interface de communication à distance comprend en outre, la génération d'un document Common Object Request Broker 25 Architecture (CORBA) en langage de définition d'interface (IDL) (34).

4. Procédé selon la revendication 1, dans lequel la génération d'au moins une partie d'une interface de 30 communication à distance comprend en outre, la génération d'une interface Simple Object Access Protocol (SOAP) (38) en extensible Markup Language (XML).

5. Procédé selon la revendication 1, dans lequel la génération de l'API par le premier compilateur comprend, en outre, la génération d'une API en langage natif C++ (26) par le premier compilateur (20).

6. Procédé selon la revendication 1, dans lequel la génération de l'API par le premier compilateur comprend, en outre, la génération d'une API en langage natif C# (26) par le compilateur (20).

7. Support lisible par un ordinateur comprenant un programme exécutable, le programme exécutable étant adapté à exécuter des tâches lorsqu'il est exécuté, comprenant: la lecture d'une source d'entrée s'appuyant sur un cadre de description de ressources (RDF) (22, 24) ; la génération d'une liste de fonctions (26) agissant sur les propriétés de la source d'entrée s'appuyant sur le RDF (22, 24) ; la génération d'un ensemble de mises en oeuvre (28) basées sur les propriétés de la source d'entrée s'appuyant sur le RDF (22, 24) ; et la génération d'au moins une partie d'une interface de communication à distance (16, 18) pour 25 permettre un accès à distance aux mises en oeuvre (28).

8. Support lisible par un ordinateur selon la revendication 7, dans lequel la génération d'au moins une partie d'une interface de communication à distance 30 pour permettre un accès à distance aux tâches de mises en oeuvre de la tâche de programme exécutable comprend en outre, la génération d'un fichier objet Enterprise JavaBeansTM (30) pour permettre l'accès à distance aux mises en oeuvre (28).

9. Support lisible par un ordinateur selon la revendication 7, dans lequel la génération d'au moins une partie d'une interface de communication à distance pour permettre un accès à distance aux tâches de mises 5 en oeuvre de la tâche de programme exécutable comprend en outre, la génération d'un document Common Object Request Broker Architecture (CORBA) en langage de définition d'interface (IDL) (34) pour permettre l'accès à distance aux mises en oeuvre (28).

10. Support lisible par un ordinateur selon la revendication 7, dans lequel la génération d'au moins une partie d'une interface de communication à distance pour permettre un accès à distance aux tâches de mises 15 en oeuvre de la tâche de programme exécutable comprend en outre, la génération d'une interface Simple Object Access Protocol (SOAP) (38) en extensible Markup Language (XML) pour permettre l'accès à distance aux mises en oeuvre (28).