Conseils pour la programmation côté client du service ORB

Chaque échange requête et réponse Internet InterORB Protocol (IIOP) comprend un ORB côté client et un ORB côté serveur. Il est important que toutes les applications qui utilisent IIOP soient correctement programmées pour communiquer avec l'Object Request Broker (ORB) côté client.

Les conseils suivants vous aideront à vous assurer qu'une application utilisant IIOP pour gérer les échanges requête et réponse est correctement programmée pour communiquer avec l'Object Request Broker (ORB) côté client.

Résolution des références initiales aux services

Les applications client peuvent utiliser les propriétés ORBInitRef et ORBDefaultInitRef pour configurer l'emplacement réseau qui permet au service ORB de rechercher un service (par exemple, un service de nommage). Une fois définies, ces propriétés sont incluses dans les paramètres utilisés pour initialiser l'ORB, comme indiqué dans l'exemple ci-dessous :
org.omg.CORBA.ORB.init(java.lang.String[] args, 
                       java.util.Properties props)

Vous pouvez définir ces propriétés dans le code client ou à l'aide d'un argument de ligne de commande. Il est possible d'indiquer différents emplacements de service en utilisant plusieurs paramètres de propriété ORBInitRef (un pour chaque service) mais vous ne devez indiquer qu'une seule valeur ORBDefaultInitRef. Pour plus d'informations sur les propriétés et l'ordre de priorité utilisé par l'ORB pour localiser les services, reportez-vous à la spécification CORBA/IIOP.

Si vous souhaitez les définir dans le code client, les deux propriétés correspondent respectivement à com.ibm.CORBA.ORBInitRef.nom_service et com.ibm.CORBA.ORBDefaultInitRef. Par exemple, pour indiquer que le service de nommage (NameService) se trouve sur sample.server.com sur le port 2809, indiquez corbaloc::sample.server.com:2809/NameService pour la propriété com.ibm.CORBA.ORBInitRef.NameService.

Si vous souhaitez utiliser l'argument de ligne de commande, ces propriétés correspondent respectivement à -ORBInitRef et -ORBDefaultInitRef. Pour localiser le même service de noms spécifié précédemment, utilisez la commande Java™ suivante :

Une fois que ces propriétés sont définies pour les services pris en charge par l'ORB, les applications Java Platform, Enterprise Edition (Java EE) peuvent appeler la fonction resolve_initial_references sur l'ORB, conformément à la spécification CORBA/IIOP, pour obtenir la référence initiale à un service donné.

API à utiliser pour obtenir une instance d'ORB

Pour les applications Java EE, vous pouvez utiliser les procédures ci-dessous. Toutefois, il est fortement recommandé d'utiliser la procédure JNDI (Java Naming and Directory Interface) pour s'assurer que la même instance d'ORB est utilisée dans l'ensemble de l'application client. Cette procédure permet d'éviter que des incohérences apparaissent lorsque différentes instances d'ORB sont utilisées.

Procédure JNDI : Pour les applications Java EE (y compris les beans enterprise, les clients Java EE et les servlets), vous pouvez obtenir une instance d'ORB en créant un objet JNDI InitialContext et en recherchant l'ORB portant le nom java:comp/ORB, comme indiqué dans l'exemple suivant :
javax.naming.Context ctx = new javax.naming.InitialContext();
org.omg.CORBA.ORB orb = 
   (org.omg.CORBA.ORB)javax.rmi.PortableRemoteObject.narrow(ctx.lookup("java:comp/ORB"), 
                                                            org.omg.CORBA.ORB.class);
L'instance ORB obtenue à l'aide de JNDI est un objet singleton, partagé par tous les Java EE composants qui s'exécutent dans le même processus de machine virtuelle Java.
Évitez les ennuis : Vous devez utiliser l'approche JNDI si vous souhaitez profiter de la fonctionnalité WLM et du basculement de cluster au sein de l'application. Pour plus d'informations sur l'obtention d'un contexte initial provenant d'un cluster de serveurs, reportez-vous à l'exemple décrivant l'utilisation d'une URL d'objet CORBA avec plusieurs adresses de serveur de nom, dans la rubrique relative à l'obtention d'un contexte initial par la définition de la propriété d'URL du fournisseur.
Procédure CORBA : Etant donné que les applications de clients légers ne s'exécutent pas dans un conteneur Java EE, elles ne peuvent pas utiliser les interfaces JNDI pour rechercher l'ORB. Dans ce cas, vous pouvez obtenir une instance d'ORB en utilisant les interfaces de programmation CORBA :
java.util.Properties props = new java.util.Properties();
java.lang.String[] args = new java.lang.String[0];
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, props);

Contrairement à la procédure JNDI, la spécification CORBA requiert la création d'une instance d'ORB lors de chaque appel de la méthode ORB.init. Si vous devez redéfinir les paramètres par défaut de l'ORB, vous pouvez ajouter les paramètres de propriété de l'ORB à l'objet Propriétés transmis dans l'appel de méthode ORB.init().

L'utilisation de la méthode com.ibm.ejs.oa.EJSORB.getORBinstance prise en charge dans les versions précédentes est déconseillée.

Limitations des API lors du partage d'une instance d'ORB entre plusieurs composants d'une application Java EE

Pour des raisons de performances, il est souvent utile de partager une instance d'ORB entre les différents composants d'une application Java EE. Conformément à la spécification Java EE, version 1.3, tous les conteneurs web et EJB fournissent une instance ORB dans l'espace de noms JNDI sous la forme java:comp/ORB. Chaque conteneur peut partager cette instance avec les différents composants de l'application mais ce n'est pas une obligation. Pour garantir l'isolement des composants d'application, le code d'application doit respecter les restrictions suivantes :
  • Ne pas appeler les méthodes d'arrêt ou de destruction de l'ORB.
  • Ne pas appeler les méthodes org.omg.CORBA_2_3.ORB, register_value_factory ou unregister_value_factory

En outre, ne partagez pas l'instance d'ORB entre les composants de différentes applications Java EE.

Utilisation obligatoire des scripts rmic et idlj fournis avec IBM Developer Kit

L'environnement JRE (Java Runtime Environment) utilisé par ce produit comprend les outils rmic et idlj. Ces outils permettent de générer des liaisons de langage Java pour le protocole CORBA/IIOP.

Lors de l'installation du produit, les outils sont installés dans le racine_serveur_app/java/ibm_bin annuaire. Versions de ces outils incluses avec les kits de développement Java dans le$JAVA_HOME/bin répertoire autre que le IBM® Le kit de développement installé avec ce produit est incompatible avec ce produit.

Lorsque vous installez ce produit, le racine_serveur_app/java/ibm_bin Le répertoire est inclus dans l'ordre de recherche $PATH pour permettre l'utilisation des scripts rmic et idlj fournis par IBM. Parce que les scripts sont dans le racine_serveur_app/java/ibm_bin répertoire au lieu du standard JRE racine_serveur_app/java/bin répertoire, il est peu probable que vous puissiez les écraser lors de l'application de la maintenance à un JRE non fourni par IBM.

Outre les outils rmic et idlj, JRE comprend des fichiers IDL (Interface Definition Language). Les fichiers se basent sur ceux définis par le groupe OMG (Object Management Group) et peuvent être utilisés par les applications qui ont besoin d'une définition IDL d'interfaces ORB sélectionnées. Les fichiers sont placés dans le racine_serveur_app/java/ibm_lib annuaire.

Avant d'utiliser l'outil rmic ou idlj, assurez-vous que le racine_serveur_app/java/ibm_bin Le répertoire est inclus dans l'ordre de recherche des variables PATH approprié dans l'environnement. Si votre application utilise des fichiers IDL dans le racine_serveur_app/java/ibm_lib répertoire, assurez-vous également que le répertoire est inclus dans la variable PATH.