Integración al Servicio de la Empresa Las Arquitecturas SOA permiten abordar los nuevos retos empresariales, ser más competitivos y disponer de sistemas de información integrados. Además, tecnologías como BPM, BAM, JBI o Web Services forman un complemento esencial para SOA. THE SERVER LABS dispone de amplia experiencia y conocimiento en arquitecturas de sistemas de información, entre ellas las orientadas al servicio (SOA), lo que permite a nuestros clientes maximizar el retorno de la inversión y construir soluciones de calidad.
Contenido Qué es SOA y los Servicios?... 2 Principios de la Arquitectura SOA... 3 Infraestructura de Servicios... 4 Ventajas para la empresa... 10 Servicios ofrecidos por THE SERVER LABS... 10 Definición de Acrónimos... 11 1
Qué es SOA y los Servicios? La Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture o SOA) es un modelo de arquitectura software que proporciona una metodología y un marco de trabajo basado en servicios. Además, está muy orientada y alineada con el negocio, por lo que normalmente se habla de SOA como un modelo de arquitectura tanto de IT como corporativo. SOA no es un producto, ni un fabricante, ni una tecnología, es una arquitectura, cuyos conceptos no son totalmente nuevos. Lo que ocurre es que ahora tenemos tecnologías y estándares que hacen posible que la implementación sea ahora una realidad. Por ejemplo, conceptos de mensajería, web services, etc. SOA hace posible que las empresas u organizaciones compartan los datos de sus aplicaciones y la lógica de negocio (sea entre departamentos o con otras empresas), permitiendo un acceso homogéneo a los datos. Un servicio en SOA es un conjunto discreto de funcionalidad técnica o de proceso de negocio, cuya característica principal es que sea reutilizable por cualquier proceso de negocio. Los servicios pueden estar compuestos de otros servicios según una jerarquía. Los tipos de servicios posibles a definir basándose en su granularidad son los siguientes: Servicios de componentes o de aplicación: Servicios atómicos que interactúan directamente con los sistemas finales; estos son independientes de la plataforma, sistema operativo, lenguaje de programación etc. Servicios de negocio: Son servicios formados por la composición de servicios de componentes. Servicios de workflow o de orquestación: Son servicios formados por la orquestación de servicios de negocio o de servicios de componentes en los que puede haber interacción humana. 2
Todos estos servicios pueden ser proporcionados al usuario del sistema, por lo general a través de una aplicación en el que sea transparente e irrelevante cualquier detalle de arquitectura o de implementación. Hay que tener en cuenta que el concepto de reutilización siempre es aplicable a todos los casos, independientemente del nivel de abstracción, aunque dependerá de si se publican o no en el bus de servicios empresariales (ESB). Si no se publican, en principio la reutilización no tendrá lugar, y se considerarían privados. Es muy importante definir correctamente qué servicios son o no publicables. Principios de la Arquitectura SOA Los principios arquitectónicos con los que se diseñan los servicios en SOA son: Reusabilidad: La lógica de los procesos de negocio es dividida en servicios, estos funcionalmente son únicos en toda la arquitectura y por tanto deberían ser reutilizados en toda la implementación. Acoplamiento mínimo: Los servicios han de requerir el conocimiento de la existencia de otros servicios, pero la dependencia ha de ser mínima o de preferencia nula. Descubrimiento del servicio: Los servicios al tener interfaces completamente definidas y autodescriptivas permiten poder ser descubiertos dinámicamente por otros servicios. Composición de servicios: Un conjunto de servicios puede ser coordinado y orquestado para crear otros servicios más complejos. Ser auto-contenidos: Los servicios han de ser autónomos y por tanto deberán implementar una funcionalidad completa sin depender de otros servicios. Establecimiento de contratos: Esto se refiere a que los procesos proveedores del servicio y los consumidores establezcan entre ellos la definición completa de las interfaces del servicio. El llevar a la práctica estos principios arquitectónicos, además de la metodología, implica disponer de una "infraestructura de servicios" que nos permita implementar SOA en tiempos cortos (requerimiento indispensable del negocio). Debido a esto, los fabricantes de software (comerciales y también de software libre) implementan sus soluciones o reconvierten sus productos buscando cubrir tales principios de arquitectura. Hay informes que señalan que muy pronto, todas las aplicaciones se construirán teniendo en cuenta las normas y estándares SOA, y que todos los productos actuales y venideros vendrán diseñados conforme a la norma. Es importante indicar que una solución, además de cubrir lo mencionado anteriormente, deberá soportar los requerimientos de un sistema corporativo: Alta Disponibilidad, Balanceo de Carga, Escalabilidad, Seguridad, Recuperación ante fallos y Mantenibilidad. 3
Infraestructura de Servicios Actualmente existen diferentes organismos (w3c, JCP, OASIS, etc.) que buscan estandarizar las tecnologías encargadas de implementar SOA. Los fabricantes de software buscan tener en un futuro próximo una plataforma que implemente SOA completamente, pero en la actualidad están reconvirtiendo o implementando su "infraestructura de servicios" basándose en su tecnología actual. De acuerdo con esto, los fabricantes han definido diversos nombres para sus productos los que evidentemente referencian los principios de SOA. A continuación enumeramos algunos de ellos: ESB Enterprise Service Bus (Bus Empresarial de Servicios) El concepto de bus ha sido extrapolado de la tecnología de middleware en el que se usaba para buses de mensajería; en este caso hablamos de bus de servicios. El concepto de bus apareció cuando la integración de aplicaciones era punto a punto obteniéndose al final el modelo "espagueti". Este modelo era muy costoso en cuanto a mantenimiento, reutilización, etc., por lo que el bus trajo orden a la integración de aplicaciones debido a que las aplicaciones cuando querían recibir o enviar información interactuaban con el bus, y éste les resolvía las peticiones de una manera anónima, desacoplada y eficiente. 4
Las tecnologías con las que están construidos los buses son de diversos tipos: demonios, colas, servidores de ejecución, webservices, etc. Actualmente JMS (Java Messaging Service) y los WebServices son las tecnologías que se prevé coparan el mercado de implementación del ESB. En relación con los WebServices a fecha de hoy aún están en progreso ciertos estándares, tal es el caso de WS-Security, WS-SecurityPolicy, WS-ReliableMessaging, WS-Trust, WS-Choreography, WS-Transactions, WS-Addressing, WS- Notification, etc., pero ya han alcanzado la categoría de estándares especificaciones como WSDL 1.1, UDDI 3.0, SOAP 1.2, WS-Reliability, WSDM 1.0, WS-Security 1.1, BPMN 1.0, XDPL 2.0; al final del documento se especifica una descripción de todos estos acrónimos. Service Registry (Registro de Servicios) Antes de implementar un servicio, hay que diseñar las definiciones de las interfaces y las políticas para la invocación de servicios entre los proveedores de servicios SOA y los consumidores de servicios SOA. El "registro de servicios" permite tal funcionalidad, además de proporcionar un mecanismo de publicación de registros de servicios. Con este mecanismo todos los servicios conocerán de la existencia de nuevos servicios y además se permite verificar que todos ellos utilizan las políticas establecidas, asegurándose la consistencia de los servicios y su calidad. 5
Data Services (Servicios de Datos) Estos servicios son los que proporcionan el nivel de acceso a datos provenientes de las fuentes de información (Bases de Datos, Sistemas de Back-Office, CRM, ERP, etc.). Adicionalmente a obtener la información, la solución también ha de tener mecanismos para realizar transformaciones, consultas y hasta permitir la combinación de varias fuentes de datos. BPM (Business Process Management) (Gestión de Procesos de Negocio) Un conjunto de servicios conformará lo que se denomina un proceso de negocio. Para entender correctamente la relación entre BPM y SOA, hay que tener en cuenta que todo proceso de negocio tiene muchos aspectos que han de ser gestionados, como por ejemplo capacidades de orquestación en los procesos, modelización del proceso, monitorización del proceso y de su estado, motores de reglas de negocio más amigables para el usuario, análisis de eficiencia de los procesos a nivel granular o agregado. SOA no especifica la gestión de cada aspecto, pero toda infraestructura de servicios requiere herramientas para gestionarlos y así garantizar la eficiencia en la arquitectura planteada. Para poder comprender la diferencia y la relación existente entre Servicios SOA y Procesos de BPM, es importante primero distinguir Servicio SOA del Servicio que el negocio ofrece al consumidor o cliente. A veces, en las organizaciones, se denomina Servicio a lo que realmente es un proceso de negocio. Este proceso de negocio estaría compuesto de servicios SOA e invocaría 6
a las operaciones de estos servicios. Además los procesos de negocio pueden tener un estado y sin embargo los Servicios SOA no tienen nunca estado. Vamos a poner un ejemplo de los dos conceptos y de su interrelación. Imaginemos un proceso de negocio llamado Mantenimiento de los vehículos de clientes. Esto es lo que normalmente llamaríamos en la empresa un Servicio, ya que se puede ofrecer como servicio de negocio directamente al público. Sin embargo, dentro de la terminología SOA, es un proceso de negocio, ya que tiene estado, no es autocontenido y tampoco reutilizable para otros procesos, como por ejemplo Venta de Vehículos a Clientes o Compra Vehículos a Mayorista etc. En el siguiente dibujo se muestran los servicios que implementarían el proceso de negocio Mantenimiento de los vehículos de clientes, como Servicio de Orden de Trabajo, Servicio de Catalogo, Servicio de Gestión, Servicio de Cliente y Servicio de Inventario. Cada uno de estos servicios consiste en una agrupación de operaciones de utilidad, es reutilizable, y no tiene estado. 7
En relación con la monitorización, que es uno de los aspectos de los procesos, es importante mencionar la tecnología BAM (Business Activity Monitoring) (Monitorización). Esta tecnología nos da información pormenorizada y en tiempo real del comportamiento de los procesos sobre la base de indicadores de eficiencia. Es una tecnología en tiempo real orientada a eventos a diferencia de la tecnología de Business Inteligence, que está mas orientada a la obtención de análisis basándose en históricos (generalmente por consultas a base de datos); en el caso de Business Inteligente el usuario final es uno de mayor nivel de gestión (gestores de operaciones, gerentes de sistemas, etc). Service Lifecycle Management La gestión del ciclo de vida de los servicios es cada vez más importante debido a la continua actualización y adecuación de los servicios para llevar a la práctica su reutilización por otros servicios. Por tanto es preciso tener una adecuada gestión del repositorio de los servicios con una auto-sincronización utilizando estándares. Toda esta gestión se denomina governance. Las actualizaciones y adecuaciones de los servicios se realizan para cualquier aspecto de los servicios, por lo que el término governance está también relacionado con seguridad, registro, políticas de gestión, etc. 8
Adicionalmente la infraestructura de servicios ha de implementar otros servicios no menos importantes como por ejemplo la seguridad. Security Services La seguridad en sí no está definida por de la tecnología SOA, pero puede ser planteada como un servicio SOA. En esto los fabricantes de software buscan que sus soluciones cumplan con todos los criterios de seguridad como autenticación, autorización, mapeo de roles, mapeo de credenciales, etc. Pero como es de suponerse los sistemas requieren de estándares y tecnología que mejoren o que faciliten aún más la implementación de SOA, por lo que hay nuevos estándares o metodologías a las que se prevé evolucionará la tecnología: SCA (Service Component Arquitecture) y JBI (Java Business Integration). SCA Es un modelo para la creación de componentes de servicio y la composición de servicios. Algunas de las características que ha de tener son: Desacoplar la implementación del servicio del ensamblaje del servicio. Diversos lenguajes de programación y estándares como Java, C++, XML, BPEL, XSLT, etc. podrán utilizarla como arquitectura de creación de componentes de servicios. Los datos deberán ser representados como objetos de servicio de datos. Los componentes han de poder ser reutilizados. Ejecutar la composición de servicios. JBI Entendido como una especificación para arquitectura de contenedores, los cuales albergan tanto a los productores de servicios como a los componentes consumidores de servicios. El mecanismo de entrega de mensajes centralizado se hará utilizando el concepto de bus, sólo que denominado router de mensajes normalizado. Este bus entrega mensajes normalizados basándose en patrones de intercambio de mensajes. Una de las cosas interesantes es qué la especificación JBI referencia a un servicio de ensamble de aplicaciones, el cual proporcionará un empaquetamiento estándar de aplicaciones compuestas (consumidores y proveedores de servicios) permitiendo que sean portables a cualquier implementación JBI de cualquier fabricante. En la actualidad los fabricantes están trabajando en esto, considerándose por tanto una tecnología aún en progreso. 9
Ventajas para la empresa Estandarizar los procesos existentes y analizarlos basándose en una arquitectura SOA permitirá reducir mucho los gastos de implementación y mantenimiento a medida que el nivel de reutilización del servicio aumente. Esto es lo que se denomina "small ROI". Pero la flexibilidad que brinda la arquitectura a responder rápidamente y de manera más efectiva a los cambios en las condiciones de mercado y de esa manera ganar ventaja competitiva es lo que traerá el "big ROI". SOA promete alcanzar la agilidad tan esperada para el negocio. Servicios ofrecidos por THE SERVER LABS Los arquitectos de THE SERVER LABS tienen una amplia experiencia en diseño e implementación de arquitecturas y desarrollo software, en diversos verticales de negocio, como el financiero, las telecomunicaciones, el ecommerce y el espacial y científico; por ello, nuestros arquitectos entienden tanto las relaciones dinámicas entre las necesidades de negocio y los servicios existentes, así como los fundamentos técnicos necesarios para crear servicios a partir de las aplicaciones técnicas. Además, hay que tener en cuenta que las características intrínsecas de SOA (reusabilidad, granularidad y bajo acoplamiento) permiten la utilización de metodologías ágiles de desarrollo, con las que THE SERVER LABS está familiarizado y que favorecen en última instancia la agilidad para el negocio, la satisfacción del cliente y la disminución del coste total del proyecto. Algunos de los servicios que ofrecemos en este contexto son los siguientes: Análisis de viabilidad, planificación y diseño de Arquitecturas SOA. Mentoring Tecnológico. Desarrollo de Frameworks SOA- para garantizar una importante reducción de costes durante el desarrollo del proyecto SOA. Formación Avanzada y Master Classes en Arquitectura (Architecture Summer Camp). Y para dar apoyo al equipo de consultoría experta, THE SERVER LABS dispone de un Laboratorio de Arquitecturas como un valor añadido para el proyecto. El laboratorio ofrece soluciones tecnológicas innovadoras que ayudarán al equipo, clientes y partners a mejorar su competitividad y rendimiento. The Server Labs S.L. C/ Pinar, 5 28006 Madrid, Spain Tel: 91 745 68 77. www.theserverlabs.com 10
Definición de Acrónimos WS-SecurityPolicy. Lenguaje para declarar políticas de seguridad de Web Services mediante el cual se definen restricciones y requerimientos (encriptado, tokens, mecanismos, etc.) para habilitar a los web services ha de participar en intercambio seguro de mensajes. WS-ReliableMessaging. Especificación normada por OASIS la cual permite la transferencia de "mensajes fiables" entre componentes software cuando existen fallos en la red de comunicaciones o fallos en componentes. WS-Trust. Especificación encargada de definir extensiones sobre WS-Security obteniéndose un framework para gestionar relaciones de seguridad a través de la solicitud y envío de testigos (tokens) de seguridad. WS-Choreography. Modelo que permite definir los datos y las relaciones entre ellos para definir la secuencia y las condiciones de intercambio. WS-Transactions. Definición del tipo de coordinación de transacción atómica que será usado con el framework de coordinación (WS-Coordination). WS-Addressing. Proporciona mecanismos para direccionar Web services y mensajes a través de redes que incluyen nodos de procesamiento como firewalls y gateways. WSDL 1.1. "Web Service Definition Language", Lenguaje de descripción de Web services para describir servicios de red conteniendo información orientada a documentos o a procedimientos. UDDI 3.0. "Universal Description Discovery and Integration", es uno de los estándares pilares en la infraestructura de los Web services. SOAP 1.2. "Simple Object Access Protocol", protocolo que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. WS-Reliability. Proporciona un método para garantizar entrega de mensajes sobre Internet WSDM 1.0. "Web Services Distributed Management": estándar para unificar gestión de infraestructuras por proveedor, plataforma y red para habilitar el acceso y recibir notificaciones de gestión de recursos habilitados. WS-Security 1.1. Protocolo de comunicaciones que permite aplicar seguridad a los Servicios Web y generalmente se provee a través de un framework. BPMN 1.0. Business Process Modeling Notation, notación gráfica estandarizada de procesos de negocios en un Workflow. XDPL 2.0. Lenguaje de procesamiento de datos XML. 11