Propuesta de Polticas de Gobernabilidad SOA

TABLA DE CONTENIDO
1. EL CONCEPTO FUNDAMENTAL DE LA INTEROPERABILIDAD DE
APLICACIONES Y PROCESOS......................................................................3
2. CONCEPCIN FUNDAMENTAL DE SOA Y BUSES DE SERVICIOS
EMPRESARIALES...........................................................................................4
2.1

Definicin 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. INTRODUCCIN AL CONCEPTO DE GOBERNABILIDAD SOA.........12
5. POLTICAS DE COEXISTENCIA DE LOS BUSES DEL DISTRITO
CAPITAL.........................................................................................................12
5.1

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

5.2

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

2. 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 Internet
Esta 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

2.1 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.
5

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

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

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
9

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.

2.3 BPM
BPM 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

10

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 una
combinacin de los dos).
3. 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.
4. Polticas 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
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
11

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.
4.2 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 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 operacin
12

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
internacional
8. 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
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 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

13