SOA: La esencia de la orientación a objetos
Las Arquitecturas Orientadas a Servicios (SOA) están madurando a la luz de las tecnologías de Servicios Web, con la promesa de implementar la esencia de la orientación a objetos, y perfeccionar las ventajas de las arquitecturas de dos y tres capas conectando a clientes y servidores que no se conocen en una red espontánea. También afrontará retos tan actuales como la reutilización e interconexión de sistemas, balanceo de carga o servicios de alta disponibilidad.
Aunque no seamos desarrolladores, utilizamos diariamente la arquitectura cliente/servidor (CSA) al acceder al correo electrónico, la Web, los archivos, las impresoras remotas y un largo etcétera. Experimentamos las ventajas de distribuir el trabajo mediante una red integrada por ordenadores potentes y especializados en tareas específicas (los servidores) y un número mayor de ordenadores de escritorio que los utilizan (los clientes). Y como cada uno puede consistir en diversas plataformas de hardware, sistema operativo, software, etc., deben ser desarrollados específicamente pero asegurando la conectividad entre ellos. Bien sabemos que cuando agregamos un servidor debemos realizar tareas de administración para que sus clientes puedan utilizarlo; y más aún, conocemos los inconvenientes que causan si por alguna razón no están disponibles, aún cuando haya otros que puedan realizar la misma tarea.
Un paso más allá
A lo largo de la corta historia de la informática hemos visto que su evolución viene dada por el aumento de la potencia de cálculo, de la cantidad de memoria que se gestiona, de las interfaces de entrada/salida y de la conectividad. En este mismo orden ha ido evolucionando a lo largo de la historia cada uno de sus aspectos. Siguiendo la tendencia actual, la conectividad es de todos los aspectos el que más tarde ha evolucionado y el que está experimentado mayores cambios.
Si, hoy en día, la red de telefonía continuara utilizando las centrales conmutadas manualmente, teniendo en cuenta el número de terminales y el volumen de tráfico actuales, uno de cada diez abonados debiera trabajar como operador. Ahora bien, somos muchos los usuarios de informática que debemos configurar los servicios de impresión, parámetros de la red o aplicaciones cuando un servidor se incorpora o ya no está disponible. ¿No debería ser automática la mayor parte de estas operaciones? Si dos servidores pueden proveer el mismo servicio, ¿por qué no se balancean las tareas automáticamente? Es lógico pensar entonces que las redes de ordenadores evolucionen hacia una arquitectura que le permita auto configurarse, distribuir tareas o auto sanearse.
En la historia de las arquitecturas observamos que, en un principio, se organizaron para reutilizar funciones y empaquetarlas en subrutinas: se programaba pensando en el ordenador. Luego, apareció la programación orientada a objetos, que permitió reutilizar esos objetos dentro de una misma aplicación y en otras diversas aplicaciones, e incluso, mediante distintas tecnologías, reutilizarlos remotamente: se programaba pensando en otras aplicaciones y ordenadores. Las Arquitecturas Orientadas a Servicios (SOA –Service-Oriented Architecture) avanzan un paso más en el camino de la reutilización al extender esta propiedad a aplicaciones completas, convirtiéndolas en componentes y presentándolas como servicios: finalmente se programa pensando también en la red.
Quizás uno de las causas de las desventajas de las arquitecturas de dos y tres capas, como las CSA, sea un error conceptual: la realidad nos demuestra que “los clientes no buscan servidores, buscan servicios”. Las SOA amplían los beneficios de la CSA sumándole capacidades para que los clientes accedan a los servidores –los proveedores del servicio que el cliente necesita– sin necesidad de conocer su dirección. Para ello, los servidores se “publican” o anuncian a un servicio de búsqueda (que puede estar implementado en uno o más servidores) que el cliente utiliza para buscar el servidor que preste el servicio que necesita. Esta búsqueda la realiza mediante una descripción técnica y/o atributos (nombre, localización...) y, una vez resuelta, se “suscribe” a ese servidor y lo utiliza.
Observamos entonces que las SOA implementan la esencia del análisis orientado a objetos, ya que permiten utilizar objetos remotos que presten un servicio ocultando y resolviendo la infraestructura subyacente. El servicio de búsqueda se encargará de resolver la utilización proporcional de todos los servidores que presten el mismo servicio (balanceo de cargas), monitorizándolos para evitar incluir en el resultado de una búsqueda a un servidor que ya no se encuentre disponible (redundancia).
Aplicaciones
Esta arquitectura tiene aplicaciones concretas dentro y fuera de la empresa, y ya cuenta con varias infraestructuras de implementación, como los Servicios Web (en los que trabajan firmas como IBM, Microsoft, Ariba, BEA o Sun, entre otros), Sun JINI (Java Intelligent Network Infraestructure), MS .NET, etc. Dentro de la empresa, podemos aplicar las SOA para construir la infraestructura subyacente de servicios para nuestras aplicaciones o en la integración de sistemas; y fuera de ella, para interconectarse con los sistemas de otras empresas.
En el primero de los casos, supone concretamente una estrategia de construcción de los sistemas de la empresa. Es algo así como definir las API que resuelven cuestiones comunes y de “bajo nivel”. En lugar de incluir en todas las aplicaciones que requieran enviar correo los componentes de acceso, y configurarlas (y mantenerlas) en consecuencia, utilizaríamos un único servicio de envío de mensajes que resolvería esa tarea para todas ellas. Ejemplos de servicios de este tipo podrían ser los servicios unificados de gestión, autenticación y autorización de usuarios, comunicación (notificaciones, correo electrónico...), repositorio de documentos (control de versiones, seguridad, búsquedas...), personalización (localismos, idiomas, unidades de medida, monedas...) y ejecución de tareas programadas, entre otros muchos posibles.
El segundo de los casos, es decir, fuera de la empresa, consiste en una interfaz para que cualquier tipo de servicios, como los que actualmente están disponibles en Internet a través de la Web, sea utilizado directamente por aplicaciones clientes. Esta nueva interfaz, a diferencia de la Web que está orientada a usuarios, responde a las necesidades propias de interconexión de sistemas que prestan y que requieren servicios. Algunos ejemplos serían los servicios de noticias (nacionales, internacionales, económicas, etc.), de información actualizada (valores de monedas, títulos de bolsa, pronósticos meteorológicos...), orientados al cliente (consulta de cuentas, realización y seguimiento de pedidos, catálogo de productos, etc.), orientados al proveedor (solicitud de ofertas, pedidos, compras, subastas...), de búsqueda en Internet, etc.
Situación actual
Dada la madurez y popularidad de la tecnología de Servicios Web, actualmente no parece una aventura pensar en SOA como estrategia tecnológica de un plan de sistemas. Además, no se trata de una arquitectura “monopolizadora”, pues su topología permite integrar y encapsular otras arquitecturas o tecnologías ya existentes. También representa una oportunidad para implementar otras estrategias, como los desarrollos evolutivo
Aunque no seamos desarrolladores, utilizamos diariamente la arquitectura cliente/servidor (CSA) al acceder al correo electrónico, la Web, los archivos, las impresoras remotas y un largo etcétera. Experimentamos las ventajas de distribuir el trabajo mediante una red integrada por ordenadores potentes y especializados en tareas específicas (los servidores) y un número mayor de ordenadores de escritorio que los utilizan (los clientes). Y como cada uno puede consistir en diversas plataformas de hardware, sistema operativo, software, etc., deben ser desarrollados específicamente pero asegurando la conectividad entre ellos. Bien sabemos que cuando agregamos un servidor debemos realizar tareas de administración para que sus clientes puedan utilizarlo; y más aún, conocemos los inconvenientes que causan si por alguna razón no están disponibles, aún cuando haya otros que puedan realizar la misma tarea.
Un paso más allá
A lo largo de la corta historia de la informática hemos visto que su evolución viene dada por el aumento de la potencia de cálculo, de la cantidad de memoria que se gestiona, de las interfaces de entrada/salida y de la conectividad. En este mismo orden ha ido evolucionando a lo largo de la historia cada uno de sus aspectos. Siguiendo la tendencia actual, la conectividad es de todos los aspectos el que más tarde ha evolucionado y el que está experimentado mayores cambios.
Si, hoy en día, la red de telefonía continuara utilizando las centrales conmutadas manualmente, teniendo en cuenta el número de terminales y el volumen de tráfico actuales, uno de cada diez abonados debiera trabajar como operador. Ahora bien, somos muchos los usuarios de informática que debemos configurar los servicios de impresión, parámetros de la red o aplicaciones cuando un servidor se incorpora o ya no está disponible. ¿No debería ser automática la mayor parte de estas operaciones? Si dos servidores pueden proveer el mismo servicio, ¿por qué no se balancean las tareas automáticamente? Es lógico pensar entonces que las redes de ordenadores evolucionen hacia una arquitectura que le permita auto configurarse, distribuir tareas o auto sanearse.
En la historia de las arquitecturas observamos que, en un principio, se organizaron para reutilizar funciones y empaquetarlas en subrutinas: se programaba pensando en el ordenador. Luego, apareció la programación orientada a objetos, que permitió reutilizar esos objetos dentro de una misma aplicación y en otras diversas aplicaciones, e incluso, mediante distintas tecnologías, reutilizarlos remotamente: se programaba pensando en otras aplicaciones y ordenadores. Las Arquitecturas Orientadas a Servicios (SOA –Service-Oriented Architecture) avanzan un paso más en el camino de la reutilización al extender esta propiedad a aplicaciones completas, convirtiéndolas en componentes y presentándolas como servicios: finalmente se programa pensando también en la red.
Quizás uno de las causas de las desventajas de las arquitecturas de dos y tres capas, como las CSA, sea un error conceptual: la realidad nos demuestra que “los clientes no buscan servidores, buscan servicios”. Las SOA amplían los beneficios de la CSA sumándole capacidades para que los clientes accedan a los servidores –los proveedores del servicio que el cliente necesita– sin necesidad de conocer su dirección. Para ello, los servidores se “publican” o anuncian a un servicio de búsqueda (que puede estar implementado en uno o más servidores) que el cliente utiliza para buscar el servidor que preste el servicio que necesita. Esta búsqueda la realiza mediante una descripción técnica y/o atributos (nombre, localización...) y, una vez resuelta, se “suscribe” a ese servidor y lo utiliza.
Observamos entonces que las SOA implementan la esencia del análisis orientado a objetos, ya que permiten utilizar objetos remotos que presten un servicio ocultando y resolviendo la infraestructura subyacente. El servicio de búsqueda se encargará de resolver la utilización proporcional de todos los servidores que presten el mismo servicio (balanceo de cargas), monitorizándolos para evitar incluir en el resultado de una búsqueda a un servidor que ya no se encuentre disponible (redundancia).
Aplicaciones
Esta arquitectura tiene aplicaciones concretas dentro y fuera de la empresa, y ya cuenta con varias infraestructuras de implementación, como los Servicios Web (en los que trabajan firmas como IBM, Microsoft, Ariba, BEA o Sun, entre otros), Sun JINI (Java Intelligent Network Infraestructure), MS .NET, etc. Dentro de la empresa, podemos aplicar las SOA para construir la infraestructura subyacente de servicios para nuestras aplicaciones o en la integración de sistemas; y fuera de ella, para interconectarse con los sistemas de otras empresas.
En el primero de los casos, supone concretamente una estrategia de construcción de los sistemas de la empresa. Es algo así como definir las API que resuelven cuestiones comunes y de “bajo nivel”. En lugar de incluir en todas las aplicaciones que requieran enviar correo los componentes de acceso, y configurarlas (y mantenerlas) en consecuencia, utilizaríamos un único servicio de envío de mensajes que resolvería esa tarea para todas ellas. Ejemplos de servicios de este tipo podrían ser los servicios unificados de gestión, autenticación y autorización de usuarios, comunicación (notificaciones, correo electrónico...), repositorio de documentos (control de versiones, seguridad, búsquedas...), personalización (localismos, idiomas, unidades de medida, monedas...) y ejecución de tareas programadas, entre otros muchos posibles.
El segundo de los casos, es decir, fuera de la empresa, consiste en una interfaz para que cualquier tipo de servicios, como los que actualmente están disponibles en Internet a través de la Web, sea utilizado directamente por aplicaciones clientes. Esta nueva interfaz, a diferencia de la Web que está orientada a usuarios, responde a las necesidades propias de interconexión de sistemas que prestan y que requieren servicios. Algunos ejemplos serían los servicios de noticias (nacionales, internacionales, económicas, etc.), de información actualizada (valores de monedas, títulos de bolsa, pronósticos meteorológicos...), orientados al cliente (consulta de cuentas, realización y seguimiento de pedidos, catálogo de productos, etc.), orientados al proveedor (solicitud de ofertas, pedidos, compras, subastas...), de búsqueda en Internet, etc.
Situación actual
Dada la madurez y popularidad de la tecnología de Servicios Web, actualmente no parece una aventura pensar en SOA como estrategia tecnológica de un plan de sistemas. Además, no se trata de una arquitectura “monopolizadora”, pues su topología permite integrar y encapsular otras arquitecturas o tecnologías ya existentes. También representa una oportunidad para implementar otras estrategias, como los desarrollos evolutivo
