6. trabajo desarrollado 6.1. j2ee...

Interoperatividad .Net-J2EE mediante WS e IIOP. Javier Viguera Muñoz Entorno de pruebas de rendimiento

104

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.


105

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.


106

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


107

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


108

• 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


109

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:


110

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.


111

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”.


112

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”.


113

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”.


114

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


115

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.


116

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.


117

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)


118

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


119

• 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.


120

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


121

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.


122

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


123

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:


124

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


125

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:


126

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:


127

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.


128

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”.


129

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.


130

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.


131

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


132

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.


133

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.


134

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.


135

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:


136

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


137

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


138

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:


139

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.


140

Figura 83: Ejemplo de gráficos estadísticos

6.2.4.3.7. Consola

Figura 84: Ejemplo de consola


141

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:


142

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


143

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:


144

Seleccionamos la opción de 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:


145

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


146

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


147

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


148

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\jboss-j2ee.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.


149

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:


150

Figura 104: Herramienta Java-.Net: Creación de la librería CommonEJBClasses.dll


151

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\viguera\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:


152

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


153

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:


154

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"


155

-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 la DDL. Ejemplo: "pack1.pack2.interfaz1.class pack1.pack2.interfaz2.class" 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\PruebasDeRendimientoServer.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.


156

Figura 114: Herramienta Java-.Net: Ejecución desde línea de comandos


157

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.


158




159


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.


160

Figura 118: Pruebas de rendimiento. Capac: No limit. Tam dato: 1KBytes



161




162


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.


163

Figura 121: Pruebas de rendimiento. Capac: 256Kbps. Tam dato: 0Bytes



164


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.


165


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.


166

Figura 124: Pruebas de rendimiento. Capac: 256Kbps. Tam dato: 1KBytes



167

Figura 125: Pruebas de rendimiento. Capac: 256Kbps. Tam dato:10KBytes



168

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.


169

Figura 127: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 0Bytes



170




171




172

Figura 130: Pruebas de rendimiento. Capac: 1Mbps. Tam dato: 1KBytes



173




174


6. trabajo desarrollado 6.1. j2ee...

Documents