ANALISIS COMPARATIVO DE LAS PLATAFORMAS J2EE Y .NET APLICADO AL DESARROLLO DE WEB SERVICES

UNIVERSIDAD DE PAMPLONAFACULTAD DE INGENIERIAS Y ARQUITECTURA

DEPARTAMENTO DE INGENIERIAS ELÉCTRICA ELECTRÓNICA SISTEMAS YTELECOMUNICACIONES

PROGRAMA DE INGENIERIA DE SISTEMAS

TITULOANALISIS COMPARATIVO DE LAS PLATAFORMAS J2EE Y .NET APLICADO

AL DESARROLLO DE SERVICIOS WEB

AUTOR: JOHN JAIRO MENDEZ ROMERO

PAMPLONA COLOMBIA

NOVIEMBRE DE 2008




PROYECTO DE TRABAJO DE GRADO PARA OPTAR POR EL TITULO DEINGENIERO DE SISTEMAS

TITULOANALISIS COMPARATIVO DE LAS PLATAFORMAS J2EE Y .NET APLICADO

AL DESARROLLO DE SERVICIOS WEB

AUTORJOHN JAIRO MEDEZ ROMERO

DIRECTORMSC. (C). JORGE OMAR PORTILLA JAIMES.

PAMPLONA – COLOMBIANOVIEMBRE DE 2008




TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DEINGENIERO DE SISTEMAS

TITULO

ANALISIS COMPARATIVO DE LAS PLATAFORMAS J2EE Y .NET APLICADOAL DESARROLLO DE SERVICIOS WEB

FECHA DE INICIO DEL TRABAJO: Mayo de 2008FECHA DE TERMINACIÓN DEL TRABAJO: Noviembre de 2008

NOMBRES Y FIRMAS DE AUTORIZACIÓN PARA SUSTENTAR:

AUTOR: JOHN JAIRO MENDEZ ROMERO (Firma)

DIRECTOR: Ing. MsC.(C). JORGE OMAR PORTILLA (Firma)

DIR. DEL PROGRAMA: Ing. Ph.D. CARLOS PARRA (Firma)

JURADO CALIFICADOR:

PRESIDENTE: Ing. MsC. LUZ MARINA SANTOS J. (Firma)

OPONENTE: Ing. MsC. LUIS ALBERTO ESTEBAN. V. (Firma)

SECRETARIO: Ing. ALEXIS OLVANY TORRES C. (Firma)

PAMPLONA COLOMBIA

NOVIEMBRE DE 2008

DEDICATORIA

A Dios, el cual siempre me ha acompañado aun en los momento más

difícil de mi vida, porque siempre lo siento a mi lado, su amor, su

perdón y misericordia han estado presentes en mi cada día, como el aire

que me rodea.

Mi esposa y mis hijos que han sido una nueva bendición de Dios;

donde su apoyo de una forma u otra jamás se ha apartado de mí.

A Mis padres que siempre han sido un gran ejemplo a seguir, por lo

que siempre me he sentido orgullosos de ellos en todo momento y

circunstancia.

Mis hermanos y familiares que siempre estuvieron pendientes de mí

para colaborarme con sus consejos.

Amigos, compañeros, colegas profesores que compartieron sus

conocimientos y experiencias con migo.

PENSAMIENTO

No hay que confundir nunca el conocimiento con la sabiduría.

El primero nos sirve para ganarnos la vida;

La sabiduría nos ayuda a vivir.

Sorcha Carey

Un hombre con una idea nueva es un loco hasta que la idea triunfa.

Marc Twain

La fe es el fin de nuestros recursos

Y el principio de los recursos de Dios.

Flora Larsson

AGRADECIMIENTOS

Principalmente agradezco a Dios por las bendiciones que me

permite experimentar. A mi Esposa Blanca y a mis hijos; Adriel,

Darly y Karol por su amor y comprensión. A mis padres Manuel

y Nancy, por creer en mí y por el respaldo que siempre recibí de

ellos. Al profesor Omar Portilla por su asesoría y

recomendaciones respecto a esta investigación.

TABLA DE CONTENIDO

CAPITULO I_________________________________________________________________________30

INTRODUCCIÓN_____________________________________________________________________30

1.1 DESCRIPCIÓN DEL PROBLEMA ___________________________________________________ 31

1.2 JUSTIFICACIÓN__________________________________________________________________ 32

1.3 OBJETIVOS DEL PROYECTO____________________________________________________ 331.3.1 Objetivo General __________________________________________________________________________ 331.3.2 Objetivos Específicos _______________________________________________________________________ 33

CAPITULO 2 ______________________________________________________________________34

MARCO HISTORICO Y CONCEPTUAL ______________________________________________34

2.1 Estado del arte a nivel mundial ____________________________________________________ 34

2.2 Estado del arte a nivel nacional y local_____________________________________________ 352.2.1 Nacional _________________________________________________________________________________ 352.2.2 Local ____________________________________________________________________________________ 35

2.3 Historia de los Servicios Web _____________________________________________________ 362.3.1 La era de las redes locales. __________________________________________________________________ 362.3.2 La era de Internet y la Web. _________________________________________________________________ 372.3.3 Evolución histórica de la Web. _______________________________________________________________ 38

2.4 Definiciones de Los Servicios Web ________________________________________________ 39

2.5 Requisitos de un Web Service_____________________________________________________ 40

2.6 Web Services Protocol Stack______________________________________________________ 402.6.1 XML_____________________________________________________________________________________ 412.6.2 Protocolo de acceso de objeto Simple (SOAP)____________________________________________________ 42

2.6.2.1 Estructura de un mensaje Soap________________________________________________________ 432.6.2.2 Ventajas de utilizar Soap _____________________________________________________________ 43

2.6.3 WSDL ___________________________________________________________________________________ 442.6.3.1 Descripción del Wsdl ______________________________________________________________________ 452.6.4 UDDI ____________________________________________________________________________________ 46

2.6.4.1 Los datos manejados por UDDI se dividen en tres categorías_____________________________ 46

2.7 Dinámica de los Servicios Web____________________________________________________ 472.8.1 Que es .NET? ______________________________________________________________________________ 482.8.2 Principales objetivos de la plataforma .NET _____________________________________________________ 482.8.6 Principales lenguajes soportados por .NET. _____________________________________________________ 492.8.4 Arquitectura .NET __________________________________________________________________________ 502.8.3 ¿Qué es .NET Framework?___________________________________________________________________ 512.8.5 Framework 3.0 Y 3.5 ________________________________________________________________________ 52

2.9 Plataforma J2EE _________________________________________________________________ 532.9.1 Definición de J2EE __________________________________________________________________________ 532.9.2 Arquitectura J2EE.__________________________________________________________________________ 53

2.9.3 Características de J2EE.______________________________________________________________________ 542.9.3.1 Paquetes de aplicaciones _____________________________________________________________ 552.9.3.2 Lenguajes soportado por J2EE________________________________________________________ 572.9.3.2.1 Java ______________________________________________________________________________ 57

CAPITULO III _______________________________________________________________________58

SELECCION DE LOS CRITERIOS Y HERRAMIENTAS PARA REALIZAR LA COMPARACION____________58

3.1 Aspectos relacionados entre J2EE y .NET__________________________________________ 58

3.2 Criterios seleccionados para realizar la comparación _______________________________ 59

3.3 Justificación de los criterios seleccionados. _______________________________________ 593.3.1 Seguridad a nivel de mensaje. _______________________________________________________________ 593.3.2 Portabilidad _____________________________________________________________________________ 593.3.3 IDE de J2EE frente al IDE de .NET ____________________________________________________________ 603.3.4 Interoperabilidad _________________________________________________________________________ 603.3.5 Desempeño _____________________________________________________________________________ 60

3.4 Herramientas seleccionadas para realizar la comparación y el prototipo ____________ 61

3.5 Justificación de las herramientas seleccionadas__________________________________ 623.5.1 IDE_____________________________________________________________________________________ 62

3.5.1.1 NetBeans __________________________________________________________________________ 623.5.1.2 Visual Studio ________________________________________________________________________ 63

3.5.2 Servidores de aplicación ___________________________________________________________________ 643.5.2.1 Sun Application Server (GlassFish) ___________________________________________________ 653.5.2. IIS (Internet Information Services) _______________________________________________________ 65

3.5.3 Especificaciones y estándares ______________________________________________________________ 663.5.3.1 JEE5 y Framework 3.5 ______________________________________________________________ 66

3.5.4 Lenguajes de programación________________________________________________________________ 673.5.4.1 Java_______________________________________________________________________________ 673.5.4.2 Visual Basic .Net ___________________________________________________________________ 67

3.5.5 Servidores y manejadores de datos ____________________________________________________________ 673.5.5.1 Java DB ____________________________________________________________________________ 673.5.5.2 Microsoft Access_____________________________________________________________________ 67

3.5.5 AdventNet QEngine ________________________________________________________________________ 68

CAPITULO IV _______________________________________________________________________70

ANÁLISIS COMPARATIVO ENTRE J2EE Y .NET _____________________________________________70

4.1 Seguridad a nivel de mensajes ____________________________________________________ 704.1.1 Algunas especificaciones soportada por J2EE____________________________________________________ 70

4.1.1.1 La plataforma J2EE (JEE 5) de Sun Microsystems ______________________________________ 704.1.1.2 GlassFish___________________________________________________________________________ 704.1.1.3 NetBeans___________________________________________________________________________ 704.1.1.4 WSIT ______________________________________________________________________________ 70

4.1.2 Algunas especificaciones soportadas por .NET ___________________________________________________ 714.1.2.1 Visual Studio .NET __________________________________________________________________ 71

4.1.2.1.1 Web Services Enhancements _____________________________________________________ 724.1.2.1.2 Windows Communication Foundation (WCF) _______________________________________ 72

4.1.3 Autentificación de usuarios usando UserNameTokens en J2EE y .NET de acuerdo a laespecificación de WS-Security _____________________________________________________________________ 73

4.1.3.1 Aplicación UserName Tokens en .NET utilizando WSE __________________________________ 734.1.3.1.1 Servicio Web ____________________________________________________________________ 734.1.3.1.2 Cliente consumiendo un WS con seguridad a nivel de mensaje _______________________ 76

4.1.3.2 Aplicación UserName Tokens en J2EE con NetBeans ___________________________________ 774.1.4 Análisis de seguridad a nivel de mensaje _______________________________________________________ 80

4.2 Portabilidad. _____________________________________________________________________ 824.2.1 Análisis de la Portabilidad en J2EE ____________________________________________________________ 824.2.2 Análisis de la Portabilidad en .NET _____________________________________________________________ 82

4.3 NetBeans 6.5 frente Visual Studio .NET 2008_______________________________________ 834.3.1 Especificaciones ___________________________________________________________________________ 834.3.2 Prueba 1 _________________________________________________________________________________ 844.3.2 Prueba 2 _________________________________________________________________________________ 844.3.3 Prueba 3 _________________________________________________________________________________ 854.3.4 Prueba 4 _________________________________________________________________________________ 854.3.5 Realizando un Servicio Web _________________________________________________________________ 86

4.3.5.1 NetBeans 6.5 _______________________________________________________________________ 864.3.5.2 Visual Studio .NET 2008 _____________________________________________________________ 864.3.5.3 Prueba 5 ___________________________________________________________________________ 874.3.5.4 Método del Servicio Web en VS .NET. _________________________________________________ 884.3.5.5 Método del Servicio Web en NetBeans_________________________________________________ 884.3.5.6 Prueba 6 ___________________________________________________________________________ 914.3.5.7 Testear el Servicio Web y ver el Wsdl desde VS ________________________________________ 914.3.5.8 Testear el Servicio Web y ver el Wsdl desde NetBeans__________________________________ 924.3.5.9 Realizando cambios en el método del WS en VS _______________________________________ 934.3.5.10 Realizando cambios en el método del WS en NetBeans ________________________________ 93

4.3.6 Conexión a Bases de datos. __________________________________________________________________ 944.3.6.1 Conexión en NetBeans_______________________________________________________________ 944.3.6.2 Conexión en VS _____________________________________________________________________ 95

4.3.7 Consumiendo un servicio Web en J2EE utilizando NetBeans _______________________________________ 964.3.7.1 Copiando la URL del Servicio ________________________________________________________ 964.3.7.2 Generando una Clase _______________________________________________________________ 974.3.7.3 Agregando Métodos a La Clase ______________________________________________________ 994.3.7.4 Llamando una operación del Servicio Web _____________________________________________ 99

4.3.8 Consumiendo un servicio Web en .NET utilizando Visual Studio ___________________________________ 1004.3.8.1 Dimensionado una variable tipo Servicio Web en VS ___________________________________ 101

4.3.9 Análisis de NetBeans Frente Visual Studio _____________________________________________________ 102

4.4 Interoperabilidad_______________________________________________________________ 1044.4.1 WS – I___________________________________________________________________________________ 1044.4.2 Interoperabilidad con METRO y WCF _________________________________________________________ 1064.4.3 Análisis de la Interoperabilidad ______________________________________________________________ 108

4.4.3.1 Posibles problemas al utilizar WS de diferentes plataformas (J2EE, .NET) ________________ 1094.4.3.2 El DataSet como un tipo de dato especifico de .NET ____________________________________ 1094.4.3.3 El código de un WS que devuelve un DataSet _________________________________________ 1104.4.3.4 Analizando el WSDL generado por el WS .NET que devuelve un DataSet_________________ 1114.4.3.5 Analizando el mensaje Soap generado por un WS utilizando DataSet ____________________ 111

4.5 Desempeño____________________________________________________________________ 114

4.5.1 Reporte de la configuración del Test__________________________________________________________ 1144.5.1.1 J2EE______________________________________________________________________________ 1144.5.1.2 NET ______________________________________________________________________________ 115

4.5.2 Resumen del estado de las transacciones _____________________________________________________ 1164.5.2.1 J2EE______________________________________________________________________________ 1164.5.2.2 .NET ______________________________________________________________________________ 1164.5.2.3 Análisis 1 __________________________________________________________________________ 117

4.5.3 Tiempo contra la cuenta de usuarios activos___________________________________________________ 1174.5.3.1 J2EE______________________________________________________________________________ 1174.5.3.2 .NET ______________________________________________________________________________ 1174.5.3.3 Análisis 2 __________________________________________________________________________ 118

4.5.4 Hits por segundos ________________________________________________________________________ 1184.5.4.1 J2EE______________________________________________________________________________ 1184.5.4.2 .NET ______________________________________________________________________________ 1194.5.4.3 Análisis 3 __________________________________________________________________________ 119

4.5.5 Tiempo contra el rendimiento ______________________________________________________________ 1194.5.5.1 J2EE______________________________________________________________________________ 1204.5.5.2 .NET ______________________________________________________________________________ 1204.5.5.3 Análisis 4 __________________________________________________________________________ 121

4.5.6 Distribución de los errores para todas las transacciones _________________________________________ 1214.5.6.1 J2EE______________________________________________________________________________ 1214.5.6.2 .NET ______________________________________________________________________________ 1214.5.6.3 Análisis 5 __________________________________________________________________________ 122

4.5.7 El tiempo contra el porcentaje de error_______________________________________________________ 1224.5.7.1 .NET ______________________________________________________________________________ 122

4.5.8 Reporte del tiempo De respuesta ___________________________________________________________ 1234.5.8.1 J2EE______________________________________________________________________________ 1234.5.8.2 .NET ______________________________________________________________________________ 1234.5.8.3 Análisis 6 __________________________________________________________________________ 124

4.5.9 El tiempo contra el tiempo de respuesta (Detallado)____________________________________________ 1244.5.9.1 J2EE______________________________________________________________________________ 1244.5.9.2 .NET ______________________________________________________________________________ 1254.5.9.3 Análisis 7 __________________________________________________________________________ 125

4.5.10 Usuarios contra el tiempo de respuesta _____________________________________________________ 1254.5.10.1 J2EE_____________________________________________________________________________ 1264.5.10.2 .NET _____________________________________________________________________________ 1264.5.10.3 Análisis 8 _________________________________________________________________________ 126

4.5.11 Usuarios contra el rendimiento ____________________________________________________________ 1274.5.11.1 J2EE_____________________________________________________________________________ 1274.5.11.2 .NET _____________________________________________________________________________ 1274.5.11.3 Análisis 9 _________________________________________________________________________ 127

4.5.12 Cuellos de botellas - Reporte de análisis _____________________________________________________ 1284.5.12.1 J2EE_____________________________________________________________________________ 1284.5.12.2 .NET _____________________________________________________________________________ 1294.5.12.3 Análisis 10 ________________________________________________________________________ 129

4.5.13 El tiempo contra el tiempo de las páginas descargadas _________________________________________ 1294.5.13.1 J2EE_____________________________________________________________________________ 130

4.5.13.2 .NET _________________________________________________________________________________ 1304.5.13.3 Análisis 11 ________________________________________________________________________ 130

4.5.14 Reporte del tamaño de páginas ____________________________________________________________ 130

4.5.14.1 J2EE_____________________________________________________________________________ 1314.5.14.2 .NET _____________________________________________________________________________ 1314.5.14.3 Análisis 12 ________________________________________________________________________ 131

4.5.15 Reporte de las páginas descargada _________________________________________________________ 1324.5.15.1 J2EE_____________________________________________________________________________ 1324.5.15.2 .NET _____________________________________________________________________________ 1324.5.15.3 Análisis 13 ________________________________________________________________________ 133

4.5.16 Resumen de los reportes _________________________________________________________________ 1334.5.16.1 J2EE_____________________________________________________________________________ 1334.5.16.2 .NET _____________________________________________________________________________ 1344.5.16.3 Análisis 14 ________________________________________________________________________ 134

4.5.17 Analizando el desempeño entre J2EE y .NET utilizando otras Investigaciones ________________________ 1354.5.17.1 Test realizado _____________________________________________________________________ 1354.5.17.2 Resultado del Test _________________________________________________________________ 1354.5.17.3 Análisis de Maneesh _______________________________________________________________ 136

4.5.18 Análisis Final____________________________________________________________________________ 137

PRESUPUESTO ECONÓMICO _________________________________________________________139

FUENTES DE FINANCIACIÓN __________________________________________________________140

MARCO LEGAL _____________________________________________________________________141

INFLUENCIA AMBIENTAL ____________________________________________________________143

CONCLUSIONES ____________________________________________________________________144

RECOMENDACIONES________________________________________________________________147

GLOSARIO DE TÉRMINOS Y SÍMBOLOS _________________________________________________148

BIBLIOGRAFÍA Y REFERENCIAS WEB ___________________________________________________150

ANEXO I __________________________________________________________________________155

SEGURIDAD A NIVEL DE MENSAJE EN LOS SERVICIOS WEB _________________________ 155

ANEXO II _________________________________________________________________________166

PORTABILIDAD EN J2EE Y .NET _____________________________________________________ 166

ANEXO III _________________________________________________________________________186

DESARROLLO DEL PROTOTIPO DE SERVICIO WEB EN AMBAS PLATAFORMAS________ 186

ANEXO IV _________________________________________________________________________203

DESARROLLO DEL CLIENTE EN AMBAS PLATAFORMAS _____________________________ 203

ÍNDICE DE FIGURAS

Figura 1 Representación de Datos XML y HTML ..................................................................................... 42Figura 2. XML como Tecnología e Innovación.......................................................................................... 42Figura 3. Composición de un mensaje SOAP ........................................................................................... 43Figura 4. Solicitud Utilizando Soap ............................................................................................................. 43Figura 5. Respuesta Utilizando Soap ......................................................................................................... 43Figura 6. Ejemplo de un documento Wsdl ................................................................................................. 45Figura 7. Dinámica de un Servicio .............................................................................................................. 47Figura 8. Arquitectura de .NET .................................................................................................................... 50Figura 9. FrameWork se desarrollan todas las aplicaciones .................................................................. 52Figura 10. Características de .NET FrameWork 3.5 ........................................................................... 52Figura 11 Arquitectura J2EE (modelo de ejecución en capas)............................................................... 53Figura 12 Estructura archivo JAR. .............................................................................................................. 55Figura 13. Estructura archivo WAR. ........................................................................................................... 56Figura 14. Estructura archivo EAR.............................................................................................................. 56Figura 15. Estructura archivo RAR ............................................................................................................. 57Figura 17. NetBeans IDE 6.5 ....................................................................................................................... 63Figura 18. Visual Studio .NET 2008 Preview ............................................................................................ 64Figura 19. Conjunto de estándares de WSIT ............................................................................................ 71Figura 20. Pestañas de ventanas en NetBeans ....................................................................................... 77Figura 21. UserNameToken......................................................................................................................... 78Figura 22. Ventana de Editor UserNameToken ........................................................................................ 78Figura 23. Agregando Tokens en NetBeans ............................................................................................. 79Figura 24. Atributos de un WS..................................................................................................................... 79Figura 25. Editor de Atributos ...................................................................................................................... 79Figura 26. Atributos a una Referencia WS ................................................................................................ 80Figura 27. Editor de Atributos Cliente......................................................................................................... 80Figura 28. Nuevo Proyecto en NetBeans................................................................................................... 86Figura 29. Escogiendo categorías de proyectos en NetBeans. ............................................................. 86Figura 30. Agregando nuevo WS a una Aplicación Web ........................................................................ 86Figura 31. Nuevo sitio Web en VS 2008 .................................................................................................... 87Figura 32. Nuevo WS en VS 2008 .............................................................................................................. 87Figura 33. Metodo por defecto un WS en Visual Studio.......................................................................... 88Figura 34. Código por defecto de un WS en NetBeans........................................................................... 89Figura 35. Adicionar un nuevo método en NetBeans. ............................................................................. 89Figura 36. Editor de métodos. ..................................................................................................................... 90Figura 37. Método de un WS en NetBeans. .............................................................................................. 90Figura 38. WSDL y Testeo de un WS en Visual Studio........................................................................... 91Figura 39. Test Web Service ....................................................................................................................... 92Figura 40. WSDL y Testeo de un WS en NetBeans ................................................................................ 92Figura 41. Herramienta para renombrar WS en NetBeans ..................................................................... 93Figura 42. Herramienta para cambiar métodos del parámetro............................................................... 93Figura 43. Asistente para agregar una nueva conexión en NetBeans .................................................. 94Figura 44. Asistente para Buscar Driver en NetBeans ............................................................................ 95Figura 45. Asistente para agregar una nueva conexión en visual Studio ............................................. 95Figura 46. Agregando una referencia Web en un cliente ........................................................................ 96Figura 47. Asistente de Adición de Referencia Web................................................................................ 97Figura 48. Referencia Web Agregada ........................................................................................................ 97

Figura 49. Crear Una Nueva Clase............................................................................................................. 98Figura 50. Asistente para nueva clase ....................................................................................................... 98Figura 51. Clase generada........................................................................................................................... 98Figura 52. Creando un Método a la Clase ................................................................................................. 99Figura 53. Llamando un método de un WS ............................................................................................... 99Figura 54. Selección de la operación ......................................................................................................... 99Figura 55. Código generado ...................................................................................................................... 100Figura 56. Nueva referencia Web en Visual Studio................................................................................ 100Figura 57. Asistente de Referencia Web ................................................................................................. 101Figura 58. Referencia Web Agregada ...................................................................................................... 101Figura 59. Método Page_Load .................................................................................................................. 102Figura 60. Variable Tipo Referencia Web ................................................................................................ 102Figura 61. WSDL del DataSet ................................................................................................................... 111Figura 62. Mensaje Soap Del DataSet Parte1 ....................................................................................... 112Figura 63. Mensaje Soap Del DataSet Parte 2 ...................................................................................... 112Figura 64. Error Generado en El Cliente con NetBeans ...................................................................... 113Figura 65. Especificaciones de Seguridad. ............................................................................................. 158Figura 66. Dialogo de Seguridad sin validación...................................................................................... 162Figura 67. Dialogo de Seguridad con auto validación. .......................................................................... 163Figura 68. Mensaje Soap con WS-Security............................................................................................. 164Figura 69. Mensaje Soap Utilizando Certificados X509. ....................................................................... 164Figura 70. Ejemplo del Lenguaje MSIL. ................................................................................................... 169Figura 71. LP Sin Maquina Virtual. ........................................................................................................... 175Figura 72. LP Con Maquina Virtual........................................................................................................... 175Figura 73. Ejemplo de bytecode................................................................................................................ 176Figura 74. Compilador Tradicional. ........................................................................................................... 181Figura 75. Actuación de un Intérprete. ..................................................................................................... 182Figura 76. Interprete de Bytecodes........................................................................................................... 182Figura 77. Just-In-Time............................................................................................................................... 183Figura 78. HotSpot. ..................................................................................................................................... 184Figura 79. Desde la versión NetBeans 5.5 incorpora JMV HotSpot. ................................................... 185Figura 80. Depuración en Visual Studio................................................................................................... 192Figura 81. Probando el WS en .NET. ....................................................................................................... 192Figura 82. Digitando Valores en .Net. ...................................................................................................... 192Figura 83. Resultado Devuelto en .NET. ................................................................................................. 192Figura 84. Iniciando el IIS........................................................................................................................... 193Figura 85. Configurando Propiedades. .................................................................................................... 193Figura 86. Configuración Paso 1............................................................................................................... 194Figura 87. Configuración Paso 2............................................................................................................... 194Figura 88. Configuración Paso 3............................................................................................................... 195Figura 89. Probando el WS en el IIS. ....................................................................................................... 195Figura 90. Testear y ver el WSDL con el IIS. .......................................................................................... 196Figura 91 Create DataBase. ...................................................................................................................... 196Figura 92. Creando BD paso 1.................................................................................................................. 197Figura 93. Creando BD Paso 2. ................................................................................................................ 197Figura 94. Creando BD Paso 3. ................................................................................................................ 197Figura 95. Creando BD Paso 4. ................................................................................................................ 198Figura 96. Creando BD Paso 5. ................................................................................................................ 198Figura 97. Start Servidor. ........................................................................................................................... 201Figura 98. Desplegando Servicio Web..................................................................................................... 201

Figura 99. Creando Formulario del Cliente .NET. .................................................................................. 203Figura 100. Vista del Cliente .NET en el Navegador. ............................................................................ 207Figura 101. Creando Formulario del Cliente J2EE. ................................................................................ 210Figura 102 Parte del Código del Cliente J2EE........................................................................................ 210Figura 103. Ejecutando Cliente J2EE....................................................................................................... 211Figura 104. Vista del Cliente J2EE en el Navegador. ............................................................................ 211

INDICE DE TABLAS

Tabla 1. Lenguajes Soportados por .NET _________________________________________________ 49Tabla 2. Aspectos Relacionados Entre J2EE y .NET _______________________________________ 58Tabla 3. Especificaciones Del Sistema Cómputo. __________________________________________ 84Tabla 4. Tiempo de Arranque de Cada IDE. _______________________________________________ 84Tabla 5. Tiempo de Arranque de Cada Servidor. ___________________________________________ 85Tabla 6. Numero de Instancias. __________________________________________________________ 85Tabla 7. Tiempo en crear un WS en cada IDE._____________________________________________ 87Tabla 8. Compilación y despliegue de WS. ________________________________________________ 91Tabla 9. Disponibilidad de NetBeans en varios SO ________________________________________ 104Tabla 10. Configuración Para J2EE._____________________________________________________ 115Tabla 11. Configuración Para .NET. _____________________________________________________ 115Tabla 12. Resumen de Transacciones en J2EE. __________________________________________ 116Tabla 13. Resumen de Transacciones en .NET. __________________________________________ 116Tabla 14. El tiempo y los Usuarios Activos en J2EE. ______________________________________ 117Tabla 15. El tiempo y los Usuarios Activos en .NET._______________________________________ 117Tabla 16. Peticiones Realizadas en J2EE. _______________________________________________ 118Tabla 17. Peticiones Realizadas en .NET.________________________________________________ 119Tabla 18. Datos recibidos por Usuarios en J2EE. _________________________________________ 120Tabla 19. Datos recibidos por Usuarios en .NET. _________________________________________ 120Tabla 20. Errores en .NET. _____________________________________________________________ 121Tabla 21. Especificaciones y Detalles de los Errores en .NET.______________________________ 121Tabla 22. Error 403 en .NET. ___________________________________________________________ 122Tabla 23. Tiempo contra el Porcentaje de error en .NET.___________________________________ 122Tabla 24. Tiempo de Respuesta Para J2EE. _____________________________________________ 123Tabla 25. Tiempo de Respuesta Para .NET.______________________________________________ 123Tabla 26. Tiempo promedio de cada transacción en J2EE. _________________________________ 124Tabla 27. Tiempo promedio de cada transacción en .NET. _________________________________ 125Tabla 28. Usuarios Contra El Tiempo de Respuesta para J2EE. ____________________________ 126Tabla 29. Usuarios Contra El Tiempo de Respuesta para .NET. ____________________________ 126Tabla 30. Usuarios Contra El Rendimiento para J2EE._____________________________________ 127Tabla 31. Usuarios Contra El Tiempo de Respuesta para .NET. ____________________________ 127Tabla 32. Análisis de Posibles Cuellos De Botellas para J2EE. _____________________________ 128Tabla 33. Análisis de Posibles Cuellos De Botellas para .NET. _____________________________ 129Tabla 34. El Tiempo De Las Páginas Descargada para J2EE. ______________________________ 130Tabla 35. El Tiempo De Las Páginas Descargada para .NET. ______________________________ 130Tabla 36. Tamaño De la Página J2EE.___________________________________________________ 131Tabla 37. Tamaño De la Página .NET.___________________________________________________ 131Tabla 38. Tiempo De Descarga Por Páginas en J2EE._____________________________________ 132Tabla 39. Tiempo De Descarga Por Páginas en J2EE._____________________________________ 132Tabla 40. Resumen Del Test de J2EE.___________________________________________________ 133Tabla 41. Resumen Del Test de .NET.___________________________________________________ 134Tabla 42. Cuatro conexiones simultáneas. _______________________________________________ 135Tabla 43. Nueve Conexiones. __________________________________________________________ 136Tabla 44. Tiempo de Descarga y Errores. ________________________________________________ 136Tabla 45. Creando BD Paso 1.__________________________________________________________ 186Tabla 46. Creando BD Paso 2.__________________________________________________________ 187Tabla 47. Creando BD Paso 3.__________________________________________________________ 187Tabla 48. Creando BD Paso 4.__________________________________________________________ 187

RESUMEN

El siguiente trabajo se constituye en un estudio que abarca los diferentes aspectos más

relevantes que se deben tener en cuenta a la hora de escoger entre J2EE y .NET, en el

contexto de los servicios web. Se realizó un análisis comparativo donde se muestra las

principales ventajas y desventajas. Así mismo se implementó un prototipo de servicio y

cliente web en cada plataforma

En el capítulo I se analiza el problema que conlleva al desarrollo de esta investigación con

su respectiva justificación y se establecen los objetivos del proyecto.

En el capítulo II Se definen algunos conceptos de los servicios web mostrando los

diferentes estándares en que estos se basan. También se estudian los principales

atributos tanto de la plataforma J2EE y de la plataforma .NET.

En el capítulo III se analizan los principales aspectos en que se relacionan J2EE y .NET

en el nivel de servicios web, el cual proporcionó una base para seleccionar los criterios

que se compararon. También se justifican las herramientas seleccionadas para realizar

dicho comparativo.

En el capítulo IV se realizo el comparativo en el siguiente orden:

Seguridad. Se estudia la seguridad a nivel de mensaje, analizando la

especificación de WS-Security, y mostrando una implementación básica en

ambas plataformas.

Portabilidad. En este criterio se estudia la maquina virtual de java (JVM) para J2EE

y el lenguaje común en tiempo de ejecución (CLR) para .NET.

IDEs. Para realizar la comparación entres los dos IDEs se utilizaron pruebas de

tiempo de respuestas, para realizar algunas tareas específicas que involucre el

desarrollo de un Servicio Web en cada herramienta. Además se estudio las

opciones, flexibilidad, facilidad que brinda cada herramienta al desarrollador para

lograr un juicio más real, aparte de las obtenidas por las pruebas de tiempo de los

dos IDEs

Interoperabilidad. Se inicio el análisis, estudiando la interoperabilidad a través

Metro y WCF. También se realizó un cliente J2EE y .NET para que consumieran

servicios web realizados en ambas plataformas. También se estudiaron tipos de

datos devueltos o retornados por los web servicies para determinar el grado de

interoperabilidad.

Desempeño. Se estudió el desempeño de ambas plataformas, realizando pruebas

o test con AdventNet QEngine aumentado usuarios y cargas de trabajos.

ABSTRACT

The next project is a study covering different aspects most relevant to be taken into

account when choosing between J2EE and .NET in the context of Web Services. A

comparative analysis was realized, where one shows the principal advantages and

disadvantages. Likewise there implemented a prototype of service and client web in every

platform.

In chapter I discussed the problem that leads to the development of this Investigation with

his respective justification and set the objectives of the project.

In Chapter II are defined some concepts of Web Services showing the different standards

to which these are based. Also the principal attributes are studied so much of the platform

J2EE and of the platform .NET.

In Chapter III There are analyzed the principal aspects in which they relate J2EE and .NET

in the level of services web, which provided a base to select the criteria that were

compared. Also the tools justify themselves selected to realize comparative saying.

In Chapter IV Realize the comparative one in the following order:

Security. Studied the security level of message, analyzing the specification of WS-

Security, and showing a basic implementation in both platforms.

Portability. In this approach studied the Java Virtual Machine (JVM) for J2EE and

the common language runtime (CLR) for .NET.

IDEs. To make the comparison between the two IDEs, using evidence-time

responses to perform some specific tasks that involve the development of a Web

Service in each tool. In addition, study the options, flexibility, ease afforded to every

developer tool to achieve a more real than those obtained by testing time for the

two IDEs.

Interoperability. Is initiate the analysis, studying the interoperability to slant Metro

and WCF. Also there carried out a client J2EE and NET to consume Web Services

in both platforms. Also examined types of data sent back or returned by Web

Services to determine the degree of interoperability.

Performance. There was studied the performance of both platforms realizing test

with AdventNet QEngine increased users and loads of works.

CAPITULO I

INTRODUCCIÓN

Es muy cierto que los sistemas de información, programas u otros, han tenido un gran

impacto en consecuencias positivas en la sociedad moderna. Estos mismos sistemas a

medida que crecen de forma acelerada, también lo hacen las necesidades que dan

soporte a dichas tecnologías, y con ellos se crean nuevos retos y así se producen o nacen

nuevas tecnologías. De este modo los servicios web se pueden ver como la respuesta o

solución de algunas necesidades causada por las interacciones de sistemas

heterogéneos, aunque los servicios web no es la única solución a este problema, cuando

se emplean de forma adecuada generan ciertas ventajas.

Una de las mayores ventajas de los servicios web es sin duda alguna la posibilidad de

interactuar con otras aplicaciones implementadas en el mismo o en diferentes sistemas

operativo, aportando así interoperabilidad que es aprovechado por los sistemas

distribuidos y la arquitectura SOA, además de fomentar algunos estándares y protocolos,

por la naturaleza misma de esta tecnología.

Hoy la plataforma J2EE al igual que la plataforma .NET son las principales alternativas

para desarrollar soluciones que se basen en clientes y servicios web, ya que ambas

ofrecen lo necesario para llevar a cabo de forma satisfactoria soluciones empresariales.

Igualmente son J2EE y .NET las plataformas más utilizadas en el mercado, conllevando a

que se genere una rivalidad que es de gran controversia al intentar definir o establecer

fortalezas y debilidades existentes, generando justamente una dificultad latente a la hora

de escoger entre J2EE y .NET.

Una de las principales causas de este problema, es que se mitifican algunas

características propias de estas plataformas ocasionando a veces, desviar u opacar las

ventajas reales que cada plataforma puede aportar sobre ciertas necesidades

particulares. Lo anterior, produce dificultad y cierto grado de confusión en la etapa de

selección de una plataforma apropiada.

En este proyecto se trata precisamente de mostrar cuáles son esas fortalezas y

debilidades de estas plataformas, al comparar algunos criterios en el plano de los

servicios web. Aunque no se compararon todos los criterios posibles, se escogieron los de

mayor relevancia que produzcan mayor impacto en el área de los servicios.

Por otro lado, Se desarrolla la documentación técnica necesaria y suficiente para ejecutar

la implementación de un servicio y cliente en ambas plataformas, con el fin comprobar en

efecto que los servicios web es un mecanismo eficaz para conseguir la interoperabilidad

entre J2EE y .NET, y para incrementar los conocimientos prácticos de cada plataforma

estableciendo un nivel adicional de garantía al comparativo realizado.

Este estudio ayuda a tener una noción más clara del funcionamiento arquitectónico, de las

principales característica, de las ventajas o desventaja que ofrece cada plataforma.

Soportado en cada análisis y conclusiones producto del resultado de cada criterio

comparado.

1.1 DESCRIPCIÓN DEL PROBLEMA

En los últimos años se ha presentado y experimentado un crecimiento en las empresas u

organizaciones en donde se ven involucradas diferentes facetas tecnológicas, la cual

plasma la dinámica actual de dichas empresas. Uno de los principales aspectos que se

ven afectados por esta dinámica es la necesidad de permitir que las aplicaciones

interoperen dinámicamente con otras aplicaciones web, no importando el lenguaje de

programación en que fueron construidos ni tampoco los sistemas operativos en que estos

operen.

Frente a esta nueva demanda surgen diversas plataformas para el desarrollo de este tipo

de aplicaciones: J2EE (Java 2 Platform Enterprise Editition) y .NET de Microsoft, dado

que son las plataformas más utilizadas actualmente en el mercado. No obstante a la

hora de implementar las aplicaciones web tanto los programadores o desarrolladores

como las empresas mismas, se ven en la dificultad de elegir una de las dos plataformas.

Tal dificultad se genera gracias a que se ven inundados de ciertas estrategias de

Marketing, publicidad, popularidad, mitos, la mayoría de veces producida por ciertos

defensores y detractores de la plataforma J2EE o .NET. Por consiguiente, se pierde

objetividad de los argumentos a la hora de intentar valorar y comparar J2EE frente a

.NET, para estimar la tecnología apropiada a utilizar en el desarrollo de aplicaciones

empresariales o corporativas.

1.2 JUSTIFICACIÓN

Actualmente los servicios web han tomado más fuerzas en todo lo que se refiere a los

desarrollos e implementaciones de aplicaciones distribuidas, que necesitan las empresas

o corporaciones para ejecutar su lógica de negocio.

Por eso, la importancia de realizar un estudio comparativo de las dos plataformas más

importante del mercado actual, verificando cual se adapta y se ajusta más a los

requerimientos mismos de la aplicación que se pretende desarrollar. Buscando con ello,

una orientación mucho más real, tanto a las empresas como a los desarrolladores o a las

personas que tienen la responsabilidad de elegir en que plataforma realizaran sus

aplicaciones web.

Por otra parte, en la Universidad de Pamplona no existe ninguna referencia o estudio

realizado sobre el presente tema, el cual produce dificultad tanto en los estudiantes, como

en los profesores e investigadores al momento de indagar y examinar material

bibliográfico que les pueda aportar en sus estudios que estén realizando, y que estén a fin

con el tema que se pretende desarrollar.

1.3 OBJETIVOS DEL PROYECTO

1.3.1 Objetivo General

Realizar un análisis comparativo entre la plataforma J2EE y la plataforma .NET aplicado al

desarrollo de servicios web.

1.3.2 Objetivos Específicos

Recopilar el estado del arte de los Servicios Web.

Determinar los criterios de análisis de ambas plataformas, respecto al desarrollo de

servicios web.

Realizar un análisis comparativo entre las dos plataformas para el desarrollo de los

servicios web de acuerdo a los criterios establecidos.

Desarrollar un prototipo de servicio web en las dos plataformas.

Redactar un artículo como resultado del comparativo de las plataformas estudiadas.

CAPITULO 2MARCO HISTORICO Y CONCEPTUAL

2.1 Estado del arte a nivel mundial

A nivel mundial se encontraron algunos trabajos y artículos sobre servicios web y también

comparativos entre J2EE y .NET. Algunos de estos se describen a continuación

Evaluación Comparativa de aplicaciones Web entre J2EE y Microsoft .NET:Esta investigación de Miguel Ángel Garrido estudia los aspectos y conocimientos

que se necesitarían para seleccionar la tecnología apropiada, para implementar de

mejor manera el desarrollo de aplicaciones Web. Así mismo crea áreas de

evaluación, dentro de las cuales define ciertos criterios de comparación entre

J2EE y .NET [07].

Comparison Of Interoperability Between J2EE And .NET Web Services: En

este trabajo realizado por Maneesh Rampally se estudia dos aspectos

importantes. El primero consiste en realizar una aplicación de comercio electrónico

utilizando WS J2EE y realizar Clientes .NET para comprobar que en efecto es

posible realizar, algún tipo de interoperabilidad entre estas dos plataformas. En

segundo lugar estudia el desempeño de cada uno realizando servicios J2EE, .NET

y cruzándolos con clientes J2EE, .NET [21].

J2EE vs. Microsoft.NET: En este Documento creado por Chad Vawter y Ed

Roman en el 2001, se estudian las arquitecturas de ambas plataformas y se

realiza un análisis final de algunos aspectos que ellos consideran más relevantes,

estableciendo así las fortalezas y debilidades de cada uno [29].

Estado del Arte de la Tecnología de Web Services. Esta trabajo realizado por

Edgardo A. Romero M. se fundamentó en el Desarrolló de una investigación

bibliográfica sobre los web services así como las principales tecnologías de

implementación, con el fin de mostrar su influencia en los factores tecnológicos y

económicos de la sociedad [01].

Algoritmo de emparejamiento de perfiles en Servicios Web Semánticos. Este

artículo creado por José J. Samper, Eduardo carrillo y Juan J. Martínez. describe

las principales características de un algoritmo de emparejamiento de Servicios

Web Semánticos y los principales componentes relacionados con el proceso de

implementación.

2.2 Estado del arte a nivel nacional y local

A nivel nacional no se encontró algún trabajo relacionado con la comparación de ambas

plataformas. No obstante se encontró un gran número de investigaciones acerca de los

servicios web tanto para J2EE como para .NET, en el ámbito nacional y local. Algunos de

estos se citan a continuación.

2.2.1 Nacional

Mecanismo de control de acceso a web services. Este trabajo realizado por

William V. Romero y Juan G. Rojas, menciona los problemas principales de

seguridad de los Web Services que se desarrollan, planteando dos soluciones;

una de ellas enfocada a solucionar el problema del control de acceso por medio de

los mecanismos existentes basados en los estándares de la W3C, y su

implementación por parte de la empresa Microsoft; y otra enfocada a crear un

mecanismo de control de acceso basada en roles, desarrollada desde su

concepción hasta su implementación por los autores [22].

2.2.2 Local

Arquitecturas Orientadas a Servicios como soporte a modelos de educaciónvirtual (Módulos: Académico, investigación, entorno y los servicios aestudiantes). En este trabajo realizado por JORGE A. PORTILLA G. se diseña un

prototipo que maneje la información a través de Web Services de los módulos

académicos, investigación, entorno y los servicios a estudiantes, los cuales

contiene servicios propios e independientes y prestan servicios a otros módulos

conformando así una arquitectura orientada a servicios que soporta modelos de

educación virtual.

Método para la implementación de confidencialidad, integridad, autenticidad,no repudio, control de acceso y continuidad en los Servicios Wb TCP/IPusando software libre. En este trabajo realizado por ALFERT J. CASTILLO L.

ofrece un método para la implementación de los elementos de la seguridad

computacional en los Servicios Web.

2.3 Historia de los Servicios Web

Hace años, todas las aplicaciones informáticas de importancia se llevaban a cabo

mediante grandes computadoras. Luego aparecieron las terminales para conectarse a

estas grandes computadoras, de forma que los usuarios pudieran utilizarlos por medio de

comandos en texto normal. Algunos años después, surgió el computador personal o PC,

desde el cual los usuarios podían ejecutar sus propias aplicaciones [1].

En los 80's, en particular en el sector de los computadores personales, los protocolos de

comunicación no ocupaban un lugar demasiado importante para los desarrolladores, la

dificultad consistía en que varias aplicaciones se comunicaran entre sí [1].

En los 90's, algunas estructuras de objetos, como COM (Component Object CODEL) de

Microsoft y CORBA (Common Object Request Broker Architecture), que se comercializó

como una iniciativa entre proveedores de OMG (Grupo de Gestión de Objetos), cobraron

popularidad [1].

COM y CORBA eran modelos y arquitecturas diseñadas para la escritura y

encapsulamiento del código binario, componentes que eran llamados por los

programadores desde cualquier aplicación [1].

COM y CORBA no interoperaban fácilmente. En estos tiempos lejanos, las máquinas

informáticas independientes eran las que dominaban el mundo [1].

2.3.1 La era de las redes locales.

La extensión de las redes locales a principios de los 90's, y la conexión entre máquinas se

volvió una prioridad. Los proveedores y las organizaciones que ya contaban con sus

propias estructuras de modelo-objeto, las ampliaron para permitir la comunicación a

través de redes [1].

OMG estableció el IIOP (Internet Inter-ORB Protocol) como protocolo de comunicación

estándar de CORBA [1].

Microsoft introdujo el DCOM (Distributed COM) como su protocolo de comunicación que

permitía cruzar las fronteras entre equipos. Otro poderoso aspirante surgió con

posterioridad a IIOP y DCOM, el RMI (Remote Method Invocation) de Sun MicroSystems,

utilizado por los usuarios de Java [1].

2.3.2 La era de Internet y la Web.

La conexión de aplicaciones mediante el uso de cualquiera de los protocolos

mencionados con anterioridad se caracteriza por un buen funcionamiento, en especial

cuando dichas aplicaciones se encuentran en la misma red local [1].

Con la aparición de Internet, y en particular de la Web, la red creció inmensamente, y se

volvió extremadamente distribuida y descentralizada. Ni personas, ni empresas eran

capaces de tomar la decisión sobre qué sistema operativo o entorno de

programación/lenguaje, se ejecutaría en los diversos computadores conectados a

Internet. Esto significa que las reglas que tienen vigencia en la red local, no funcionan de

forma óptima en Internet y la Web [1].

Primero surgieron las Web Aisladas. Luego surgió la interoperabilidad en aplicaciones y

sitios Web por medio de los Frames (Frameset). Posteriormente se empleo CGI (Common

Gateway Interface), para la publicación de la información (HTTP GET y POST) [1].

Tras la aparición de XML a mediados de los noventa, los desarrolladores se encontraron

con la posibilidad de expresar una estructura de información y mensajes de forma auto

descriptiva y uniforme, lo que impulso a XML, para aplicar un formato a los mensajes

intercambiados entre sistemas [1].

Uno de los primeros protocolos para la comunicación mediante el protocolo HTTP, que

permite llamar a procedimientos remotos sin importar el lenguaje de desarrollo o el

sistema operativo fue XML-RPC, sin embargo a pesar de ser el primero en este campo y

de las ventajas que ofrece la mayoría de proveedores optaron por su sucesor SOAP

(Simple Object Access Protocol) [1].

El concepto de Web Services comenzó a tomar forma definitiva con la introducción de

SOAP como protocolo de mensajería entre computadores. A pesar de que su nombre

pueda parecer que requiere del uso de determinados objetos, SOAP especifica el formato

del mensaje que accede e invoca a los objetos, en vez de especificar los objetos en sí

[1].

En mayo del año 2000, el W3C (World Wide Web Consortium http://www.w3c.org/)

reconoció la propuesta de SOAP presentada de forma conjunta por un conglomerado de

empresas (Ariba Inc., CommerceOne Inc., Compaq Computer Corp., Microsoft Corp.,

Development Corp., IBM Corp, Hewlett-Packard Co., etc). Siendo desarrollado en base a

un estándar abierto [1].

2.3.3 Evolución histórica de la Web.

Con el surgimiento del Internet las aplicaciones en la web partieron usando el lenguaje de

etiquetas HTML, permitían usar la web como medio para distribuir documentos estáticos,

estos se alojaban en servidores Web que usaban el protocolo de comunicación HTTP,

luego la información se desplegada por navegadores web en cualquier cliente en el

mundo que los invocara por medio de una dirección web conocida como URL, con el paso

del tiempo se observo la necesidad de generar información dinámicamente, como

solución a este problema, se desarrollaron aplicaciones web, usando códigos fuente

escritos en diferentes lenguajes de programación como ASP, PHP, PERL, etc. Estos

códigos fuentes se alojaban y se ejecutaban en servidores web, estos generaban HTML

en forma dinámica [1].

Luego los servidores web permitieron incorporar capacidades de programación

distribuida, pero las necesidades de los usuarios son mayores cada día hasta que se

necesito integrar las aplicaciones web con otras del mismo tipo, integrar aplicaciones

entre diferentes plataformas, lenguajes de programación, sistemas operativos,

compañías, etc. como alternativas de a tal necesidad la representación de información

(como XML) y nuevos mecanismos de transporte (como SOAP) aparecieron uniéndose

para formar lo que ahora se conoce como los Web Services [1].

http://www.w3c.org/

2.4 Definiciones de Los Servicios Web

Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su

complejidad a la hora de dar una adecuada definición que englobe todo lo que son e

implican. A continuación se presentan algunas de ellas:

Un Web Service es un componente de software que se comunica con otras

aplicaciones codificando los mensajes en XML y enviando estos mensajes a través

de protocolos estándares de Internet tales como el Hypertext Transfer Protocol

(HTTP). Intuitivamente un Web Service es similar a un sitio web que no cuenta con

un interfaz de usuario y que da servicio a las aplicaciones en vez de las personas.

Un Web Service, en vez de obtener solicitudes desde el navegador y retornar

páginas web como respuesta, lo que hace es recibir solicitudes a través de un

mensaje formateado en XML desde una aplicación, realiza una tarea y devuelve

un mensaje de respuesta también formateado en XML [02].

Conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la

Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo

de ofrecer unos servicios. Los proveedores ofrecen sus servicios como

procedimientos remotos y los usuarios solicitan un servicio llamando a estos

procedimientos a través de la Web [03].

Una aplicación software identificada por un URI, cuyas interfaces se pueden

definir, describir y descubrir mediante documentos XML. Un Servicio Web soporta

interacciones directas con otros agentes software, utilizando mensajes XML

intercambiados mediante protocolos basados en Internet [03].

Los Servicios Web basados en XML permiten que las aplicaciones compartan

información y que además invoquen funciones de otras aplicaciones

independientemente de cómo se hayan creado las aplicaciones, cuál sea el

sistema operativo o la plataforma en que se ejecutan y cual sea el dispositivo

utilizado para tener acceso a ellas [03].

2.5 Requisitos de un Web Service

Interoperabilidad: Un Servicio Web debe permitir su utilización por clientes de otras

plataformas.

Amigabilidad con Internet: La solución debe poder funcionar para soportar clientes

que accedan a los servicios remotos desde internet.

Interfaces fuertemente tipadas: No debería haber ambigüedad acerca del tipo de

dato enviado y recibido desde un Servicio Web. Más aún, los tipos de datos definidos

en el Servicio Web deben poderse corresponder razonablemente bien, con los tipos

de datos de la mayoría de los lenguajes de programación procedimentales.

Posibilidad de aprovechar los estándares de Internet existentes: La

implementación del Servicio Web debería aprovechar estándares de Internet

existentes tanto como sea posible y evitar reinventar soluciones a problemas que ya

se han resuelto. Una solución construida sobre un estándar de Internet ampliamente

adoptado puede aprovechar conjuntos de herramientas y productos existentes

creados para dicha tecnología.

Soporte para cualquier lenguaje: La solución no debería ligarse a un lenguaje de

programación particular. Un cliente debería ser capaz de implementar un nuevo

Servicio Web existente independientemente del lenguaje de programación en el que

se halla escrito el cliente

Soporte para cualquier infraestructura de componente distribuida: La solución no

debe estar fuertemente ligada a una infraestructura de componentes en particular [06].

2.6 Web Services Protocol Stack

La Pila de protocolos para Servicios Web, es una colección de protocolos para redes de

Computadores que son utilizados para definir, localizar, implementar y hacer que un

Servicio Web interactúe con otro. La Pila de Protocolos para servicios está comprendida

principalmente por cuatro áreas:

Mensajería XML: responsable por la codificación de mensajes en un formato común

XML así que ellos puedan ser entendidos en cualquier extremo de una conexión de

red. Actualmente, esta área incluye protocolos tales como XML-RPC, SOAP y REST.

Servicio de Transporte: responsable del transporte de mensajes entre las

Aplicaciones de red y los protocolos en los cuales se incluyen protocolos tales como

HTTP, SMTP, FTP, Blocks Extensible Exchange Protocol (BEEP).

Descripción del Servicio: usado para describir la interface pública de un Servicio

Web especifico. El archivo WSDL es típicamente usado para este propósito.

Descubrimiento de servicios: centraliza servicios en un registro común tal que los

servicios Web de la red puedan publicar su localización y descripción, y hace que sea

fácil descubrir que servicios están disponibles en la red. Actualmente, la API UDDI se

utiliza normalmente para el descubrimiento de servicios [05].

2.6.1 XML

Es un estándar para la representación estructurada de datos y crear etiquetas, definido

por el World Wide Web Consortium (W3C). Las características especiales son la

independencia de datos, o de la separación de los contenidos de su presentación. Es un

metalenguaje que permite diseñar un lenguaje propio de etiquetas para múltiples clases

de documentos. Los documentos XML se componen de unidades de almacenamiento

llamadas entidades (entities), que contienen datos analizados (parsed) o sin analizar

(unparsed). Los datos analizados se componen de caracteres, algunos de los cuales

forman los datos del documento y el resto forman las etiquetas. Las etiquetas codifican la

descripción de la estructura lógica y de almacenamiento del documento. XML proporciona

un mecanismo para imponer restricciones en la estructura lógica y de almacenamiento

[01].

Figura 1 Representación de Datos XML y HTML

Figura 2. XML como Tecnología e Innovación

2.6.2 Protocolo de acceso de objeto Simple (SOAP)

Es el protocolo de comunicaciones que usan los Web Services. Define los mecanismos

por los cuales un Web Service, es invocado y cómo devuelve los datos. SOAP es un

estándar definido por W3C y creado a partir de un grupo de trabajo integrado por varias

asociaciones.

2.6.2.1 Estructura de un mensaje Soap

Figura 3. Composición de un mensaje SOAP

A continuación se observa un ejemplo de solicitud y respuesta para SOAP 1.1 [01]

Figura 4. Solicitud Utilizando Soap

Figura 5. Respuesta Utilizando Soap

2.6.2.2 Ventajas de utilizar Soap

Fácil de implementar y usar.

Utiliza los mismos estándares de la web: HTTP para la comunicación, protocolos

de autenticación y encriptación.

Atraviesa “firewalls” y routers ya que piensan que es una comunicación HTTP.

Tanto los datos como las funciones se describen en XML.

No depende del sistema operativo y procesador

Se puede implementar en casi cualquier lenguaje de programación.

SOAP provee un mecanismo independiente del protocolo, que se use para la

comunicación, para asociar el encabezado al cuerpo del mensaje: a esto se le

conoce como “envelope”.

SOAP no impone ninguna restricción acerca de cómo debe formatearse el cuerpo

del mensaje [01].

2.6.3 WSDL

Describe la interfaz externa de un Web Service y cómo utilizarlo. Se puede definir un

archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y

la forma en que éstos interactúan.

Puesto que la notación que utiliza WSDL es XML significa que es un idioma de

programación neutral, basado en estándares (W3C) y que puede utilizarse desde una

gran variedad de plataformas y lenguajes [01].

Figura 6. Ejemplo de un documento Wsdl

2.6.3.1 Descripción del Wsdl

Información de interfaz que describe todas las funciones públicamente accesibles.

Información de los tipos de datos para todos los mensajes de petición y respuesta.

Información acerca del protocolo de transporte a utilizar.

Información para localizar un servicio específico. Representa un contrato entre el

peticionario del servicio y el servicio proveedor.

El cliente puede localizar un servicio web y llamar a alguna de sus funciones.

El lenguaje de descripción de Web Services WSDL es un lenguaje XML que

contiene información acerca de la interfaz, semántica, y administración de una

llamada a un Web Service [01].

2.6.4 UDDI

El proyecto Universal Description, Discovery and Integration (UDDI) es una iniciativa de la

industria para crear una plataforma independiente que, a modo de marco de trabajo

abierto, especifica servicios, descubrir negocios e integrar servicios empresariales a

través de Internet.

Es un elemento básico sobre el que se asientan los Web Services, hace posible que

empresas pueden tanto publicar como encontrar Web Services. UDDI provee un

mecanismo para que los negocios se "describan" a sí mismos y los tipos de servicios que

proporcionan. Los Web Services son registrados para que los posibles usuarios puedan

encontrarlos, tales negocios publicados pueden ser buscados, consultados o

"descubiertos" por otros negocios utilizando mensajes SOAP. Un registro UDDI es como

la lista de los Web Services, es decir, una entrada en UDDI es un archivo XML que,

realizando una similitud con las páginas amarillas, describe el proveedor y los servicios

que ofrece [01].

2.6.4.1 Los datos manejados por UDDI se dividen en tres categorías

1. Páginas Blancas: Con información general sobre una empresa (nombre,

descripción, información de contacto, dirección y teléfono).

2. Páginas Amarillas: Es muy similar a su equivalente telefónico, e incluyen

categorías de catalogación industrial tradicionales, ubicación geográfica, etc.

Mediante el uso de códigos y claves predeterminadas, los negocios se pueden

registrar y así facilitar a otros servicios la búsqueda usando estos índices de

clasificación.

3. Páginas Verdes: Con información técnica sobre un servicio web. Generalmente

esto incluye un apuntador a la especificación externa y una dirección en la que

invocan el servicio [01].

2.7 Dinámica de los Servicios Web

1. Cliente pregunta al registro (UDDI) para ubicar un servicio.

2. El registro le indica al cliente un documento WSDL.

3. Cliente accede al documento WSDL

4. WSDL provee lo necesario para que el cliente pueda interactuar con el

servicio.

5. El cliente envía un requerimiento usando SOAP

6. El Web Service retorna una respuesta SOAP.

Figura 7. Dinámica de un Servicio[08].

2.8 PLATAFORMA .NET

2.8.1 Que es .NET?

.NET es un proyecto de Microsoft para el desarrollo de software con énfasis en

transparencia de redes, con independencia de plataforma de hardware y que permite un

rápido desarrollo de aplicaciones. Basado en esto, la empresa desarrolla una estrategia

horizontal integrando todos sus productos, desde el sistema operativo hasta las

herramientas de mercado [04].

2.8.2 Principales objetivos de la plataforma .NET

Liberar al programador de las cuestiones de infraestructura (aspectos nofuncionales). Así, el Framework .NET se encarga de gestionar automáticamente

tales cuestiones como la gestión de la memoria, de los hilos o de los objetos

remotos.

Proporcionar integración entre diferentes lenguajes. Con el auge de los

sistemas distribuidos, la interoperabilidad se ha convertido en una de las

principales cuestiones de los desarrolladores de sistemas. El problema de la

interoperabilidad ha sido considerado durante muchos años, desarrollándose

varios estándares y arquitecturas con diferente nivel de éxito.

Proporcionar una ejecución multiplataforma. .NET ha sido diseñado

para ser independiente de la plataforma sobre la cual se ejecutaran las

aplicaciones, si bien actualmente sólo está disponible el Framework .NET

para las distintas plataformas Windows.

Sistema de despliegue simple. Se ha eliminado la necesidad de tratar con el

registro, con GUIDs, etc, de forma que la instalación de una aplicación es tan

sencilla como su copia en un directorio.

Mejora de la escalabilidad. La gestión por parte del sistema de ejecución de

.NET de cuestiones como la memoria permite mejorar la escalabilidad.

Proporcionar soporte para arquitecturas fuertemente acopladas y débilmente

acopladas. Para conseguir un buen rendimiento, escalabilidad y confiabilidad con

grandes sistemas distribuidos, hay operaciones en las cuales los componentes

están fuertemente acoplados. Sin embargo, también debe soportarse una

comunicación débilmente acoplada orientada a mensajes, de forma que una

transacción no quede interrumpida o bloqueada por cualquier dependencia en

tiempo de ejecución.

Proporcionar un mecanismo de errores consistente. En .NET todos los

errores son manejados mediante un mecanismo de excepciones, el cual permite

aislar el código de manejo de errores del resto, permitiéndose la propagación de

excepciones entre distintos módulos [04].

2.8.6 Principales lenguajes soportados por .NET.

Actualmente .NET soporta una gran variedad de lenguajes de programación. Entre los

principales lenguajes soportados por .NET se encuentran los siguientes:

Tabla 1. Lenguajes Soportados por .NET

2.8.4 Arquitectura .NET

Figura 8. Arquitectura de .NET

.NET presenta distintos niveles de aplicaciones y componentes ofreciendo distintas

capacidades y servicios apoyándose en los sistemas operativos Windows, y sistemas

compatibles. De esta forma puede presentar a los usuarios incluidos dentro del nivel

superior de la arquitectura los siguientes aspectos divididos en 3 capas:

1. La capa de presentación: formada por los componentes de IU, y los

componentes de proceso de IU. Los componentes de IU son los cuales

interactúan con el usuario (por ejemplo ventanas o páginas Web). Los

componentes de proceso de IU son los distinto tipo de clases del tipo

controladora en UML, lo cuales encapsulan la lógica de navegación y control

de eventos de la interface.

2. La capa de negocios: es la capa o nivel que encapsula la lógica de

negocios. Las entidades empresariales representan objetos que van a ser

manejados por la aplicación (modelo de objetos, xml, datasets con tipo,

estructuras de datos), las cuales permiten representar objetos que han sido

identificados durante el modelamiento. Los componentes empresariales

contienen lógica de negocios y en algunos casos pueden ser los objetos raíz que

inician las transacciones.

3. La capa de acceso a datos: capa que contiene las clases que interactúan con

las base de datos. Éstas surgen con la necesidad de mantener la

cohesión o clases altamente especializadas que ayuden a reducir la

dependencia entre las clases y capas. Aquí se encuentra la clase de métodos

estáticos que permite uniformizar las operaciones de acceso a datos a través de

un único conjunto de métodos [07].

2.8.3 ¿Qué es .NET Framework?

.NET Framework es el marco de trabajo con el cual se desarrollan las aplicaciones. Es un

conjunto de servicios de programación diseñados para simplificar el desarrollo de

aplicaciones en el entorno altamente distribuido de Internet. El .NET Framework

se instala como un componente aparte en Windows 2000, mientras que Windows

XP, Windows vista y las futuras versiones de Windows lo incorporan directamente al

sistema operativo. [09].

El FrameWork .NET es el resultado de la confluencia de dos proyectos; el primero de ellos

tenía como objetivo la mejora del desarrollo sobre las plataformas Windows, prestando

una especial atención a la mejora del modelo COM, mientras que el segundo proyecto,

conocido como NGWS (Next Generation Windows Services), tenía como objetivo la

creación de una plataforma para el desarrollo del software como servicio. El producto

resultante de ambos proyectos mejora considerablemente el desarrollo, despliegue y

ejecución de las aplicaciones, e introduce el concepto de los servicios Web [04].

El FrameWork .NET administra gran parte de los detalles de infraestructura, permitiendo a

los desarrolladores centrarse en escribir el código de la lógica empresarial para sus

aplicaciones. .NET Framework incluye Common Language Runtime y bibliotecas de

clases [01]. Para conocer más sobre el CLR Ver ANEXO II [PORTABILIDAD EN J2EE Y

.NET].

Figura 9. FrameWork se desarrollan todas las aplicaciones

2.8.5 Framework 3.0 Y 3.5

Microsoft ha lanzando el nuevo Framework 3.5 La versión Framework .NET 3.5 no tiene

grandes diferencias con la versión 3.0, solamente fue un agregado de más librerías. Lo

interesante se presenta en la versión 3.0. Los nuevos componentes son: Windows

Presentation Foundation (WPF), Windows Communication Foundation (WCF) y

Windows Workflow Foundation (WF) [10].

Figura 10. Características de .NET FrameWork 3.5

2.9 Plataforma J2EE

2.9.1 Definición de J2EE

El concepto J2EE, Java 2 Enterprise Edition es la arquitectura creada por Sun para el

desarrollo de todo tipo de aplicaciones para empresas y usuarios en general facilitando

las herramientas necesarias para la programación en el lenguaje Java, las cuales facilitan

el manejo de los conceptos necesarios para el desarrollo de aplicaciones más avanzadas

de desarrollo, implementación y administración de software empresarial. Sun lo define

como un estándar para el desarrollo de aplicaciones empresariales multicapa,

simplificando las aplicaciones empresariales basándolas en componentes modulares y

estandarizados, proveyendo un completo conjunto de servicios a estos componentes, y

manejando muchas de las funciones de la aplicación de forma automática, sin necesidad

de una programación compleja.

2.9.2 Arquitectura J2EE.

J2EE contiene un completo conjunto de APIs, algunas de las cuales están insertas dentro

de la arquitectura J2SE que se agregan a la arquitectura. Éstas permiten la ejecución

entre las distintas capas.

Figura 11 Arquitectura J2EE (modelo de ejecución en capas)

El modelo de ejecución en capas de J2EE presenta distintas áreas de containers los

cuales contienen API's de funcionamiento, éstas son: Web Containers los cuales

almacenan los Servlet y páginas JSP que corren del lado del servidor y EJB Containers

que manejan la ejecución de lo Beans de aplicaciones J2EE que también corren del lado

del servidor. Por su parte el Applicattion Client Container maneja la ejecución de todos los

componentes de servidor y a su vez el Applet Container la ejecución de dichos applets en

el cliente [07].

2.9.3 Características de J2EE.

La tecnología Java 2 Enterprise Edition (J2EE) proporciona una completa y potente

plataforma orientada al desarrollo de aplicaciones corporativas, distribuidas y a los

servicios Web. De acuerdo al apartado anterior este tipo de aplicaciones suelen tener una

arquitectura en capas: una capa de cliente o de presentación que proporciona el interfaz

de usuario, una o más capas intermedias que proporcionan la lógica de negocio de la

aplicación y una capa final con los sistemas de información que mantienen aplicaciones y

bases de datos corporativas [07].

Entre las características de este tipo de aplicaciones se encuentran las siguientes:

Posibilidad de altas productividades en el desarrollo de las distintas tecnologías

J2EE para la integración de aplicaciones corporativas e integración de sistemas

existentes.

Mayor Escalabilidad al describir las características básicas de transacciones y

desarrollando distintos tipos de componentes de aplicación J2EE con modelos

flexibles de seguridad.

Libertad de elección de plataformas de desarrollo y producción, lo que define los

aspectos necesarios que puedan solucionar una determinada problemática.

El desarrollo de aplicaciones Web utilizando conceptos de la arquitectura J2EE

que permiten la construcción de este tipo de aplicaciones.

La utilización de herramientas libres que agilizan el desarrollo de software con

J2EE y que permiten el funcionamiento en los distintos módulos de ejecución [07].

2.9.3.1 Paquetes de aplicaciones

Son encapsulaciones de aplicaciones J2EE con distinta orientación, definidas en tipos de

extensiones de archivos.

JAR (Java archive): es un formato de archivo independiente de la plataforma que

permite que varios archivos puedan ser encapsulados dentro de uno, permitiendo

que éste pueda ser una aplicación completa de fácil movilidad y ejecución.

Figura 12 Estructura archivo JAR.

WAR (Web Application archive): este componente es un archivo que contiene un

archivo JAR que posee uno o más módulos WEB. Pudiendo ser desde un simple

sistema JSP a un servicio Web.

Figura 13. Estructura archivo WAR.

EAR (Enterprise Archive file): un archivo EAR es un archivo JAR que contiene

una aplicación J2EE. Utilizando archivos EAR es posible unir un número de

diferentes aplicaciones J2EE usando los mismos componentes sin necesidad

de códigos extra solo incluyéndolos dentro de este módulo.

Figura 14. Estructura archivo EAR

RAR (Resource Adapter Archive): Un archivo RAR es un archivo JAR que

contiene un adaptador de recursos que puede ser desplegado en un servidor

J2EE. Es bastante similar a un archivo EAR e incluso un RAR puede estar

contenido dentro de éste [07].

Figura 15. Estructura archivo RAR

2.9.3.2 Lenguajes soportado por J2EE

2.9.3.2.1 Java

Java es un lenguaje de programación orientado a objetos desarrollado por Sun

Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su

sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas

de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de

punteros o memoria.

Las aplicaciones Java están típicamente compiladas en un bytecode. En tiempo de

ejecución, el bytecode es normalmente interpretado o compilado a código nativo mediante

la maquina virtual de Java [07]. Para profundizar más sobre la JVM Ver ANEXO II[PORTABILIDAD EN J2EE Y .NET].

CAPITULO III

SELECCION DE LOS CRITERIOS Y HERRAMIENTAS PARA REALIZAR LACOMPARACION

3.1 Aspectos relacionados entre J2EE y .NET

Para escoger algunos criterios a tener en cuenta para realizar el análisis comparativo

entre las dos plataformas, es necesario estudiar y analizar los aspectos en que se

relacionan, de acuerdo al grado de relevancia que posea. En la siguiente tabla se ilustran

algunos aspectos importantes que tienen en común las dos plataformas, aunque se han

escogido los que afectan o se involucran al momento de realizar un servicio Web.

AspectosRelacionados

J2EE .NET

Proveedores ovendedores

Sun, IBM, +30 Microsoft

IDEs o herramientaspara desarrollarServicios Web

NetBeans, Eclipse, JBuilder,otros

Visual Studio .NET, Mono

Lenguaje Java C#, Basic .NET, C++, Java,otros

Lenguaje Intermedio BYTECODE MSIL (conocido como CIL oIL)

Interpretadores Interpretador (JRE) JVM Interpretador CLRCompiladores

dinámicos, motoresde Ejecución

JIT JIT

Estándares SOAP 1.1, SOAP1.2 , WSDL,XML, UDDI

SOAP 1.1, SOAP1.2, WSDL,XML, UDDI

Servidores de BD Java DB, MySQL, Oracle,Postgres, otros

SqlServer, Oracle, MySQL,otros

Acceso a datos JDBC, SQL/J ADO.NETServidores deAplicaciones

GlassFish (sun applicationserver), JBoss, SAP

NetWeaver, JEUS, Geronimo,JOnAS, IBM WebSphere

Application Server, WebLogicde BEA Systems, otros

IIS (Internet InformationServices), Application Center,

BizTalk Server, CommerceServer, Content Management

Server, Apache 2(modomono), XSP, otros

Interoperabilidad METRO (WSIT), Otros WCF (WSE)Tabla 2. Aspectos Relacionados Entre J2EE y .NET

3.2 Criterios seleccionados para realizar la comparación

Seguridad a nivel de mensajes.

Portabilidad.

IDE de J2EE frente al IDE de .NET.

Interoperabilidad.

Desempeño.

3.3 Justificación de los criterios seleccionados.

A continuación se presenta la justificación, y el por qué de cada aspecto seleccionado

para realizar la comparación entre las dos plataformas para el desarrollo de WS.

3.3.1 Seguridad a nivel de mensaje.

En el momento de tomar decisiones de negocio sobre que tecnologías implementar y de

seleccionar la plataforma de desarrollo de las mismas, es fundamental considerar las

amenazas en la seguridad de la información, ya que, garantizar la seguridad conforma un

objetivo fundamental en la actualidad para implementar los WS [11].

El hecho de que se haya tomado la seguridad en el desarrollo de los servicios Web como

criterio de comparación, es porque para los sistemas distribuidos la seguridad constituye

uno de los principales desafíos.

3.3.2 Portabilidad

La portabilidad de un programa según [05] es la facilidad para ser ejecutados en distintos

entornos lógicos o físicos; sean sistemas operativos o hardware, obteniéndose a si una

independencia de la maquina o sistema computo en la cual se va a ejecutar el programa.

Al considerarse que un software o aplicación es portable se presume que el sistema

puede migrarse a otra plataforma a un costo razonable.

Se ha tomado la Portabilidad como un criterio de comparación, ya que, es muy probable

requerir desplegar WS en sistemas operativos diferentes, de donde originalmente fueron

implementados.

3.3.3 IDE de J2EE frente al IDE de .NET

Uno de los factores más importante al momento de desarrollar una aplicación

necesariamente no tiene que ser WS, es la herramienta que exista y que permita a los

programadores o desarrolladores la forma de realizar, o llevar a cabo la lógica de negocio.

Estas herramientas comúnmente se conocen como IDE, y es importante el uso fácil, que

brinden ventajas, sea más rápido, que sea más transparente, intuitivo, entre otras cosas a

los programadores que quieran crear Servicios Web. Dedicándose así, únicamente en

desarrollar los métodos de los WS y dejando que las herramientas se encarguen de las

demás cosas o aspectos de bajo nivel como: sincronización, recursos compartidos, etc.

3.3.4 Interoperabilidad

Una de las mayores ventajas al momento de utilizar WS es que aportan interoperabilidad

entre aplicaciones de software, independientemente de sus propiedades o de las

plataformas sobre las que se instalen.

Dentro de la arquitectura SOA, la interoperabilidad es tal vez el principio más importante.

Los WS como método de implementación de esta arquitectura deben ofrecer importantes

beneficios de interoperabilidad, y permitir la ejecución de Servicios Web distribuidos en

múltiples plataformas de software y arquitecturas de hardware [05], [12].

Se ha tomado este criterio de análisis porque es en la interoperabilidad, donde se puede

encontrar el mayor beneficio de los WS, al interconectar sistemas distribuidos

implementados en diversas plataformas.

3.3.5 Desempeño

A menudo se convierte en un problema cuando el número de usuarios en un sistema se

incrementan más allá de lo que se había previsto. Adicionalmente, los usuarios pueden

cambiar su patrón de uso, por ejemplo, utilizar algunos servicios con más frecuencia que

antes. Los cambios en el volumen de trabajo pueden tener consecuencias imprevistas en

el rendimiento. Incluso los cambios en la definición de trabajo puede conducir a una

mayor carga de software en sub-componentes. Esto puede dar lugar a efectos de gestión

de colas para los recursos que a su vez dependen de otros softwares y sub-componentes.

El Desempeño es el rendimiento (R) en términos de tiempo de respuesta por cada

usuario de un sistema (S), sin una determinada carga de trabajo (T). (R) es una

respuesta de (S) a un estímulo de (T) [13], y puede ilustrarse con la representación

funcional:

R(S, T)

Se ha tomado el desempeño como criterio fundamental para el análisis comparativo entre

J2EE y .NET, ya que, uno de los objetivos principales a la hora de implementar un

sistema de información o aplicación con cualquier plataforma, y utilizando cualquier

tecnología es el desempeño que presentará de forma inmediata a la implementación, y en

la perspectiva de crecimiento de la empresa como tal.

3.4 Herramientas seleccionadas para realizar la comparación y el prototipo

IDEs (NetBeans 6.5 para J2EE, Visual Studio 2008 para .NET).

Servidores (Sun Application Server 9,2 de J2EE en su versión libre (GlassFish), IIS

de .NET).

Especificaciones y standards (JEE 5, Framework 3.5), (Soap1.2).

Lenguajes de programación (Java para J2EE, Visual Basic para .NET).

Accesos a datos (Java DB para J2EE, Microsoft Access para .NET).

Pruebas de desempeño (AdventNet QEngine para ambas plataformas.).

3.5 Justificación de las herramientas seleccionadas

3.5.1 IDE

Un entorno de desarrollo integrado o en inglés Integrated Development Environment

('IDE'), es un programa compuesto por un conjunto de herramientas para un programador.

Un IDE es un entorno de programación que ha sido empaquetado como un programa de

aplicación, consiste en un editor de código, un compilador, un depurador y un constructor

de interfaz gráfica GUI. Los IDEs pueden ser aplicaciones por si solas o pueden ser parte

de aplicaciones existentes. Es posible que un mismo IDE pueda funcionar con varios

lenguajes de programación [05].

3.5.1.1 NetBeans

NetBeans IDE es una herramienta para que los programadores puedan escribir, compilar,

depurar y ejecutar programas. Está escrito en Java pero puede servir para cualquier otro

lenguaje de programación. Existe además un número importante de módulos para

extender el NetBeans IDE. NetBeans IDE es un producto libre y gratuito sin restricciones

de uso.

La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de un

conjunto de componentes de software llamados módulos. Un módulo es un archivo Java

que contiene clases de java escritas para interactuar con las APIs de NetBeans y un

archivo especial (manifest file), que lo identifica como módulo. Las aplicaciones

construidas a partir de módulos pueden ser extendidas agregándole nuevos módulos.

Debido a que los módulos pueden ser desarrollados independientemente, las aplicaciones

basadas en la plataforma NetBeans pueden ser extendidas fácilmente por otros

desarrolladores de software.

NetBeans es un proyecto de código abierto de gran éxito con una gran base de usuarios,

una comunidad en constante crecimiento, y con cerca de 100 socios en todo el mundo.

Sun MicroSystems fundó el proyecto de código abierto NetBeans en junio 2000 y continúa

siendo el patrocinador principal de los proyectos [05].

Para desarrollar Servicios Web J2EE o JEE5 existen diversos IDE de desarrollo, algunos

de estos son de uso libre y otro de uso propietario, este último se debe comprar y adquirir

una licencia de uso. Se escoge NetBeans para realizar tanto la comparación como el

prototipo de Servicio Web, ya que, es una herramienta de uso libre, robusta, y que

incorpora lo necesario para el perfecto desarrollo y consumo de los Servicios Web. A

demás la versión 6.5 de NetBeans es la más reciente el cual tiene nuevas característica y

mejoras de la versión antecesora NetBeans 6.1. Con esta IDE es posible escribir

aplicaciones J2EE 1.3, 1.4, JEE5 y en el desarrollo de servicios Web permite escoger con

que versión de SOAP trabajar (1.1, 1.2).

Figura 16. NetBeans IDE 6.5

3.5.1.2 Visual Studio

Microsoft Visual Studio es un entorno de desarrollo integrado (IDE, por sus siglas en

inglés) para sistemas Windows. Soporta varios lenguajes de programación tales como

Visual C++, Visual C#, Visual J#, ASP.NET y Visual Basic .NET, aunque actualmente se

han desarrollado las extensiones necesarias para muchos otros.

Visual Studio permite a los desarrolladores crear aplicaciones, sitios web, así como

servicios web en cualquier entorno que soporte la plataforma.

Antes para crear aplicación .NET era únicamente posible desde la IDE visual Studio que

se ejecuta en el sistema operativo Windows. No obstante con el nuevo proyecto mono es

posible crear servicios Web desde sistemas operativo como Linux, aunque el proyecto

aun no está terminado se ha optado por escoger el visual Studio, el cual posee las

herramientas necesarias para desarrollar los WS, y es posible descargar una versión

preview del visual Studio 2008 en español, que es actualmente una de las últimas

versiones de este IDE. Además permite escoger en que Framework trabajar, las opciones

que presenta son: 2.0, 3.0, 3.5, en el desarrollo de servicios Web genera SOAP 1.1 y 1.2

[05]

Figura 17. Visual Studio .NET 2008 Preview

3.5.2 Servidores de aplicación

Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación

a las computadoras cliente, o a otros proveedores de aplicaciones o servicios. Un servidor

de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de

lógica de negocio y de acceso a los datos de la aplicación. El principal beneficio de la

implementación de la tecnología de servidores de aplicación, es la disminución de la

complejidad en el desarrollo de aplicaciones [05].

3.5.2.1 Sun Application Server (GlassFish)

Sun Java System Application Sever, o SJSAS es un servidor de aplicaciones de la

plataforma Java producido por Sun Microsystems. El servidor está basado en la

plataforma Java EE y es el núcleo del sistema Java Enterprise, a manera de contenedor

de EJB o de proveedor de Web Service. Tiene soporte integrado para interfaces de

desarrollo tales como Sun Java Studio Enterprise, Sun Java Studio Creator, NetBeans y

otros.

A partir de la versión 9, SJSAS Plataform Edition se encuentra siendo desarrollada bajo el

proyecto de código libre GlassFish y bajo las licencias de CDDL y GPL. Este proyecto

incluye código de otras compañías tales como Oracle y bases para el JEE5 [05].

Existen varias razones por las cuales se opto por GlassFish. NetBeans 6.5 trae incluido el

GlassFish (Sun Application Server 9.2) el cual es libre para desarrollar servicios Web. Uno

de los objetivo de GlassFish es que ha sido diseñado para competir con Weblogic y

Websphere y hasta ahora lleva 3 versiones, es robusto escalable y fue el primer servidor

de aplicaciones certificado para Java EE 5, aunque soporta J2EE.

3.5.2. IIS (Internet Information Services)

Internet Information Server, IIS, es una serie de servicios para los computadores que

funcionan con Windows. Originalmente era parte del Option Pack para Windows NT.

Luego fue integrado en otros sistemas operativos de Microsoft destinados a ofrecer

servicios, como Windows 2000 o Windows Server 2003. Windows XP Profesional,

Windows Vista incluye una versión limitada de IIS. Los servicios que ofrece son: FTP,

SMTP, NNTP y HTTP/HTTPS.

Este servicio convierte a un computador en un servidor de Internet o Intranet, es decir,

que en las computadoras que tienen este servicio instalado se pueden publicar páginas

web tanto local como remotamente (servidor web).

El servidor web se basa en varios módulos que le dan capacidad para procesar distintos

tipos de páginas, por ejemplo Microsoft incluye los de Active Server Pages (ASP) y

ASP.NET. También pueden ser incluidos los de otros fabricantes, como PHP o Perl [05].

Se selecciono el IIS, ya que es el servidor insignia de Microsoft, el cual soporta asp, aspx,

servicios Web. A demás viene con el sistema operativo Windows XP SP 2, que es el

sistema operativo del sistema cómputo en el cual, se realizará tanto la comparación como

el prototipo de servicios Web para las plataformas J2EE y .NET. El IIS brinda facilidad a la

hora de desplegar servicios Web y también se encuentra la documentación para varios

idioma.

3.5.3 Especificaciones y estándares

3.5.3.1 JEE5 y Framework 3.5

JEE 5 Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2

Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de

programación Java con arquitectura de N niveles distribuida, basándose ampliamente en

componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La

plataforma Java EE está definida por una especificación. Similar a otras especificaciones

del Java Community Process, Java EE es también considerada informalmente como un

estándar, debido a que los suministradores deben cumplir ciertos requisitos de

conformidad para declarar que sus productos son conformes a Java EE [05].

Framework 3.5 un FrameWork es una estructura de soporte definida, en la cual otro

proyecto de software puede ser organizado y desarrollado. Típicamente, un FrameWork

puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros

software para ayudar a desarrollar, y unir los diferentes componentes de un proyecto [05].

Las decisiones o razones para usar estas especificaciones es que son las versiones más

recientes de ambas plataformas y el cual brindara un mayor soporte en lo que se

pretenden estudiar.

3.5.4 Lenguajes de programación

3.5.4.1 Java

En la plataforma J2EE se ha escogido el lenguaje de programación JAVA, porque es el

único lenguaje que ofrece esta plataforma para realizar WS, aunque el NetBeans 6.5 trae

incorporado la capacidad de realizar proyecto: php, c, c++, Ruby, entre otros. Aunque

ninguno brinda soporte para realizar WS.

3.5.4.2 Visual Basic .Net

En la plataforma .NET se opto por utilizar el lenguaje de programación VISUAL BASIC

.NET, ya que, la comparación e implementación de los servicios Web en .NET, se

realizará con una versión preview o de muestra, la cual solo posee soporte para el

desarrollo de WS con dos lenguajes de programación VISUAL BASIC y C#. De los dos

lenguajes se encuentra suficiente documentación en diferentes idiomas, lo cual hace que

la decisión de VB .NET sobre C# no sea de gran relevancia para el desarrollo del

prototipo del WS en .NET.

3.5.5 Servidores y manejadores de datos

3.5.5.1 Java DB

El Java DB de Sun es la distribución de código abierto Apache Derby cien por ciento

tecnología Java para base de datos, el cual viene integrado en la versión de NetBeans

6.5.

3.5.5.2 Microsoft Access

Microsoft Access es un programa o sistema de gestión de base de datos relacional,

creado y modificado por Microsoft para uso personal de pequeñas organizaciones. Es

posible descargar una versión preview de la suite Microsoft Office, que venga con

Microsoft Access en [05].

La base de datos que se realizará para llevar a cabo el prototipo propuesto de WS .NET,

no requiere una excesiva potencia, la cual hace ideal el uso de este sistema de gestión

de BD, además Access posee facilidad para integrarse de forma perfecta con el resto de

aplicación de Microsoft, en este caso Visual Studio .NET.

3.5.5 AdventNet QEngine

AdventNet QEngine es una herramienta automática de pruebas para hacer Test de

funcionalidad, rendimiento, carga, tráfico de datos, servicios web, control del rendimiento

de servidores y pruebas de regresión. QEngine funciona tanto en plataformas Windows

como en Linux. Permite grabar y reproducir los exploradores Microsoft Internet Explorer,

Firefox y Mozilla.

AdventNet QEngine está realizado en lenguaje Java y su distribución no es libre, pero es

posible descargar una versión preview que es limitada en sus funcionalidades, desde

diferentes sitios Web. Desde el sitio oficial en [14], se puede encontrar las últimas

versiones de este software.

AdventNet Es una empresa de Software que tiene su sede principal en Estados unidos,

otras en: México, Inglaterra, India, China, Japón y otras. Ofrecen diferentes productos

empresariales; productos para base de datos, productos para testear la Web, entre otros.

Lleva varios años en el mercado de software y tiene una gran reputación a nivel mundial.

Ya que existen muchas investigaciones en las cuales se utilizan algunas herramientas de

esta empresa como:

Ingeniería de Tráfico en Redes MPLS. Por Adrián Delfino, Sebastián Rivero,

Marcelo [32]. A Choice Between Interoperability And Migration. Por CHAITANYA KURADA

[33]. Performance Comparison Of Interoperability Between J2EE And .NET Web

Services. Por Maneesh Rampally [21].

En el momento de buscar herramientas para analizar el desempeño, se encontraron

diversos software para realizar test de carga a sitios Web como son: webstress,

PageSpeedTester wapt, imacros-setup, entre otros. La mayoría de los programas son de

uso propietario, pero, por la complejidad de los datos ofrecido al momento de terminar

con el test, y además de la poca información o documentación se opto por la

herramientas AdventNet QEngine.

CAPITULO IV

ANÁLISIS COMPARATIVO ENTRE J2EE Y .NET

4.1 Seguridad a nivel de mensajes

Para tener una mejor compresión de los términos y conceptos que se nombren a

continuación, es necesario Ver ANEXO I [SEGURIDAD A NIVEL DE MENSAJE EN LOS

SERVICIOS WEB], y ver el apartado 4.4.2 Interoperabilidad con METRO y WCF.

4.1.1 Algunas especificaciones soportada por J2EE

4.1.1.1 La plataforma J2EE (JEE 5) de Sun Microsystems

La plataforma J2EE comúnmente conocida en su última versión como JEE 5, a través de

sus servidores de aplicaciones, soporta varias especificaciones de seguridad, entre estas

especificaciones se encuentra WS-Security, más sin embargo esto depende del servidor

de aplicación que se utilice. [15].

4.1.1.2 GlassFish

A partir de la versión 2.0 soporta: SOAP 1.1/2.0, WSDL 1.1, trae soporte para METRO

que incluye WS-Security [15]. Para ver más sobre METRO ir al apartado 4.4.2.

4.1.1.3 NetBeans

Desde la versión 5.5 soporta WS-Security, ya sea directamente a través de la herramienta

o utilizando un Plugin como WSIT, que se puede descargar o actualizando el IDE. Desde

la versión 6.1 de NetBeans soporta la implementación de servicios web con el Stack de

Metro [15].

4.1.1.4 WSIT

Web Services Interoperability Technology (WSIT) es una implementación de tecnologías

abiertas de Servicios Web, que trata aspectos clave de la interoperabilidad como:

mensajería confiable, manejo de transacciones y seguridad a nivel de mensajes.

Figura 18. Conjunto de estándares de WSIT

WSIT en el área de seguridad implementa un conjunto de estándares de seguridad

publicados por el consorcio OASIS (Organization for the Advancement of Structured

Information Standards). Los estándares de seguridad incluidos en WSIT son:

WS-Security.

WS-SecurityPolicy.

WS-SecureConversation.

WS-Trust.

La implementación de estos estándares le permite a WSIT asegurar comunicaciones

entre servicios web [16].

4.1.2 Algunas especificaciones soportadas por .NET

4.1.2.1 Visual Studio .NET

Desde sus versión 2003 utiliza plugin o complementos que se pueden descargar e instalar

para agregar mejora a los WS construido en .NET. Uno de estos complementos son Web

Services Enhancements (WSE), Development Kit (WSDK), WCF (viene integrado con

Visual Studio 2008) [15].

4.1.2.1.1 Web Services Enhancements

Web Services Enhancements es un complemento de Visual Studio .NET, que

permite satisfacer los requisitos empresariales, dicho de otra forma es la

implementación de Microsoft para Servicios Web Avanzados. Desde la versión

WSE 2.0 incluye el estándar WS-Security, el cual permite a las organizaciones

exponer servicios de forma segura y que puedan ser consumidos en ambientes

heterogéneos. Después de la versión WSE 3.0 salió WCF.

WSE 1.0 y 2.0 se integran con VS.2003 (1.x)

WSE 3.0 se integra con VS.2005 (2.0)

4.1.2.1.2 Windows Communication Foundation (WCF)

Para ver más sobre WCF ir al apartado 4.4.2. WCF incluye un número significativo

de tecnologías relacionadas con los WS entre las que destacan SOAP, WSDL,

WS-Policy, en el área de arranque y configuración. WS-Addressing, WS-

AtomicTransaction, en el área de transaccionabilidad. WS-Coordination, WS-

ReliableMessaging en el área de fiabilidad. En el área de seguridad, implementa

un conjunto de estándares de seguridad publicados por el consorcio OASIS, como

son:

WS-Security.

WS-SecurityPolicy.

WS-SecureConversation.

WS-Trust.

Es posible crear aplicaciones basadas en WCF utilizando Microsoft Visual Studio

2005 en su entorno de desarrollo integrado. Microsoft ha liberado un paquete de

extensiones y un Kit de Desarrollo que puede ser utilizado con esta tecnología, y

otras que se incluyen en la Plataforma .NET v3.x [15].

4.1.3 Autentificación de usuarios usando UserNameTokens en J2EE y .NET deacuerdo a la especificación de WS-Security

Para aplicar UserName Token (Ver Anexo I, III, IV) en el caso de la plataforma J2EE es

posible mediante la construcción programática de la cabecera Soap, o en algunos casos

depende del IDE en que se esté trabajando, utilizando así una ayuda Wizard de un SDK

de WS-Security de J2EE que sea soportado por la herramienta de desarrollo como WSIT,

o en otros la herramienta como tal trae integrada la característica para aplicar la

especificación de WS-Security.

En la plataforma .NET es posible a través del complemento WSE o utilizando WCF a

través de Visual Studio.

4.1.3.1 Aplicación UserName Tokens en .NET utilizando WSE

Para tener una mejor compresión de los siguientes ejemplos es necesario consultar el

Apartado 4.3, Anexos III y Anexo IV.

4.1.3.1.1 Servicio Web

using System;using System.Collections;using System.ComponentModel;using System.Diagnostics;using System.Web;using System.Web.Services;using System.Security.Permissions;using Microsoft.Web.Services;using Microsoft.Web.Services.Security;using Microsoft.Web.Services.Security.Tokens;

namespace samples.webbish6{

[ WebService(Description="Hello World",Namespace="http://samples.webbish6.com/")]

public class HelloWorld : System.Web.Services.WebService{

public HelloWorld(){//Esta llamada es requerida por el ASP.NET Web Services

DiseñadorInitializeComponent();

}

#region Component Designer generated code

http://samples.webbish6.com/

//Requerido por el Diseñador del servicios webprivate IContainer components = null;

/// <summary>/// Método requerido para el Diseñador de apoyo - no

modificar///el contenido de este método con el editor de código.

/// </summary>private void InitializeComponent(){}

/// <summary>/// Limpiar los recursos que se utilizan

/// </summary>protected override void Dispose( bool disposing ){

if(disposing && components != null){

components.Dispose();}base.Dispose(disposing);

}

#endregion

// Este es el "Hola Mundo" método que Visual Studio trae pordefecto

[WebMethod]public string GetHelloWorld(){// Obetenga el contexto Soap para la respuesta

SoapContext myResponse = ResponseSoapContext.Current;

// Crear el mismo Username token para el retorno del mensajeUsernameToken myToken = new UsernameToken("anyname",

"Secure$Password",PasswordOption.SendNone);

// Añadir el Username token para el SoapContextmyResponse.Security.Tokens.Add(myToken);

// Firme el mensaje con el TokenmyResponse.Security.Elements.Add(new

Signature(myToken));

// Retorno del Hola Mundoreturn "Hello World";

}}

// Esta clase implementa el nombre de usuario personalizado tokenhandler (I utilizar el mismo código

//en el cliente para manejar el mensaje devuelto con un nombre deusuario token

/** Restringir el acceso al manjador de token solamente para asambleas

que se han* concedido derechos suficientes para ejecutar código no

administrado, que* incluye WSE - para garantizar el propio nombre de usuario, usted

debe utilizar SSL*/

[SecurityPermission(SecurityAction.Demand,Flags= SecurityPermissionFlag.UnmanagedCode)]

public class CustomUsernameTokenManager : UsernameTokenManager{

/*Para implementar un administrador de username token, debeanular

* el metodo de AuthenticateToken para que vuelva la contraseña* que se corresponde con el nombre de usuario, aprobada en el

token*/

protected override string AuthenticateToken(UsernameTokenmyNameToken)

{// Asegurando que el mensaje SOAP enviado// no pase un null en el UsernameToken

if (myNameToken == null) throw newArgumentNullException();

// Para retornarstring myPwd;

/*Aquí se suele llamar a un método que recibe la copia local* de la contraseña suministrada por el nombre de usuario* desde una ubicación segura myPWD cadena =

GetSecurelyStoredPassword (myNameToken.Username);* Y SE RETORNA myPWD;*/

/*Para este ejemplo se utilizara un password facil pero en la* precatica real se debe colocar un clave dificil*/

string hardCodedPwd = "Secure$Password";

myPwd = hardCodedPwd;

return myPwd;}

}}

4.1.3.1.2 Cliente consumiendo un WS con seguridad a nivel de mensaje

(Aplicación de Consola)

using System;using Microsoft.Web.Services;using Microsoft.Web.Services.Security;using Microsoft.Web.Services.Security.Tokens;using HelloWorldClient.HelloWorldWebService;

namespace HelloWorldClient{

class HWClient{

[STAThread]static void Main(string[] args){

string myName="";string myPwd="";

try{

if (args.Length<2){throw new ApplicationException("Por favor agregue

un nombre de usuario y password");}myName = args[0];

// Esto necesita ser una contraseña segura// En la Practica, nunca utilice una contraseña de

seguridad baja!myPwd = args[1];

Console.WriteLine("Nombre de Usuario: " + myName +"\nContraseña: *******" +myPwd+

"\n\nLlamando al Servicio de HelloWorld con estascredenciales\n\n");

}catch(Exception ex){

Console.WriteLine(ex.ToString());}

// Instanciando la Clase HelloWorldWse.HelloWorldWse myService = new HelloWorldWse();

// Obteniendo el Objeto SoapContext para el mensjaeSaliente.

SoapContext myContext = myService.RequestSoapContext;

// Una nueva instancia UsernameTokenUsernameToken myToken = new UsernameToken(myName,

myPwd, PasswordOption.SendNone);

// Adicionando el token para el contexto soap o cuerposoap.

myContext.Security.Tokens.Add(myToken);

//Generar una firma utilizando el UserName Token,//y agregar la firma al SoapContext.

myContext.Security.Elements.Add(newSignature(myToken));

// Creando Una variable para el retorno del WS.string response = "";

try{

// LLamando el metodo del Web Servicesresponse = myService.GetHelloWorld();

}catch(Exception ex){

Console.WriteLine(ex.ToString());}Console.WriteLine(response);

}}

}

[17].

Para ver sobre como implementar un servicio web con WCF y sus principales

características consultar [31].

4.1.3.2 Aplicación UserName Tokens en J2EE con NetBeans

Se crea un nuevo proyecto en NetBeans tipo aplicación web para realizar un Web

Services.

Se crea el WS

Se crea un Cliente que consuma Dicho WS

Se hace click en Runtime como se muestra a continuación.

Figura 19. Pestañas de ventanas en NetBeans

Se hace click en la opción Sun Java System Access Managers, luego en Default

Instance, luego en profiles y luego se da click derecho escogiendo Edit en la

opción de UserNameToken.

Figura 20. UserNameToken

Aparece la siguiente ventana la cual trae un nombre de usuario y contraseña por

defecto como se observa en la siguiente grafica

Figura 21. Ventana de Editor UserNameToken

Se hace Click en Add y aparece la siguiente ventana, el cual se coloca un nombre

de usuario y contraseña, luego se da click en ok, mostrando la ventana anterior

con el o los usuarios agregado y se da click en ok

Figura 22. Agregando Tokens en NetBeans

Luego se hace click en la pestaña de proyecto, en la aplicación que contiene el

WS, se busca el Web Services y se hace click derecho y se escoge la opción Edit

Web Service Attributes

Figura 23. Atributos de un WS

Se habilita la Seguridad a nivel de mensaje y se escoge la opción

UserNameToken, y luego se hace click en OK.

Figura 24. Editor de Atributos

Luego se refresca el Wsdl en el cliente, y se busca el Web Service References se

hace click derecho se escoge Edit Web Service Attributes

Figura 25. Atributos a una Referencia WS

Se habilita el nivel de seguridad se escoge UserNameToken, se escribe el nombre

de usuario y la contraseña, que coincida , con la establecida en profiles, se da click

en OK

Figura 26. Editor de Atributos Cliente

4.1.4 Análisis de seguridad a nivel de mensaje

La seguridad ha sido uno de los aspectos más desarrollados en los últimos tiempos en el

área de servicios web. Sun y Microsoft se agruparon para trabajar en este tema,

buscando con ello que además de que la seguridad sea interoperable, sea estándar en

cualquiera de las dos plataformas tecnológicas. Lo anterior evidencia el hecho de que en

este aspecto la seguridad ofrecida tanto por J2EE como por .NET abarca el mismo

conjunto de especificaciones. Por ejemplo, ambas plataformas soportan las

especificaciones de seguridad a nivel de mensaje como WS-Security, esto quiere decir

que si en J2EE se implementa la encriptación del mensaje Soap utilizando la

especificación de WS-Security y un intruso logra desencriptar el mensaje Soap utilizando

un ataque, entonces también es posible violar la seguridad en .NET. Por consiguiente si

una especificación de seguridad es violada, ambas plataformas se ven afectadas, ya que,

ellas se apoyan en las mismas especificaciones.

Consecuentemente cada plataforma a través de las herramientas IDEs para desarrollar

WS presenta unas series de API y asistentes para la implementación de la seguridad a

nivel de mensaje, donde es posible utilizar estándares, tecnologías entre otras como:

firmas digitales, XML encriptados, llave pública, llaves privadas, involucrar entidades

certificadoras y otros. Por lo general estas implementaciones son transparentes al

desarrollador en el caso que se utilice un IDE, esto quiere decir que la forma de cómo se

implementa (en un nivel más bajo) las especificaciones como algoritmos de encriptación y

las demás cosas no hacen parte de la lógica del SW como tal.

Ambas plataformas muestra cierto grado simplicidad para implementar algunas o las

principales especificaciones de seguridad, eliminando en ese aspecto la ventaja de una

plataforma frente a la otra. No obstante en la aplicación de UserNameTokens que se

estudio anteriormente, es posible destacar hasta cierto nivel la facilidad que presenta

J2EE frente a .NET en la implementación de esta especificación de seguridad, utilizando

NetBeans, sin embargo es necesario tener en cuenta que en cada IDE de desarrollo para

J2EE que soporte WS-Security es diferente su implementación en lo concerniente a la

facilidad que pueda brindar a los desarrolladores.

4.2 Portabilidad.

Hoy en día se convierte en un aspecto a tener en cuenta, ya que la potencia de un

programa no sólo reside en su perfección o velocidad de procesamiento de datos, sino

también en la portabilidad, ya que un programa portable a varias plataformas, tendrá más

usuarios o compradores, que un programa que sólo se pueda usar sólo en un cierto

entorno.

Aunque es cierto que la portabilidad aun no es posible en un cien por ciento, a través del

estudio realizado de la JVM de J2EE y el CLR de .NET (Ver ANEXO II [ESTUDIO DE LA

PORTABILIDAD DE J2EE Y .NET]), es posible deducir el siguiente análisis:

4.2.1 Análisis de la Portabilidad en J2EE

Se consigue una mejor portabilidad con la plataforma J2EE donde existe JVM

para la mayoría de los Sistemas Operativos.

La mayoría de los IDEs o FrameWork para desarrollar servicios web en J2EE (se

pueden descargar en el caso de ser gratuito o comprar en el caso de usar licencia

comercial), se pueden instalar en diversos sistemas operativos, ejemplo de esto es

tener el IDE Eclipse para el sistema operativo Windows realizar un servicio web y

luego llevar ese proyecto y abrirlo en el IDE Eclipse pero en el sistema operativo

Linux y el proyecto de servicio web no presentaría ningún problema.

Por lo general los proyectos de servicios web realizado en estos IDE generan un

(.WAR, EAR, o JAR) que contiene toda la aplicación, que es el equivalente a un

.Class de un programa Java; este archivo se puede transportar a diferentes

sistemas operativos y utilizando algún servidor de aplicación que soporte las

característica con que se creó el servicio web es posible desplegarlo para ser

accedido mediante un cliente.

4.2.2 Análisis de la Portabilidad en .NET

La portabilidad de .NET a través del PE (Ejecutable Portable) es mucho menor a la

obtenida con J2EE, ya que, no existen versiones del CLR para varios Sistemas

Operativos, Microsoft ha sacado versiones del CLR para Windows 95, Windows

98, Windows ME, Windows NT 4.0, Windows 2000, Windows XP, Windows CE y

Vista.

Aunque a través del Proyecto Mono se obtendrán portabilidad hasta cierto punto

con .NET, aun el proyecto no está terminado al cien por ciento y no hay versiones

para cada SO y para cada versión.

Según [18] se afirma que todo lo que se realiza en mono funciona en .NET, pero a

lo contrario no se obtiene la misma compatibilidad.

A través de CLR se consigue que .NET sea una Plataforma de Ejecución

independiente de lenguajes, o comúnmente conocido Multilenguaje, lo que permite

integrar desarrolladores de distintos perfiles. Aunque esto en ocasiones presenta

ciertas ventajas en otras se convierte en una desventaja, ya que, mantener un

proyecto en múltiples lenguajes es costoso. Si una aplicación está realizada en

varios lenguajes se necesitan expertos en cada LP para entenderla y mantenerla,

aumentando los costos. No obstante En la plataforma .NET las librerías o clases

son comunes a los lenguajes, con lo que los desarrolladores no tienen que

aprender una nueva librería cuando cambian de lenguaje, lo cual ayuda mucho a

un desarrollador en el momento de pasar de un lenguaje a otro.

4.3 NetBeans 6.5 frente Visual Studio .NET 2008

A continuación se muestra algunas pruebas básicas en el desarrollo de un Servicio Web,

teniendo en cuenta el tiempo que toma cada operación en realizarse tanto en NetBeans

como en Visual Studio. Adicionalmente se estudia las opciones que brinda cada

Herramienta en relación a: flexibilidad, facilidad, a la hora de construir o implementación

un WS básico

4.3.1 Especificaciones

La prueba se realiza bajo las siguientes especificaciones

Nombre EspecificaciónSistema Operativo Microsoft Windows XP Version 2002

Service Pack 2Procesador Intel Celeron D 2.8

Memoria Ram 1.5 GBTamaño del Archivo de Paginación 2046 MB

Uso De Memoria Caché Del SistemaTabla 3. Especificaciones Del Sistema Cómputo.

4.3.2 Prueba 1

Arranque de NetBeans 6.5 y Visual Studio 2008: Se ha realizado diferentes arranques o

inicios de los dos IDE, para analizar el tiempo que demora en estar lista la aplicación IDE

para su posterior ejecución o uso.

Prueba Nombre Del IDE Tiempo (Segundos)1 NetBeans 33.41 Visual .NET 4.72 NetBeans 28.92 Visual .NET 3.13 NetBeans 27.93 Visual .NET 3.3

Promedio NetBeans 30.066Promedio Visual .NET 3.7

Tabla 4. Tiempo de Arranque de Cada IDE.

4.3.2 Prueba 2

Arranque del Servidor GlassFish de J2EE y el Servidor IIS de .NET.

Prueba Nombre Del Servidor Tiempo (Segundos)1 PLAY GlassFish 46.41 PLAY IIS 9.11 STOP GlassFish 19.31 STOP IIS 4.12 PLAY GlassFish 40.72 PLAY IIS 6.82 STOP GlassFish 16.32 STOP IIS 6.53 PLAY GlassFish 40.93 PLAY IIS 6.23 STOP GlassFish 9.23 STOP IIS 6.3

Promedio PLAY GlassFish 42.666

Promedio STOP GlassFish 14.933Promedio PLAY IIS 7.366Promedio STOP IIS 5.633

Tabla 5. Tiempo de Arranque de Cada Servidor.

Nota: El IDE visual Studio 2008 posee un servidor de desarrollo Asp.NET, el cual brinda al

desarrollar velocidad a la hora de desarrollar cualquier aplicación, en este caso Servicios

Web.

4.3.3 Prueba 3

Se analiza el Uso del procesador a través del administrador de tarea

Uso del Procesador NetBeans: se presentaron diferentes picos entre

99%,93%,91%90% aproximadamente por lapsos de 400 milisegundo

aproximadamente.

Uso del Procesador Al iniciar Visual Studio .NET: Pico más alto 91 %

aproximadamente por 1 Segundo

4.3.4 Prueba 4

Número de instancia que permite cada IDE

Nombre Numero de InstanciaNetBeans 6.5 1

Visual Studio 2008 43Tabla 6. Numero de Instancias.

Visual Studio .NET permite trabajar diferentes proyectos en la misma instancia del Visual

que se ejecute, y también permite crear otras instancias para trabajar los proyectos en

instancias diferentes. A diferencia de NetBeans que solo permite trabajar todos los

proyectos en una sola instancia. Cabe mencionar que para trabajar varios proyectos en

una misma instancia es más intuitivo NetBeans que Visual Studio

4.3.5 Realizando un Servicio Web

4.3.5.1 NetBeans 6.5

Al momento de realizar un servicio Web en NetBeans se escoger alguna de las 2

opciones siguiente del IDE:

Nuevo proyecto, se escoge la categoría java Web, y luego aplicación Web y

luego crear el servicio Web dentro de la aplicación Web.

Nuevo Proyecto, se escoge la categoría Java EE, y luego cualquiera de las

opciones que aparecen (aplicación empresarial, EJB modulo, etc.), y luego dentro

de esta crear el o los servicios Web que se necesiten.

Figura 27. Nuevo Proyecto en NetBeans

Figura 28. Escogiendo categorías de proyectos en NetBeans.

Luego se hace click derecho sobre el proyecto y se escoge la opción servicio Web, se la

asigna un nombre y un paquete para el servicio Web, el servidor de aplicación con el cual

se desea trabajar y luego el tipo de especificación J2EE 1.3, J2EE 1.4, JEE 5

Figura 29. Agregando nuevo WS a una Aplicación Web

4.3.5.2 Visual Studio .NET 2008

Al momento de realizar un servicio Web en Visual brinda 2 opciones nuevo proyecto, o

nuevo sitio Web, luego se debe escoger un Framework o marco de trabajo; visual Studio

2008 permite escoger entre Framework (2.0, 3.0, 3.5), que viene siendo el equivalente de

NetBeans en cuanto J2EE 1.3, J2EE 1.4, JEE 5. Luego se escoge algún lenguaje que

permita realizar un servicio Web (Basic .NET, C#, etc.), por último se selecciona la

plantilla “Aplicación de Servicio Web de ASP.NET”.

Figura 30. Nuevo sitio Web en VS 2008

Figura 31. Nuevo WS en VS 2008

4.3.5.3 Prueba 5

Tiempo que demora en crear un nuevo Servicio Web.

Prueba Nombre Del IDE Tiempo (Segundos)

1 NetBeans 42.5 + 32.31 Visual .NET 15.72 NetBeans 30.1 + 9.72 Visual .NET 5.43 NetBeans 39.8 + 6.73 Visual .NET 5.0

Promedio NetBeans 37.46 + 16.23 = 53.69Promedio Visual .NET 8.7

Tabla 7. Tiempo en crear un WS en cada IDE.

El segundo tiempo que aparece en NetBeans es debido que este no crea servicios Web

“netamente puros”, ya que, es necesario por ejemplo crear una aplicación Web, que

corresponde al primer tiempo y luego a este crearle un nuevo servicio Web que

corresponde al segundo tiempo.

4.3.5.4 Método del Servicio Web en VS .NET.

Al realizar un nuevo proyecto de Servicio Web en Visual Studio .NET 2008, genera un

método de de Servicio Web por defecto. Cuyo nombre es HelloWorld y tiene como retorno

un String por defecto, el cual permite modificarlo: al borrar y escribir código; ya sea el

nombre del método, el retorno del método, la programación del método y la variable de

retorno final. También es posible agregar nuevos métodos al mismo servicio Web al

escribir un nuevo método o al copiar al método y realizándole los cambios respectivos

desde el nombre, retorno, programación. Las librerías que aparecen al principio fueron

generadas de forma automática en el momento de crear un nuevo servicio Web.

Figura 32. Metodo por defecto un WS en Visual Studio.

4.3.5.5 Método del Servicio Web en NetBeans

A diferencia de Visual .NET 2008 NetBeans, no crea ningún método por defecto genera

2 opciones para crear el método:

Escribiendo totalmente el código del método a partir de la siguiente ventana,

utilizando el botón que aparece enmarcado en rojo.

Figura 33. Código por defecto de un WS en NetBeans.

Utilizando el botón que aparece enmarcado en rojo

Figura 34. Adicionar un nuevo método en NetBeans.

Haciendo click en Add operation aparece la siguiente ventana, el cual pide el

nombre de el método, el retorno del método, los parámetros de entrada

Figura 35. Editor de métodos.

Que termina generando el siguiente método en NetBeans equivalente del HelloWorld solo

hay que modificar el retorno por un “HelloWorld” de Visual Studio, y que es posible, tanto

escribir el código de la implementación, como crear otros métodos; realizando los pasos

antes mencionados.

Figura 36. Método de un WS en NetBeans.

Cabe mencionar dos aspectos importantes, ambos poseen auto completa de código, pero

únicamente visual Studio posee auto corrección.

No se destaca las 13 líneas de códigos de Visual Studio frente a las 10 líneas de códigos

NetBeans; ya que estas son generadas automáticamente por cada IDE, lo importante son

las líneas de código de las implementaciones complejas que se pretenda realizar.

4.3.5.6 Prueba 6

Tiempo que demora cada IDE en compilar y subir el Servicio Web en su respectivo

Servidor

Prueba Nombre Del IDE Tiempo (Segundos)1 NetBeans 23.71 Visual .NET 15.72 NetBeans 12.02 Visual .NET 5.83 NetBeans 10.63 Visual .NET 6.0

Promedio NetBeans 15.433Promedio Visual .NET 9.166

Tabla 8. Compilación y despliegue de WS.

4.3.5.7 Testear el Servicio Web y ver el Wsdl desde VS

Cuando se ejecuta o se sube el servicio Web en visual Studio de forma correcta aparece

una página en el browser como la siguiente

Figura 37. WSDL y Testeo de un WS en Visual Studio

Donde se puede testear el servicio haciendo click en el nombre del método “HelloWorld”

y ver el WSDL haciendo click en “descripción de servicio”

4.3.5.8 Testear el Servicio Web y ver el Wsdl desde NetBeans

En NetBeans se puede testear o ver el archivo WSDL haciendo click derecho sobre el

servicio Web del proyecto y escoger la opción de test Web Service

Figura 38. Test Web Service

Apareciendo en el browser lo siguiente

Figura 39. WSDL y Testeo de un WS en NetBeans

Para testear el servicio Web se hace click en el botón que tiene el nombre del método el

cual se le quiere aplicar. Para ver el WSDL se debe hacer click en link “WSDL File”

Es necesario tener en cuenta a la hora de construir servicios Web en NetBeans, que no

se puede crear un servicio Web con el mismo nombre del método de ese mismo Servicio

Web, a diferencia de Visual Studio.

4.3.5.9 Realizando cambios en el método del WS en VS

Para realizar un cambio de nombre del método, tipo de retorno, parámetros de entradas,

del servicio Web en visual Studio se realizan manualmente adicionando y sustrayendo el

código necesario para llevar a cabo los cambios que a si se requieran. No es posible

cambiar el nombre del servicio Web desde el mismo Visual Studio.

4.3.5.10 Realizando cambios en el método del WS en NetBeans

En NetBeans es posible cambiar el nombre del servicio Web al utilizar la herramienta

refactor y escoger la opción apropiado para llevar a cabo el cambio de nombre del WS,

también es posible cambiar el nombre y el tipo de variables a través de los pasos

anteriores. No es posible realizar los anteriores cambios de forma manual. El nombre del

método es posible de cambiarlo de forma manual.

Figura 40. Herramienta para renombrar WS en NetBeans

Figura 41. Herramienta para cambiar métodos del parámetro

4.3.6 Conexión a Bases de datos.

Tanto NetBeans como Visual Studio ofrecen un explorador o ventanas para agregar

servidores de BD. Creación de bases de datos, conexión de datos, ejecución de consultas

de BD.

4.3.6.1 Conexión en NetBeans

Figura 42. Asistente para agregar una nueva conexión en NetBeans

En la anterior figura se observa los diferentes driver de Servidores DB y de tipos de

conexión que trae esta versión de NetBeans. JAVA DB es integrado en esta versión de

NetBeans, se pueden agregar nuevos driver utilizando el siguiente asistente

Figura 43. Asistente para Buscar Driver en NetBeans

Es necesario adherir un archivo JDBC driver y buscarlo en el equipo en donde se realizo

la instalación del servidor BD, el cual es tipo de archivo comprimido (jar, zip).

4.3.6.2 Conexión en VS

Figura 44. Asistente para agregar una nueva conexión en visual Studio

En visual Studio .NET 2008 se escoge el origen de datos y se establece el proveedor de

datos, algunos orígenes de datos solo tienen un solo proveedor como Microsoft Access y

cuyo proveedor es OLE DB.

Un consumidor efectúa solicitudes de datos. Un proveedor responde a esas solicitudes

colocando los datos en formato tabular y devolviéndolos al consumidor. Cualquier llamada

que haga el consumidor debe estar implementada en el proveedor.

Un proveedor es cualquier componente de software que implementa interfaces para

encapsular el acceso a los datos y exponerlos a otros objetos (estos son los

consumidores). Las interfaces se implementan en un proveedor. Proveedor actúa más

como un controlador de base de datos que como servidor.

Una aplicación ASP.NET debe conectar con una base de datos a través de un proveedor

de OLE DB. Éste actúa como un intérprete que permite a la aplicación ASP.NET

comunicarse con una base de datos [19].

4.3.7 Consumiendo un servicio Web en J2EE utilizando NetBeans

Se crea un nuevo proyecto por defecto de este ejemplo una aplicación Web como se

explico en el apartado (4.3.5.1). Se hace click derecho y se escoge la opción Web Service

Client como se observa a continuación:

Figura 45. Agregando una referencia Web en un cliente

4.3.7.1 Copiando la URL del Servicio

Luego se copia la URL del Wsdl en WSDL URL no importa si el servicio es J2EE o .NET

como se indica en la siguiente figura

Figura 46. Asistente de Adición de Referencia Web

Al finalizar el asistente anterior se puede verificar el WS en el cliente como se muestra

Figura 47. Referencia Web Agregada

4.3.7.2 Generando una Clase

Luego existen muchas formas de hacer uso de WS References a continuación se

presenta la forma de hacerlo a través de una clase en java. Se hace click derecho en el

proyecto y se escoge Java Class como se observa a continuación:

Figura 48. Crear Una Nueva Clase

Luego aparece el siguiente Wizard El cual pide el nombre de la clase y el paquete en que

va estar contenida la clase que se creará

Figura 49. Asistente para nueva clase

Al finalizar se genera el siguiente código java:

Figura 50. Clase generada

4.3.7.3 Agregando Métodos a La Clase

A la clase generada se le agregan métodos de acuerdo a las necesidades. Para este

ejemplo se crea un método llamado llamar_MSW como se muestra a continuación

Figura 51. Creando un Método a la Clase

4.3.7.4 Llamando una operación del Servicio Web

Luego se hace click derecho dentro de este método para llamar el WS_Reference como

se muestra en la siguiente figura:

Figura 52. Llamando un método de un WS

Se escoge el método apropiado del WS como se muestra en la siguiente figura:

Figura 53. Selección de la operación

Se genera el siguiente código el cual se puede modificar el retorno y agregar más

funcionalidades si es necesario para ser llamado donde se necesite (función, clase,

página Jsp, etc.):

Figura 54. Código generado

4.3.8 Consumiendo un servicio Web en .NET utilizando Visual Studio

Se crea un nuevo proyecto por defecto de este ejemplo una aplicación Web como se

explico en el apartado (4.3.5.2). Se hace click derecho y se escoge la opción Agregar

Referencia Web como se observa a continuación:

Figura 55. Nueva referencia Web en Visual Studio

Luego aparece el siguiente Wizard y se pega la dirección URL del servicio Web, se le

coloca un nombre a esta referencia en este caso “MiServicio” y por último se le da click en

Agregar Referencia

Figura 56. Asistente de Referencia Web

Aparece la referencia Web en el proyecto como se muestra a continuación:

Figura 57. Referencia Web Agregada

4.3.8.1 Dimensionado una variable tipo Servicio Web en VS

Al ser visual Basic .NET un lenguaje orientado a evento se procede a programar en “Load

Page” haciendo click en el botón diseño y luego hacer doble click en alguna parte de la

página, el cual genera el siguiente código:

Figura 58. Método Page_Load

Luego se dimensiona una variable tipo servicio Web y utilizando la auto completación es

posible manipular los métodos que contenga de acuerdo a lo que se necesite o de

acuerdo a la forma que se vaya a emplear:

Figura 59. Variable Tipo Referencia Web

4.3.9 Análisis de NetBeans Frente Visual Studio

Luego de haber estudiado y comparado los tiempos que demora en realizar algunas

operaciones básicas para construcción de Servicios Web tanto en NetBeans como en

Visual Studio se pueden concluir los siguientes aspectos:

Iniciar Visual Studio requiere un tiempo promedio mucho menor que NetBeans lo

cual genera además de un ahorro en el tiempo para realizar cualquier tipo de

aplicación, también esto implica un consumo mucho menor de los recursos del

sistema computo en el momento de realizar un arranque de Visual Studio frente

NetBeans IDE.

Normalmente cuando se realizan Servicios Web es necesario ejecutar un servidor

de aplicación. En el caso de NetBeans el GlassFish tarda un tiempo largo si se

compara con el servidor IIS que utiliza Visual Studio el cual hay una diferencia

promedio de aproximadamente 35 segundos de acuerdo a los datos arrojados en

la prueba 2.

La prueba 5 que consiste en medir el tiempo promedio que tarda en crearse un

WS en cada IDE, es donde se apreciar una de las mayores ventajas de Visual

Studio Frente NetBeans, esto es debido a que es posible realizar 5 Servicios Web

en Visual Studio mientras que en NetBeans se hace solamente un Servicio.

Cada vez que se realiza, se crea o modifica un método de un servicio web es

necesario la compilación y el despliegue en el servidor de aplicación que se utilice,

esto hace que dichas operaciones sea algo muy normal y necesario durante la

construcción de cualquier aplicación que contenga servicio web. Una reducción en

el tiempo de despliegue de un servicio genera mucha ventaja frente otra

herramienta de construcción de servicio, a través de la prueba 6 se puede

establecer que el servidor utilizado por Visual Studio es mucho más eficiente que

el servidor de NetBeans en lo que respecta a tiempo de despliegue de un servicio,

y más aun cuando el IDE Visual Studio incorpora un Servidor de desarrollo

principalmente para ahorrar tiempo en el desarrollo no solo de WS, si no en la

mayoría de aplicaciones que se realicen.

El número de instancias de VS es mayor que el NetBeans que solo permite una

instancia, sin embargo esto no es un factor de gran relevancia que pueda

determinar que IDE utilizar, básicamente dependería más de las exigencias misma

de cada proyecto a implementar y del desarrollador mismo que determina al final

como se siente más cómodo.

Las opciones de crear nuevos proyectos, agregar métodos, compilarlos,

desplegarlos, y todas las demás operaciones comunes al realizar WS que brinda

tanto NetBeans como VS, son muy parecida y no se encuentra en realidad una

ventaja del uno sobre otro.

Hasta aquí parece que todo apunta a que Visual Studio tiene mayor ventaja frente

NetBeans en lo concerniente a servicio web, pero a continuación se presenta una de

las mayores ventajas de NetBeans frente a visual Studio y de la más grande debilidad

de VS frente la mayoría de los IDEs de la plataforma J2EE.

NetBeans Visual Studio

Disponibilidad Plataforma(Sistema Operativo)

Windows (2000, xp, vista)Linux (x86 / x64)

Solaris (x86 / x64)Solaris (sparc)

MAC OS XOS Independent Zip

SO Windows (Diferentesversiones)

Lenguajes disponiblesActualmente

Ingles

EspañolIngles

FrancésAlemánItaliano

JaponésCoreano

Chino

Tabla 9. Disponibilidad de NetBeans en varios SO

Aunque VS posee mayor soporte de lenguaje que NetBeans, el problema principal del

Visual Studio es que Microsoft solo tiene disponible esta herramienta para el entorno de

sistema operativo Windows, obligando a si a desarrollar el servicio web bajo este sistema

operativo a diferencia de NetBeans que hay disponibilidad en diferentes SO,

proporcionando así más flexibilidad a los desarrolladores que empleen esta herramienta

frente a VS, a demás en el caso particular de los WS es posible transportar el archivo

.WAR generado por NetBeans y llevarlo a otras plataformas acoplándose con otros

servidores de aplicación y SO.

4.4 Interoperabilidad

En la actualidad existen algunas organizaciones o comunidades cuyo objetivo primordial,

es ofrecer una mayor interoperabilidad a nivel de WS entre las diferentes plataformas y

que se han unido para crear WS-I.

4.4.1 WS – I

Es la Organización para la Interoperabilidad de los Servicios Web. Es un esfuerzo de la

industria con el objetivo de fomentar la interoperabilidad de los servicios Web entre

distintas plataformas, aplicaciones y lenguajes de programación. La organización une una

comunidad diversa de líderes en servicios Web y cuyo principal objetivo es dar respuesta

a las necesidades de los clientes proporcionando unas directrices, prácticas

recomendadas y recursos de ayuda para el desarrollo de servicios Web interoperables.

Esta comunidad desarrolla activamente herramientas, recursos y otras guías de apoyo

para ayudar en la implementación de los servicios Web.

La comunidad de WS-I crea ciertos perfiles para desarrollar WS interoperables, y los

proporciona a los desarrolladores como documento o guías online para poder guiarse y

hacer WS con un nivel mayor de interoperabilidad. Se consigue un nivel mayor de

interoperabilidad al tener más empresa utilizando o basándose en las especificaciones

WS-I. Los perfiles creado por la comunidad WS-I consisten en unas directrices en el cual

explica cómo se deben utilizar las especificaciones para lograr una mejor

interoperabilidad. Por ejemplo WS-I ha creado un perfil para la utilización de SAML

Token de la especificación de WS-Security. A continuación se observa un ejemplo de

cómo sería la correcta utilización de SAML token y otras donde no sería correcta [20].

Correcto:<wsse:SecurityTokenReference xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'>

<wsse:KeyIdentifier ValueType='http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID'>

uuid: 006ab385-35e0-41b1-b0f5-ccef5090c1b0</ PSES: KeyIdentifier>

</ PSES: SecurityTokenReference>

Incorrecto:<! - Este ejemplo es incorrecto porque el PSES: KeyIdentifier elemento

le falta un atributo ValueType por lo tanto conflicto con R6602 -><wsse:SecurityTokenReference xmlns:wsse='http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'><wsse:KeyIdentifier> uuid: 006ab385-35e0-41b1-b0f5-ccef5090c1b0 </

PSES: KeyIdentifier></ PSES: SecurityTokenReference>

Incorrecto:<! - Este ejemplo es incorrecto porque el PSES: KeyIdentifier elemento

tiene un valor incorrecto para el atributo ValueType por lo tanto, enconflicto con R6603 ->

<wsse:SecurityTokenReference xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'>

<wsse:KeyIdentifier ValueType='http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAML'>

http://docs.oasis-

http://docs.oasis-open.org/wss/oasis-wss-saml-

http://docs.oasis-

http://docs.oasis-

http://docs.oasis-open.org/wss/oasis-



Incorrecto:<! - Este ejemplo es incorrecto porque el PSES: KeyIdentifier ha

EncodingType un atributo por lo tanto, en conflicto con R6604 -><wsse:SecurityTokenReference xmlns:wsse='http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'><PSES: KeyIdentifier ValueType = 'http://docs.oasis-

open.org/wss/oasis-wss-saml-token-profile-1.0 # SAMLAssertionID "EncodingType = 'xs: string'>



Según [35] y [36] Existen algunos Stack que se basan en las normas o perfiles de WS-I.

Como son METRO y WCF.

4.4.2 Interoperabilidad con METRO y WCF

Metro es el producto para la interoperabilidad de los servicios web de Sun. Windows

Communication Foundation (WCF) en. NET de Microsoft es modelo de programación

unificado para la construcción de sistemas conectados [35].

La interoperabilidad de servicios Web es una iniciativa de Sun y Microsoft. En la que

prueban y entregan productos al mercado que interoperen a través de diferentes

plataformas [35].

Según [16], Metro contiene a JAX-WS (lo que incluye a JAXB, JAXP, StAX, SAAJ;

utilizado para el mapeo de XML a objetos y viceversa) y WSIT (Tecnología de

Interoperabilidad de los Servicios Web) que garantizar la interoperabilidad y una mejor

fiabilidad, seguridad, y transaccionabilidad de los servicios web. Según [15], WCF integra

un conjunto de tecnologías proporcionadas por .NET Framework, tales como ASMX),

.NET Remoting, Enterprise Services y Web Services Enhancements. Para ver más sobre

WSIT ir al apartado 4.1.1.4 y para WSE ir al apartado 4.1.2.1.1.

Sun Microsystems y Microsoft conjuntamente prueban Metro contra WCF, para garantizar

que los servicios y clientes Web de Sun, interoperen con las aplicaciones de servicio web

http://docs.oasis-

http://docs.oasis-

de WCF y viceversa. Estas pruebas garantizan que los objetivos de interoperabilidad

siguientes sean realizados:

Servicios y Clientes Web de Metro Pueden acceder y consumir servicios Web

WCF.

Servicios y Clientes Web WCF pueden acceder y consumir Servicios web de Metro

Como dice en [35], estas pruebas de interoperabilidad se realizan en las siguientes áreas

Transaccionabilidad, Fiabilidad de Mensajes, Seguridad a nivel de mensajes.

Transaccionabilidad: La transaccionabilidad utiliza una tecnología de optimización de

mensajes. Cuando grandes objetos binarios están codificados en formato XML para su

inclusión en mensajes SOAP, y un servicio web los procesa y transmite estos datos

grandes a través de la red, el rendimiento de la aplicación de servicios web y la red son

afectados negativamente de la siguiente forma:

El rendimiento de la aplicación web del servicio se degrada hasta el punto que ya

no es útil.

La red se encuentra con más tráfico que el ancho de banda asignado puede

manejar.

Una manera de hacer frente a estos problemas es codificando los objetos binarios a fin de

optimizar la aplicación SOAP en el tiempo de procesamiento y en el ancho de banda

necesario para transmitir el mensaje a través de la red. En resumen, XML debe ser

optimizado para servicios web. Esto es exactamente lo que hace la tecnología de

optimización de mensajes. Se asegura de que los mensajes Soap de los Servicios Web

sean transmitidos a través de la Internet de la manera más eficiente [35].

Fiabilidad de Mensajes: capacidad de entregar los mensajes del punto A al punto

B. El objetivo principal de la fiabilidad de mensajes es garantizar la entrega de

mensajes a la aplicación de servicios web extremos a extremos [35].

La tecnología de Fiabilidad de Mensajes garantiza que los mensajes en una

determinada secuencia de mensajes, se entreguen al menos una vez y no más de

una vez, y opcionalmente, en el orden correcto. Cuando los mensajes en una

determinada secuencia se pierden en el tránsito o llegan fuera de orden, esta

tecnología permite a los sistemas, la recuperación de tales fracasos. Si un

mensaje se pierde en el tránsito, el sistema de envío retransmite el mensaje hasta

su recepción hasta que sea reconocido por el sistema de recepción. Si los

mensajes se reciben fuera de orden, el sistema de recepción puede re ordenar los

mensajes en el orden correcto. Normalmente se utiliza Fiabilidad de mensajes

cuando se presenta los siguientes problemas en los WS:

Las Comunicaciones fracasadas están ocurriendo como resultado de que la

red no está disponible o las conexiones se están cayendo.

Los mensajes se están perdiendo en el transito.

Los mensajes están llegando a su destino fuera de orden, y la entrega

ordenada es un requisito

Seguridad de Mensajes: Provee interoperabilidad al utilizar seguridad en los

mensajes Soap. Para ver más ir al apartado 4.1.1 y al 4.1.2

Sun proporciona Metro en la plataforma Java y Microsoft proporciona WCF sobre.

NET 3.0 y. NET 3.5 plataformas [35].

4.4.3 Análisis de la Interoperabilidad

Se inició este análisis investigando las organizaciones que promueven la

interoperabilidad entre WS de diferentes plataformas, y el Stack METRO para J2EE como

la infraestructura de comunicación WCF para .NET, los cuales se basan en algunos

perfiles de la organización (WS-I). Esta agrupación de Sun y Microsoft conducen a

concluir que los servicios web de ambas plataforma, han aumenta de gran manera en el

área de la interoperabilidad, en algunos aspectos muy claves como por ejemplo en:

Fiabilidad, transaccionabilidad y seguridad. Lo cual promueve aun más el uso de esta

tecnología como método principal para implementar la arquitectura SOA, al romper con

algunas barreras de interoperabilidad que existían anteriormente.

Por último se realizó un prototipo de SW que consistía en realizar transacciones de

dinero de una cuenta bancaría hacia otras cuentas del mismo banco o a bancos

diferentes tanto para J2EE como para .NET. Dos de los 4 bancos que se utilizó en el

prototipo son accedidos a través de WS J2EE y los dos restantes accedidos a través de

WS .NET. Adicionalmente se construyeron dos aplicaciones clientes que consumieran los

WS J2EE y .NET; estas aplicaciones fueron construidas en ambas plataformas. Los

parámetros de los dos métodos en cada servicios devuelve un String, el cual indica que

el depósito de dinero o el retiro del mismo se realizo de forma satisfactoria. Ver [Anexo IIIy Anexo IV]

Este prototipo de WS no presento ningún tipo de problema tanto en J2EE como en .NET,

el cual demuestra de forma clara que es posible conseguir interoperabilidad entre estas

dos plataformas con la utilización de servicios web.

4.4.3.1 Posibles problemas al utilizar WS de diferentes plataformas (J2EE, .NET)

Aunque en la actualidad se están haciendo esfuerzos por lograr una mejor

interoperabilidad a nivel de WS aún existen algunos problemas en esta área. A

continuación se presenta un error común de interoperabilidad en el momento de

consumir WS a través de un cliente construido en una plataforma diferente donde fue

construido el WS como tal.

Con tipos de datos tanto primitivos o simple (como: int, float, boolean, u otros) como

complejos (arraylist, vector, otros) no se presento ningún error. El único inconveniente se

generó al realizar un WS en la plataforma .NET, al momento de retornar un DataSet,

aplicado a la base de datos del prototipo .NET.

4.4.3.2 El DataSet como un tipo de dato especifico de .NET

El DataSet de ADO.NET es una representación de datos residente en memoria que

proporciona un modelo de programación relacional, coherente, independientemente del

origen de datos que contiene, como dice en [12]. Un DataSet representa un conjunto

completo de datos, incluyendo las tablas que contienen, ordenamiento y restricción de los

datos, así como las relaciones entre las tablas.

4.4.3.3 El código de un WS que devuelve un DataSet

A continuación se presenta la implementación de un WS que devuelve un DataSet. En el

método del Web Service se recibe como parámetro un tipo de dato String, cuyo nombre

es nombre_de_banco; el cual se utiliza como parte del argumento para consultar la Base

de Datos empleada en el prototipo de WS de .NET. Ver [Anexo III y IV].

Imports System.WebImports System.Web.ServicesImports System.Web.Services.ProtocolsImports System.Data.OleDbImports System.Data

' Para permitir que se llame a este servicio web desde un script, usandoASP.NET AJAX, quite la marca de comentario de la siguiente línea.' <System.Web.Script.Services.ScriptService()> _<WebService(Namespace:="http://tempuri.org/")> _<WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _Public Class Service

Inherits System.Web.Services.WebService

<WebMethod()> _Public Function BUSCAR(ByVal nombre_de_banco As String) As DataSet

Dim conexion As OleDbConnection

Tryconexion = New

OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; " & "DataSource=C:\banconet.mdb;")

Dim Qry As String = "Select * From " &nombre_de_banco

Dim cmd As New OleDbCommand(Qry, conexion)Dim ds As New DataSetDim da As New OleDbDataAdapter(cmd)If conexion.State <> Data.ConnectionState.Open Then

conexion.Open()End Ifda.Fill(ds)

conexion.Close()Return ds

Catch ex As ExceptionReturn Nothing

End Try

http://tempuri.org/

End Function

End Class

4.4.3.4 Analizando el WSDL generado por el WS .NET que devuelve un DataSet

Parte del Wsdl generado por este WS creado en .Net es el siguiente:

Figura 60. WSDL del DataSet

Debido a que la estructura del Dataset no se conoce hasta tiempo de ejecución, no hay

manera para el WSDL de describir su estructura interna. El valor de retorno (elemento

BUSCARResponse) del método BUSCAR tiene dos elementos, un elemento de tipo any

(<s:any/>) que es en efecto un tipo de objeto y un XML Schema (<s:schema>) que en

tiempo de ejecución describirá la estructura del DataSet de retorno [37].

4.4.3.5 Analizando el mensaje Soap generado por un WS utilizando DataSet

A continuación se muestra el resultado del mensaje Soap producido por el método antes

descrito

Figura 61. Mensaje Soap Del DataSet Parte1

Figura 62. Mensaje Soap Del DataSet Parte 2

El elemento NewDataSet tiene un atributo específico de Microsoft llamado “IsDataSet”.

Esta es una pista de Visual Studio de que el resultado debería ser deserializado como

DataSet [37].

Al utilizar DataSet se generan varios problemas debido a que el desarrollador del cliente

no sabe la estructura del objeto que el método devolverá, no podrán generar un proxy

muy útil. El segundo problema cuando se utiliza DataSet desde un servicio web es la

gran cantidad de datos que se envía. El XML anterior sólo describe la estructura de un

DataSet con una tabla. Mientras se añaden tablas, relaciones y claves, el Schema se

vuelve más complejo y más grande. De hecho, rápidamente puede adquirir un tamaño

mayor que los datos que se devuelven [37].

Cuando se trata de consumir desde J2EE genera el siguiente error:

Figura 63. Error Generado en El Cliente con NetBeans

Al utilizar en .NET en el desarrollo de Servicios Web el tipo de dato DataSet, se pierde o

se dificultad hasta cierto punto la interoperabilidad con otras plataformas en especial con

J2EE, ya que este tipo de datos es especifico de .NET, a demás el esquema que se

devuelve que describe la base de datos o la consulta realizada a una BD solo se conoce

en tiempo de ejecución, aunque se trabaje con esquema especifico preestablecido, es

posible que genere error cuando se produzca algún cambio en el WS o en la consulta. La

forma posible de consumir este WS en J2EE seria recibir el mensaje SOAP enviado por

el Servicio .NET y deserializarlo a un tipo de dato especifico de JAVA, utilizando alguna

API para manipular documentos XML.

4.5 Desempeño

Con frecuencia la arquitectura de una aplicación se evalúa en términos de su rendimiento

(throughtput); la habilidad que tiene para terminar un número dado de operaciones lógicas

en un periodo específico de tiempo. La meta es lograr una arquitectura que garantice que

el rendimiento alcanzará un nivel suficientemente alto que permita darle un tiempo de

respuesta adecuado a la demanda de los clientes aun en horas y días pico [13].

A continuación se muestre el test realizado al servidor de aplicación de J2EE Sun

Application Server 9 (En Su Versión Libre GlassFish) y al Servidor de .NET IIS 5.1

utilizando la herramienta AdventNet QEngine.

4.5.1 Reporte de la configuración del Test

A continuación se observa los detalles de la configuración de test y los detalles del

sistema generador de la carga.

El test se realizo con 25 usuarios virtuales con repeticiones por usuarios de 500. Las

URLs que se utilizaron es la de cada aplicación clientes del prototipo realizado. Ver

[Anexo III y IV]

4.5.1.1 J2EE

La duración del test demoro aproximadamente 31 minutos

Tabla 10. Configuración Para J2EE.

4.5.1.2 NET

Tabla 11. Configuración Para .NET.

4.5.2 Resumen del estado de las transacciones

La grafica del resumen del estado de las transacciones provee o muestra las peticiones

pendientes en un instante, las respuestas pendientes, como el estado de las respondidas.

La descarga al iniciar y la descarga al terminar.

4.5.2.1 J2EE

Tabla 12. Resumen de Transacciones en J2EE.

4.5.2.2 .NET

Tabla 13. Resumen de Transacciones en .NET.

4.5.2.3 Análisis 1

Las 2 tablas anteriores refleja que J2EE recibió 12500 peticiones que equivalen a los 25

usuarios virtuales activados con repeticiones por cada uno de 500, el cual respondió

todas las peticiones generando respuesta para cada usuario. A diferencia de .NET que

aunque respondió 12500 peticiones, recibió más de esa cantidad, ya que, el tiempo de

respuesta en algunas peticiones expiro, lo cual el programa de test genero peticiones

adicionales para completar las 12500 peticiones.

4.5.3 Tiempo contra la cuenta de usuarios activos

Esta grafica muestra el conteo de los usuarios virtuales activos durante la ejecución del

test.

4.5.3.1 J2EE

Tabla 14. El tiempo y los Usuarios Activos en J2EE.

4.5.3.2 .NET

Tabla 15. El tiempo y los Usuarios Activos en .NET.

4.5.3.3 Análisis 2

Los 25 usuarios virtuales en el test de J2EE fueron activados al mismo instante a

diferencia de .NET que activo al instante 24 usuarios y luego activo el último usuario en

menos de 1 Segundo. Este dato no se toma tan relevante en esta investigación, ya que el

programa como tal es el encargado de activar los usuarios, a demás se hicieron varios

test presentado resultado en este punto donde .NET activaba todos los usuarios y J2EE

activaba menos de los 25. Hay que tener en cuenta que en esta prueba de activar 24

usuarios, y luego activar el último usuario pasaron únicamente pocos milisegundos.

4.5.4 Hits por segundos

Esta grafica muestra el número de peticiones HTTP/S hechas por los usuarios Virtuales al

servidor durante cada segundo de la ejecución

4.5.4.1 J2EE

Tabla 16. Peticiones Realizadas en J2EE.

4.5.4.2 .NET

Tabla 17. Peticiones Realizadas en .NET.

4.5.4.3 Análisis 3

Se observa que el número de peticiones hechas por los usuarios virtuales al Servidor

J2EE toma diferentes valores desde 1 hasta 25, a diferencia del IIS que aunque también

fluctúa lo hace en menor grado. Esta diferencia de valores es producida por la diferencia

de rendimiento de cada uno.

4.5.5 Tiempo contra el rendimiento

El siguiente gráfico muestra la cantidad de datos en bytes que los usuarios virtuales

recibieron del servidor en segundos. Esto depende de la carga y la transacción que el

usuario realiza.

4.5.5.1 J2EE

Tabla 18. Datos recibidos por Usuarios en J2EE.

4.5.5.2 .NET

Tabla 19. Datos recibidos por Usuarios en .NET.

4.5.5.3 Análisis 4

Se observa que el rendimiento de Bytes por Segundo presentado en GlassFish fue menor

que el presentado en el IIS, ya que se presentaron valores máximos aproximados de 21

000 Byte/Seg y de 72 000 Bytes/Seg respectivamente.

4.5.6 Distribución de los errores para todas las transacciones

Este gráfico indica el porcentaje de error en cada tipo del error expresado como un

porcentaje de errores totales en cada transacción.

4.5.6.1 J2EE

Ningún error encontrado en J2EE

4.5.6.2 .NET

Tabla 20. Errores en .NET.

A continuación se muestra las especificaciones y detalles de los errores

Tabla 21. Especificaciones y Detalles de los Errores en .NET.

Código de error 0 no está definido en el IIS. El Código de error 403 si está definido en el

IIS. Los detalles de este error es el siguiente

Tabla 22. Error 403 en .NET.

4.5.6.3 Análisis 5

Denegación de direcciones IP. Los servicios IIS permiten limitar las aplicaciones de forma

que sólo sirvan un número determinado de solicitudes, lo que podría resultar útil para

denegar el acceso a los usuarios o direcciones IP que se sabe que tienen malas

intenciones. No obstante el otro error presentado en el IIS no se encontró código de error

específico, el cual se asume como algunas peticiones pendiente producido por qué expiro

el tiempo de respuesta, tal vez producido por un posible cuello de botella.

4.5.7 El tiempo contra el porcentaje de error

4.5.7.1 .NET

Este gráfico indica la proporción del error expresada como un porcentaje de golpes o Hit

totales durante la ejecución del test para cada transacción.

Tabla 23. Tiempo contra el Porcentaje de error en .NET.

4.5.8 Reporte del tiempo De respuesta

Este reporte muestras el tiempo de respuesta del Servidor

4.5.8.1 J2EE

Tabla 24. Tiempo de Respuesta Para J2EE.

4.5.8.2 .NET

Tabla 25. Tiempo de Respuesta Para .NET.

4.5.8.3 Análisis 6

De las anteriores tablas cabe destacar que el promedio de respuesta del servidor de .NET

fue menor que del GlassFish cuyos valores respectivos fueron 1254 ms. y 1378 ms.

Obteniéndose así una diferencia de 124 milisegundos, lo que hace que el IIS sea unos

milisegundo más rápido, dándole así más velocidad a las aplicación realizada en .NET y

que trabajen con el servidor IIS. No obstante en el test se presentaron valores superiores

e inferiores en tiempo de respuestas, ya que estos valores no son constantes si no

variables en el tiempo.

4.5.9 El tiempo contra el tiempo de respuesta (Detallado)

Este gráfico muestra el promedio del tiempo de respuesta de cada transacción con el

tiempo. De este gráfico es posible identificar las transacciones que tiene un tiempo de

respuesta largo.

4.5.9.1 J2EE

Tabla 26. Tiempo promedio de cada transacción en J2EE.

4.5.9.2 .NET

Tabla 27. Tiempo promedio de cada transacción en .NET.

4.5.9.3 Análisis 7

Se observa claramente que al principio el Servidor IIS respondía con valores de 63000

milisegundos antes de activar cualquier usuario virtual, luego cuando se activaron los 24

usuarios el servidor respondió con valores de aproximadamente 49000 milisegundos y

luego al activar el último usuario bajo el tiempo de respuesta de acuerdo a la Tabla 25. El

servidor GlassFish a diferencia del IIS empezó con tiempos de respuesta mucho menor;

estos valores fueron aproximadamente 30000 milisegundos antes de activar cualquier

usuario, cuando se activaron los 25 usuarios el servidor respondió con valores menores

de 2000 milisegundo de acuerdo a la Tabla 26.

4.5.10 Usuarios contra el tiempo de respuesta

Este gráfico muestra el tiempo que el servidor tomó para responder contra la cuenta de

usuarios a ese punto de tiempo. Ayuda a identificar el tope de los usuarios simultáneo

máximo que el servidor puede responder tan rápidamente como sea posible.

4.5.10.1 J2EE

Tabla 28. Usuarios Contra El Tiempo de Respuesta para J2EE.

4.5.10.2 .NET

Tabla 29. Usuarios Contra El Tiempo de Respuesta para .NET.

4.5.10.3 Análisis 8

Inicialmente el IIS inicio con 24 usuarios con un tiempo de respuesta del servidor

aproximadamente 49000 milisegundos y bajo a menos 1000 milisegundo al activar el

usuario número 25, en menos de 1 segundo. A diferencia del Servidor de J2EE que activo

los 25 usuarios con un tiempo menor de 700 milisegundos y lo mantuvo “constante”

4.5.11 Usuarios contra el rendimiento

Este gráfico muestra la cantidad de datos en bytes que recibieron del servidor. Esto

depende de la carga y las transacciones ejecutadas por los usuarios. Ayudas a estudiar

los datos a la velocidad transferida del servidor de aplicación.

4.5.11.1 J2EE

Tabla 30. Usuarios Contra El Rendimiento para J2EE.

4.5.11.2 .NET

Tabla 31. Usuarios Contra El Tiempo de Respuesta para .NET.


Inicialmente el IIS inicio con 24 usuarios con un rendimiento por descargas medidos en

bytes de 170 bytes por milisegundos y la velocidad de descargas aumento en menos de 1

segundo al tiempo que completo el ultimo usuario (de 24 usuarios a 25 usuarios) su nueva

velocidad de descarga era aproximadamente de 1270 bytes por milisegundos

aproximadamente. A diferencia del Servidor GlassFish que activo los 25 usuarios con una

velocidad de descarga de 830 bytes por milisegundos, el cual se mantuvo constante.

Donde es notable la ventaja que tiene el servidor IIS frente al de GF con una diferencia

entre ambos de aproximadamente de 500 bytes por milisegundos permitiendo ser más

veloz

4.5.12 Cuellos de botellas - Reporte de análisis

Este gráfico superposiciona el tiempo de respuesta, el porcentaje de error y la cuenta de

usuarios activos para cada intervalo del test ejecutado. Indica la capacidad del sistema en

términos de usuarios simultáneos

4.5.12.1 J2EE

Tabla 32. Análisis de Posibles Cuellos De Botellas para J2EE.

4.5.12.2 .NET

Tabla 33. Análisis de Posibles Cuellos De Botellas para .NET.


En la Tabla 33 cabe de destacar la gran cantidad de error presentado en el servidor IIS

frente al GlassFish, el cual no presento ninguno, estos errores se han explicado en el

Análisis 5.

4.5.13 El tiempo contra el tiempo de las páginas descargadas

Este gráfico muestra el promedio del tiempo de las página transmita o descargada para

todas las transacciones por tiempo. Ayuda a identificar los picos en tiempos de descargas

cuando el servidor es continuamente cargado

4.5.13.1 J2EE

Tabla 34. El Tiempo De Las Páginas Descargada para J2EE.

4.5.13.2 .NET

Tabla 35. El Tiempo De Las Páginas Descargada para .NET.


El servidor de J2EE presenta un promedio de 60 milisegundos por páginas descargadas

con picos máximos 78 milisegundos, en el IIS aun que no es posible apreciarlo ya que su

valor inicial fue alto en esta gráfica, el promedio del tiempo de descarga por páginas es de

7 milisegundos Ver (4.5.15.2)

4.5.14 Reporte del tamaño de páginas

Este reporte muestra el tamaño de cada página

4.5.14.1 J2EE

Tabla 36. Tamaño De la Página J2EE.

4.5.14.2 .NET

Tabla 37. Tamaño De la Página .NET.


El tamaño de la página de .NET es mayor que el J2EE, presentando valores de 2141

bytes para .NET y de 829 bytes para J2EE, a pesar de que ambos clientes son muy

parecidos en la parte grafica y en funcionalidades.

4.5.15 Reporte de las páginas descargada

Este grafico muestra el tiempo de descarga por páginas, imagines y otros contenidos por

cada Página.

4.5.15.1 J2EE

Tabla 38. Tiempo De Descarga Por Páginas en J2EE.

4.5.15.2 .NET

Tabla 39. Tiempo De Descarga Por Páginas en J2EE.


Aunque el tamaño en bytes de la página Web de la aplicación de .NET es mucho mayor

que la de J2EE el tiempo de descarga es mucho mejor ya que existe una diferencia de de

53 milisegundo por páginas descargadas.

4.5.16 Resumen de los reportes

Esta página muestra los detalles de ejecución del test como el estado de las

transacciones, los errores de la prueba detalla en gráfico, promedio del tiempo respuesta,

la cuenta del usuario, el tiempo de descarga de las páginas, promedios, etc.

4.5.16.1 J2EE

Tabla 40. Resumen Del Test de J2EE.

4.5.16.2 .NET

Tabla 41. Resumen Del Test de .NET.


En el resumen anterior se muestra la diferencia entre los 2 test realizado a J2EE y .NET

respectivamente el primero de mora un tiempo de 1896 segundos y el segundo demora

1856 segundos, una diferencia de 40000 milisegundos. El primero tuvo un tiempo mínimo

de respuesta promedio en el servidor de 1378 milisegundo el segundo tuvo 1254

milisegundos. El primero tuvo un tiempo mínimo de páginas descargadas de 60

milisegundo el segundo tuvo un tiempo mínimo de 7 milisegundo. El primero tuvo un

rendimiento mínimo de 5509 bytes/segundos el segundo tuvo un mínimo de 14533 bytes /

segundos. El primero tuvo un total de 1 MB transferido, el segundo tuvo un total de 2 MB

transferido.

4.5.17 Analizando el desempeño entre J2EE y .NET utilizando otras Investigaciones

Según [21] Maneesh realizó un estudio similar utilizando la herramienta AdventNet

QEngine, después de haber estudiado otras herramientas como JMeter, ANTS.

4.5.17.1 Test realizado

En esta investigación se crearon cuatro clientes, dos en ASP.NET y dos en JSP. Uno de

los clientes ASP .NET accede a los servicios web desarrollados en EJB, mientras que el

otro accede de forma similar a los servicios web desarrollados en ASP .NET. Del mismo

modo, uno de los clientes JSP invoca los servicios web desarrollados en ASP .NET y el

otro accede a los servicios web desarrollados en EJB. Los cuatro clientes se comparan

para diferentes cargas y estrés.

Lo antes dicho queda representado de esta forma:

a. Clientes JSP accediendo a los servicios web EJB.

b. Cliente JSP accediendo a servicios web .NET.

c. Clientes .NET accediendo a Servicios Web EJB.

d. Clientes .NET accediendo a Servicios Web .NET.

4.5.17.2 Resultado del Test

a. Cuatro conexiones simultáneas

Tabla 42. Cuatro conexiones simultáneas.

Tabla 43. Nueve Conexiones.

Tabla 44. Tiempo de Descarga y Errores.

4.5.17.3 Análisis de Maneesh

El análisis que Maneesh Rampally realiza de la primera grafica es el siguiente: Que un

WS .NET responde más rápido que un servicio Web EJB. Entre los clientes que acceden

a los WS .NET el tiempo de la página descargada de los clientes JSP es mayor que los

clientes .NET Entre los clientes que acceden a los WS EJB, el tiempo de la página

descargada de los clientes .NET es mayor que los clientes JSP.

En la segunda grafica dice que a diferencia de la primera se presentan en los clientes

.NET picos hacia arriba y hacia abajo, llegando a dos conclusiones que es debido alto

índice de error en este, del 30% presentado en .NET como lo muestra la ultima grafica

debido a que el IIS para Windows XP viene configurado para soportar máximo 10

conexiones. Y luego agrega que hay gran carga en la CPU ya que está trabajando al

tiempo el servidor de J2EE que en este caso es el Sun Application Server, y el IIS además

la herramienta de testeo QEngine lo cual hace posible que se genera gran cantidad de

error.

Maneesh Rampally realiza otras pruebas obteniendo resultados similares, al final de

investigación concluye que los WS de .NET son más rápido que los de J2EE, aunque

también dice que ambas plataformas tiene pro y contra cuando se observa desde la

perspectiva del programador [21].

4.5.18 Análisis Final

Después de haber realizado el test con AdventNet QEngine para evaluar cual plataforma

presenta un mayor de Desempeño se concluye lo siguiente:

El rendimiento obtenido en Bytes por el IIS es mejor que el obtenido por

GlassFish, aunque hasta cierto punto esto es debido a que la página de la

aplicación de .NET es de mayor tamaño.

Además del test que se presenta en este capítulo se hicieron repeticiones del

mismo con más o con menos usuarios y se observo que el rendimiento medido en

la descarga de bytes por milisegundo que se observo en las tablas del apartado

4.5.11, en las repeticiones de los test para el caso del servidor GlassFish siempre

se mantuvo constante, en caso del servidor IIS se obtuvieron valores por encima

de los obtenidos con GlassFish, los valores máximos obtenidos en otros test

fueron de aproximadamente 45000 bytes por milisegundos.

El tiempo promedio de respuesta obtenido de los Servidores fue muy bueno de

acuerdo a las especificaciones del sistema cómputo donde se realizo el test, pero

se destaca de forma importante que los mejores resultados en esta área las

obtuvo el servidor IIS.

Una de la más grande ventaja que se encontró entre el desempeño .NET frente a

J2EE en este test realizado es que aunque el tamaño de la página de la

aplicación .NET es mucho mayor que la aplicación J2EE, el tiempo de descarga de

la página .NET es mucho mejor que la página J2EE. Según esta prueba es

posible descargar aproximadamente 8 páginas de .NET por cada página de J2EE.

Ver análisis 11.

En el análisis hecho por Maneesh [21] en el 2006 utilizando el IIS y el Sun

Application Server se obtiene como resultado que existe un mejor desempeño de

forma general en los WS de la plataforma .NET. Aunque para acceder a servicios

J2EE, es mejor a través de un cliente J2EE al igual que .NET. En este test

realizado para evaluar el desempeño entre las dos plataformas se obtienen

resultados similares.

En el servidor IIS al aumentar el número de usuarios genera cierto porcentaje de

errores, algunos de estos errores se explican por la configuración que trae por

defecto el servidor, pero que existen una gran cantidad de errores generado, en el

cual se concluyó que fueron peticiones en el que expiro el tiempo de respuesta.

En la investigación realizada por Maneesh [21] también se generaron algunos

errores en el Servidor IIS, en donde se establecieron algunos factores causantes;

uno de ellos es la configuración por defecto del IIS.

El Servidor GlassFish presenta un soporte adecuado al número de peticiones

pendientes frente al IIS de acuerdo a las configuraciones que ambos traen por

defecto, ya que, el GlassFish dio una respuesta a cada petición generada por los

usuarios activos obteniendo así ningún tipo de error en el test de 25 usuarios

virtuales con repeticiones de 500 por cada usuario que se realizó.

Se pueden obtener los resultados de las diferentes pruebas realizadas al prototipo

propuesto J2EE y .NET utilizando QEngine, con diferentes números de usuarios,

diferentes repeticiones por usuario y diferentes cargas de trabajos en [38].

PRESUPUESTO ECONÓMICO

Presupuesto GeneralPersonal $ 2.808.000Material inventariable $ 1.840.000Material Noinventariable $ 222.000

TOTAL $ 4.870.000

PERSONALDescripción Dedicación Cantidad Valor-Mes Meses Valor Total

Director de proyecto 2 Horas semanales 1 $ 0 6 $ 0Autor 8 Horas diarias 1 $ 468.000 6 $ 2 808 000

Total $ 2.808.000

Material InventariableDescripción Cant Valor Total

1.Computador Intel(R)/Celeron(R)2.80GHz/1,5-GB RAM/DVD-RW/CD-RW/Monitor de 15 pul AOC 1 $ 1400000 $ 1400000

2. Mesas para computador 1 $ 150000 $ 1500003. Sillas para computador 1 $ 50000 $ 500004. Impresora de tinta APOLLO P-2600 1 $ 130000 $ 1300005. Scanner 1 $ 110000 $ 110000

Total $ 1840000

Material No InventariableDescripción Cant Valor Total

1. CD 12 $ 1000 $ 120002. Papelería, Fotocopias, impresiones 1 $ 60000 $ 600003. Tinta negra para Impresora Apollo 1 $ 40000 $ 400004. Tinta de color para Impresora Apollo 1 $ 60000 $ 600005. Memoria USB de 512 MB 1 $ 50000 $ 50000

Total $ 222000

FUENTES DE FINANCIACIÓN

Para la realización de este trabajo de grado los recursos económicos fueron totalmente

financiados por mis padres y demás familiares.

MARCO LEGAL

En la realización de este trabajo se utilizaron una series de herramientas, las cuales

ayudo tanto para realizar el comparativo entre las dos plataformas como para desarrollar

el prototipo de servicio web, cada una de estas herramientas cuenta con una licencia con

la cual se rige el desarrollo y la comercialización de todo aquello que se desarrolle en

estas.

A continuación se presenta cada una de las licencias de las herramientas o programas

utilizados en el desarrollo de este proyecto.

NetBeans: es un producto de código abierto y gratuito para uso tanto comercial

como no comercial. El código fuente está disponible para su reutilización de

acuerdo con la Common Development and Distribution License ( CDDL) v1.0 and

the GNU General Public License (GPL) v2.

Java DB: Java DB se basa en el Apache Derby proyecto de código abierto, el cual

se puede descargar es su última versión de [29], pero para la realización del

prototipo se utilizo el Java DB que viene integrado con el IDE NetBeans.

GlassFish Server Application: Es gratuito y de código libre, se distribuye bajo la

licencia CDDL y la GNU GPL. Se utilizo la Versión que viene integrada en el IDE

NetBeans.

Visual Studio .NET 2008 Profesional: es un producto cuya licencia es privativa y

comercial, pero para efecto de este trabajo se utilizo una versión preview o de

prueba por 90 días que es posible descargar de [12].

Microsoft Access 2003: es un producto cuya licencia es privativa y comercial,

pero para efecto de este trabajo se utilizo una versión de prueba que es posible

descargar de [12].

IIS 6: No es un producto software que se puede comprar o adquirir como tal en

forma individual, es un componente del Sistema Operativo Windows el cual se

debe añadir al momento de la instalación del Windows o agregarlo como un

componente del SO Windows utilizando el Cd de instalación.

AdventNet QEngine: Es un producto cuya licencia es privativa y comercial, pero

se utilizo una versión preview descargada de [14].

INFLUENCIA AMBIENTAL

En el desarrollo de este trabajo de grado no se presentó ningún impacto negativo al

medio ambiente, ya que los dispositivos, equipos y tecnologías que se utilizaron en el

desarrollo tanto del proyecto investigativo como en la implementación del prototipo, se

hizo en una forma segura evitando afectar y perjudicar el medio ambiente y al ser

humano; de lo cual se pudo hacer buen uso de los mismos, sin dañar el medio que nos

rodea.

CONCLUSIONES

Ambas plataformas brindan lo necesario para desarrollar de forma satisfactoria, servicios

y clientes web para crear soluciones empresariales bajo cada tecnología. Sin embargo se

destacan algunos aspectos importantes que se pueden tener en cuanto, a la hora de

elegir o escoger entre algunas de las dos:

Ambas plataformas se basan en especificaciones de seguridades comunes a nivel

de mensaje lo que hace posible que la interoperabilidad se mantenga aún al

emplearlas. Así que la decisión de utilizar una plataforma en vez de la otra radica

al final en los desarrolladores o en la organización que pretenda implementar los

servicios web, aunque según [30] se creer que existe una ventaja de seguridad de

J2EE frente a .NET, ya que, desde un comienzo Java se fundamentó en un

estricto modelo de seguridad a diferencia de .NET, y que por ende la experiencia

Java en cuanto a seguridad es mucho mayor.

Cada una se fundamenta en una arquitectura de código intermedio y de maquinas

virtuales para permitir la portabilidad, pero J2EE posee un mayor grado de

portabilidad. Si la portabilidad es un factor importante y fundamental es mejor

decidirse por una solución J2EE, donde ya esta portabilidad ha sido demostrada a

lo largo de la historia. Por otro lado si lo que se pretende desarrollar exige varios

lenguajes de propósito programacional diferente, es mejor una solución .NET

debido a su independencia de lenguaje, proporcionada por el CLR.

Tanto NetBeans como Visual Studio son herramientas potentes que ayudan a

crear aplicaciones por capas, y a que los desarrolladores se concentren

únicamente en la lógica de negocio. En el desarrollo de servicios web cada una

demostró tener los instrumentos necesarios para construir servicios y clientes web.

La ventaja obtenida al comparar los dos IDE se encuentra a favor de Visual Studio.

Aspectos como el IDE marca la diferencia cuando el factor tiempo de desarrollo, es

de suma importancia en lo que se pretende realizar, aun cuando se trata de

servicios web o de cualquier clase de aplicación, decidiéndose así por optar por

una solución .NET cuando se da esta clase necesidad.. Por otro se resalta el

hecho que NetBeans es una de tantas herramientas para construir servicios en

J2EE. Además cuando se cuenta con aplicaciones con diferentes sistemas

operativos, la utilización de Visual Studio se convierte en un problema. Entonces

en un escenario como este la mejor solución es J2EE, ya que, la mayoría de las

herramientas para construir servicios se pueden instalar en cualquier sistema

operativo.

Al implementar servicios web J2EE y .NET y consumirlos desarrollando clientes en

ambas plataformas, se comprobó en efecto que los servicios web permiten la

interoperabilidad. Por otro lado, Sun y Microsoft están trabajando mancomunado

en algunos aspectos específicos, para aumentar el nivel de interoperabilidad

entres las dos. Si los factores de fiabilidad, transaccionabilidad y seguridad son de

suma importancia; se pueden utilizar cualquiera de las dos plataformas, ya que,

ambas poseen soporte e interoperabilidad en estos aspectos. Sin embargo se

puede perder cierto grado de interoperabilidad al utilizar servicios web .NET, ya

que, estos a veces devuelven datos específicos de la misma plataforma. Si se

requiere un máximo nivel de interoperabilidad en los servicios web, que se

pretenden desarrollar es mejor optar por una solución J2EE. Diferentemente, si se

sabe que los servicios web únicamente serán consumidos por clientes .NET

(teniendo en cuenta también el criterio de desempeño), es una buena opción

construir estos servicios en .NET utilizando DataSet en caso que así se requiera, y

ahorrar tiempo en el desarrollo de los mismos.

Tanto J2EE como .NET ofrecen un buen grado de desempeño óptimo, para

realizar soluciones empresariales basadas en Servicios Web, y aunque en las

pruebas realizadas se nota una superioridad de .NET, sería bueno realizar otras

pruebas con otras características, como se menciona en las recomendaciones de

este documento. No obstante de acuerdo a los resultados obtenidos de las

pruebas realizadas de desempeño, se recomienda utilizar servicios web .NET para

lograr el máximo desempeño, y de acuerdo a Maneesh como se estudio en [21],se aconseja si es posible, utilizar clientes construidos en la misma plataforma

donde se realizaron los servicios web como tal, para conseguir un mejor

desempeño.

RECOMENDACIONES

Este documento puede ser utilizado para investigaciones futuras donde se estudie o se

analicen criterios de comparación en un área diferente a los servicios web como por

ejemplo componentes o aplicaciones web, entre otros.

Ampliar este proyecto escogiendo otros criterios de comparación en el plano de los

servicios web. De igual forma investigar sobre el estado del arte de los servicios web

semánticos y su posible implementación e interoperabilidad en cada plataforma.

Las pruebas realizadas para comparar el desempeño, se hicieron bajo el sistema

operativo Windows XP y utilizando la herramienta QEngine, se recomienda realizar

nuevas pruebas de desempeño bajo otros sistemas operativos en el caso de J2EE para

su posterior verificación con los datos arrojados en el sistema operativo Windows. Así

mismo utilizar una herramienta diferente a QEngine y utilizar otros servidores aplicaciones

en J2EE como: WebSphere (IBM), Oracle Application Server (Oracle Corporation),

WebLogic (BEA) entre otros.

Estudiar e Implementar otras especificaciones de seguridad a nivel de mensaje para el

desarrollo de servicios web en aras de fortalecer más los conocimientos en esta área y

estar así mejor preparado para enfrentar los retos de seguridad que se originen.

Asignación de un salón computacional con los requerimientos necesarios de hardware

para la realización de prácticas y pruebas con J2EE y .NET para los estudiantes de la

Universidad De Pamplona que ayude en la preparación profesional y desarrollo de la

investigación en esta área.

GLOSARIO DE TÉRMINOS Y SÍMBOLOS

Algoritmo: Un algoritmo es una serie de pasos organizados que describe el proceso quese debe seguir, para dar solución a un problema específico.

API: Interfaz de Programación de Aplicaciones.

ASP: Active Server Pages (ASP) es una tecnología de Microsoft.

BD: Base de Datos.

CLASS: Extensión generado al compilar una clase Java en Bytecode

Código Gestionado: Código de un programa de computador que se ejecuta bajo lagestión de una máquina virtual.

Código No Gestionado: Código de un programa de computador que se ejecutadirectamente por la CPU del computador.

Componente de Software: son aquel recurso desarrollado para un fin concreto y quepuede formar solo o junto con otro/s, un entorno funcional requerido por cualquier procesopredefinido. Son independientes entre ellos, y tienen su propia estructura eimplementación.

Containers: Contenedores.

CPU: Unidad de Proceso Central.

Deploya(r): Desplega(r).

Desencriptar: Proceso inverso de encriptación que permite ver una información que sehabía protegido.

ENCRIPTAR: Acción de proteger información para que no pueda ser leída sin una clave.

FIREWALL: Corta Fuegos, es un elemento de hardware o software utilizado en una redde computadoras para controlar las comunicaciones, permitiéndolas o prohibiéndolassegún las políticas de red que haya definido la organización responsable de la red.

FTP: Protocolo de transferencia de Archivos.

GET: Comando del Protocolo HTTP que solicita el recurso ubicado en la URL especifica.

GF: Servidor GlassFish de J2EE.

HTML: Lenguaje de Marcas de Hipertexto

HTTP: Protocolo de transferencia de Hipertexto

HTTP/S: Protocolo de transferencia de Hipertexto seguro

IDE: Entorno de Desarrollo Integrado.

IU: Interfaz usuario.

JAXP: API de Java para el Procesamiento de XML

JDBC: Conectividad de Bases de Datos de Java.

JSP: Java Server Pages, que en español seria Páginas de Servidor Java. Es unatecnología orientada a crear páginas web con programación en Java.

JVM: Maquina Virtual de Java

LP: Lenguaje de programación.

Llave Pública: Clave que se utiliza para desencriptar información.

Llave Privada: Clave que se utiliza para encriptar una información.

NNTP: Network News Transfer Protocol

POST: Comando del Protocolo HTTP que Envía datos al programa ubicado en la URLespecificada.

ROUTER: Enrutador.

SAAJ: SOAP with Attachments API for Java. Suministra una manera estándar de enviardocumentos XML sobre Internet desde la plataforma Java.

SCHEMA: Es un vocabulario basado en XML para describir instancias de documentosXML. Un “schema” describe una clase de documentos, del cual pueden haber variasinstancias. Esta relación es parecida a la que hay entre clases y objetos en los sistemasorientados a objetos.

SI: Sistemas de Información.

SMTP: Simple Mail Transfer Protocol (SMTP), Protocolo Simple de Transferencia deCorreo.

SQL: Lenguaje de Consulta Estándar o Universal.

StAX: Streaming API for XML. Para tratar los documentos XML de forma más rápida.

SUN: Sun Microsystems, empresa productora de software.

URI: Identificador Uniforme de Recursos.

URL: Localizador Uniforme de Recursos.

VS: Visual Studio.

W3C: World Wide Web Consortium.

WS: Web Service(s). Servicio(s) Web.

WSS: WS-Security.

BIBLIOGRAFÍA Y REFERENCIAS WEB

[01] Edgardo Alberto Romero Masis. Estado del Arte de la Tecnología de Web Services.

Septiembre del 2004. Disponibilidad Septiembre 2008.

http://www.juliux.org/tesis/webservices/Web_Services_final.doc.

[02] Vadim Paz Madrid Gorelov y Juan Francisco De Paz Santana. Articulo Servicios

Web. Disponibilidad Septiembre 2008. http://zarza.usal.es/~fgarcia/doctorado/iweb/05-

07/Trabajos/ServiciosWeb.pdf

[03] Consorcio World Wide Web. Guía Breve de Servicios Web. Disponibilidad

Septiembre 2008. http://www.w3c.es/

[04] Francisco Carpe García. Estudio de la plataforma .NET. Diciembre de 2001.

Disponibilidad Septiembre 2008. http://ditec.um.es/cgi-bin/dl/ProyectoNET.pdf

[05] Enciclopedia de Contenido Libre. Disponibilidad Septiembre 2008.

http://www.es.wikipedia.org/

[06] Xml Web Service. Disponibilidad Septiembre 2008. http://www.desarrolloweb.com/

[07] Miguel Ángel Garrido Pino. Evaluación Comparativa de aplicaciones Web entre J2EE

y Microsoft. NET. 2006. Disponibilidad Septiembre 2008.

http://biblioteca.uct.cl/tesis/miguel-garrido/tesis.pdf

[08] Lía Molinari. Arquitecturas Orientadas a Web Services abril 2004 Disponibilidad

marzo 2007 http://www.sedici.unlp.edu.ar/search/request.php

[09] Jose G. Samper C. Integración Del Sistema De Gestión Administrativa y el Sistema

De Comercio Electrónico mediante XML Web Services. Septiembre 2005. Disponibilidad

Septiembre 2008. http://www.tauniversity.org/tesis/Tesis_Jose_Samper1.pdf

http://www.juliux.org/tesis/webservices/Web_Services_final.doc

http://zarza.usal.es/~fgarcia/doctorado/iweb/05-

http://www.w3c.es/

http://ditec.um.es/cgi-bin/dl/ProyectoNET.pdf

http://www.es.wikipedia.org/

http://www.desarrolloweb.com/

http://biblioteca.uct.cl/tesis/miguel-garrido/tesis.pdf

http://www.sedici.unlp.edu.ar/search/request.php

[10] Mario Alberto Chávez Cárdenas. Introducción a Visual Studio 2008 y .NET

Framework 3.5 Febrero 2008. Disponibilidad Septiembre 2008.

http://ejqdfa.blu.livefilestore.com/

[11] Organización para la Cooperación y el Desarrollo Económicos (OCDE). Guías para

la Seguridad de los Sistemas de Información y Redes. Año 2002. Disponibilidad

Septiembre 2008. http://www.uaslp.mx/PDF/2042_182.pdf, artículo sobre la seguridad de

información http://w3.bsa.org/colombia/press/newsreleases/Colombia-25-09-2006.cfm

[12] Simon Guest. Interoperabilidad de Servicios Web, Aaron Skonnard. Mejorar la

interoperabilidad de los servicios Web. Disponibilidad Septiembre 2008.

http://www.microsoft.com/

[13] Geir Bostad. Supporting SAM: Infrastructure Development for Scalability Assessment

of J2EE Systems. October 2006. Disponibilidad Septiembre 2008.

http://daim.idi.ntnu.no/masteroppgaver/IME/IDI/2002/3289/masteroppgave.pdf

[14] QEngine - Load Testing and Functional Testing Tool

http://www.adventnet.com/products/qengine/index.html

[15] J. J. Domínguez Jiménez, A. Estero Botaro, I. Medina Bulo, M. Palomo Duarte y F.

Palomo Lozano. El Reto De Los Servicios Web Para El Software Libre. Disponibilidad

Septiembre 2008. http://www.willydev.net/

[16] Web Services Interoperability Technologies (WSIT) https://wsit.dev.java.net/ ,

METRO. https://metro.dev.java.net/

[17] Ejemplo de UserNameTokens. Securing .NET Web Services with the WS-Security

Protocol. Disponibilidad Septiembre 2008.

http://www.devx.com/dotnet/Article/19986#codeitemarea

[18] Artículo Servicios web con Mono. Disponibilidad Septiembre 2008. http://ruido-

blanco.net/blog/archivos/2003/09/18/servicios-web-con-mono/

http://www.tauniversity.org/tesis/Tesis_Jose_Samper1.pdf

http://ejqdfa.blu.livefilestore.com/

http://www.uaslp.mx/PDF/2042_182.pdf

http://w3.bsa.org/colombia/press/newsreleases/Colombia-25-09-2006.cfm

http://www.microsoft.com/

http://daim.idi.ntnu.no/masteroppgaver/IME/IDI/2002/3289/masteroppgave.pdf

http://www.adventnet.com/products/qengine/index.html

http://www.willydev.net/

http://www.devx.com/dotnet/Article/19986#codeitemarea

http://ruido-

[19] Consumidores y proveedores OLE DB. http://msdn.microsoft.com/

[20] Organización Para La Interoperabilidad De Los Servicios Web. http://www.ws-i.org/

[21] Maneesh Rampally. Performance Comparison Of Interoperability Between J2EE And

.NET Web Services. Año 2006. Disponibilidad Septiembre 2008.

http://people.cis.ksu.edu/~maneesh/maneesh/Report_Final_Draft.doc

[22] William Vásquez Romero y Juan Guillermo Rojas. Mecanismos de Control de Acceso

en Web Services. Diciembre 2004. Disponibilidad Septiembre 2008.

http://www.javeriana.edu.co/biblos/tesis/ingenieria/Tesis208.pdf

[23] C. Gutiérrez, E. Fernández-Medina, M. Piattini. Seguridad en Servicios Web. Enero

2005. Disponibilidad Septiembre 2008. http://www.info-

ab.uclm.es/descargas/thecnicalreports/DIAB-05-01-2/Seguridad_en_Servicios_Web.pdf

[24] Jorgen Thelin. Identity, Security, and XML Web Services. Disponibilidad Septiembre

2008. http://www.idealliance.org/papers/dx_xmle03/papers/03-04-06/03-04-06.pdf

[25] Características de Java. Disponibilidad Septiembre 2008.

http://www.itapizaco.edu.mx/paginas/JavaTut/froufe/parte2/cap2-5.html

[26] Rolando Menchaca Méndez y Félix García Carballeira. Arquitectura de la Máquina

Virtual Java. Octubre de 2000. Disponibilidad Septiembre 2008.

http://www.revista.unam.mx/vol.1/num2/art4/

[27] Daniel Fernández Garrido. Desmitificando Java. Marzo del 2003

http://www.elrincondelprogramador.com/default.asp?pag=articulos/leer.asp&id=56

[28] Nathalie M. Aquino Salvioni Juan Carlos Frutos Acosta. Fundamentos de la Máquina

Virtual Java y el Entorno .NET. Octubre de 2002. Disponibilidad Septiembre 2008.

http://www.jeuazarru.com/docs/Java_y_PuntoNET.pdf

http://msdn.microsoft.com/

http://www.ws-i.org/

http://people.cis.ksu.edu/~maneesh/maneesh/Report_Final_Draft.doc

http://www.javeriana.edu.co/biblos/tesis/ingenieria/Tesis208.pdf

http://www.info-

http://www.idealliance.org/papers/dx_xmle03/papers/03-04-06/03-04-06.pdf

http://www.itapizaco.edu.mx/paginas/JavaTut/froufe/parte2/cap2-5.html

http://www.revista.unam.mx/vol.1/

http://www.elrincondelprogramador.com/default.asp

[29] Chad Vawter y Ed Roman. J2EE vs. Microsoft.NET. Junio de 2001. Disponibilidad

Septiembre 2008. http://www.sun.com/

[30] Comparación entre J2EE y .NET. Disponibilidad Septiembre 2008.

http://cek.blogia.com/2004/050301-comparacion-entre-j2ee-y-.net.php

[31] Improving Web Services Security. Disponibilidad Septiembre 2008.http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx?ReleaseId=15892

[32] Adrián Delfino, Sebastián Rivero, Marcelo San Martín. Ingeniería de Tráfico en Redes

MPLS. http://iie.fing.edu.uy/investigacion/grupos/artes/fce/net -

te/Ingenieria_de_Trafico_en_Redes_MPLS.pdf

[33] Chaitanya Kurada. A CHOICE BETWEEN INTEROPERABILITY AND MIGRATION.

Año 2004. Disponibilidad Septiembre 2008.

http://people.cis.ksu.edu/~kurada/MS%20Report.doc

[34] Damian K. y AndrésP Federación de Servicios en Ambiente Heterogéneo. Estado

del arte de WS-Security, parte del Standard WS-*. Año 2008. Disponibilidad Noviembre

2008 http://www.fing.edu.uy/~pgfedws/Documentos/Estado%20del%20Arte%20WS-

Security_v1.1.doc

[35] METRO Guia de Usuario. Disponibilidad Noviembre 2008. https://jax-

ws.dev.java.net/guide/

[36] Krishna Prasad. Windows Communication Foundation (WCF) and WinFX.

Disponibilidad Noviembre 2008. http://www.codeproject.com/KB/dotnet/

WinCommunicationFoundatio.aspx?display=Print

[37] Paul Ballard Top 5 Web Service Mistakes. Mayo 2005. Disponibilidad Septiembre

2008. http://www.theserverside.net/tt/articles/showarticle.tss?id=Top5WSMistakes

http://www.jeuazarru.com/docs/Java_y_PuntoNET.pdf

http://www.sun.com/

http://cek.blogia.com/2004/050301-comparacion-entre-j2ee-y-.net.php

http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx

http://iie.fing.edu.uy/investigacion/grupos/artes/fce/net

http://people.cis.ksu.edu/~kurada/MS%20Report.doc

http://www.fing.edu.uy/~pgfedws/Documentos/Estado%20del%20Arte%20WS-

http://www.codeproject.com/KB/dotnet/

http://www.theserverside.net/tt/articles/showarticle.tss

[38] John Jairo Méndez R. Análisis comparativo entre J2EE y .NET. Noviembre 2008.

http://www.j2ee-vs-net.blogspot.com/

ANEXO I

SEGURIDAD A NIVEL DE MENSAJE EN LOS SERVICIOS WEB

1. Técnicas y procedimientos de seguridad

El hecho de publicar una serie de servicios Web accesibles a todo el mundo puede

suponer una ventaja comercial, pero en ocasiones, la seguridad en determinados

servicios puede ser de vital importancia, y es necesario evitar acceso de terceros a la

información que viaja en los mensajes SOAP, o la alteración de los mismos y evitar

ataques de negación de servicio. Para poder ofrecer al cliente seguridad en la

comunicación con los proveedores de servicios se utiliza una combinación de las

siguientes características, según [22]:

Autenticación: La autenticación es un proceso por el cual se puede identificar a

una persona o a un sistema y validar sus credenciales, normalmente se hace

mediante el empleo de una combinación de nombre de usuario y contraseña. Si la

contraseña no es protegida adecuadamente, entonces la autenticación se verá

comprometida. La autentificación en los WS es asegurar la procedencia del

mensaje, realmente es quién dice ser?. Otra manera de garantizar la

autenticación, es por medio del uso de certificados, el cual se basa en llaves

privadas y públicas para encriptar la información y garantizar la autenticidad de

los servicios, para lograr esto se necesita de una entidad certificadora externa al

Servicio con el fin de poder garantizar la identidad de los clientes.

Autorización: Una vez que se ha autenticado al usuario, se le debe dar la

autorización de acceso, esto quiere decir que identifica a qué recursos tiene

derecho el usuario, y cuáles recursos le serán negados al momento de una

petición. Esta autorización se hace a través del uso de ACL (Access Control List),

en esta lista se encuentran los usuarios y los tipos de acceso que tienen a los

recursos.

http://www.j2ee-vs-net.blogspot.com/

Integridad: Consiste en ofrecerle al cliente la seguridad de que la información

que se está enviando a través de la conexión con el proveedor, no ha sido

alterada, esto quiere decir que no se hará ninguna modificación a la información

transportada por quien no esté autorizado a hacerlo.

Confidencialidad: Es el proceso por el cual se asegura que la información no

pueda ser leída, a menos que se tenga autorización para ello. No basta con

emplear la identificación del usuario y la contraseña, sino que además la

información es encriptada para protegerla.

No repudio: Asegurar que no se pueda negar el haber participado en una

operación, esto quiere decir que se debería mantener un historial de participación

o de uso del sistema, de los usuarios.

Auditar: Es el proceso de grabar los eventos relacionados con la seguridad en la

comunicación, y tomar acciones basados en las ocurrencias de estos.

2. Tipos de ataques

A continuación se mencionan los principales ataque que pueden ocurrir al implementar

Servicios Web en el nivel de mensaje, según [22].

Alteración de los mensajes. Este tipo de amenazas afectan a la integridad de los

mensajes, en tanto en cuanto un atacante podría modificar partes (o la totalidad)

de un mensaje. Un atacante que tuviera interceptada la línea de comunicaciones

entre los servicios podría hacer rastreo (sniffing), capturar los mensajes, eliminar o

modificar parte o la totalidad del mensaje, y volverlo a poner en la línea de

comunicaciones. La integridad de los mensajes también se verá afectada si el

atacante realiza modificaciones sobre sus anexos.

Ataques a la confidencialidad. Este tipo de amenaza se lleva a cabo cuando el

atacante es capaz de interceptar los mensajes y de obtener, total o parcialmente,

la información que transportan.

Hombre en el medio o ‘man- in-the-middle’. Los ataques ‘man-inthe- middle’

consisten en que un atacante se sitúa entre dos interlocutores, e intercepta siendo

capaz de responder, a los mensajes que éstos se están intercambiando dando la

sensación a los interlocutores de que realmente, se están comunicando entre sí

cuando realmente lo están haciendo con el atacante.

Spoofing. El spoofing es un ataque complejo que explota las relaciones de

confianza establecidas entre los interlocutores. El atacante es capaz de suplantar

la identidad de una de las partes de una relación de confianza con el objeto,

normalmente, de comprometer la seguridad de la parte destinataria. En este

ataque, la parte destinataria siempre pensará que está dialogando con un

interlocutor de confianza. Normalmente, esta técnica se utiliza como medio para

realizar otros tipos de ataques como el ‘forjado’ de los mensajes. Se deben aplicar

técnicas robustas de autenticación para poder hacer frente a estos tipos de

ataques.

Denegación de servicio. Los ataques de denegación de servicio, comúnmente

conocidos con el acrónimo DoS (Denial-of-Service), se centra en prevenir que los

usuarios legítimos de un servicio sean capaces de hacer uso de él. Estos ataques

suelen estar destinados a explotar el servicio de seguridad básico conocido como

la disponibilidad. Los ataques de DoS pueden interrumpir las operaciones llevadas

a cabo por un servicio, consiguiendo su desconexión efectiva respecto del resto

del mundo. Los ataques por DoS pueden tomar varias formas, desde un intruso

interno, con acceso físico a la máquina que proporciona el servicio, que

desconecta un cable o para cierto proceso, a la realización de un sencillo ‘script’

que realice peticiones masivas hacia un mismo servicio, de forma que es capaz de

saturarlo impidiendo que ofrezca un servicio de calidad, al resto de los usuarios (o

incluso consiguiendo llegar a pararlo).

Ataque de repetición. En este caso un atacante es capaz de interceptar un

mensaje válido pudiendo re-enviarlo más tarde todas las veces que quiera al

servicio para el que era destinatario. Para poder solventar este problema se deben

utilizar técnicas de autenticación apropiadas conjuntamente con técnicas de

sellado de tiempos y números de secuencia.

Para solucionar estos problemas, se crean una pila de especificación que define una serie

de extensiones para el protocolo SOAP, que permite el intercambio entre el cliente y el

servidor de tokens de seguridad., con mecanismos de encriptación y firmado entre otras

cosas.

3. Pila de especificaciones para la seguridad de los WS

Figura 64. Especificaciones de Seguridad.

3.1 WS-Policy

Así como el nombre lo implica, WS-Policy permite a una organización que expone un Web

Service especificar una política para ese servicio. La política detalla que capacidades y

limitaciones presenta un servicio en materia de seguridad, por ejemplo, qué tipo de

algoritmo cifrado soporta y que parámetros necesitan para la encriptación. La política

puede ser utilizada para descubrir de un servicio, sus capacidades y limitaciones en

materia de seguridad, similar a cómo WSDL se utiliza para describir las características

generales de un servicio [34].

3.2 WS-Trust

Describe como las relaciones de confianza son creadas, direct o brokered. En el caso de

los Web Services y la seguridad, la confianza significa que se puede confiar en relación

con la autenticidad y la autorización de una entidad, si un tercero en que puedes confiar

da fe de ello. Ejemplos comunes de confianza son los modelos de PKI (modelo de

confianza jerárquica) y PGP (un modelo de red de confianza). El modelo WS-Trust

también permite que la delegación y la suplantación se lleven a cabo. Esto significa que

un mensaje SOAP no es enviado directamente al usuario final, sino que un programa de

software actúa en su nombre, un token de seguridad que contiene información se retorna

de vuelta al usuario final insertado en el mensaje. [34].

3.3 WS-SecureConversation

Define un conjunto de extensiones para permitir el establecimiento, compartición y

derivación de contextos y claves de seguridad entre los interlocutores de una

comunicación. Mientras que la especificación WS-Security se centra en un modelo de

autenticación de mensajes, que aunque resultará muy útil en muchos casos se encuentra

sujeto a múltiples formas de ataque, WS-SecureConversation introduce el concepto de

seguridad contextual y describe como utilizarlo [23].

3.4 WS-Federation

Debido a que diferentes partes implicadas en el consumo y la prestación de un servicio,

pueden utilizar diferentes tecnologías de seguridad, por ejemplo, una de las partes podrá

utilizar Kerberos y otros Certificados X.509, puede ser necesario traducir los datos

relativos a la seguridad entre las partes implicadas. WS-Federation es la especificación

que describe la forma en que la intermediación, entre las partes debe llevarse a cabo. La

especificación funciona en una capa por encima de WS-Policy y WS-Trust [34].

3.5 WS-Authorization

El principal objetivo de esta especificación es cómo definir y gestionar las políticas de

control de acceso a los servicios Web [23].

3.6 WS-Privacy

La información relativa a un usuario final y el envío de esta información con el mensaje,

es ruteada entre diferentes nodos, puede esto tener un impacto en el usuario final y la

protección de la intimidad, en función de que tan delicada sea la información manejada.

La especificación de WS-Privacy hace que sea posible para un proveedor de servicios

expresar su política en relación con cuestiones de privacidad, y para el prestador de

servicios exigir que las solicitudes especificadas del remitente se adhieran a esa política.

Para lograr este objetivo, el WS-Privacy a su vez, hace uso de una combinación de otras

especificaciones, incluyendo WS-Policy, WS-Security y WS-Trust [34].

3.7 WS-Security

En la base se encuentra la especificación WS-Security. Esta especificación es un

estándar según OASIS y proporciona Autentificación, integridad, confidencialidad y

opcionalmente no repudio a los mensajes SOAP intercambiados entre servicios Web. En

Abril de 2004 el estándar WS-Security 1.0 fue publicado por Oasis-Open. En 2006 fue

publicada la versión 1.1. WS-Security que especifica cómo adjuntar firma y cifrado de

información, así como fichas de seguridad para los mensajes SOAP.

El protocolo contiene especificaciones sobre cómo debe garantizarse la integridad y

seguridad en mensajería de Servicios Web. El protocolo WSS incluye detalles en el uso

de SAML y Kerberos, y formatos de certificado tales como X.509 [23].

3.7.1 WS-Security define esencialmente tres funcionalidades

1. La capacidad de persistir tokens en la cabecera SOAP. Los Tokens son las

credenciales que se utilizan para la identificación. Los tokens se añaden a la

cabecera del mensaje SOAP y ayuda a identificar al receptor sobre quien remite.

La cabecera es capaz de llevar varios tokens de seguridad, cada uno pertenece a

los diferentes receptores, que se distinguen por una URI asociado a un actor,

donde un actor sabe que token de seguridad utilizar. La creación, la caducidad y

la información relacionada para tokens también se almacena para ayudar a

distinguir los datos in validos de los datos válidos. WS-Security no define cómo

realizar la autenticación de estos tokens, pero proporciona un mecanismo para

que estos token pueden ser transportados en la cabecera SOAP; los receptores

puede hacer lo que quieran con los tokens. Agregando el uso de WS-Security no

es suficiente para garantizar las funcionalidades; las partes interesadas también

necesitan ponerse de acuerdo sobre los tokens de seguridad que van a ser

utilizados. La especificación permite para cualquier tipo de token, pero tres

variedades son las más comúnmente utilizadas según [24].

UserNameTokens. Estos token es una representación de un nombre de

usuario / contraseña combinación que podría ser utilizado para acceder a un

servicio web. La contraseña se define por una enumeración y pueden ser

enviadas a ser texto plano, cifrado.

Kerberos Tokens. Es un protocolo de autenticación de redes de

computadores, que permite a varios computadores en una red insegura

demostrar su identidad mutuamente de manera segura.

Certificado X.509 Tokens. Estos tokens es una representación de claves

públicas y privadas, que se utilizan de forma simétrica y asimétrica en

algoritmos de intercambio de claves. La información del Certificado se

transporta de un destino a otro a través de la cabecera de los mensajes SOAP.

2. La capacidad de firmar digitalmente los mensajes La Firma Digital XML es un

estándar que permite la inclusión de las firmas digitales utilizando una clave

privada, en los contenidos digitales, previendo integridad, autentificación,

autorización y no repudio en la cabecera del mensaje.

3. La capacidad de cifrar los mensajes XML Encription permite cifrar elementos

que deberán incluirse en los mensajes SOAP utilizando una clave pública

compartida. Al cifrar el mensaje, se asegura hasta cierto punto de que el

intermediario no puede leer el mensaje enviado. Cifrar el mensaje también ayuda a

proporcionar integridad en las transacciones que se realicen.

3.7.2 Tipos de Seguridad utilizando Token

Según [24] las especificaciones de WS-Security defines los siguientes tipos de Tokens de

seguridad:

Seguridad de Tokens sin Firmar

UserNameTokens.

Seguridad de Tokens con Firmas

X.509 certificates (binary).

UserNameTokens

Kerberos tickets (binary).

Tokens de Seguridad XML

Cualquier Token XML , como SAML.

Verificador / Firma

A continuación se muestra el Típico Dialogo de Seguridad XML sin auto validación de

Credenciales

Figura 65. Dialogo de Seguridad sin validación.

1. El Cliente Del Web Service realiza una petición de autentificación al manejador de

sesión de seguridad y autorización del servicio web.

2. El manejador de sesión establece un Token de sesión.

3. El cliente trata de consumir el Web Service incluyendo en dicha petición el token

de sesión.

4. El WS antes de dar respuesta al cliente trata de verificar que clase de autorización

tiene el token de sesión de dicho cliente, realizando una petición de validación de

sesión de token al manejador de sesión.

5. El manejador de sesión verifica el token enviando una respuesta al Web Service.

6. Por último el WS envía una respuesta al cliente [24].

A continuación se muestra el Típico Dialogo de Seguridad XML con auto validación de

Credenciales

Figura 66. Dialogo de Seguridad con auto validación.

1. El cliente realiza una petición de autentificación a la autoridad de seguridad del

WS.

2. La autoridad de seguridad devuelve la respuesta de autentificación utilizando

credenciales / Token

3. El cliente realiza una petición al WS incluyendo la seguridad a través de

Credenciales / Token.

4. El servicio web validad las credenciales y determina la autentificación del cliente

enviando una respuesta al cliente [24].

5. servicio web validad las credenciales y determina la autentificación manejador de

sesión establece un Token de sesión.

3.7.3 UserName Token Usando WS-Security en la Cabecera SOAP

Figura 67. Mensaje Soap con WS-Security.

Este ejemplo muestra un mensaje SOAP con un WS-Security en la cabecera que

contiene un nombre de usuario / contraseña Token. El token en este ejemplo es para el

usuario jthelin, y la codificación usa base64. Para confirmar que estas credenciales son

válidas, el receptor de este mensaje debe consultar la autoridad de seguridad para el

usuario para confirmar si la contraseña adjunta es correcta para este usuario.

3.7.4 Certificado Binario X509 usando WS-Security en la cabecera SOAP

Figura 68. Mensaje Soap Utilizando Certificados X509.

Este ejemplo muestra un certificado digital X.509 siendo incluido en la cabecera SOAP

usando WS-Security como un Token binario.

El Token muestra que ha sido firmado, de conformidad con la Firma Digital XML de la

especificación [XML Signature], y el uso de la información clave del certificado X.509 para

calcular el hash de la firma [24].

ANEXO II

PORTABILIDAD EN J2EE Y .NET

1. Plataforma .NET

1.1 CLR

La plataforma .NET, desarrollada por Microsoft, ofrece al igual que otras propuestas como

java la ventaja de que la programación, no se realice para un determinado procesador o

sistema operativo como anteriormente se hacía, si no por el contrario Microsoft adopta

esta idea en .NET creando CLR, que viene siendo el equivalente en .NET del JRE de

Java utilizado por J2EE.

Common Language Runtime (CLR) asume la responsabilidad de ejecutar la

aplicación. CLR garantiza que se cumplan todas las dependencias de la aplicación,

es responsable de los servicios en tiempo de ejecución como la integración de

lenguajes, la aplicación de seguridad y la administración de la memoria, los procesos y los

subprocesos. Además, juega un importante papel en tiempo de desarrollo. [28].

1.1.1 Característica del CLR

Según [28], las características más notables son las siguientes:

Modelo de programación consistente

A todos los servicios ofrecidos por el CLR se accede por un modelo de

programación orientado a objetos. Esto marca una diferencia con respecto al modo

de acceso a servicios ofrecidos por algunos sistemas operativos, como por

ejemplo los de la familia Windows, en los que a algunos servicios se accede a

través de llamadas globales definidas en bibliotecas DLL's.

Modelo de programación sencillo

Con el CLR desaparecen elementos complejos de manejar incluidos en los

sistemas operativos actuales, como por ejemplo el registro de Windows. No se

trata de que la plataforma abstraiga al programador de estos conceptos, sino que

simplemente dejen de existir ya que no tienen sentido.

Eliminación del problema de las DLL

Las DLL's, es un problema que radica en que al sustituirse bibliotecas antiguas por

nuevas, puede que aplicaciones antiguas que fueron diseñadas para ser

ejecutadas con las bibliotecas antiguas, dejen de funcionar correctamente o

simplemente dejen de funcionar. En la plataforma .NET, las versiones nuevas de

las bibliotecas DLL pueden coexistir con las versiones antiguas. Esto facilita

mucho la tarea de instalación y desinstalación de software.

Ejecución multiplataforma

El CLR actúa como una máquina virtual, encargándose de ejecutar las

aplicaciones diseñadas para la plataforma .NET. Es decir, cualquier plataforma

para la que exista una versión del CLR, podrá ejecutar una aplicación diseñada en

la plataforma .NET. Microsoft solamente ha implementado versiones del CLR para

Windows 98, 2000, XP, Vista y otras versiones Windows. También hay que decir

que estas versiones del CLR no tienen porqué ser ejecutadas en plataformas

hardware x86, debido a la existencia de versiones de Windows para plataformas

AMD, o AMD64. Existen versiones del CLR que pueden ser ejecutadas en otros

sistemas operativos, como por ejemplo Linux, gracias al proyecto Mono.

Integración de lenguajes

Es posible programar en cualquier lenguaje para el que exista un compilador que

genere código para la plataforma .NET, como si se estuviera programando en el

lenguaje nativo de la plataforma .NET. Microsoft, ha desarrollado el lenguaje C#

que genera código de este tipo, así como versiones de sus compiladores para

Visual Basic (Visual Basic .NET), C++ o JScript (JScript .NET).

Recolección de basura

El CLR incluye un recolector de basura, que evita que el programador tenga que

tener en cuenta cuándo es necesario liberar la memoria de los objetos que ya no

se utilizan. Este recolector es una aplicación que se activa cuando se crea un

nuevo objeto y no exista memoria para crearlo. El recolector busca en la memoria

dinámica de la aplicación por aquellos objetos que no pueden ser accedidos a

través del código de la aplicación, y los elimina, liberando la memoria necesaria

para crear el nuevo objeto. Gracias al recolector de basura, se evitan errores muy

típicos como el acceso a objetos que ya no existen, eliminación de objetos ya

borrados o agotamiento de memoria por no eliminar los objetos innecesarios.

Seguridad de tipos

El CLR facilita la detección de errores de programación difíciles de detectar,

comprobando que toda conversión o casting de tipos que se realice durante la

ejecución de una aplicación .NET se haga de modo que ambos tipos sean

compatibles.

Aislamiento de procesos

El CLR asegura que desde cualquier proceso no se pueda acceder a código o

datos pertenecientes a otro, lo que garantiza la seguridad en las aplicaciones y

evita errores comunes de acceso a datos de otro proceso.

Soporte Multihilo

El CLR es capaz de trabajar con aplicaciones divididas en múltiples hilos de

ejecución, que pueden ir evolucionando por separado, en paralelo o

intercalándose, según el número de procesadores de la máquina donde se

ejecute. Las aplicaciones pueden lanzar nuevos hilos, destruirlos, suspenderlos

por un tiempo, y demás operaciones útiles para sincronizar los diferentes hilos

[28].

1.1.2 Funcionamiento del CLR

La herramienta de desarrollo (VISUAL STUDIO) compila el código fuente de cualquiera de

los lenguajes soportados por .NET en un código intermedio, el MSIL (Microsoft

Intermediate Lenguaje), similar al BYTECODE de Java. Para generarlo, el compilador se

basa en la especificación CLS (Common Language Specification) que determina las

reglas necesarias para crear el código MSIL compatible con el CLR. [28].

1.2 MSIL (Lenguaje Intermedio de Microsoft)

MSIL ha sido creado por Microsoft, después de consultar a numerosos especialistas en

compiladores y lenguajes. Se trata de un lenguaje de un nivel de abstracción más elevado

que los lenguajes de código máquina de las CPUs existentes, ya que permite por ejemplo

trabajar directamente con objetos (crearlos, destruirlos, inicializarlos, etc) así como tablas

y excepciones (lanzarlas, capturarlas y manejarlas). El compilador de C#, desarrollado por

Microsoft, genera código fuente MSIL, así como que Microsoft ha desarrollado

extensiones de sus compiladores de Visual Basic y C++ que generan también código

MSIL. Pero no son éstos los únicos lenguajes que generan código MSIL, sino que son

bastantes los lenguajes que han optado por desarrollar una extensión que genere código

MSIL para la plataforma .NET, como por ejemplo Fortran, Haskell, Java, Pascal, Perl,

Python, o Smalltalk. Como se puede observar la oferta es bastante amplia, ya que debido

a la arquitectura de la plataforma .NET, se puede programar aplicaciones en cualquiera

de estos lenguajes, accediendo a todos los servicios ofrecidos por el CLR [28].

Figura 69. Ejemplo del Lenguaje MSIL.

1.2.1 Compilar en lenguaje intermedio de Microsoft (MSIL)

Cuando se compila a código administrado, el compilador convierte el código fuente en

Lengua intermedio de Microsoft (MSIL), que es un conjunto de instrucciones

independiente de la CPU que se pueden convertir de forma eficaz en código nativo. MSIL

incluye instrucciones para cargar, almacenar, inicializar y llamar a métodos en los objetos,

así como instrucciones para operaciones lógicas y aritméticas, flujo de control, acceso

directo a la memoria, control de excepciones y otras operaciones.

Cuando el compilador produce MSIL, también genera metadatos. Los metadatos

describen los tipos que aparecen en el código, incluidas las definiciones de los tipos, las

firmas de los miembros de tipos, los miembros a los que se hace referencia en el código y

otros datos que el motor en tiempo de ejecución utiliza en tiempo de ejecución. El

lenguaje intermedio de Microsoft (MSIL) y los metadatos se incluyen en un archivo

ejecutable portable (PE), que se basa y extiende el PE de Microsoft publicado y el formato

Common Object File Format (COFF) utilizado tradicionalmente para contenido ejecutable.

Este formato de archivo, que contiene código MSIL así como metadatos, permite al

sistema operativo reconocer imágenes de Common Language Runtime. La presencia de

metadatos junto con el Lenguaje intermedio de Microsoft (MSIL) permite crear códigos

autodescriptivos, con lo cual las bibliotecas de tipos y el Lenguaje de definición de

interfaces (IDL) son innecesarios. El motor en tiempo de ejecución localiza y extrae los

metadatos del archivo cuando son necesarios durante la ejecución [28].

1.2.2 Principal ventaja del MSIL

La principal ventaja del MSIL es que facilita la ejecución multiplataforma y la integración

entre lenguajes al ser independiente de la CPU y proporcionar un formato común para el

código máquina generado por todos los compiladores que generen código para .NET [28].

1.2.3 Compilar MSIL a código nativo

Según [28], para poder ejecutar el lenguaje intermedio de Microsoft (MSIL), primero se

debe convertir éste, mediante un compilador Just-In-Time (JIT) o jitter, es el que genera el

código máquina real que se ejecuta en la plataforma del cliente. Common Language

Runtime proporciona un compilador JIT para cada arquitectura de CPU compatible. De

esta forma se consigue con .NET independencia de la plataforma de hardware. La

compilación JIT la realiza el CLR a medida que el programa invoca métodos. El código

ejecutable obtenido se almacena en la memoria caché del computador, siendo

recompilado de nuevo sólo en el caso de producirse algún cambio en el código fuente.

Este jitter se distribuye en tres versiones:

jitter normal: Es el que se suele usar por defecto, y sólo compila el código MSIL a

código nativo a medida que va siendo necesario, pues así se ahorra tiempo y

memoria al evitarse tener que compilar innecesariamente código que nunca se

ejecute. Para conseguir esto, el cargador de clases del CLR sustituye inicialmente

las llamadas a métodos de las nuevas clases que vaya cargando por llamadas a

funciones auxiliares (stubs) que se encarguen de compilar el verdadero código del

método. Una vez compilado, la llamada al stub es sustituida por una llamada

directa al código ya compilado, con lo que posteriores llamadas al mismo no

necesitarán compilación [28].

jitter económico: Funciona de forma similar al jitter normal, solo que no realiza

ninguna optimización de código al compilar sino que traduce cada instrucción

MSIL, por su equivalente en el código máquina sobre la que se ejecute. Esta

especialmente pensado para ser usado en dispositivos empotrados que dispongan

de poca potencia de CPU y poca memoria, pues aunque genere código más

ineficiente es menor el tiempo y memoria que necesita para compilar. Es más,

para ahorrar memoria este jitter puede descargar código ya compilado que lleve

cierto tiempo sin ejecutarse y sustituirlo de nuevo por el stub apropiado. Por estas

razones, este es el jitter usado por defecto en Windows CE, sistema operativo que

se suele incluir en los dispositivos empotrados antes mencionados. Otra utilidad

del jitter económico es que facilita la adaptación de la plataforma .NET a nuevos

sistemas, porque es mucho más sencillo de implementar que el normal. De este

modo, gracias a él es posible desarrollar rápidamente una versión del CLR que

pueda ejecutar aplicaciones gestionadas aunque sea de una forma poco eficiente,

y una vez desarrollada es posible centrarse en desarrollar el jitter normal para

optimizar la ejecución de las mismas [28].

prejitter: Se distribuye como una aplicación en línea de comandos llamada

ngen.exe mediante la que es posible compilar completamente cualquier ejecutable

o librería (cualquier ensamblado en general) que contenga código gestionado y

convertirlo a código nativo, de modo que posteriores ejecuciones del mismo se

harán usando esta versión ya compilada y no se perderá tiempo en hacer la

compilación dinámica.

Como parte de la compilación MSIL en código nativo, el código debe pasar un proceso de

comprobación, a menos que el administrador haya establecido una directiva de seguridad

que permita al código omitir esta comprobación. En esta comprobación se examina el

MSIL y los metadatos para determinar si el código garantiza la seguridad de tipos, lo que

significa que el código sólo tiene acceso a aquellas ubicaciones de la memoria para las

que está autorizado. La seguridad de tipos ayuda a aislar los objetos entre sí y, por tanto,

ayuda a protegerlos contra daños involuntarios o maliciosos. Además, garantiza que las

restricciones de seguridad sobre el código se aplican con toda certeza. Por ejemplo, un

código no permite el acceso a los campos de un objeto si esta acción sobrecarga las

ubicaciones de memoria [28].

1.3 Common Language Specification (CLS)

El Common Language Specification (CLS) o Especificación del Lenguaje Común,

Determina las reglas necesarias para crear código MSIL compatible con el CLR. Es

un conjunto de reglas que han de seguir las definiciones de tipos que se hagan usando un

determinado lenguaje gestionado si se desea que sean accesibles desde cualquier otro

lenguaje gestionado. Obviamente, sólo es necesario seguir estas reglas en las

definiciones de tipos y miembros que sean accesibles externamente. Además, si no

importa la interoperabilidad entre lenguajes tampoco es necesario seguirlas. A

continuación se listan algunas de reglas significativas del CLS:

Los tipos de datos básicos admitidos son bool, char, byte, short, int, long, float,double, string y object.

Las tablas han de tener una o más dimensiones, y el número de dimensiones de

cada tabla ha de ser fijo. Además, han de indexarse empezando a contar desde 0.

Se pueden definir tipos abstractos y tipos sellados. Los tipos sellados no pueden

tener miembros abstractos.

Las excepciones han de derivar de System.Exception, los delegados de

System.Delegate, las enumeraciones de System.Enum, y los tipos por valor que

no sean enumeraciones de System.ValueType.

Los métodos de acceso a propiedades en que se traduzcan las definiciones

get/set de éstas han de llamarse de la forma get_X y set_X respectivamente,

donde X es el nombre de la propiedad; los de acceso a indizadores han de

traducirse en métodos get_Item y set_Item; y en el caso de los eventos, sus

definiciones add/remove han de traducirse en métodos add_X y remove_X.

En las definiciones de atributos sólo pueden usarse enumeraciones o datos de los

siguientes tipos: System.Type, string, char, bool, byte, short, int, long, float,double y object.

En un mismo ámbito no se pueden definir varios identificadores cuyos nombres

sólo difieran en la capitalización usada. De este modo se evitan problemas al

acceder a ellos usando lenguajes no sensibles a mayúsculas.

Las enumeraciones no pueden implementar interfaces, y todos sus campos han

de ser estáticos y del mismo tipo. El tipo de los campos de una enumeración sólo

puede ser uno de estos cuatro tipos básicos: byte, short, int o long [28].

1.4 Proyecto Mono

En [05], dice que Mono es el nombre de un proyecto de código abierto iniciado por Ximian

y actualmente impulsado por Novell (tras su adquisición de Ximian), para crear un grupo

de herramientas libres, basadas en GNU/Linux y compatibles con .NET según lo

especificado por el ECMA.

Mono proporciona las funciones necesarias para crear servicios web, esto incluye las

tecnologías XML, SOAP, ASP.NET, y Remoting así como el acceso a bases de datos, a

través ADO.NET, de tipo Oracle, MySQL, DB2, SQL Server, o Progress.

Mono posee importantes componentes útiles para desarrollar software:

Una máquina virtual de lenguaje común de infraestructura (CLI) que contiene un

cargador de clases, un compilador en tiempo de ejecución (JIT), y unas rutinas de

recolección de memoria.

Una biblioteca de clases que puede funcionar en cualquier lenguaje que funcione

en el CLR (Common Language Runtime).

Un compilador para el lenguaje C#, MonoBasic (la versión para mono de Visual

Basic), Java y Python.

El CLR y el Sistema de tipos común (CTS) permite que la aplicación y las

bibliotecas sean escritas en una amplia variedad de lenguajes diferentes que

compilen para byte code. Esto significa por ejemplo, que si defines una clase que

haga una manipulación algebraica en C#, esa clase puede ser reutilizada en

cualquier lenguaje que soporte el "CLI". Puede crear una clase en C#, una

subclase en C++ e instanciar esa clase en un programa en Eiffel.

Un sistema de objetos único, sistema de hilos, bibliotecas de clases y sistema

recolector de memoria pueden ser compartidos por todos estos lenguajes. [05].

2. Plataforma J2EE

2.1 JRE (Java Runtime Environment)

JRE es el acrónimo de Java Runtime Environment (entorno en tiempo de ejecución Java)

y se corresponde con un conjunto de utilidades y componentes que permite la ejecución

de programas java sobre todas las plataformas soportadas. El JRE está constituido por

una JVM (máquina virtual Java) que es el programa que interpreta el código Java y

además por las librerías de clases estándar que implementan el API de Java. Ambas JVM

y API deben ser consistentes entre sí, de ahí que sean distribuidas conjuntamente [05].

2.2 Máquina virtual de Java

(En inglés Java Virtual Machine, JVM) es un programa nativo, es decir, ejecutable en una

plataforma específica, capaz de interpretar y ejecutar instrucciones expresadas en

un código binario especial (el Java bytecode), el cual es generado por el compilador del

lenguaje Java. El código binario de Java no es un lenguaje de alto nivel, sino un

verdadero código máquina de bajo nivel, viable incluso como lenguaje de entrada para

un microprocesador físico. Como todas las piezas del rompecabezas Java, fue

desarrollado originalmente por Sun Microsystems. La JVM es una de las piezas

fundamentales de la plataforma Java. Básicamente se sitúa en un nivel superior al

Hardware del sistema, y este actúa como un puente que entiende tanto el bytecode, como

el sistema sobre el que se pretende ejecutar. Así, cuando se escribe una aplicación Java,

se hace pensando que será ejecutada en una máquina virtual Java en concreto, siendo

ésta la que en última instancia convierte de código bytecode a código nativo del

dispositivo final.

Un usuario sólo necesita el JRE para ejecutar las aplicaciones desarrolladas en lenguaje

Java, mientras que para desarrollar nuevas aplicaciones en dicho lenguaje es necesario

un entorno de desarrollo, denominado JDK, que además del JRE (mínimo imprescindible)

incluye, entre otros, un compilador para Java [27].

Figura 70. LP Sin Maquina Virtual.

Figura 71. LP Con Maquina Virtual.

2.3 Bytecode

El bytecode es un código intermedio más abstracto que el código máquina. Habitualmente

es tratado como un fichero binario que contiene un programa ejecutable similar a un

módulo objeto, que es un fichero binario producido por el compilador cuyo contenido es

el código objeto o código máquina .El bytecode recibe su nombre porque generalmente

cada código de operación tiene una longitud de un byte, si bien la longitud del código de

las instrucciones varía. Cada instrucción tiene un código de operación entre 0 y 255

seguido de parámetros tales como los registros o las direcciones de memoria. Esta sería

la descripción de un caso típico, si bien la especificación del bytecode depende

ampliamente del lenguaje. El bytecode generado de la compilación de un código fuente X

será el mismos que se genere por la compilación de ese mismo código fuente X en otro

sistema operativo o procesador

Figura 72. Ejemplo de bytecode.

2.4 Máquina Virtual vs Lenguajes Interpretados

El concepto de máquina virtual es antiguo. Fue usado por IBM en 1959 para describir uno

de los primeros sistemas operativos que existieron en la historia de la computación, el

VM. En 1970, el ambiente de programación de SmallTalk llevó la idea a un nuevo nivel y

construyó una máquina virtual para soportar abstracciones orientadas a objetos de alto

nivel, sobre las máquinas subyacentes.

Las máquinas virtuales tienen varias ventajas importantes. La primera es que presentan

un medio excelente para alcanzar la portabilidad. Otra de las ventajas importantes, es que

introduce otro nivel de abstracción y de protección, entre la computadora y el software que

ejecuta sobre ella. Esto cobra particular importancia en un ambiente donde el código que

se ejecuta proviene de algún lugar del mundo y es escrito por alguna "buena" persona

[26].

2.5 Lenguajes totalmente interpretados

Es posible decir que los lenguajes totalmente interpretados, como Tcl y JavaScript,

también poseen las cualidades de ser altamente portables y seguros, pero existe una

diferencia importante entre este tipo de lenguajes y los basados en una máquina virtual: la

eficiencia.

Un programa escrito en un lenguaje interpretado requiere de un programa auxiliar (el

intérprete), que traduce los comandos de los programas según sea necesario.

Para ejecutar un programa escrito en un lenguaje completamente interpretado, el

intérprete debe realizar el análisis léxico y sintáctico en el momento de estar ejecutando el

programa, lo que provoca una sobrecarga muy considerable en la ejecución del mismo

[26].

2.6 Lenguajes compilados a código intermedio

Los lenguajes basados en una máquina virtual, comúnmente son más rápidos que los

totalmente interpretados, debido a que utilizan una arquitectura de código intermedio. La

idea es dividir la tarea de ejecutar un programa en dos partes. En la primera, se realiza el

análisis léxico y sintáctico del programa fuente, para generar el programa en instrucciones

del procesador virtual (código intermedio) y en el segundo paso, se itera sobre el código

intermedio para obtener la ejecución final del programa.

Los lenguajes compilados de código intermedio, pueden llegar a ser un orden de

magnitud más rápido que los lenguajes completamente interpretados [26].

2.7 La plataforma Java (Sistema en tiempo de ejecución)

Sun utiliza el término "Máquina Virtual Java", para referirse a la especificación abstracta

de una máquina de software para ejecutar programas Java. La especificación de esta

máquina virtual, define elementos como el formato de los archivos de clases de Java

(.class), así como la semántica de cada una de las instrucciones que componen el

conjunto de instrucciones de la máquina virtual. A las implantaciones de esta

especificación se les conocen como "Sistemas en Tiempo de Ejecución Java". Ejemplos

de Sistemas de tiempo de ejecución son el Navegador de Nestcape, el Explorador de

Microsoft y el programa Java (incluido en el JDK). Un sistema de tiempo de ejecución

incluye típicamente:

Motor de ejecución. El procesador virtual que se encarga de ejecutar el código

(bytecode), generado por algún compilador de Java o por algún ensamblador del

procesador virtual Java.

Manejador de memoria. Encargado de obtener memoria para las nuevas

instancias de objetos, arreglos, etcétera, y realizar tareas de recolección de

basura.

Manejador de errores y excepciones. Encargado de generar, lanzar y atrapar

excepciones.

Soporte de métodos nativos. Encargado de llamar métodos de C++ o funciones de

C, desde métodos Java y viceversa.

Interfaz multihilos. Encargada de proporcionar el soporte para hilos y monitores.

Cargador de clases. Su función es cargar dinámicamente las clases Java a partir

de los archivos de clase (.class).

Administrador de seguridad. Se encarga de asegurar que las clases cargadas

sean seguras, así como controlar el acceso a los recursos del sistema.

Adicionalmente, existe un conjunto de clases Java estándar, fuertemente ligadas a la

implantación de cada JVM en particular. Ejemplos de estos son las clases encargadas de

funciones, como los accesos a los recursos de la red, manejar el sistema de ventanas, los

hilos y el sistema de archivos local. Todos estos elementos en conjunto actúan como una

interfaz de alto nivel, para acceder a los recursos del sistema operativo. Es esta interfaz la

clave de la portabilidad de los programas Java, debido a que independientemente del

hardware o sistema operativo sobre el que se esté trabajando, la máquina virtual Java

oculta todas estas diferencias [26].

A continuación se describe con mayor detalle algunos de estos elementos

2.8 Motor de ejecución

Es la entidad de hardware o software, que ejecuta las instrucciones contenidas en los

códigos de operación (bytecodes) que implementan los métodos Java. En las versiones

iníciales de Sun, el motor de ejecución consistía de un intérprete de códigos de operación.

En las versiones más avanzadas de nuestros días, se utiliza la tecnología de "generación

de código justo en el momento" (Just-in-Time code generation), en dónde las

instrucciones que implementan a los métodos, se convierten en código nativo que se

ejecuta directamente en la máquina sobre la que se subyace. El código nativo se genera

únicamente la primera vez que se ejecuta el código de operación Java, por lo que se logra

un aumento considerable en el rendimiento de los programas [26].

2.9 El conjunto de instrucciones del procesador virtual

Muchas de las instrucciones del procesador virtual Java, son muy similares a las que se

pueden encontrar para los procesadores comunes y corrientes, como los Intel, es decir,

incluyen los grupos de instrucciones típicos como los aritméticos, los de control de flujo,

de acceso a memoria, a la pila, etcétera.

Una de las características más significativas del conjunto de instrucciones del procesador

virtual Java, es que están basadas en la pila y utilizan "posiciones de memoria"

numeradas, en lugar de registros. Esto es hasta cierto punto lógico, debido a que la

máquina virtual está pensada para correr sobre sistemas con procesadores

sustancialmente diferentes. Es difícil hacer suposiciones sobre el número o tipo de

registros que estos pudiesen tener [26].

2.10 El verificador de Java

Una de las principales razones para utilizar una máquina virtual, es agregar elementos de

seguridad a un sistema, por lo que si un intérprete falla o se comporta de manera

aleatoria, debido a código mal formado, es un problema muy serio. La solución trivial a

este problema sería incluir código encargado de capturar errores y verificar que el código

sea correcto.

Los diseñadores de Java tomaron otro camino. Cuando estaban diseñando el conjunto de

instrucciones para la máquina virtual de Java, tenían dos metas en mente. La primera era

que el conjunto de instrucciones fuera similar a las instrucciones que se pueden encontrar

en los procesadores reales. La segunda era construir un conjunto de instrucciones que

fuera fácilmente verificable.

En Java, justo después de que se obtiene una clase del sistema de archivos o de Internet,

la máquina virtual puede ejecutar un verificador que se encargue precisamente de

constatar que la estructura del archivo de clase es correcta. El verificador se asegura que

el archivo tenga el número mágico (0xCAFEBABE) y que todos los registros que contiene

el archivo tengan la longitud correcta, pero aún más importante, comprueba que todos los

códigos de operación sean seguros de ejecutar. Es importante notar que Java no necesita

que el verificador se ejecute sobre el archivo de clase, sino que es activado por el sistema

en tiempo de ejecución y sólo sobre clases que el mismo sistema decida. Por lo común,

las clases verificadas son las provenientes de Internet [26].

2.11 Administrador de Memoria

Java utiliza un modelo de memoria conocido como "administración automática del

almacenamiento" (automatic storage management), en el que el sistema en tiempo de

ejecución de Java mantiene un seguimiento de los objetos. En el momento que no están

siendo referenciados por alguien, automáticamente se libera la memoria asociada con

ellos [26].

2.13 Funcionamiento: Interpretación y compilación en Java

El código fuente escrito con cualquier editor se compila generando el ByteCode. El

ByteCode corresponde al 80% de las instrucciones de la aplicación. Ese mismo código es

el que se puede ejecutar sobre cualquier plataforma. Para ello hace falta el runtime, que sí

es completamente dependiente de la máquina y del sistema operativo que interpreta

dinámicamente el ByteCode y añade el 20% de instrucciones que faltaban para su

ejecución.

Hoy en día la situación se acerca mucho a la de los programas compilados, sobre todo en

lo que a la rapidez en la ejecución del código se refiere. Las siguientes graficas se

muestran cómo actúa el sistema runtime en los diversos casos que hasta ahora pueden

darse y sobre el último lanzamiento que hace SUN, el HotSpot que promete interpretar

los ByteCodes de forma más rápida. [25].

2.13.1 Compilador tradicional

La imagen muestra las acciones correspondientes a un compilador tradicional. El

compilador traslada las sentencias escritas en lenguaje de alto-nivel a múltiples

instrucciones, que luego son enlazadas junto con el resultado de múltiples compilaciones

previas que han dado origen a librerías, y juntando todo ello, es cuando genera un

programa ejecutable [25].

Figura 73. Compilador Tradicional.

2.13.2 Actuación de un Intérprete

Figura 74. Actuación de un Intérprete.

La imagen muestra la forma de actuación de un intérprete. Básicamente es un enorme

bucle, en el cual se va leyendo o recogiendo cada una de las instrucciones del programa

fuente que se desea ejecutar, se analiza, se parte en trozos y se ejecuta. Luego se va a

recoger la siguiente instrucción que se debe interpretar y se continúa con este proceso,

hasta que se terminan las instrucciones o hasta que entre las instrucciones, hay alguna

que contiene la orden de detener la ejecución de las instrucciones que componen el

programa fuente [25].

2.13.3 Intérprete de Bytecodes

Figura 75. Interprete de Bytecodes.

La imagen muestra un tipo de intérprete más eficiente que el anterior, el intérprete deByteCodes, que fue popularizado hace más de veinte años por la Universidad de

California al crear el UCSD Pascal. En este caso, el intérprete trabaja sobre instrucciones

que ya han sido trasladadas a un código intermedio en un paso anterior. Así, aunque se

ejecute en un bucle, se elimina la necesidad de analizar cada una de las instrucciones

que componen el programa fuente, porque ya lo han sido en el paso previo. Este es el

sistema que Java antes utilizaba, y la Máquina Virtual Java es un ejemplo de este tipo de

intérprete. No obstante, sigue siendo lento, aunque se obtenga un código independiente

de plataforma muy compacto, que puede ser ejecutado en cualquier computadora que

disponga de una máquina virtual capaz de interpretar los ByteCodes trasladados [25].

2.13.4 Compiladores Just-In-Time

Figura 76. Just-In-Time.

Un paso adelante en el rendimiento del código Java lo han representado los

compiladores Just-In-Time, que compilan el código convirtiéndolo a código máquina

antes de ejecutarlo. Es decir, un compilador JIT va trasladando los ByteCodes al código

máquina de la plataforma según los va leyendo, realizando un cierto grado de

optimización. El resultado es que cuando el programa se ejecute, habrá partes que no se

ejecuten y que no serán compiladas, y el compilador JIT no perderá el tiempo en optimizar

código que nunca se va a ejecutar. No obstante, los compiladores JIT no pueden realizar

demasiadas optimizaciones, ya que hay código que ellos no ven, así que aunque siempre

son capaces de optimizar la parte de código de inicialización de un programa, hay otras

partes que deben ser optimizadas, según se van cargando, con lo cual, hay una cierta

cantidad de tiempo que inevitablemente ha de perderse [25].

2.13.5 HotSpot

Lo último en que trabaja Sun es HotSpot, una herramienta que incluye un compilador

dinámico y una máquina virtual para interpretar los Bytecodes, tal como se muestra en la

figura 73. Cuando se cargan los Bytecodes producidos por el compilador por primera vez,

éstos son interpretados en la máquina virtual. Cuando ya están en ejecución, el profiler

mantiene información sobre el rendimiento y selecciona el método sobre el que se va a

realizar la compilación. Los métodos ya compilados se almacenan en un caché en código

máquina nativo. Cuando un método es invocado, esta versión en código máquina nativo

es la que se utiliza, en caso de que exista; en caso contrario, los ByteCodes son

reinterpretados. La función control que muestra el diagrama es como un salto indirecto a

través de la memoria que apunta tanto al código máquina como al interpretado, aunque

Sun no ha proporcionado muchos detalles sobre este extremo [25].

Figura 77. HotSpot.

Figura 78. Desde la versión NetBeans 5.5 incorpora JMV HotSpot.

ANEXO III

DESARROLLO DEL PROTOTIPO DE SERVICIO WEB EN AMBAS PLATAFORMAS

Los servicios Web Realizado tanto para J2EE como para .NET, son en lo posible iguales

en cuanto a funcionalidades respecta. El prototipo consiste en 4 aplicaciones de bancos

para realizar giros electrónicos; cuya función es enviar dinero de una cuenta a otra

cuenta sea del mismo banco o de otros bancos. Dos de estos bancos se construyeron en

J2EE y los otros 2 en .NET. Se utilizó dos BD una para cada plataforma y en cada una se

realizan 2 tablas que representan bancos diferentes por lo que entre ella no hay ninguna

relación.

Servicio Web en la plataforma .NET

Especificaciones

El servicio Web en la plataforma .NET se construyó utilizando una versión de prueba o

preview de visual Studio 2008 que se puede descargar de [12].

Creando la Base de Datos

A continuación se muestra las tablas que se crearon en Access con el nombre de

bancoA, bancoB respectivamente:

Tabla 45. Creando BD Paso 1.

Los tipos de datos para cada campo son los siguientes


La base se llamó banconet y se guardó en C: \banconet.mdb. Se asignaron algunos

valores utilizando Access a las tablas bancoA y bancoB:



Creando el Servicio Web

Se abrió el VS.

Se creó un nuevo proyecto como se mostró en (4.3.5.2)

Se escogió el Framework 3.5.

Se le asignó el nombre de SERVIBANCO_A_B y se guardó en la siguiente

dirección C:\Inetpub\wwwroot. El cual es lugar donde se alojan los proyectos Web

cuando se trabaja con el servidor IIS.

Posteriormente se generó un método por defecto como en (4.3.5.3) el cual se

modifico de la siguiente forma.

Imports System.WebImports System.Web.ServicesImports System.Web.Services.ProtocolsImports System.Data.OleDbImports System.Data

' To allow this Web Service to be called from script, using ASP.NET AJAX,uncomment the following line.' <System.Web.Script.Services.ScriptService()> _<WebService(Namespace:="http://tempuri.org/")> _<WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _Public Class Service

Inherits System.Web.Services.WebService

<WebMethod()> _Public Function LLEGA_GIRO(ByVal nombre_de_banco As String, ByVal

num_de_cuenta As Integer, ByVal giro As Integer) As StringDim conexion As OleDbConnectionDim comando As OleDbCommandDim consulta As StringDim datos_de_consulta As OleDbDataReader

Tryconexion = New

OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; " & "DataSource=C:\banconet.mdb;")

conexion.Open()consulta = "SELECT deposito FROM " & nombre_de_banco & "

WHERE num_cuenta = " & num_de_cuenta

comando = New OleDbCommand(consulta, conexion)datos_de_consulta = comando.ExecuteReaderDim dinero_total As IntegerDim ok As String = "nada"While datos_de_consulta.Read

ok = "ok"dinero_total = datos_de_consulta.GetInt32(0)

End Whiledinero_total = dinero_total + giro

consulta = "UPDATE " & nombre_de_banco & " SET deposito = " &dinero_total & " WHERE num_cuenta = " & num_de_cuenta

comando = New OleDbCommand(consulta, conexion)''comando.ExecuteReader()

comando.ExecuteNonQuery()

http://tempuri.org/

conexion.Close()Return ok

Catch ex As ExceptionReturn "nada" ''ex.ToString

End Try

End Function

Entran tres valores como parámetro

Nombre_de_banco: el cual es un tipo String y le dice al método hacia qué

banco se dirige el giro,

Num_de_cuenta: Después de conocer el banco hacia donde se va a

realizar el giro es necesario conocer el número de la cuenta. Esta variable

es de tipo entero.

Giro: que es una variable tipo entero, el cual trae el valor del giro

Las siguiente variables que se crearon en el método, son para realizar la conexión

ejecutar, la conexión un String para escribir el SQL de la consulta y objeto tipo

OleDbDataReader para guardar los datos devuelto y poder manipularlos de

acuerdo como se necesiten.

Dentro del try se coloca la conexión a la base de dato, se abre la BD y se prepara

y se ejecuta una consulta utilizando OleDbCommand y ExecuteReader.

Si no se encuentra en la base de dato el usuario se genera un error devolviendo

un String “nada” en el método del Web Services a través del Catch.

Lo que hace la consulta es que si encuentra el usuario seleccione el depósito para

sumar nuevo depósito y antes de realizar el nuevo depósito es necesario saber

cuánto dinero tiene actualmente se logra a través del While.

Por último se suma el nuevo monto y se realiza una consulta de actualización para

establecer el nuevo monto.

Se creó otro método en el servicio Web para realizar el retiro del dinero

<WebMethod()> _Public Function RETIRO_DINERO(ByVal nombre_de_banco As String, ByVal

num_de_cuenta As Integer, ByVal contrasena As Integer, ByVal dinero AsInteger) As String

Dim conexion As OleDbConnectionDim comando As OleDbCommandTry

conexion = NewOleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; " & "DataSource=C:\banconet.mdb;")

conexion.Open()Dim consulta As String = "SELECT deposito FROM " &

nombre_de_banco & " WHERE num_cuenta = " & num_de_cuenta & "AND clave = "& contrasena

comando = New OleDbCommand(consulta, conexion)

Dim datos_de_consulta As OleDbDataReaderdatos_de_consulta = comando.ExecuteReader

Dim dinero_total As IntegerWhile datos_de_consulta.Read

dinero_total = datos_de_consulta.GetInt32(0)

End Whiledinero_total = dinero_total - dineroIf dinero_total >= 0 Then

consulta = "UPDATE " & nombre_de_banco & " SET deposito =" & dinero_total & " WHERE num_cuenta = " & num_de_cuenta

comando = New OleDbCommand(consulta, conexion)comando.ExecuteReader()conexion.Close()Return "ok"

End IfReturn "nada"

Catch ex As ExceptionReturn "nada"

End Try

End Function

Entran cuatro valores como parámetro:

nombre_de_banco: nombre del banco en el cual hay una cuenta a la cual se le

pretende realizar un retiro de dinero. Es de tipo String.

Num_de_cuenta: es la cuenta de algún usuario que se le será realizado un

retiro de dinero. Es de tipo entero.

Contrasena: es la clave del usuario al cual le pertenece la cuenta y es de tipo

entero. Se utiliza solo cuando se va a realizar un retiro.

Dinero: es el monto o la cantidad que se retira de la cuenta. Es de tipo entero.

Se dimensionan variables conexión, comando para realizar una conexión y

preparar una consulta.

Se ejecuta la consulta a través de un comando ExecuteReader. los datos

generados se guardan en la variable datos_de_consulta.

Se manipula datos_de_consulta a través de un While, para a si obtener el dinero

que tiene el usuario actualmente en la cuenta.

Luego a través de una operación matemática y un If; se sabe si esa cuenta tiene

el monto o cantidad de dinero suficiente para llevar a cabo la transacción

Si tiene el dinero suficiente para realizar un giro de dinero, de acuerdo al valor que

entro como parámetro “dinero”; se procede a realizar una UPDATE para actualizar

el nuevo monto que queda en la cuenta.

Si no se tiene dinero suficiente para realizar el giro, se devuelve un String con

“nada” a través del End If.

Si la cuenta no existe o la contraseña no concuerda, se produce un error en el try

y retorna un String “nada” a través del Catch.

Si la transacción se lleva de manera satisfactoria se devuelve un String “OK”

Luego se procede a ejecutar

Figura 79. Depuración en Visual Studio.

Se prueba el método

Figura 80. Probando el WS en .NET.

Se digitan los respectivos valores

Figura 81. Digitando Valores en .Net.

Por último se le da click en el botón Invocar y devuelve el siguiente mensaje Soap

Figura 82. Resultado Devuelto en .NET.

Iniciando el IIS

Para iniciar el IIS se abre panel de control / rendimiento y mantenimiento / herramientas

administrativas / Servicios de Internet Information Server, y se ejecuta. Luego se sube

haciendo click en el botón “iniciar elemento” como se muestra a continuación:

Figura 83. Iniciando el IIS.

Configurando un nuevo Sitio Web

Cuando se crea un proyecto Web es necesario configurar el sito, para que funcione y se

desplegué correctamente en el IIS

Se hace click derecho en el proyecto y se escoge la opción propiedades

Figura 84. Configurando Propiedades.

Se configura las opciones de cada casillas como se muestra a continuación luego

se da click en crear

Figura 85. Configuración Paso 1.

Luego se va a la pestañas Documentos para configurar la página de inicio, en este

caso se escoge o se agrega si no aparece Service.asmx.


Luego se verifica en la pestaña ASP.NET la versión de Asp, si no aparece ninguna

se configura la siguiente


Por último se guardan los cambios dando click en aceptar

Se puede probar el servicio Web en el IIS, haciendo click derecho en el sitio Web y

escogiendo la opción examinar.

Figura 88. Probando el WS en el IIS.

Se muestra la opción para testear los métodos y de ver el Wsdl, al igual como se

hizo con el servidor de desarrollo

Figura 89. Testear y ver el WSDL con el IIS.

El servicio Web hecho en .NET está listo para ser consumido y la URL del WSDL

que lo describe es:

http://localhost/SERVIBANCO_A_B/Service.asmx?WSDL.

Servicio Web en la plataforma J2EE

Especificaciones

El servicio Web en la plataforma J2EE se construyó utilizando NetBeans 6.5.

Creando la Base de Datos

A continuación se muestra las tablas que se crearon en JavaDB con el nombre de

banco1, banco2. Al Abrir NetBeans 6.5 se da click derecho en JavaDB y se escogió la

opción crear base de dato.

Figura 90 Create DataBase.

http://localhost/SERVIBANCO_A_B/Service.asmx

Luego aparece la siguiente ventana el cual se configuró el nombre de BD, el nombre de

usuario y la contraseña y se le da click en OK.

Figura 91. Creando BD paso 1.

Luego se le dio click derecho y se escogió la opción de conectar como se muestra a

continuación

Figura 92. Creando BD Paso 2.

Cuando se ha hecho la conexión, se crean las tablas haciendo click derecho sobre

Tables y escogiendo Create Table.


Aparece el siguiente asistente; el cual se le configuró el nombre de la tabla y se le

asignaron los siguientes campos con sus respectivos tipos de datos.


Después se le da click en ok y se procede a realizar otra tabla con los mismo campos y

tipos de datos y con el nombre banco2. Posteriormente se insertaron datos utilizando

comando de SQL en el Wizard


Creando el Servicio Web

Se abrió el NetBeans


Se escogió la especificación JEE 5

Se le asignó el nombre de SERVIBANCO_1_2

Al tener el nuevo proyecto liso, se creó luego un nuevo servicio Web y se le

agregaron métodos como se mostró en (4.3.5.5), de la siguiente manera.

package paquete_servicio; // Empaquetando

import java.sql.Connection;import java.sql.ResultSet;import java.sql.SQLException;import java.sql.Statement;import javax.annotation.Resource;import javax.jws.WebMethod;import javax.jws.WebParam;import javax.jws.WebService;import javax.sql.DataSource;

/**** @author JOHNX*/

@WebService()public class SERVICIO {

/* hacienda la connexion co la BD se realiza con un Wizard*/@Resource(name = "conexion1")private DataSource conexion1;

/*** Web Service operation*/

@WebMethodpublic String LLEGA_GIRO(@WebParam(name = "nombre_de_banco") String

nombre_de_banco, @WebParam(name = "num_de_cuenta") int num_de_cuenta,@WebParam(name = "giro") int giro) {

try{Connection con = conexion1.getConnection();Statement stm = con.createStatement();

String consul="";

consul ="select \"deposito\" from \""+nombre_de_banco+"\" where \"num_cuenta\"="+num_de_cuenta+"";

ResultSet rs = stm.executeQuery(consul);

rs.next();String devolver =rs.getString(1);

int total = Integer.parseInt(devolver);total = total + giro;

@author

@WebService

@Resource

@WebMethod

@WebParam

@WebParam

@WebParam

stm.executeUpdate("update \""+nombre_de_banco+"\" set \"deposito\" = "+total+"where \"num_cuenta\" = "+num_de_cuenta+"");

} catch(SQLException y){return "nada";

}

return "ok";}

/*** Web Service operation*/@WebMethodpublic String RETIRO_DINERO(@WebParam(name = "nombre_de_banco") String

nombre_de_banco, @WebParam(name = "num_de_cuenta") int num_de_cuenta,@WebParam(name = "contrasena") int contrasena, @WebParam(name = "dinero") int dinero){

try{Connection con = conexion1.getConnection();Statement stm = con.createStatement();

String consul="";

consul ="select \"deposito\" from \""+nombre_de_banco+"\" where \"num_cuenta\"="+num_de_cuenta+" and \"clave\" ="+contrasena+"";

ResultSet rs = stm.executeQuery(consul);

rs.next();String devolver =rs.getString(1);

int saldo = Integer.parseInt(devolver);saldo = saldo - dinero;

if(saldo >= 0) {consul="update \""+nombre_de_banco+"\" set \"deposito\" = "+saldo+" where

\"num_cuenta\" ="+num_de_cuenta+"";stm.executeUpdate(consul);

} else {return "nada";

}} catch(SQLException y){

return "nada";}return "ok";

}}

Los métodos son parecidos del servicio Web en J2EE al de .NET, ambos tienen 2

métodos LLEGA_GIRO y RETIRO_DINERO reciben 3 y 4 parámetros

@WebMethod

@WebParam

@WebParam

@WebParam

@WebParam

respectivamente. En J2EE Se realiza una conexión se preparan los estamentos,

se ejecuta la consulta este devuelve un ResultSet el cual se manipula con next ().

El método LLEGA_GIRO verifica que la cuenta exista, y si no se produce ningún

error actualiza la cantidad total sumando el dinero que llega del giro, y manda un

String “ok” o si no devuelve un “nada”.

El método RETIRO_DINERO verifica que la cuenta exista y que la contraseña

coincida, luego verifica que antes de realizar el retiro de dinero el valor que quede

en la cuenta sea mayor o igual a 0. si se cumple esto se realiza el UPDATE con la

nueva cantidad que quedo luego de haber realizado la transacción.

Antes de compilar o desplegar en el servidor es necesario subirlo

Figura 96. Start Servidor.

Luego se deploya haciendo click derecho y escogiendo la opción que aparece

Figura 97. Desplegando Servicio Web.

Luego se testea los métodos del WS como se explico en (4.3.5.6)

El servicio Web hecho en J2EE está listo para ser consumido y la URL del WSDL que lo

describe es: http://localhost:8080/SERVIBANCO_1_2/SERVICIOService?wsdl

ANEXO IV

DESARROLLO DEL CLIENTE EN AMBAS PLATAFORMAS

Desarrollo del Cliente .NET

Consiste en una aplicación Web que consuma los servicios Web hechos en J2EE y .NET.

Creando La Aplicación Web

Se abrió el VS.

Se creó un nuevo proyecto como se mostró en (4.3.5.2).

Se escogió el Framework 3.5.

Se le asigno el nombre de CITYGIRO y se guardo en la siguiente dirección

C:\Inetpub\wwwroot. El cual es lugar donde se alojan los proyectos Web cuando

se trabaja con el servidor IIS.

Utilizando el cuadro de herramientas y en la vista de diseñador se creó el

siguiente formulario y tabla con sus respectivos textos, combos, etiquetas y el

botón “ENVIAR GIRO”

Figura 98. Creando Formulario del Cliente .NET.

http://localhost:8080/SERVIBANCO_1_2/SERVICIOService

Luego Se agregaron 2 referencias Web; la del WS de .NET y la de J2EE como se

mostró en (4.3.8).

El nombre que se estableció a la referencia Web de .NET fue MiServicio

El nombre que se estableció a la referencia Web de J2EE fue MiServicioJ2ee

Como visual Studio es orientado a evento se hizo doble click en el botón ENVIAR

GIRO, y se le programó lo siguiente:

Partial Class _DefaultInherits System.Web.UI.Page

Protected Sub Button1_Click(ByVal sender As Object, ByVal e AsSystem.EventArgs) Handles Button1.Click

Dim banco_inicioN As String = COMBO1.SelectedItem.TextDim banco_destinoN As String = COMBO2.SelectedItem.Text

Dim banco_inicioV As String = COMBO1.TextDim banco_destinoV As String = COMBO2.Text

If (TextBox1.Text = "" Or TextBox2.Text = "" Or TextBox3.Text ="" Or TextBox4.Text = "" Or (banco_inicioN = banco_destinoN AndTextBox1.Text = TextBox3.Text)) Then

'REDIRECCIONE A LA PAGINA DE ERROR O A UN MSGBOX

Else'Dim nombreBanco1 As StringDim numcuenta1 As Integer = TextBox1.TextDim clave As Integer = TextBox2.Text

'Dim nombrebanco2 As StringDim numcuenta2 As Integer = TextBox3.TextDim giro As Integer = TextBox4.Text

Dim wsnet As New MiServicio.ServiceDim wsj2ee As New MiServicioJ2ee.SERVICIOService

Dim resultado As String = ""If (banco_inicioV = "bancoA" Or banco_inicioV = "bancoB")

Thenresultado = wsnet.RETIRO_DINERO(banco_inicioV,

numcuenta1, clave, giro)If (resultado = "ok") Then

If (banco_destinoV = "bancoA" Or banco_destinoV ="bancoB") Then

resultado = wsnet.LLEGA_GIRO(banco_destinoV,numcuenta2, giro)

If (resultado = "ok") ThenResponse.Write("se realizo la transaccion en

forma satisfactoria")Else

wsnet.LLEGA_GIRO(banco_inicioV, numcuenta1,giro)

End IfElse

resultado = wsj2ee.LLEGA_GIRO(banco_destinoV,numcuenta2, giro)



wsnet.LLEGA_GIRO(banco_inicioV, numcuenta1,giro)

End If

End IfElse

Response.Write("LA TRANSACCION NO SE PUDO REALIZAR... por favor intentelo mas tarde....")

End IfElse

'' /****************************/

resultado = wsj2ee.RETIRO_DINERO(banco_inicioV,numcuenta1, clave, giro)

If (resultado = "ok") ThenIf (banco_destinoV = "banco1" Or banco_destinoV =

"banco2") Thenresultado = wsj2ee.LLEGA_GIRO(banco_destinoV,

numcuenta2, giro)If (resultado = "ok") Then

Response.Write("se realizo la transaccion enforma satisfactoria")

Else

wsj2ee.LLEGA_GIRO(banco_inicioV, numcuenta1,giro)

End IfElse

resultado = wsnet.LLEGA_GIRO(banco_destinoV,numcuenta2, giro)



wsj2ee.LLEGA_GIRO(banco_inicioV, numcuenta1,giro)

End If

End IfElse

Response.Write("LA TRANSACCION NO SE PUDO REALIZAR... por favor intentelo mas tarde....")

End If

'' /****************************/

End IfEnd If

End Sub

End Class

Explicando el código

El primer if es para verificar si el usuario no dejo vacio los TextBox y que no

envie giro a la misma cuenta.

El segundo if es para verificar si el banco donde se va a realizar el retiro, es

soportado por WS de .NET y asi llamar el servicio Web que retiro_dinero, se

verifica si el banco destino pertenece tambien a .NET y a si se llama el servicio

Web llega giro.

Si se produce un error en en retiro dinero, sale y manda un mensaje de error.

Si se realizo el retiro de dinero y se produce un error en llega_giro, entonces se

aplica un llega_giro a la cuenta que se habia aplicado el retiro de dinero.

Los demas if hacen lo mismo: buscar que si retiro de dinero y llega giro

pertenecen a los bancos soportados por J2EE. o .Net, o si pertenecen a ambos

en algún orden.

Luego se procedió a ejecutar con el servidor de desarrollo y verificar que funcione,

como se explico en el desarrollo del servicio Web.

Luego se configuró el nuevo sitio Web en el IIS, de la misma forma que se

configuró el servicio Web

Finalmente se prueba realizando transacciones de giro de dinero entre los

diferentes bancos.

Figura 99. Vista del Cliente .NET en el Navegador.

Desarrollo del Cliente en J2EE

Consiste en una aplicación Web que consuma los servicios Web hechos en J2EE y .NET.

Creando la Aplicación Web

Se abrió el NetBeans


Se escogió la especificación JEE 5

Se le asignó el nombre de GIROJEE

Se llamó los Web Services hecho en (J2EE, .NET) como se explico en (4.3.7)

Se creó una clase en la aplicación como se explico en (4.3.7.2) con dos métodos

retirar_dinero, llega_giro para llamar los métodos apropiados del Web Services de

acuerdo a su funcionalidad. Al igual que en .NET se utilizan unos If para

determinar a qué banco corresponde y así que WS usar.

package PAQ;

/**** @author JOHNX*/

public class clase1 {

/** Creates a new instance of clase1 */public clase1() {}public String retirar_dinero(String nombre_banco, int numero_cuenta, int clave, int dinero){

if(nombre_banco.equals("banco1") || nombre_banco.equals("banco2")){

try { // Call Web Service Operationpaquete_ser.SERVICIOService service = new paquete_ser.SERVICIOService();paquete_ser.SERVICIO port = service.getSERVICIOPort();// TODO initialize WS operation arguments herejava.lang.String nombreDeBanco = nombre_banco;int numDeCuenta = numero_cuenta;int contrasena = clave;

java.lang.String result = port.retiroDINERO(nombreDeBanco, numDeCuenta, contrasena,dinero);

System.out.println("Result = "+result);if (result.equals("ok"))

return "ok";else

return "nada";} catch (Exception ex){// TODO handle custom exceptions here

return ex.toString();}

}else{

try { // Call Web Service Operationpaquete_ser2.Service service = new paquete_ser2.Service();paquete_ser2.ServiceSoap port = service.getServiceSoap();// TODO initialize WS operation arguments herejava.lang.String nombreDeBanco = nombre_banco;int numDeCuenta = numero_cuenta;int contrasena = clave;

java.lang.String result = port.retiroDINERO(nombreDeBanco, numDeCuenta, contrasena,dinero);

@author

System.out.println("Result = "+result);if (result.equals("ok"))

return "ok";else

return "nada";} catch (Exception ex){// TODO handle custom exceptions here


}//{

//return null;

}

public String llega_giro(String nombre_banco, int num_cuenta, int giro){

if(nombre_banco.equals("banco1") || nombre_banco.equals("banco2")){

try { // Call Web Service Operationpaquete_ser.SERVICIOService service = new paquete_ser.SERVICIOService();paquete_ser.SERVICIO port = service.getSERVICIOPort();// TODO initialize WS operation arguments herejava.lang.String nombreDeBanco = nombre_banco;int numDeCuenta = num_cuenta;

java.lang.String result = port.llegaGIRO(nombreDeBanco, numDeCuenta, giro);System.out.println("Result = "+result);

if (result.equals("ok"))return "ok";

elsereturn "nada";

} catch (Exception ex){// TODO handle custom exceptions here


}else{

try { // Call Web Service Operationpaquete_ser2.Service service = new paquete_ser2.Service();paquete_ser2.ServiceSoap port = service.getServiceSoap();// TODO initialize WS operation arguments herejava.lang.String nombreDeBanco = nombre_banco;int numDeCuenta = num_cuenta;// TODO process result herejava.lang.String result = port.llegaGIRO(nombreDeBanco, numDeCuenta, giro);System.out.println("Result = "+result);

if (result.equals("ok"))return "ok";

elsereturn "nada";

} catch (Exception ex){// TODO handle custom exceptions here


}

// return null;}

}

Utilizando la palette se creó el formulario, la tabla, los texto, combo, botón para

capturar los valores y enviarlo a la clase

Figura 100. Creando Formulario del Cliente J2EE.

A continuación se muestra parte del código en el Jsp para instanciar la clase

Figura 101 Parte del Código del Cliente J2EE.

Luego se le da click derecho y luego Run para ejecutar y probar la aplicación Web

Figura 102. Ejecutando Cliente J2EE.

A continuación se muestra la aplicación Web

Figura 103. Vista del Cliente J2EE en el Navegador.

Explicando el código

Los códigos fuentes anteriores tienen la misma funcionalidad del código fuente antes

explicado en el cliente .NET.

Documents

ANALISIS COMPARATIVO DE LAS PLATAFORMAS J2EE Y .NET APLICADO AL DESARROLLO DE WEB SERVICES