Hoy en día es perfectamente normal hablar de redes en las que conviven dispositivos que no están totalmente conectados a Internet, tales como teléfonos móviles, PDA’s, etc. En definitiva toda una clase de dispositivos heterogéneos. Las tendencias actuales en investigación indican que todos estos dispositivos se conectaran en muy pocos tiempo a redes con ancho de banda muy superior a las líneas de teléfono actual, al mismo tiempo estas redes tendrán acceso multi-modal (IPv6, xDSL, CATV, Wi-fi, fibra óptica), con lo cual la se multiplicará la conectividad de los dispositivos. El nuevo paradigma de la tecnología de la información bajo este entorno es lo que actualmente se ha dado en llamar redes ubicuas. La palabra "Ubicuo" define la cualidad de "existir en cualquier lugar simultáneamente". Las redes ubicuas permiten a los usuarios acceder a Internet desde cualquier sitio y en cualquier momento, esta característica introduce una nueva serie de problemas en el uso de las telecomunicaciones, la multidifusión y la efectividad de los modelos de negocio actuales. Este nuevo paradigma se esta imponiendo poco a poco en nuestra sociedad y la sanidad como colectivo habitual en el uso de nuevas tecnologías será uno de los primeros en utilizarlo en el uso diario. Uno de nuestros esfuerzos en investigación y desarrollo se centra en dar soluciones aplicadas a los entornos sanitarios en este nuevo paradigma de comunicación.

En la actualidad uno de los esfuerzos mas importantes en los desarrollos de sistemas de información puede ser la capacidad de ofrecer al usuario la información necesaria en cualquier entorno posible sin prestar atención a la disposición geográfica del elemento ni a su arquitectura hardware y software, incluyendo en esta descripción la posibilidad de integración del sistema con otros sistemas de la organización. Como se puede suponer este requisito fundamental es difícil de conseguir y trae consigo una serie de requisitos adicionales, como son la extensibilidad y la portabilidad.

Extensibilidad. La capacidad de extensión se refiere a la capacidad del sistema para adoptar nuevas mejoras o cambios, por ejemplo adaptándose a nuevas tecnologías. La arquitectura del sistema debe facilitar esta calidad de servicio mediante la utilización de protocolos abiertos. Si se utiliza el sistema de comunicaciones SOAP/HTTP es fácil extender el sistema y hacerlo accesible a diferentes plataformas y dispositivos cliente (Windows, telefonía móvil, etc.).

Portabilidad. Las aplicaciones desarrolladas sobre la arquitectura deben estar aisladas de las peculiaridades de los diferentes servidores de aplicaciones, bases de datos y sistemas de comunicaciones a través de una serie de interfaces genéricos (capas de abstracción software) que ocultarán los detalles de implementación a la aplicación, de forma que el cambio de uno de estos recursos no implique un cambio en el código fuente de las aplicaciones, facilitando en consecuencia la portabilidad de la misma.

La arquitectura que mejor se adapta a los requisitos expuestos en el apartado anterior en la plataforma Java 2 Enterprise Edition (J2EE), esta plataforma proporciona una solución al diseño, desarrollo, ensamblado y despliegue de aplicaciones empresariales basada en componentes. La plataforma J2EE ofrece un modelo de aplicación distribuida multicapa compuesta por componentes reutilizables, un modelo de seguridad unificado, control de transacciones flexibles, y soporte de servicios Web a través de intercambio integrado de datos sobre protocolos estándar abiertos basados en XML (Extensible Markup Language).

Una aplicación J2EE se compone de componentes. Un componente J2EE es una unidad de software funcional auto-contenida que es capaz de comunicarse con otros componentes y que se ensambla junto con sus clases y ficheros relacionados en una aplicación J2EE. La especificación J2EE define los siguientes componentes:

Los componentes J2EE se escriben en lenguaje Java y se compilan como cualquier otro programa Java. La diferencia entre los componentes J2EE y las clases Java estándar es que los componentes J2EE se ensamblan en una aplicación J2EE, se verifica que estén bien formados y conforme a la especificación J2EE, y se despliegan en producción donde son ejecutados y gestionados por el servidor J2EE.

Una aplicación J2EE estándar se estructura en cuatro capas. La capa cliente (Client Tier) o de presentación se encarga de la representación visual del interfaz de usuario, la capa de negocio (Bussines Tier) ejecuta los componentes que conocen la lógica de negocio y devuelven información a los componentes clientes, finalmente la capa de información (EIS Tier) posee los datos de los que se nutren los componentes de la capa de negocio.

La arquitectura propuesta se basa en la especificación J2EE y añade un nuevo nivel o capa, denominado Capa de estandarización. Esta capa se sitúa entre la capa de negocio y la capa de presentación.

La capa de cliente se implementa en Java de tal modo que puede ser distribuida o bien como una aplicación o bien como un applet. La aplicación Java permite una distribución a través de módulos que puedan descargarse a través de la red y almacenarse en el ordenador del usuario para su posterior uso, aunque también se puede desarrollar parte en HTML Dinámico. Si se utiliza Java Web Start como plataforma para la distribución del producto como aplicación entonces la metodología para el acceso a recursos del sistema (el sistema de ficheros, por ejemplo) es ligeramente diferente que en el caso de un applet, ya que esos recursos son accedidos a través de una librería especial incluida en el protocolo Java Network Launching Protocol (JNLP). En consecuencia el sistema debe construirse con un módulo de acceso a estos recursos. Este módulo presenta un interfaz único y dos implementaciones diferentes: la primera en el caso de utilizar Java Web Start y la segunda para el caso de applets Java. Este subsistema decide en tiempo de ejecución que implementación utilizar para el acceso a los recursos del ordenador del usuario.

La capa cliente es capaz de acceder a diferentes servidores de aplicaciones. El diseño del sistema se ajusta a la especificación J2EE (Java 2 Enterprise Edition), evitando la utilización de clases de terceros (BEA/iPlanet/etc.) para el acceso a los servidores. En especial se señala la utilización de SOAP (Simple Object Access Protocol) sobre protocolo HTTP (HyperText Transfer Protocol) para el acceso a los servidores remotos, a fin de lograr total independencia con respecto a los servidores.

Autenticación de Usuario. La plataforma cliente debe disponer de un sistema de autenticación de usuarios que se conecta con el sistema remoto a fin de determinar si un usuario puede o no tener acceso al mismo. Además el sistema proporciona un módulo que encapsula toda la lógica de autorización en la plataforma cliente. Esta lógica permite la deshabilitación de opciones de menú a las que un usuario no debe tener acceso, atendiendo a su perfil, que se almacena en base de datos remota.

Integración con Tarjetas Inteligentes. La aplicación cliente puede acceder a SIP (Sistema de Información Poblacional), TIS (Tarjeta Individual Sanitaria) y a lectores de tarjetas. Todas estas operaciones se realizan a través de un subsistema especializado que facilita el proceso y que ofrece un interfaz único al resto de la aplicación. De este modo un cambio en estos sistemas externos implica únicamente un cambio en este subsistema y no afecta a la totalidad de la aplicación.

La capa de estandarización ofrece un interfaz a la capa de presentación basado en sockets TCP/IP e intercambio de mensajes XML-HL7. La capa de estandarización se compone de uno o varios servidores TCP/IP que atienden peticiones de solicitudes XML-HL7. Cada servidor se relaciona con un sistema de información (EIS) a través de un conjunto de EJB’s. Por ejemplo, existirá un servidor que atiende peticiones para HIS y otro atenderá peticiones para AP. Gracias a la capa de estandarización es posible ofrecer un interfaz (API) basado en XML-HL7 para el acceso a los datos a cualquier aplicación externa (que tenga los permisos adecuados para ello). La complejidad de las estructuras de datos internas de cada EIS es transparente para el usuario externo que solo se tiene que preocupar en realizar las peticiones y recibir las respuestas en el estándar XML-HL7. La complejidad de la lógica queda encapsulada en la capa de negocio, los servidores XML-HL7 interrogarán a los componentes de la capa de negocio para obtener los datos, operar con ellos y luego enviarlos, a la capa cliente.

La capa de lógica de negocio se debe desarrollar siguiendo la especificación J2EE. En especial se ofrece un interfaz remoto basado en EJB (Enterprise Java Beans) de tipo Stateless Session para el acceso a la lógica de negocio. Opcionalmente se puede incluir un interfaz HTTP basado en servlets que permite el acceso a la lógica de negocio utilizando el protocolo SOAP. Esta tecnología facilita el acceso a diferentes servidores de aplicaciones sin que esto requiera modificaciones en las aplicaciones cliente. Si se utiliza el protocolo nativo RMI/IIOP (Remote Method Invocation) la aplicación cliente utiliza subsistemas especiales basados en las librerías proporcionadas por el fabricante del servidor de aplicaciones.

Acceso a Datos. La aplicación en el servidor accede a una única instancia de base de datos, el acceso a la misma se realiza utilizando sentencias SQL (Standar Query Lenguage) estándar que permiten cambiar la versión y/o el fabricante de la misma (Informix, Sybase, Oracle, etc.). A tal fin la arquitectura del sistema incluye un módulo de acceso a la base de datos y una serie de utilidades para la generación de sentencias SQL. El módulo de acceso a la base de datos permite la localización de conexiones a la base de datos a través del pool de conexiones nativo al servidor de aplicaciones, pero a través de un interfaz común a todos los servidores. Además incluye funcionalidades para la conversión de fechas, números y cadenas de texto al formato SQL dependiente de la base de datos.

Seguridad en el Servidor. En cuanto a la prevención de la utilización o acceso no deseado al sistema y a los datos, la seguridad suele dividirse en dos aspectos principales: la referente al hardware o acceso al sistema mismo y la referente al software o a la capacidad de acceso a la información. La seguridad hardware debe asegurarse a través de sistemas específicos de seguridad como firewalls y una correcta instalación y administración de los sistemas operativos que se estén utilizando. La seguridad software se proporciona al sistema a través de su arquitectura. Esta calidad de servicio viene asegurada mediante la utilización de protocolos seguros de comunicaciones (HTTPS) entre las aplicaciones cliente y el servidor. La seguridad puede verse reforzada utilizando sistemas especiales de reordenación del código binario Java de las aplicaciones (que dificulta la ingeniería inversa de las aplicaciones cliente) conocidos como "Java Code Obfuscators".