Interoperatividad .Net-J2EE mediante WS e IIOP. Javier Viguera

Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6. Trabajo desarrollado
6.1. Justificación
El desarrollo de aplicaciones empresariales y aplicaciones distribuidas ha sufrido un
auge muy importante durante los últimos años. Frente a esta nueva demanda surgen dos
grandes plataformas distintas para el desarrollo de este tipo de aplicaciones: J2EE de
Sun Microsystems y .NET de Microsoft.
Ambas dan soporte a las necesidades de las aplicaciones empresariales por lo que la
decisión de elegir una u otra para el desarrollo de las nuevas aplicaciones dependen de
otros factores, como pueden ser factores comerciales, políticas de empresa, continuidad
de una línea técnica de desarrollo, modernización de las tecnologías empleadas, etc.
Todos estos factores pueden hacer que dentro de una empresa o entre empresas haya
aplicaciones desarrolladas en ambas plataformas destinadas a interactuar entre sí.
Esto supone un problema ya que al estar desarrolladas en diferentes plataformas no
“hablan el mismo idioma” y por lo tanto la comunicación entre ambas no es posible a
menos que se utilice alguna tecnología de comunicación que ambas plataformas
conozcan.
Este es el caso que nos aborda y que resolveremos mediante dos tecnologías disponibles
en el mercado, Servicios Web e IIOP.Net.
Ambas tecnologías tienen características y comportamientos diferentes en función del
ancho de banda disponible para la comunicación, complejidad de las aplicaciones, etc.
Se tratará de analizar dichos comportamientos y ver las características que ofrecen
ambas mediante el desarrollo de un entorno de pruebas de rendimiento, cliente-servidor
(.Net-J2EE), desarrollado usando ambas plataformas, que refleje las características de
ambas tecnologías en función del ancho de banda disponible.
Este entorno de pruebas servirá además de ejemplo para el desarrollo de aplicaciones
mixtas que tengan que interoperar entre sí y para decidir qué tecnología es la más
adecuada en función de los requisitos de las aplicaciones y de la red de comunicaciones
disponible para su interconexión.
6.2. Entorno de pruebas de rendimiento
6.2.1. Introducción
Como se ha mencionado anteriormente de forma general, el entorno de pruebas de
rendimiento tiene como objetivo analizar el comportamiento de las tecnologías
Servicios Web e IIOP.Net como medio de interconexión de las plataformas .Net y
J2EE.
Esta aplicación consistirá en una aplicación cliente-servidor, el cliente desarrollado en la
plataforma .Net y la parte servidora en la plataforma J2EE, que estarán comunicados
mediante ambas tecnologías, Servicio Web e IIOP.
Mediante esta aplicación mediremos el rendimiento de ambos protocolos en función del
tamaño de los datos que se intercambian y del ancho de banda disponible sacando
gráficas comparativas de dichos rendimientos.
Desde el cliente se podrá elegir el tamaño del dato a intercambiar, limitar el ancho de
banda disponible y la tecnología a emplear en la comunicación. La lógica de negocio de
la parte servidora será única, y será expuesta para ser accedida a través de Servicios
Web y de IIOP simultáneamente. De esta manera, independientemente de cuál de las
dos tecnologías se elija, se accederá a la misma implementación de la lógica de negocio
haciendo más fácil su mantenimiento al tener que actualizar el código sólo en un sitio.
104
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6.2.2. Estructura de la aplicación
Para la parte cliente se ha optado por usar la plataforma .Net y para la parte servidora
J2EE. Esta elección se ha basado en los siguientes criterios:
• Cliente .Net:
o .Net cuenta con el entorno de desarrollo Visual Studio, que proporciona
una herramienta de desarrollo de IHM (Interfaz Hombre-Máquina) muy
potente y sencillo de usar.
o El lenguaje C# de la plataforma .Net es muy potente y con una sintaxis
similar a la de Java, por lo que a un programador acostumbrado a usar
Java no le resulta costoso desarrollar en este lenguaje.
o La mayoría de las aplicaciones mixtas (interoperatividad .Net-J2EE)
usan para la parte cliente .Net por lo que haciendo el cliente .Net
abordamos la configuración más común del problema de las aplicaciones
mixtas.
•
Servidor J2EE:
o Se estableció mucho antes que la plataforma .Net por lo que domina en
el ambiente corporativo, en particular como servidor de aplicaciones.
o La mayoría de las aplicaciones mixtas (interoperatividad .Net-J2EE)
usan para la parte servidora J2EE por lo que haciendo la parte servidora
J2EE abordamos la configuración más común del problema de las
aplicaciones mixtas.
Realizar el entorno de manera inversa (cliente Java, servidor .Net) sería de una utilidad
mucho menor ya que la gran mayoría de las aplicaciones mixtas necesitan la
interoperatividad contraria. Además, sería necesario el estudio de un servidor de
aplicaciones .Net que soporte el acceso a servicios mediante Servicios Web e IIOP.
La aplicación desarrollada tendrá una estructura que permita la comunicación e
interoperatividad de las plataformas .Net Framework y J2EE a través de un cliente en
lenguaje C# de .Net que accederá a unos servicios Java.
Estos servicios Java están encapsulados en un EJB de sesión sin estado que serán
expuestos al exterior de dos maneras diferentes:
• Como un EJB para que sean accedidos mediante RMI-IIOP
• Como un Servicios Web para que sean accedidos mediante SOAP
Habrá por lo tanto dos proxies de acceso a los servicios de la parte servidora, uno para
Servicios Web y otro para EJB. La manera de acceder a estos proxies será publicada en
servicios de nombrado para que el cliente pueda acceder a ellos independientemente de
la ubicación específica en la que se encuentren.
El Proxy para el acceso al EJB mediante RMI-IIOP será publicado en dos servicios de
directorio, JNDI (Java Naming and Directory Interface) y COSNaming. El primero será
el que se utilice cuando el acceso sea mediante RMI y el segundo cuando sea a través de
IIOP. En nuestro caso sólo nos interesa COSNaming ya que el acceso al Proxy EJB se
realizará solamente mediante IIOP.
El Proxy para el acceso mediante Servicios Web se publicará en el servicio de
nombrado UDDI (Universal Description, Discovery, and Integration).
Los proxies del lado cliente buscarán en dicho servicio de nombrado los proxies del
lado servidor y serán posteriormente invocados.
105
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
En el caso de Servicios Web, el contrato que el cliente necesita saber para conectarse
con el Proxy servidor es un fichero WSDL (Web Service Definition Language) que está
en lenguaje XML. La llamada que realiza el cliente también será XML encapsulado en
SOAP por lo que no será necesario realizar ninguna conversión de tipos ni adaptación ni
traducción. El cliente manda texto plano y el servidor entiende ese texto plano.
El caso de IIOP es más complejo ya que el cliente .Net necesita invocar de alguna
manera al interfaz Java que expone el Proxy EJB. Aquí es donde entra en juego
IIOP.Net y la herramienta, también desarrollada en este Proyecto Fin de Carrera, Java.Net (ver 6.3), para la generación de clases .Net a partir de clases Java. El cliente tendrá
una interfaz .Net equivalente al interfaz expuesto por el EJB. Durante la invocación se
realizaría una traducción de esa interfaz de manera que el servidor de aplicación supiera
que se está invocando a la interfaz deseada.
A continuación se muestra una figura de la arquitectura implementada en el desarrollo
de la aplicación:
Figura 32: Arquitectura de la aplicación Entorno de pruebas de rendimiento
6.2.3. Desarrollo
6.2.3.1. Implementación del EJB
Como se ha comentado anteriormente la implementación de los métodos que el cliente
invocará estarán encapsulados en un EJB de sesión sin estado. Para la implementación
de dicho EJB se ha utilizado el entorno de desarrollo para Java Eclipse y un plugin para
dicho entorno llamado JBossIDE. Este plugin permitirá crear EJBs para el servidor de
aplicaciones JBoss de forma sencilla sin tener que escribir manualmente los descriptores
de despliegue. Además mediante el plugin JBossWS podremos exponer de forma
sencilla los EJBs como Servicios Web.
6.2.3.1.1. JBossIDE
6.2.3.1.1.1. Introducción
106
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Para la implementación de los EJBs y de su lógica de negocio usaremos el entorno de
desarrollo Eclipse más el plugin JbossIDE. Este plugin ofrece las siguientes
características:
• Soporte extensivo e intuitivo para XDoclet, que es es un motor de código abierto
para Java cuya función es la generación de código.
• Depurar y monitorizar el servidor de aplicaciones Jboss y controlar sus ciclos de
vida.
• Una forma sencilla de configurar el empaquetado de ficheros.
• Una forma sencilla de desplegar los ficheros empaquetados en el servidor de
aplicaciones Jboss.
• Varios asistentes J2EE para facilitar y simplificar el desarrollo J2EE.
Implementaremos un ejemplo que sirva de muestra y referencia para usar el plugin
JbossIDE para el desarrollo de un EJB.
Este ejemplo constará de las siguientes partes:
• Creación del proyecto J2EE.
• Creación del EJB
• Generación de los ficheros relacionados con el EJB mediante la configuración de
XDoclet .
• Empaquetado de los ficheros que componen el EJB.
• Configuración del JBoss para ser lanzado dentro de Eclipse.
• Despliegue del EJB en el servidor de aplicaciones.
• Depurado de los EJBs desplegados en el servidor de aplicaciones.
6.2.3.1.1.2. Creación de un proyecto J2EE
•
Crearemos un nuevo proyecto J2EE mediante la opción:
File > New > Project... y elegimos JBoss-IDE > J2EE Projects > J2EE 1.4 Project.
Figura 33: JBossIDE: Nuevo proyecto J2EE
•
Introducimos el nombre del proyecto y pulsamos el botón Next
107
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
•
Javier Viguera Muñoz
Creamos una carpeta para el código fuente llamada src y nos aseguramos que la
carpeta de salida por defecto sea bin.
Figura 34: JBossIDE: Configuración de carpeta de código de fuente y carpeta de salida
•
En el explorador de paquetes el nuevo proyecto tendría que tener la siguiente
apariencia:
Figura 35: JBossIDE: Apariencia del nuevo proyecto
6.2.3.1.1.3. Creación de un EJB
Por simplicidad crearemos un EJB de sesión sin estado. Para ello seguiremos los
siguientes pasos:
• Crear un nuevo EJB de sesión mediante la opción:
File > New > Other...y elegir JBoss-IDE > EJB Components > Session Bean
108
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 36: JBossIDE: Crear un nuevo EJB
•
Elegir una ruta de paquetes para las clases, un nombre para la clase (terminado en
Bean) y asegurarnos que hemos seleccionado stateless, ejbCreate() Method,
y
Remote, Local o Both en función del modo de acceso que queramos que tenga el
EJB.
Figura 37: JBossIDE: Configuración del nuevo EJB
Una vez hecho esto el aspecto del proyecto debería ser el siguiente:
109
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 38: JBossIDE: Aspecto del nuevo EJB
• Creación de los métodos de negocio de los EJBs:
Pulsar con el botón derecho sobre la clase y seleccionar la opción J2EE >
Add Business Method
Figura 39: JBossIDE: Nuevo método de negocio
Seleccionar el nombre, los parámetros, el tipo devuelto, las excepciones y el tipo de
acceso al método.
110
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 40: JBossIDE: Configuración del nuevo método de negocio
•
Implementar el cuerpo del nuevo método de negocio creado.
6.2.3.1.1.4. Generación de los ficheros asociados al EJB
Para generar de forma automática los ficheros asociados al EJB (interfaces y
descriptores) es necesario crear previamente una configuración XDoclet.
Los pasos a seguir para crear una nueva configuración XDoclet son los siguientes:
• Activar XDoclet
o Pulsar con el botón derecho en el proyecto y seleccionar Properties
o En la página de propiedades seleccionar XDoclet configuration
o Comprobar que esté seleccionada la casilla Enable XDoclet
•
•
Creación de la configuración de XDoclet para el EJB
o Pulsar el botón Add…Seleccionar un nombre para la configuración y
pulsar Ok.
Configuración del ejbdoclet
o Seleccionar la nueva configuración.
o Pulsar con el botón derecho en el área inferior y seleccionar Add Doclet
o De la lista que aparece seleccionar ejbdoclet.
o En la lista de propiedades del ejbdoclet establecer la propiedad setDir a
“src”.
o En la lista de propiedades del ejbdoclet establecer la propiedad ejbSpec a
“2.0”.
111
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 41: JBossIDE: Configuración de XDoclet para la generación automática de ficheros
La configuración ahora tiene un ejbdoclet que genera ficheros en la carpeta “src” para
EJBs versión “2.0”.
• Configuración del fileset
o Seleccionar el ejbdoclet creado.
o Pulsar con el botón derecho en el área inferior y seleccionar Add.
o De la lista que aparece seleccionar fileset.
o En la lista de propiedades del fileset establecer la propiedad dir a “src”.
o En la lista de propiedades del fileset deseleccionar la propiedad exclude.
o En la lista de propiedades del fileset establecer la propiedad includes a
“**/*Bean.java”.
Figura 42: JBossIDE-Configuración XDoclet: fileset
La configuración ejbdoclet tiene ahora un fileset que contiene una carpeta “src” y todos
los ficheros que terminen en Bean.java.
•
Configuración del descriptor de despliegue
o Seleccionar el ejbdoclet creado.
o Pulsar con el botón derecho en el área inferior y seleccionar Add.
o De la lista que aparece seleccionar deploymentdescriptor.
o En la lista de propiedades del deploymentdescriptor establecer la
propiedad destDir a “src/META-INF”.
112
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 43: JBossIDE-Configuración XDoclet: Descriptor de despliegue
Ahora todos los descriptores de despliegue creados se colocaran en “src/META-INF”.
• Configuración del Jboss
o Seleccionar el ejbdoclet creado.
o Pulsar con el botón derecho en el área inferior y seleccionar Add.
o De la lista que aparece seleccionar jboss.
o En la lista de propiedades del jboss establecer la propiedad setDir a
“src/META-INF”.
o En la lista de propiedades del jboss establecer la propiedad Version a
“3.0”.
Figura 44: JBossIDE-Configuración XDoclet: JBoss
Ahora los ficheros descriptores de despliegue específicos de Jboss generados se
colocarán en la carpeta “src/META-INF”;
•
Configuración de la sustitución de paquetes
o Seleccionar el ejbdoclet creado.
o Pulsar con el botón derecho en el área inferior y seleccionar Add.
o De la lista que aparece seleccionar packageSubstitution.
o En la lista de propiedades del packageSubstitutión establecer la
propiedad packages a “ejb”.
o En la lista de propiedades del packageSubstitutión establecer la
propiedad substituteWith a “interfaces”.
113
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 45: JBossIDE: JBossIDE-Configuración XDoclet: Sustitución de paquetes
Ahora los interfaces generados se colocarán en el paquete “interfaces”
•
Configuración de los interfaces
o Seleccionar el ejbdoclet creado.
o Pulsar con el botón derecho en el área inferior y seleccionar Add.
o De la lista que aparece seleccionar remoteinterface.
o De la lista que aparece seleccionar homeinterface.
o De la lista que aparece seleccionar localhomeinterface.
o De la lista que aparece seleccionar localinterface.
Figura 46: JBossIDE-Configuración XDoclet: Interfaces
Con esto se generarán los interfaces home y remote tanto para el acceso local como para
el acceso remoto.
Con esto se termina la configuración para la generación de los ficheros asociados al
EJB. A partir de las clases que estén dentro del paquete “ejb” que terminen en Bean.java
se generarán interfaces en el paquete “interfaces”con los métodos de negocio del EJB.
Además se generarán los ficheros descriptores de despliegue tanto los específicos de
Jboss como los estándars para el EJB en particular.
Ahora para que se generen todos estos ficheros es necesario ejecutar esta nueva
configuración. Para ello hay que seleccionar el proyecto en cuestión, pulsar con el botón
114
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
derecho y seleccionar Run XDoclet. La ejecución XDoclet mostrará la salida en la
consola de Eclipse y debería tener el siguiente aspecto:
Figura 47: JBossIDE: Ejecutar XDoclet
Después de la ejecución de XDoclet, y habiendo refrescado previamente el proyecto se
debería haber creado un nuevo paquete “interfaces” con las interfaces requeridas y una
nueva carpeta “META-INF” con los ficheros descriptores de despliegue necesarios.
Figura 48: JBossIDE: Interfaces y ficheros descriptores de despligue generados
6.2.3.1.1.5. Empaquetado
JbossIDE proporciona una manera sencilla para empaquetar ficheros. No hay ninguna
restricción sobre lo que se puede empaquetar.
En este caso sólo es necesario crear dos ficheros, uno que empaquete todo el EJB, y otro
que empaquete sólo las interfaces que serán necesarias para el cliente que quiera invocar
el EJB. Sin embargo podrían hacerse tantos ficheros como sean necesarios.
El fichero Ejemplo.jar contendrá las clases y las interfaces del EJB, además de los
ficheros descriptores de despliegue ejb-jar.xml y jboss-jar.xml.
El fichero EjemploClient.jar contendrá los interfaces del EJB para que un cliente pueda
invocar los servicios ofrecidos por el EJB.
•
Ejemplo.jar
o Pulsar con el botón derecho en el proyecto y seleccionar Properties
o Selecciona la opción Packaging Configurations.
o Asegurarnos que está seleccionado en la parte superior Enable
Packaging.
115
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
o Pulsar el botón Add… y escribir el nombre que queramos que tenga el
fichero, en este caso Ejemplo.jar.
(NOTA: Este fichero se incluye en el CD del PFC, en la carpeta “ejemplos”)
Figura 49: JBossIDE: Configuración del empaquetado
Queremos añadir las clases y las interfaces del EJB compiladas, que estarán
en la carpeta “bin”, ya que se declaró como la carpeta de salida por defecto.
o Seleccionamos el nuevo fichero creado Ejemplo.jar, pulsamos con el
botón derecho y seleccionamos Add Folder.
Figura 50: JBossIDE: Configuración del empaquetado (Selección de carpetas I)
Aparecerá un nuevo cuadro de diálogo que nos permitirá seleccionar una
carpeta a agregar al fichero, ya sea perteneciente al proyecto o externa a él.
o Seleccionamos Proyect Folder y la carpeta “bin” del proyecto.
o Como sólo queremos incluir las clases y las interfaces, en el filtro
included pondremos sólo aquello que queremos incluir.
116
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 51: JBossIDE: Configuración del empaquetado (Selección de carpetas II)
o Ahora queremos incluir los ficheros de despliegue. Para ello
seleccionamos el nuevo fichero creado Ejemplo.jar, pulsamos con el
botón derecho y seleccionamos Add File.
Figura 52: JBossIDE: Configuración del empaquetado (Selección de ficheros I)
Aparecerá un nuevo cuadro de diálogo que nos permitirá seleccionar un
fichero a agregar, ya sea perteneciente al proyecto o externo a él.
o Pulsamos en Proyect File y seleccionamos el fichero “ejb-jar.xml”. En
Prefix ponemos la carpeta donde queremos que el fichero aparezca
dentro del fichero empaquetado, en este caso “META-INF”.
o Repetimos el proceso para el fichero “jboss.xml.
Figura 53: JBossIDE: Configuración del empaquetado (Selección de ficheros II)
117
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
El aspecto final de la configuración del empaquetado será la siguiente:
Figura 54: JBossIDE: Configuración del empaquetado (Aspecto final)
Ahora para que se genere el fichero empaquetado es necesario ejecutar esta nueva
configuración. Para ello hay que seleccionar el proyecto en cuestión, pulsar con el botón
derecho y seleccionar Run Packaging. La ejecución del empaquetado mostrará la salida
en la consola de Eclipse y debería tener el siguiente aspecto, habiéndose creado el
fichero resultante:
Figura 55: JBossIDE: Ejecución del empaquetado
6.2.3.1.1.6. Configuración y arranque del Jboss
Ahora vamos a proceder a configurar el servidor de aplicaciones para poder lanzarlo
desde dentro de Eclipse y así poder depurar el código del EJB posteriormente.
Los pasos a seguir serán los siguientes:
• Seleccionar el fichero resultante del apartado anterior, “Ejemplo.jar”, pulsar con el
botón derecho y seleccionar Debug on Server o Run on Server en función de si
queremos depurar el EJB o sólo desplegarlo pero sin depuración.
Figura 56: JBossIDE: Despliegue y depuración del EJB
118
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
•
Javier Viguera Muñoz
A continuación aparecerá un formulario para seleccionar el servidor de aplicaciones
en el que queremos desplegar el EJB. Si todavía no hemos configurado ninguno,
como es el caso, tendremos que definir uno nuevo con los datos del servidor de
aplicaciones que tenemos instalado.
Figura 57: JBossIDE: Despliegue y depuración del EJB (Configuración del JBoss I)
•
•
Seleccionamos Jboss AS 4.0 y pulsamos Next.
Elegimos un nombre para la configuración del servidor de aplicaciones, la ruta
donde tenemos instalado el servidor de aplicaciones, y la configuración del servidor
de aplicaciones que queremos arrancar (default,minimum,all). En nuestro caso
seleccionaremos la configuración all.
119
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 58: JBossIDE: Despliegue y depuración del EJB (Configuración del JBoss II)
•
En el siguiente formulario volvemos a poner el nombre para la nueva configuración
y pulsamos Next
120
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 59: JBossIDE: Despliegue y depuración del EJB (Configuración del JBoss III)
•
En el siguiente formulario se observan los componentes que se van a desplegar en el
servidor de aplicaciones, entre los cuales se debe encontrar nuestro EJB
“Ejemplo.jar”. Pulsamos Finish.
121
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 60: JBossIDE: Despliegue y depuración del EJB (Configuración del JBoss IV)
•
Una vez hecho todo esto se lanzará el servidor de aplicaciones y el EJB que
queremos depurar
Figura 61: JBossIDE: Despliegue y depuración del EJB (Configuración del JBoss V)
6.2.3.1.1.7. Depuración
Ahora sólo quedaría depurar la lógica de negocio del EJB para comprobar que el
comportamiento es el deseado. Para ello sólo es necesario poner un breakpoint en el
código donde queremos que la ejecución se pare y realizar el depurado como si de una
aplicación Java normal se tratase.
6.2.3.1.2. JBossWS Plugin
6.2.3.1.2.1. Introducción
122
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
JbossWS Plugin es un plugin de Eclipse especializado para trabajar con Servicios Web
para Jboss. Este plugin soporta las siguientes funcionalidades:
• Publicar POJO’s (Plain Old Java Objetct, que son clases Java simples que no
dependen de un framework en especial) y EJB’s como Servicios Web de Jboss.
• Consumir un Servicio Web existente.
• Implementar un contrato WSDL existente con JbossWS
• Añadir anotaciones de Servicio Web JSR-181 a una clase Java existente.
6.2.3.1.2.2. Instalación
Este plugin se distribuye junto con la versión JbossIDE2.0. Una vez instalado el plugin
es necesario configurarlo para que sepa dónde buscar las herramientas de las que
depende.
Para
ello
seleccionar
Windows>Preferentes>Jboss
Eclipse
IDE>Jboss
WS>Intergrated Tools.
Figura 62: JBossWS: Configuración de las herramientas que emplea
Sólo es necesario configurar la ruta de “JbossWS wstools” que estará en la carpeta “bin”
de la ruta de instalación del JBoss.
6.2.3.1.2.3. Activación de JbossWS
JbossWS se puede activar para cualquier tipo de proyecto Java. Esto permite publicar,
consumir e implementar Servicios Web desde la mayoría de tipos de proyectos (web,
ejb, jar, etc). Al activar JbossWS en un proyecto se creará un nuevo nodo en el proyecto
que corresponderá con el fichero soapui-project.xml y que contendrá todos los Servicios
Web manejados por el proyecto:
• Servicios Web publicados: generados a partir de EJBs/POJOs
• Servicios Web importados: importados desde Servicios Web externos.
Para activar JbossWS en un proyecto Java pulsamos con el botón derecho en el
proyecto en cuestión, seleccionamos JbossWS>Add JBossWS Nature. Aparecerá el
siguiente formulario:
123
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 63JBossWS: Activación de JBossWS para un proyecto Java
Estas opciones controlan el comportamiento básico de un proyecto JBossWS:
• Output Source Directory: Es el directorio dentro del proyecto en el que se generará
el código fuente cuando se implementa un Servicio Web.
• JBossWS wstools: Es la ruta del script “wstools” que utiliza JBossWS y que está
incluido en su distribución.
• Output Classes Directory: El directorio donde están las clases compiladas que van a
ser publicadas como Servicio Web
• Add JBossWS JAR: Añade la librería “jboss-client.jar” al classpath del proyecto.
Una vez que JBossWS ha sido activado, podremos encontrar esta configuración para
posteriores modificaciones en las propiedades del proyecto:
Figura 64: JBossWS: Configuración JBossWS para el proyecto Java
124
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6.2.3.1.2.4. Publicación de un EJB como Servicio Web
Con publicación de Servicio Web nos queremos referir al proceso de exposición de un
EJB o un POJO como Servicio Web usando JSR-109. El plugin JbossWS actuaría como
un encapsulador de la herramienta de Jboss “JbossWS”.
Una vez que JbossWS ha sido activado en el proyecto EJB sólo es necesario pulsar con
el botón derecho sobre el objeto que queremos publicar como Servicio Web y
configurar las opciones de publicación.
En nuestro caso, exposición de un EJB como Servicio Web, es necesario hacer una
copia de la interfaz que queremos exponer modificando la interfaz de la que extiende.
Esto es debido a un bug del plugin que estamos usando ya que está todavía en versión
Beta.
Haremos una copia del interfaz remoto de nuestro EJB reemplazando solamente la
interfaz javax.ejb.EJBObject por java.rmi.Remote. Esta nueva interfaz sería la que
queremos publicar como Servicio Web.
Pulsamos sobre esta nueva interfaz con el botón derecho y seleccionamos
“JBossWS>Publish as Web Service”
Figura 65: JBossWS: Publicar un EJB como WS I
Las opciones de configuración que habría que poner serían las siguientes:
125
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 66: JBossWS: Publicar un EJB como WS II
Interface: Es la interfaz Java que va a ser publicada. Se mostrará una lista con todas las
interfaces. Una lista con las interfaces implementadas por la clase seleccionada.
Service Name: Nombre para el servicio que va a ser publicado.
Style: Se selecciona si el servicio será “Document” o “RPC”.
Paremeter Style: Se selecciona si los parámetros deberían ser “wrapped” o “bare”. Este
último sólo para style “Document”.
Deploy as: Selecciona si el Servicio Web se debería desplegar como un POJO (usando
un servlet) o como un EJB.
Servlet/EJB-link: Dependiendo del parámetro “Deploy as”, especifica el nombre del
enlace del servlet o el EJB generado.
Deployment Descriptor: Especifica el descriptor de despliegue. Debería apuntar al
fichero “web.xml” (para POJOs) o al fichero “ejb-jar.xml” (para EJBs). Los
descriptores generados serán fusionados con los existentes en caso de que los haya.
Endpoint: El endpoint bajo el cual debería ser accesible el Servicio Web.
En la pestaña “Advanced” la configuración será la siguiente:
126
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 67: JBossWS: Publicar un EJB como WS III
Output WEB-INF Directory: Será el destino para los ficheros de mapeo/configuración
generados. El plugin fusionará los ficheros generados con los ficheros existentes en este
directorio.
Package: Nombre del paquete que se creará cuando se publique el POJO o el EJB. Se
usará las características de empaquetado disponibles en el plugin JbossIDE para crear
automáticamente un .war o un .jar (dependiendo de si es un POJO o un EJB) que podrá
ser desplegado directamente en Jboss.
Mapping-file: Es el nombre del fichero de mapeo JAX-RPC a crear, relativo al
parámetro “Output WEB-INF directory”. Si el fichero existe, los mapeos generados se
fusionarán en el fichero existente.
Target NS: Es el espacio de nombrado para el fichero WSDL generado. Por defecto será
“urn:<nombre del paquete>”.
Types NS: Es el espacio de nombrado para los tipos del xml-schema generados. Por
defecto será “urn:<nombre del paquete>.types”.
Mapping Override: Es un fichero de mapeo JAX-RPC que se usará en lugar del fichero
generado. Si se especifica, el fichero será copiado en el directorio “Output WEB-INF
directory” y la entrada en el fichero “webservices.xml” usará este fichero en su lugar.
WSDL Port to Use: Si se sobrescribe el fichero WSDL, es necesario especificar el
puerto real en el WSDL que debería ser considerado como el único en uso. Éste será
establecido en el fichero “webservices.xml”.
Import Interface: Controla si el fichero WSDL generado va a ser importado/actualizado
a un proyecto JbossWS subyacente. Deshabilitar esta opción si, por ejemplo, se
implementa un WSDL que ya ha sido importado.
127
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6.2.3.1.2.5. Generación
Una vez que la configuración ha sido establecida como es debido, se pulsa el botón
“Generate” que invocará la herramienta WSTools con la configuración establecida. La
salida se mostrará en consola:
Figura 68: JBossWS: Publicar un EJB como WS IV
6.2.3.1.2.6. Despliegue
Cuando el plugin está corriendo sobre JbossIDE y el despliegue de paquetes se
especifica como describe anteriormente, el plugin jbossws creará el .jar o el .war en la
raíz del proyecto, que contiene las clases de proyecto y el directorio de salida del
Servicio Web. Para desplegar el fichero sólo es necesario pulsar con el botón derecho y
seleccionar “Run as > Run on Server” y seleccionar una instancia configurada del
servidor Jboss.
El fichero .jar o .war se puede ver y modificar pulsando con el botón derecho en el
proyecto y seleccionando “Project Properties/Packaging Configurarions”.
128
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 69: JBossWS: Despliegue del EJB
6.2.3.2. Implementación del cliente
6.2.3.2.1. Introducción
Para la implementación del cliente hemos usado el entorno de desarrollo de .Net,
Microsoft Visual Studio 2005. Este entorno es el entorno de desarrollo más importante
para los lenguajes de la plataforma .Net. Ofrece herramientas muy útiles para el
desarrollo de aplicaciones así como la posibilidad instalar plugins que amplíen y
mejoren el funcionamiento de Visual Studio .Net
6.2.3.2.2. Interfaz hombre-máquina
El entorno de desarrollo Microsoft Visual Studio 2005 ofrece un diseñador muy potente
que permite realizar los interfaces hombre-máquina de una manera sencilla e intuitiva.
Mediante este diseñador se ha creado todo el entorno gráfico del cliente permitiendo al
usuario utilizar la aplicación cliente sin tener que conocer aspectos internos de la
programación del cliente.
Este interfaz hombre-máquina estará conectado a los proxies de comunicación con el
servidor de aplicaciones. En este caso habrá dos uno para acceder a los EJBs y otro para
acceder a Servicios Web.
129
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6.2.3.2.3. Proxies
Se implementarán unos proxies que servirán para realizar la comunicación entre el
cliente y el servidor. Estos proxies implementarán la interfaz IProxy que contendrá los
métodos necesarios para realizar una comunicación independientemente del protocolo
de comunicación que utilicemos. Esta interfaz IProxy contendrá los siguientes atributos,
métodos y eventos:
public delegate void TestExecutedEventHandler(int i,int tamDato,
double time);
public abstract event TestExecutedEventHandler TestExecuted;
private int numPruebas;
private int tamDato;
public const int DOWNLOAD = 0;
public const int UPLOAD = 1;
public const int UPLOAD_DOWNLOAD = 2;
protected abstract bool initializeCommunication(string host);
public abstract string execute(int mode);
public abstract void reset();
El método initializeCommunication(String host) está destinado a crear los canales de
comunicación y dejar todo listo para que se puedan realizar las llamadas a los métodos
de negocio de la parte servidora. La implementación de este método variará en función
del protocolo de comunicación que estemos usando.
El método execute(int mode) realizará la llamada a los métodos del servidor de
aplicaciones. En función del parámetro que se le pasa llamará a un método en el que la
comunicación será sólo de subida, sólo de bajada o de subida y bajada. Evidentemente,
dichos métodos deben estar implementados en el servidor de aplicaciones.
El método reset() resetea el proxy eliminando los canales, recursos y variables
necesarias para la comunicación entre el cliente y el servidor. La implementación de
este método variará en función del protocolo de comunicación que estemos usando.
El atributo numPruebas fijará el número de pruebas que se realizarán cuando se ejecute
el método execute(int mode).
El atributo tamDato fijará el tamaño de los datos que se intercambiarán entre cliente y
servidor, tanto si es de subida, bajada o subida y bajada.
Las constantes UPLOAD, DOWNLOAD y UPLOAD_DOWNLOAD serán las que se
pasen como parámetro al método execute().
El evento TestExecuted será lanzado cada vez que se realice una llamada dentro del
método execute(int mode). Al lanzarse este evento se ejecutarán todos los métodos que
hayan sido suscritos a dicho evento. El evento proporcionará el número de prueba
correspondiente dentro del número de pruebas que se realizan en el método execute(int
mode), el tamaño del dato de la prueba realizada y el tiempo que ha tardado en
realizarse esta prueba. Con estos datos se podrán analizar los resultados y mostrarlos en
gráficas comparativas.
130
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6.2.3.2.3.1. Proxy IIOP
El Proxy IIOP implementará la interfaz IProxy descrita anteriormente y será la
encargada de comunicar el cliente con el servidor de aplicaciones mediante el protocolo
de comunicaciones IIOP. Para ello es necesario que conozca las interfaces de acceso al
EJB con el que se quiere comunicar. Estas interfaces las conocerá gracias a la
herramienta desarrollada en este proyecto para convertir clases e interfaces Java a clases
o interfaces .Net (Ver apartado 6.3).
El cliente conoce cómo son las interfaces de acceso, pero le hace falta obtener una
referencia a la instancia de esas interfaces almacenadas en el servidor de aplicaciones y
no otras. Por lo tanto será necesario obtener dicha referencia mediante una búsqueda en
el servicio de nombrado COSNaming, lugar donde el servidor de aplicaciones ha
publicado dichas interfaces.
Para facilitar y aislar al desarrollador de la tecnología IIOP se ha creado una librería
encargada de facilitar las tareas más comunes en las comunicaciones IIOP, como
pueden ser la creación de canales, registro y desregistro de canales, comunicación bajo
SSL, etc. Esta librería se llama IIOPLibrary.dll y contendrá la implementación de los
siguientes métodos:
public static NamingContext configuraIIOP(string hostName);
public static NamingContext configuraIIOP(string hostName, string
port);
public static NamingContext connect(string server);
public static NamingContext connect(string server, string port);
public static NamingContext connectSSL(string server);
public static NamingContext connectSSL(string server, string port);
public static IiopChannel createIIOPChannel();
public static IiopClientChannel createIIOPSSLChannel(string
channelName, string expectedServerCertificate);
public static IiopClientChannel createIIOPSSLChannel(string
channelName, string expectedServerCertificate, string port);
public static void registerChannel();
public static void registerChannel(IiopChannel channel);
public static void registerChannel(IiopClientChannel channel);
public static void unRegisterChannel();
public static void unRegisterChannel(IiopChannel channel);
public static void unRegisterChannel(IiopClientChannel channel);
En el apéndice veremos el código fuente de esta librería.
6.2.3.2.3.2. Proxy Web Service
El Proxy Web Service implementará la interfaz IProxy descrita anteriormente y será el
encargado de comunicar el cliente con el servidor de aplicaciones mediante Servicios
Web. Para ello es necesario que conozca el fichero WSDL del Servicio Web publicado
en el servidor de aplicaciones. Esto podrá hacerse buscando en el servicio de nombrado
UDDI o pasándole directamente la URL donde puede encontrar dicho fichero. Una vez
obtenida la referencia a ese fichero WSDL ya podrá realizar las llamadas pertinentes a
los métodos de la lógica de negocio.
6.2.3.2.4. Herramienta para limitar el ancho de banda
131
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Para poder comprobar el comportamiento de los dos protocolos de comunicación en
diferentes entornos, con diferentes anchos de banda, es necesario disponer de una
herramienta que limite el ancho de banda de la conexión entre el cliente y el servidor,
tanto de subida como de bajada y ya sea conexión inalámbrica o mediante cable.
Para poder realizar esta limitación hemos contado con la ayuda de una aplicación de
terceros llamada BandWidth Controller (ver .
Figura 70: Despliegue de Bandwidth Controller
BandWidth Controller es una aplicación que realiza una gestión completa del ancho de
banda para comunicaciones basadas en el protocolo IP. Proporciona administradores de
red con limitación de tráfico y opciones de control de flujo. Todo el tráfico puede ser
controlado usando una combinación de niveles de servicio garantizados y limitaciones
de capacidad. El sistema de clasificación permite limitar todos los tipos de tráfico de red
como VoIP, vídeo, web y email.
La arquitectura de la herramienta consiste en un núcleo procesador dentro de la pila IP
que ejecuta servicios de bajo nivel como monitorización de tráfico y limitación de
capacidad. Los paquetes de red entrantes son inspeccionados y encolados según el tipo.
Los datos son posteriormente procesados por los sistemas automatizados de la
herramienta y por los definidos por el usuario antes de ser devueltos al sistema
operativo para su procesado habitual.
132
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 71: Arquitectura de Bandwidth Controller
6.2.4. Manual de usuario
6.2.4.1. Introducción
En este apartado vamos describir el funcionamiento de la aplicación desde el punto de
vista del usuario final, es decir, ver cómo pueden interactuar el usuario y la aplicación, y
qué tienen que hacer para conseguir de la aplicación lo que desee.
6.2.4.2. Arrancar la aplicación
Lo primero que tiene que hacer el usuario es arrancar la aplicación. El arranque de la
aplicación constará de dos partes diferenciadas. Por un lado arrancar el servidor de
aplicaciones JBoss que contendrá el EJB al que accederá el cliente y por otro lado
arracar el cliente.
6.2.4.2.1. Arrancar el servidor de aplicaciones
Para arrancar el servidor de aplicaciones habrá que ir a la carpeta donde se ha instalado
el servidor de aplicaciones JBoss y ejecutar el acceso directo runAll.bat o desde la línea
de comandos ejecutar el fichero run.bat con las opciones –c all: run.bat –c all.
De forma inmediata el servidor de aplicaciones comenzará a arrancarse mostrando una
pantalla con la información sobre el despliegue de los componentes.
133
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 72: Arranque y despliegue del servidor de aplicaciones
La siguiente figura muestra el momento del despliegue de nuestro EJB en el servidor de
aplicaciones:
Figura 73: Depliegue del EJB
El siguiente log indica que el servidor de aplicaciones ha sido arrancado y está listo para
ser usado.
Figura 74: Servidor de aplicaciones arrancado
6.2.4.2.2. Arrancar el cliente
Para arrancar el cliente sólo es necesario ir a la carpeta donde tengamos instalada la
aplicación cliente y ejecutar el fichero ClientePruebasRendimiento.exe. De forma
inmediata arrancará el interfaz gráfico de la aplicación cliente.
6.2.4.3. Uso de la aplicación cliente
6.2.4.3.1. Ventana inicial
Al iniciar la aplicación cliente aparecerá una ventana inicial en la que tendremos que
seleccionar el nombre de máquina o la dirección IP en la se encuentra el servidor de
aplicaciones.
134
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 75: Ventana incial
Se podrá escribir con texto libre el nombre de máquina o la IP del servidor de
aplicaciones o bien seleccionar uno de los que aparecen:
Figura 76: Selección del servidor de aplicaciones
La lista de los nombres ofrecidos puede ser modificada mediante un fichero XML que
se encuentra en la carpeta config llamado servers.xml y tiene el siguiente formato:
<servers>
<server>localhost</server>
<server>jviguera</server>
</servers>
Se podrían añadir tantos nombres o direcciones IP como se deseen simplemente
añadiendo nuevas líneas <server>newName</server> al fichero.
Pulsamos el botón aceptar y se dará paso a la ventana principal de la aplicación cliente.
6.2.4.3.2. Ventana principal
Este es el aspecto de la ventana principal de la aplicación:
135
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 77: Ventana principal
Iremos analizando cada uno de los componentes que forman la ventana principal.
Figura 78: Componentes de la ventana principal
6.2.4.3.3. Zona de pruebas IIOP
136
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 79: Zona de pruebas IIOP
La zona de pruebas IIOP es donde se configuran las opciones para las pruebas de
rendimiento mediante IIOP. Los parámetros a configurar son los siguientes:
Tamaño del dato: Será el tamaño del dato que se envíe, se reciba o se envíe y se reciba
en función de la opción Bajada, Subida o Bajada/Subida seleccionada.
Número de pruebas: Será el número de pruebas que se realizarán. En cada prueba se
envía, se recibe o se envía y se recibe un dato del tamaño del parámetro anteriormente
configurado.
Bajada-Subida-Bajada/Subida: Se seleccionará el modo en que queremos realizar la
comunicación cliente-servidor. Si seleccionamos Bajada, sólo se recibirán datos del
servidor. Si seleccionamos Subida, sólo se enviarán datos al servidor. Si seleccionamos
Bajada/Subida se enviarán y se recibirán datos del servidor.
También aparece una barra de progreso que nos indicará en nivel de progreso de las
pruebas que se están realizando.
Por último, y una vez configurados los parámetros deseados, se pulsará el botón
“Comenzar” para empezar las pruebas de rendimiento.
6.2.4.3.4. Zona de pruebas Servicio Web
Figura 80: Zona de pruebas WS
137
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
La zona de pruebas Servicio Web es donde se configuran las opciones para las pruebas
de rendimiento mediante Servicios Web. Los parámetros a configurar son los
siguientes:
Tamaño del dato: Será el tamaño del dato que se envíe, se reciba o se envíe y se reciba
en función de la opción Bajada, Subida o Bajada/Subida seleccionada.
Número de pruebas: Será el número de pruebas que se realizarán. En cada prueba se
envía, se recibe o se envía y se recibe un dato del tamaño del parámetro anteriormente
configurado.
Bajada-Subida-Bajada/Subida: Se seleccionará el modo en que queremos realizar la
comunicación cliente-servidor. Si seleccionamos Bajada, sólo se recibirán datos del
servidor. Si seleccionamos Subida, sólo se enviarán datos al servidor. Si seleccionamos
Bajada/Subida se enviarán y se recibirán datos del servidor.
También aparece una barra de progreso que nos indicará en nivel de progreso de las
pruebas que se están realizando.
Por último, y una vez configurados los parámetros deseados, se pulsará el botón
“Comenzar” para empezar las pruebas de rendimiento.
6.2.4.3.5. Zona de pruebas conjuntas IIOP-WS
Figura 81: Zona de pruebas conjuntas IIOP-WS
La zona de pruebas conjuntas es donde se configuran las opciones para las pruebas de
rendimiento que se realizan mediante Servicios Web e IIOP.
Lo que diferencia esta zona de pruebas de las anteriores es que se va aumentando
progresivamente el tamaño del dato desde el tamaño mínimo hasta el tamaño máximo.
El incremento que sufre el tamaño del dato en cada prueba es configurable.
Se podrá seleccionar si queremos usar ambos protocolos o sólo uno de ellos, y como en
las anteriores zonas, si queremos que el flujo de datos sea de subida, de bajada, o de
subida y bajada.
Los parámetros a configurar son los siguientes:
138
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Tamaño máximo del dato: Será el tamaño máximo del dato que se envíe, se reciba o se
envíe y se reciba en función de la opción Bajada, Subido o Bajada/Subida seleccionada.
Será el tamaño del dato que se utilice en la última prueba de la batería de pruebas que se
realizan desde esta zona.
Tamaño mínimo del dato: Será el tamaño mínimo del dato que se envíe, se reciba o se
envíe y se reciba en función de la opción Bajada, Subido o Bajada/Subida seleccionada.
Será el tamaño del dato que se utilice en la primera prueba de la batería de pruebas que
se realizan desde esta zona.
Bajada-Subida-Bajada/Subida: Se seleccionará el modo en que queremos realizar la
comunicación cliente-servidor. Si seleccionamos Bajada, sólo se recibirán datos del
servidor. Si seleccionamos Subida, sólo se enviarán datos al servidor. Si seleccionamos
Bajada/Subida se enviarán y se recibirán datos del servidor.
También aparece una barra de progreso que nos indicará en nivel de progreso de las
pruebas que se están realizando.
El número de pruebas que se realizarán desde esta zona viene dado por el tamaño
mínimo, el tamaño máximo y el incremento del dato.
Por último, y una vez configurados los parámetros deseados, se pulsará el botón
“Comenzar” para empezar las pruebas de rendimiento.
Desde esta zona podremos ver como afecta el incremento del tamaño del dato en el
retardo de las comunicaciones, tanto de forma aislada como de forma conjunta.
6.2.4.3.6. Gráficos estadísticos
Figura 82: Zona de gráficos estadísticos
En esta parte de la ventana principal se mostrarán los datos recogidos de los tiempos
empleados en las comunicaciones de forma gráfica. De esta manera será mucho más
fácil e intuitivo sacar conclusiones sobre el comportamiento de los protocolos en un
entorno dado.
139
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Figura 83: Ejemplo de gráficos estadísticos
6.2.4.3.7. Consola
Figura 84: Ejemplo de consola
140
Javier Viguera Muñoz
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
En la consola se muestran los resultados que se van obteniendo de las pruebas de
rendimiento que se realizan, así como las incidencias que pudieran ocurrir en la
comunicación.
6.2.4.3.8. Menu principal
Figura 85: Menú principal
El menú principal de la aplicación consta de dos menús, Configuración, Herramientas.
Vamos a ir describiendo cada uno de ellos con más detalle.
6.2.4.3.8.1. Configuración
Figura 86: Menú Configuración
El menú configuración consta de dos opciones: Configuración de parámetros y
Cambiar servidor.
La primera de ellas, Configuración de parámetros, da lugar a un formulario en el que se
fijarán los límites máximos y mínimos de los parámetros configurables de las pruebas
de rendimiento.
Figura 87: Configuración de parámetros
Los parámetros que se podrán configurar serán los siguientes:
141
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Tamaño máximo del dato: Será el tamaño máximo del dato que se podrá fijar en las
pruebas de rendimiento, ya sean bajo IIOP o bajo Servicio Web.
Tamaño mínimo del dato: Será el tamaño mínimo del dato que se podrá fijar en las
pruebas de rendimiento, ya sean bajo IIOP o bajo Servicio Web.
Máximo número de pruebas: Será el número máximo de pruebas que se podrán fijar en
las pruebas de rendimiento bajo IIOP y bajo Servicio Web. Para las pruebas conjuntas,
el número de pruebas vendrá dado por la configuración tamaño máximo, el tamaño
mínimo y el incremento del tamaño de los datos en dichas pruebas conjuntas.
Mínimo número de pruebas: Será el mínimo número de pruebas que se podrán fijar en
las pruebas de rendimiento bajo IIOP y bajo Servicio Web. Para las pruebas conjuntas,
el número de pruebas vendrá dado por la configuración tamaño máximo, el tamaño
mínimo y el incremento del tamaño de los datos en dichas pruebas conjuntas.
Incremento de las trackbars: Este parámetro hace referencia al incremento que sufrirán
las barras de tamaño de los datos cada vez que se pulse con el ratón en una de ellas. En
la siguiente figura se muestra una barra de tamaño o trackbar.
Figura 88: TrackBar
Puerto para IIOP: Este parámetro hace referencia al puerto del servidor de aplicaciones
por el que estará escuchando para atender a peticiones IIOP.
Puerto para WS: Este parámetro hace referencia al puerto del servidor de aplicaciones
por el que estará escuchando para atender a peticiones WS.
La segunda de las opciones del menú Configuración, Cambiar servidor, da lugar a un
formulario en el que se podrá cambiar el servidor al que nos conectamos.
Figura 89: Cambiar servidor
El uso de este formulario es idéntico al descrito en el apartado 6.2.4.3.1.
6.2.4.3.8.2. Herramientas
Figura 90: Menú Herramientas
El menú herramientas sólo tiene una opción, Limitador de ancho de banda. Esta opción
ejecuta
una
aplicación
de
terceros
(Bandwidth
Controller,
http://bandwidthcontroller.com/) que será usada para limitar el ancho de banda de la
conexión entre el cliente y el servidor de aplicaciones. Se podrá limitar tanto el ancho de
142
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
banda de subida como el de bajada, tanto para una conexión con cables como para una
sin cables. Vamos a describir más en detalle esta herramienta limitadora del ancho de
banda.
Al ejecutar esta opción aparecerá en la parte derecha de la barra de herramientas un
icono:
Figura 91: Icono del limitador de ancho de banda
Haciendo doble click sobre el icono o pulsando con el botón derecho del ratón el icono
y seleccionando la opción Bandwidth Controller Manager aparecerá la ventana
principal de la aplicación. La ventana principal tendrá el siguiente aspecto:
Figura 92: Bandwidth Controller
Habrá que crear filtros de tráfico para limitar el ancho de banda de la comunicación.
Veamos un ejemplo:
143
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Seleccionamos
la
opción
de
Javier Viguera Muñoz
menú
FileÆNew
Filter.
Figura 93: Bandwidth Controller: Menú de nuevo filtro
Esta opción dará lugar a una ventana de creación y configuración del nuevo filtro.
Figura 94: Bandwidth Controller: Configuración del filtro
Pasaremos a describir con mayor detalle cada uno de los campos de la ventana:
• Name: Nombre que tendrá el filtro.
• Network adapter: Será el adaptador de red que queramos limitar. Las opciones
serán:
144
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 95: Bandwidth Controller: Selección del adaptador de red
Seleccionaremos una u otra en función de si nuestra conexión es una red de área
local con cables o inalámbrica.
• Direction: Indica el flujo del tráfico que queremos filtrar. Las opciones
disponibles serán :
Figura 96: Bandwidth Controller: Dirección de filtrado
Usaremos Send cuando queremos limitar el flujo de subida y Receive cuando
queremos limitar el flujo de bajada.
• Maximun rate: Indica la tasa máxima, en bytes por segundo, que se permitirá.
Habrá una serie de valores por defecto a elegir pero también se permite la
inserción libre de un valor.
Figura 97: Bandwidth Controller: Tasa máxima de envío
•
Protocol: Es el protocolo al que queremos limitar el ancho de banda. El resto
de protocolos no se verán limitados. Las opciones serán las siguientes:
Figura 98: Bandwidth Controller: Protocolo limitado
Con la opción IP limitaremos tanto el protocolo UDP como TCP.
• Source address: Es la dirección de la que parte el flujo de datos al que
queremos limitar la capacidad. Las opciones serán:
Figura 99: Bandwidth Controller: Direcciones origen de datos que queremos limitar
Any: Limitará el flujo procedente de cualquier dirección
145
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Equal to: Aparecerá un nuevo campo en el que habrá que indicar la dirección IP
de la que procede el flujo que queremos limitar.
Between: Aparecerán dos campos en los que habrá que indicar dos direcciones IP
que serán los limites del rango de direcciones cuyo flujo queremos limitar.
MAC: Aparecerá un nuevo campo en el que habrá que indicar la dirección MAC
de la que procede el flujo que queremos limitar.
• Source port: Indica el puerto o el rango de puertos de los que procede el flujo
que queremos limitar.
Figura 100: Bandwidth Controller: Puerto origen a limitar
•
Destination address: Es la dirección a la que va dirigido el flujo de datos al
que queremos limitar la capacidad. Las opciones serán:
Figura 101: Bandwidth Controller: Direcciones origen de datos que queremos limitar
Any: Limitará el flujo destinado a cualquier dirección
Equal to: Aparecerá un nuevo campo en el que habrá que indicar la dirección IP a
la que va dirigido el flujo que queremos limitar.
Between: Aparecerán dos campos en los que habrá que indicar dos direcciones IP
que serán los limites del rango de direcciones destino del flujo que queremos
limitar.
MAC: Aparecerá un nuevo campo en el que habrá que indicar la dirección MAC a
la que va dirigido el flujo que queremos limitar.
• Destination port: Indica el puerto o el rango de puertos a los que va dirigido el
flujo que queremos limitar.
Figura 102: Bandwidth Controller: Puerto destino a limitar
6.3. Herramienta Java-.Net
6.3.1. Introducción
Para que clases o interfaces Java puedan ser usadas por un cliente .Net a través de IIOP
es necesario que el cliente .Net tenga una definición de dicha clase o interfaz. No hay
una equivalencia directa entre una clase Java y una clase .Net, ni siquiera en los tipos de
datos básicos. Debido a esto tiene que haber un punto en común que ambos entiendan y
a partir del cual se establezca una equivalencia entre ambos lenguajes. Ese punto en
común es el lenguaje IDL (Interface Definition Language). Como su propio nombre
indica es un lenguaje de definición de interfaces que se utiliza en computación
146
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
distribuida y ofrece la sintaxis necesaria para definir los procedimientos o métodos que
se quieren invocar de manera remota. Una vez que tengamos esa interfaz creada hay que
traducirla mediante un compilador de interfaces a tipos en los lenguajes deseados que
actuarán de Proxy o stub cliente y Proxy o skeleton del servidor.
En el caso que nos atañe partimos de unas interfaces en lenguaje Java que deberán ser
traducidas a lenguaje .Net (C# en este caso). Para que esto sea posible habrá que seguir
una serie de pasos:
1. Definición los interfaces o las clases Java que serán accedidas desde un cliente
.Net
2. Traducción de esas clases e interfaces a lenguaje IDL.
3. Traducción de esas clases e interfaces en lenguaje IDL a lenguaje .Net.
Esta aplicación proporcionará un interfaz gráfico intuitivo y fácil de usar que permitirá
realizar los pasos 2 y 3 automáticamente y generará una librería .Net con las clases e
interfaces correspondientes a las clases e interfaces Java deseadas. Estás clases serán
usadas por el cliente para poder invocar los servicios de la parte servidora.
6.3.2. Desarrollo
Para el desarrollo de esta aplicación se han seguido dos pasos consistentes en:
• Convertir las clases y los interfaces Java a IDL
• Convertir las clases IDL anteriores en clases e interfaces .Net
En la siguiente figura se muestran los pasos seguidos:
Figura 103: Herramienta Java-.Net: Pasos seguidos
6.3.2.1. Conversión Java-IDL
Para la conversión de Java a IDL se ha usado una herramienta proporcionada por la
máquina virtual de Java. Esta herramienta es “rmic”.
La herramienta “rmic” genera los stubs y los skeletons de los protocolos JRMP e IIOP
para objetos remotos. Estas clases se generan a partir de las clases Java compiladas que
147
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
contienen la implementación de los objetos remotos. Un objeto remoto es aquel que
implementa la interfaz java.rmi.remote. Las clases que se usen con la herramienta
“rmic” deben ser clases que se hayan compilado con éxito con el comando “javac”.
Para el caso que nos atañe usaremos la opción del comando “rmic” –idl.
Esta opción genera clases IDL para las clases especificadas y las clases referenciadas
por éstas. IDL proporciona una manera de especificar una API de objetos independiente
del lenguaje de programación y puramente declarativa, es decir, sin implementación.
IDL se usa como una especificación para métodos y datos que pueden ser escritos e
invocados desde cualquier otro lenguaje compatible con CORBA.
Utilizaremos “rmic -idl” para generar las clases IDL de las interfaces del EJB al que
accederemos desde el cliente, así como aquellas clases complejas que se utilicen en los
métodos de las interfaces. Esto generará además clases IDL para cada una de las clases
referenciadas en los interfaces del EJB, por ejemplo javax.ejb.EJBHome,
javax.ejb.EJBObject, etc. Estas a su vez hacen referencia a otras clases por lo que se
crearía todo un árbol de clases IDL.
Posteriormente habrá que generar clases e interfaces .Net para todas y cada una de las
clases IDL generadas.
Para realizar la conversión a IDL se ha creado un fichero .bat que será el encargado de
ejecutar la herramienta “rmic” así como crear las carpetas donde se almacenarán los
ficheros creados. Este fichero .bat será invocado una vez por cada clase o interfaz que
queramos convertir a IDL (la generación de los ficheros IDL, correspondientes a las
clases referenciadas por las clases e interfaces que queremos convertir a IDL, se hará de
forma automática y transparente por la herramienta “rmic”).
Las llamadas realizadas a esta herramienta “rmic” serán de la siguiente manera:
%JAVA_HOME%\bin\rmic
-idl
-classpath
.;%SERVICE_HOME%\lib\jbossj2ee.jar;%BUSINESS_CLASSPATH% -d %OUTPUT% %FILE%
%JAVA_HOME% es una variable de entorno apuntando donde esté instalada la
máquina virtual de Java.
%SERVICE_HOME% hace referencia al lugar donde tenemos instalada esta aplicación
que estamos describiendo.
%BUSINESS_CLASSPATH% es el conjunto de librerías utilizado por los métodos de
negocio del EJB. La librería con las clases típicas de los EJB ya está agregada al
classpath de la herramienta “rmic”.
% OUTPUT% es la carpeta donde creará los ficheros IDL generados.
%FILE% es la clase o la interfaz Java de la cual queremos generar su clase IDL.
Este proceso habrá que repetirlo una vez por cada clase que queramos convertir.
6.3.2.2. Herramienta IDLToCLSCompiler
IIOP.Net proporciona, entre otras, una herramienta que permite generar a partir de
definiciones de clases e interfaces IDL interfaces .Net y clases abstractas. El motivo por
el que genera clases abstractas es porque IDL es un lenguaje de definición de interfaces,
es decir, de clases y métodos pero no de implementación de dichos métodos. Por lo
tanto un cliente que quiera utilizar los métodos de dichas clases tendrá que realizar su
propia implementación. Este no será el caso si el interfaz corresponde a un objeto
remoto ya que una vez obtenida e instanciada la referencia remota podríamos invocar a
los métodos como si de métodos locales se tratara.
148
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Ya hemos descrito como la aplicación genera los ficheros IDL a partir de clases e
interfaces Java. Ahora a partir de esos ficheros IDL tenemos que generar las
correspondientes clases e interfaces .Net.
6.3.2.3. Creación de la librería CommonEJBClasses.dll
Imaginemos el caso en que tengamos varios EJB diferentes que van a ser invocados por
el cliente .Net y las librerías .Net necesarias se han creado por separado. Esto crearía un
conflicto en el cliente ya que las librerías contienen las clases propias de los EJBs y el
cliente no sabría cúal de ellas tendría que usar. Para evitar este problema habría dos
formas de actuar:
• Generar un única librería .Net con las clases propias de los EJB más los
interfaces del EJB y las clases de lógica de negocio de cada EJB
• Generar una librería .Net que contenga únicamente las clases propias de los
EJB y una librería por cada uno de los EJB que tengamos que contenga sólo
los interfaces del EJB y las clases de la lógica de negocio.
La primera opción puede plantear un problema ya que los EJB no han tenido porqué ser
creados al mismo tiempo o no tienen nada que ver unos EJB con otros por lo que tener
las interfaces de los EJB y las clases de lógica de negocio de todos los EJB juntas en
una misma librería no es aconsejable.
La segunda opción es más recomendable y es por la que se ha optado. Para este
proyecto se ha creado una librería .Net llamada CommonEJBClasses.dll que contiene
todas las clases propias de un EJB de sesión sin estado. Esta librería será usada por la
aplicación para convertir de Java a .Net y más en particular por la herramienta de
Iiop.Net IDLToCLSCompiler como base en la generación de las clases e interfaces .Net
de los EJB, de manera que en la librería resultante no incluya las clases propias de los
EJB.
De esta manera el cliente .Net tendrá que referenciar la librería con las clases comunes
del EJB CommonEJBClasses.dll y las librerías generadas mediante la aplicación para
cada uno de los EJB.
La siguiente figura muestra la alternativa elegida:
149
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 104: Herramienta Java-.Net: Creación de la librería CommonEJBClasses.dll
150
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6.3.2.4. Conversión de cadenas
Tanto las rutas de las clases e interfaces introducidas mediante el interfaz gráfico en la
herramienta como las rutas de compilación del EJB y de la librería final generada deben
ser tranformadas para adaptarlas al formato necesario usado en la generación de los
ficheros IDL y de las clases .Net.
Las cadenas se introducen con un formato tipo Windows, del estilo a
“D:\Proyecto_fin_de_Carrera\Proyecto\workspace\PruebasDeRendimiento\bin\es\vigue
ra\ejb\interfaces\BytesArray.class”.
Sin embargo el formato de las herramientas “rmic” e “IDLToCLSCompiler” son de la
siguiente manera:
“rmic –idl –classpath %CLASSPATH% -d %OUTFOLDER%
es.viguera.ejb.interfaces.BytesArray”
“IDLToCLSCompiler.exe -o %OUTFOLDER% PruebaDeRendimiento.dll
es\viguera\ejb\interfaces\BytesArray.idl es\viguera\ejb\interfaces\BytesArray.classidl”
6.3.3. Manual de usuario
6.3.3.1. Prerrequisitos
Para poder utilizar esta herramienta es necesario tener instalado en el sistema el
siguiente software:
• Una máquina virtual Java. Versión 1.5.x o superior.
También será necesario tener establecida una variable de entorno JAVA_HOME
apuntando al directorio de instalación de la máquina virtual de Java.
6.3.3.2. Guía de uso
La aplicación se podrá usar tanto desde un interfaz gráfico intuitivo y fácil de usar como
desde la línea de comandos. Queda a elección del usuario usar la aplicación de una
manera o de otra.
6.3.3.2.1. Interfaz gráfico
El interfaz hombre-máquina que proporciona la herramienta es el siguiente:
151
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 105: Herramienta Java-.Net: Componentes
Vamos a analizar parte por parte las secciones del interfaz gráfico.
Sección 1:
Figura 106: Herramienta Java-.Net: Carpeta de salida del EJB I
En esta sección se selecciona la carpeta que contiene las clases Java compiladas del EJB
con la estructura de paquetes incluida. Normalmente a esta carpeta se le suele llamar
“bin” o “clases”. Si, por ejemplo, las clases de un EJB están en la ruta de paquetes
“ejemplo.ejb” y la compilación de las clases de realiza en una carpeta llamada “bin”, la
estructura de carpetas generadas en la compilación sería de la siguiente manera:
Figura 107: Herramienta Java-.Net: Carpeta de salida del EJB II
La carpeta que habría que seleccionar en la sección 1 del interfaz gráfico sería la carpeta
“bin”.
Sección 2:
Figura 108: Herramienta Java-.Net: Librería resultante
152
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
En esta sección se selecciona el nombre de la librería .Net resultante de todo el proceso
de conversión y la ruta donde se generará. Por ejemplo, si ponemos “C:\ejemplo.dll”, la
librería .Net generada se llamará “ejemplo.dll” y se guardará en la carpeta raíz de la
unidad “C”.
Sección 3:
Figura 109: Herramienta Java-.Net: Ruta de las interfaces y las clases
En esta sección se seleccionan las clases Java y las interfaces que queremos convertir de
clases abstractas e interfaces .Net. Como en nuestro proyecto se trata de convertir el
Proxy de acceso al EJB, las clases que habría que seleccionar son los interfaces
compilados del EJB, es decir, los interfaces Home y Remote. Si además, en los métodos
de estos EJBs utilizamos además de tipos simples clases complejas, también habrá que
seleccionarlas ya que habrá que convertirla para que pueda ser usada por el cliente.
Sección 4:
Figura 110: Herramienta Java-.Net: Classpath necesario para la conversión
En esta sección se seleccionan las librerías Java de las que dependen las clases
seleccionadas en la sección 3. No es necesario seleccionar la librería Java que contiene
las clases de los EJB, como son EJBObject.class y otras clases propias de los EJB. Estas
clases ya son tenidas en cuenta por la aplicación. Sólo sería necesario en el caso de que
seleccionemos en la sección 3 alguna clase compleja que dependa de alguna librería
externa o que en los métodos de los interfaces se use algún tipo cuya definición esté en
alguna librería. En caso de que se seleccione alguna librería, sus clases también serían
transformadas a IDL y posteriormente se incluirían en la dll resultante.
Sección 5:
Figura 111: Herramienta Java-.Net: Borrado de los ficheros intermedios IDL
En esta sección lo único que hay que hacer es seleccionar si queremos que borre los
ficheros IDL intermedios que se generan en el proceso de la conversión de Java a .Net.
Esos ficheros serán usados de forma interna por la aplicación por lo que pueden ser
borrados posteriormente por el usuario una vez hecha la conversión.
Sección 6:
153
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 112: Herramienta Java-.Net: Consola de resultados
Esta sección es una consola de resultados. Se muestran las operaciones que se realizan,
los resultados de la conversión de los ficheros, los errores que se han producido, etc.
Un ejemplo de la generación de una librería .Net correspondiente a los interfaces de un
EJB sería de la siguiente manera:
Figura 113: Herramienta Java-.Net: Ejemplo de ejecución
6.3.3.2.2. Línea de comandos
La herramienta también deja la posibilidad de realizar la conversión desde la línea de
comandos.
La sintaxis para ejecutar la herramienta desde la línea de comandos es la siguiente:
launch.bat [[-classpath xxx] -binpath yyy -out zzz -interfaces aaa bbb]
Donde:
-classpath: classpath necesario para los interfaces. Ejemplo: "C:\lib\ejemplo.jar"
-binpath: Carpeta "bin" con los interfaces compilados. Ejemplo: "C:\misEJb\bin"
154
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
-out: Ruta y nombre de la dll que se va a generar. Ejemplo: "C:\misDLL\ejemplo1.dll"
-interfaces: Interfaces a partir de las cuales generar
"pack1.pack2.interfaz1.class pack1.pack2.interfaz2.class"
la
DDL.
Ejemplo:
El ejemplo equivalente al mostrado en el apartado anterior mediante interfaz gráfico
sería:
launch.bat
-binpath D:\Proyecto_fin_de_Carrera\Proyecto\workspace\PruebasDeRendimiento\bin
-out
D:\Proyecto_fin_de_Carrera\Proyecto\workspace\PruebasDeRendimiento\PruebasDeRe
ndimientoServer.dll
-interfaces es.viguera.ejb.interfaces.BytesArray.class
es.viguera.ejb.interfaces.BytesArrayHome.class
Una vez ejecutado esto desde la línea de comandos aparecerán los mismos resultados
que se mostrarán en la consola del interfaz gráfico.
155
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 114: Herramienta Java-.Net: Ejecución desde línea de comandos
156
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
6.4. Pruebas de rendimiento
Vamos a realizar baterías de pruebas variando el tamaño del dato y el ancho de banda de
la conexión para ver el comportamiento de ambas tecnologías. La comunicación será de
subida y bajada.
Estas pruebas se realizarán en una red de área local de 100 Mbps y se realizarán 100 test
para cada una de las pruebas:
6.4.1. Capacidad de conexión: No limitada
6.4.1.1. Subida/Bajada
6.4.1.1.1. Tamaño del dato intercambiado: no se intercambia dato
Tiempo medio empleado en cada prueba:
IIOP: 3,796408 mseg
WS: 7,340957 mseg
Con este tamaño de dato IIOP es 1,93 veces más rápido.
Figura 115: Pruebas de rendimiento. Capac: No limit. Tam dato: 0Bytes
6.4.1.1.2. Tamaño del dato intercambiado: 10Bytes
Tiempo medio empleado en cada prueba:
IIOP: 4,020072 mseg
WS: 7,676757 mseg
Con este tamaño de dato IIOP es 1,91 veces más rápido.
157
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 116: Pruebas de rendimiento. Capac: No limit. Tam dato: 10Bytes
6.4.1.1.3. Tamaño del dato intercambiado: 100Bytes
Tiempo medio empleado en cada prueba:
IIOP: 4,055271 mseg
WS: 10,047131 mseg
Con este tamaño de dato IIOP es 2,48 veces más rápido.
158
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 117: Pruebas de rendimiento. Capac: No limit. Tam dato: 100Bytes
6.4.1.1.4. Tamaño del dato intercambiado: 1KBytes
Tiempo medio empleado en cada prueba:
IIOP: 5,520691 mseg
WS: 35,800773 mseg
Con este tamaño de dato IIOP es 6,48 veces más rápido.
159
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 118: Pruebas de rendimiento. Capac: No limit. Tam dato: 1KBytes
6.4.1.1.5. Tamaño del dato intercambiado: 10KBytes
Tiempo medio empleado en cada prueba:
IIOP: 18,128514 mseg
WS: 286,204648 mseg
Con este tamaño de dato IIOP es 15,79 veces más rápido.
160
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 119: Pruebas de rendimiento. Capac: No limit. Tam dato: 10KBytes
6.4.1.1.6. Tamaño del dato intercambiado: 100KBytes
Tiempo medio empleado en cada prueba:
IIOP: 131,750068 mseg
WS: 2810,896006 mseg
Con este tamaño de dato IIOP es 21,33 veces más rápido.
161
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 120: Pruebas de rendimiento. Capac: No limit. Tam dato: 100KBytes
6.4.2. Capacidad de conexión: 256Kbps
6.4.2.1. Subida/Bajada
6.4.2.1.1. Tamaño del dato intercambiado: no se intercambia dato
Tiempo medio empleado en cada prueba:
IIOP: 4,635727 mseg
WS: 11,487805 mseg
Con este tamaño de dato IIOP es 2,48 veces más rápido.
162
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 121: Pruebas de rendimiento. Capac: 256Kbps. Tam dato: 0Bytes
6.4.2.1.2. Tamaño del dato intercambiado: 10Bytes
Tiempo medio empleado en cada prueba:
IIOP: 4,331575 mseg
WS: 12,582551 mseg
Con este tamaño de dato IIOP es 2,91 veces más rápido.
163
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 122: Pruebas de rendimiento. Capac: 256Kbps. Tam dato: 10Bytes
6.4.2.1.3. Tamaño del dato intercambiado: 100Bytes
Tiempo medio empleado en cada prueba:
IIOP: 4,947452 mseg
WS: 10, 14,72161 mseg
Con este tamaño de dato IIOP es 2,97 veces más rápido.
164
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 123: Pruebas de rendimiento. Capac: 256Kbps. Tam dato: 100Bytes
6.4.2.1.4. Tamaño del dato intercambiado: 1KBytes
Tiempo medio empleado en cada prueba:
IIOP: 6,964883 mseg
WS: 41,736982mseg
Con este tamaño de dato IIOP es 6 veces más rápido.
165
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 124: Pruebas de rendimiento. Capac: 256Kbps. Tam dato: 1KBytes
6.4.2.1.5. Tamaño del dato intercambiado: 10KBytes
Tiempo medio empleado en cada prueba:
IIOP: 23,839965 mseg
WS: 354,319695 mseg
Con este tamaño de dato IIOP es 14,86 veces más rápido.
166
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 125: Pruebas de rendimiento. Capac: 256Kbps. Tam dato:10KBytes
6.4.2.1.6. Tamaño del dato intercambiado: 100KBytes
Tiempo medio empleado en cada prueba:
IIOP: 6198,20804 mseg
WS: 9791,24477 mseg
Con este tamaño de dato IIOP es 1,57 veces más rápido.
167
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 126: Pruebas de rendimiento. Capac: 256Kbps. Tam dato: 100KBytes
6.4.3. Capacidad de conexión: 1Mbps
6.4.3.1. Subida/Bajada
6.4.3.1.1. Tamaño del dato intercambiado: no se intercambia dato
Tiempo medio empleado en cada prueba:
IIOP: 4,416388 mseg
WS: 11,053581 mseg
Con este tamaño de dato IIOP es 2,50 veces más rápido.
168
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 127: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 0Bytes
6.4.3.1.2. Tamaño del dato intercambiado: 10Bytes
Tiempo medio empleado en cada prueba:
IIOP: 4,431542 mseg
WS: 11,796131 mseg
Con este tamaño de dato IIOP es 2,66 veces más rápido.
169
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 128: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 10Bytes
6.4.3.1.3. Tamaño del dato intercambiado: 100Bytes
Tiempo medio empleado en cada prueba:
IIOP: 4,465971 mseg
WS: 14,643667 mseg
Con este tamaño de dato IIOP es 3,28 veces más rápido.
170
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 129: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 100Bytes
6.4.3.1.4. Tamaño del dato intercambiado: 1KBytes
Tiempo medio empleado en cada prueba:
IIOP: 5,972108 mseg
WS: 40,319377 mseg
Con este tamaño de dato IIOP es 6,75 veces más rápido.
171
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 130: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 1KBytes
6.4.3.1.5. Tamaño del dato intercambiado: 10KBytes
Tiempo medio empleado en cada prueba:
IIOP: 24,514942 mseg
WS: 353,40076 mseg
Con este tamaño de dato IIOP es 14,4 veces más rápido.
172
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 131: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 10KBytes
6.4.3.1.6. Tamaño del dato intercambiado: 100KBytes
Tiempo medio empleado en cada prueba:
IIOP: 1937,990429 mseg
WS: 5330,266244 mseg
Con este tamaño de dato IIOP es 2,75 veces más rápido.
173
Interoperatividad .Net-J2EE mediante WS e IIOP.
Entorno de pruebas de rendimiento
Javier Viguera Muñoz
Figura 132: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 100KBytes
174