Embed Size (px)
Citation preview
IMPLEMENTACIÓN DE UN CLIENTE WEB ENRIQUECIDO PARA LA APLICACIÓN DE HEALTHBOOK
JAIME DANIEL MOYA ROMERO
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA DE SISTEMAS
BOGOTÁ D.C. 2009
IMPLEMENTACIÓN DE UN CLIENTE WEB ENRIQUECIDO PARA LA APLICACIÓN DE HEALTHBOOK
JAIME DANIEL MOYA ROMERO
Proyecto de grado presentado para optar al título de
Ingeniero de Sistemas y Computación
Directora: Claudia Jiménez
Profesor Asociado
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA DE SISTEMAS
BOGOTÁ D.C. 2009
TABLA DE CONTENIDOS
TABLA DE CONTENIDOS .................................................................................................................. 3
INDICE DE FIGURAS ......................................................................................................................... 5
1. INTRODUCCIÓN ....................................................................................................................... 8
2. ANTECEDENTES Y CONTEXTO ................................................................................................ 10
2.1 Arquitectura HealthBook ............................................................................................... 11
2.2 Estado del arte ............................................................................................................... 13
2.2.1 Aplicaciones enriquecidas en el Internet (Rich Internet Applications RIA) ............ 13
2.2.2 Web 2.0 ................................................................................................................... 14
2.2.3 Usabilidad ............................................................................................................... 17
2.2.4 Infraestructura técnica y tecnológica ..................................................................... 19
3. ANÁLISIS DEL PROTOTIPO EXISTENTE Y ESTRATEGIA DE SOLUCIÓN. .................................. 29
3.1 Análisis de la implementación de HBNucleo1.0 ............................................................ 29
3.2 Objetivos Específicos ...................................................................................................... 31
3.3 Estrategia de Solución .................................................................................................... 32
4. ARQUITECTURA DE LA SOLUCIÓN ......................................................................................... 33
4.1 Capa presentación .......................................................................................................... 35
4.1.1 RichFaces ................................................................................................................. 35
4.1.2 Manejador del idioma ............................................................................................. 36
4.1.3 Manejador de plantillas y estilos ............................................................................ 37
4.1.4 Páginas Servicios Usuario........................................................................................ 37
4.1.5 Páginas Comunidad ................................................................................................. 37
4.1.6 Páginas Signos Vitales ............................................................................................. 37
4.1.7 Páginas InfoGeneral ................................................................................................ 38
4.2 Capa EJB ......................................................................................................................... 38
5. DISEÑO DE LA SOLUCIÓN ...................................................................................................... 40
5.1 Diseño cliente web enriquecido HealthBook ................................................................. 40
5.1.1 Capa presentación .................................................................................................. 40
5.1.2 Capa EJB .................................................................................................................. 47
5.2 Servicios web del núcleo de HealthBook ....................................................................... 61
6. IMPLEMENTACIÓN ................................................................................................................ 71
6.1 Estructura de archivos del cliente enriquecido .............................................................. 71
6.2 Diseño de la demostración del cliente web enriquecido ............................................... 73
6.3 Servicios web HealthBook HBNucleo2.0. ....................................................................... 90
6.4 Implementación de un cliente para los Servicios web de HealthBook .......................... 93
7. ANÁLISIS DE RESULTADOS ..................................................................................................... 95
Servicios web ServiciosUsuario .................................................................................. 95
Servicios web ServiciosComunidad ............................................................................. 97
Servicios web ServiciosSignosVitales ................................................................... 98
8. CONCLUSIONES Y TRABAJO FUTURO .................................................................................... 99
9. BIBLIOGRAFIA ...................................................................................................................... 100
ANEXO ......................................................................................................................................... 102
DESPLIEGUE DE LA APLICACIÓN .............................................................................................. 102
ESPECIFICACIONES TECNICAS .............................................................................................. 102
INSTALACION DEL ENTORNO DE DESARROLLO ................................................................... 102
INDICE DE FIGURAS
Figura 1. Estructura general de HealthBook. ................................................................................ 11
Figura 2. Arquitectura general del núcleo de HealthBook (Carrizosa, 2008). .............................. 12
Figura 3. Arquitectura propuesta para RIA (Deitel, y otros, 2008). .............................................. 14
Figura 4. RSS www.eltiempo.com. ................................................................................................ 16
Figura 5. Respuesta del servicio RSS. ............................................................................................ 16
Figura 6. Mash Up implementado por una aplicación con RichFaces. ......................................... 17
Figura 7. Flujo de una aplicación que utiliza el patrón MVC (Gamma, et al., 2009). ................... 21
Figura 8. Ciclo de vida de un JSF (IBM, 2009). .............................................................................. 23
Figura 9. Diagrama de secuencia de una interacción normal cliente/servidor. ........................... 25
Figura 10. Diagrama de secuencia utilizando la técnica AJAX. ..................................................... 25
Figura 11. Funcionamiento de RichFaces (RichFaces, 2009). ....................................................... 27
Figura 12. Arquitectura de RichFaces (RichFaces, 2009). ............................................................. 28
Figura 13. Diagrama de componentes servicios web. HBNucleo1.0 (Beltran, 2008). .................. 29
Figura 14. Ejemplo descripción servicio ObtenerDatosUsuario. ........................................ 30
Figura 15. Ejemplo datos de entrada servicio obtenerDatosUsuario. ............................... 31
Figura 16. Arquitectura J2EE para HealthBook. ............................................................................ 34
Figura 17. Diagrama de componentes que interactúan con la capa EJB. ..................................... 38
Figura 18. Diagrama de actividades de gestión de servicios eventos médicos. ........................... 41
Figura 19.Diagrama de actividades servicios de gestión de comunidad virtual. .......................... 42
Figura 20. Diagrama de actividades de gestión de signos vitales. ................................................ 43
Figura 21. Diagrama de zonas de página. ..................................................................................... 45
Figura 22. Estructura del contenido principal de una página. ...................................................... 45
Figura 23. Archivo de propiedades de idioma español. ............................................................... 46
Figura 24. Ejemplo de utilización de las propiedades de lenguaje. .............................................. 47
Figura 25. Componentes de la capa EJB. ...................................................................................... 48
Figura 26. Diagrama de clase MenuBean. ................................................................................... 49
Figura 27. Diagrama de clase ComunidadBean. ....................................................................... 50
Figura 28. Diagrama de clase PushHealthBookBean. ........................................................... 52
Figura 29. Diagrama de clase SignosVitalesBean. ............................................................. 54
Figura 30. Diagrama de clase UsuarioBean. ............................................................................ 56
Figura 31. Diagrama de clase ValoresBean. ............................................................................ 57
Figura 32. Diagrama de clase VitalSignsServiceDelegate. .......................................... 58
Figura 33. Diagrama de clase UserServicesDelegate. ...................................................... 59
Figura 34. Diagrama de clase CommunityDelegate. ............................................................. 60
Figura 35. Estructura de archivos del cliente enriquecido ........................................................... 71
Figura 36. Estructura de archivos del paquete WebContent. ................................................... 72
Figura 37. Página de inicio HealthBook. ....................................................................................... 73
Figura 38. Página de inicio HealthBook ingreso no exitoso. ......................................................... 74
Figura 39. Página de inicio HealthBook inscripción usuario. ........................................................ 74
Figura 40. Página de bienvenida posterior de iniciar sesión. ....................................................... 75
Figura 41. Menú principal ubicación general. .............................................................................. 76
Figura 42. Menú principal despliegue de opciones. ..................................................................... 76
Figura 43. Despliegue del calendario. ........................................................................................... 77
Figura 44. Resultado filtrar eventos por fecha. ............................................................................ 77
Figura 45. Ver información detallada evento. .............................................................................. 78
Figura 46. Datos básicos para ingresar nuevo evento. ................................................................. 79
Figura 47. Datos de la observación. .............................................................................................. 79
Figura 48. Confirmación de los datos de la observación. ............................................................. 80
Figura 49. Datos solicitados para crear una prescripción. ............................................................ 80
Figura 50. Confirmación de los datos de una prescripción. ......................................................... 81
Figura 51. Página mandar nuevo mensaje. ................................................................................... 81
Figura 52. Página mandar nuevo mensaje despliegue sugerencias usuario. ............................... 82
Figura 53. Página confirmar envio de nuevo mensaje. ................................................................ 83
Figura 54. Página ver mensajes no leídos. .................................................................................... 83
Figura 55. Página ver mensajes no leídos mensaje completo. ..................................................... 84
Figura 56. Página mensajes enviados. .......................................................................................... 85
Figura 57. Página mensajes enviados ver mensaje completo. ..................................................... 85
Figura 58. Página mensajes. .......................................................................................................... 86
Figura 59. Página agregar amigo. .................................................................................................. 87
Figura 60. Página agregar amigo resultado búsqueda. ................................................................ 87
Figura 61. Página de inicio de signos vitales. ................................................................................ 88
Figura 62. Página insertar signo vital. ........................................................................................... 89
Figura 63. Página consultar signos vitales. ................................................................................... 89
Figura 64. Ejemplo datos de entrada para el servicio obtenerDatosUsuario del servicio
web ServiciosUsuario. ....................................................................................................... 90
Figura 65. Ejemplo respuesta del servicio obtenerDatosUsuario del servicio web
ServiciosUsuario ................................................................................................................ 90
Figura 66. Ejemplo datos de entrada para el servicio darRelacionesUsuario del servicio
web ServiciosComunindad. ................................................................................................ 91
Figura 67. Ejemplo Respuesta del servicio darRelacionesUsuario del servicio web
ServiciosComunidad. .......................................................................................................... 91
Figura 68. Ejemplo datos de entrada para el servicio consultarSignosVitales del
servicio web ServiciosSignosVitales. ............................................................................ 92
Figura 69. Ejemplo datos de salida consultarSignosVitales del servicio web
ServiciosSignosVitales. ................................................................................................. 92
Figura 70. Generar cliente Web Service automáticamente paso 1. ............................................. 93
Figura 71. Generar cliente Web Service automáticamente paso 2. ............................................. 93
Figura 72.Generar cliente Web Service automáticamente paso 3. .............................................. 94
Figura 73. Resultado cliente Web Service. ................................................................................... 94
Figura 74 Instalación JBOSS Developer página de inicio. ........................................................... 103
Figura 75. Instalación JBOSS Developer seleccionar destino. .................................................... 103
Figura 76. Instalación JBOSS Developer seleccionar maquina virtual. ....................................... 104
Figura 77. Instalación JBOSS Developer Instalación. .................................................................. 104
Figura 78. Instalación JBOSS Developer instalacion completada. .............................................. 105
Figura 79. Instalación JBOSS Developer. ..................................................................................... 105
Figura 80. Abrir JBOSS Developer. .............................................................................................. 106
Figura 81. Seleccionar WorkSpace. ............................................................................................. 106
Figura 82. Configurar nuevo servidor. ........................................................................................ 107
Figura 83. Despliegue del servidor. ............................................................................................. 107
Figura 84. Importar Proyecto desde CVS. ................................................................................... 108
Figura 85 Seleccionar proyecto HealthBookNúcleoWS .............................................................. 109
Figura 86. Núcleo de la aplicación en JBOSS. .............................................................................. 109
Figura 87. Configuración del archivo build.xml. ................................................................... 110
Figura 88. Compilar el build.xml. ................................................................................................ 110
Figura 89. Accediendo a los servicios web. ................................................................................. 111
Figura 90. Servicios web de JBOSS. ............................................................................................. 111
Figura 91. Servicios web desplegados. ....................................................................................... 112
Figura 92. Importar cliente web HealthBook.............................................................................. 113
Figura 93. Despliegue del cliente web. ....................................................................................... 113
Figura 94. Pagina inicial de HealthBook. ..................................................................................... 114
1. INTRODUCCIÓN
En el mundo de hoy día el uso del Internet es cada vez es más importante. Es normal escuchar
hablar sobre esta tecnología permanentemente, de tal manera que se ha convertido en una
herramienta imprescindible en nuestras vidas. Su uso es tan natural que procesos tan
cotidianos como: hablar por teléfono, leer el correo electrónico, compartir información en
redes sociales, entre otros se realizan a través del internet.
A medida que el Internet ha venido creciendo y las fronteras se han ido acercando, es
imperativo hablar de cómo compartir información a nivel global y más aún en sectores tan
críticos como es el sector de la salud. En el entorno colombiano se encuentran gran variedad de
tratantes e instituciones que prestan servicios de salud, es importante que la información de los
diferentes pacientes que acceden a este servicio sea de fácil acceso y consistente a la vez,
debido a que un paciente puede estar recurriendo a diferentes instituciones de salud al mismo
tiempo y cada una manejando su propia información.
El proyecto HealthBook (Jiménez, et al., 2008) es una iniciativa para poder integrar la
información clínica de los pacientes a través de un esquema de una comunidad virtual (Red
Social). Dicho proyecto consiste en crear una red social entre los pacientes y los tratantes y de
esta manera ofrecer los servicios normales que una red social ofrece (Moreno, 2008).
Puesto que el proyecto HealthBook está dirigido principalmente a los pacientes, ofrece servicios
especializados como el de acceder su historia médica y proveer una comunicación informal y
práctica (Jiménez, et al., 2008).
El manejo de integración de la información por HealthBook se hace a través de estándares
definidos tales como el HL7 (HL7 Organization, 1987) llamado CDA (Clinical Document
Architecture)(Dolin, et al., 2004), el cual representa la historia clínica de un paciente a través de
un medio electrónico (Beltran, 2008). Se espera que al manejar un estándar internacional, la
aplicación sea compatible con otras aplicaciones que utilicen el mismo estándar.
La persistencia de la información se hace a través de Bases de datos nativas en XML, debido a
que la naturaleza de la información que se maneja es puramente XML (Extensible Markup
Language). A través de este servicio de persistencia de los datos (Carrizosa, 2008) (Beltran,
2008) se logra introducir toda la información médica generada por medio de un documento
CDA al sistema HealthBook (Carrizosa, 2008).
Es importante para HealthBook la adaptación y la aceptación de nuevas tecnologías. Por esta
razón este trabajo busca crear un cliente altamente interactivo, el cual explote todos los
servicios creados anteriormente. Además, cada vez son más los miles de usuarios que acceden
a internet en busca de un producto o servicio específico o en busca de alternativas o soluciones
para el manejo de información médica de una manera robusta como lo ofrece HealthBook. Es
por esto que el no tener una interfaz interactiva, supondría una gran desventaja para el
proyecto HealthBook, que lo haría quedar un paso atrás con respecto a las nuevas tecnologías y
mercados que cada vez se abren paso por medio del Internet.
Gracias al incremento de la penetración a nivel mundial y el aumento de velocidad de la red, la
web ha evolucionado y se han abierto nuevos campos de acción tales como hacer negocios
eficiente y rápidamente a través del internet. Las tecnologías web siguen en constante
evolución entregando nuevas experiencias a los usuarios, incrementando la utilidad de las
aplicaciones web y creando clientes web más interactivos.
Un cliente interactivo actualmente se desarrolla alrededor de las aplicaciones web
enriquecidas, las cuales nos ofrecen más servicios que una aplicación web normal. Para no ir
tan lejos se entiende este tipo de cliente como una mejora en la satisfacción e incremento de
productividad con la experiencia de interacción de los usuarios.
En este trabajo se diseña y construye un cliente interactivo para HealthBook. Para esta
implementación se propone manejar las últimas tecnologías ofrecidas actualmente por el
mercado.
En el Capítulo 2 se presenta los antecedentes y el estado del arte que impulsa el desarrollo del
proyecto. En el Capítulo 3 se describe el análisis del prototipo existente, objetivos propuestos
para este proyecto y la estrategia de solución. En el Capítulo 4 se describe la arquitectura
propuesta para la solución. En el Capítulo 5 se diseña la solución que cumple con los objetivos
propuestos. En el Capítulo 6 se desarrolla la implementación de la solución. En el Capítulo 7 se
presenta el análisis de los resultados. Se finaliza con el Capitulo 8 el cual presenta las
conclusiones del proyecto y trabajos futuros.
2. ANTECEDENTES Y CONTEXTO
“HealthBook nace con el propósito de construir un marco de trabajo con infraestructura móvil,
basada en web y grid, que ofrezca servicios de integración de información médica y de
integración de la comunidad alrededor del paciente “ (Jiménez, et al., 2008).
A medida que se ha trabajando en este mismo proyecto en diferentes proyectos de grado, se
ha ido construyendo todo un marco de desarrollo, el cual permite ofrecer diferentes servicios
para la implementación de la comunidad virtual de HealthBook.
HealthBook está dividido en cuatro componentes principales que se constituyen en el centro de
la aplicación, los cuales son:
Servicios de comunidad (HBCS): este componente satisface las necesidades, los
requerimientos funcionales y la implementación de los diferentes servicios que provee
una red social para la comunidad de usuarios de HealthBook. Estos servicios se pueden
resumir en la creación de relaciones entre usuarios de la aplicación y la posibilidad de
intercambiar información entre ellos (Moreno, 2008)
Servicios para los pacientes (HBPS): este componente se encarga de proveer la
funcionalidad de la administración de los pacientes dentro de la comunidad y, además,
del manejo de los eventos médicos de un paciente, los cuales constituyen la historia
clínica del paciente (Rincón, 2008).
Servicio de persistencia (HBFS): este componente es el encargado en persistir la
información manejada por HealthBook. Inicialmente el componente de persistencia de
HealthBook estaba construido a través de sistemas de archivos que almacena la
información por medio de archivos XML (HBFS). En estos archivos se guarda la
información clínica de cada paciente y paralelamente en otro archivo se guarda la
información relacionada con los datos manejados por los servicios de comunidad de
HealthBook. Para el manejo de la información clínica se utiliza el estándar HL7
especialmente el subconjunto CDA, ya que al manejar un esquema estándar se podrá
manejar la información de cada paciente de una manera organizada, y así garantizar el
acoplamiento de diferentes fuentes de información que tengan el mismo estándar,
haciendo posible tanto la importación como la exportación de información en el sistema
HealthBook (Beltran, 2008).
Servicio de persistencia por medio de base de datos (HealthBook Data Base System
HBDBS): este componente es la evolución del componente HBFS. HealthBook
implementa un mecanismo de almacenamiento a través de una base de datos nativa
XML, de esta manera ser más eficiente en la inserción, como también en las consultas
de los diferentes tipos de información almacenada por HealthBook. Este nuevo
componente maneja el mismo estándar CDA y corrige algunos errores en la
implementación de este estándar en el componente HBFS, logrando manejar
información valida según el estándar CDA. Para demostrar el funcionamiento de este
componente se implementó un nuevo componente o servicio llamado Signos Vitales
(Carrizosa, 2008).
Servicios Signos Vitales (HBVS): este nuevo componente explota las funcionalidades de
HBDBS ingresando información médica especializada en el sistema a través de los
servicios que ofrece HBDBS. Este componente es concebido como la primera aplicación
satélite de HealthBook (Carrizosa, 2008).
2.1 Arquitectura HealthBook
HealthBook fue diseñado en una arquitectura orientada a servicios que busca ofrecer un
sistema altamente escalable y separado en componentes que a su vez son invocados a través
de servicios web. En la Figura 1 se puede ver las capas de la arquitectura, las cuales consisten
en una capa de presentación, un núcleo de la aplicación que ofrece los diferentes servicios a las
capas superiores, y por último las aplicaciones satélite que consumen y extienden servicios que
ofrece el núcleo de la aplicación.
Figura 1. Estructura general de HealthBook.
Figura 2. Arquitectura general del núcleo de HealthBook (Carrizosa, 2008).
En la Figura 2 se presenta la arquitectura del núcleo de HealthBook, la cual cuenta con tres
componentes principales.
El componente de persistencia (HData): Como su nombre lo dice se encarga de persistir
la información manejada por HealthBook como también de realizar consultas de la
información deseada.
El núcleo (HCore) de la aplicación: Suministra las funcionalidades básicas de la aplicación
HealthBook.
Componente Magos: Este componente está completamente desarrollado y permite el
soporte para una infraestructura grid para HealthBook (Jiménez-Guarín, 2009).
Actualmente HealthBook es una aplicación independiente de Magos y su integración
constituye trabajo futuro del proyecto. El objetivo de este trabajo es la capa web de
HealthBook.
2.2 Estado del arte
Para el desarrollo del cliente interactivo de HealthBook se definen aspectos importantes que
permiten situarlo en el entorno actual de las aplicaciones web interactivas. A continuación se
define qué es una aplicación enriquecida, posteriormente se describe que es la Web 2.0 y el
concepto de usabilidad, finalizando con la presentación de las tecnologías y técnicas que harán
posible la implementación de un cliente interactivo para HealthBook.
2.2.1 Aplicaciones enriquecidas en el Internet (Rich Internet Applications RIA)
RIA (Deitel, y otros, 2008) es el resultado de una evolución gradual de la web que demuestra
una transformación inevitable de las aplicaciones web sobre el modelo de un cliente sin tanta
capacidad de procesamiento a través de un navegador simple, sin capacidad de interpretar
datos complejos que no van más allá de un HTML. Esta evolución hacia un cliente con más
capacidad de procesamiento ha generado navegadores más ricos y capaces de distribuir las
funciones del modelo cliente/servidor de una manera más eficiente. A medida que avanza esta
tecnología los usuarios experimentan nuevas aplicaciones implementadas con las tecnologías
de auge.
Recientemente, los desarrolladores de aplicaciones web han incursionado en el nuevo modelo
de desarrollo de aplicaciones web enriquecidas (RIA) pueden ser definidos como un híbrido de
las aplicaciones web y las aplicaciones de escritorio tradicionales, creando así cierta
independencia en el procesamiento de la información por parte del cliente y el mantenimiento
de algunos procesos por parte del servidor.
El contexto actual de esta nueva técnica se puede describir de la siguiente manera:
No se necesita instalación de nuevas aplicaciones para su correcto funcionamiento.
Las actualizaciones ocurren de manera automática y transparente para el usuario.
Es accesible desde cualquier computador conectado a internet con un navegador
estándar.
La comunicación con el servidor se hace de manera asincrónica.
Se hace procesamiento de la información por parte del cliente.
Se desea explotar la capacidad de procesamiento al lado del cliente.
Se realizan peticiones pequeñas por el cliente con respuestas pequeñas por el servidor.
Intercambio de mensajes XML por parte del cliente y el servidor.
La arquitectura propuesta para RIA es la siguiente:
Figura 3. Arquitectura propuesta para RIA (Deitel, y otros, 2008).
2.2.2 Web 2.0
Para definir qué es la Web 2.0 (WEB, 2009), se arranca de la definición de la Web 1.0.
La Web 1.0 es un tipo de web estática con documentos que no se actualizan, convirtiéndose en
una web de solo lectura y con una interacción casi nula por parte del usuario. Las animaciones
se hacen por medio de GIF sencillos como también etiquetas simples en HTML. Por ejemplo, la
etiqueta <marquee> daba una ilusión de un texto en movimiento, sin utilizar componentes
más avanzados como el uso de JavaScripts dentro de las páginas.
La Web 2.0 es el paso de una web estática donde la interacción con el usuario era muy
limitada, al paso de una web participativa, donde se puede compartir cualquier tipo de
información y conversar con los diferentes usuarios. Otro aspecto importante es la construcción
colectiva de los contenidos.
Esta evolución de la web cambia el enfoque de cómo un servidor web presta su servicio,
pasando de ser un servidor de páginas web planas, que ofrecen simples contenidos y donde el
usuario se limita a una interacción de llenar formularios y dar click en enlaces para leer la
información solicitada, a ser un servidor de herramientas informáticas donde el usuario
interactúa directamente con el contenido al crearlo y editarlo. Todas estas nuevas interacciones
con el usuario dan el valor agregado a un sitio web.
Esta nueva web surge como resultado de la evolución de las infraestructuras de comunicación
del Internet, así como también del avance de la capacidad de procesamiento de los
computadores que existen hoy en día y no sólo a las nuevas arquitecturas de desarrollo.
Esta nueva web, al implementar las nuevas técnicas para el desarrollo de páginas tales como
AJAX (Asleson, 2007), hace que su funcionamiento sea rápido y eficiente. Este nuevo enfoque
crea la posibilidad de la sindicación de contenidos, es decir que sitios webs tengan la capacidad
de incluir contenidos de otros sitios de forma automática y dinámica.
Really Simple Syndication (RSS) (Wittenbrink, 2005) es el estándar de la sindicación de
contenidos en la web. Permite extraer el contenido de una página web sin importar el diseño
de la página, codificando la información por medio un archivo XML. De esta manera, se
actualiza periódicamente a otro sitio web diseñado por terceros. Un ejemplo concreto del uso
del RSS es, eltiempo.com, el cual nos puede ofrecer sus últimas noticias actualizadas
constantemente por medio de esta canal de comunicaciones sin necesidad de acceder
directamente a la página de internet.
Figura 4. RSS www.eltiempo.com.
Figura 5. Respuesta del servicio RSS.
Por otro lado está la tecnología Mash Up (Wikipedia, 2009) que permite mezclar contenido de
páginas webs distintas y de esta manera crear una página final para el usuario. Esta técnica se
puede realizar sin poseer grandes conocimientos, debido a que muchas de estas aplicaciones
web publican APIs para su implementación y de esta manera consumir estos servicios.
Los Mash Ups más conocidos actualmente son los de utilizar los servicios de búsqueda que
ofrece Google (Google, 2009) como también el servicio de Google Maps (GoogleMaps, 2009).
Figura 6. Mash Up implementado por una aplicación con RichFaces.
2.2.3 Usabilidad
La interfaz web de HealthBook debe ser fácil y altamente intuitiva para los usuarios. Esto es
debido que HealthBook está orientado a cualquier tipo de usuarios, ya sean usuarios expertos o
inexpertos. Es por esta razón que el concepto de usabilidad cobra importancia en la
implementación del cliente web enriquecido de HealthBook.
Para una definición más formal sobre el término de usabilidad, la Organización Internacional
para la estandarización (ISO) (ISO, 2009) ofrece la siguiente definición:"La usabilidad se refiere a
la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el
usuario, en condiciones específicas de uso" (ISO, 2009). En esta definición se encuentra que la
usabilidad no solo depende de la aplicación sino también del usuario, es decir no se puede
manejar un concepto de usabilidad de una aplicación estudiándola de manera aislada para el
usuario final.
Al tener claro cuál es el concepto de usabilidad, el siguiente paso es encontrar el valor agregado
que aportaría este gran esfuerzo de crear una aplicación usable. Al mejorar la usabilidad de una
aplicación es decir la experiencia del usuario sobre la aplicación se encuentra que los usuarios
actuales de la aplicación quedan más satisfechos y la eficiencia en procesos cotidianos de la
aplicación aumenta; por lo consiguiente, la aplicación aumentará el número de nuevos usuarios
por la recomendación de usuarios actuales satisfechos.
El concepto de usabilidad en este trabajo sólo se está aplicando en el diseño de páginas web,
aunque es un tema pertinente a cualquier aplicación informática. A continuación se explican
algunos puntos relevantes para obtener una aplicación usable.
2.2.3.1 La facilidad del manejo de la aplicación
La facilidad del manejo de la aplicación: Es muy normal que en alguna aplicación un usuario
llegue a un punto donde no sabe cómo seguir avanzando o devolverse a un punto anterior. Esto
ocurre debido a que los diseñadores de la aplicación son usuarios expertos y además subjetivos
dejando de pensar como un usuario inexperto, pensado que cualquier paso es obvio aunque no
vean que es complicado dependiendo los niveles de experiencia de cada usuario. Actualmente
la mayoría de los usuarios están en continuo contacto sobre las aplicaciones informáticas pero
al encontrarse con nuevas aplicaciones no van a tener el nivel de conocimiento suficiente para
manejar la aplicación como un usuario experto. Es por esto que el diseñador de la aplicación
siempre debe suponer que los usuarios inexpertos deben lograr desenvolverse con la misma
facilidad de un usuario experto.
La facilidad es el corazón de la usabilidad, el éxito de cualquier aplicación radica en su facilidad
de uso y el cumplimiento de las expectativas del usuario especifico en otras palabras que sea
útil para el usuario.
Para lograr que una aplicación sea fácil de manejar es importante manejar las siguientes
características fundamentales (Brinck, et al., 2009).
Minimizar el número de menús: entre más simple mejor, se desea encontrar un
equilibrio al acceso rápido de la funcionalidad de la aplicación con el exceso de
opciones en una misma página.
Estructurar el contenido de la aplicación: al estructurar el contenido de la aplicación
logra una organización en la página que intuitivamente el usuario entenderá y de
esta manera evitar caminos sin salida o puntos sin retorno en la aplicación.
Además si se desea manejar los controles de navegación del navegador deben ser de una
manera clara que permitan hacer una navegación correcta, en dado caso que no se desea
utilizar dichos controles es primordial ofrecer controles alternativos que sean llamativos,
uniformes y que cumplan todas las funcionalidades que los controles estándar del navegador
ofrece.
2.2.3.2 Definir el esquema de la página
Si se quiere que el usuario identifique el contenido de la página en todo momento, tanto el área
principal de la página como la ubicación del menú principal deben aparecer de una manera
clara y consistente en todas las demás páginas por medio de un esquema. La página de inicio
debe tener el logo tipo de la aplicación visible. También es recomendable dar una breve
descripción del objetivo de la aplicación. De esta manera, a simple vista el nuevo usuario sabrá
si le interesa la aplicación o no.
Tener varios esquemas de página en la misma aplicación genera confusión y dificultad en el
usuario al no reconocer, por ejemplo, si todavía se encuentra en la aplicación inicial o no. Es por
esto que se recomienda manejar el mismo esquema de página en las demás páginas.
2.2.4 Infraestructura técnica y tecnológica
Para la implementación del nuevo cliente enriquecido se explica brevemente las diferentes
tecnologías ofrecidas actualmente en el mercado que pueden ser utilizadas en el desarrollo de
la aplicación.
2.2.4.1 JBOSS AS 4.2.3
JBOSS (JBOSS, 2009) es un servidor de aplicaciones web, implementado en Java, lo cual le
permite ser utilizado por cualquier sistema operativo que tenga una maquina virtual de Java
instalada. Este servidor también es un sistema de código abierto y puede ser utilizado sin
restricciones debido a su licencia libre. Finalmente, este sistema también combina tanto una
arquitectura orientada a servicios como una robustez para la implementación de aplicaciones
empresariales de alto alcance orientada para plataforma web.
El servido de aplicaciones de JBOSS es el número uno en servidores de aplicaciones que usan
Java. Debido a que es un código abierto, miles de desarrolladores profesionales continuamente
contribuyen con el desarrollo y mejoras de esta aplicación.
Las principales características que llevan a utilizar este tipo de servidor de aplicaciones son las
siguientes:
JBOSS permite desarrollar, desplegar e integrar servicios web en una Arquitectura
Orientada a Servicios, y al estar diseñado para una arquitectura SOA (Service Oriented
Architecture) puede ser utilizado por la aplicación HealthBook.
Su soporte completo en J2EE permite que la curva de aprendizaje entre los
desarrolladores de HealthBook sea mínima.
JBOSS cuenta con una gran documentación tanto para la administración como el
desarrollo de aplicaciones con tecnología J2EE.
El IDE soportado para el desarrollo de aplicaciones en JBOSS es Eclipse, el cual es muy
conocido y manejado por los desarrolladores de la aplicación HealthBook.
El núcleo de la aplicación de HealthBook está desarrollado con tecnología J2EE y
desplegado en un servidor JBOSS.
Soporta componentes ricos tales como RichFaces que son importantes para la
implementación del nuevo cliente web de HealthBook.
Al ser un servidor de aplicaciones reciente, utiliza las últimas tecnologías del mercado y
de esta manera facilitando futuras migraciones de la aplicación HealthBook.
2.2.4.2 JAVASCRIPT
JavaScript (Wilton, 2004) es un lenguaje de programación para aplicaciones web
dinámicas. Es un lenguaje de programación interpretado, es decir, no necesita una previa
compilación para ser ejecutado. Es por esto que cualquier navegador puede ejecutarlo en
tiempo real sin ninguna previa pre compilación del código.
A través de JavaScript se puede crear páginas dinámicas que interactúan directamente con
el usuario final de la aplicación, y de esta manera facilitar el uso una aplicación web, como
también la creación de componentes GUI reutilizables.
Hoy en día la mayoría de las páginas web utilizan JavaScript dentro del código de su
página. Por ejemplo, para no ir tan lejos, páginas tales como el correo electrónico, facebook, los
chat entre otros.
Al utilizar JavaScript dentro del nuevo cliente de HealthBook se aumenta la interactividad
de la aplicación como también la usabilidad de la página.
2.2.4.3 JSF
Antes que todo es importante explicar brevemente qué es el patrón MVC, debido a que es el
más usado para las aplicaciones web.
El patrón MVC (Modelo Vista Controlador) nos permite separar los tres componentes básicos
que lo conforman: controlador, modelo y la vista de nuestra aplicación (Gamma, et al., 2009).
Controlador: es el encargado de responder a los eventos generados por el usuario en la
Vista y de esta manera evitar que el usuario pueda realizar procedimientos que no son
permitidos en alguna etapa de la aplicación.
Vista: es la interfaz gráfica con la que el usuario interactúa, en otras palabras, es la
página web que accede el usuario cuando entra a una dirección específica.
Modelo: en el Modelo se encuentran los datos que maneja la aplicación así como las
diferentes reglas de negocio que permiten mantener una integridad de la información
manejada por la aplicación.
A continuación se muestra el flujo de los procesos de una aplicación que implementa el patrón
MVC (Ver Figura 7).
Figura 7. Flujo de una aplicación que utiliza el patrón MVC (Gamma, et al., 2009).
Después de aclarar qué es el patrón MVC, el siguiente paso es explicar qué son los JSF y cómo
utilizan el patrón MVC.
JSF (IBM, 2009) es un marco de trabajo basado en el patrón MVC, el cual pretende normalizar y
estandarizar el desarrollo de aplicaciones Web hechas en Java. Las páginas desarrolladas con
esta tecnología integran componentes complejos, los cuales son los encargados de interactuar
con el controlador de la aplicación. Posteriormente a través del servidor de aplicaciones se
genera una respuesta HTML con JavaScript embebido dentro de éste. Es por esto que
cualquier navegador puede interpretarlo y visualizarlo.
Cuando una aplicación se desarrolla en esta tecnología, se habla de un ciclo de vida, el cual
representa los procesos que acurren a través de un JSF. El ciclo de vida de una aplicación en JSF
tiene seis partes, las cuales se explican a continuación.
Restauración de vista (Restore view): es la primera fase del ciclo de vida del JSF.
Una petición es solicitada a través del controlador de la aplicación, este controlador
determina el nombre de la página que se está solicitando y crea una nueva vista de la
página, si aun no se encuentra creada para esa determinada petición.
Aplicar los valores de la petición (Apply request values): en esta fase se van
recorriendo todos los componentes del formulario siguiendo la jerarquía padre e hijo
entre los componentes y al mismo tiempo se recuperan los valores a partir de los
parámetros de la petición enviada al servidor.
Procesamiento de las validaciones (Process validations): esta fase consiste en
validación del dato suministrado por el usuario en función de las reglas definidas para el
componente.
Actualización de los valores del modelo (Update values model): esta fase es la
encargada de la asignación de los valores al bean, después de las respectivas
validaciones y ejecuciones de eventos por parte del usuario.
Invocar Aplicación (Invoke application): se llega a la fase la cual usa los valores
del bean para ejecutar la lógica de negocio y se llevan a cabo los procesos
correspondientes a los eventos ejecutados por el usuario.
Presentación de la respuesta (Render response): es la última fase del ciclo de vida
la cual despliega la vista de los componentes en su estado actual.
En la Figura 8 se presenta el ciclo de vida de un JSF con cada una de sus fases explicadas
anteriormente.
Para los desarrolladores de HealthBook JSF es una tecnología utilizada y ya conocida, lo cual es
una gran ventaja en términos de tiempo y curvas de aprendizaje, sumándole a esto las ventajas
sobre el desarrollo de aplicaciones web sobre esta tecnología que se acaban de mencionar.
Figura 8. Ciclo de vida de un JSF (IBM, 2009).
2.2.4.4 AJAX
Con el fin de entender el estado actual de las aplicaciones web, es necesario explicar la
arquitectura actual de las aplicaciones web tradicionales. Estas aplicaciones web tradicionales
se pueden dividir en dos tipos de aplicación (Asleson, 2007):
Aplicaciones ejecutadas al lado del servidor: son las típicas aplicaciones web en las
cuales todo el procesamiento de la información recae sobre el servidor. De esta manera,
cualquier solicitud efectuada por parte del cliente implica un tiempo de procesamiento
y de envio de la página web procesada por el servidor. A medida que el número de
solicitudes aumenta y la aplicación se vuelve más interactiva, lo que genera con un
mayor número de usuarios concurrentes. Se requiere que el servidor sea bastante
potente para logar mantener esta aplicación en línea. Este tipo de arquitectura hace que
el costo de mantenimiento sea insostenible a medida que el número de usuarios crece y
el tráfico de información aumenta. Así mismo, la escalabilidad de la aplicación de ve
afectada.
Aplicaciones ejecutadas del lado del cliente: este tipo de arquitectura plantea que la
mayoría del proceso de la información recae sobre el cliente. Esta manera minimiza el
intercambio de información por parte del servidor. De este modo, el servidor procesa
menos solicitudes y delega al cliente ciertas responsabilidades, las cuales puede ejecutar
autónomamente o con una mínima colaboración por parte del servidor. Al principio
estas nuevas aplicaciones utilizaban algunos programas adicionales, tales como ya
plug-ins, applets o active-x, para el buen funcionamiento de la página
dependiendo el grado de complejidad de la misma. Lo que hacía que estos programas, si
bien necesarios, se tornaran engorrosos para usuarios inexpertos en el uso de
aplicaciones interactivas.
Una solución que permite balancear la carga entre cliente y servidor, es utilizar una alternativa
intermedia como JavaScripts dentro de la página. Estos pueden ser interpretados por
cualquier navegador estándar, lo que le evita al usuario instalar programas adicionales a su
navegador predeterminado. Por estas razones nace AJAX (Asynchronous JavaScript And XML),
una nueva manera de crear aplicaciones web con ayuda de JavaScript. Gracias a este
nuevo medio se puede definir qué procesos se ejecutan del lado del cliente y qué información
es necesaria o requerida de lado del servidor.
La comunicación del servidor se implementa a través de mensajes cortos formateados en XML.
Estos mensajes son interpretados por el servidor retornando una respuesta formada en XML, la
que posteriormente es interpretada por el navegador para ser visualizada en la página. Puesto
que la respuesta no necesariamente es una página completa en cada petición del cliente, se
facilita el trabajo del servidor de aplicaciones, y de esta manera se puede atender a más
usuarios simultáneamente.
AJAX no es un lenguaje, ni tampoco una arquitectura, ni mucho menos una tecnología, es una
técnica de desarrollo de aplicaciones web que combina diferentes tecnologías ya existentes.
Una de sus principales características es el llamado de peticiones asincrónicas al servidor por
medio del JavaScript que se ejecuta del lado del cliente. En otras palabras, un usuario no
necesita recargar toda una página para que una pequeña zona de la página actualice o altere su
contenido, lo que puede bloquear la interacción actual del usuario con la página web. En
cambio, se hacen pequeñas peticiones asincrónicas en XML al servidor y se retorna una
repuesta XML, que el cliente se encarga de procesar y posteriormente modificar solamente en
la zona de la página especifica.
Figura 9. Diagrama de secuencia de una interacción normal cliente/servidor.
Figura 10. Diagrama de secuencia utilizando la técnica AJAX.
Como se puede ver en los diagramas de secuencia, en una aplicación web tradicional solamente
(Ver Figura 9) se puede enviar una solicitud una vez se haya recibido la respuesta, ya que el
servidor tiene que procesar la solicitud para generar una página web completa, y así enviarla
como repuesta de la solicitud para luego continuar con la siguiente petición. Al tener que
transferir páginas completas, el volumen de datos transferidos es muy alto, más aún si
contemplan escenarios donde cientos de usuarios hacen peticiones al mismo tiempo.
En el diagrama de la Figura 10 se puede ver cómo ser realizan diferentes solicitudes sin
necesidad de esperar la respuesta de la anterior. De una manera asincrónica, enviando
pequeños fragmentos XML y recibiendo como respuesta también un XML, le mejora la
velocidad de respuesta como también disminuye el tráfico y el procesamiento de información
por parte del servidor.
En conclusión, si se reduce el procesamiento y tráfico de la información por parte del servidor
con ayuda de AJAX, se pueden crear aplicaciones web más interactivas debido a que la
capacidad de procesamiento del servidor aumenta cuando se hacen pequeñas solicitudes.
Al utilizar esta técnica para el cliente web de HealthBook, se mejora el equilibrio de carga entre
el cliente y el servidor y poder así crear una aplicación altamente interactiva que es lo que se
desea.
2.2.4.5 RICHFACES
RichFaces (RichFaces, 2009) es un marco de trabajo de código abierto que añade la capacidad
de AJAX para aplicaciones JSF sin recurrir a la utilización de JavaScript directamente
embebido a nuestra página web.
Los beneficios al utilizar RichFaces son los siguientes:
Intensifica el beneficio sobre las páginas JSF al trabajar con AJAX. RichFaces se integra
completamente el ciclo de vida del JSF.
Al añadir la capacidad de AJAX sobre las aplicaciones en JSF, se establece un motor de
peticiones AJAX y de actualización de los componentes que conforman una página, sin
necesidad alguna de utilizar JavaScript por parte del diseñador de la página.
RichFaces permite la definición de eventos en las páginas, y así hace que un evento
invoque una petición AJAX.
Se pueden crear complejas vistas rápidamente gracias a los diferentes componentes que
ofrece RichFaces.
Permite ahorrar tiempo para los desarrolladores y de esta manera éstos se pueden
concentrar en la lógica de negocio.
Ofrece variedad de componentes altamente interactivos con el usuario y altamente
personalizables a través de hojas de estilo.
Ofrece un marco de desarrollo para diseñar sus propios componentes enriquecidos en
AJAX.
El marco de desarrollo de RichFaces es implementado como un componente que añade la
capacidad AJAX dentro de las páginas existentes de la aplicación; de esta manera, se encarga de
manejar todo el JavaScript necesario para implementar esta funcionalidad sin necesidad
de que el desarrollador necesite implementarlo por su propia cuenta. RichFaces, al soportar
todas las características de AJAX, permite que sus componentes sean totalmente compatibles
con peticiones AJAX y así actualizar determinada zona de la página que generó el evento por
parte del usuario (RichFaces, 2009) .
Figura 11. Funcionamiento de RichFaces (RichFaces, 2009).
Al permitir definir zonas por medio de etiquetas dentro de páginas JSF y al realizar una petición
por medio de AJAX, RichFaces permite la actualización de una zona del JSF sin necesidad de
recargar todo el contenido de la página. Todo lo anterior se logra sin necesidad de escribir
JavaScript o XMLHttpRequest por parte del programador, ya que esto se hace
automáticamente.
Figura 12. Arquitectura de RichFaces (RichFaces, 2009).
Ajax Filter: Es el filtro que se encarga en definir qué tipo de petición se hace al
servidor por parte del cliente y así decide si se hace por medio de una petición normal o
una petición AJAX.
AjaxAction Components: Son los diferentes componentes que pueden enviar
solicitudes al servidor del lado del cliente, por ejemplo, los <a4j:commandButton>,
los <a4j:commandLink>, y los <a4j:poll>, etc.
Ajax Containers: Es una interfaz que define que región de la página JSF debe ser
decodificada durante una petición AJAX.
RichFaces JavaScript Engine: RichFaces incluye un motor de JavaScript,
el cual se ejecuta del lado del cliente. Este motor maneja automáticamente la
actualización de las páginas que utilicen peticiones AJAX.
Al ofrecer RichFaces todos estos componentes ricos ya diseñados, con todo un marco de
desarrollo, HealthBook puede utilizarlos de una manera eficaz y sin gastar tiempo en el
desarrollo de componentes que podrían prestar el mismo servicio.
3. ANÁLISIS DEL PROTOTIPO EXISTENTE Y ESTRATEGIA DE SOLUCIÓN.
El objetivo general de este trabajo es implementar un cliente web el cual utilicen todos los
servicios ofrecidos por el núcleo de HealthBook por medio del uso de Servicios web. En trabajos
anteriores se han creado los diferentes servicios que ofrece HealthBook actualmente.
A continuación se analizan los aspectos relevantes para el desarrollo del cliente web de
HealthBook. Posteriormente se define los objetivos específicos y la estrategia de solución.
3.1 Análisis de la implementación de HBNucleo1.0
Para el desarrollo del cliente web de HealthBook, es necesario acceder a los servicios que
ofrece el núcleo de la aplicación a través de servicios web.
Actualmente HBNucleo1.0 expone tres servicios, los cuales son, servicios comunidad, servicios
usuario y servicios signos vitales. Estos servicios ofrecidos por el núcleo de la aplicación se
invocan a través de una cadena de texto en formato XML, que es mandada al servicio solicitado
y de la misma manera el servicio responde a través de una cadena de texto en formato XML.
Figura 13. Diagrama de componentes servicios web. HBNucleo1.0 (Beltran, 2008).
Como se observa en la Figura 13, existen tres componentes principales en la implementación
de los servicios web los cuales se explican a continuación:
XMLParser: Este componente es el encargado de analizar sintácticamente los datos
de entrada, y de esta manera reconstruir la información en objetos de negocio los
cuales serán utilizados posteriormente por el núcleo de la aplicación. Por otro lado
también este componente se encarga en generar texto en formato XML que contenga la
respuesta del servicio.
WebServices: Este componente se encarga de exponer los servicios y así que
cualquier aplicación pueda acceder a las funcionalidades que ofrece el núcleo de la
aplicación.
Servicios HealthBook: Este componente se encarga de suministrar la lógica de
negocio de la aplicación.
El principal problema de esta implementación se debe a las entradas y salidas de los servicios,
que son cadenas de texto planas y sin ninguna descripción de los datos. En otras palabras a
cualquier cliente que quiera utilizar los servicios del núcleo de HealthBook, no le es suficiente
utilizar el WSDL sino necesitará tener acceso al componente XMLParser, o un documento
técnico donde expliquen cómo poder utilizar los servicios ofrecidos por el núcleo de la
aplicación.
Por otro lado, el cliente que utilice estos servicios necesita implementar su propio componente
XMLParser para poder analizar sintácticamente las respuestas de los servicios utilizados,
convirtiéndose en un proceso totalmente engorroso para el cliente que desea utilizar estos
servicios.
Figura 14. Ejemplo descripción servicio ObtenerDatosUsuario.
En la Figura 14 se muestra la descripción del servicio obtenerDatosUsuario que se obtuvo
a través del WSDL. Se puede apreciar en la descripción que no aporta ninguna información
sobre los datos esperados en la entrada del servicio, siendo obligación del cliente conocer los
parámetros de entrada y la forma en que los espera el servicio (Ver Figura 15).
Figura 15. Ejemplo datos de entrada servicio obtenerDatosUsuario.
En la actualidad HBNucleo1.0 ofrece una manera de probar los servicios que actualmente
ofrece a través de una interfaz grafica desarrollada en JSF. Esta interfaz grafica no está
orientada para el uso de un usuario final, fue desarrollado con el objetivo único de mostrar la
funcionalidad del núcleo.
3.2 Objetivos Específicos
Los objetivos de este trabajo según el análisis previo son los siguientes:
Integrar los servicios ofrecidos por el núcleo del HealthBook por medio del nuevo cliente
web enriquecido.
Evaluar el desarrollo previo del proyecto HealthBook en cuanto a los requerimientos
funcionales y no funcionales ante la implementación de un cliente web enriquecido.
Migrar la aplicación de JBOSS 4.0 a JBOSS 4.2.3.
Rediseñar o adaptar los servicios ofrecidos por el núcleo HealthBook a su nueva
plataforma de desarrollo.
3.3 Estrategia de Solución
Para construir la estrategia de solución se utiliza las tecnologías mencionadas anteriormente
(Ver Capitulo 2.2) las cuales nos permiten el desarrollo del cliente web para HealthBook.
Con estas nuevas tecnologías se logra:
Exponer todos los servicios ofrecidos por el núcleo de HealthBook en el nuevo servidor
de aplicaciones JBOSS 4.2.3.
Utilizar los servicios ofrecidos por núcleo de HealthBook a través de un cliente de
manera fácil y sencilla por medio de la redefinición de las entradas de los servicios
ofrecidos por el núcleo de la aplicación.
Se implementa una aplicación altamente intuitiva y de fácil manejo y así su usabilidad
sea eficiente, por medio de RichFaces, JSF y AJAX.
Se maneja y se utiliza el concepto de usabilidad para el cliente web de HealthBook.
4. ARQUITECTURA DE LA SOLUCIÓN
El proyecto HealthBook está concebido para una Arquitectura Orientada a Servicios y de esta
manera logra separar los diferentes módulos que lo conforman por medio de componentes
(Ver Figura 1). Este trabajo se enfoca en la capa web de la aplicación, es decir, en la capa de
presentación y capa EJB.
Para la implementación del cliente se maneja una arquitectura J2EE la cual permite una
arquitectura de N niveles distribuidos, y la cual se basa en componentes y se ejecuta sobre un
servidor de aplicaciones.
A continuación se describen las capas que constituyen el diseño de la capa web (Ver Figura 16)
que es el objetivo principal de este trabajo.
Figura 16. Arquitectura J2EE para HealthBook.
4.1 Capa presentación
La capa de presentación (Ver Figura 16) es la encargada de manejar una interfaz grafica
altamente interactiva para el usuario final de la aplicación. Esta campa la conforma los
siguientes componentes que se explica a continuación.
4.1.1 RichFaces
Es el encargado de suministrar los diferentes componentes ricos que componen a las páginas y
de esta manera construir una interfaz grafica interactiva para el usuario. RichFaces se encarga
del manejo de las peticiones AJAX, esto lo logra a través de su arquitectura explicada en el
Capitulo 2.2.
Los principales componentes utilizados de RichFaces son los siguientes:
Push: Este componente es el encargado de mantener una conexión abierta entre el
servidor y el cliente de la aplicación y de esta manera hacer posible las notificaciones en
tiempo real y sin necesidad de recargar la página.
ActionParameter: Este componente se encarga de asignar valores a los atributos
del Bean por medio de una petición AJAX.
CommandButton: Este componente ofrece la funcionalidad de un botón normal de
una página web, pero con la posibilidad de hacer peticiones al servidor por medio de
AJAX y solo actualizando cierta zona de la página.
FileUpload: Este componente provee la funcionalidad de cargar archivos desde el
cliente de la aplicación hasta el servidor de la aplicación.
CommandLink: Este componente ofrece la funcionalidad de un link normal de una
página web, pero con la posibilidad de hacer peticiones AJAX al servidor y actualizar
únicamente las zonas de la página que son requeridas.
DataTable: Este componte es el encargado de ofrecer la funcionalidad de desplegar
información de una manera organizada por medio de una tabla.
Repeat: Este componte permite iterar sobre una variable y de esta manera recorrerla
y mostrar la información de la manera que uno desee.
SuggestionBox: Este componente ofrece la entrada de texto, con la capacidad de
predecir y sugerir a medida que el usuario digite el texto de entrada. De esta manera
selecciona el valor deseado de una manera más sencilla para el usuario. La capacidad de
sugerir el texto se hace a través de peticiones AJAX al servidor.
TableSorting: Este componente ofrece la funcionalidad de ordenar los datos de una
tabla ya sea numéricamente, por fecha o alfabéticamente.
MenuItem: Este componente ofrece la capacidad de crear menús en la aplicación y
además con la posibilidad de hacer peticiones AJAX.
Messages: Este componente ofrece la capacidad de visualizar mensajes generados
desde la capa EJB de la aplicación y de esta manera avisar al usuario sobre algún evento
acontecido ya sea de error o de éxito por parte de la aplicación.
ModalPanel: Este componente permite crear ventanas que se superponen sobre la
página y de esta manera obtener toda la atención del usuario sobre la ventana.
Panel: Este componente permite crear ventanas sobre una página.
TabPanel: Este componente permite agregar pestañas a una página y de esta manera
tener varias páginas en una sola página con solo navegar por medio de las pestañas.
Adicionalmente ofrece la funcionalidad de hacer peticiones AJAX.
Calendar: Este componente ofrece un calendario interactivo y amigable para el
usuario.
ComboBox: Este componente ofrece la entrada de texto, con la capacidad de predecir y
sugerir a medida que el usuario digite el texto de entrada. De esta manera selecciona el
valor deseado de una manera más sencilla para el usuario.
Editor: Este componente provee la posibilidad de la entrada de texto enriquecido por
medio de HTML de una manera sencilla para el usuario.
4.1.2 Manejador del idioma
El cliente web interactivo ofrece la posibilidad de soportar varios idiomas, y así visualizar la
interfaz grafica en el idioma por defecto del browser.
Este componente maneja archivos de propiedades lenguaje, en los cuales se encuentran los
diferentes valores que corresponden a una etiqueta especifica en su respectivo idioma. De esta
manera el servidor de aplicaciones selecciona el archivo correspondiente, dependiendo la
configuración del browser del usuario y permite visualizar la página en el idioma
correspondiente.
4.1.3 Manejador de plantillas y estilos
Este componente se encarga en suministrar la plantilla y así mismo el estilo que manejan las
diferentes páginas de HealthBook. Es importante manejar un estándar de visualización en la
aplicación, y de esta manera poder crear una imagen general ante el usuario.
El cliente web utiliza una hoja de estilos según en el estándar CSS (Croft, et al., 2009), de esta
forma garantizar uniformidad de colores y fuentes en las páginas. Por otro lado se definen
zonas de página por medio de una plantilla que todas las páginas deben seguir y así garantizar
una misma estructura de la visualización de la interfaz grafica.
4.1.4 Páginas Servicios Usuario
Este componente suministra las diferentes páginas que se necesitan para ofrecer toda la
interacción con el usuario. Estas páginas se basan sobre los servicios que le ofrece el bean
UsuarioBean y ValoresBean.
4.1.5 Páginas Comunidad
Este componente suministra las diferentes páginas que se necesitan para ofrecer toda la
interacción con el usuario. Estas páginas se basan sobre los servicios que le ofrece el bean
ComunidadBean y ValoresBean.
4.1.6 Páginas Signos Vitales
Este componente suministra las diferentes páginas que se necesitan para ofrecer toda la
interacción con el usuario. Estas páginas se basan sobre los servicios que le ofrece el bean
SignosVitalesBean.
4.1.7 Páginas InfoGeneral
Este componente suministra las diferentes páginas que se necesitan para ofrecer toda la
interacción con el usuario. Estas páginas se basan sobre los servicios que le ofrece el bean
PushHealthBookBean.
4.2 Capa EJB
Esta capa permite que múltiples aplicaciones tengan acceso de manera concurrente a la lógica
de negocio. Un EJB puede conectarse a cualquier capa aunque su misión esencial es conectarse
a la capa de los sistemas que le proveen la información necesaria para la lógica del negocio.
Figura 17. Diagrama de componentes que interactúan con la capa EJB.
Para la implementación del cliente web de HealthBook se manejan EJB, los cuales son los
responsables de la interacción directa con la capa de presentación de la aplicación. Esto se logra
a través de exponer las funcionalidades que ofrecen los Beans a la capa de presentación (Ver
Figura 17).
La capa EJB ofrece tres componentes que se explican a continuación:
BeansSesion: Este componente es el encargado de manejar los atributos o valores
que utilizan las diferentes páginas que lo llaman. Es también el encargado de capturar
los eventos que se generen desde la capa de presentación para su procesamiento en la
lógica de negocio. Por último al manejar la sesión de una conexión se garantiza para
cara usuario que acceda a la aplicación se cree una nueva instancia de este componente
y así ofrecer concurrencia en la aplicación.
Delegates: Al utilizar este componente se está usando el patrón Delegate, el cual
ayuda a reducir el acoplamiento entre la capa de negocio y la capa de presentación, es
decir, oculta los detalles de la implementación de la capa de negocio. De esta manera,
se reduce el número de cambios que se deben hacer en la capa de presentación cuando
se realicen cambios en el núcleo del servicio del negocio.
ClienteWS: Es necesario utilizar un componente el cual brinde un puente entre la
capa EJB y el núcleo de la aplicación. De esta manera se pueden acceder a los diferentes
servicios que ofrece el núcleo como a su lógica de negocio.
5. DISEÑO DE LA SOLUCIÓN
Para el diseño del cliente web enriquecido de HealthBook es necesario migrar la aplicación del
servidor aplicaciones JBOSS 4.0.2 a JBOSS 4.2.3. Esto es debido a que el servidor actual de la
aplicación, ya es un servidor desactualizado y el cual no soporta algunas de las principales
características requeridas para este trabajo.
En el Capitulo 5.1 se presenta el diseño del cliente web enriquecido, en el cual se profundiza en
los diferentes procesos que dan como resultado el objetivo de este trabajo.
En la migración de la aplicación en el nuevo servidor aplicaciones, se ve comprometida la
implementación de los servicios expuestos por el núcleo de HealthBook. Esto se debe a que la
implementación anterior de los servicios no es compatible con el nuevo servidor de
aplicaciones. Con el nuevo servidor de aplicaciones se rediseñan los servicios ofrecidos por el
núcleo de HealthBook debido a los problemas que se explican en el Capitulo 3.1. Esto se
presenta detalladamente en el Capitulo 5.2.
5.1 Diseño cliente web enriquecido HealthBook
Para el diseño del cliente web enriquecido, el diseño se centra en la capa de presentación y la
capa EJB (Ver Figura 16), que se explica en la arquitectura de la solución.
5.1.1 Capa presentación
La capa de presentación debe ser capaz soportar o suministrar las diferentes funcionalidades
que ofrece el núcleo de HealthBook. A continuación se presenta los principales puntos que se
tienen en cuenta en el diseño de la capa de presentación.
5.1.1.1 Diagrama de actividades del cliente enriquecido
Para el diseño de la capa de presentación es importante identificar los principales procesos de
negocio de HealthBook con el fin de desarrollar un cliente web enriquecido y funcional.
También este proceso se hace necesario con el objetivo de utilizar esta caracterización para
evaluar el cumplimiento de las funciones desempeñadas por los diferentes servicios
suministrados por la aplicación.
Figura 18. Diagrama de actividades de gestión de servicios eventos médicos.
Como se observa en el diagrama de actividades de la Figura 18 para los servicios de eventos
médicos, el proceso inicia con el ingreso del usuario al sistema con la respectiva validación.
Después de la validación el usuario decide si desea consultar un evento por medio del filtro de
eventos por fecha y así utilizar el servicio filtrar eventos por fechas ofrecido por el
núcleo. Si el usuario decide utilizar este servicio, se despliegan los eventos que cumplan esa
restricción dada por el usuario. Así mismo, se observan los datos básicos del evento como una
opción para poder ver detalladamente la información del evento seleccionado.
Si el usuario desea agregar un nuevo evento, la aplicación solicita los datos básicos para poder
ingresar un evento al sistema. Luego de ingresar estos datos se puede elegir entre ingresar una
prescripción o una observación y dependiendo del evento seleccionado se ingresarán al sistema
los datos suministrados para cada caso por parte del usuario. Al finalizar con el ingreso de los
datos, la aplicación solicita la confirmación del nuevo evento a agregar. Si el usuario decide
confirmar el evento, éste se almacena en el componente de persistencia de HealthBook. De no
ser así, se regresa de nuevo a los datos de entrada para la inscripción del nuevo evento.
Figura 19.Diagrama de actividades servicios de gestión de comunidad virtual.
En el diagrama de actividades de la Figura 19 para los servicios de comunidad, el proceso
también inicia a través del ingreso del sistema por parte del usuario con su respectiva
validación. Posteriormente el usuario decide qué servicio desea utilizar dentro de los cuales
puede elegir: crear nuevo mensaje, consultar mensajes no leídos, consultar mensajes enviados,
consultar todos los mensajes, agregar amigo y ver amigos.
Si se elige crear nuevo mensaje, se solicitan los datos del mensaje y sólo se pueden mandar
mensajes a los usuarios que actualmente son sus amigos. El nuevo mensaje puede ser en un
formato simple o enriquecido por medio de HTML.
Al consultar mensajes no leídos, se muestran dichos mensajes de una forma organizada. Sólo se
muestra la fecha y el asunto del mensaje. Existe la opción de observar todo el mensaje por
medio de un link que despliega el contenido del mensaje e internamente lo marca como leído
por el usuario.
En la opción consultar mensajes enviados, se muestran los mensajes organizados
alfabéticamente según el nombre del destinatario. Sólo se muestra el asunto y la fecha del
mensaje También existe la opción de observar todo el mensaje por medio de un link que
despliega el contenido del mensaje.
En la opción de leer todos los mensajes, se muestran tanto los mensajes leídos como no leídos
organizados por destinatario del mensaje. Únicamente se muestra la fecha y el asunto del
mensaje con la opción de observar todo el mensaje por medio de un link que despliega todo el
contenido del mensaje. Además de esto, hay la opción de marcar el mensaje como no leído o
eliminar el mensaje.
En la opción de buscar amigos, se tiene la posibilidad de buscar a cualquier usuario registrado
por medio del nombre. Al realizar la búsqueda se arrojan los resultados de los usuarios
encontrados que satisfacen la búsqueda, y se tiene la opción de hacer la solicitud de amistad si
se desea.
En la opción de ver amigos, se despliegan los amigos que actualmente están relacionados con el
usuario, y se tiene la opción de mandar un mensaje o eliminar al amigo de su lista de
relaciones.
Para finalizar, en la opción de solicitudes se despliegan las solicitudes pendientes del usuario, y
existe la opción de confirmar la solicitud o rechazarla.
Figura 20. Diagrama de actividades de gestión de signos vitales.
En el diagrama de actividades de la Figura 20 para los servicios de signos vitales, el proceso
también inicia a través del ingreso del sistema por parte del usuario con su respectiva
validación. Posteriormente el usuario decide qué servicio desea utilizar dentro de los cuales
puede elegir: importar documento CDA, exportar sección, exportar
documento CDA, ingresar signo vital y buscar signo vital.
Si se elige importar documento CDA, se abrirá una venta la cual dará la posibilidad de
buscar un documento de formato XML que desea importar al sistema, luego de seleccionarlo se
procederá a procesarlo por el sistema, generando un mensaje de éxito o de error si es el caso.
En la opción exportar sección, se dará la opción con un menú desplegable que sección
del documento desea exportar, luego de haber seleccionado se procederá a exportar el archivo
y de esta manera guardarlo por el usuario.
En la opción de exportar documento, se exportar el documento CDA en su totalidad,
dando la opción al usuario de guardar el documento.
Si se elige la opción de ingresar signo vital, se procederá a solicitar los datos
respectivos para ingresar el signo vital, posteriormente se recibe un mensaje de confirmación
por parte del sistema cuando se desea almacenar el nuevo signo vital.
En la opción buscar signo vita, se filtran los signos vitales dentro de un rango de fechas
dadas o también con la opción de visualizar todos los signos vitales que el usuario tenga en el
momento.
5.1.1.2 Definición de zonas de visualización e interacción
Es importante en las páginas definir zonas por medio de un template y así sean fácilmente
identificables por el usuario. Al definir zonas se logra manejar una estructura organizada en la
presentación de la información al usuario, acostumbrando al usuario a una misma interfaz lo
que hace que el uso de la página sea más intuitivo y natural para el usuario. De esta manera
logramos aumentar la usabilidad de la página.
Se definen seis zonas que siempre aparecen al incoar la sesión en el cliente. A continuación se
explican cada una de las zonas que se observan en la Figura 21.
Encabezado (Header): Se encuentra el logo de la página, el cual dará al usuario la
sensación al usuario que aun se encuentre de la misma aplicación.
Menu: En esta zona ira siempre ubicado el menú principal de la aplicación.
Contenido principal: En esta zona se desplegara la información relacionada con las
diferentes interacciones que realice el usuario.
Notificaciones: En esta zona se mostrara las diferentes notificaciones que recibirá el
usuario.
Noticias: Sera una zona de publicidad para nuevas aplicaciones que se integren al
sistema.
Pie de página (Footer): En esta zona se encontrará información relacionada a
HealthBook.
Figura 21. Diagrama de zonas de página.
El estilo de páginas manejadas dentro del contenido principal, utiliza pestañas en la parte
superior de cada página. De esta manera permite una fácil navegación dentro de los diferentes
servicios que presta cada aplicación de HealthBook, sin necesidad de recurrir directamente al
menú principal ofreciendo diferentes alternativas para llegar a un mismo sitio (Ver Figura 22).
Figura 22. Estructura del contenido principal de una página.
5.1.1.3 Manejo de estilos soporte multilenguaje
Se maneja hoja de estilo de acuerdo con el estándar CSS (Croft, y otros, 2009) y de esta manera
garantiza la uniformidad de la presentación de la información dando a la página un carácter de
identidad como de imagen fácilmente reconocible para los usuarios. Algunos de los aspectos
principales en el manejo del estilo de la página son de manejar colores claros y que se
combinen o complementen de una manera agradable al usuario.
Para el soporte de diferentes idiomas se utiliza un archivo de propiedades para cada idioma que
soporta la aplicación y posterior utilización dentro las páginas. Otra ventaja al utilizar un archivo
de propiedades de lenguaje es que al realizar cualquier cambio sobre el archivo, éste se ve
reflejado automáticamente sobre las páginas que estén utilizando esa etiqueta específica.
Figura 23. Archivo de propiedades de idioma español.
Figura 24. Ejemplo de utilización de las propiedades de lenguaje.
5.1.2 Capa EJB
La capa EJB es la responsable de la interacción directa con la capa web de la aplicación. Se usa
un patrón Delegate, el cual ayuda a reducir el acoplamiento entre la capa de negocio y la
capa de presentación, es decir, oculta los detalles de la implementación de la capa de negocio.
De esta manera, se reduce el número de cambios que se deben hacer en la capa de
presentación cuando se realicen cambios en el núcleo del servicio del negocio.
Para el diseño del cliente web se manejan tres componentes que hacen parte de esta capa y
que a continuación se explican detalladamente.
Figura 25. Componentes de la capa EJB.
5.1.2.1 Beans
Los beans son el componente superior de esta capa. Su principal objetivo es la interacción con
la capa web y tomar valores a los diferentes eventos que se generen desde la capa web.
Para el cliente web de HealthBook utilizo seis clases de este componente que se explican a
continuación.
5.1.2.1.1 La clase MenuBean
La clase MenuBean es la encargada de manejar los valores del menú que selecciona el usuario
y de esta manera se despliega la página seleccionada y se activa la pestana seleccionada. Sus
principales atributos son:
actual: Se almacena la pestaña que debe ser seleccionada cuando se pulsa alguna
opción del menú principal de la página.
menuSuperior: Se almacena la página que debe ser desplegada al seleccionar una
opción del menú.
Figura 26. Diagrama de clase MenuBean.
5.1.2.1.2 La clase ComunidadBean
La clase ComunidadBean es la encargada de manejar todos los valores e interacción con los
diferentes eventos asociados a los servicios de comunidad. Sus principales atributos son:
loginUsuario: Almacena los datos del usuario que inicio sesión.
mandarMensajeNuevo: Almacena los datos del nuevo mensaje que el usuario desea
mandar.
misAmigos: Almacena los datos básicos de los amigos del usuario.
Delegator: Es el encargado de delegar los servicios ofrecidos.
relacionesUsuario: Se obtienen los datos de las relaciones que tiene actualmente
el usuario.
nombresAmigos: Almacena los nombres de los amigos actuales del usuario.
mensajesNoLeidos: Almacena los mensajes no leídos del usuario.
mensajesEnviados: Almacena los mensajes enviados del usuario.
mensajesTodos: Almacena todos los mensajes del usuario leídos como no leídos.
solicitudiesAmigos: Almacena las solicitudes pendientes del usuario.
Figura 27. Diagrama de clase ComunidadBean.
5.1.2.1.3 La clase PushHealthBookBean
La clase PushHealthBookBean es la encargada de hacer las diferentes notificaciones al
usuario, tales como, notificar nuevos mensajes, notificar nuevas solicitudes, notificar nuevos
eventos. Sus principales atributos son:
mensajesSolicitudes: Se almacena el mensaje que será notificado al usuario
cuando se tenga nuevas solicitudes.
mensajesMensaje: Se almacena el mensaje que será notificado al usuario cuando se
tenga nuevos mensajes.
mensajesEventos: Se almacena el mensaje que será notificado al usuario cuando se
tenga nuevos eventos.
delegatorUsuario: Es el encargado de delegar los servicios ofrecidos por
serviciosUsuario y de esta manera poder saber en qué momento se tienen
nuevos eventos.
delegatorComunidad: Es el encargado de delegar los servicios ofrecidos por
serviciosComunidad y de esta manera poder saber en qué momento se tienen
nuevos mensajes o solicitudes.
Actualmente el núcleo de HealthBook no ofrece servicios de notificaciones, por esta razón la
implementación de esta clase no es óptima. Es aconsejable replantear su implementación en el
momento que el núcleo soporte servicio de notificaciones.
Figura 28. Diagrama de clase PushHealthBookBean.
5.1.2.1.4 La clase SignosVitalesBean
La clase SingosVitalesBean es la encargada de manejar todos los valores e interacción
con los diferentes eventos asociados a los servicios de signos vitales. Sus principales atributos
son:
delegator: Es el encargado de delegar los servicios ofrecidos por
serviciosSignosVitales.
criterioExpor: Se almacena el valor por el cual desea el usuario hacer la
exportación de signos vitales.
exportCriteria: Están almacenados los diferentes criterios que puede utilizar el
usuario para exportar un signo vital.
criterioNombreSV: Se almacena el valor del criterio del signo vital que el usuario
desea agregar.
valor1: Se almacena el valor del signo vital.
valor2: Se almacena el valor del signo vital.
criterioUnidadSV1: Se almacena el valor de la unidad del signo vital.
criterioUnidadSV2: Se almacena el valor de la unidad del signo vital.
vitalSignNombresCriteria: Están almacenados los diferentes criterios que
pueden ser utilizados por el usuario al ingresar un signo vital.
vitalSignUnidadesCriteria: Están almacenados los diferentes unidades que
pueden ser utilizados por el usuario al ingresar un signo vital.
consultarFechas: Se almacena el valor de las fechas para realizar posteriormente
una búsqueda de signos vitales.
misSignosVitales: Se almacena el resultado de una búsqueda de signos vitales.
signoVitalActual: Se almacenan los datos de ingreso de un nuevo signo vital.
Figura 29. Diagrama de clase SignosVitalesBean.
5.1.2.1.5 La clase UsuarioBean
La clase UsuarioBean es la encargada de manejar todos los valores e interacción con los
diferentes eventos asociados a los servicios de usuario. Sus principales atributos son:
delegator: Es el encargado de delegar los servicios ofrecidos por
serviciosUsuario.
miUsuarioActual: Almacena los datos del usuario que inicio sesión.
loginUsuario: Almacena los datos para iniciar sesión.
miUsuarioNuevo: Almacena los datos para ingresar un nuevo usuario.
resultadoTransaccion: Almacena el resultado de efectuar alguna transacción.
consultarFechas: Almacena la fecha para realizar una búsqueda.
listaObservacionesActual: Almacena la lista de observaciones que ha sido el
resultado de una búsqueda.
listaPrescripcionesActual: Almacena la lista de prescripciones que ha sido el
resultado de una búsqueda.
listaEventosGenerica: Almacena la lista de eventos genérica que ha sido el
resultado de una búsqueda.
eventoObservacionActual: Almacena los datos de la observación actual.
eventoPrescripcionActual: Almacena los datos de la prescripción actual.
Figura 30. Diagrama de clase UsuarioBean.
5.1.2.1.6 La clase ValoresBean
La clase ValoresBean es la encargada de manejar todos los valores que serán usados por
diferentes criterios de selección que maneja la aplicación. Sus principales atributos son:
valoresDocumentos: Almacena los diferentes criterios de selección que el usuario
puede escoger par un documento.
valoresSexo: Almacena los diferentes criterios de selección que el usuario puede
escoger para el sexo de una persona.
documentosUsuariosAttendant: Almacena los diferentes tratantes que el
usuario puede escoger.
unidadesPrescripciones: Almacena los diferentes criterios de selección que el
usuario puede para las unidades de una prescripción.
Hasta el momento, estos valores están atados en el código del bean. Para futuras trabajos se
sugiere que estos valores sean ofrecidos por el núcleo de la aplicación y sean llamados a través
de servicio web. De esta manera el bean pueda tomar estos valores a través de su
delegate.
Figura 31. Diagrama de clase ValoresBean.
5.1.2.2 Delegates
El objetivo de los delegates es proveer los diferentes servicios a los beans y de esta
manera satisfacer los diferentes eventos generados en la capa de presentación. Esto lo logra a
través un cliente de servicios web que es el encargado de comunicarse directamente con los
servicios web del núcleo de HealthBook.
Para el cliente web de HealthBook, este componente está formado por tres clases que
explicaremos a continuación.
5.1.2.2.1 La clase VitalSignsServicesDelegate
La clase VitalSignsServicesDelegate es la encargada de suministrar todos los
servicios a los beans, que ofrece ServiciosSignosVitales del núcleo de HealthBook.
Los servicios que provee esta clase son los siguientes:
consultarTodosLosUsuario: Consulta los nombres de todos los usuarios.
exportarCDACompleto: Exporta todo el documento CDA.
importarCDACompleto: Importa documento CDA.
exportarSeccion: Exporta sección del documento CDA.
ingresarSignoVital: Ingresa un nuevo signo vital.
consultarSignosVitalesTodos: Consulta todos los signos vitales de un usuario.
consultarSignosVitalesFecha: Consulta los signos vitales de un usuario dentro
de un rango de fecha.
Figura 32. Diagrama de clase VitalSignsServiceDelegate.
5.1.2.2.2 La clase UserServicesDelegate
La clase UserServicesDelegate es la encargada de suministrar todos los servicios a los
beans, que ofrece ServiciosUsuario del núcleo de HealthBook.
Los servicios que provee esta clase son los siguientes:
inscribirUsuario: Inscribe un nuevo usuario a la aplicación.
obtenerDatosUsuario: Obtiene los datos básicos del usuario para iniciar sesión.
filtrarEventosUsuario: Filtra los eventos de un usuario dada una regla.
agregarEventoUsuario: Agrega un nuevo evento a un usuario.
Figura 33. Diagrama de clase UserServicesDelegate.
5.1.2.2.3 La clase CommunityDelegate
La clase CommunityDelegate es la encargada de suministrar todos los servicios a los
beans, que ofrece ServiciosComunidad del núcleo de HealthBook.
Los servicios que provee esta clase son los siguientes:
buscarUsuario: Busca usuarios dado un nombre.
consultarMensajesNoLeidos: Consulta los mensajes no leídos de un usuario.
consultarMensajesUsuario: Consulta todos los mensajes de un usuario.
consultarSolicitudesPendientes: Consulta las solicitudes pendientes de un
usuario.
darRelacionesUsuario: Consulta las relaciones de amistad de un usuario.
eliminarMensaje: Elimina un mensaje del usuario.
eliminarRelacion: Elimina una relación de amistad.
enviarMensaje: Envía un mensaje creado por el usuario.
marcarMensajeComoLeido: Marca un mensaje como leído.
marcarMensajeComoNoLeido Marca un mensaje como no leído.
relacionarUsuarios: Relaciona dos usuarios.
Figura 34. Diagrama de clase CommunityDelegate.
5.1.2.3 Cliente WS
Para hacer la comunicación con los servicios web expuestos por el núcleo de HealthBook, se
realiza a través de un cliente autogenerado por un plugin de Eclipse. Dado que este
componente corresponde a clases generadas de forma automática, no se describen en el
diseño de la aplicación. En el Capitulo 6.4 se presenta como se genera este cliente de manera
automática.
A través de este cliente los delegators consumirán los servicios que son ofrecidos por el
núcleo de la aplicación.
5.2 Servicios web del núcleo de HealthBook
Una de las ventajas en la migración de la aplicación al nuevo servidor de aplicaciones, es
delegar la función del análisis sintáctico de la información tanto de los datos de entrada como
de salida por parte del servidor de aplicaciones.
Este beneficio se consigue a través de la definición de objetos simples, sin ninguna lógica de
negocio en los cuales sólo se almacenan información del objeto. Estos objetos se convierten en
las entradas y salidas de los servicios expuestos por parte de la aplicación. De esta manera el
servidor de aplicaciones automáticamente mapea y crea su respectiva descripción en XML.
Otro beneficio es que al generar una descripción más detallada del WSDL por medio de objetos
negocio simple, el cliente que desea utilizar estos servicios no necesita implementar su propio
componente de análisis sintáctico para las diferentes respuestas de obtenga del servicio. Esto
es debido a que, por medio del WSDL, se pueden reconstruir los diferentes objetos de negocio
manejados por el servicio. De esta manera se oculta en ambas partes, tanto para el cliente
como la aplicación, el procesamiento interno que realiza el servidor sobre los XML que
representan los objetos de negocio.
Para la implementación de los diferentes servicios se definieron clases simples sin ninguna
lógica de negocio que son utilizadas para la implementación del servicio.
Servicios web ServiciosUsuario
Nombre de la clase Nombre del atributo Tipo de dato Descripción
ComparationWSBO tipoComparacion String Comparación que indica si un evento cumple o no una opción.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EstadoRespuestaWSBO respuesta String Respuesta manejada tas invocar un servicio, ya sea un mensaje de éxito o una excepción generada por el servicio.
codigoRespuesta int Código numérico que representa el mensaje generado tras la invocación del servicio.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
OptionWSBO comparation ComparationWSBO Comparación de los eventos.
elemento String Elemento que es comparado.
valor String Valor de referencia.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
RuleWSBO opciones List
<OptionWSBO>
Lista de opciones que compone la regla.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EventFilterWSBO reglas List <RuleWSBO> Lista de reglas para aplicar un filtro sobre los eventos.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EventPrescriptionWSBO perido int Periodo para la toma
de cada dosis. Peridounidad String Unidad de tiempo del
periodo. dosis int Dosis de la
medicación. dosisUnidad String Unidad de la Dosis. nombreGenerico String Nombre genérico del
medicamento nombreComercial String Nombre Comercial
del medicamento. numeroTomas int Numero de tomas de
la dosis definida.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EventObservationWSBO titulo String Datos de la observación
Nombre de la clase Nombre del atributo Tipo de dato Descripción
ListaEventosW
SBO
listaEventObservation
WSBO
List<EventObservationW
SBO>
Lista de observaciones.
listaEventPrescriptio
nWSBO
List<EventPrescription
WSBO>
Lista de prescripciones.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EventsRespuestaWSBO listaEventosWSBO ListaEventosWSBO Clase que contiene eventos.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EventWSBO fecha Date Fecha del evento texto String Texto del evento tratante IdUserWSBO Id del tratante paciente IdUserWSBO Id del paciente
Nombre de la clase Nombre del atributo Tipo de dato Descripción
IdUserWSBO tipoIdUsuario int Representación
numérica del tipo de documento.
idUsuario long Número de identificación.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
PatientWSBO idUser IdUserWSBO Clase que identifica los datos de un usuario.
nombre String Nombre del paciente. apellidos String Apellidos del
paciente. fechaNacimiento Date Fecha de nacimiento
del paciente. sexo String Sexo del paciente.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
PatientBasicWSBO idUser IdUserWSBO Clase que identifica los datos de un usuario.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
PatientRespuestaWSBO idUser IdUserWSBO Clase que identifica los datos de un usuario.
nombre String Nombre del paciente.
apellidos String Apellidos del paciente.
fechaNacimiento Date Fecha de nacimiento del paciente.
sexo String Sexo del paciente.
Las clases que contienen la palabra respuesta son las salidas de los servicios y cada una
extiende la clase ResultadoRespuesta.
Servicios web ServiciosComunidad
Nombre de la clase Nombre del atributo Tipo de dato Descripción
UsuarioWSBO idUser IdUserWSBO Clase que identifica los datos de un usuario.
nombre String Nombre del paciente. apellido String Apellidos del
paciente.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
PatientBasicWSBOCS idUser IdUserWSBO Clase que identifica los datos de un usuario.
nombre String Nombre del paciente.
apellido String Apellidos del paciente.
especialidad String Especialidad del paciente.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
PatientBasicWSBOCS2 idUser IdUserWSBO Clase que identifica los datos de un usuario.
nombre String Nombre del paciente.
Nombre de la clase Nombre del atributo
Tipo de dato Descripción
RelacionesUsuariosWSB
O
usuario1 PatientBasicWSBOCS
2
Datos básicos usuario1.
usuario2 PatientBasicWSBOCS
2
Datos básicos usuario1.
typeRelatio
n
int Datonumérico que representa el tipo de la relación.
idRelacion long Identificadornumérico de la relación.
estado boolean Representa si la relación está
establecida o está pendiente.
Nombre de la clase Nombre del atributo
Tipo de dato Descripción
RespuestaConsultaNombreUsuarioW
SBO
misUsuario
s
PatientBasicWSBOC
S2
Datos básicos del usuario.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EnviarMensajeWSBO sender PatientBasicWSBOCS2 Datos básicos de la persona que envía.
receiver PatientBasicWSBOCS2 Datos básicos de la persona que recibe.
fecha int Fecha del mensaje. id long Identificadornumérico
del mensaje status boolean Representa si el
mensaje se encuentra leído.
texto String Texto del mensaje. sujeto String Asunto del mensaje
Nombre de la clase Nombre del atributo Tipo de dato Descripción
EstadoRespuestaWSBO respuesta String Respuesta manejada tas invocar un servicio, ya sea un mensaje de éxito o una excepción generada por el servicio.
codigoRespuesta int Código numérico que representa el mensaje generado tras la invocación del servicio.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
RespuestaMensajeUs
uarioWSBO
mensajesUsuario LinkedList<Enviar
MensajeWSBO>
Lista de mensajes.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
RespuestaRelacione
sUsuarioWSBO
misUsuarios LinkedList<usuari
oWSBO>
Lista de usuarios.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
RespuestaBusquedaU
suariosWSBO
misUsuarios LinkedList<usuari
oWSBO>
Lista de usuarios.
Las clases que contienen la palabra respuesta son las salidas de los servicios y cada una
extiende la clase ResultadoRespuesta.
Servicios web SignosVitales
Nombre de la clase Nombre del atributo Tipo de dato Descripción
CDWSBO status String Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
Nombre de la clase Nombre del atributo Tipo de dato Descripción
CompWSBO numeratorUnit String Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
denominatorUnit String Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
valueDen int Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
valueNum int Recibe información
relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
Nombre de la clase Nombre del atributo Tipo de dato Descripción
PQWSBO numeratorUnit String Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
valueNum int Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
Nombre de la clase Nombre del atributo Tipo de dato Descripción
RTO_PQ_PQWSBO numeratorUnit String Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
denominatorUnit String Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
valueDen int Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa, 2008).
valueNum int Recibe información relacionada con el tipo de signo vital para más información consultar (Carrizosa,
2008).
Nombre de la clase Nombre del atributo Tipo de dato Descripción
ConsultarFechasWSBO fechasDesde Date Recibe una fecha inicial.
fechasHasta Date Recibe una fecha final.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
IdUserWSBO tipoIdUsuario int Representación numérica del tipo de documento.
idUsuario long Número de identificación.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
IdUser2WSBO tipoIdUsuario String Representación tipo caracter del tipo de documento.
idUsuario long Número de identificación.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
PatientBasicWSBO idUser IdUserWSBO Clase que identifica los datos de un usuario.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
ResultCodeWSBO mensaje String Respuesta manejada tas invocar un servicio, ya sea un mensaje de éxito o una excepción generada por el servicio.
codigo int Código numérico que representa el mensaje generado tras la invocación del servicio.
Nombre de la clase Nombre del atributo
Tipo de dato Descripción
RespuestaSignosVital
esWSBO
misSignos LinkedList<SignosVita
lesWSBO>
Lista signos vitales.
Nombre de la clase Nombre del atributo
Tipo de dato Descripción
RespuestaUsuariosWSB
O
misUsuari
os
LinkedList<IdUser2WSB
O>
Lista de usuarios.
Nombre de la clase Nombre del atributo
Tipo de dato Descripción
RespuestaTipoUsuario
WSBO
userType String Tipo de usuario.
Nombre de la clase Nombre del atributo Tipo de dato Descripción
SignosVitalesWSBO tipo String Tipo signo vital. name String Nombre signo vital. date Date Fecha signo vital. signoPqwsbo PQWSBO Información signo
vital. signoCdwsbo CDWSBO Información signo
vital. signoRto_pq_pqwsbo RTO_PQ_PQWSBO Información signo
vital. signoCompwsbo CompWSBO Información signo
vital.
Las clases que contienen la palabra respuesta son las salidas de los servicios y cada una
extiende la clase ResultCodeWSBO.
6. IMPLEMENTACIÓN
Para la implementación del cliente web enriquecido se utiliza la versión 5 de Java. Tanto los
servicios web como el cliente web se montan utilizando el servidor de aplicaciones JBOSS 4.2.3
GA. El ambiente de desarrollo utilizado es JBoss Developer Studio versión 2.0 y adicionalmente
se utilizó SoapUI V 2.5. 1. para las pruebas de los servicios web.
Para el manejo de la interfaz gráfica del cliente enriquecido se utilizó RichFaces (RichFaces,
2009), el cual suministra diversos componentes ricos para la aplicación web.
6.1 Estructura de archivos del cliente enriquecido
La estructura general del cliente enriquecido se parte en tres paquetes principales, los cuales se
observan en la Figura 35.
Figura 35. Estructura de archivos del cliente enriquecido
Paquete SRC
Es el responsable de la comunicación entre la interfaz gráfica del cliente y la lógica de
aplicación, en otras palabras, es la capa EJB de la aplicación.
Paquete comunicacionWS
Es el cliente generado para el consumo de los servicios web ofrecidos por el núcleo de
HealthBook, y el cual proveerá la lógica de negocio para la capa de presentación del cliente
enriquecido de HealthBook a través de la capa EJB.
Paquete WebContent
Es la capa de presentación del cliente enriquecido. En este paquete se encuentran las páginas
web de la aplicación, hojas de estilo, imágenes utilizadas, los archivos de idioma y la
configuración de la aplicación a través de los archivos que se encuentran en la carpeta WEB-
INF. Todo esto se puede observar en la Figura 36.
Figura 36. Estructura de archivos del paquete WebContent.
6.2 Diseño de la demostración del cliente web enriquecido
A continuación se muestra el resultado obtenido tras la implementación del cliente web
enriquecido.
6.2.1.1 Página de inicio HealthBook
En la Figura 37 se observa la vista de la página de inicio de HealthBook. En esta página se
encuentra la opción de ingresar al sistema y la de inscribirse si aún no se encuentra registrado.
Figura 37. Página de inicio HealthBook.
Si el usuario no se encuentra registrado, se retorna un mensaje de error informando que no se
puede iniciar sesión como se observa en la Figura 38.
Figura 38. Página de inicio HealthBook ingreso no exitoso.
Si se desea registrar un nuevo usuario, se deben ingresar todos los datos solicitados y luego
presionar el botón Registrar. Si el registro es exitoso se recibe un mensaje de éxito por parte del
sistema, como se observa en la Figura 39.
Figura 39. Página de inicio HealthBook inscripción usuario.
De igual manera si el usuario ya se encuentra inscrito, se recibe un mensaje de error por parte
del sistema.
6.2.1.2 Página de bienvenida.
En la Figura 40 se observa el resultado al iniciar una sesión. Se inicia la sesión mostrando los
datos básicos del cliente en la parte del contenido principal de la página. En la parte superior se
encuentra el menú de la aplicación con las diferentes opciones que se pueden realizar en la
página. En la parte izquierda se encuentra un servicio de noticias y también un espacio para
promocionar futuras aplicaciones que se integren al cliente HealthBook.
Figura 40. Página de bienvenida posterior de iniciar sesión.
Se observa en la Figura 41 y Figura 42 la ubicación del menú principal de la página y como se
despliegan las diferentes opciones que se encuentran actualmente implementadas.
Figura 41. Menú principal ubicación general.
Figura 42. Menú principal despliegue de opciones.
6.2.1.3 Página Historia Clínica
En la página Historia clínica se observa los datos básicos datos del usuario con la
opción de filtrar eventos por fecha. Se despliega un calendario dando la opción de elegir una
fecha de una manera sencilla y natural al usuario (Ver Figura 43). Posteriormente se despliegan
los resultados del filtro aplicado y se observa este resultado en la tabla eventos (Ver Figura
44).
Figura 43. Despliegue del calendario.
Figura 44. Resultado filtrar eventos por fecha.
Al pulsar el vinculo Ver más, se despliega la información detallada del evento asociado,
opacando la parte de atrás de la página y resaltando la información del evento (Ver Figura 45).
Figura 45. Ver información detallada evento.
6.2.1.4 Página Agregar nuevo evento.
En la página Agregar nuevo evento ofrece los servicios de crear nuevos eventos para
un usuario, tales como, agregar prescripción o agregar una observación.
Se realizo de tal forma que el usuario tenga que llenar los datos solicitados y así pasar al
siguiente paso para continuar con el proceso de crear un nuevo evento (Ver Figura 46).
Luego de haber llenado los datos necesarios tanto para una observación (Ver Figura 47) o una
prescripción (Ver Figura 49) se solicitara la confirmación del evento y de esta manera ser
almacenado en el sistema (Ver Figuras 48 y 50 ).
Figura 46. Datos básicos para ingresar nuevo evento.
En la Figura 47 se observa el campo para llenar los datos de una nueva observación si es el caso.
En caso en que se desea es crear una prescripción, el campo de observación se deja en blando y
se pulsa el botón Desea agregar prescripción.
Figura 47. Datos de la observación.
Figura 48. Confirmación de los datos de la observación.
Figura 49. Datos solicitados para crear una prescripción.
Figura 50. Confirmación de los datos de una prescripción.
6.2.1.5 Página enviar mensaje
En la página Enviar mensaje ofrece enviar un mensaje a los amigos que el usuario tiene
actualmente. Estos mensajes pueden ser simples o enriquecidos por medio de HTML, debido a
que se incorpora un editor de texto avanzado que permite la manipulación del texto de manera
sencilla para el usuario (Ver Figura 51).
Figura 51. Página mandar nuevo mensaje.
Únicamente es posible enviar mensajes entre usuarios que están relacionados. En el campo
Destinatario incorpora texto predictivo, es decir, a medida que el usuario va digitando las
iníciales del nombre, la aplicación le sugiere aquellos amigos que cumplen esa condición (Ver
Figura 52).
Figura 52. Página mandar nuevo mensaje despliegue sugerencias usuario.
Cuando el usuario presiona el botón de enviar se abre una ventana con una vista preliminar del
mensaje y de esta manera el usuario puede confirmar el envio del mensaje o cancelarlo para
poder volver a editarlo como se puede ver en la Figura 53.
Figura 53. Página confirmar envio de nuevo mensaje.
6.2.1.6 Página ver mensajes no leidos
En la página Ver mensajes no leidos se muestran los mensajes nuevos del usuario o
que no han sido leídos. Los mensajes se encuentran organizados por remitente y fecha del
mensaje, además se muestra solo el asunto del mensaje con un link para ver el mensaje
completo (Ver Figura 54).
Figura 54. Página ver mensajes no leídos.
Cuando el usuario presión el link Leer mensaje completo se despliega todo el mensaje
e internamente marcando el mensaje como leído (Ver Figura 55). Cuando un mensaje es
marcado como leído desaparecerá la próxima vez que se consulten los mensajes no leídos.
Figura 55. Página ver mensajes no leídos mensaje completo.
6.2.1.7 Página mensajes enviados
En la página Mensajes enviados se muestran los mensajes enviados por el usuario. Los
mensajes se encuentran organizados por destinatario y fecha del mensaje, además se muestra
solo el asunto del mensaje con un link para ver el mensaje completo (Ver Figura 56).
Figura 56. Página mensajes enviados.
Cuando el usuario presión el link Leer mensaje completo se despliega todo el mensaje
(Ver Figura 57).
Figura 57. Página mensajes enviados ver mensaje completo.
6.2.1.8 Página mensajes
En la página Mensajes se muestran los mensajes leídos como no leídos. Los mensajes se
encuentran organizados por remitente y fecha del mensaje. Solo se muestra el asunto del
mensaje con un link para ver el mensaje completo, además se ofrecen dos opciones, marcar
como no leído y eliminar mensaje (Ver Figura 58).
Figura 58. Página mensajes.
Cuando el presiona Leer mensaje completo se despliega todo el mensaje de igual manera que
en la Figura 57. Si el usuario presiona Marcar como no leído la aplicación internamente marca el
mensaje como no leído y volverá aparece en los mensajes no leídos. Por último la opción
Eliminar mensaje no está funcionando debido a problemas del núcleo que ofrece este servicio.
6.2.1.9 Página agregar amigo
En la página Agregar amigo se encuentra la opción de buscar a algún usuario (Ver Figura
59), la búsqueda se realiza dando parte del nombre o algún conjunto de letras.
Figura 59. Página agregar amigo.
Cuando se realiza una búsqueda se despliegan los resultados que satisfacen la búsqueda y de
esta manera daño la opción de hacer una solicitud de amistad al usuario deseado (Ver Figura
60).
Figura 60. Página agregar amigo resultado búsqueda.
6.2.1.10 Página de signos vitales
La página inicial de signos vitales (Ver Figura 61) se encuentra tres servicios los cuales son:
Desea importar un signo vital: Importa un documento CDA valido, el cual será validado y
almacenado por el sistema.
Desea exportar una sección de información: Exporta una sección del documento CDA
que el usuario desee.
Exportar historia completa: Exporta todo el documento que contiene la información del
usuario relacionado a su historia médica en un formato CDA valido.
Figura 61. Página de inicio de signos vitales.
6.2.1.11 Página insertar nuevo signo vital
En la página de insertar nuevo signo vital ofrece la posibilidad de ingresar nuevos signos vitales
al sistema. Para conocer el correcto funcionamiento para insertar un nuevo signo vital pueden
consultar a (Carrizosa, 2008).
Figura 62. Página insertar signo vital.
6.2.1.12 Página Consultar signos vitales
Esta página permite consultar los signos vitales de un usuario. Ofrece un filtrar los eventos
entre un rango de fechas dado o consultar todos los signos vitales como se puede ver en la
Figura 63.
Figura 63. Página consultar signos vitales.
6.3 Servicios web HealthBook HBNucleo2.0.
Para observar el resultado de la redefinición de los servicios web ofrecidos por el núcleo de la
aplicación, se muestra a continuación algunos ejemplos de los servicios web del núcleo.
Figura 64. Ejemplo datos de entrada para el servicio obtenerDatosUsuario del servicio
web ServiciosUsuario.
Figura 65. Ejemplo respuesta del servicio obtenerDatosUsuario del servicio web
ServiciosUsuario
Figura 66. Ejemplo datos de entrada para el servicio darRelacionesUsuario del servicio
web ServiciosComunindad.
Figura 67. Ejemplo Respuesta del servicio darRelacionesUsuario del servicio web
ServiciosComunidad.
En la Figura 66 se observa que en los datos de entrada hay un parámetro llamado Nombre, el
cual acepta cualquier tipo de dato sin importar que la información sea correcta respecto a los
demás parámetros de entrada. Además este tipo de inconsistencia no afecta la ejecución
normal del servicio. Esta inconsistencia se debe a que sólo se modificó la capa superior del
servicio basándose en los datos de entrada que utilizaba la versión anterior del servicio.
Figura 68. Ejemplo datos de entrada para el servicio consultarSignosVitales del
servicio web ServiciosSignosVitales.
Figura 69. Ejemplo datos de salida consultarSignosVitales del servicio web
ServiciosSignosVitales.
6.4 Implementación de un cliente para los Servicios web de HealthBook
Se implementa un cliente que consuma los servicios ofrecidos por HealthBook. Este cliente se
implementa de manera automática por medio de los diferentes plugins que ofrece cualquier
distribución estándar de eclipse, en esta caso se utiliza Eclipse Ganymede.
A continuación se explica cómo se genera un cliente de manera automática por medio de
Eclipse para su posterior uso en el cliente web enriquecido de HealthBook.
Figura 70. Generar cliente Web Service automáticamente paso 1.
Figura 71. Generar cliente Web Service automáticamente paso 2.
Luego de crear un nuevo proyecto y seguir los pasos explicados en la Figura 70 y la Figura 71, se
procede a ingresar la dirección de los WSDL (Ver la Figura 72) y posteriormente a presionar el
botón Finish.
Figura 72.Generar cliente Web Service automáticamente paso 3.
El resultado final se puede apreciar en la Figura 73. Se observa la reconstrucción de los objetos
simples descritos anteriormente.
Figura 73. Resultado cliente Web Service.
7. ANÁLISIS DE RESULTADOS
Como resultado de este trabajo se desarrolla un cliente web enriquecido para HealthBook que
usa las últimas tecnologías y técnicas utilizadas actualmente para el desarrollo de aplicaciones
web interactivas y que accede a los servicios del núcleo a través del uso de servicios web. Este
trabajo también rediseño los servicios web expuestos por el núcleo de HealthBook, obteniendo
una descripción clara a través del WSDL del servicio. De esta manera, cualquier aplicación
externa que acceda a estos servicios podrá hacerlo de una manera rápida y sencilla.
La migración de la aplicación a la nueva versión de JBOSS fue satisfactoria. Además de estar
corriendo en una versión más actual del servidor de aplicaciones, abre las puertas a otras
tecnologías tales como portlets que pueden ser utilizadas en futuros trabajos sobre
aplicaciones satélites de HealthBook. Por otro lado, en futuras migraciones de la aplicación su
impacto no será tan alto debido a que no es la última versión de este servidor de aplicación sino
la versión anterior que se encuentra actualmente en el mercado y es la más estable en este
momento, a diferencia de la versión que tenia la aplicación anteriormente, la cual era muy vieja
(principios del 2005).
La implementación del servicio de notificaciones en el cliente web no es óptima. Esto es debido
a que el núcleo de la aplicación actualmente no ofrece estos tipos de servicios. Si bien es
objetivo de este trabajo validar y migrar el núcleo de HealthBook HBNucleo1.0, esta fuera del
alcance esperado la implementación de nuevos servicios o corrección los problemas
encontrados en este componente. A continuación se documenta el estado de los diferentes
servicios web que actualmente expone el núcleo de la aplicación HBNucleo2.0.
Lamentablemente no se pudo implementar todos los servicios expuestos por el núcleo de
HealthBook debido a diferentes errores que tiene el núcleo de la aplicación en la
implementación de la lógica del servicio. A continuación se presentan el estado actual de los
diferentes servicios ofrecidos por la el HBNucleo2.0.
Servicios web ServiciosUsuario
Nombre del servicio Descripción del servicio Observaciones del servicio
agregarEventoUsuario Agrega un evento dado un usuario y la información requerida para el almacenamiento del evento.
Funciona correctamente.
cargarUsuario Carga un usuario dado. No se utilizo este servicio
debido a que se decidió que los WS no manejan sesión y era un servicio expuesto el cual cargaba los datos de un usuario y los almacenaba en memoria dentro de una sesión.
cerrarUsuario No hay información clara sobre este servicio.
No se utilizo este servicio debido a que se decidió que los WS no manejan sesión y era un servicio expuesto el cual cargaba los datos de un usuario y los almacenaba en memoria dentro de una sesión.
convertirPacienteATratante Convierte un paciente a tratante.
Su funcionamiento es correcto aunque el atributo fielId no lo está manejando se sugiere revisar su implementación.
eliminarUsuario Elimina un usuario. Su funcionamiento es correcto eliminando el usuario del sistema.
filtrarEventosUsuario Filtra los eventos dependiendo de alguna regla dada.
Su funcionamiento es correcto.
inscribirUsuario Ingresa un nuevo usuario al sistema HealthBook.
Su funcionamiento es correcto.
modificarDatosUsuario Modifica los datos de un usuario dado.
Su funcionamiento es correcto.
mostrarEventosUsuario Mostrar todos los eventos de un usuario.
No esta funcionando. Verificar su implementación.
obtenerDatosUsuario Obtener los datos de un usuario.
Presenta problemas respecto al parámetro de respuesta numero de cedula ya que siempre lo trae en “0” se sugiere verificar su implementación.
usuarioEsTratante Verifica si un usuario es tratante.
No está funcionando. Verificar su implementación.
Servicios web ServiciosComunidad
Nombre del servicio Descripción del servicio Observaciones del servicio
agregarUsuarioActivo Carga un usuario dado. No se utilizo este servicio debido a que se decidió que los WS no manejan sesión y era un servicio expuesto el cual cargaba los datos de un usuario y los almacenaba en memoria dentro de una sesión.
buscarTratante Busca a un tratante. No está funcionando. Verificar su implementación.
buscarUsuario Busca un usuario. Su funcionamiento es correcto.
consultarMensajesAmigoUsuario Muestra los menajes entre un amigo y el usuario.
No está funcionando. Verificar su implementación.
consultarMensajesNoLiedos Muestra los mensajes no leídos de un usuario.
Su funcionamiento es correcto.
consultarMensajesUsuario Muestra todos los mensajes de un usuario
Su funcionamiento es correcto.
consultarNombreUsuario Muestra el nombre del usuario que ha sido consultado.
Su funcionamiento es correcto.
consultarSolicitudesPendientes Muestra las solicitudes pendientes de un usuario.
Su funcionamiento es correcto.
darPacientesTratante Muestra los pacientes de un tratante.
No está funcionando. Verificar su implementación.
darRelacionesUsuario Muestra las relaciones de un paciente.
Su funcionamiento es correcto.
darTratantesPaciente Muestra los tratantes de un paciente.
No está funcionando. Verificar su implementación.
eliminarMensaje Elimina un mensaje de un usuario.
No está funcionando. Verificar su implementación.
eliminarRelacion Elimina la relación entre usuarios.
No está funcionando. Verificar su implementación.
eliminarUsuarioActivo Elimina usuario activo. No se utilizo este servicio debido a que se decidió que los WS no manejan sesión y era un servicio expuesto el
cual cargaba los datos de un usuario y los almacenaba en memoria dentro de una sesión.
enviarMensaje Envía un mensaje a un usuario.
Su funcionamiento es correcto. Es deber del cliente que lo implementa no generar un id repetido.
marcarMensajeComoLeido Marca un mensaje como leído.
Su funcionamiento es correcto.
marcarMensajeComoNoLeido Marca un mensaje como no leído.
Su funcionamiento es correcto.
relacionarUsuarios Relaciona usuarios Su funcionamiento es correcto. Es deber del cliente que lo implementa no generar un id repetido.
Servicios web ServiciosSignosVitales
Nombre del servicio Descripción del servicio Observaciones del servicio
consultarSignosVitalesFecha Muestra los signos vitales de un usuario dada una fecha.
Su funcionamiento es correcto.
consultarSignosVitalesTodos Muestra todos los signos vitales de un usuario.
Su funcionamiento es correcto.
consultarTipoUsuario Muestra el tipo de usuario. Su funcionamiento es correcto.
darListaPacientes Muestra todos los pacientes. Su funcionamiento es correcto.
exportarCDACompleto Exporta documento CDA completo de un usuario.
Su funcionamiento es correcto.
exportarSeccion Exporta sección del documento CDA de un usuario.
Su funcionamiento es correcto.
importarCDACompleto Importa documento CDA completo de un usuario.
Su funcionamiento es correcto.
ingresarSignoVital Ingresa un nuevo signo vital a un usuario.
Su funcionamiento es correcto.
Finalmente el manejo de excepciones por parte del núcleo de HealthBook no está funcionando,
se han implementado clases para este manejo pero desafortunadamente no se están
propagando hasta las capas superiores, impidiendo de esta forma saber qué tipo de error se
produce en algún tipo de proceso.
8. CONCLUSIONES Y TRABAJO FUTURO
El desarrollo del cliente web enriquecido es satisfactorio porque cumple los objetivos
propuestos al principio del documento. El nuevo cliente de HealthBook implementa las nuevas
tecnologías y técnicas ofrecidas actualmente por el mercado.
El nuevo cliente, al desarrollarse en un servidor de aplicaciones reciente, soporta la utilización
de las últimas tecnologías y la integración de las mismas. Esto permite que trabajos futuros
puedan seguir siendo implementados sobre este servidor de aplicaciones. Dado el caso de una
futura migración de la aplicación a una nueva versión del servidor, su impacto no será tan alto.
Con la integración del nuevo cliente web enriquecido, se logra tener una versión de la
aplicación totalmente funcional y que puede ser utilizada sin ningún tipo de restricción,
permitiendo usar la mayoría de los servicios que ofrece el núcleo de HealthBook.
Rediseñar y verificar la implementación de los servicios ofrecidos por el núcleo de HealthBook
podría ser una opción de trabajo futuro, y así integrarlos de manera efectiva al cliente
interactivo de HealthBook.
Otro trabajo a desarrollar para la aplicación de HealthBook es la integración de las aplicaciones
satélite que se pueden ir agregando al cliente web enriquecido por medio de portlets, por
ejemplo.
Para finalizar, otra área a explorar es la implementación efectiva de servicios de notificación por
parte del núcleo de HealthBook. Aunque actualmente están implementados unos servicios de
notificación en el cliente web de HealthBook, su implementación no es la óptima, ya que
actualmente el núcleo no soporta estos servicios.
9. BIBLIOGRAFIA
Asleson, Ryan. 2007. Foundations of Ajax. 2007.
Beltran, Juan David. 2008. INTERFAZ DE SERVICIOS Y VALIDACION DE DATOS PARA PROYECTO
HEALTHBOOK. Bogotá : s.n., 2008.
Brinck, Tom, Gergle, Darren and Wood, Scott D. 2009. Usability for the Web: Designing Web
Sites that Work . 2009.
Carrizosa, Manuel Andres. 2008. SERVICIO DE DATOS SOA PARA ARQUITECTURAS EXTENSIBLES:
DISEÑO E IMPLEMENTACIÓN DE HEALTHBOOK DATA SERVICES. Bototá : s.n., 2008.
Croft, Jeff, Lloyd, Ian and Rubin, Dan. 2009. Pro CSS Techniques (Pro) . 2009.
Deitel, Paul J. and Deitel, Harvey M. 2008. AJAX, Rich Internet Applications, and Web
Development for Programmers . 2008.
Dolin, R. H., et al. 2004. Clinical Document Architecture Release 2.0. Recuperado el 02 de Enero
de 2009, de http://xml.coverpages.org/CDA-Release2-Unofficial.html . 2004.
Gamma, Erich, et al. 2009. Design Patterns: Elements of Reusable Object-Oriented Software.
2009.
Google. 2009. Recuperado el 15 de Mayo del 2009, de Google Code:
http://code.google.com/intl/es-ES/apis/ajaxsearch/. 2009.
GoogleMaps. 2009. Recuperado el 15 de Mayo del 2009, de Google Code:
http://code.google.com/intl/es-ES/apis/ajaxsearch/. 2009.
HL7 Organization. 1987. Health Level 7. Recuperado el 6 de Noviembre de 2008, de
http://www.hl7.org. 1987.
IBM, JSF. 2009. Recuperado el 15 de Mayo del 2009, de IBM:
http://www.ibm.com/developerworks/java/library/j-jsf2/. 2009.
ISO. 2009. Recuperado el 22 de Mayo de 2009, de ISO: http://www.iso.org/iso/home.htm. 2009.
JBOSS. 2009. Recuperado el 15 de Mayo del 2009, de JBOSS ORG:http://www.jboss.org/. 2009.
Jiménez, C, Bravo, G and Castro, H. 2008. HealthBook: Red social de información de salud,
centrada en el paciente. Bogotá : Univerisidad de los Andes, 2008.
Jiménez-Guarín, Claudia Lucía. 2009. The MAGOS Project: Middleware for easy and standard
development of SOA grid applications, Proceedings of the First EELA-2 Conference. Bogotá,
February 25-27 2009. Bogotá : s.n., 2009.
Moreno, Marcial Antonio. 2008. REDES SOCIALES APLICADAS A LA SALUD - DISEÑO E
IMPLMENTACIÓN DE HEALTHBOOK COMMUNITY SERVICES HBCS. Bogotá : s.n., 2008.
RichFaces. 2009. Recuperado el 15 de Mayo del 2009, de RichFaces: http://www.jboss.org/file-
access/default/members/jbossrichfaces/freezone/docs/devguide/en/html/ArchitectureOvervie
w.html. 2009.
Rincón, Miguel Alejandro. 2008. CONSTRUCCIÓN DE HBPS: HEALTHBOOK PATIENT SERVICES,
UNA SOLUCION DE ALMACENAMIENTO DE HISTORIAS CLINICAS EN LA RED SOCIAL
HEALTHBOOK ENFOCADA A LA SALUD. Bogotá : s.n., 2008.
Wikipedia. 2009. Recuperado el 12 de Mayo, de Wikipedia:
http://es.wikipedia.org/wiki/Mashup_(aplicaci%C3%B3n_web_h%C3%ADbrida). 2009.
—. 2009. Recuperado el 22 de Mayo del 2009, de Wikipedia:
http://es.wikipedia.org/wiki/Usabilidad. 2009.
Wittenbrink, Heinz. 2005. RSS and Atom: Understanding and Implementing Content Feeds and
Syndication: A clear and concise guide to strategy, structure, selection with in depth technical of
feed formats and XML vocabularies. 2005.
ANEXO
DESPLIEGUE DE LA APLICACIÓN
ESPECIFICACIONES TECNICAS
Servidor de aplicaciones: JBOSS 4.2.3 GA
Base de datos: Base de datos nativa XML eXist V1.2.
Lenguaje: Java, JDK-1_5_0_17.
Tecnologías:
o J2EE
o Servicios web
Frameworks:
o Facelets
o JSF
o RichFaces V 3.2.1
o APIs eXist
IDEs:
o JBOSS Developer V 2.0
Otros:
o SoapUI V 2.5. 1 para pruebas funcionales sobre los servicios web.
INSTALACION DEL ENTORNO DE DESARROLLO
Instalacion JBOSS Developer.
En la carpeta ambiente seleccionar archivo “jbdevstudio-eap-win32-2.0.0.CR2-
R200901291303.jar”. Antes de la instalación de JBOSS Developer es necesario haber instalado
el JDK 1.5-017 que también se encuentra en la carpeta de ambiente.
Figura 74 Instalación JBOSS Developer página de inicio.
Figura 75. Instalación JBOSS Developer seleccionar destino.
Figura 76. Instalación JBOSS Developer seleccionar maquina virtual.
Figura 77. Instalación JBOSS Developer Instalación.
Figura 78. Instalación JBOSS Developer instalacion completada.
Figura 79. Instalación JBOSS Developer.
Figura 80. Abrir JBOSS Developer.
Figura 81. Seleccionar WorkSpace.
9.1.1.1 Configurar servidor.
Luego de haber instalado JBOSS Developer el automáticamente también instala el servidor de
aplicaciones que se utiliza. En la pestaña server se encuentra el servidor de aplicaciones listo
para hacer desplegado.
Figura 82. Configurar nuevo servidor.
Figura 83. Despliegue del servidor.
Es importante que la primera vez que se realiza el despliegue del servidor y concluya
exitosamente, se detenga y se procesada a añadir las librerías requeridas para la aplicación de
HealthBook, esto sucede debido a que en la primera ejecución del servidor el crea unas
carpetas necesarias para su funcionamiento y si modificamos las librerías antes de hacer un
despliegue es posible que el servidor omita el paso de crear estas carpetas por lo tanto el
servidor quedara mal configurado.
En la carpeta de ambiente se encuentra una carpeta llamada libServidorJboosDev el
cual contiene un zip. Este zip debe ser descomprimido en la ruta que está instalado el
servidor, en nuestro caso la ruta es la siguiente: C:\jbdevstudio\jboss-eap\jboss-
as\server\default. En esta carpeta se descomprime el zip sobrescribiendo la carpeta
lib.
9.1.1.2 Núcleo de la aplicación.
Conectarse al repositorio de la aplicación, los datos de conexión son los siguientes:
Host: chie.uniandes.edu.co
Path: /u2/pregrado/tesis/ja-moya
Tipo de Conexión: extssh
Usuario: ja-moya
Pwd:2wsx4rfv
Seleccione: HealthBookNúcleoWS
Figura 84. Importar Proyecto desde CVS.
Figura 85 Seleccionar proyecto HealthBookNúcleoWS
Figura 86. Núcleo de la aplicación en JBOSS.
Luego de importar el proyecto satisfactoriamente se procede en desplegar el servidor y
configurar el archivo build.xml del núcleo de la aplicación. En la Figura 87 se muestra la ruta que
para nuestro caso se encuentra instalado el servidor y que debe ser configurado en el
build.xml.
Figura 87. Configuración del archivo build.xml.
Figura 88. Compilar el build.xml.
Después de haber compilado el build.xml y desplegar el servidor exitosamente se comprueba
que los servicios del núcleo se encuentran arriba. Para comprobar que los servicios fueron
correctamente desplegados ingresamos a: http://localhost:8080/jbossws/.
Al ingresar a esta dirección se pide un nombre de usuario y contraseña las cuales son
respectivamente son: “admin” y “admin” (sin comillas).
Figura 89. Accediendo a los servicios web.
Figura 90. Servicios web de JBOSS.
Luego de acceder a los servicios web de JBOSS se selecciona View a list of deployed
services el cual muestra que servicios se encuentran arriba (Ver Figura 91).
Figura 91. Servicios web desplegados.
Luego de corroborar que los servicios se encuentran arriba se procede a desplegar la base de
datos eXist (Para la configuración y despliegue de la base de datos de eXist consultar
anexos de (Carrizosa, 2008)).
9.1.1.3 Despliegue del cliente web de HealthBook
Se procede a importar a JBOSS Developer el proyecto que se encuentra en la carpeta
clienteWebHealthBook (Ver Figura 92).
Figura 92. Importar cliente web HealthBook.
Luego de importar el proyecto satisfactoriamente se procede a desplegar el cliente web de
HealthBook (Ver Figura 93).
Figura 93. Despliegue del cliente web.
Para acceder a la aplicación es necesario utilizar Firefox para un correcto funcionamiento de
la misma. La dirección de la aplicación es la siguiente: http://localhost:8080/HealthBookWeb/.
Figura 94. Pagina inicial de HealthBook.
