Propuesta de Polticas de Gobernabilidad SOA

TABLA DE CONTENIDO1.El concepto fundamental de la Interoperabilidad de Aplicaciones y Procesos32.Concepcin fundamental de SOA y buses de servicios empresariales42.1Definicin de SERVICIO62.1.1Que es un Web Service72.1.2Que es un REST web service?92.2Que es un bus de servicios empresariales?92.3BPM113.Marco de trabajo del documento124.Introduccin al concepto de gobernabilidad SOA125.Polticas de coexistencia de los buses del Distrito Capital125.1Definiciones previas125.2Polticas13

5.3 Mecanismo de gobierno soa

1

12

El concepto fundamental de la Interoperabilidad de Aplicaciones y ProcesosEn el desarrollo de la estrategia de Gobierno en lnea la definicin de interoperabilidad es acogida como:El ejercicio de colaboracin entre organizaciones para intercambiar informacin y conocimiento en el marco de sus procesos de negocio, con el propsito de facilitar la entrega de servicios en lnea a ciudadanos, empresas y a otras entidades.Esta definicin aunque bastante amplia en el sentido de extender la interoperabilidad a la colaboracin de los procesos inter empresariales es bastante aplicable al caso del proyecto de la PLATAFORMA DE GESTIN Y COLABORACIN DE UNA EMPRESA. Esta plataforma tiene como objeto facilitar la gestin interinstitucional a nivel empresarial con medios virtuales para aquellos procesos y procedimientos donde interacten varias entidades.

Tcnicamente hablando desde el punto de vista de la informtica, interoperabilidad de aplicaciones es la habilidad o capacidad de un sistema, aplicacin o producto para trabajar con otro sistema, aplicacin o producto en forma automtica 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 obtencin de la interoperabilidad si se han alcanzado 3 niveles en la interaccin:

Nivel de datos Nivel de funcionalidad y lgica de las aplicaciones Nivel de procesos del negocio de la empresa que son apoyados por cada aplicacin

Normalmente en las empresas se acude al primer nivel mediante la extraccin de datos de las bases de datos o archivos de una aplicaciones sin que la propia aplicacin lo detecte, causando as problemas en la gobernabilidad IT y posteriormente en la operacin o mediante tcnicas ETL (Extract, Transform and Load) para minera de datos, esta ltimas menos invasivas.

En el nivel 2 se logra la interaccin a nivel lgico entre las aplicaciones y programas mediante el uso de APIs, RPC, interfaces, APPS y dems artilugios que aunque permiten esta interaccin en mltiples oportunidades puede perjudicar la operacin propia de las aplicaciones pues no existe una arquitectura apropiada que maneje esta interaccin.

Adicionalmente, existe el Marco de Interoperabilidad para Gobierno en lnea el cual es un conjunto de elementos que orientan el intercambio de informacin a nivel de las entidades pblicas y est constituido por: Principios y polticas que orientan los esfuerzos polticos, legales y organizacionales de las entidades, con el fin de facilitar la interoperabilidad. Un modelo de administracin, compuesto por un modelo de madurez, un modelo de administracin y un modelo de medicin. Un conjunto de recomendaciones, protocolos, estndares y guas metodolgicas, necesarias para que las entidades compartan informacin a travs de servicios de intercambio de informacin, con el propsito de facilitar la prestacin de sus servicios a ciudadanos, empresas y otras entidades pblicas en Colombia.

Concepcin 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 travs de interfaces y contratos bien definidos entre esos servicios. La interfaz se define de forma neutral, y debera ser independiente de la plataforma hardware, del sistema operativo y del lenguaje de programacin utilizado. Esto permite a los servicios, construidos sobre sistemas heterogneos, 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 tecnologas. 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 estn basados en procesos primigenios del negocio.Los conceptos que hoy en da estn asociados a la arquitectura SOA aparecen con la adopcin de Internet y el protocolo HTTP. En el 2003, Roy Schulter acu el trmino SOA por vez primera.Schulter fue uno de los ingenieros que contribuyo tambin a la creacin del http y html los 2 elementos cumbres dela implementacin de InternetEsta arquitectura define y proporciona la infraestructura necesaria para que el intercambio de informacin y la participacin 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 programacin, caractersticas de los equipos, etc.Esta arquitectura presenta un modelo de construccin de sistemas distribuidos en el que la funcionalidad demandada ser entregada a la aplicacin a travs de servicios. Para SOA el mundo informtico o aplicaciones son un conjunto de servicios autnomos independientes de sus plataformas operativas de HW y SW. Para su construccin como toda arquitectura SOA depende de los facilitadores TECNOLGICOS que la implementan. En la Fig. 1 a continuacin describamos esos facilitadores:

Fig. 1: Facilitadores tecnolgicos de la arquitectura orientada a servicios

Definicin de SERVICIO

Un servicio representa una funcin de negocios claramente definida en un proceso,que puede ser invocada remotamente mediante protocolos de comunicaciones estndar, definidas mediante interfaces e independientes de su implementacin interna.Los servicios deben poder ser invocados utilizando protocolos de comunicacin estndar que enfatizan la interoperabilidad e independencia de ubicacin.Los servicios en SOA representan procesos de negocio. Hay una relacin 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 diseado y construido pensando en su reutilizacin dentro de la misma aplicacin, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio pblico 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 implementacin del propio servicio. En el caso de los Servicios Web, se lograr mediante la definicin 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 travs 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 podrn ser totalmente reutilizables. Los Servicios deben permitir la composicin: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genricos 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 orquestacin (WS-BPEL) y coreografa (WS-CDL). Los Servicios deben ser autnomos: Todo servicio debe tener su propio entorno de ejecucin. 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 ejecucin. Los Servicios no deben tener estado: Un servicio no debe guardar ningn tipo de informacin. Esto es as porque una aplicacin est formada por un conjunto de servicios, lo que implica que si un servicio almacena algn tipo de informacin, se pueden producir problemas de inconsistencia de datos. La solucin, es que un servicio slo contenga lgica, y que toda informacin est almacenada en algn sistema de informacin 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 creacin 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.

Qu es un Web ServiceUn 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 travs de la web. Accesible a travs de la web, no a travs de un protocolo especial, ni de una infraestructura especial, ni en una topologa de red especial. Esta condicin garantiza que la invocacin de un servicio web se pueda realizar aprovechando la infraestructura de la web ya existente, sin necesidad de instalar nada especial.

La tecnologa elegida para publicar servicios web debera 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 implementacin real. El servicio puede estar implementado en cualquier tecnologa, lenguajes de programacin, por ejemplo COBOL. La tecnologa real de implementacin, 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 tecnologas distintas, y aun as poder interactuar. Como se coment anteriormente no debera 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 categoras:

Privados. El servicio web slo va a ser consumido por clientes desarrollados por la misma organizacin que lo cre. Denominado tambin local. Pblicos. El servicio web, puede adems 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 tpico tenemos los escenarios B2B. Un ejemplo es el tarificador de seguros que es llamado por un portal de bsqueda para comparar precios para el seguro del automvil. Globales. El servicio web puede ser consumido por cualquier cliente en la nacin o el mundo. No es factible realizar una negociacin sobre el modo de acceso al servicio. Normalmente en este caso se crea una pgina 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 ms informacin necesite el cliente para poder invocar al servicio. Cuanto mayor acoplamiento, mayor cantidad de documentacin tendr qu leer el desarrollador del cliente, y ms esfuerzo se necesitar para la programacin de ste. El hecho de que los servicios web oculten los detalles de su implementacin a travs de una interface es bueno en este sentido, ya que el cliente no necesita saber detalles sobre cmo implementa el servicio su funcionalidad para invocarlo. Otra buena prctica de desacoplamiento es que el servicio sea stateless, de esta manera el cliente no necesita almacenar el estado de la conversacin para poder invocar al servicio correctamente, slo necesita comprender los parmetros que va a enviar.

Analicemos la tecnologa ms popular para hacer servicios web, la pila WS-*. La pila WS-* es un conjunto de protocolos y estndares para realizar servicios web basados en XML. La verdad es que son muchos protocolos y estndares, 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 estndares, nos podemos fijar en los dos ms 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, mviles 3G, etc.). Otra caracterstica importante de SOAP es que es neutral con respecto a la infraestructura. Esto permite invocar procedimientos remotos a travs de distintos protocolos, como por ejemplo SMTP, MQSeries, y como no, HTTP. Se debe tener presente que SOAP no fue diseado para aprovechar HTTP, sino que permite usar HTTP entre otros protocolos.

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 ms pequeos y fciles que los web services con protocolos SOAP, XML, WSDL y dems.

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 propsito principal de un bus de servicios es interconectar a los participantes de una arquitectura SOA. Soporte a la heterogeneidad de tecnologas: debe ser capaz de conectar a participantes basados en distintos lenguajes de programacin, sistemas operativos, entornos de ejecucin y protocolos de comunicacin. Soporte a la heterogeneidad de paradigmas de comunicacin: debe ser capaz de mantener distintos modos de comunicacin (por ejemplo comunicaciones sncronas y asncronas).

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

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

El desafo de SOAUno de los grandes desafos de la Arquitectura Orientada a Servicios es resolver la escalabilidad de las conexiones punto a punto, creadas cuando un servicio es consumido por otra aplicacin a travs de Internet o de una maraa de redes empresariales, donde el nmero de conexiones crece exponencialmente por cada aplicacin que se aade como usuaria y cada Web service que se publica.

Con el empleo de un ESB (Enterprise Service Bus o Bus de Servicio Empresarial) cada aplicacin se conecta slo una vez a una infraestructura troncal comn, llamada el bus. Esto reduce al mnimo las conexiones y proporciona una ubicacin centralizada para su administracin, control de acceso y seguridad, gestin y estadsticas del uso y para la gestin de sistemas integrados y arquitecturas.

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

Fig.1 Arquitectura de servicios con bus y sin bus.

Pero afortunadamente un ESB brinda mucho ms que la concentracin del control de acceso, gestin de publicacin y estadsticas de uso de un Web Service; un ESB proporciona una plataforma de integracin basada en estndares que combinan mensajera, servicios Web, transformacin de datos y enrutamiento inteligente. En un ESB las aplicaciones y servicios estn 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 integracin de una Arquitectura Orientada a Servicios:

Mensajera distribuida. El ncleo del ESB lo constituye una aplicacin de middleware que proporciona un mtodo de transporte fiable y distribuido, empleando un mecanismo de almacenamiento y reenvo que garantiza la entrega de los mensajes incluso en caso de anomalas 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. Transformacin. 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 funcin del ESB en esta necesidad Transparencia de las ubicaciones. Con la mediacin entre servicios, un cliente que invoque a un servicio no necesita saber su ubicacin. El ESB localiza el servicio cuando se invoca, de forma tal que si un equipo falla o si se cambia la ubicacin de un proveedor de servicio, no es necesario notificar el cambio a cada uno de los consumidores individuales. Esto puede contribuir significativamente a la reduccin de los costes de gestin 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 invocacin 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 lgica 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 especficos basndose 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 gestin de la Informacin. Orquestacin de servicios. Una herramienta ESB permite orquestar servicios, de modo tal que en ellas se puedan desarrollar procesos que solamente incorporen actividades automticas y que pueden constituir servicios de negocio.BPMBPM en ingls, (Gestin 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 inters para una organizacin. Algunos ejemplos de procesos incluyen:

Una compaa contrata un nuevo empleado: existen acciones que se deben realizar antes, durante y despus 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 circulacin 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 adquisicin ante una notara y antes las entidades gubernamentales de registro de la propiedad Un banco concede un prstamo a un cliente y todas las actividades de estudio, aprobacin y constitucin de garantas conforman el proceso prstamo bancario

La Gestin de Procesos de Negocio en su nivel ms simple (descriptivo) hace que el proceso sea explcito y lo ilustra o representa en un modelo, un diagrama de flujo, por ejemplo. En el campo de BPM existen estndares con smbolos especficos utilizados para modelar los procesos de negocio; incluyendo diferentes formas para distinguir las etapas, tareas o actividades realizadas por personas de aquellas que estn automatizadas (realizadas por algn software, hardware o unacombinacin de los dos).

Introduccin 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.

Lgicamente no solo estas polticas conforman un gobierno SOA, pero por ahora nos hemos dedicado a ellas como medio de establecer una correcta operacin e los buses SOA del Distrito.

Polticas de coexistencia de los buses en la empresa

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 orquestacin 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 forneas 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 corporacin o conglomerado de corporacioneses un ejemplo de este tipo de bus

Servicios WEB LOCALES /PRIVADOS: Son servicios acoplados conectados dbilmente a aplicaciones y procesos internos de una entidad. Como tal nunca se publicarn para ser consumidos por aplicaciones o usuarios forneos a la entidad, se denominan tambin Privados. El servicio web privado slo va a ser consumido por clientes y aplicaciones desarrolladas por la misma organizacin 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 de la entidad que lo genera, si no que puede ser utilizada por cualquier entidad a travs de acuerdos de niveles de servicio previamente pactados.

Servicios WEB Globales. El servicio web puede ser consumido por cualquier cliente en la nacin o el mundo. No es factible realizar una negociacin sobre el modo de acceso al servicio.

Polticas

Este conjunto de polticas se sugieren para una Plataforma empresarial de Gestin y Colaboracin (PEGC)1. Los buses de servicios empresariales que estn en una fase de diseo y construccin o que estn en operacin continuarn en operacin o hasta que entren en operacin.2. Los buses de servicios empresariales locales a una entidad continuarn 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 consumirn otras entidades diferentes a la duea del bus, o no pueden orquestar el consumo de servicios Web publicados en buses empresarial locales de otras entidades. Se exceptan los casos y situaciones siguientes:a. Cuando por razones de continuidad del negocio un servicio WEB de la PEGC este fallando en su publicacin 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 duea del proceso original.5. La PEGC deber establecer y acordar contratos de servicios y acuerdos de niveles de servicio para la publicacin 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 exceptan 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 publicacin 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 PEGCb. 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 operacin

7. El bus empresarial de la PEGC se encargar de la publicacin 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 publicacin de estos servicios web en el mbito nacional e internacional8. Estas polticas pre asumen que no existen buses nacionales o regionales de servicio empresariales SOA y que por tanto no existe un Poltica Nacional de Gobernabilidad SOA con excepcin de la Gua de Interoperabilidad de GEL

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 poltica sern liderados por las altas instancias corporativas Tic.2. Los procesos de seguimiento, evaluacin y administracin del gobierno SOA, sern desarrollados por el Grupo de Interoperabilidad de la Comisin Empresarial l de Sistemas. 3. Cada plataforma SOA de cada entidad ser administrada y gestionada por la misma entidad participante en un bus