Procedimientos recomendados de programación del cliente ActiveX

El mejor modo para acceder a los componentes Java™ es utilizar el lenguaje Java. Se le recomienda que efectúe toda la programación posible en el lenguaje Java y que utilice una pequeña y sencilla interfaz entre el contenedor COM Automation (por ejemplo, Visual Basic) y el código Java. Esta interfaz evita cualquier problema de carga adicional y rendimiento que puede producirse cuando se desplaza por la interfaz.

procedimientos recomendados: Se tratan los temas siguientes:
  • Directrices de Visual Basic
  • CScript y Windows Scripting Host
  • Directrices de Active Server Pages
  • Directrices de J2EE

Directrices de Visual Basic

Las directrices siguientes están ideadas para ayudarle a mejorar el uso del puente de ActiveX a EJB con Visual Basic:

  • Inicie la duplicación de Visual Basic mediante el archivo launchClientXJB.bat. Si desea ejecutar la aplicación Visual Basic mediante el depurador Visual Basic, ejecute el entorno de desarrollo integrado (IDE) de Visual Basic en el entorno del puente de ActiveX a EJB. Después de crear el proyecto Visual Basic, puede iniciarlo desde una línea de mandatos; por ejemplo, launchClientXJB MiAplicación.vbp. También puede iniciar la aplicación Visual Basic sola en el entorno ActiveX a EJB, modificando el acceso directo a Visual Basic en el menú Inicio de Windows de modo que el archivo launchClientXJB.bat preceda a la llamada al archivo VB6.EXE.
  • Salga de IDE de Visual Basic antes de depurar programas.

    Dado que el código JVM (Máquina virtual Java) se asocia al proceso en ejecución, debe salir del editor de Visual Basic antes de depurar el programa. Si ejecuta el proceso y, a continuación, sale del programa en IDE de Visual Basic, el código JVM continúa ejecutándose y se volverá a asociar el mismo código JVM cuando el depurador llame a XJBInit(). Esto ocasionará problemas cuando intente actualizar los argumentos de XJBInit() (por ejemplo, classpath), ya que los cambios no se aplicarán hasta que reinicie el programa Visual Basic.

  • Almacene el objeto XJB.JClassFactory globalmente.

    Ya que no puede descargar ni reinicializar el código JVM, almacene en la memoria caché el objeto XJB.JClassFactory resultante como una variable global. La carga adicional de manejar este objeto como una variable global o de pasar una sola referencia es mucho menor que la de volver a crear un objeto XJB.JClassFactory nuevo y llamar al argumento XJBInit() más de una vez.

CScript y Windows Scripting Host

Las directrices siguientes están ideadas para ayudarle a mejorar el uso del puente de ActiveX a EJB con CScript y WSH (Windows Scripting Host):
  • Inicie el entorno ActiveX a EJB.
    Inicie los archivos VBScript del entorno del puente de ActiveX a EJB, para ejecutar los archivos VBScript en archivos .vbs. Para iniciar el script hay dos métodos comunes:
    • launchClientXJB MyScript.vbs
    • launchClientXJB cscript MyScript.vbs

Directrices de Active Server Pages

Las directrices siguientes están ideadas para ayudarle a mejorar el uso del puente de ActiveX a EJB con el software Active Server Pages:

  • Utilice las funciones de ayudante de ActiveX a EJB desde la aplicación Active Server Pages.

    Dado que el código ASP (Active Server Pages) generalmente utiliza VBScript, puede utilizar las funciones de ayudante incluidas en cualquier entorno VBScript con ligeros cambios. Para obtener más información acerca de estas funciones de ayudante, consulte las funciones de ayudante para la conversión de tipos de datos. Para ejecutar fuera del entorno ASP, suprima o modifique todas las referencias a los objetos Server, Request, Response, Application y Session; por ejemplo, modifique Server.CreateObject por CreateObject.

  • Establezca la vía de acceso JRE globalmente en el sistema.

    El objeto XJB.JClassFactory debe poder encontrar la biblioteca de enlaces dinámicos (DLL) de tiempo de ejecución Java durante la inicialización. En Internet Information Server, no puede especificar una vía de acceso para sus procesos de forma independiente; debe establecer las vías de acceso de proceso en la variable PATH del sistema. Sólo puede tener disponible una versión JVM en una máquina que utilice la aplicación ASP. Asimismo, recuerde que después de modificar la variable PATH del sistema debe reiniciar la máquina Internet Information Server, para que el servidor Internet Information Server pueda ver el cambio.

  • Establece la variable de entorno TEMP del sistema.

    Si la variable de entorno TEMP del sistema no se establece, Internet Information Server almacena todos los archivos temporales en el directorio WINNT, lo que no es aconsejable.

  • Utilice un nivel alto de aislamiento o un proceso aislado.

    Cuando utilice el puente de ActiveX a Java con el software Active Server Pages, se le recomienda que cree su aplicación web con su propio proceso. Solamente puede cargar una instrucción JVM en un solo proceso y si desea tener más de una aplicación en ejecución con opciones de entorno JVM diferentes (por ejemplo, classpaths diferentes), tendrá que tener procesos separados.

  • Utilización de la opción de descarga de aplicación

    Cuando depure la aplicación, utilice Unload para visualizar las propiedades de la aplicación ASP en la consola administrativa de Internet Information Server para descargar el proceso de la memoria y, por lo tanto, descargar el código de la JVM.

  • Ejecute un proceso por aplicación.

    Utilice solamente una aplicación ASP por aplicación J2EE o entorno JVM, en su entorno ASP. Si necesita classpaths o valores JVM diferentes, necesita aplicaciones ASP diferentes (directorio virtuales con un alto nivel de aislamiento o un proceso aislado).

  • Almacene el objeto XJB.JClassFactory en el ámbito de la aplicación.

    Dado que se necesita una relación de uno a uno entre una instrucción JVM y un proceso, y dado que el código JVM no se puede nunca desasociar ni concluir de un proceso de forma independiente, almacene en la memoria caché el objeto XJB.JClassFactory en el ámbito de la aplicación y llame al método XJBInit() solamente una vez.

    Dado que el puente de ActiveX a EJB emplea una presentación sin hebras, puede beneficiarse de que Internet Information Server y el entorno ASP tienen muchas hebras. Si opta por renicializar el objeto XJB.JClassFactory en el ámbito de página (variables locales), entonces el método XJBInit() solamente puede inicializar la variable XJB.JClassFactory local. Es más eficaz utilizar el método XJBInit() una vez.

  • Utilice las funciones de conversión VBScript.

    Dado que el código VBScript solamente soporta los tipos de datos variables, utilice las funciones CStr(), CByte(), CBool(), CCur(), CInt(), Clng(), CSng() y CDbl() para indicar al puente de ActiveX a EJB qué tipos de datos está utilizando; por ejemplo oMyObject.Foo(CDbl(1.234)).

Directrices de J2EE

Las directrices siguientes están ideadas para ayudarle a mejorar el uso del puente de ActiveX a EJB con el entorno J2EE:

  • Almacena los objetos del contenedor cliente globalmente.

    Dado que solamente puede tener una instrucción JVM por proceso y un solo contenedor cliente J2EE (com.ibm.websphere.client.applicationclient.launchClient) por instrucción JVM, inicialice el contenedor cliente J2EE sólo una vez y vuelva a utilizarlo. Para las aplicaciones ASP, almacene el contenedor cliente J2EE en una variable de nivel de aplicación e inicialícelo solamente una vez (ya sea en el suceso Application_OnStart() del archivo global.asa o comprobando si es IsEmpty()).

    Un efecto colateral de almacenar el objeto de contenedor cliente globalmente es que no puede cambiar los parámetros del contenedor cliente sin destruir el objeto y crear uno nuevo. Estos parámetros incluyen el archivo EAR, BootstrapHost, classpath, etc. Si ejecuta una aplicación Visual Basic y desea cambiar los parámetros del contenedor cliente, debe finalizar la aplicación y volver a iniciarla. Si ejecuta una aplicación Active Server Pages, en primer lugar debe descargar la aplicación desde Internet Information Server (consulte el tema "Utilización del botón de descarga de aplicaciones" en las directrices de Active Server Pages). A continuación, cargue la aplicación Active Server Pages con parámetros de contenedor cliente diferentes. Los parámetros se establecen la primera vez que se carga la aplicación Active Server Pages. Dado que el contenedor cliente se almacena en Internet Information Server, todos los clientes de navegador comparten los parámetros utilizando la aplicación Active Server Pages. Este comportamiento es normal para el código de Active Server Pages pero puede confundirle cuando intente ejecutar servidores WebSphere Application Server diferentes utilizando la misma aplicación Active Server Pages, lo cual no está soportado.

  • Vuelva a utilizar el directorio temporal personalizado para extraer el archivo EAR.

    De forma predeterminada, el contenedor cliente inicia y extrae el archivo .ear de la aplicación en el directorio temp, y luego configura el cargador de clases de la hebra para que utilice el directorio del archivo EAR extraído y los archivos JAR incluidos en el manifiesto JAR del cliente. Este proceso ocupa mucho tiempo y debido a algunas limitaciones del proceso de conclusión de JVM a través de JNI (Java Native Interface) y del bloqueo de archivos, estos archivos no se borran nunca.

    En concreto, cada vez que se invoca el método del contenedor de cliente, extrae el archivo EAR en un nombre de directorio temporal aleatorio del directorio temporal de la unidad de disco duro. El cargador de clases de hebra Java actual se cambia a continuación para que apunte a este directorio extraído que, a su vez, bloquea los archivos en él. En un cliente Java J2EE normal, estos archivos se borran automáticamente cuando se sale de la aplicación. Este proceso de borrado se produce cuando se llama al enlace (hook) del contenedor cliente (lo que no ocurre nunca en el puente de ActiveX a EJB), lo cual deja el directorio temporal allí.

    Para evitar estos problemas, puede especificar un directorio que extraiga el archivo EAR estableciendo la propiedad del sistema Java com.ibm.websphere.client.applicationclient.archivedir antes de llamar al método launch() del contenedor cliente. Si el directorio no existe o está vacío, el archivo EAR se extrae del modo habitual. Si el archivo EAR ya se había extraído, se vuelve a utilizar el directorio. Esta función es especialmente importante para procesos servidor (por ejemplo, ASP), que puede detener y reiniciar, llamando potencialmente al método launchClient() varias veces.

    Si necesita actualizar el archivo EAR, suprima en primer lugar el directorio temporal. La próxima vez que cree el objeto de contenedor cliente, éste extraerá el nuevo archivo EAR en el directorio temporal. Si no suprime el directorio temporal o cambia el valor de la propiedad del sistema para que apunte a un directorio temporal diferente, el contenedor de cliente vuelve a utilizar el archivo EAR extraído actualmente y no utiliza el archivo EAR modificado.

    Nota: Cuando especifique la propiedad com.ibm.websphere.client.applicationclient.archivedir, asegúrese de que el directorio que especifica sea exclusivo para cada archivo EAR que utilice. Por ejemplo, no apunte los archivos MyEar1.ear y MyEar2.ear al mismo directorio.

    Si opta por no usar esta propiedad de sistema, borre con regularidad los subdirectorios WSTMP* del directorio de Windows temp. En un período de tiempo relativamente corto, estos subdirectorios pueden ocupar una considerable cantidad de espacio en la unidad de disco duro.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rcli_activexbestpractice
File name: rcli_activexbestpractice.html