• Author / Uploaded
• Jaime H Rubio R

Citation preview

Propuesta de Políticas de Gobernabilidad SOA TABLA DE CONTENIDO 1. EL CONCEPTO FUNDAMENTAL DE LA INTEROPERABILIDAD DE APLICACIONES Y PROCESOS......................................................................3 2. CONCEPCIÓN FUNDAMENTAL DE SOA Y BUSES DE SERVICIOS EMPRESARIALES...........................................................................................4 2.1

Definición de SERVICIO.............................................................................................6

2.1.1

Que es un Web Service................................................................7

2.1.2

Que es un REST web service?....................................................9

2.2

Que es un bus de servicios empresariales?............................................................9

2.3

BPM............................................................................................................................ 11

3. MARCO DE TRABAJO DEL DOCUMENTO...........................................12 4. INTRODUCCIÓN AL CONCEPTO DE GOBERNABILIDAD SOA.........12 5. POLÍTICAS DE COEXISTENCIA DE LOS BUSES DEL DISTRITO CAPITAL.........................................................................................................12 5.1

Definiciones previas................................................................................................. 12

5.2

Políticas..................................................................................................................... 13

5.3

MECANISMO DE GOBIERNO SOA

1. El concepto fundamental de la Interoperabilidad de Aplicaciones y Procesos En el desarrollo de la estrategia de Gobierno en línea la definición de interoperabilidad es acogida como: “El ejercicio de colaboración entre organizaciones para intercambiar información y conocimiento en el marco de sus procesos de negocio, con el propósito de facilitar la entrega de servicios en línea a ciudadanos, empresas y a otras entidades”. Esta definición aunque bastante amplia en el sentido de extender la interoperabilidad a la colaboración de los procesos inter empresariales es bastante aplicable al caso del proyecto de la PLATAFORMA DE GESTIÖN Y COLABORACIÓN DE UNA EMPRESA. Esta plataforma tiene como objeto facilitar la gestión interinstitucional a nivel empresarial con medios virtuales para aquellos procesos y procedimientos donde interactúen varias entidades. Técnicamente hablando desde el punto de vista de la informática, interoperabilidad de aplicaciones es la habilidad o capacidad de un sistema, aplicación o producto para trabajar con otro sistema, aplicación o producto en forma automática y sin esfuerzo adicional de parte del usuario de cualquiera de las 2 aplicaciones, sistemas o productos. La interoperabilidad de aplicaciones de una empresa es la capacidad de estas aplicaciones de interaccionar entre sí. Se considera que se ha llegado la obtención de la interoperabilidad si se han alcanzado 3 niveles en la interacción:   

Nivel de datos Nivel de funcionalidad y lógica de las aplicaciones Nivel de procesos del negocio de la empresa que son apoyados por cada aplicación

Normalmente en las empresas se acude al primer nivel mediante la extracción de datos de las bases de datos o archivos de una aplicaciones sin que la propia aplicación lo detecte, causando así problemas en la gobernabilidad IT y posteriormente en la operación o mediante técnicas ETL (Extract, Transform and Load) para minería de datos, esta últimas menos invasivas. En el nivel 2 se logra la interacción a nivel lógico entre las aplicaciones y programas mediante el uso de API´s, RPC, interfaces, APPS y demás artilugios que aunque permiten esta interacción en múltiples oportunidades puede perjudicar la operación propia de las aplicaciones pues no existe una arquitectura apropiada que maneje esta interacción. Adicionalmente, existe el Marco de Interoperabilidad para Gobierno en línea el cual es un conjunto de elementos que orientan el intercambio de información a nivel de las entidades públicas y está constituido por:

2

  

Principios y políticas que orientan los esfuerzos políticos, legales y organizacionales de las entidades, con el fin de facilitar la interoperabilidad. Un modelo de administración, compuesto por un modelo de madurez, un modelo de administración y un modelo de medición. Un conjunto de recomendaciones, protocolos, estándares y guías metodológicas, necesarias para que las entidades compartan información a través de servicios de intercambio de información, con el propósito de facilitar la prestación de sus servicios a ciudadanos, empresas y otras entidades públicas en Colombia.

2. Concepción fundamental de SOA y buses de servicios empresariales SOA es un modelo de componentes que interrelaciona las diferentes unidades funcionales de las aplicaciones, denominadas servicios, a través de interfaces y contratos bien definidos entre esos servicios. La interfaz se define de forma neutral, y debería ser independiente de la plataforma hardware, del sistema operativo y del lenguaje de programación utilizado. Esto permite a los servicios, construidos sobre sistemas heterogéneos, interactuar entre ellos de una manera uniforme y universal. Es un paradigma para organizar y utilizar capacidades distribuidas que pueden estar organizadas bajo diferentes propietarios e implementadas bajo diferentes tecnologías. SOA define una base para que diferentes servicios disimiles, pueden entrar en un conjunto de servicios que colaboren entre si para dar flujo operativo a procesos del negocio muy complejos. A su vez estos servicios están basados en procesos primigenios del negocio. Los conceptos que hoy en día están asociados a la arquitectura SOA aparecen con la adopción de Internet y el protocolo HTTP. En el 2003, Roy Schulter acuñó el término SOA por vez primera.Schulter fue uno de los ingenieros que contribuyo también a la creación del http y html los 2 elementos cumbres dela implementación de Internet Esta arquitectura define y proporciona la infraestructura necesaria para que el intercambio de información y la participación en los procesos de negocio se lleve a cabo con total independencia de la plataforma hardware-software sobre la que trabajan: sistema operativo, lenguaje de programación, características de los equipos, etc. Esta arquitectura presenta un modelo de construcción de sistemas distribuidos en el que la funcionalidad demandada será entregada a la aplicación a través de servicios. Para SOA el mundo informático o aplicaciones son un conjunto de servicios autónomos independientes de sus plataformas operativas de HW y SW. Para su construcción como toda arquitectura SOA depende de los facilitadores TECNOLÓGICOS que la implementan. En la Fig. 1 a continuación describíamos esos facilitadores:

3

Fig. 1: Facilitadores tecnológicos de la arquitectura orientada a servicios

4

2.1 Definición de SERVICIO Un servicio representa una función de negocios claramente definida en un proceso,que puede ser invocada remotamente mediante protocolos de comunicaciones estándar, definidas mediante interfaces e independientes de su implementación interna. Los servicios deben poder ser invocados utilizando protocolos de comunicación estándar que enfatizan la interoperabilidad e independencia de ubicación. Los servicios en SOA representan procesos de negocio. Hay una relación directa entre los procesos de negocio de una empresa y los servicios que se van a implementar en SOA, de tal manera que un proceso de negocio estará formado por la llamada a uno o varios servicios. Los principios fundamentales del servicio de acuerdo a Tomas Erl son:  Los Servicios deben ser reutilizables: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.   Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato, logrando así la independencia entre el consumidor y la implementación del propio servicio. En el caso de los Servicios Web, se logrará mediante la definición de interfaces con WSDL.  Los Servicios deben tener bajo acoplamiento: Los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si se consigue este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.  Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de alto nivel a partir de servicios de bajo nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de os protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).  Los Servicios deben ser autónomos: Todo servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.  Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. 5



La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea del tipo que sea. Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando sus interfaces en registros UDDI.

Existen 2 tipos de servicios comunes: los Web Services y los REST services. 2.1.1 Qué es un Web Service Un servicio web es una pieza (programa de computadora) de software que posee las siguientes propiedades: 

Proporciona una funcionalidad de negocio.



Esta funcionalidad es accesible en remoto a través de la web. Accesible a través de la web, no a través de un protocolo especial, ni de una infraestructura especial, ni en una topología de red especial. Esta condición garantiza que la invocación de un servicio web se pueda realizar aprovechando la infraestructura de la web ya existente, sin necesidad de instalar nada especial.



La tecnología elegida para publicar servicios web debería aprovechar de la mejor manera posible la infraestructura web ya existente, para conseguir una mejor interoperabilidad y calidad de servicio. Proporciona una interface bien definida, ocultando la implementación real. El servicio puede estar implementado en cualquier tecnología, lenguajes de programación, por ejemplo COBOL. La tecnología real de implementación, y los detalles de ésta, no son importantes y no deben ser visibles al consumidor del servicio. Interoperable, el proveedor del servicio y el consumidor pueden estar en tecnologías distintas, y aun así poder interactuar. Como se comentó anteriormente no debería ser necesario montar una infraestructura especial para que un cliente pueda invocar a un servicio.





Desde el punto de vista del nivel de interoperabilidad de los servicios web, hay tres categorías: 

Privados. El servicio web sólo va a ser consumido por clientes desarrollados por la misma organización que lo creó. Denominado también local. 6





Públicos. El servicio web, puede además ser consumido por clientes o aplicaciones de otras organizaciones o entidades diferentes a aquella sonde se genera, con los que previamente se ha negociado el modo de acceso. Como caso típico tenemos los escenarios B2B. Un ejemplo es el tarificador de seguros que es llamado por un portal de búsqueda para comparar precios para el seguro del automóvil. Globales. El servicio web puede ser consumido por cualquier cliente en la nación o el mundo. No es factible realizar una negociación sobre el modo de acceso al servicio. Normalmente en este caso se crea una página web documentando la API del servicio y qué protocolo se va a usar. Algunas organizaciones como eBay, Amazon, Google, Yahoo, Facebook o Twitter necesitan este nivel de interoperabilidad.

Es claro que cuanto mayor nivel de interoperabilidad queramos alcanzar, necesitamos un menor nivel de acoplamiento entre el consumidor y el proveedor del servicio con respecto al servicio. El acoplamiento será mayor cuanta más información necesite el cliente para poder invocar al servicio. Cuanto mayor acoplamiento, mayor cantidad de documentación tendrá qué leer el desarrollador del cliente, y más esfuerzo se necesitará para la programación de éste. El hecho de que los servicios web oculten los detalles de su implementación a través de una interface es bueno en este sentido, ya que el cliente no necesita saber detalles sobre cómo implementa el servicio su funcionalidad para invocarlo. Otra buena práctica de desacoplamiento es que el servicio sea stateless, de esta manera el cliente no necesita almacenar el estado de la conversación para poder invocar al servicio correctamente, sólo necesita comprender los parámetros que va a enviar. Analicemos la tecnología más popular para hacer servicios web, la pila WS-*. La pila WS-* es un conjunto de protocolos y estándares para realizar servicios web basados en XML. La verdad es que son muchos protocolos y estándares, y bastante complejos, tantos y tan complejos que no existen dos implementaciones completas de la pila WS-* en funcionamiento e interoperables entre si a todos los niveles. Sin embargo, dentro de todos estos estándares, nos podemos fijar en los dos más usados (y casi los únicos): SOAP y WSDL. SOAP nos permite invocar procedimientos remotos usando XML. Actualmente SOAP se ha extendido para que soporte adjuntos binarios. La verdad es que si ya de por si, el XML es un formato de datos muy poco conciso, el formato SOAP es bastante grande y complejo. Esto evidentemente es un problema cuando queremos trabajar con anchos de banda reducidos (modems, móviles 3G, etc.). Otra característica importante de SOAP es que es neutral con respecto a la infraestructura. Esto permite invocar procedimientos remotos a través de distintos protocolos, como por ejemplo SMTP, MQSeries, y como no, HTTP. Se debe tener

7

presente que SOAP no fue diseñado para aprovechar HTTP, sino que permite usar HTTP entre otros protocolos. 2.1.2 Que es un REST web service? Un servicio web tipo REST es una familia de arquitecturas que permite crear los servicios de manera sencilla como se creó la Web. No utiliza SOAP, XML ni WSDL, los servicios son auto descubribles y no requiere el protocolo UUI. Consisten en un conjunto de comandos parecidos a los comandos de un lenguaje HTTP, o Socket y normalmente sus programas son mucho más pequeños y fáciles que los web services con protocolos SOAP, XML, WSDL y demás. 2.2 Qué es un bus de servicios empresariales? El bus de servicios es el elemento de las arquitecturas SOA que conecta los servicios con sus consumidores y que proporciona:   

Conectividad: el propósito principal de un bus de servicios es interconectar a los participantes de una arquitectura SOA. Soporte a la heterogeneidad de tecnologías: debe ser capaz de conectar a participantes basados en distintos lenguajes de programación, sistemas operativos, entornos de ejecución y protocolos de comunicación. Soporte a la heterogeneidad de paradigmas de comunicación: debe ser capaz de mantener distintos modos de comunicación (por ejemplo comunicaciones síncronas y asíncronas).

Consumidores de servicios Definimos consumidores de servicios como aquellos elementos (usuarios humanos o aplicaciones) de una arquitectura SOA que:  

Pueden descubrir servicios a través de un repositorio. Realizan llamadas a los mismos de acuerdo al contrato y a través del interfaz definido a tal efecto.

El desafío de SOA Uno de los grandes desafíos de la Arquitectura Orientada a Servicios es resolver la escalabilidad de las conexiones punto a punto, creadas cuando un servicio es consumido por otra aplicación a través de Internet o de una maraña de redes empresariales, donde el número de conexiones crece exponencialmente por cada aplicación que se añade como usuaria y cada Web service que se publica. Con el empleo de un ESB (Enterprise Service Bus o Bus de Servicio Empresarial) cada aplicación se conecta sólo una vez a una infraestructura troncal común, llamada el bus. Esto reduce al mínimo las conexiones y proporciona una ubicación centralizada para su administración, control de acceso y seguridad, gestión y estadísticas del uso y para la gestión de sistemas integrados y arquitecturas. 8

En la Figura 1 mostramos la operación sin un Bus y con bus, para comprobar comparativamente la complejidad de una operación SOA sin un bus

Fig.1 Arquitectura de servicios con bus y sin bus. Pero afortunadamente un ESB brinda mucho más que la concentración del control de acceso, gestión de publicación y estadísticas de uso de un Web Service; un ESB proporciona una plataforma de integración basada en estándares que combinan mensajería, servicios Web, transformación de datos y enrutamiento inteligente. En un ESB las aplicaciones y servicios están unidos en una Arquitectura Orientada a Servicios, permitiendo operar de manera independiente. Un Bus de Servicios Empresariales posee una serie de capacidades que permiten satisfacer la integración de una Arquitectura Orientada a Servicios: 







Mensajería distribuida. El núcleo del ESB lo constituye una aplicación de middleware que proporciona un método de transporte fiable y distribuido, empleando un mecanismo de almacenamiento y reenvío que garantiza la entrega de los mensajes incluso en caso de anomalías en la red. Soporte multiprotocolo en transporte. El protocolo de transporte HTTP no satisface los requisitos de todos los servicios y aplicaciones. Un ESB es capaz de soportar muchos tipos de sistemas de transporte para integrar sistemas dispares y gestionar el transporte de comunicaciones complejas eficazmente. Transformación. Un ESB es capaz de transformar los datos de un formato a otro. En ocasiones el formato de los datos de un servicio no satisface los requisitos de otro servicio, siendo invaluable la función del ESB en esta necesidad Transparencia de las ubicaciones. Con la mediación entre servicios, un cliente que invoque a un servicio no necesita saber su ubicación. El ESB localiza el servicio cuando se invoca, de forma tal que si un equipo falla o si se cambia la ubicación de un proveedor de servicio, no es necesario 9

 



notificar el cambio a cada uno de los consumidores individuales. Esto puede contribuir significativamente a la reducción de los costes de gestión de las TI y a minimizar los riesgos. Calidad de servicio. Un ESB puede proporcionar un servicio de alta fiabilidad garantizando la entrega del mensaje de principio a fin. Enrutamientos. Existen dos tipos de enrutamiento dentro de un ESB. El primer tipo de enrutamiento se produce cuando la invocación de un servicio entra en el ESB y éste encamina la respuesta al proveedor de servicio apropiado. El otro tipo es el enrutamiento basado en el contenido, en el cual se introduce una serie de reglas o una lógica de negocio que se aplica al contenido del mensaje en la etapa del enrutamiento y hacen posible que el ESB encamine los mensajes a proveedores de servicios específicos basándose en su contenido. Con el enrutamiento basado en el contenido se pueden establecer prioridades y marcas a los pedidos, contribuyendo a reducir el coste de la gestión de la Información. Orquestación de servicios. Una herramienta ESB permite orquestar servicios, de modo tal que en ellas se puedan desarrollar procesos que solamente incorporen actividades automáticas y que pueden constituir servicios de negocio.

2.3 BPM BPM en inglés, (Gestión de Procesos de Negocio) es una manera de definir y gestionar lo que sucede dentro de un “proceso de negocio”, desde el comienzo hasta el final. Un proceso de negocio es cualquier secuencia de actividades de interés para una organización. Algunos ejemplos de procesos incluyen: 

Una compañía contrata un nuevo empleado: existen acciones que se deben realizar antes, durante y después de la llegada del empleado  Un usuario con un problema en su ordenador se comunica con el servicio de asistencia especializado: el problema se debe registrar, rastrear, resolver y documentar.  Un cliente lleva un coche que ha sido retirado de circulación debido a una pieza defectuosa a una concesionaria de coches o a un taller: se debe registrar el problema, se debe solicitarla pieza o sacarla del inventario, se debe reparar el coche, se debe notificar a la franquicia,  Un ciudadano adquiere una casa y hace las labores de registro de su adquisición ante una notaría y antes las entidades gubernamentales de registro de la propiedad  Un banco concede un préstamo a un cliente y todas las actividades de estudio, aprobación y constitución de garantías conforman el proceso préstamo bancario

10

La Gestión de Procesos de Negocio en su nivel más simple (descriptivo) hace que el proceso sea explícito y lo ilustra o representa en un modelo, un diagrama de flujo, por ejemplo. En el campo de BPM existen estándares con símbolos específicos utilizados para modelar los procesos de negocio; incluyendo diferentes formas para distinguir las etapas, tareas o actividades realizadas por personas de aquellas que están automatizadas (realizadas por algún software, hardware o una combinación de los dos). 3. Introducción al concepto de gobernabilidad SOA La "Gobernabilidad" en la arquitectura orientada a servicios es un concepto que se refiere a la capacidad de monitorizar y controlar a alto nivel procesos de negocio. Lógicamente no solo estas políticas conforman un gobierno SOA, pero por ahora nos hemos dedicado a ellas como medio de establecer una correcta operación e los buses SOA del Distrito. 4. Políticas de coexistencia de los buses en la empresa 4.1 Definiciones previas Bus de servicios empresariales local a una entidad: Es el bus de servicios cuyo dominio operativo está restringido a prestar servicios de interoperabilidad y orquestación a aplicaciones y procesos locales de la entidad y a procesos internos en la entidad. Este bus no publicará servicios Web que sean consumidos por entidades foráneas de cualquier orden. Bus de servicios empresariales de dominio metropolitano: Es el bus de servicios cuyo dominio operativo comprenden las redes y ámbitos del distrito capital de Bogotá. Como tal publica servicios WEB generados o duplicados en aplicaciones de una entidad para ser consumidos por aplicaciones o usuarios de otras entidades. El bus de servicios empresariales de una corporación o conglomerado de corporacioneses un ejemplo de este tipo de bus Servicios WEB LOCALES /PRIVADOS: Son servicios acoplados conectados débilmente a aplicaciones y procesos internos de una entidad. Como tal nunca se publicarán para ser consumidos por aplicaciones o usuarios foráneos a la entidad, se denominan también Privados. El servicio web privado sólo va a ser consumido por clientes y aplicaciones desarrolladas por la misma organización que lo creó. Servicios WEB PUBLICOS: Son servicios Web publicados para cualquier entidad dentro del distrito que requiera el uso del mismo, es decir no es de uso exclusivo 11

de la entidad que lo genera, si no que puede ser utilizada por cualquier entidad a través de acuerdos de niveles de servicio previamente pactados. Servicios WEB Globales. El servicio web puede ser consumido por cualquier cliente en la nación o el mundo. No es factible realizar una negociación sobre el modo de acceso al servicio. 4.2 Políticas Este conjunto de políticas se sugieren para una Plataforma empresarial de Gestión y Colaboración (PEGC) 1. Los buses de servicios empresariales que están en una fase de diseño y construcción o que están en operación continuarán en operación o hasta que entren en operación. 2. Los buses de servicios empresariales locales a una entidad continuarán ejerciendo como recursos SOA para la propia entidad, publicando y consumiendo los servicios que inter operen entre sus propias aplicaciones y procesos. 3. Los buses de servicios empresariales locales a las entidades no pueden publicar servicios Web que consumirán otras entidades diferentes a la dueña del bus, o no pueden orquestar el consumo de servicios Web publicados en buses empresarial locales de otras entidades. Se exceptúan los casos y situaciones siguientes: a. Cuando por razones de continuidad del negocio un servicio WEB de la PEGC este fallando en su publicación en esta. Debe hacer previos convenios de respaldo entre la PEGC y las entidades participantes en la interoperabilidad. 4. El bus empresarial metropolitano de la PEGC publicará todos los servicios Web decuplicados en las aplicaciones de las entidades y que consuman entidades diferentes a la dueña del proceso original. 5. La PEGC deberá establecer y acordar contratos de servicios y acuerdos de niveles de servicio para la publicación y consumo de web services publicados en su bus empresarial. 6. El bus empresarial de la PEGC no podrá publicar servicios WEB de consumo local de cada entidad. Se exceptúan los casos y situaciones siguientes: a. Cuando la entidad no posea un bus de servicios ni este en proyecto de tenerlo. La PEGC deberá establecer y acordar contratos de servicios y acuerdos de niveles de servicio para la publicación y consumo de servicios Web locales o privados publicados en su bus empresarial. El control de la privacidad de estos servicios WEB está a cargo de la PEGC b. Cuando por razones de continuidad del negocio la PEGC deba dar apoyo de respaldo a otro bus de servicios empresariales local que no esté en condiciones adecuadas de operación 12

7. El bus empresarial de la PEGC se encargará de la publicación de los Servicios WEB Globales nacionales e internacionales. La PEGC deberá establecer y acordar contratos de servicios y acuerdos de niveles de servicio para la publicación de estos servicios web en el ámbito nacional e internacional 8. Estas políticas pre asumen que no existen buses nacionales o regionales de servicio empresariales SOA y que por tanto no existe un Política Nacional de Gobernabilidad SOA con excepción de la Guía de Interoperabilidad de GEL 4.3 Mecanismo de gobierno SOA Como parte integral de la propuesta de gobierno SOA, se complementa con una propuesta de mecanismo que permita dinamizar y darle seguimiento a los procesos que emprenda el gobierno SOA: 1. El lineamiento y la política serán liderados por las altas instancias corporativas Tic. 2. Los procesos de seguimiento, evaluación y administración del gobierno SOA, serán desarrollados por el Grupo de Interoperabilidad de la Comisión Empresarial l de Sistemas. 3. Cada plataforma SOA de cada entidad será administrada y gestionada por la misma entidad participante en un bus

13