Meilleures pratiques de programmation du client de type ActiveX
Le meilleur moyen d'accéder aux composants Java™ est d'utiliser le langage Java. Il est recommandé de programmer autant que possible en Java et de n'utiliser qu'une interface simple entre le conteneur d'automatisation COM (tel que Visual Basic) et le code Java. Cette interface évite tout problème de surcharge et de performances lors des déplacements dans l'interface.
- Instructions pour Visual Basic
- CScript et Windows Scripting Host (WSH)
- Instructions pour Active Server Pages
- Instructions pour J2EE
Instructions pour Visual Basic
Les instructions suivantes sont conçues pour vous permettre d'optimiser l'utilisation de la passerelle ActiveX vers EJB avec Visual Basic :
- Lancez la réplication Visual Basic avec le fichier launchClientXJB.bat. Lorsque vous devez exécuter votre application Visual Basic avec le débogueur Visual Basic, exécutez l'environnement IDE (integrated development environment) de Visual Basic au sein de l'environnement de la passerelle ActiveX vers EJB. Une fois le projet Visual Basic créé, vous pouvez le lancer à partir d'une ligne de commande en tapant, par exemple, launchClientXJB MonApplication.vbp. Vous pouvez également exécuter l'application Visual Basic indépendamment, dans l'environnement de la passerelle ActiveX vers EJB, en modifiant le raccourci Visual Basic dans le menu Démarrer de Windows, afin que le fichier launchClientXJB.bat précède l'appel au fichier VB6.EXE.
- Quittez l'environnement de développement intégré (IDE) de Visual Basic avant
de déboguer les programmes.
Dans la mesure où le code de la machine JVM (Java Virtual Machine) établit un lien avec le processus en cours d'exécution, vous devez quittez l'éditeur de Visual Basic avant de déboguer votre programme. Si vous lancez le processus, puis quittez votre programme au sein de l'IDE de Visual Basic, le code JVM poursuit son exécution et vous établissez un lien avec le même code JVM lorsque XJBInit() est appelé par le débogueur. Cela pose des problèmes lorsque vous tentez de mettre à jour les arguments XJBInit() (tels que, classpath), car les modifications ne sont appliquées qu'après le redémarrage du programme Visual Basic.
- Stockez l'objet XJB.JClassFactory globalement.
Dans la mesure où vous ne pouvez pas décharger ou réinitialiser le code JVM, placez l'objet XJB.JClassFactory résultant en mémoire cache en tant que variable globale. La surcharge imposée par le traitement de cet objet en tant que variable globale ou par la transmission d'une référence unique est largement préférable à la création d'un nouvel objet XJB.JClassFactory et à des appels multiples de l'argument XJBInit().
CScript et Windows Scripting Host (WSH)
- Activez l'environnement ActiveX vers EJB. Exécutez les fichiers VBScript dans l'environnement de la passerelle ActiveX vers EJB, afin d'exécuter les fichiers VBScript dans les fichiers .vbs. Le script peut être exécuté de deux façons :
- launchClientXJB MyScript.vbs
- launchClientXJB cscript MyScript.vbs
Instructions pour Active Server Pages
Les instructions suivantes sont conçues pour vous permettre d'optimiser l'utilisation de la passerelle ActiveX vers EJB avec le logiciel Active Server Pages :
- Utilisez les fonctions auxiliaires ActiveX vers EJB à partir de l'application ASP.
Dans la mesure où le code Active Server Pages (ASP) utilise généralement VBScript, vous pouvez utiliser les fonctions auxiliaires incluses dans tous les environnements VBScript après quelques modifications superficielles. Pour plus de détails sur ces fonctions auxiliaires, reportez-vous à Fonctions auxiliaires pour la conversion des types de données. Pour procéder à l'exécution dans un environnement ASP, supprimez ou modifiez toutes les références aux objets Server, Request, Response, Application et Session ; par exemple, modifiez Server.CreateObject pour obtenir CreateObject.
- Définissez globalement le chemin JRE dans le système.
L'objet XJB.JClassFactory doit pouvoir trouver les DLL (dynamic link library) du contexte d'exécution Java dès son initialisation. Avec Internet Information Server, vous ne pouvez pas spécifier les chemins de processus indépendamment ; ils doivent être définis dans la variable système PATH. Vous ne pouvez disposer que d'une seule version JVM sur la machine exécutant l'application ASP. Tenez également compte du fait que la modification de la variable système PATH implique le redémarrage de la machine exécutant Internet Information Server de façon à ce que ce programme prenne en compte la modification.
- Définissez la variable d'environnement système TEMP.
Lorsque la variable d'environnement TEMP n'est pas définie, Internet Information Server stocke tous les fichiers temporaires dans le répertoire WINNT, ce qui n'est généralement pas souhaité.
- Utilisez un processus isolé ou un isolement complet.
Lorsque vous utilisez la passerelle ActiveX vers Java avec un logiciel ASP, il est recommandé de créer votre application web dans son propre processus. Vous ne pouvez charger qu'une seule instruction JVM dans un seul processus, et si vous souhaitez exécuter plusieurs applications avec différentes options d'environnement JVM, telles que différentes variables classpath, vous devez disposer de processus distincts.
- Utilisez l'option de déchargement de l'application.
Lorsque vous déboguez votre application, utilisez la commande Décharger lorsque vous consultez les propriétés de l'application ASP dans la console d'administration d'Internet Information Server afin de décharger le processus de la mémoire et par conséquent, de décharger le code JVM.
- N'exécutez qu'un seul processus par application.
N'utilisez qu'une seule application ASP par application J2EE ou environnement JVM dans votre environnement ASP. Si vous avez besoin de chemins de classes ou de paramètres de JVM distincts, vous devez utiliser des applications ASP distinctes (répertoires virtuels avec un processus isolé ou un isolement complet).
- Stockez l'objet XJB.JClassFactory dans l'environnement de l'application.
Dans la mesure où une relation univoque est requise entre une instruction et un processus JVM, et dans la mesure où le code JVM ne peut pas rompre la liaison à un processus n'y s'y arrêter indépendamment, placez l'objet XJB.JClassFactory en mémoire cache dans l'environnement de l'exploitation et n'appelez la méthode XJBInit() qu'une seule fois.
Dans la mesure où la passerelle ActiveX vers EJB utilise un Free-Threaded Marshaler, profitez du fait qu'Internet Information Server et l'environnement ASP utilisent des unités d'exécution multiples. Si vous choisissez de réinitialiser l'objet XJB.JClassFactory dans l'environnement de la page (variables locales), la méthode XJBInit() ne peut initialiser que votre variable XJB.JClassFactory locale. Il est plus efficace d'utiliser la méthode XJBInit() en une seule opération.
- Utilisez les fonctions de conversion VBScript.
Dans la mesure où le code VBScript ne prend en charge que les types de données Variant, utilisez les fonctions CStr(), CByte(), CBool(), CCur(), CInt(), Clng(), CSng() et CDbl() pour spécifier à la passerelle activeX vers EJB le type de données à utiliser ; par exemple oMyObject.Foo(CDbl(1.234)).
Instructions pour J2EE
Les instructions suivantes sont conçues pour vous permettre d'optimiser l'utilisation de la passerelle ActiveX vers EJB avec l'environnement J2EE :
- Stockez les objets conteneur client globalement.
Dans la mesure où vous ne pouvez avoir qu'une seule instruction JVM par processus et un seul conteneur client J2EE (com.ibm.websphere.client.applicationclient.launchClient) par instruction JVM, n'initialisez votre conteneur client J2EE qu'une seule fois et réutilisez-le. Pour les applications ASP, stockez le conteneur client J2EE dans une variable au niveau de l'application et ne l'initialisez qu'une seule fois (soit suite à l'événement Application_OnStart() dans le fichier global.asa, soit en utilisant la fonction de vérification IsEmpty()).
L'un des inconvénients du stockage global de l'objet conteneur client est que vous ne pouvez pas changer les paramètres du conteneur client sans détruire l'objet et en créer un nouveau. Ces paramètres incluent le fichier EAR, l'hôte d'amorçage (BootstrapHost), le chemin de classes, etc. Si vous exécutez une application Visual Basic et devez changer les paramètres du conteneur client, vous devez arrêter l'application et la redémarrer. Lorsque vous exécutez une application ASP, vous devez au préalable décharger l'application d'Internet Information Server (reportez-vous à "Utilisez le bouton Décharger de l'application" sous les instructions pour Active Server Pages). Chargez ensuite l'application Active Server Pages avec les différents paramètres du conteneur client. Ces paramètres spécifient le premier chargement de l'application ASP. Du fait que le conteneur client est stocké sur Internet Information Server, tous les clients de navigation partagent les paramètres en utilisant l'application ASP. Ce comportement est normal pour le code ASP mais peut entraîner des confusions lorsque vous tentez d'exécuter un programme avec la même application ASP sur plusieurs serveurs d'applications WebSphere, ce qui n'est pas pris en charge.
- Réutilisez le répertoire temporaire personnalisé pour les extractions de
fichiers EAR.
Par défaut, le conteneur client lance et extrait le fichier .ear de l'application dans votre répertoire temp, puis configure le chargeur de classes de l'unité d'exécution (thread) afin d'utiliser le répertoire du fichier EAR extrait et tous les fichiers JAR inclus dans le manifeste du fichier JAR du client. Ce processus est long et, en raison des limitations liées à l'arrêt de la machine JVM suite au verrouillage JNI (Java Native Interface) et de fichiers, ces fichiers ne sont jamais nettoyés.
De façon plus précise, lorsque la méthode launch() du conteneur client est appelée, elle extrait le fichier EAR dans un répertoire, sans nom standard, figurant dans un répertoire temporaire sur votre disque dur. Le chargeur de classe d'unités d'exécution Java actif est alors modifié pour faire référence à ce nouveau répertoire, qui verrouille ensuite les fichiers qu'il contient. Dans un client Java J2EE standard, ces fichiers sont nettoyés automatiquement lorsque l'application se termine. Ce nettoyage se produit lorsque le point d'ancrage d'arrêt du conteneur client est appelé (ce qui ne se produit jamais dans la passerelle ActiveX vers EJB) et que celui-ci laisse le répertoire temporaire en place.
Pour éviter ces problèmes, indiquez le répertoire d'extraction du fichier EAR en configurant la propriété système Java com.ibm.websphere.client.applicationclient.archivedir avant d'appeler la méthode launch() du conteneur client. Lorsque ce répertoire n'existe pas ou est vide, le fichier EAR est extrait normalement. Si le fichier EAR a déjà été extrait, le répertoire est utilisé de nouveau. Cette fonction est particulièrement importante pour les processus serveur (tels que ASP), qui peuvent s'arrêter et redémarrer et, si nécessaire, appeler la méthode launchClient() plusieurs fois.
Lorsque vous devez mettre à jour un fichier EAR, commencez par supprimer son répertoire temporaire. Sinon, la création de l'objet conteneur client va extraire le nouveau fichier EAR dans le répertoire temporaire existant. Si vous ne l'avez pas supprimé ou modifié la valeur de la propriété système désignant ce répertoire, le conteneur client utilisera le fichier extrait et ne mettra pas à jour votre fichier EAR.
Remarque : Lorsque vous spécifiez la propriété com.ibm.websphere.client.applicationclient.archivedir, assurez-vous que le répertoire indiqué est unique pour chaque fichier EAR. Par exemple, ne spécifiez pas le même nom de répertoire pour les fichiers MyEar1.ear et MyEar2.ear.Si vous choisissez de ne pas utiliser cette propriété système, consultez régulièrement votre répertoire Windows temp et supprimez les sous-répertoires WSTMP*. Ces sous-répertoires peuvent occuper très rapidement un espace considérable sur le disque dur.