ARQUITECTURA ORIENTADA A

SERVICIOS (SOA) Y
TECNOLOGAS

1 INTRODUCCIN
Hoy en da, las aplicaciones empresariales a
gran escala se estn tejiendo cada vez ms
desde aplicaciones, paquetes y componentes
que nunca fueron diseados para trabajar
juntos e incluso pueden funcionar en
plataformas incompatibles. Esto da lugar a
una necesidad crtica de interoperabilidad y los servicios web en
conjunto con las arquitecturas orientadas a servicios son la
respuesta a esta necesidad de tecnologas de integracin
interoperables, permitiendo que las aplicaciones invoquen la
funcionalidad proporcionada por otras aplicaciones.
Aunque es posible disear y construir "sistemas orientados al
servicio" utilizando cualquier middleware de computacin o
integracin distribuida, slo las tecnologas de servicios web
pueden satisfacer hoy el requisito crtico para la interoperabilidad
transparente que es una parte tan importante de la visin
orientada al servicio.

2 SISTEMAS ORIENTADOS A SERVICIOS

El cambio a los sistemas orientados al servicio est siendo impulsado
por la necesidad de integrar tanto las aplicaciones como los sistemas
empresariales que soportan.
Los servicios web son realmente simplemente otra tecnologa de
integracin de aplicaciones. Diferentes tecnologas de integracin son
conceptualmente muy parecidas: las aplicaciones cliente pueden
descubrir servidores, descubrir qu servicios estn ofreciendo e invocar
las funciones que proporcionan. Lo que es diferente acerca de los
sistemas orientados al servicio y sus tecnologas de soporte es que
ahora se espera que estas aplicaciones y servidores sean accedidos
por organizaciones externas e individuos a travs de la Internet
pblica. El resultado de este cambio de enfoque es un conjunto de
normas y principios arquitectnicos
que hacen hincapi en la
interoperabilidad.

Los principios fundamentales que

subyacen a las arquitecturas
orientadas a los servicios son los
siguientes:

2.1 Los lmites son explcitos

El acceso a un servicio requiere, al menos, cruzar los lmites que
separan procesos, y probablemente atravesar redes y hacer
autenticacin de usuario entre dominios. Cada uno de estos lmites
(proceso, mquina, confianza) que hay que cruzar reduce el
rendimiento, agrega complejidad y aumenta las posibilidades de
fracaso. Es importante destacar que tienen que ser
conscientemente reconocidos y manejados dentro del proceso de
diseo.

2.2 Los servicios son autnomos

Los servicios son aplicaciones autnomas independientes, no
necesitan saber nada acerca de las aplicaciones cliente y pueden
aceptar solicitudes de servicio entrantes desde cualquier lugar. Todo
lo que los clientes saben acerca de un servicio es qu mensajes
aceptar y devolver, y esta es la nica dependencia que existe
entre un cliente y un servicio.

2.3 Compartir esquemas y contratos, no implementaciones

Todo lo que una aplicacin necesita saber acerca de un servicio es
su contrato: el esquema de los mensajes que va a aceptar y
devolver, y si tienen que ser enviados en cualquier orden en
particular. Las aplicaciones cliente pueden utilizar dicho contrato
para crear mensajes de solicitud para enviar a un servicio y los
servicios pueden utilizar sus esquemas para validar los mensajes
entrantes y asegurarse de que estn correctamente formateados,
mas no comparten cdigo de mtodos o entornos complejos de
tiempo de ejecucin.

2.4 La compatibilidad de servicios se basa en polticas

Compatibilidad no es solo cerciorarse de que los clientes estn
siguiendo los formatos de mensajes y patrones de intercambio
especificados, sino tambin que se cumple con los requisitos no
funcionales. En el modelo orientado a servicios, estos requisitos se
definen mediante polticas. Las polticas son colecciones de
sentencias legibles por mquina que permiten a un servicio definir
sus requisitos para temas como seguridad y confiabilidad.
3 SERVICIOS WEB
Los servicios web son un conjunto de estndares
de tecnologa de integracin diseados para
satisfacer los requisitos que surgen de
arquitecturas y sistemas orientados a servicios.
De muchas maneras, los servicios web no son tan
diferentes de las tecnologas de middleware
existentes, pero difieren en su enfoque de
simplicidad e interoperabilidad.

Todas las tecnologas de integracin de aplicaciones, incluidos los

servicios web, proporcionan cuatro funciones bsicas que permiten a
los desarrolladores (y programas) hacer lo siguiente:
- Buscar servicios adecuados (utilizando UDDI u otro directorio)
- Obtener informacin sobre un servicio (mediante WSDL)
- Solicitar un servicio para hacer algo (utilizando SOAP)
- Hacer uso de servicios como la seguridad (utilizando estndares
WS- *)
Uno de los principios simplificadores
que subyacen a los servicios web es
que los diversos campos y atributos
de mensajes utilizados para soportar
funciones como la seguridad y la
fiabilidad son totalmente
independientes entre s. Las
aplicaciones solo necesitan incluir los
campos y atributos necesarios para
sus propsitos especficos y pueden ignorar todas las dems normas.
Los servicios web brindan soporte para arquitecturas basadas en
intermediarios. Los intermediarios pueden hacer cualquier cosa con los
mensajes que reciben, incluyendo enrutamiento, registro, verificacin
de seguridad, o incluso agregando o restando bits del contenido del
mensaje.

1 SOAP Y MENSAJERIA
SOAP fue el estndar servicio web y es el ms importante y el ms
ampliamente usado debido a su simplicidad ya que se mantiene alejado
de problemas complejos como pasar objetos por referencia. Lo que realiza
SOAP es definir un protocolo orientado a mensaje para invocar servicios
locales usando HTTP, SMTP, UDP u otros protocolos de la capa de
transporte y XML para dar formato a los datos.
Los mensajes SOAP tienen una simple estructura: una cabecera que
contiene algunos elementos como tokens de seguridad, contenido de la
transaccin; y el cuerpo que contiene el mensaje pasado entre
aplicaciones.
Al usar SOAP, los clientes SOAP mandan un mensaje de solicitud en
formato XML a los proveedores de servicios por cualquier transporte y le
puedan devolver el mensaje de respuesta en XML. Esta solicitud contiene,
en el encabezado, al usuario y una contrasea hasheada para saber quin
enva la solicitud.
La ventaja del uso de SOAP es que no solo depende del protocolo HTTP de
la capa de transporte ya que puede mandar el mensaje a travs cualquier
protocolo de transporte como TCP/IP, UDP, SMTP, colas de mensajes y WS-
Addressing que provee un mecanismo de transporte neutral; EL uso del
modelo publicador-suscriptor tambin es soportado mediante el WS-
Eventing, ya que los mensajes del publicador pueden ser mandados a
travs de mensajes SOAP.

2 UDDI, WSDL Y METADATOS

Los servicios SOAP son descritos usando WSDL y pueden ser localizados
usando el directorio UDDI.
Los servicios pueden describir sus requerimientos como seguridad,
confiabilidad usando polticas definidas por WS-Policy framework, y
polticas especializadas como WS-SecurityPolicy, estas pueden estar
unidas a la definicin servicios WSDL o separada en almacenes y
recuperadas usando WS-MetadataExchange.
Aunque el UDDI es una de los tres originales servicios web es el menos
utilizados o el que tiene mejor potencial dependiendo si se puede vincular
las aplicaciones con los servicios. Actualmente las organizaciones
desarrollan sistemas de servicios web sin necesidad del uso del directorio
UDDI utilizando otros mtodos u otros servicios publicados en internet.
WSDL, mencionado
anteriormente, sirve para
describir los servicios web
incluidas sus interfaces,
mtodos y parmetros; este
formato es soportado por
diversos entorno de
desarrollos como Visual
Studio, Eclipse mediante el
uso de herramientas se puede
autogenerar con sus mtodos
e interfaces ayudando a los
desarrolladores escribir
cdigo que llama a estos servicios lo que puede hacer pensar a los
programadores que los servicios son mtodos remotos en vez de utilizar el
modelo basado en mensajes de los servicios web.

3 SEGURIDAD, TRANSACCIONES Y CONFIABILIDAD

Uno de los problemas a la hora de usar protocolos de los middlewares es
que no funcionan bien en Internet debido a las barreras de conexiones
impuestos por el firewall. Pero la tecnologa comn responde a ese
problema adoptando los servicios web usando HTTP ya que pasa a travs
de la mayora de firewalls, pero tambin crea problemas de seguridad
potenciales ya que podran realizar llamadas directas en aplicaciones
internas.
WS-Security y sus direcciones estndares asociadas a estos problemas
proveen unos fuertes mecanismos criptogrficos que brindan
autenticacin, encriptacin y firmas digitales adems estos estandartes
son extensibles pudiendo adaptarse a nuevas tecnologas de seguridad y
algoritmos.
WS-Security soporta arquitectura de aplicaciones intermediarias que
permitan la seguridad de los elementos de cabecera, cada uno etiquetado
con su rol y apoyando a la una parcial encriptacin y firmas.
El ltimo conjunto de estandartes de servicios web apoya a las
transacciones y la mensajera confiable. Por parte de las transacciones,
hay dos tipos de transacciones de servicios web apoyados por estandartes
como el WS-AtomicTransaction que se apoya las transacciones ACID y
asume niveles de confianza y tiempos de respuesta rpidos que hace
adecuado solo para tareas de aplicaciones de integracin interna pero no
para sus propsito; tambin existe el WS-BusinessActivity que es un
framework y conjunto de elementos de protocolos que provee apoyo para
la atomicidad de compensadores invocadores cuando una aplicacin
distribuida termina en fracaso.

El apoyo para los mensajes confiables se utiliza WS-ReliableMessaging,

aunque no garantiza la entrega en caso de fallo como los middlewares de
mensajera en cola, sigue siendo un estndar til ya que entrega el
mensaje por cualquier protocolo de la capa de transporte como UDP o

SMTP.

4 SERVICIOS WEB RESTFUL

Servicios Web RESTful confa en HTTP como un protocolo que conoce lo
que necesita las aplicaciones que usan servicios web; utiliza get, post, put
y delete para la transferencia de datos en forma de documento XML entre
los clientes y servicios que proporciona los "recursos" identificados por las
URI (Uniform Resource Identifiers). El uso de HTTP y las tecnologas web
hacen que RESTful pueda manejar la infraestructura web completa.
RESTful compite con las tecnologas basadas en SOAP, mucho argumentos
entre estos dicen que RESTful es simple en comparacin a SOAP y WS-*,
aunque esto depende de los problemas tcnicos y arquitectnicos que se
desee resolver, si es que necesitas resolver problemas complejos que
enfrenta una aplicacin distribuida o una arquitectura de integracin de
aplicaciones se recomienda SOAP con los estndares WS-*. En cambio,
RESTful construye servicios web que pueden ser adaptados a muchos
problemas especialmente donde la seguridad, confiabilidad y la
interoperabilidad no son tan importante.
TECNOLOGAS DE MIDDLEWARE
AVANZADO
En lo mencionado antes, se habla de los componentes de
middleware que se pueden implementar en arquitecturas de
sistemas distribuidos a gran escala. Pero esto sin embargo no es
suficiente para los desarrolladores en disear e implementar
arquitecturas ms complejas, de tal caso necesitas de otras
herramientas y diseos ms avanzados. En esta parte hablaremos
de dos: Message Brokers y Workflow Engines.

1 MESSAGE BROKERS
La mensajera bsica utilizando MOM y Publicador-Suscriptor es
suficiente para muchas aplicaciones porque es un enfoque simple y
eficaz que ofrece altos niveles de rendimiento y fiabilidad. Las
implementaciones de MOM empiezan a ser complejas en la integracin
del dominio de la empresa, donde el problema bsico es la
construccin de aplicaciones empresariales que nunca fueron
diseados para trabajar juntos e intercambiar informacin. Para la
integracin empresarial ha surgido un middleware conocidos como
MESSAGE BROKERS.
Explicaremos con un ejemplo el funcionamiento del middleware
MESSAGE BROKERS, supongamos que una organizacin tiene cuatro
sistemas empresariales heredados que contienen informacin sobre
clientes. Cada uno de los sistemas almacena datos de los clientes
como datos nicos. Cada sistema tiene un registro de cliente diferente,
tambin tienen nombres de datos diferentes (Por ejemplo, uno utiliza
ADDRESS, otro LOCATION). Para poder actualizar los datos estos usan
una API que est disponible para cada sistema heredado. Aunque esto
es conceptualmente simple, es un problema para muchas
organizaciones, por lo tanto mantener los datos correctos es un
problema. Por ello deciden poner una pgina web donde los clientes
puedan actualizar sus propios datos en lnea.
La organizacin utiliza MOM para comunicarse entre los sistemas. Por
consecuente, el componente web formatea un mensaje con los nuevos
datos cliente y utiliza MOM para enviar el mensaje a cada sistema
heredado.
Los datos duplicados como estos son muy comunes en las empresas.
Por ejemplo, mi banco enva mi estado de cuenta a diferentes
direcciones. El MOM puede implementar una cola diferente para cada
aplicacin heredada o una sola cola e incluir un campo destino en
cada mensaje.
Cada sistema heredado tiene un componente de interfaz de cola que
puede leer mensajes desde la cola, crea una llamada a los datos del
cliente API de actualizacin que soporta este sistema heredado. Si
cualquier API del sistema heredado cambia, sola la modificacin para
este sistema debe ser probado. Modificar esto requiere coordinacin
con el equipo de desarrollo responsable del mantenimiento de los
sistemas heredado. Estos son los que conocen a fondo de cmo
acceder a la API del sistema heredado. Por lo tanto existe un estrecho
acoplamiento en esta arquitectura. Esto se debe a la necesidad que se
pongan de acuerdo sobre el formato del mensaje que se comunica. En
las grandes organizaciones, comunicar este tipo de mensaje y
coordinar a un formato comn es un poco tedioso, por eso esta
transformacin se deja a un formato web, esto significa que cada
sistema heredado interacte con el API con el mensaje en el formato
que necesitan. La principal desventaja es la complejidad del
componente web. MESSAGE BROKERS ofrece una solucin alternaba
mucha ms atractiva arquitectnicamente, un BROKER es un patrn de
arquitectura que incorpora un componente que desacopla cliente y
servidores. Del mismo modo un middleware intermediario de mensajes
aumenta las capacidades de un MOM.
No es un trabajo masivo implementar el patrn BROKER ya que tiene la
desventaja de la lgica en la transformacin del cdigo en el programa.
Para transformaciones sencillas no es problema pero las empresas
grandes requieren transformaciones complejas. Las tecnologas en
MESSAGE BROKERS proporcionan herramientas especializadas para:

Descripcin graficas de transformaciones complejas entre

formatos de entrada y salida.
Alto rendimiento en mensajes multitarea que pueden manejar
mltiples solicitudes de transformacin simultnea.
Describir y ejecutar flujos de mensajes.

El mapeo puede generar las transformaciones necesarias para mover

datos entre dos esquemas XML, con las lneas que representan mapeo
de origen y destino pueden asociarse para definir asignaciones ms
complejas. Por lo tanto los intermediarios de mensajes son esenciales
para la transformacin de mensajes, la definicin de las
transformaciones de mensajes pueden ser:

Fcil de entender y modificar

Gestionado centralmente
Ejecutado por un Brokers de transformacin de multiproceso de
alto rendimiento.
Por supuesto mientras ms compleja sea la lgica del MESSAGE
BROKERS, implementarlo ser ms complejo.
6.3 ORQUESTACIN DEL PROCESO DE NEGOCIO
Los procesos de negocio en las empresas pueden ser complejas en
trminos de nmero de aplicaciones empresariales que deben ser
visitados y actualizadas para completar el servicio de negocio.
Las transacciones de compensacin son unos mecanismos que
permiten al diseador de proceso definir explcitamente la lgica
necesaria para deshacer una transaccin fallida que parcialmente se
ha completado. Los procesos empresariales de larga ejecucin no son
factibles debido a que no se pueden acceder a los datos bloqueados
por transacciones simultneas y por lo tanto la contencin de bloqueo
har esperar hasta la liberacin de estos en tal situacin no es
probable que produzcan un alto rendimiento y sean escalables para la
implementacin de procesos empresariales de larga ejecucin en el
proceso de negocio. El comportamiento transaccional para procesos de
larga duracin son manejadas por una serie de actividades en un
mbito de transaccin de larga ejecucin.
Las transacciones de larga ejecucin comprenden varias actividades de
proceso que no coloque cerraduras en los elementos de datos, las
actualizaciones se realizan localmente y estn comprometidos en cada
sistema de negocio, el papel del compensador es deshacer los efectos
de la transaccin comprometidos, esto significa deshacer cualquier
cambio realizado en la transaccin dejando los datos en el mismo
estado que tena antes de iniciar la transaccin.
Las plataformas estn diseadas para hacer que la aplicacin sea
relativamente sencillo, las plataformas son tpicamente construidas
como una capa que aprovecha alguna forma de infraestructura de
mensajera tales como SOA o un intermediario de mensajes.

Administracin de estado: el estado de ejecucin de un proceso

empresarial se almacenan permanentemente en una base de datos,
una vez almacenado no consume los recursos computacionales en
la BPO hasta que se reanuda la instancia de flujo de trabajo.
 Herramientas de desarrollo:
proporciona herramientas para
definir los procesos de negocio
Herramientas de
implementacin: permiten
vincular fcilmente los pasos
del proceso de negocio para
los sistemas subyacentes
mediante el uso de tipos de
conectividad.
BPO motores son la adicin ms
reciente a la pila de middleware
cuya funcionalidad es
automatizar el proceso de
negocio que accede a
aplicaciones de negocio independiente.

6.4 LA ARQUITECTURA DE INTEGRACIN DE TEMAS

La dificultad de integrar aplicaciones heterogneas
en las grandes empresas es un problema serio, en el
fondo es un problema arquitectnico sobre
modificabilidad.
Cambiar una aplicacin de interfaz de mensajes se
convierte en un terrorfico ejercicio en esas
empresas, a veces el cambio es tan aterrador que
equipos de desarrollo simplemente optan por no
hacerlo.

En general el nmero de interfaces entre N aplicaciones es (N 2N )

, as que a medida que N aumenta, el nmero de interfaces posibles
crece exponencialmente, haciendo punto a punto nonscalable
arquitecturas en trminos de modificabilidad.
Muchas aplicaciones tienen ms de una interfaz de modo que en
realidad el nmero de interfaces entre dos aplicaciones fuertemente
acopladas puede ser considerablemente mayor que uno.
Otro nombre para un punto a punto es una arquitectura de
espagueti, cuando la disciplina floreci a finales de la dcada de
1990, el incipiente dogma fue que las arquitecturas de espagueti
deben evitarse a toda costa, la solucin promovida por muchas buenas
razones era utilizar un intermediario de mensajes.
Las desventajas de su uso son:

La arquitectura de espagueti todava existen dentro del Message

brker, donde las dependencias complejas entre los formatos de
 mensaje son capturados en brker de mensaje definido por
transformaciones.
Los corredores son potencialmente un cuello de botella de
rendimiento como todos los mensajes entre las aplicaciones.
Hay un enfoque de diseo que puede utilizarse que posee la
escalabilidad de un punto a punto de la arquitectura con la
modificabilidad, la solucin es definir un modelo de datos de la
empresa que se convierte en el formato de destino para todas las
transformaciones de mensajes entre aplicaciones.
Supongamos que definimos un formato de mensaje cannico para la
informacin del cliente, este puede ser usado como el formato de
destino para cualquier aplicacin empresarial que se necesita para el
intercambio de datos relacionados con el cliente. Utilizando este
formato de mensaje, un intercambio de mensaje se reduce ahora a los
pasos siguientes:

Fuente de aplicacin local del cliente: transforma datos en formato

cannico de la informacin del cliente.
Enva el mensaje al destino con formato de mensaje cannico como
carga til.
Recibe el mensaje y transforma el formato cannico en sus propios
locales de representacin de datos del cliente.
Cada punto final debe conocer:
Como transformar todos los mensajes que recibe desde el formato
cannico a su formato local.
Como trasformar todos los mensajes que enva dese su formato
cannico.
La principal dificultad de disear y llegar a un acuerdo sobre el modelo
de datos de una empresa en una organizacin grande.
La razn por la que las soluciones basadas en brker son exitosos es
por reconocen la realidad de los sistemas empresariales y la necesidad
de construir muchas transformaciones ad hoc entre sistemas en una
forma sustentable.

6.5 QU ES UN BUS DE SERVICIOS DE EMPRESA?

Un ESB proporciona los mecanismos fundamentales de integracin
complejos a travs de una de las arquitecturas orientada a eventos y
motor de mensajera basada en estndares. Proporciona generalmente
una infraestructura basada en mensajera middleware con la habilidad
de conectarse al sistema externo endpoints a travs de una variedad
de protocolos: TCP/IP, SOAP, JMS, FTP y muchos ms.