Analisis Comparativo de Las Plataformas J2ee y .Net Aplicado Al Desarrollo de Web Services

UNIVERSIDAD DE PAMPLONA
FACULTAD DE INGENIERIAS Y ARQUITECTURA

DEPARTAMENTO DE INGENIERIAS ELÉCTRICA ELECTRÓNICA SISTEMAS Y
TELECOMUNICACIONES
PROGRAMA DE INGENIERIA DE SISTEMAS
TITULO
ANALISIS COMPARATIVO DE LAS PLATAFORMAS J2EE Y .NET APLICADO
AL DESARROLLO DE SERVICIOS WEB
AUTOR: JOHN JAIRO MENDEZ ROMERO
PAMPLONA COLOMBIA
NOVIEMBRE DE 2008
TELECOMUNICACIONES
PROYECTO DE TRABAJO DE GRADO PARA OPTAR POR EL TITULO DE

INGENIERO DE SISTEMAS
TITULO
AUTOR
JOHN JAIRO MEDEZ ROMERO
DIRECTOR
MSC. (C). JORGE OMAR PORTILLA JAIMES.
PAMPLONA – COLOMBIA
NOVIEMBRE DE 2008
TELECOMUNICACIONES
TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

INGENIERO DE SISTEMAS
TITULO

FECHA DE INICIO DEL TRABAJO: Mayo de 2008

FECHA 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 ____________________________________________________ 33
1.3.1 Objetivo General __________________________________________________________________________ 33
1.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_____________________________________________ 35
2.2.1 Nacional _________________________________________________________________________________ 35
2.2.2 Local ____________________________________________________________________________________ 35
2.3 Historia de los Servicios Web _____________________________________________________ 36
2.3.1 La era de las redes locales. __________________________________________________________________ 36
2.3.2 La era de Internet y la Web. _________________________________________________________________ 37
2.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______________________________________________________ 40
2.6.1 XML_____________________________________________________________________________________ 41
2.6.2 Protocolo de acceso de objeto Simple (SOAP)____________________________________________________ 42
2.6.2.1 Estructura de un mensaje Soap________________________________________________________ 43
2.6.2.2 Ventajas de utilizar Soap _____________________________________________________________ 43
2.6.3 WSDL ___________________________________________________________________________________ 44
2.6.3.1 Descripción del Wsdl ______________________________________________________________________ 45
2.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 ____________________________________________________ 47
2.8.1 Que es .NET? ______________________________________________________________________________ 48
2.8.2 Principales objetivos de la plataforma .NET _____________________________________________________ 48
2.8.6 Principales lenguajes soportados por .NET. _____________________________________________________ 49
2.8.4 Arquitectura .NET __________________________________________________________________________ 50
2.8.3 ¿Qué es .NET Framework?___________________________________________________________________ 51
2.8.5 Framework 3.0 Y 3.5 ________________________________________________________________________ 52
2.9 Plataforma J2EE _________________________________________________________________ 53
2.9.1 Definición de J2EE __________________________________________________________________________ 53
2.9.2 Arquitectura J2EE.__________________________________________________________________________ 53
2.9.3 Características de J2EE.______________________________________________________________________ 54
2.9.3.1 Paquetes de aplicaciones _____________________________________________________________ 55
2.9.3.2 Lenguajes soportado por J2EE________________________________________________________ 57
2.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. _______________________________________ 59
3.3.1 Seguridad a nivel de mensaje. _______________________________________________________________ 59
3.3.2 Portabilidad _____________________________________________________________________________ 59
3.3.3 IDE de J2EE frente al IDE de .NET ____________________________________________________________ 60
3.3.4 Interoperabilidad _________________________________________________________________________ 60
3.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 __________________________________ 62
3.5.1 IDE_____________________________________________________________________________________ 62
3.5.1.1 NetBeans __________________________________________________________________________ 62
3.5.1.2 Visual Studio ________________________________________________________________________ 63
3.5.2 Servidores de aplicación ___________________________________________________________________ 64
3.5.2.1 Sun Application Server (GlassFish) ___________________________________________________ 65
3.5.2. IIS (Internet Information Services) _______________________________________________________ 65
3.5.3 Especificaciones y estándares ______________________________________________________________ 66
3.5.3.1 JEE5 y Framework 3.5 ______________________________________________________________ 66
3.5.4 Lenguajes de programación________________________________________________________________ 67
3.5.4.1 Java_______________________________________________________________________________ 67
3.5.4.2 Visual Basic .Net ___________________________________________________________________ 67
3.5.5 Servidores y manejadores de datos ____________________________________________________________ 67
3.5.5.1 Java DB ____________________________________________________________________________ 67
3.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 ____________________________________________________ 70
4.1.1 Algunas especificaciones soportada por J2EE____________________________________________________ 70
4.1.1.1 La plataforma J2EE (JEE 5) de Sun Microsystems ______________________________________ 70
4.1.1.2 GlassFish___________________________________________________________________________ 70
4.1.1.3 NetBeans___________________________________________________________________________ 70
4.1.1.4 WSIT ______________________________________________________________________________ 70
4.1.2 Algunas especificaciones soportadas por .NET ___________________________________________________ 71
4.1.2.1 Visual Studio .NET __________________________________________________________________ 71
4.1.2.1.1 Web Services Enhancements _____________________________________________________ 72
4.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 la
especificación de WS-Security _____________________________________________________________________ 73
4.1.3.1 Aplicación UserName Tokens en .NET utilizando WSE __________________________________ 73
4.1.3.1.1 Servicio Web ____________________________________________________________________ 73
4.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 ___________________________________ 77
4.1.4 Análisis de seguridad a nivel de mensaje _______________________________________________________ 80
4.2 Portabilidad. _____________________________________________________________________ 82
4.2.1 Análisis de la Portabilidad en J2EE ____________________________________________________________ 82
4.2.2 Análisis de la Portabilidad en .NET _____________________________________________________________ 82
4.3 NetBeans 6.5 frente Visual Studio .NET 2008_______________________________________ 83
4.3.1 Especificaciones ___________________________________________________________________________ 83
4.3.2 Prueba 1 _________________________________________________________________________________ 84
4.3.2 Prueba 2 _________________________________________________________________________________ 84
4.3.3 Prueba 3 _________________________________________________________________________________ 85
4.3.4 Prueba 4 _________________________________________________________________________________ 85
4.3.5 Realizando un Servicio Web _________________________________________________________________ 86
4.3.5.1 NetBeans 6.5 _______________________________________________________________________ 86
4.3.5.2 Visual Studio .NET 2008 _____________________________________________________________ 86
4.3.5.3 Prueba 5 ___________________________________________________________________________ 87
4.3.5.4 Método del Servicio Web en VS .NET. _________________________________________________ 88
4.3.5.5 Método del Servicio Web en NetBeans_________________________________________________ 88
4.3.5.6 Prueba 6 ___________________________________________________________________________ 91
4.3.5.7 Testear el Servicio Web y ver el Wsdl desde VS ________________________________________ 91
4.3.5.8 Testear el Servicio Web y ver el Wsdl desde NetBeans__________________________________ 92
4.3.5.9 Realizando cambios en el método del WS en VS _______________________________________ 93
4.3.5.10 Realizando cambios en el método del WS en NetBeans ________________________________ 93
4.3.6 Conexión a Bases de datos. __________________________________________________________________ 94
4.3.6.1 Conexión en NetBeans_______________________________________________________________ 94
4.3.6.2 Conexión en VS _____________________________________________________________________ 95
4.3.7 Consumiendo un servicio Web en J2EE utilizando NetBeans _______________________________________ 96
4.3.7.1 Copiando la URL del Servicio ________________________________________________________ 96
4.3.7.2 Generando una Clase _______________________________________________________________ 97
4.3.7.3 Agregando Métodos a La Clase ______________________________________________________ 99
4.3.7.4 Llamando una operación del Servicio Web _____________________________________________ 99
4.3.8 Consumiendo un servicio Web en .NET utilizando Visual Studio ___________________________________ 100
4.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 _______________________________________________________________ 104
4.4.1 WS – I___________________________________________________________________________________ 104
4.4.2 Interoperabilidad con METRO y WCF _________________________________________________________ 106
4.4.3 Análisis de la Interoperabilidad ______________________________________________________________ 108
4.4.3.1 Posibles problemas al utilizar WS de diferentes plataformas (J2EE, .NET) ________________ 109
4.4.3.2 El DataSet como un tipo de dato especifico de .NET ____________________________________ 109
4.4.3.3 El código de un WS que devuelve un DataSet _________________________________________ 110
4.4.3.4 Analizando el WSDL generado por el WS .NET que devuelve un DataSet_________________ 111
4.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__________________________________________________________ 114
4.5.1.1 J2EE______________________________________________________________________________ 114
4.5.1.2 NET ______________________________________________________________________________ 115
4.5.2 Resumen del estado de las transacciones _____________________________________________________ 116
4.5.2.1 J2EE______________________________________________________________________________ 116
4.5.2.2 .NET ______________________________________________________________________________ 116
4.5.2.3 Análisis 1 __________________________________________________________________________ 117
4.5.3 Tiempo contra la cuenta de usuarios activos___________________________________________________ 117
4.5.3.1 J2EE______________________________________________________________________________ 117
4.5.3.2 .NET ______________________________________________________________________________ 117
4.5.3.3 Análisis 2 __________________________________________________________________________ 118
4.5.4 Hits por segundos ________________________________________________________________________ 118
4.5.4.1 J2EE______________________________________________________________________________ 118
4.5.4.2 .NET ______________________________________________________________________________ 119
4.5.4.3 Análisis 3 __________________________________________________________________________ 119
4.5.5 Tiempo contra el rendimiento ______________________________________________________________ 119
4.5.5.1 J2EE______________________________________________________________________________ 120
4.5.5.2 .NET ______________________________________________________________________________ 120
4.5.5.3 Análisis 4 __________________________________________________________________________ 121
4.5.6 Distribución de los errores para todas las transacciones _________________________________________ 121
4.5.6.1 J2EE______________________________________________________________________________ 121
4.5.6.2 .NET ______________________________________________________________________________ 121
4.5.6.3 Análisis 5 __________________________________________________________________________ 122
4.5.7 El tiempo contra el porcentaje de error _______________________________________________________ 122
4.5.7.1 .NET ______________________________________________________________________________ 122
4.5.8 Reporte del tiempo De respuesta ___________________________________________________________ 123
4.5.8.1 J2EE______________________________________________________________________________ 123
4.5.8.2 .NET ______________________________________________________________________________ 123
4.5.8.3 Análisis 6 __________________________________________________________________________ 124
4.5.9 El tiempo contra el tiempo de respuesta (Detallado)____________________________________________ 124
4.5.9.1 J2EE______________________________________________________________________________ 124
4.5.9.2 .NET ______________________________________________________________________________ 125
4.5.9.3 Análisis 7 __________________________________________________________________________ 125
4.5.10 Usuarios contra el tiempo de respuesta _____________________________________________________ 125
4.5.10.1 J2EE_____________________________________________________________________________ 126
4.5.10.2 .NET _____________________________________________________________________________ 126
4.5.10.3 Análisis 8 _________________________________________________________________________ 126
4.5.11 Usuarios contra el rendimiento ____________________________________________________________ 127
4.5.11.1 J2EE_____________________________________________________________________________ 127
4.5.11.2 .NET _____________________________________________________________________________ 127
4.5.11.3 Análisis 9 _________________________________________________________________________ 127
4.5.12 Cuellos de botellas - Reporte de análisis _____________________________________________________ 128
4.5.12.1 J2EE_____________________________________________________________________________ 128
4.5.12.2 .NET _____________________________________________________________________________ 129
4.5.12.3 Análisis 10 ________________________________________________________________________ 129
4.5.13 El tiempo contra el tiempo de las páginas descargadas _________________________________________ 129
4.5.13.1 J2EE_____________________________________________________________________________ 130
4.5.13.2 .NET _________________________________________________________________________________ 130
4.5.13.3 Análisis 11 ________________________________________________________________________ 130
4.5.14 Reporte del tamaño de páginas ____________________________________________________________ 130
4.5.14.1 J2EE_____________________________________________________________________________ 131
4.5.14.2 .NET _____________________________________________________________________________ 131
4.5.14.3 Análisis 12 ________________________________________________________________________ 131
4.5.15 Reporte de las páginas descargada _________________________________________________________ 132
4.5.15.1 J2EE_____________________________________________________________________________ 132
4.5.15.2 .NET _____________________________________________________________________________ 132
4.5.15.3 Análisis 13 ________________________________________________________________________ 133
4.5.16 Resumen de los reportes _________________________________________________________________ 133
4.5.16.1 J2EE_____________________________________________________________________________ 133
4.5.16.2 .NET _____________________________________________________________________________ 134
4.5.16.3 Análisis 14 ________________________________________________________________________ 134
4.5.17 Analizando el desempeño entre J2EE y .NET utilizando otras Investigaciones ________________________ 135
4.5.17.1 Test realizado _____________________________________________________________________ 135
4.5.17.2 Resultado del Test _________________________________________________________________ 135
4.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 ..................................................................................... 42

Figura 2. XML como Tecnología e Innovación.......................................................................................... 42
Figura 3. Composición de un mensaje SOAP........................................................................................... 43
Figura 4. Solicitud Utilizando Soap ............................................................................................................. 43
Figura 5. Respuesta Utilizando Soap ......................................................................................................... 43
Figura 6. Ejemplo de un documento Wsdl ................................................................................................. 45
Figura 7. Dinámica de un Servicio .............................................................................................................. 47
Figura 8. Arquitectura de .NET .................................................................................................................... 50
Figura 9. FrameWork se desarrollan todas las aplicaciones .................................................................. 52
Figura 10. Características de .NET FrameWork 3.5 ........................................................................... 52
Figura 11 Arquitectura J2EE (modelo de ejecución en capas)............................................................... 53
Figura 12 Estructura archivo JAR. .............................................................................................................. 55
Figura 13. Estructura archivo WAR. ........................................................................................................... 56
Figura 14. Estructura archivo EAR.............................................................................................................. 56
Figura 15. Estructura archivo RAR ............................................................................................................. 57
Figura 17. NetBeans IDE 6.5 ....................................................................................................................... 63
Figura 18. Visual Studio .NET 2008 Preview ............................................................................................ 64
Figura 19. Conjunto de estándares de WSIT ............................................................................................ 71
Figura 20. Pestañas de ventanas en NetBeans ....................................................................................... 77
Figura 21. UserNameToken......................................................................................................................... 78
Figura 22. Ventana de Editor UserNameToken ........................................................................................ 78
Figura 23. Agregando Tokens en NetBeans ............................................................................................. 79
Figura 24. Atributos de un WS..................................................................................................................... 79
Figura 25. Editor de Atributos ...................................................................................................................... 79
Figura 26. Atributos a una Referencia WS ................................................................................................ 80
Figura 27. Editor de Atributos Cliente......................................................................................................... 80
Figura 28. Nuevo Proyecto en NetBeans................................................................................................... 86
Figura 29. Escogiendo categorías de proyectos en NetBeans. ............................................................. 86
Figura 30. Agregando nuevo WS a una Aplicación Web ........................................................................ 86
Figura 31. Nuevo sitio Web en VS 2008 .................................................................................................... 87
Figura 32. Nuevo WS en VS 2008 .............................................................................................................. 87
Figura 33. Metodo por defecto un WS en Visual Studio.......................................................................... 88
Figura 34. Código por defecto de un WS en NetBeans........................................................................... 89
Figura 35. Adicionar un nuevo método en NetBeans. ............................................................................. 89
Figura 36. Editor de métodos. ..................................................................................................................... 90
Figura 37. Método de un WS en NetBeans............................................................................................... 90
Figura 38. WSDL y Testeo de un WS en Visual Studio........................................................................... 91
Figura 39. Test Web Service ....................................................................................................................... 92
Figura 40. WSDL y Testeo de un WS en NetBeans ................................................................................ 92
Figura 41. Herramienta para renombrar WS en NetBeans ..................................................................... 93
Figura 42. Herramienta para cambiar métodos del parámetro............................................................... 93
Figura 43. Asistente para agregar una nueva conexión en NetBeans .................................................. 94
Figura 44. Asistente para Buscar Driver en NetBeans ............................................................................ 95
Figura 45. Asistente para agregar una nueva conexión en visual Studio............................................. 95
Figura 46. Agregando una referencia Web en un cliente ........................................................................ 96
Figura 47. Asistente de Adición de Referencia Web................................................................................ 97
Figura 48. Referencia Web Agregada ........................................................................................................ 97
Figura 49. Crear Una Nueva Clase............................................................................................................. 98
Figura 50. Asistente para nueva clase ....................................................................................................... 98
Figura 51. Clase generada........................................................................................................................... 98
Figura 52. Creando un Método a la Clase ................................................................................................. 99
Figura 53. Llamando un método de un WS ............................................................................................... 99
Figura 54. Selección de la operación ......................................................................................................... 99
Figura 55. Código generado ...................................................................................................................... 100
Figura 56. Nueva referencia Web en Visual Studio................................................................................ 100
Figura 57. Asistente de Referencia Web ................................................................................................. 101
Figura 58. Referencia Web Agregada ...................................................................................................... 101
Figura 59. Método Page_Load .................................................................................................................. 102
Figura 60. Variable Tipo Referencia Web................................................................................................ 102
Figura 61. WSDL del DataSet ................................................................................................................... 111
Figura 62. Mensaje Soap Del DataSet Parte1 ....................................................................................... 112
Figura 63. Mensaje Soap Del DataSet Parte 2 ...................................................................................... 112
Figura 64. Error Generado en El Cliente con NetBeans ...................................................................... 113
Figura 65. Especificaciones de Seguridad. ............................................................................................. 158
Figura 66. Dialogo de Seguridad sin validación...................................................................................... 162
Figura 67. Dialogo de Seguridad con auto validación. .......................................................................... 163
Figura 68. Mensaje Soap con WS-Security............................................................................................. 164
Figura 69. Mensaje Soap Utilizando Certificados X509. ....................................................................... 164
Figura 70. Ejemplo del Lenguaje MSIL. ................................................................................................... 169
Figura 71. LP Sin Maquina Virtual. ........................................................................................................... 175
Figura 72. LP Con Maquina Virtual........................................................................................................... 175
Figura 73. Ejemplo de bytecode................................................................................................................ 176
Figura 74. Compilador Tradicional. ........................................................................................................... 181
Figura 75. Actuación de un Intérprete. ..................................................................................................... 182
Figura 76. Interprete de Bytecodes........................................................................................................... 182
Figura 77. Just-In-Time............................................................................................................................... 183
Figura 78. HotSpot. ..................................................................................................................................... 184
Figura 79. Desde la versión NetBeans 5.5 incorpora JMV HotSpot.................................................... 185
Figura 80. Depuración en Visual Studio................................................................................................... 192
Figura 81. Probando el WS en .NET. ....................................................................................................... 192
Figura 82. Digitando Valores en .Net. ...................................................................................................... 192
Figura 83. Resultado Devuelto en .NET. ................................................................................................. 192
Figura 84. Iniciando el IIS........................................................................................................................... 193
Figura 85. Configurando Propiedades. .................................................................................................... 193
Figura 86. Configuración Paso 1............................................................................................................... 194
Figura 89. Probando el WS en el IIS. ....................................................................................................... 195
Figura 90. Testear y ver el WSDL con el IIS. .......................................................................................... 196
Figura 91 Create DataBase. ...................................................................................................................... 196
Figura 92. Creando BD paso 1.................................................................................................................. 197
Figura 93. Creando BD Paso 2. ................................................................................................................ 197
Figura 97. Start Servidor. ........................................................................................................................... 201
Figura 98. Desplegando Servicio Web..................................................................................................... 201
Figura 99. Creando Formulario del Cliente .NET. .................................................................................. 203
Figura 100. Vista del Cliente .NET en el Navegador. ............................................................................ 207
Figura 101. Creando Formulario del Cliente J2EE................................................................................. 210
Figura 102 Parte del Código del Cliente J2EE........................................................................................ 210
Figura 103. Ejecutando Cliente J2EE....................................................................................................... 211
Figura 104. Vista del Cliente J2EE en el Navegador. ............................................................................ 211
INDICE DE TABLAS
Tabla 1. Lenguajes Soportados por .NET _________________________________________________ 49

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

virtual (Módulos: Académico, investigación, entorno y los servicios a
estudiantes). 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/IP
usando 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].
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 no

funcionales). 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 LA

COMPARACION
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.
Aspectos J2EE .NET

Relacionados
Proveedores o Sun, IBM, +30 Microsoft
vendedores
IDEs o herramientas NetBeans, Eclipse, JBuilder, Visual Studio .NET, Mono
para desarrollar otros
Servicios Web
Lenguaje Java C#, Basic .NET, C++, Java,
otros
Lenguaje Intermedio BYTECODE MSIL (conocido como CIL o
IL)
Interpretadores Interpretador (JRE) JVM Interpretador CLR
Compiladores JIT JIT
dinámicos, motores
de Ejecución
Estándares SOAP 1.1, SOAP1.2 , WSDL, SOAP 1.1, SOAP1.2, WSDL,
XML, UDDI XML, UDDI
Servidores de BD Java DB, MySQL, Oracle, SqlServer, Oracle, MySQL,
Postgres, otros otros
Acceso a datos JDBC, SQL/J ADO.NET
Servidores de GlassFish (sun application IIS (Internet Information
Aplicaciones server), JBoss, SAP Services), Application Center,
NetWeaver, JEUS, Geronimo, BizTalk Server, Commerce
JOnAS, IBM WebSphere Server, Content Management
Application Server, WebLogic Server, Apache 2(modo
de BEA Systems, otros mono), 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 de
acuerdo 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ñador
InitializeComponent();
}
#region Component Designer generated code

//Requerido por el Diseñador del servicios web
private 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 por

defecto
[WebMethod]
public string GetHelloWorld()
{
// Obetenga el contexto Soap para la respuesta
SoapContext myResponse = ResponseSoapContext.Current;
// Crear el mismo Username token para el retorno del mensaje

UsernameToken myToken = new UsernameToken("anyname",
"Secure$Password",PasswordOption.SendNone);
// Añadir el Username token para el SoapContext

myResponse.Security.Tokens.Add(myToken);
// Firme el mensaje con el Token

myResponse.Security.Elements.Add(new
Signature(myToken));
// Retorno del Hola Mundo

return "Hello World";
}
}
// Esta clase implementa el nombre de usuario personalizado token

handler (I utilizar el mismo código
//en el cliente para manejar el mensaje devuelto con un nombre de
usuario 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, debe
anular
* 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(UsernameToken
myNameToken)
{
// Asegurando que el mensaje SOAP enviado
// no pase un null en el UsernameToken
if (myNameToken == null) throw new
ArgumentNullException();
// Para retornar
string 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 estas
credenciales\n\n");
}
catch(Exception ex)
{
Console.WriteLine(ex.ToString());
}
// Instanciando la Clase HelloWorldWse.

HelloWorldWse myService = new HelloWorldWse();
// Obteniendo el Objeto SoapContext para el mensjae

Saliente.
SoapContext myContext = myService.RequestSoapContext;
// Una nueva instancia UsernameToken

UsernameToken myToken = new UsernameToken(myName,
myPwd, PasswordOption.SendNone);
// Adicionando el token para el contexto soap o cuerpo

soap.
myContext.Security.Tokens.Add(myToken);
//Generar una firma utilizando el UserName Token,

//y agregar la firma al SoapContext.
myContext.Security.Elements.Add(new
Signature(myToken));
// Creando Una variable para el retorno del WS.

string response = "";
try
{
// LLamando el metodo del Web Services
response = 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ón
Sistema Operativo Microsoft Windows XP Version 2002
Service Pack 2
Procesador Intel Celeron D 2.8
Memoria Ram 1.5 GB
Tamaño del Archivo de Paginación 2046 MB
Uso De Memoria Caché Del Sistema
Tabla 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.4
1 Visual .NET 4.7
2 NetBeans 28.9
2 Visual .NET 3.1
3 NetBeans 27.9
3 Visual .NET 3.3
Promedio NetBeans 30.066
Promedio 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.4
1 PLAY IIS 9.1
1 STOP GlassFish 19.3
1 STOP IIS 4.1
2 PLAY IIS 6.8
2 STOP IIS 6.5
3 PLAY IIS 6.2
3 STOP IIS 6.3
Promedio PLAY GlassFish 42.666
Promedio STOP GlassFish 14.933
Promedio PLAY IIS 7.366
Promedio 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 Instancia

NetBeans 6.5 1
Visual Studio 2008 43
Tabla 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.

1 NetBeans 42.5 + 32.3
1 Visual .NET 15.7
2 NetBeans 30.1 + 9.7
2 Visual .NET 5.4
3 NetBeans 39.8 + 6.7
3 Visual .NET 5.0
Promedio NetBeans 37.46 + 16.23 = 53.69
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

1 NetBeans 23.7
1 Visual .NET 15.7
2 NetBeans 12.0
2 Visual .NET 5.8
3 NetBeans 10.6
3 Visual .NET 6.0
Promedio NetBeans 15.433
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

Windows (2000, xp, vista)
Linux (x86 / x64)
Disponibilidad Plataforma Solaris (x86 / x64) SO Windows (Diferentes
(Sistema Operativo) Solaris (sparc) versiones)
MAC OS X
OS Independent Zip
Español
Ingles
Francés
Lenguajes disponibles Ingles Alemán
Actualmente Italiano
Japonés
Coreano
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:KeyIdentifier> uuid: 006ab385-35e0-41b1-b0f5-ccef5090c1b0 </
PSES: KeyIdentifier>
Incorrecto:
<! - Este ejemplo es incorrecto porque el PSES: KeyIdentifier elemento
tiene un valor incorrecto para el atributo ValueType por lo tanto, en
conflicto con R6603 ->
<wsse:KeyIdentifier ValueType='http://docs.oasis-open.org/wss/oasis-
wss-saml-token-profile-1.0#SAML'>
Incorrecto:
<! - Este ejemplo es incorrecto porque el PSES: KeyIdentifier ha
EncodingType un atributo por lo tanto, en conflicto con R6604 ->
<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
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 III
y 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.Web
Imports System.Web.Services
Imports System.Web.Services.Protocols
Imports System.Data.OleDb
Imports System.Data
' Para permitir que se llame a este servicio web desde un script, usando
ASP.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
Try
conexion = New
OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; " & "Data
Source=C:\banconet.mdb;")
Dim Qry As String = "Select * From " &
nombre_de_banco
Dim cmd As New OleDbCommand(Qry, conexion)
Dim ds As New DataSet
Dim da As New OleDbDataAdapter(cmd)
If conexion.State <> Data.ConnectionState.Open Then
conexion.Open()
End If
da.Fill(ds)
conexion.Close()
Return ds
Catch ex As Exception
Return Nothing
End Try
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 General
Personal $ 2.808.000
Material inventariable $ 1.840.000
Material No
inventariable $ 222.000
TOTAL $ 4.870.000
PERSONAL
Descripción Dedicación Cantidad Valor-Mes Meses Valor Total
Director de proyecto 2 Horas semanales 1 $ 0 6 $ 0
Autor 8 Horas diarias 1 $ 468.000 6 $ 2 808 000
Total $ 2.808.000
Material Inventariable
Descripción Cant Valor Total
Computador Intel(R)/Celeron(R)2.80GHz/1,5-GB RAM/
1. DVD-RW/CD-RW/Monitor de 15 pul AOC 1 $ 1400000 $ 1400000
2. Mesas para computador 1 $ 150000 $ 150000
3. Sillas para computador 1 $ 50000 $ 50000
4. Impresora de tinta APOLLO P-2600 1 $ 130000 $ 130000
5. Scanner 1 $ 110000 $ 110000
Total $ 1840000
Material No Inventariable
Descripción Cant Valor Total
1. CD 12 $ 1000 $ 12000
2. Papelería, Fotocopias, impresiones 1 $ 60000 $ 60000
3. Tinta negra para Impresora Apollo 1 $ 40000 $ 40000
4. Tinta de color para Impresora Apollo 1 $ 60000 $ 60000
5. 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 que
se 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 la
gestión de una máquina virtual.
Código No Gestionado: Código de un programa de computador que se ejecuta
directamente por la CPU del computador.
Componente de Software: son aquel recurso desarrollado para un fin concreto y que
puede formar solo o junto con otro/s, un entorno funcional requerido por cualquier proceso
predefinido. Son independientes entre ellos, y tienen su propia estructura e
implementació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 se
habí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 red
de computadoras para controlar las comunicaciones, permitiéndolas o prohibiéndolas
segú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 una
tecnologí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 URL
especificada.
ROUTER: Enrutador.
SAAJ: SOAP with Attachments API for Java. Suministra una manera estándar de enviar
documentos XML sobre Internet desde la plataforma Java.
SCHEMA: Es un vocabulario basado en XML para describir instancias de documentos
XML. Un “schema” describe una clase de documentos, del cual pueden haber varias
instancias. Esta relación es parecida a la que hay entre clases y objetos en los sistemas
orientados a objetos.
SI: Sistemas de Información.
SMTP: Simple Mail Transfer Protocol (SMTP), Protocolo Simple de Transferencia de
Correo.
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
[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/
[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
[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=1
5892
[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
[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.
 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 de
ByteCodes, 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.Web
Imports System.Web.Services
Imports System.Web.Services.Protocols
Imports System.Data.OleDb
Imports 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 String
Dim comando As OleDbCommand
Dim consulta As String
Dim datos_de_consulta As OleDbDataReader
Try
conexion = New
conexion.Open()
consulta = "SELECT deposito FROM " & nombre_de_banco & "
WHERE num_cuenta = " & num_de_cuenta
comando = New OleDbCommand(consulta, conexion)

datos_de_consulta = comando.ExecuteReader
Dim dinero_total As Integer
Dim ok As String = "nada"
While datos_de_consulta.Read
ok = "ok"
dinero_total = datos_de_consulta.GetInt32(0)
End While
dinero_total = dinero_total + giro
consulta = "UPDATE " & nombre_de_banco & " SET deposito = " &
dinero_total & " WHERE num_cuenta = " & num_de_cuenta

''comando.ExecuteReader()
comando.ExecuteNonQuery()
conexion.Close()
Return ok
Return "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 As
Integer) As String
Dim comando As OleDbCommand
Try
conexion = New
conexion.Open()
Dim consulta As String = "SELECT deposito FROM " &
nombre_de_banco & " WHERE num_cuenta = " & num_de_cuenta & "AND clave = "
& contrasena
Dim datos_de_consulta As OleDbDataReader

datos_de_consulta = comando.ExecuteReader
Dim dinero_total As Integer

While datos_de_consulta.Read
dinero_total = datos_de_consulta.GetInt32(0)
End While
dinero_total = dinero_total - dinero
If dinero_total >= 0 Then
consulta = "UPDATE " & nombre_de_banco & " SET deposito =

" & dinero_total & " WHERE num_cuenta = " & num_de_cuenta

comando.ExecuteReader()
conexion.Close()
Return "ok"
End If
Return "nada"
Return "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.

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
*/
@WebMethod
public 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;
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
*/
@WebMethod
public 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
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.

 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 _Default

Inherits System.Web.UI.Page
Protected Sub Button1_Click(ByVal sender As Object, ByVal e As

System.EventArgs) Handles Button1.Click
Dim banco_inicioN As String = COMBO1.SelectedItem.Text
Dim banco_destinoN As String = COMBO2.SelectedItem.Text
Dim banco_inicioV As String = COMBO1.Text

Dim banco_destinoV As String = COMBO2.Text
If (TextBox1.Text = "" Or TextBox2.Text = "" Or TextBox3.Text =

"" Or TextBox4.Text = "" Or (banco_inicioN = banco_destinoN And
TextBox1.Text = TextBox3.Text)) Then
'REDIRECCIONE A LA PAGINA DE ERROR O A UN MSGBOX
Else
'Dim nombreBanco1 As String
Dim numcuenta1 As Integer = TextBox1.Text
Dim clave As Integer = TextBox2.Text
'Dim nombrebanco2 As String

Dim numcuenta2 As Integer = TextBox3.Text
Dim giro As Integer = TextBox4.Text
Dim wsnet As New MiServicio.Service

Dim wsj2ee As New MiServicioJ2ee.SERVICIOService
Dim resultado As String = ""

If (banco_inicioV = "bancoA" Or banco_inicioV = "bancoB")
Then
resultado = 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)
Response.Write("se realizo la transaccion en
forma satisfactoria")
Else
wsnet.LLEGA_GIRO(banco_inicioV, numcuenta1,
giro)
End If
Else
resultado = wsj2ee.LLEGA_GIRO(banco_destinoV,
numcuenta2, giro)
Else
wsnet.LLEGA_GIRO(banco_inicioV, numcuenta1,
giro)
End If
End If
Else
Response.Write("LA TRANSACCION NO SE PUDO REALIZAR

... por favor intentelo mas tarde....")
End If
Else
'' /****************************/
resultado = wsj2ee.RETIRO_DINERO(banco_inicioV,
numcuenta1, clave, giro)
If (banco_destinoV = "banco1" Or banco_destinoV =
"banco2") Then
resultado = wsj2ee.LLEGA_GIRO(banco_destinoV,
numcuenta2, giro)
Else
wsj2ee.LLEGA_GIRO(banco_inicioV, numcuenta1,
giro)
End If
Else
resultado = wsnet.LLEGA_GIRO(banco_destinoV,
numcuenta2, giro)
Else
wsj2ee.LLEGA_GIRO(banco_inicioV, numcuenta1,
giro)
End If
End If
Else
Response.Write("LA TRANSACCION NO SE PUDO REALIZAR

... por favor intentelo mas tarde....")
End If
'' /****************************/
End If
End 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 Operation
paquete_ser.SERVICIOService service = new paquete_ser.SERVICIOService();
paquete_ser.SERVICIO port = service.getSERVICIOPort();
// TODO initialize WS operation arguments here
java.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
{
paquete_ser2.Service service = new paquete_ser2.Service();
paquete_ser2.ServiceSoap port = service.getServiceSoap();
int numDeCuenta = numero_cuenta;
int contrasena = clave;
java.lang.String result = port.retiroDINERO(nombreDeBanco, numDeCuenta, contrasena,

dinero);
return "ok";
else
return "nada";
{
}
}
//{
//return null;
public String llega_giro(String nombre_banco, int num_cuenta, int giro)

{
if(nombre_banco.equals("banco1") || nombre_banco.equals("banco2"))
{
paquete_ser.SERVICIOService service = new paquete_ser.SERVICIOService();
paquete_ser.SERVICIO port = service.getSERVICIOPort();
int numDeCuenta = num_cuenta;
java.lang.String result = port.llegaGIRO(nombreDeBanco, numDeCuenta, giro);

return "ok";
else
return "nada";
{
}
}
else
{
paquete_ser2.Service service = new paquete_ser2.Service();
paquete_ser2.ServiceSoap port = service.getServiceSoap();
int numDeCuenta = num_cuenta;
// TODO process result here
java.lang.String result = port.llegaGIRO(nombreDeBanco, numDeCuenta, giro);
return "ok";
else
return "nada";
{
}
// 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.

Analisis Comparativo de Las Plataformas J2ee y .Net Aplicado Al Desarrollo de Web Services

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analisis Comparativo de Las Plataformas J2ee y .Net Aplicado Al Desarrollo de Web Services

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE PAMPLONA

FACULTAD DE INGENIERIAS Y ARQUITECTURA

AUTOR: JOHN JAIRO MENDEZ ROMERO

PROYECTO DE TRABAJO DE GRADO PARA OPTAR POR EL TITULO DE

TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

ANALISIS COMPARATIVO DE LAS PLATAFORMAS J2EE Y .NET APLICADO

FECHA DE INICIO DEL TRABAJO: Mayo 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)

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

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

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

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

Mis hermanos y familiares que siempre estuvieron pendientes de mí

Amigos, compañeros, colegas profesores que compartieron sus

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.

La fe es el fin de nuestros recursos

Y el principio de los recursos de Dios.

Principalmente agradezco a Dios por las bendiciones que me

CAPITULO III _______________________________________________________________________58

PRESUPUESTO ECONÓMICO _________________________________________________________139

Figura 1 Representación de Datos XML y HTML ..................................................................................... 42

Tabla 1. Lenguajes Soportados por .NET _________________________________________________ 49

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

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

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

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

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

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

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

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

1.1 DESCRIPCIÓN DEL PROBLEMA

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

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

1.3.1 Objetivo General

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

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

 Desarrollar un prototipo de servicio web en las dos plataformas.

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

2.1 Estado del arte a nivel mundial

 Evaluación Comparativa de aplicaciones Web entre J2EE y Microsoft .NET:

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

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

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

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

 Arquitecturas Orientadas a Servicios como soporte a modelos de educación

2.3 Historia de los Servicios Web

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

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

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

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

2.3.1 La era de las redes locales.

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

2.3.2 La era de Internet y la Web.

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

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