CORBA rencontre Java

Nous avons tous accédé à des sites Web qui nous permettent d'interagir avec un script serveur via l'utilisation de formulaires HTML et de la Common Gateway Interface (CGI). Les sites utilisent souvent cette technique pour inviter une personne à entrer un nom d'utilisateur et un mot de passe pour se connecter à un site. Les variables Username et Password sont transmises à un script serveur qui vérifie qu'un utilisateur donné peut effectivement accéder à certaines parties d'un site. Ce processus se fait via HTTP, qui (comme vous le savez ou non) est un état sans étatprotocole. Chaque fois qu'une nouvelle page est chargée, vous êtes effectivement déconnecté du serveur et il n'a aucune connaissance de qui vous êtes et de ce que vous faites actuellement. Ainsi, même après s'être connecté à un tel site, chaque page accédée à partir de ce point doit renvoyer le nom d'utilisateur et le mot de passe au serveur pour vérifier le droit de l'utilisateur d'accéder à la page. En d'autres termes, votre application cliente (le navigateur Web) et l'application serveur (le serveur Web) n'ont aucune notion de variables locales, d'appels de méthodes locales ou d'objets.

Juste après la lutte de plusieurs décennies de la communauté des développeurs de logiciels pour encapsuler le code alors que les objets semblaient enfin réussir, nous nous sommes retrouvés à reculer dans le temps vers un mode de calcul apatride et «par lots».

Cependant, ce n'est pas tout mauvais. Le Web nous a fourni les avantages révolutionnaires des protocoles ouverts basés sur des normes et de l'indépendance de la plateforme. Alors que des dizaines de milliers de sites utilisent HTTP et CGI pour récupérer des informations utilisateur, exécuter un script sur le serveur et éventuellement renvoyer des informations supplémentaires à l'utilisateur, ces sites ne peuvent pas être considérés comme de véritables «applications», au sens traditionnel du terme . De plus, tout le code de ces sites a dû être écrit à partir de zéro en raison des nouvelles technologies utilisées (HTTP et CGI). Pour mettre à niveau des applications logicielles existantes sur le Web ou pour créer de nouvelles applications vraiment puissantes en utilisant Internet / intranet comme épine dorsale de communication, il faut utiliser une technologie qui possède les attributs suivants: «Saint Graal»:

  • Prise en charge du code hérité actuellement existant en C, C ++ et COBOL (entre autres langages)
  • Prise en charge de Java afin de permettre la création d'applications mobiles, indépendantes de la plate-forme et orientées objet
  • Neutralité du fournisseur, afin que les applications puissent être maintenues et prospérer au fil du temps
  • Évolutivité pour gérer un grand nombre d'utilisateurs
  • Prise en charge large de la plateforme pour éviter le «verrouillage»
  • Un paradigme de développement orienté objet (en raison des nombreux avantages inhérents à la POO)
  • Sécurité de bout en bout
  • Large soutien à l'industrie

Entrez CORBA.

Au cours de cet article, vous verrez qu'une seule technologie, CORBA, répond vraiment à notre liste de souhaits (et plus encore). De plus, vous verrez que, comme Java et CORBA sont des technologies très complémentaires, vous pouvez rapidement et à moindre coût commencer le développement CORBA en Java.

Une brève introduction à CORBA

CORBA est une spécification qui définit comment les objets distribués peuvent interagir. Jusqu'à l'explosion de popularité du World Wide Web, et en particulier du langage de programmation Java, CORBA était essentiellement une solution d'objets distribués haut de gamme principalement utilisée par les développeurs C ++.

La spécification CORBA actuelle est contrôlée par l'Object Management Group (OMG), un consortium ouvert de plus de 700 entreprises (y compris mon employeur) qui travaillent ensemble pour définir des normes ouvertes pour l'informatique d'objets. Les objets CORBA peuvent être écrits dans n'importe quel langage de programmation pris en charge par un fabricant de logiciels CORBA tel que C, C ++, Java, Ada ou Smalltalk. Ces objets peuvent également exister sur toute plate-forme prise en charge par un fabricant de logiciels CORBA, comme Solaris, Windows 95 / NT, OpenVMS, Digital Unix, HP-UX et AIX, entre autres. Cela signifie que nous pourrions avoir une application Java exécutée sous Windows 95 qui charge et utilise dynamiquement des objets C ++ stockés sur Internet sur un serveur Web Unix.

L'indépendance du langage est rendue possible grâce à la construction d'interfaces avec des objets à l'aide du langage de description d'interface (IDL). IDL permet à tous les objets CORBA d'être décrits de la même manière; la seule exigence est un "pont" entre le langage natif (C / C ++, COBOL, Java) et IDL. Les objets CORBA communiquent entre eux en utilisant un ORB (Object Request Broker) comme intermédiaire et peuvent communiquer via de nombreux protocoles réseau courants (tels que TCP / IP ou IPX / SPX). Les ORB de différents fournisseurs communiquent via TCP / IP à l'aide du protocole Internet Inter-Orb (IIOP), qui fait partie de la norme CORBA 2.0 (la dernière version).

Actuellement, des ORB tiers sont disponibles pour les langages de programmation les plus courants (notamment C ++, Smalltalk, Java et Ada95). Alors que d'autres langages gagnent en popularité, les fournisseurs de CORBA publieront sans aucun doute des ORB pour ces langages.

L'OMG a initialement défini l'architecture de gestion d'objets (OMA) en 1990 pour décrire comment les applications pouvaient interopérer. En tant que sous-ensemble de cet objectif, une norme devait être définie pour articuler comment les pièces, ou objets, au sein des applications pourraient interopérer - d'où la naissance de CORBA. L'OMA définit quatre parties principales pouvant constituer une installation CORBA:

  1. L' Object Request Broker agit comme un bus logiciel pour l'intercommunication des objets.
  2. CORBAServices définissent les services au niveau du système qui sont ajoutés à l'ORB, tels que la sécurité, la dénomination et les transactions.
  3. Les CORBAFacilities définissent des services au niveau de l'application, tels que des documents composés et d'autres fonctions verticales.
  4. Les objets métier décrivent des objets et des applications du monde réel, tels qu'un avion ou un compte bancaire.

Travaux pratiques: développement CORBA en Java

Pour créer une applet Java distribuée qui accède aux objets serveur en utilisant CORBA, nous utiliserons un ORB commercial populaire et utiliserons l'IDL pour définir des interfaces avec nos objets. le

Ressources

La section à la fin de cet article fournit les coordonnées de plusieurs fournisseurs CORBA populaires. Pour l'exemple d'applet que nous allons construire, j'ai choisi d'utiliser le Visigenic VisiBroker pour Java. Cet ORB a été concédé sous licence par plusieurs sociétés différentes, notamment Oracle, Netscape et Novell, et est inclus avec Netscape Navigator 4.0.

Remarque: vous pouvez exécuter cette applet dans un navigateur autre que Netscape Navigator 4.0. L'applet démarrera un peu plus lentement car plusieurs fichiers de classe Java supplémentaires doivent être téléchargés sur le client.

Nous allons construire une applet Java simple qui instancie un objet serveur en utilisant CORBA. Par souci de simplicité, cet objet serveur sera également écrit en Java. L'objet serveur stockera un tableau d'informations sur divers fournisseurs CORBA ORB et leurs produits. L'applet client instanciera l'objet et interrogera le tableau afin de mettre à jour l'écran. Un exemple plus complet (et celui que je vous encourage à considérer) serait de stocker les informations ORB dans une base de données relationnelle et d'utiliser JDBC (ou un autre moyen d'accès à la base de données) sur le serveur pour récupérer les informations demandées. Cette approche créerait une véritable application à trois niveaux utilisant CORBA.

Avant de commencer la construction de l'application, nous examinerons plus en détail l'ORB et l'IDL utilisés pour définir l'interface avec l'objet.

L'Object Request Broker en détail

L'élément le plus important de l'architecture de gestion d'objets est l'ORB. L'ORB est la seule partie de CORBA qui doit être présente pour créer une application compatible CORBA. De nombreux ORB sont livrés sans aucun des services CORBAS ni des installations CORBAF, et vous devez créer (ou acheter) vous-même les objets métier. Cependant, sans l'ORB, une application CORBA ne peut pas fonctionner.

La fonction la plus visible d'un ORB CORBA est de répondre aux demandes de votre application ou d'un autre ORB. Pendant le cycle de vie de votre application CORBA en cours d'exécution, votre ORB peut être invité à faire de nombreuses choses différentes, notamment:

  • Rechercher et instancier des objets sur des machines distantes
  • Marshal les paramètres d'un langage de programmation (tel que C ++) vers un autre langage (tel que Java)
  • Gérez la sécurité à travers les limites locales de votre machine
  • Récupérer et publier des métadonnées sur des objets sur le système local pour un autre ORB
  • Invoquer des méthodes sur un objet distant à l'aide de l'invocation de méthode statique décrite par un stub téléchargé
  • Invoquer des méthodes sur un objet distant à l'aide de l'appel de méthode dynamique
  • Démarrer automatiquement les objets qui ne sont pas actuellement opérationnels
  • Acheminer les méthodes de rappel vers l'objet local approprié qu'il gère

L'avantage de l'ORB est que presque tous les détails de mise en œuvre de toutes ces tâches sont cachés au développeur de logiciels. Fournir simplement les «crochets» appropriés dans votre code pour initialiser l'ORB et enregistrer votre application auprès de l'ORB ouvre votre application à une vaste galaxie d'objets distribués.

Décrire des objets à l'aide de l'IDL

Pour que CORBA conserve sa position indépendante du fournisseur et du langage, il doit y avoir un intermédiaire entre le code serveur C ++ CORBA, par exemple, et un client Java CORBA. Cet intermédiaire, comme vous le savez, est l'IDL. Les méthodes et propriétés associées prises en charge par un objet sous-jacent sont regroupées dans une seule interface à l'aide d'IDL. Une fois l'interface IDL terminée, elle peut être compilée dans la langue de votre choix sous la forme de code de stub et de squelette. Les compilateurs IDL sont inclus avec tous les ORB. Par exemple, un compilateur Java / IDL est inclus avec l'ORB Visigenic VisiBroker pour Java, tandis qu'un compilateur C ++ / IDL est inclus avec l'ORB Visigenic VisiBroker pour C ++.

Notez qu'il est beaucoup plus facile de travailler avec IDL qu'avec un langage de programmation orienté objet standard car IDL ne peut pas être utilisé pour spécifier l'implémentation réelle des classes ou des méthodes qu'elles contiennent. Au lieu de cela, IDL est utilisé uniquement pour décrire l' interface avec les objets sous-jacents.

Après avoir lu cette section, vous serez suffisamment familiarisé avec la langue pour comprendre les exemples présentés plus loin dans l'article. Pour une présentation plus approfondie sur l'IDL, visitez le site Web d'OMG. (Voir la section Ressources ci-dessous.)

Just as properties and methods are grouped together into related classes in Java, these items are contained within modules in IDL. There can be one or more interfaces defined within each IDL module. Listing 1 shows a simple IDL module named TheModule that contains a basic interface named TheInterface. This interface contains a single variable (TheVariable, of course) defined to be an integer value.

Listing 1: The simplest IDL module possible

Module TheModule { interface TheInterface { long TheVariable; }; }; 

If you compile this IDL module using an IDL-to-Java compiler (such as Visigenic's idl2java), you will get the Java interface shown in Listing 2.

Listing 2: The Java equivalent of TheModule

package TheModule; public interface TheInterface { public int TheVariable; } 

The ORBQuery applet

Now that you have a basic understanding of an ORB and IDL, we are ready to construct our ORBQuery applet. The client applet will consist of a standard Java GUI and will instantiate a remote CORBA object. Once this object has been instantiated, its methods can be called to determine information about a specific CORBA ORB. On the server side, we need to define five methods in order to retrieve the following information about a particular ORB: Name, Vendor, Operating System, Languages, and URL. Therefore, we must construct an IDL interface that defines five methods to retrieve this information. This interface,

ORBInfo

, is defined in Listing 3.

Listing 3: The ORBInfo IDL interface

module ORBQuery { interface ORBInfo { string GetName(in long index); string GetVendor(in long index); string GetOS(in long index); string GetLanguages(in long index); string GetURL(in long index); }; }; 

The VisiBroker installation includes an IDL compiler, idl2java, that you can use to generate the necessary Java code required to implement this interface. Once you've installed the package, simply execute the following command to generate the code:

idl2java ORBInfo.idl

This operation will create a subdirectory named ORBQuery (corresponding to the ORBQuery Java package). Within this directory, there are eight files: ORBInfo.java, ORBInfoHolder.java, ORBInfoHelper.java, _st_ORBInfo.java, _sk_ORBInfo.java, ORBInfoOperations.java, _tie_ORBInfo.java, and _example_ORBInfo.java. As you might have guessed, the ORBInfo.java file contains the Java version of the ORBInfo interface declaration, but what do the other Java classes do?

The ORBInfoHolder.java file contains a holder class used when passing parameters, while the ORBInfoHelper class defines various utility functions. The _st_ORBInfo class defines the client stub, while the _sk_ORBInfo class defines the server skeleton class. The ORBInfoOperations and _tie_ORBInfo classes are used to implement a tie mechanism, a VisiBroker feature designed to allow the implementation class to inherit from a class other than the skeleton class. We will not use these classes directly within this example. Finally, _example_ORBInfo contains a sample server object that can be extended to build the server application.

Si vous ne l'avez pas encore assemblé, les huit classes Java créées par le compilateur IDL nous ont donné un cadre (sous la forme de classes d'assistance, d'un stub, d'un squelette et d'une interface) pour construire notre propre client / serveur CORBA application en Java.

Construire l'application serveur