Je sais que CORBA vous permet d'implémenter plusieurs objets dans différents langages de programmation et même de s'exécuter sur différents nœuds de calcul. Mais est-il alors nécessaire d’avoir deux ORB différents écrits dans deux langages différents ?

Exemple : le nœud A exécute une application Java J1 et le nœud B exécute une application C++ C1. Dois-je obtenir un « ORB Java » pour le nœud A et un « ORB C++ » pour le nœud B ou est-ce que tous/certains ORB interagissent avec des applications écrites dans n'importe quel langage doté d'un mappage IDL ?

Je serais particulièrement reconnaissant si quelqu'un pouvait me relier à une source, en la déclarant directement comme j'aimerais qu'elle soit déclarée. Le plus proche que j'ai trouvé est "la façon dont un programmeur manipule une structure ou une union, effectue un appel à distance à l'aide d'un proxy ou implémente une interface avec une classe servante, de la même manière dans tous les produits CORBA C++, de la même manière dans tous les produits Java". Produits CORBA, etc." d. ". Cela me fait penser que j'aurai besoin de deux ORB, mais pas assez explicites. Fondamentalement, j'aimerais savoir si je peux dire que "puisque ORB est écrit en C++, il est également interdit aux programmeurs d'applications d'utiliser C++".

grâce à

3 réponses

Peu importe le langage dans lequel l'ORB est implémenté, ce qui compte, ce sont les liaisons linguistiques qu'il fournit. Pour le langage L, vous avez besoin d'un orbe qui fournit des liaisons pour le langage L. Souvent, les orbes fournissent simplement une liaison pour le langage dans lequel ils sont eux-mêmes écrits, mais peuvent également fournir des liaisons pour d'autres langages.

Non. L’intérêt de CORBA est qu’il découple complètement les composants.

Évidemment, vos applications doivent utiliser des bibliothèques clientes avec lesquelles elles peuvent interagir. Votre ORB ne peut installer des liaisons que pour un seul langage, auquel cas vous devrez rechercher d'autres liaisons ou trouver un moyen d'interagir avec elles (par exemple, si vous utilisez Python, vous pouvez toujours travailler avec des bibliothèques C++ si vous le souhaitez). ).

Essayez d'utiliser cette technologie.

Il existe plusieurs approches qui peuvent être utilisées lors de l'implémentation d'applications CORBA, mais pour résumer, oui, le framework ORB doit être dans le même langage que l'implémentation de votre application.

En Java et en C++, le compilateur IDL génère des stubs et des squelettes qui servent de lien entre le réseau et votre programme. Vous fournissez une implémentation de vos objets CORBA, héritant généralement d'une classe IDL (squelette) générée par le compilateur. Le squelette reçoit d'une manière ou d'une autre la demande du client puis appelle votre implémentation. La même chose se produit en sens inverse côté client.

Le squelette et le stub utilisent ensuite les mécanismes fournis par l'ORB pour appeler les serveurs à distance et répondre aux réponses, y compris même en établissant des connexions réseau si le client et les serveurs se trouvent sur des machines différentes. Cette « magie » est implémentée par l'ORB et doit être présente dans votre programme sous la forme d'une bibliothèque, d'un ensemble de fonctions, etc. que le stub et le squelette utiliseront pour faire le travail.

Ainsi, chaque programme doit avoir une sorte de représentation ORB pour communiquer avec d'autres clients et serveurs CORBA sur d'autres machines.

Cependant, d'un point de vue logique, l'ORB est considéré comme la couche qui connecte réellement et de manière transparente les clients et les serveurs. Ainsi, même si une application C++ a une implémentation ORB écrite en C++ et une implémentation Java, avoir un ORB écrit en Java Ce sont des protocoles standards magiques (GIOP, IIOP), ils peuvent communiquer entre eux sans problème.

Le rapport doit contenir :

Énoncé d'un problème résolu par un programme qui fonctionne bien.

Manuel d'utilisation du programme débogué, contenant une description des interfaces de toutes les fonctions du programme.

Liste des programmes avec commentaires nécessaires.

1. Questions de sécurité

Qu’est-ce que CORBA ?

Ce qui s'est passé IDL? A quoi ça sert ?

Comment le client et le serveur interagissent-ils ?CORBA?

Comment les données sont-elles transférées entre eux ?

A quoi sert un serveur de noms ?

Comment ça commence CORBA serveur?

1. Littérature

Ken Arnold, James Gosling, David Holmes.Langage de programmation Java™.

Site officielJava – http:// Java. soleil. com/ (il y a une section en russe avec un manuel).

SDK Java™ 2, documentation de l'édition standard - http://java.sun.com/products/jdk/1.5/index.html.

James Gosling, Bill Joy, Guy Steele.Spécification du langage Java ( La spécification du langage Java – http :// www . javasoft . com / documents / livres / jls /). Traduction en russe –http:// www. uni- vologda. ca. ru/ Java/ jls/ indice. HTML

Site officiel du projetÉclipse – http:// www. éclipse. org/.

1. Annexe 1. CORBA

Technologie CORBA (CommunObjetDemandeCourtierArchitecture) est un standard d'écriture d'applications distribuées proposé par un consortiumOH MON DIEU (OuvrirGestionGroupe). En créant des objets CORBA, nous pouvons, par exemple, réduire considérablement le temps nécessaire à la résolution de problèmes nécessitant une grande quantité de calculs. Ceci est possible en plaçant des objets CORBA sur différentes machines. Chaque objet distant résout une sous-tâche spécifique, évitant ainsi au client un travail inutile.

Le cœur de CORBA est l’Object Request Broker. ORB gère l'interaction des objets dans un environnement réseau distribué. IIOP (Internet Inter-ORB Protocol) est un protocole spécial pour l'interaction entre les ORB.

Un objet spécial appelé stub fonctionne dans l'espace d'adressage du client. Ayant reçu une requête du client, il regroupe les paramètres de la requête dans un format spécial et les transmet au serveur, ou plutôt au squelette.

Skeleton est un objet qui opère dans l’espace d’adressage du serveur. Ayant reçu une requête du client, il la décompresse et l'envoie au serveur. Le squelette convertit également les réponses du serveur et les transmet au client (stub).

Pour écrire une application CORBA à l'aide de la technologie Java, vous devez disposer de deux éléments : le package JDK1.5 installé et le compilateur idlj (…\ jdk 1.5.0\ poubelle\ idlj. exe). Le JDK fournit un ensemble de classes pour travailler avec des objets CORBA et idlj mappe le langage IDL sur Java.

6 .1 Création d'une application CORBA simple

1. Ecrire une interface

Création CORBA candidatures sur Javacommence par l'écriture d'une interface pour un objet distant à l'aide d'un langage de description d'interface (InterfaceDéfinitionLangue, IDL).

Créonsdéposerbonjour.idl

module BonjourApp

interface Bonjour

chaîne sayBonjour();

arrêt nul à sens unique ();

Cette interface ne décrit que deux méthodesfermer Et direBonjour . De plus, peu importe ce que font ces méthodes, l'essentiel est que nous déterminions qu'elles existent et déterminons leurs paramètres d'entrée et de sortie.

Ensuite, vous devriez exécuter le compilateurIDL- à- Javaidlj:

idlj – automneBonjour. inactif

Un nouveau dossier est apparu dans le répertoire courantBonjour Application , qui contient six fichiers Java. Chacun d'eux a son propre objectif.

BonjourPOA. JavaJava– une classe abstraite qui n'est rien d'autre que le squelette du serveur (squelette) et fournit des fonctionnalités de serveur.

_ BonjourStub. Java– une classe qui implémente talon ( bout) client. Fournitfonctionnalité client.

BonjourHelper. Java Et BonjourHolder. Java– des classes qui fournissent des fonctions d'assistance pourCORBA objets.

BonjourOpérations. Java– une classe contenant une description de l’interfaceBonjour dans la langue Java.

Bonjour. Java– classe – héritierBonjourOpérations, interface de supportorg. oh mon Dieu. CORBA. Objet.

1. Création d'un serveur

Maintenant, notre tâche est d'écrire une classe qui implémente l'interfaceBonjour . Dans notre cas, ce seraBonjourImpl . Veuillez noter qu'il s'agit d'un héritier de la classeBonjourPOA . DANS BonjourImpl méthodes déclarées dansBonjour . inactif .

Pour simplifier la tâche, la déclaration des méthodes peut être extraite du fichier BonjourOpérations . Java , généré jdlj .

orbe ORB privé ;

orbe = orb_val;

chaîne publique sayHello() (

return "\nBonjour tout le monde !!\n" ;

arrêt public vide() (

orb.shutdown(false);

L'étape suivante consiste à créer le véritablepartie serveur de l'application. Ce sera la classeBonjourServeur.

Il n'aura qu'une seule méthode - une fonction standardprincipal.

La première chose que nous faisons est de créer un ORB. Ensuite, nous créons une instance de la classe d'objet distant (BonjourImpl) et enregistrez-le dans ORB. Ensuite, nous appelons un service de nom spécial (NameService) et y enregistrons le nom de l'objet distant afin que le client puisse le trouver.

Regardons de plus près ces étapes.

1. Création et initialisation de l'ORB. Produit en appelant une méthode statiqueinitialisation Classe ORB

2. Création d'une instance d'une classe d'objet distant et enregistrement dans l'ORB

bonjourImpl.setORB(orbe);

3. Obtenir le contexte de dénomination (Contexte de dénomination)

org.omg.CORBA. Objet objRef =

Dans la première ligne, nous obtenons une référence d'objet au service de noms (NameService). Mais en fait, il s'agit d'un objet CORBA ordinaire et pour l'utiliser comme contexte de nommage (NamingContext), vous devez appeler la méthodeétroit classe NamingContextHelper , qui semble spécifier cet objet CORBA.

4. Enregistrement du nom de l'objet distant (BonjourImpl)

Nom de la chaîne = "Bonjour" ;

ncRéf. relier (chemin, href);

Le nom est enregistré afin que le client puisse trouver l'objet distant. Cet objectif est atteint par la fonctionrelier (NomComposantCaroline du Nord, Objetobj)interface Contexte de dénomination.

5. En attente des demandes du client

orbe. courir();

Le serveur est maintenant prêt à être utilisé.

// BonjourServeur.java

importer HelloApp.* ;

importer org.omg. CosNom.*;

importer org.omg.CORBA.* ;

importer org.omg. ServeurPortable.*;

importer org.omg. PortableServer.POA ;

importer java.util. Propriétés;

la classe HelloImpl étend HelloPOA (

orbe ORB privé ;

public void setORB(ORB orb_val) (

orbe = orb_val;

// implémente la méthode sayHello()

chaîne publique sayHello() (

return "\nBonjour tout le monde !!\n" ;

// implémente la méthode shutdown()

arrêt public vide() (

orb.shutdown(false);

classe publique HelloServer (

public static void main (arguments de chaîne) (

essayer (

ORB orbe = ORB.init(args, null);

// récupère la référence à rootpoa et active le POAManager

POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));

rootpoa.the_POAManager().activate();

// crée un serviteur et l'enregistre auprès de l'ORB

HelloImpl helloImpl = new HelloImpl();

bonjourImpl.setORB(orbe);

// récupère la référence de l'objet du serviteur

org.omg.CORBA. Ref d'objet = rootpoa.servant_to_reference(helloImpl);

Bonjour href = HelloHelper.narrow(ref);

// NameService appelle le service de noms

orb.resolve_initial_references("NameService");

// Utilisez NamingContextExt qui fait partie de l'Interoperable

// Spécification du service de noms (INS).

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

// lie la référence d'objet dans le nommage

Nom de la chaîne = "Bonjour" ;

Chemin NameComponent = ncRef.to_name(nom);

ncRef.rebind(chemin, href);

System.out.println("HelloServer prêt et en attente...");

// attend les invocations des clients

orb.run();

attraper (Exception e) (

System.err.println("ERREUR :" + e);

System.out.println("Bonjour le serveur sort...");

1. Création d'un client

Passons à l'écriture du code pour le client.

Étapes de base pour écrire une application client

Création et initialisation d'ORB

Obtenir le contexte du service de noms (Contexte de dénomination)

Trouver un objet distant

Appel de la méthode sayHello.

Appel de la méthode d'arrêt.

Comme vous pouvez le constater, les deux premiers points coïncident avec les étapes de création d'une application serveur, nous ne les considérerons donc pas.

Le troisième point est également assez simple à mettre en œuvre. Un objet est crééNomComposant. La méthode s'appellerésoudre (NomComposantchemin), qui recherche un objet distant par son nom (standardCORBAobjet). En utilisant la méthodeétroit (org. oh mon Dieu. CORBA. Objetobj) classe bonjourAide(généréidljcompilateur) nous obtenons une référence d'objet à l'interfaceBonjour.

Nom de la chaîne = "Bonjour" ;

Vous pouvez maintenant appeler la méthodedireBonjour:

Méthodefermerarrête le serveur.

bonjourImpl.shutdown();

//testClient.java

importer HelloApp.* ;

importer org.omg. CosNom.*;

importer org.omg. CosNaming. NommageContextPackage.*;

importer org.omg.CORBA.* ;

classe publique HelloClient

{

statique Bonjour bonjourImpl;

public static void main (arguments de chaîne)

{

essayer (

// crée et initialise l'ORB

ORB orbe = ORB.init(args, null);

// récupère le contexte de dénomination racine

org.omg.CORBA. Objet objRef =

orb.resolve_initial_references("NameService");

// Utilisez NamingContextExt au lieu de NamingContext. C'est

// fait partie du service de noms interopérable.

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

// résout la référence d'objet dans le nommage

Nom de la chaîne = "Bonjour" ;

helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));

System.out.println("Obtention d'un handle sur l'objet serveur :" + helloImpl);

System.out.println(helloImpl.sayHello());

bonjourImpl.shutdown();

) attraper (Exception e) (

System.out.println("ERREUR :" + e);

e.printStackTrace(System.out);

}

}

}

4. Compilation Et lancement candidatures

FichiersBonjourServeur. Java et BonjourClient. Java, Bonjour. inactifet dossierBonjourApp, crééidkj. exedoivent être stockés dans un seul dossier.

Pour compiler le client et le serveur, vous devez taper sur la ligne de commande

javac *.java HelloApp/*.java

javac. exeest situé à...\jdk1.5.0\ poubelle.

MercrediÉclipsene permet pas de courirCORBAcandidatures. Pour commencer

1. Démarrez le serviceorbd – Objet Demande Courtier Démon (…\ jdk1.5.0\ poubelle\ orbd. exe). Ceci est fait pour que nous puissions obtenir un lien vers le service de noms.

commencer orbd – ORBInitialPort 1050

Paramètre -ORBInitialPort– numéro de port sur lequel le serveur de noms fonctionnera.

2. Lancement serveurs

serveur de noms.

3. Lancement client

Spécifie le port sur lequel le serveur de noms est exécuté. Paramètre – ORBInitialHost spécifie l'hôte sur lequel il s'exécuteserveur de noms.

Pour faciliter la compilation et le lancement, vous pouvez créerbattedéposer:

idlj – automne Bonjour.idl

javac *.java HelloApp/*.java

démarrer Java HelloServer – ORBInitialPort 1050 – ORBInitialHost localhost

java HelloClient – ​​​​ORBInitialPort 1050 – ORBInitialHost localhost

6.2 Langue IDL

LangueOH MON DIEU IDL (Interface Définition Langue– Interface Description Language) est une syntaxe indépendante de la technologie pour décrire les interfaces d'objets. Lors de la description des architectures logicielles,OH MON DIEU IDLest parfaitement utilisé comme notation universelle pour définir les limites d'un objet qui déterminent son comportement par rapport aux autres composants du système d'information.OH MON DIEU IDLvous permet de décrire des interfaces qui ont différentes méthodes et attributs. Le langage prend également en charge l'héritage d'interface, nécessaire à la réutilisation d'objets avec la possibilité de les étendre ou de les instancier.

IDLest un langage purement déclaratif, c'est-à-dire qu'il ne contient aucune implémentation.IDLles spécifications peuvent être compilées (affichées) dans des fichiers d'en-tête et des prototypes de serveur spéciaux qui peuvent être utilisés directement par le programmeur. C'estIDLcertaines méthodes peuvent être écrites, puis exécutées, dans n'importe quel langage pour lequel un mappage existe à partir deIDL. Ces langues incluentC, C++, Petite conversation, Pascal, Java, Ada.

En utilisantIDLVous pouvez décrire les attributs du composant, les classes parentes dont il hérite, les exceptions levées et, enfin, les méthodes qui définissent l'interface, avec une description des paramètres d'entrée et de sortie.

StructureCORBA IDLle fichier ressemble à ceci :

module(

;

;

;

interface [: ] (

;

;

;

;

()

.

.

()

.

.

}

interface [: ]

.

.

}

Syntaxe du langageIDLassez volumineux et il n’est pas possible de le décrire dans un manuel pédagogique.

Pour implémenter l'interface du serveur de messagerie, vous pouvez ajouterBonjour. inactif

module BonjourApp

{

structure TMessage

{

chaîne À ;

chaîne De ;

chaîne Message ;

};

séquence de typedef TMessages ;

interface Bonjour

{

TMessages GetMessages (dans la chaîne Nom, nombre insuffisant) ;

oneway void Send (dans la chaîne Client, dans la chaîne Nom, dans la chaîne Message) ;

chaîne sayBonjour();

arrêt nul à sens unique ();

};

};

séquence typedef TMessages; – annonce taper dynamique tableau messagesMessage.

Source : JBuilder

Introduction

Dans toute organisation, les domaines de travail liés à l'entreprise sont répartis entre les différents membres de l'organisation afin de gérer chaque partie plus efficacement. De la même manière, les objets du cyberespace d’une organisation sont distribués pour remplir le plus efficacement possible leurs fonctions commerciales. Paradoxalement, le but d’un système d’objets distribués est de mieux intégrer l’organisation. Une répartition suffisamment significative et réfléchie des objets dans tous les processus métier d'une organisation crée une plus grande cohérence, une efficacité supplémentaire et rend le système dans son ensemble beaucoup plus rationnel. Cependant, cette répartition doit être parfaitement réfléchie, car disperser des objets au vent est sans aucun doute néfaste. Pour éviter de telles erreurs, cet article présente des technologies puissantes telles que CORBA et Java, implémentées dans les outils de développement Borland - VisiBroker et JBuilder. Il s'avère souvent que les systèmes distribués présentent une grande complexité à toutes les étapes du cycle de vie du logiciel, de la conception à la gestion. JBuilder et VisiBroker améliorent ce processus en facilitant la création et le déploiement d'applications CORBA distribuées. Avec la sortie de JBuilder 3.5, l'intégration CORBA devient transparente avec l'ajout de plusieurs fonctionnalités destinées à aider les développeurs à créer des objets, servlets, serveurs et clients VisiBroker CORBA en Java.

Cet article adopte une approche pratique pour présenter VisiBroker et illustre chaque sujet avec une application réelle. Au lieu de présenter CORBA dans son ensemble, nous décrirons les concepts tels que nous les rencontrons ici. Cette méthode permet de mieux introduire les concepts CORBA en illustrant clairement la théorie avec un exemple direct.

Qu’est-ce que CORBA ?

Avec l'avènement de l'Intranet et d'Internet, l'informatique en réseau devient finalement le domaine dominant du développement logiciel. Mais comment tant de systèmes différents peuvent-ils interagir les uns avec les autres ? Pour faire face à ce problème, OMG développe continuellement les spécifications CORBA. Ces spécifications standardisent la manière dont les programmes communiquent entre eux sur un réseau. CORBA, cependant, va au-delà de la simple interaction ; il s'agit d'une solution de connectivité flexible et personnalisable pour les applications multi-niveaux - ce qu'on appelle. middleware ou logiciel de niveau intermédiaire. Common Object Request Broker Architecture (CORBA) est un ensemble de spécifications développées et standardisées par l'Object Management Group (OMG).

OMG, ou Object Programming Standards Working Group, est un consortium d'environ 800 entreprises de l'industrie informatique. L'objectif principal d'OMG est de définir un cadre d'architecture appelé Object Management Architecture (OMA), qui est un cadre d'architecture pour l'informatique distribuée. OMG n'est pas une organisation d'élaboration de normes. Son objectif est de promouvoir l'adoption par l'industrie de spécifications d'interface pour la gestion d'objets distribués. Encore une fois, force est de constater que ce consortium à but non lucratif n'établit pas de normes pour l'industrie. Au lieu de cela, l'OMG favorise l'adoption de normes en parvenant à un consensus parmi ses membres. De par leur nature, les normes envisagées pour adoption par l’OMG ne sont pas théoriques ; ils ont été mis en œuvre et testés dans la pratique. La norme CORBA définit comment les objets se représentent et comment ils interagissent dans un environnement distribué, ainsi que les protocoles de communication entre les objets.

La structure de la norme CORBA permet à des éditeurs de logiciels individuels, tels que Borland, de développer des programmes conformes aux recommandations de l'OMG. Plusieurs composants d'une implémentation CORBA sont définis par la norme OMG ; cependant, la plupart des fournisseurs étendent ces composants de base pour fournir une solution complète. Cet article est consacré à l'implémentation de CORBA VisiBroker et aux composants qui le représentent.

Qu'est-ce qu'un système d'objets distribués ?

Le terme « distribué » implique des objets géographiquement dispersés. En fait, un système d'objets distribués est un simple mélange de deux technologies : la programmation réseau et la programmation orientée objet. Les réseaux permettent l'informatique distribuée et les objets assurent l'encapsulation, la réutilisation et une fiabilité opérationnelle accrue. L’un des moteurs les plus importants de l’informatique distribuée est le Web. En tant que plus grand système distribué au monde, il connecte des technologies, des informations et des médias radicalement différents. Cependant, tous les systèmes distribués ne sont pas nécessairement « orientés objet ». La combinaison des approches réseau et objet conduit à des améliorations significatives dans le développement de logiciels et la gestion de la maintenance, la réutilisabilité et l'évolutivité.

Pourquoi distribué ?

Si une organisation est située au même endroit (c'est-à-dire qu'elle dispose d'un seul emplacement) et ne dispose que de quelques ordinateurs, une telle organisation n'a probablement pas besoin de distribuer ses objets. Cependant, la plupart des organisations dépassent rapidement cette étape et commencent à étendre leur présence avec plusieurs sites, plusieurs secteurs d'activité et plusieurs ordinateurs. Pour ces organisations, l'informatique distribuée peut augmenter le niveau d'évolutivité des solutions. De plus, la motivation pour développer des systèmes distribués ou multi-niveaux peut avoir plusieurs raisons. Les applications distribuées multiniveaux offrent un certain nombre d'avantages par rapport au développement d'applications client/serveur traditionnel. Pour comprendre les avantages des applications à n niveaux, il est utile de noter les inconvénients des autres approches ; par exemple, l'opposé diamétralement opposé d'un système distribué : un système centralisé basé sur un seul ordinateur central. Comme l’ont noté les partisans de l’architecture client/serveur, ce système présente plusieurs inconvénients. Si l'ordinateur central n'est pas disponible, aucun traitement ne peut être effectué. De plus, toutes les données doivent être transférées vers un ordinateur central, qui constitue essentiellement l'archive principale. De même, dans un environnement client/serveur, le client est généralement un morceau de code plus lourd avec une base de données spécialisée (SQL, AS/400, etc.) conçue pour assurer le stockage des données. Le problème de ce modèle est que la plupart des systèmes de bases de données ne peuvent pas représenter et appliquer toutes les règles et processus métier requis par un système logiciel complexe. En raison de cette inadéquation, la logique métier est souvent partagée entre l'application client et l'application serveur. Ce type de pratique pose de nombreux problèmes liés à la fiabilité opérationnelle, à la réutilisation et aux mises à jour, puisque la logique métier n'appartient pas à une partie distincte de l'application.

Contrairement aux clients rigides « le mainframe peut tout faire » ou aux clients « gros » dans les clients/serveurs, les solutions multi-niveaux surmontent bon nombre de ces problèmes en consolidant la logique métier dans un niveau intermédiaire ou un niveau. Grâce à cette approche, les objets et les fonctionnalités conçus pour fonctionner avec la base de données sont séparés. Le résultat est une évolutivité, une maintenance et une réutilisation améliorée des logiciels.

De plus, la fonctionnalité de compartimentation réduit considérablement le temps nécessaire au développement de nouvelles applications, permettant ainsi aux nouveaux systèmes de s'interfacer facilement avec les données et les processus actuels. Le nouveau client peut simplement utiliser le middleware existant, exploitant ainsi la logique métier existante écrite pour les applications précédentes. Enfin, conserver la logique dans un niveau intermédiaire bien défini permet de concentrer du matériel plus puissant dans des serveurs d'objets spécialisés. À mesure que les niveaux de charge augmentent, de nouvelles machines peuvent être ajoutées ou, pour optimiser les performances, les processus du serveur peuvent être redistribués vers d'autres machines, de manière totalement transparente pour le client.

Pourquoi CORBA ?

La décision d'utiliser CORBA dans une application multiniveau est généralement motivée par ses performances industrielles éprouvées, son utilisation généralisée en tant que standard et sa mise en œuvre ouverte et multiplateforme. Outre la norme de définition des interfaces objet, CORBA définit également le protocole d'interface objet standard (GIOP) et une implémentation spécifique de GIOP, appelée IIOP, qui s'exécute sur TCP/IP.

La capacité des objets CORBA à échanger des informations sur le Web et au sein des intranets à l'aide d'IIOP est l'une des principales raisons pour lesquelles CORBA a été si largement adopté. Lors du choix d'applications middleware, CORBA offre un certain nombre d'avantages par rapport aux autres approches de type DCOM, notamment l'indépendance de la plate-forme, un meilleur contrôle sur la manière dont les informations sont transférées entre les objets et une stabilité éprouvée.

Architecture VisiBroker

Examen ORB

L'architecture CORBA est composée de plusieurs services, directives et processus qui permettent aux objets distribués de communiquer entre eux. OMA, comme décrit précédemment, est logiquement divisé en deux composants de haut niveau. Cette séparation permet aux concepteurs de systèmes de créer des architectures distribuées basées sur OMA à partir de composants provenant de plusieurs fournisseurs.

Composant orienté système : courtier de requêtes d'objet ( Courtier de requêtes d'objet)
Composant centré sur l'application : objets d'application CORBAfacilities.

L'Object Requests Broker (ORB) est le composant principal d'OMA. Un ORB définit et fournit un moyen d'échange d'informations entre objets. Un ORB, ou Object Request Broker, est une fonction de pontage qui fournit un ensemble de services permettant à deux objets de communiquer sur un réseau. Voici des exemples de certains services implémentés dans ORB. Il s'agit de l'activation, de la localisation et de la communication des objets. Ces services sont documentés dans l'architecture CORBA. Il existe de nombreux fournisseurs d'ORB. Certains fournisseurs ORB, comme Borland, implémentent également d'autres services CORBA, tels qu'un service de noms, un service d'événements, un service de transactions et un service de base de données. Ces services à valeur ajoutée fournissent la structure de base pour créer des systèmes logiciels distribués et évolutifs.

Les CORBAfacilities sont des collections d'objets définis en IDL qui peuvent être directement utilisés par les applications. Ils sont constitués de composants horizontaux et verticaux qui décrivent les règles d'interaction entre les objets. Ils sont liés aux Java Beans du monde Java.

La spécification complète de l'architecture CORBA, telle qu'adoptée et publiée par l'OMG, est divisée en trois sections principales : le noyau CORBA, l'interopérabilité CORBA et les mappages OMG IDL vers différents langages. La norme CORBA ne précise pas de règles strictes pour la mise en œuvre d'une architecture. Les vendeurs d'ORB sont libres de concevoir leur ORB comme ils en ont besoin.

Un courtier de demandes d'objets (ORB) est un middleware qui fournit un ensemble de services permettant de rechercher et d'utiliser des implémentations de divers objets. L'Object Request Broker (ORB) est la base d'OMA. Il définit l'infrastructure qui permet aux composants CORBA de communiquer entre eux. N'oubliez pas qu'ORB est ce que l'on appelle communément CORBA. L’avantage de l’utilisation des ORB est qu’ils masquent la complexité de la méthode de rappel envoyée à l’objet. Lorsqu'un objet client appelle une méthode sur un objet serveur, quel que soit son emplacement, l'ORB intercepte la requête et trouve le serveur correspondant. Idéalement, les fournisseurs d'ORB enregistrent désormais tout le code de communication jamais écrit par les développeurs. Les ORB peuvent communiquer entre eux à l’aide de protocoles de communication standard. Cela permet aux objets client et serveur CORBA d'être implémentés dans différents langages de programmation et environnements d'exploitation. Une fois que l'ORB du serveur a accepté une demande client, une méthode sur l'objet serveur est appelée, en transmettant les paramètres appropriés. Une fois le traitement de l'objet serveur terminé, l'ORB serveur renvoie les résultats à l'objet client via l'ORB client. Les clients peuvent recevoir un ensemble de paramètres de résultat à partir d'une seule requête de méthode d'objet serveur. Les paramètres IDL in et in/out sont implémentés à cette fin uniquement. Ainsi, ORB libère les programmeurs d'une quantité importante de travail de routine. Les objets peuvent échanger des informations quel que soit leur emplacement, leur système d'exploitation ou leur langage de programmation.

Une implémentation de base de CORBA comprend généralement un Object Request Broker (ORB), un compilateur pour IDL (CORBA Interface Definition Language) et Common Object Services (COS), qui assistent les objets dans le processus d'interaction. Si l'objet est local, l'ORB effectue une requête de méthode locale ; si l'objet se trouve sur une autre machine associée, l'ORB communique en utilisant GIOP (l'utilisation la plus courante est IIOP sur TCP/IP). Par conséquent, le client n'a pas besoin de « savoir » quoi que ce soit sur l'emplacement de l'objet, le système d'exploitation hôte ou le langage dans lequel il a été implémenté afin d'obtenir une référence à celui-ci.

Adaptateurs d'objets, BOA et POA

Un adaptateur d'objet CORBA est nécessaire pour faire correspondre le concept d'implémentation d'objets dans un langage de programmation au concept d'objets CORBA. Il s'agit d'une réintégration du principe de conception de l'adaptateur. Voici les responsabilités des adaptateurs d'objet :

Génération et interprétation de références d'objets

• Appeler une méthode
• Activation et désactivation d'un objet et mise en œuvre
• Mappage des références d'objet à l'implémentation d'objet correspondante
• Enregistrement des ventes

Adaptateurs d'objet CORBA standard :

• Basic Object Adapter (BOA) - Le premier adaptateur d'objet standard de CORBA
• Portable Object Adapter (POA) - introduit dans la norme CORBA 2.1, remplace BOA

Les développeurs se sont rendu compte que BOA présentait de nombreux défauts. Les spécifications du BOA lui-même étaient incomplètes, rendant l'écriture de code de serveur portable presque impossible. Voici quelques autres problèmes qui surviennent lorsque vous travaillez avec BOA. Cela signifie que l'enregistrement de l'implémentation et le traitement des requêtes n'ont pas été spécifiés, et que la présentation ou les noms des classes squelettiques n'ont pas été définis. De plus, il n’existe aucune méthode pour enregistrer et restaurer l’état d’un objet. Les cycles de vie des objets CORBA et des objets d'exécution sont étroitement liés à l'implémentation de BOA, et la spécification BOA ignore complètement l'exécution de processus parallèles dans le processus serveur.

L'adaptateur d'objet portable corrige certaines des lacunes de BOA. Les spécifications POA sont conçues pour permettre aux développeurs d'écrire des applications serveur mobiles et évolutives. Dans le même temps, POA prend en charge un large éventail de fonctionnalités qui permettent un contrôle précis des ressources requises pour implémenter les objets CORBA et leur envoyer des requêtes. Il fournit des interfaces pour gérer le cycle de vie de l'implémentation d'un objet et sa disponibilité à accepter les demandes. POA peut être utilisé même pour les serveurs ayant des exigences exotiques.

Terminologie du POA

POA contient son propre ensemble de concepts qui étendent et affinent le modèle objet CORBA. Nous avons un objet CORBA qui est un objet "virtuel", abstrait, avec la possibilité d'accéder à sa référence d'objet et la possibilité d'accepter des requêtes. De plus, il existe un serviteur, qui est un objet de langage de programmation qui existe dans le contexte du processus serveur et implémente un objet CORBA. Un buffet donne une forme physique à un objet CORBA correspondant. De plus, le POA prend en charge un ID d'objet, un identifiant système ou défini par l'utilisateur utilisé pour identifier un objet au sein de son POA. Et enfin, le squelette est un objet de langage de programmation qui connecte le serviteur au POA, permettant au POA d'envoyer des requêtes au serviteur.

Cycle de vie des objets et des serviteurs CORBA

POA offre une forte séparation entre la durée de vie des objets CORBA et la durée de vie d'un buffet. Les termes suivants font référence au cycle de vie d'un objet CORBA :

• Activation - Démarrage d'un objet CORBA existant pour lui permettre d'accepter les demandes.
• La désactivation est l'arrêt d'un objet CORBA actif.

Les termes suivants font référence au cycle de vie d'un buffet :

Au cours de sa durée de vie, un objet CORBA peut être instancié par plusieurs serviteurs. En revanche, un seul buffet peut incarner plus d’un objet.

Hiérarchie du POA

La principale caractéristique de l’architecture POA est qu’un serveur peut contenir plusieurs POA imbriqués en son sein. D'un autre côté, un POA imbriqué peut être créé en utilisant une opération de fabrication provenant d'un autre POA. Tous les serveurs disposent d'au moins un POA racine, qui peut être obtenu auprès de l'ORB. Le nom d'un POA imbriqué identifie de manière unique ce POA dans le contexte de son parent. Le nom du POA racine est RootPOA.

Gestionnaires de POA Chaque POA est associé à un gestionnaire de POA, et le gestionnaire de POA gère le flux de demandes vers son POA.

Le gestionnaire POA peut mettre les demandes en mémoire tampon ou les refuser. POA fournit un ensemble très riche de fonctionnalités qui offrent une flexibilité maximale pour le développement d'applications serveur. Les spécifications standardisent le développement de serveurs, permettant aux programmeurs de créer des applications portables sur différents ORB. L'implémentation CORBA de Visibroker prend en charge toutes les fonctionnalités POA.

Examen IDL

L'une des spécifications clés fournies par CORBA est le langage de définition d'interface (IDL). IDL décrit les objets indépendamment de la langue afin que les objets soient directement accessibles à l'aide de n'importe quelle langue, système d'exploitation ou réseau pris en charge. Java et C++ sont des langages de programmation qui permettent au développeur de mettre en œuvre des solutions aux problèmes métiers. Quant à IDL, il est indépendant des autres langages, et permet au programmeur uniquement de définir des interfaces pour les objets, mais pas l'implémentation de ces objets.

CORBA fournit une technologie d'objets distribués qui permet aux utilisateurs de créer des applications interactives et évolutives. La spécification IDL CORBA sépare l'interface de son implémentation, permettant à l'interface d'être implémentée dans le langage de programmation le mieux adapté à des tâches spécifiques. Des mappages IDL ont été créés pour C, C++, Ada et Java, ainsi que pour d'autres langages. CORBA fournit une infrastructure qui permet à différentes implémentations d'objets de communiquer entre elles. Les requêtes d'objets sont regroupées dans un format commun qui peut être reconnu par différents langages et systèmes d'exploitation.

IDL est utilisé pour définir l'interface d'un objet, qui devient un accord ou un contrat entre le client et le serveur de l'objet. L'interface décrit toutes les opérations, les paramètres d'entrée et de sortie et toutes les exceptions pouvant être levées par l'objet serveur. En d’autres termes, une interface décrit le comportement d’un objet, et non la manière dont ce comportement sera implémenté. Ainsi, IDL est un langage idéal pour définir des systèmes logiciels, grands ou petits, quel que soit le langage d'implémentation. Les concepteurs et architectes de systèmes utilisent IDL pour décrire les services qu'ils souhaitent offrir aux clients potentiels.

De plus, IDL constitue un excellent moyen d'encapsuler des interfaces héritées car il sépare la spécification d'un objet de son implémentation. Des objets serveur CORBA peuvent être créés pour s'interfacer avec les applications existantes existantes. Il fournit aux applications existantes une interface orientée objet et accessible au réseau.

L'IDL ne contient aucune information sur la façon dont un objet est implémenté. IDL décrit uniquement l'interface. L'implémentation de l'objet serveur peut être représentée dans n'importe quel langage de programmation prenant en charge CORBA. Je voudrais noter qu'IDL est facile à apprendre. Il prend en charge un sous-ensemble de la syntaxe C++ sans constructions procédurales comme les boucles for et while. Puisque IDL décrit uniquement l'interface avec un objet (par exemple la méthode d'appel et les paramètres), il démontre en outre qu'il s'agit d'un langage facile à apprendre. Pour ceux qui n'aiment pas l'idée d'apprendre encore une autre langue, réjouissez-vous - VisiBroker propose une solution Java complète, où l'interface est définie dans l'interface Java et le compilateur effectue une rétro-ingénierie de l'IDL et des fichiers requis à partir de l'interface Java. déposer. Cette fonctionnalité permet également d'utiliser des structures de classe Java telles que Vector comme paramètres d'appel.

IDL est essentiellement un langage à part entière, bien que ses constructions soient similaires à celles du C++ et de Java. Plusieurs ressources sont disponibles sur le site Web d'OMG (www.omg.org) qui fournissent des informations sur la façon de démarrer avec IDL.

CORBA offre une transparence de localisation. Les clients n'ont pas besoin de connaître l'emplacement d'implémentation de l'objet. Cela offre la flexibilité d’aligner des objets sur la même machine, à distance ou de déplacer en continu un objet dans un environnement dynamique. Le client peut utiliser le service de noms CORBA pour rechercher des objets serveur. L'emplacement réel de l'objet serveur est transparent pour le client. De plus, VisiBroker dispose d'un Smart Agent « prêt à l'emploi » pratique, qui fonctionne comme un service d'annuaire pour rechercher et localiser rapidement des objets.

CORBA IIOP

Le protocole Internet CORBA Inter-ORB (IIOP) offre aux ORB une indépendance vis-à-vis des fournisseurs. Les ORB peuvent interagir selon les spécifications IIOP. Autrement dit, IIOP garantit que les objets CORBA implémentés à l'aide des ORB d'un fournisseur seront capables de communiquer avec les objets CORBA implémentés sur n'importe quel autre ORB.

L'architecture de gestion d'objets (OMA) décrit un ensemble de spécifications de base, appelé CORBAservices, qui peuvent être inclus dans des systèmes logiciels complexes. Ces services permettent aux objets d'application de communiquer de manière standard. Les fournisseurs ont mis en œuvre des « CORBAservices » pour faciliter le développement de grands systèmes distribués.

D'un autre côté, si un développeur envisage d'écrire des applications à l'aide d'Enterprise Java Beans, IIOP bénéficie de la prise en charge de l'interopérabilité déclarée RMI/IIOP entre plusieurs langages et entre les conteneurs de plusieurs fournisseurs. Le conteneur EJB Inprise est basé sur CORBA. Inprise Application Server offre une compatibilité CORBA avec le mappage RMI-over-IIOP et Java-over-IDL.

Création d'un serveur CORBA à l'aide de JBuilder

Définition d'objet

Compte tenu de ces deux composants, la définition d'un objet en tant qu'IDL et d'un ORB en tant que canal de communication entre ces objets, nous pouvons commencer à explorer le développement d'une application CORBA à l'aide de JBuilder. Comme tout projet logiciel, les premiers défis liés à la mise en œuvre de notre application seront l'évaluation et la conception. Puisque CORBA est un standard orienté objet, nous devons décomposer notre processus métier en objets logiques, leurs propriétés et les opérations que nous devrons effectuer sur ces objets et avec ces objets. Pour accomplir ces tâches, nous utiliserons un simple serveur de participants qui pourra extraire une estimation de la participation à la conférence Borland/Inprise.

Pour commencer, nous garderons la fonctionnalité simple en définissant une seule interface, que nous appellerons Attendees. IDL. L'interface décrit les fonctionnalités que notre objet offre aux clients. Il a été mentionné précédemment que nous pourrions utiliser Caffeine pour définir nos interfaces en Java, mais nous souhaitons le démontrer en IDL.

Développement CORBA dans JBuilder

Dans le monde informatique, Java s'est rapidement imposé comme la plate-forme standard pour la création d'applets et d'applications Internet et Intranet. L'une des principales raisons du succès de Java est la portabilité quasi parfaite de la plateforme. Les programmes écrits en Java peuvent s'exécuter sur une variété de systèmes d'exploitation et de configurations matérielles. Combinez ces caractéristiques avec la facilité d'utilisation de Java, la prise en charge de la gestion des exceptions, la prise en charge des threads et le garbage collection, et vous obtenez un langage qui constitue un environnement idéal pour le développement informatique en réseau, en particulier la programmation Internet.

• Java - orienté objet
• Java - convivial
• Java propose des exceptions, la prise en charge des threads et un garbage collection
• Java s'affiche bien sur IDL

Java et CORBA sont faits l'un pour l'autre. Java offre la flexibilité multiplateforme nécessaire pour créer et distribuer des objets sur un réseau d'ordinateurs et de systèmes d'exploitation divers. CORBA fournit des outils pour connecter et intégrer des objets distribués écrits dans différents langages. Voyons comment ces deux technologies fonctionnent ensemble.

Actuellement, les concepteurs de systèmes CORBA sont en mesure de fournir des systèmes logiciels distribués, décrits en IDL et implémentés en Java, en utilisant des navigateurs modernes et la technologie Web.

Avant l’avènement de Java et CORBA, les utilisateurs distants n’avaient clairement pas accès aux informations du mainframe. La communication avec le mainframe est difficile. Nous devons nous soucier des nouvelles éditions des plateformes, des protocoles de communication et des langages.

Pour déployer un client léger, vous pouvez utiliser du HTML standard sur le client et des servlets Java (qui font deux fois la taille des clients CORBA) sur le serveur Web. Dans une architecture à trois niveaux, le programme d'application est réparti entre le client, le serveur et le niveau intermédiaire. Le niveau intermédiaire simplifie à la fois le client et le serveur et rend le déploiement plus facile qu'un système à deux niveaux dans lequel le client et le serveur sont directement couplés.

Dans CORBA, les serveurs implémentent des objets et les clients appellent des méthodes sur ces objets. Description IDL est un contrat entre un client et un serveur et tout ce que le client doit faire est d'utiliser un objet implémenté par le serveur.

Maintenant que nous avons défini ce qu'est CORBA et comment il est implémenté, passons à l'écriture de l'application. Les derniers langages de programmation prennent en charge le développement CORBA, notamment C++, Java et Object Pascal Delphi. En conséquence, les principaux outils RAD prennent en charge la norme OMG à des degrés divers. JBuilder a été l'un des premiers outils conçus pour intégrer étroitement les outils de développement CORBA dans les IDE, et JBuilder3.5 a ajouté plusieurs nouvelles fonctionnalités pour créer des serveurs, des clients et d'autres services CORBA VisiBroker. Nous apprendrons le développement en utilisant Java avec JBuilder.

Développement d'applications d'architecture CORBA dans l'environnement Jbuilder

Initialement, notre serveur Attendees sera constitué d'un seul objet, le ConferenceManager, qui informera les demandes de participation probable à la conférence. Nous souhaitons pouvoir interroger AttendeesManager sur le nombre de visiteurs attendu cette année.

Dans IDL, nous le définissons comme ceci : // Attendees.idl module bicon2000 ( interface Attendees ( long number(in long lastYear); ); );

Nous avons défini un module appelé bicon2000 (abréviation de Borland/Inprise Conference 2000). Un module correspond à un package Java et constitue simplement un espace de noms dans lequel se trouve une interface. Au sein du module bicon2000, nous définissons une interface unique appelée Attendees. Comme les interfaces Java, cette interface est essentiellement un contrat entre le client et le serveur indiquant les méthodes que l'objet Attendees expose à utiliser. Nous pouvons voir ici à quel point IDL est similaire à C++ et Java dans sa syntaxe. Les types de données sont également similaires ; nous renvoyons un long (entier long) pour le nombre de nos visiteurs, et comme entrée nous prenons la valeur de l'année dernière. L'argument "l'année dernière" est identifié comme étant entré car l'objet serveur (défini dans ce cas comme étant sorti) ne modifiera pas cette valeur. L'interface Attendees n'expose qu'une seule méthode "numéro", ce qui implique que l'objet Java que nous utilisons pour implémenter Attendees n'aura besoin de prendre en charge que cette seule méthode. Pour créer ce fichier IDL, sélectionnez Fichier, Nouveau... dans le menu supérieur. Sélectionnez l'onglet Entreprise dans la boîte de dialogue Galerie d'objets. Et puis sélectionnez Exemple IDL.

La définition est complète ; il suffit de « compiler » les constructions standards dans un langage spécifique, dans notre cas, des classes Java. La compilation d'un fichier IDL produit des interfaces Java, des stubs client et des squelettes de serveur implémentés pour communiquer entre eux. Ces classes gèrent le regroupement/décompression des données, appelé marshalling, depuis les types de données Java sur le client vers les types de données CORBA, puis de nouveau vers les types de données Java sur le serveur. Ces classes stub et squelette gèrent également la transmission des messages IIOP qui se produisent entre elles.

Faites un clic droit sur l'icône Attendees.idl et sélectionnez Créer dans le menu contextuel qui apparaît, qui générera les cours nécessaires.

Pour générer un serveur CORBA qui implémentera la méthode "numéro", sélectionnez Fichier, Nouveau... dans le menu de la barre d'outils. Sélectionnez l'onglet Entreprise dans la galerie d'objets, puis sélectionnez Application serveur CORBA. L'utilisation du fichier IDL nouvellement créé créera les fichiers serveur restants. De plus, une interface graphique sera créée pour pouvoir héberger le serveur.

Fichiers créés :

Participants .java : simplement une interface Java qui correspond à notre interface IDL. L'objet Java qui fournit l'implémentation de notre objet Attendees implémente cette interface.

AttendeesHelper.java : une classe abstraite utilisée par le client pour se lier à un objet serveur et fournissant une variété de méthodes de service pour récupérer les identifiants des participants, restreindre les CORBAServices récupérés à partir de TOUS les types, etc. AttendeesHolder.java : utilisée par Helper, cette classe est une classe de support qui offre la possibilité de transmettre un objet Attendees en tant que paramètre CORBA.

AttendeesOperations.java : une classe d'interface utilisée comme alternative à la liaison squelette via des délégués. Cela permet également de surmonter les limitations des classes Java dont elles ne peuvent pas hériter de plusieurs interfaces.

AttendeesPOA.java : classe Java POA à partir de laquelle l'objet réel sera implémenté.

AttendeesPOATie.java : Il s'agit d'une implémentation déléguée pour l'interface. Chaque instance de la classe tie doit être initialisée avec une instance de la classe d'implémentation qui implémente la classe Operation à laquelle elle délègue pour chaque opération.

AttendeesStub.java : utilisé par Helper pour déléguer des appels de méthode à un objet distant, il s'agit d'un code de remplacement à utiliser côté client.

Côté serveur :

Bicon2000ServerApp.java : une application serveur qui chargera le ServerFrame et effectuera AttendeesImpl (implémentation).

AttendeesImpl .java : implémentation réelle. Il s'agit de la classe Java que nous allons modifier pour implémenter le résultat de l'appel de la méthode "number". Dans cette méthode, nous renvoyons (int)(1.2 * lastYear).

ServerFrame .java : classe Frame (GUI).

ServerMonitor.java : conserve le fichier journal du serveur et constitue le conteneur de toutes les pages de Server Monitor.

ServerMonitorPage.java : implémente une page Server Monitor pour afficher les compteurs d'interface.

ServerResources.java : contient des chaînes d'application serveur pour la localisation.

Pour générer un client pouvant appeler la méthode numérique, sélectionnez Fichier, Nouveau... dans le menu supérieur. Sélectionnez l'onglet Entreprise dans la galerie d'objets. Lors de l'utilisation d'IDL, cela générera la classe ClientImpl. Pour tester rapidement le client, créez une méthode principale dans cette classe.

public static void main (String args) lève une exception ( System.out.println(new AttendeesClientImpl().number(10000)); )

Exécuter la ou les applications

Pour exécuter la ou les applications, lancez d’abord SmartAgent. Sélectionnez Outils dans le menu Barre d'outils et sélectionnez VisiBroker Smart Agent. Si le menu est coché, Smart Agent est déjà en cours d'exécution. Faites un clic droit sur bicon2000ServerApp.java et sélectionnez Exécuter dans le menu contextuel. Pour démarrer le client, sélectionnez AttendeesClientImpl et sélectionnez Exécuter dans le menu contextuel. Le résultat devrait renvoyer 12 000.

Vous disposez désormais d’une véritable application CORBA fonctionnelle. JBuilder réduit non seulement le travail fastidieux de développement d'une application en ligne de commande EMACS, mais il vous permet également de générer rapidement des prototypes et des preuves de concept pour votre programme en quelques minutes seulement.

Agent intelligent

Pour bien comprendre le code généré par Jbuilder, nous devons apprendre quelques nouveaux détails sur l'implémentation de VisiBroker CORBA. La première nouveauté à aborder est le Smart Agent, parfois désigné sous le nom d'exécutable OSAGENT. Smart Agent est un processus de démarrage spécifique à la plateforme qui fournit des services d'annuaire aux clients et aux implémentations CORBA. On le compare parfois à un opérateur d'information, les demandes des clients étant comparées à un appel téléphonique vers un service d'information, où le client demande le nom d'une autre personne et l'opérateur met en relation les deux parties. Lorsqu'un client tente de se connecter à un objet spécifique, le Smart Agent localise une instance de cet objet et renvoie une référence au client. De l'autre côté de ce modèle, lorsque des implémentations d'objets deviennent disponibles, elles s'enregistrent auprès du Smart Agent afin que les clients puissent les trouver. De même, lorsque l’implémentation se termine, elle se désenregistre auprès du Smart Agent. Si, pour une raison quelconque, l'implémentation d'un objet se termine sans avoir été extrait par le Smart Agent, l'agent finira par le détecter via ping et vérifiera l'implémentation lui-même. Smart Agent est l'un des processus clés du modèle VisiBroker CORBA pour faire abstraction de l'objet. l'emplacement de l'objet, il recherche simplement l'objet lorsqu'une requête arrive. Le client n'a pas besoin de savoir si l'objet se trouve sur le même ordinateur, ou globalement, ou s'il s'exécute sur un système d'exploitation différent.

Implémentation d'objets côté serveur public class AttendeesImpl extends bicon2000.bicon2000.AttendeesPOA ( String name = "Participants"; ... ... public int number(int lastYear) ( ServerMonitor.log("(" + name + ") AttendeesImpl.java number()" ); return (int)(1.2 * lastYear); ) ) Code côté serveur // SmartAgent écoute sur le port UDP 14000. // Ceci est souvent appelé le battement de cœur du smartagent. System.getProperties().put("ORBagentPort", "14000"); // Initialisation de l'ORB org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, System.getProperties()); // Obtention de RootPOA ; au lieu d'initialiser le BOA, //nous obtenons une référence au //le POA racine POA poaRoot = POAHelper.narrow (orb.resolve_initial_references("RootPOA")); // Définition d'une constante de chaîne qui enregistrera ce // nom de l'objet = "Participants" ; // Définition de la politique (durée de vie) dans Persistent org.omg.CORBA.Policy AttendeesPolicies = ( poaRoot.create_lifespan_policy(LifespanPolicyValue.PERSISTENT) ); // Dans BOA, un objet devient persistant (stocké) s'il reçoit // un nom. Certains BOA peuvent prendre en charge à la fois des objets éphémères et //persistants. Cependant, un seul POA ne peut prendre en charge que des objets //stockés ou éphémères. Le poa racine que nous avons obtenu ci-dessus // ​​ne prend en charge que les objets de courte durée. Cependant, nous avons // besoin de l'objet stocké. Par conséquent, nous allons créer un autre //POA avec une politique de cycle de vie de « persistance ». POA poaAttendees = poaRoot.create_POA(nom + "_poa", poaRoot.the_POAManager(), AttendeesPolicies); // Dans BOA, un serviteur est un objet CORBA. Mais dans POA, un serviteur et // un objet CORBA sont différents. Au lieu de créer un objet CORBA et de définir // obj_is_ready pour activer cet objet, nous allons maintenant créer // un serviteur et l'activer dans le POA à l'aide d'un ID. L'opérateur new //AttendeesImpl()) est une implémentation d'un serviteur et active //ce serviteur en utilisant l'ID dans myPOA poaAttendees.activate_object_with_id (name.getBytes(), new AttendeesImpl()); // Activer le gestionnaire POA poaRoot.the_POAManager().activate(); // Attendez que les requêtes arrivent orb.run(); Code côté client public class AttendeesClientImpl ( boolean bInitialized = false; bicon2000.bicon2000.Attendees _attendees; com.borland.cx.OrbConnect orbConnect1; String name = "Participants"; public AttendeesClientImpl() ( try ( jbInit();) catch (Exception ex) ( ex.printStackTrace(); ) ) private void jbInit() lance une exception ( ) public boolean init() ( if (!bInitialized) ( try ( org.omg. CORBA.ORB orbe = nul ;

Extension de notre exemple

L'application Attendees que nous avons écrite était un exemple simplifié à l'extrême de ce à quoi pourrait ressembler un véritable système de présence. Pour évaluer plus en détail IDL et les avantages de CORBA, nous reviendrons brièvement sur notre projet Attendees. Dans notre exercice, les informations Attendees ont été renvoyées en appelant une méthode simple sur l'objet Attendees. Nous devrons peut-être ajouter des changements en pourcentage, des pourcentages par jour, des réservations d'hôtel et une gestion des exceptions pour savoir si une méthode donnée n'est pas disponible pour appeler. Notre IDL ressemblerait alors à ceci :

/** * Attendees.idl * Exemple IDL pour une conférence Borland/Inprise * */ module bicon2000 ( /** * L'interface Person définit une personne */ interface Person ( string getName(); ); /** * Les participants interface définit un objet de conférence * Attendees. Il s'agit d'une conférence de trois jours. */ interface Attendees ( enum ConferenceDays ( DAY1, DAY2, DAY3 ); exception RoomNotAvailable (); long number(in long lastYear); float percentIncrease(); float percentIncreaseOnDay (en ConferenceDays whichDay); booléen bookHotelRoom (le participant en personne) augmente (RoomNotAvailable);

Notez que ce module possède plusieurs interfaces. Deux squelettes et un proxy sont les codes de deux objets qui seront générés lors de l'exécution d'IDL2JAVA. Il est important de comprendre qu'IDL est un langage très riche qui peut décrire complètement la conception de notre objet et, une fois compilé, il ne nous reste finalement que l'implémentation des objets Java, comme pour toute classe Java. Cela démontre que la conception des applications CORBA n’impose aucune restriction ni ne fait d’hypothèses quant à une mise en œuvre possible.

Services VisiBroker supplémentaires

Dans notre exemple, nous avons abordé de nombreuses fonctionnalités de base fournies par VisiBroker en particulier, et l'architecture CORBA en général. Il existe cependant plusieurs services et processus supplémentaires non utilisés dans cet exemple et qui sont souvent nécessaires dans les développements CORBA à grande échelle. Voici quelques-uns de ces composants :

Console - Inprise VisiBroker Console est un outil qui vous permet d'afficher et de gérer les services VisiBroker ORB à l'aide d'une interface graphique. Plus précisément, vous pouvez utiliser les navigateurs de services ORB pour gérer les serveurs d'objets, gérer la configuration des contrôleurs d'accès, afficher le référentiel d'interface, modifier les contextes de dénomination, rechercher des instances d'objet et afficher les OAD sur votre réseau. La conception de VisiBroker Console est similaire aux interfaces de console graphique d'Inprise Application Server et d'Inprise AppCenter.

SmartAgent - Smart Agent VisiBroker (osagent) est un service d'annuaire dynamique et distribué qui fournit des fonctionnalités utilisées à la fois par les programmes clients et les implémentations d'objets. Smart Agent doit être exécuté sur au moins un hôte de votre réseau local. Lorsque votre programme client appelle bind() sur un objet, le Smart Agent le consulte automatiquement. Le Smart Agent localise l'implémentation spécifiée afin qu'une connexion puisse être établie entre le client et l'implémentation. La communication avec Smart Agent est totalement transparente pour le programme client. Si la stratégie POA est définie sur PERSISTENT et que activate_with_id est utilisé, le Smart Agent enregistre l'objet ou l'implémentation afin que le programme client puisse l'utiliser. Lorsqu'un objet ou une implémentation est désactivé, Smart Agent le supprime de la liste des objets disponibles. Comme pour les programmes clients, la communication avec Smart Agent est totalement transparente pour l'implémentation de l'objet.

OsFind- Si nous voulons nous assurer que le Smart Agent connaît l'objet, nous pouvons le vérifier en exécutant un utilitaire VisiBroker spécifique à la plate-forme appelé osfind. Lorsque nous exécutons osfind, nous voyons que notre objet est enregistré auprès du Smart Agent et est disponible pour les demandes des clients. SmartAgent, exécuté dans un environnement Windows, fournit une console pour afficher les objets enregistrés. De plus, vous pouvez afficher visuellement le fichier journal et les liaisons. OSFIND rapporte également des informations concernant Object Activation Demon, un processus spécial VisiBroker qui peut activer les serveurs en tant que fournisseurs d'objets à la demande des clients.

Débogueur

RMI-over-IIOP - RMI (invocation de méthodes à distance) est un mécanisme Java qui vous permet de créer et d'utiliser des objets dans un environnement distribué. En ce sens, RMI est un ORB spécifique au langage (Java) et non conforme à CORBA. OMG a publié une spécification de mappage Java vers IDL qui permet aux classes Java écrites à l'aide de RMI d'interagir avec les objets CORBA en utilisant le codage IIOP. VisiBroker dispose de deux compilateurs qui vous permettent d'adapter vos classes Java existantes pour fonctionner avec d'autres objets qui utilisent l'ORB VisiBroker. Le compilateur java2iiop vous permet d'adapter vos classes compatibles RMI pour utiliser IIOP, en générant les classes squelette, stub et Helper complètes correspondantes. Le compilateur java2idl génère des IDL à partir de vos classes Java, vous permettant de les implémenter dans des langages autres que Java.

Interface Repository est un service facultatif qui peut fournir des détails concernant une interface spécifique à la demande des clients. De cette façon, les clients peuvent interroger le référentiel d'interface pour connaître les méthodes proposées par l'interface et les appeler à leur tour. Un référentiel d'interface peut également être utilisé pour stocker des informations supplémentaires concernant une interface, telles que des informations d'activation.

ADO- L'OAD ou Object Activation Demon mentionné précédemment brièvement peut être utilisé pour activer les processus serveur soit à la demande, lorsque le client demande des objets à l'intérieur de ceux-ci, soit en appelant des méthodes sur ceux-ci. OAD utilise les mappages stockés dans le référentiel d'interfaces pour déterminer quels serveurs fournissent quelles interfaces.

Services de dénomination- Vous permet de rechercher des objets en fonction d'un contexte de dénomination - un objet spécialisé qui stocke une référence d'objet unique et une liaison de dénomination. Grâce aux services de noms, les développeurs et les administrateurs peuvent attribuer des noms logiques aux objets qui pourront ensuite être trouvés à l'aide de ces noms.

Intercepteurs/gestionnaires d'événements/déclencheurs- Ces services peuvent être écrits pour offrir un meilleur contrôle sur la liaison et la reliure, la gestion des échecs et la fourniture de services de niveau inférieur tels que l'équilibrage de charge ou le chiffrement.

Portier- Gatekeeper permet aux clients VisiBroker de contacter des serveurs situés sur différents réseaux, tout en négociant simultanément les restrictions de sécurité imposées par les navigateurs Web et les pare-feu. Gatekeeper agit comme une passerelle entre les clients et le serveur lorsque les restrictions de sécurité imposées par la sécurité du bac à sable Java ou les filtres réseau empêchent les clients de communiquer directement avec les serveurs. Gatekeeper est un serveur proxy GIOP entièrement conforme aux spécifications du pare-feu OMG CORBA. De plus, Gatekeeper fournit les fonctionnalités suivantes : amorçage, transparence de l'emplacement, capacité de rappel, tunneling HTTP, agissant comme un simple serveur Web pour le chargement des classes, contrôles d'accès personnalisables basés sur IP, équilibrage de charge, tolérance aux pannes.

Interface d'appel dynamique- Cette interface permet aux clients CORBA d'appeler les méthodes d'exécution par leur nom et de découvrir ces méthodes au moment de l'exécution en accédant au référentiel d'interface. DII vous permet de créer des clients sans utiliser de fichiers stub générés à partir du code IDL.

Interface squelette dynamique- Comme DII, DSI permet de former des implémentations d'objets sans étendre les classes squelettes. Il peut être utile de permettre à un objet d'implémenter plusieurs interfaces.

Reliure à cravate- Garantit que les implémentations d'objets CORBA sont créées à partir de classes qui n'héritent pas de org.omg.CORBA.Object. La délégation d'objet, connue sous le nom de liaison d'objet, permet au serveur d'effectuer des appels directs à la véritable implémentation de l'objet. Ceci est particulièrement utile lors de la création d'objets CORBA à partir de classes existantes, puisque Java ne prend pas en charge l'héritage multiple.

Talons intelligents- Des stubs qui interfèrent avec tous les appels de méthode, fournissant de bons gestionnaires d'interruptions pour ajouter du code pour la sécurité, la mise en cache et l'équilibrage de charge.

Conclusion

Nous avons discuté des principaux concepts de VisiBroker CORBA et implémenté un exemple simple de son utilisation. Même si l'on peut affirmer sans se tromper que les applications du monde réel sont beaucoup plus complexes, cet exemple représente bon nombre des concepts généraux de l'architecture CORBA. Il est clair que CORBA est une norme consensuelle de l'industrie qui a considérablement modifié la façon dont le développement des systèmes d'information peut être réalisé en mettant en œuvre des systèmes d'objets distribués et en passant des systèmes existants aux architectures modernes. En lisant cet article, les développeurs et les architectes seront en mesure d'acquérir une compréhension claire de l'architecture de base CORBA et des motivations de son utilisation, ainsi que des connaissances pratiques sur la façon de maximiser les avantages de VisiBroker dans les futures applications développées dans l'environnement JBuilder.

CORBA (Architecture de courtier de requêtes d'objets communs)- technologie orientée objet pour créer des applications distribuées. La technologie est basée sur l'utilisation Courtier de requêtes d'objets (ORB) pour envoyer et recevoir de manière transparente des demandes d'objets dans un environnement distribué. La technologie vous permet de créer des applications à partir d'objets distribués implémentés dans divers langages de programmation. Standard CORBA développé Groupe de gestion d'objets (OMG).

Architecture CORBA

Cette section fournit un bref aperçu CORBA comme décrit dans la spécification OH MON DIEU version 3.0. Les exigences de ce document peuvent être satisfaites à des degrés divers par des mises en œuvre réelles. courtiers en demandes d'objet. Sur la fig. La figure 2.1 représente une requête envoyée par un client à une implémentation d'objet. Client est une entité qui souhaite effectuer une opération sur un objet, et Mise en œuvre est la collection de code et de données qui implémente réellement l'objet.

ORBE est responsable de tous les mécanismes nécessaires pour trouver une implémentation appropriée d'un objet pour une demande, préparer l'implémentation pour recevoir la demande, et transfert de données en cours remplir la demande. L'interface visible par le client est totalement indépendante de l'emplacement d'implémentation de l'objet, du langage de programmation dans lequel il est écrit et de tout autre aspect non reflété dans la spécification de l'interface.

L'interface d'appel dynamique et l'interface stub ont la même sémantique, de sorte que le destinataire du message ne peut pas déterminer comment la demande a été envoyée. ORBE trouve le code d'implémentation d'objet approprié, lui envoie des paramètres et donne le contrôle via IDL squelette ou squelette dynamique (Fig. 2.4). Les squelettes sont spécifiques à une interface et à un adaptateur d'objet particuliers. Lors de l'exécution de la requête, l'implémentation peut utiliser certains services ORBE via un adaptateur d'objet. Lorsque la demande est terminée, les valeurs de contrôle et de résultat sont renvoyées au client.

Une implémentation d'objet peut choisir l'adaptateur d'objet à utiliser en fonction des services dont elle a besoin. Sur la fig. La figure 2.5 montre comment les informations d'interface et d'implémentation sont mises à la disposition des clients et des implémentations d'objets. Les interfaces sont décrites dans IDL ou en utilisant un référentiel d'interface. Leurs descriptions sont utilisées pour générer des stubs et des squelettes de clients pour la mise en œuvre.

Les informations sur l'implémentation de l'objet sont fournies lors de l'installation et stockées dans le référentiel d'implémentation, puis utilisées lors de la livraison de la demande.