Arquitecturas Orientadas a Servicios

y Tecnologas

Background
Las arquitecturas orientadas al servicio y los servicios Web son el
ltimo paso en el desarrollo del middleware de integracin de
aplicaciones. Tratan de solucionar los problemas de interoperabilidad
del pasado y proporcionan una base para futuras aplicaciones
distribuidas a escala de Internet. Tambin intentan, y hasta cierto
punto triunfan, marcar el final de las "guerras de middleware" con
todos los principales proveedores finalmente llegando a un acuerdo
sobre un nico y rico conjunto de estndares tecnolgicos para la
integracin de aplicaciones y la computacin distribuida.
La realidad es que las aplicaciones empresariales a gran escala estn
cada vez ms tejidas entre 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, que se hace an ms importante a medida que las
organizaciones comienzan a construir una nueva generacin de
aplicaciones integradas de rea amplia que incorporan directamente
funciones alojadas por socios comerciales y proveedores de servicios
especializados.

Sistema Orientado a Servicios

El cambio hacia los sistemas orientados al servicio est siendo
impulsado por la necesidad de integrar tanto las aplicaciones como los
sistemas empresariales que soportan. La mayora de las tecnologas de
integracin existentes son cerradas o propietarias y slo admiten la
integracin de aplicaciones basadas en la misma tecnologa, a menos
que las organizaciones estn dispuestas a soportar el costo de comprar
o escribir cdigo de adaptador complejo y especial.
La figura muestra una tpica aplicacin de venta al por menor basada
en Internet. Los clientes ven una sola aplicacin transparente que les
permite realizar pedidos de libros y msica y realizar pagos. En
realidad, esta aplicacin consiste en un pequeo ncleo de lgica de
negocio proporcionado por el minorista aumentado por los servicios
proporcionados por los socios de negocios, y todo funcionando en una
mezcla diversa de plataformas y middleware. Los clientes pueden
acceder a esta aplicacin mediante navegadores Web o pueden ejecutar
aplicaciones cliente ms amigables y inteligentes que realizan
llamadas directamente a los servicios de fondo proporcionados por la
aplicacin principal del minorista. Estos mismos servicios tambin se
pueden utilizar para apoyar los servicios de outsourcing de la entrega
de la orden proporcionados a los minoristas especializados,
permitindoles poseer y funcionar sus propios frentes de tienda en
lnea y confiar en el minorista para los servicios tales como manejar
rdenes y aceptar pagos. Esta aplicacin podra ser construida
utilizando cualquiera de las tecnologas de middleware discutidas en
captulos anteriores. Sin embargo, el arquitecto de cualquier sistema
de este tipo se enfrentar a cuestiones difciles y complejas que
garanticen la interoperabilidad y la robustez.
Estas son precisamente las reas atendidas por arquitecturas
orientadas a servicios y tecnologas de servicios web. Los principios
bsicos subyacentes a las arquitecturas orientadas al servicio se
expresan a menudo como cuatro principios:
Los lmites son explcitos
Los servicios son autnomos
Compartir esquemas y contratos, no implementaciones
La compatibilidad del servicio se basa en la poltica Echemos un
vistazo a cada uno de ellos.

Los lmites son explcitos

El primero de los principios reconoce que los servicios son

aplicaciones independientes, no
slo el cdigo que est vinculado a su programa que se puede llamar a
casi ningn costo.
El acceso a un servicio requiere, al menos, cruzar los lmites que
separan
procesos y probablemente atravesando redes y haciendo autenticacin de
usuario entre dominios.
Cada uno de estos lmites (proceso, mquina, confianza) que tiene que
ser
cruzado reduce el rendimiento, aumenta la complejidad y aumenta las
fracaso.

Los servicios son autnomos

Los servicios son aplicaciones autnomas independientes, no clases o

componentes que estn estrechamente vinculados a las aplicaciones
cliente. Los servicios estn destinados a ser desplegados en una red,
posiblemente la Internet, donde se pueden integrar fcilmente en
cualquier aplicacin que les resulte til. Los servicios no necesitan
saber nada acerca de las aplicaciones cliente y pueden aceptar
solicitudes de servicio entrantes desde cualquier lugar, siempre y cuando
los mensajes de solicitud estn correctamente formateados y cumplan con
los requisitos de seguridad especificados.
Los servicios se pueden implementar y gestionar completamente y los
propietarios de estos servicios pueden cambiar sus definiciones,
implementaciones o requisitos en cualquier momento.
 Dado que los servicios son autnomos, tambin son responsables de su
propia seguridad y tienen que protegerse contra posibles llamadas
malintencionadas.

Compartir esquemas y contratos, no implementaciones

Todo lo que una aplicacin necesita saber sobre un servicio es su

contrato: la estructura (esquema) de los mensajes que aceptar y
devolver, y si tienen que ser enviados en cualquier orden
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.

La compatibilidad de los servicios se basa en la poltica

Las polticas son colecciones de instrucciones legibles por mquina

que permiten a un servicio definir sus requisitos para cosas como
seguridad y fiabilidad. Estas polticas pueden incluirse como parte del
contrato de un servicio, lo que le permite especificar completamente el
comportamiento y las expectativas de un servicio, o pueden mantenerse
en almacenes de polticas independientes y obtenerse dinmicamente en
tiempo de ejecucin.
Las polticas basadas en contrato pueden considerarse slo una parte
de la documentacin de un servicio, pero tambin pueden ser utilizadas
por herramientas de desarrollo para generar automticamente cdigo
compatible para clientes y servicios.
La separacin de las polticas de los contratos tambin permite que
las aplicaciones cliente se adapten dinmicamente para satisfacer los
requisitos de un proveedor de servicios particular. Esto ser cada vez
ms til a medida que los servicios se normalizan y se ofrecen por los
proveedores de la competencia. El uso de polticas dinmicas permite a
nuestros desarrolladores escribir una sola aplicacin que admita ambos
mtodos de autenticacin y selecciona dinmicamente cul utilizar para
obtener la directiva del servicio de destino antes de construir y enviar
las solicitudes de entrega.

Servicios web

Los servicios web son un conjunto de estndares de tecnologa de

integracin diseados especficamente para satisfacer los requisitos que
surgen de las arquitecturas y sistemas orientados al servicio por su
simplicidad y interoperabilidad.
Todas las tecnologas de integracin de aplicaciones, incluidos los
servicios Web, slo proporcionan cuatro funciones bsicas que permiten
a los desarrolladores (y programas) hacer lo siguiente:
Buscar servicios adecuados (utilizando UDDI u otro directorio)
Conozca un servicio (utilizando WSDL)
Solicite un servicio para hacer algo (utilizando SOAP)
Hacer uso de servicios como la seguridad (usando estndares WS-
*)
SOAP, WSDL y UDDI fueron los primeros estndares de servicios web que
se publicaron, pero slo cumplen con los requisitos ms bsicos para la
integracin de aplicaciones. Ellos carecen de soporte para seguridad,
transacciones, confiabilidad y muchas otras funciones importantes. Esta
brecha se est llenando progresivamente con una serie de estndares
(comnmente llamados "WS- *"), expuestos por primera vez por IBM y
Microsoft en un taller del W3C en 2001.

Los servicios web son estndares XML. Los servicios se definen mediante
XML y los servicios de solicitud de aplicaciones mediante el envo de
mensajes XML y los estndares de servicios Web hacen uso extensivo de
otros estndares XML existentes siempre que sea posible. Existen varios
estndares de servicios Web y estos pueden ser organizados en las
categoras que se muestran en la Figura

Otro objetivo de los estndares de servicios web es proporcionar un

buen soporte para las arquitecturas de sistemas que hacen uso de
"intermediarios". En lugar de suponer que los clientes siempre envan
solicitudes directamente a los proveedores de servicios, el modelo
intermedio asume que estos mensajes pueden (transparentemente) pasar a
lo largo de una cadena de otras aplicaciones en su camino hacia su
destino final. Estos 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.

SOAP y Mensajera
SOAP era el estndar de servicios web original y sigue siendo el ms
importante y usado. Especifica un simple pero extensible XML basado en
protocolo de comunicacin aplicacin-a-aplicacin, aproximadamente
equivalente a RPC de DCE o Java RMI, pero mucho menos compleja y mucho
ms fcil de implementar.
Todo el SOAP estndar es definir un protocolo simple pero extensible
orientado a mensajes para invocar servicios remotos, utilizando HTTP,
SMTP, UDP u otros protocolos como la capa de transporte y XML para el
formato de datos.
 Envoltura: Marca el inicio y el final
de un mensaje

Encabezado: Informacin general sobre

el mensaje

Cuerpo: Datos del mensaje o documento

actual que se est enviando

Los clientes SOAP envan mensajes de solicitud XML a los proveedores

de servicios sobre cualquier transporte y puede obtener mensajes de
respuesta XML a cambio.

Hay una serie de otros estndares incluidos en los servicios Web

Messaging incluyendo WS-Addressing y WS-Eventing. WS-Addressing existe
porque los servicios Web realmente tienen poco que ver con la Web y no
dependen nicamente en HTTP como capa de transporte. Los mensajes SOAP
pueden enviarse por cualquier protocolo de transporte, incluyendo TCP
/ IP, UDP, correo electrnico (SMTP), colas de mensajes, y WS-
Addressing proporciona mecanismos neutrales al transporte para abordar
los mensajes. WS-Eventing proporciona soporte para un modelo
publicador-suscriptor.

UDDI, WSDL y metadatos

Existe un fuerte tema de metadatos y polticas que se ejecutan a
travs de los estndares de servicios Web. Los servicios SOAP
normalmente se describen utilizando WSDL y puede localizarse mediante
la bsqueda en un directorio UDDI. Los servicios pueden describir sus
requerimientos de seguridad y fiabilidad utilizando declaraciones de
polticas, definidas WS-Policy framework y normas de polticas
especializadas como WS-SecurityPolicy.
Estas polticas se pueden adjuntar a una definicin de servicio WSDL o
mantenerse en una poltica independiente almacenada y recuperada
mediante WS-MetadataExchange.

UDDI ha demostrado ser el menos utilizado hasta ahora de los tres

servicios Web originales. En muchos sentidos, UDDI es el menos
interesante o potencialmente ms interesantes de estos estndares,
dependiendo de lo importante que creas poder descubrir y vincular a
los servicios de tu aplicacin.
Las organizaciones desarrollan grandes sistemas complejos de servicios
Web sin el uso de directorios UDDI, utilizando otros mtodos de
bsqueda de servicios como el contacto personal o listas publicadas de
servicios en sitios Web.
Todo esto podra cambiar en el futuro, especialmente cuando las
asociaciones de la industria comienzan a publicar definiciones de
servicio comn y la necesidad de publicar directorios de proveedores
de servicios calificados.
WSDL se utiliza para describir servicios Web, incluyendo sus
interfaces, mtodos y parmetros.
Seguridad, Transacciones y Fiabilidad
Uno de los problemas que enfrentan la mayora de los protocolos de
middleware es que no funcionan bien en el Internet abierto debido a
las barreras de conectividad impuestas por los firewalls.

La respuesta tecnolgica comn a este problema, y la adoptada por

Servicios Web, ha sido co-optar el protocolo Web, HTTP, como una capa
de transporte debido a su capacidad de pasar a travs de la mayora de
firewalls. Este uso de HTTP es convencional pero tambin crea posibles
problemas de seguridad.

WS-Security y sus direcciones standards asociadas a estos problemas de

los sistemas de criptogrficos para identificar los callers,
(autentificacin), y garantizar la integridad (firma digital)
Estos estndares estn diseados para ser extensibles, los que se
adaptan para nuevas tecnologas de seguridad y algoritmos, y tambin
integracin con tecnologa de seguridad legal.

Existen dos tipos de servicios web de negocios compatibles con

estndares.
WS-AtomicTransactions admite compatibilidad convencional distribuida
ACID y los niveles de confianza y las respuestas de tiempo rpido que
hacen este estndar slo para aplicaciones internas de integracin de
aplicaciones.
WS-BusinessActivity es un framework y un conjunto de protocolos
elementales para coordinar la terminacin delas aplicaciones
integradas.

Servicios web de RESTful

Los servicios Web RESTful se basan en HTTP como protocolo

suficientemente rico para satisfacer las necesidades de las
aplicaciones de servicios Web. En el modelo REST, el HTTP GET,los
verbos POST, PUT y DELETE se utilizan para transferir datos (a menudo
en forma de documentos XML) entre cliente y servicios.
Estos documentos son "representaciones" de
"Recursos" identificados por los URls Web normales.
Este uso de tecnologas estndar HTTP y Web significa que los
servicios Web RESTful pueden aprovechar toda la infraestructura Web,
como el almacenamiento en cach y la indexacin.

Tecnologas Avanzadas de Middleware

Message Broker

La mensajera bsica que utiliza MOM y las tecnologas de suscripcin

de publicacin es suficiente para muchas aplicaciones. Cuando los
formatos de mensajes no estn totalmente de acuerdo entre las
distintas aplicaciones que se comunican utilizando la MOM surge un
problema, que ocurre comnmente en el dominio de la integracin
empresarial, donde el problema bsico es la creacin de aplicaciones
empresariales a partir de grandes y complejos sistemas empresariales
heredados que nunca fueron diseados para trabajar juntos e
intercambiar informacin. La integracin empresarial es todo un campo
de estudio en s mismo.

Aqu es donde los corredores de mensajes ofrecen una solucin

alternativa potencialmente atractiva. Arquitectnicamente, un corredor
es un patrn de arquitectura conocido que incorpora un componente que
desacopla clientes y servidores mediando las comunicaciones entre
ellos. Del mismo modo, middleware intermediario de mensajes aumenta
las capacidades de una plataforma MOM para que la lgica de negocios
relacionados con la integracin se puede ejecutar dentro del corredor.

Una solucin de intermediario de mensajes es atractiva porque

desacopla completamente el componente web y los componentes de
interfaz heredados. El componente web simplemente ensambla y emite un
mensaje y el intermediario transforma el mensaje en el formato
necesario para cada sistema heredado. A continuacin, enva un mensaje
de salida a los componentes de la interfaz del sistema heredado en el
formato preciso que deseen. Otra atraccin es la simplificacin de
todos los componentes del sistema, ya que ahora no tienen que
preocuparse por la transformacin del formato del mensaje. La lgica
de transformacin de mensajes se localiza dentro del intermediario de
mensajes y se convierte en la responsabilidad del grupo de integracin
de mantener. En consecuencia, si se necesitan cambios en los formatos
de mensajes de la red o del sistema heredado, el equipo de desarrollo
responsable slo necesita estar en contacto con el grupo de
integracin, cuyo trabajo consiste en actualizar correctamente las
transformaciones.

Las tecnologas de Message Broker comienzan a sobresalir en esta

etapa, ya que proporcionan herramientas especializadas para:

Representar grficamente las transformaciones complejas de los

mensajes entre los formatos de entrada y de salida. Las
transformaciones pueden ser simples en trminos de mover un
valor de campo de entrada a un campo de salida o pueden
definirse utilizando lenguajes de secuencias de comandos
(tpicamente especficos del producto) que pueden realizar
varios formatos, conversiones de datos y transformaciones
matemticas.
Motores de transformacin de mensajes de varios segmentos de
alto rendimiento que pueden manejar mltiples solicitudes de
transformacin simultnea.
Describir y ejecutar flujos de mensajes, en los que un mensaje
entrante puede ser enrutado a diferentes transformaciones y
salidas dependiendo de los valores en el mensaje entrante.

Es importante destacar que los intermediarios de mensajes operan en un

nivel de mensaje. Reciben un mensaje de entrada, lo transforman de
acuerdo con las reglas de enrutamiento de mensajes y la lgica, y
emiten el mensaje resultante o mensajes a sus destinos. Los corredores
funcionan mejor cuando estas transformaciones son de corta duracin y
se ejecutan rpidamente en, por ejemplo, unos pocos milisegundos. Esto
se debe a que son tpicamente optimizado para el rendimiento y, por
tanto, tratar de evitar gastos generales que ralentizar las
transformaciones. Por lo tanto, si un broker o su mquina host se
bloquea, se basa en el hecho de que la transformacin fallida
simplemente puede ser ejecutada de nuevo desde el principio, lo que
significa que no se necesita administracin costosa del estado y de
las transacciones. Tenga en cuenta, sin embargo, que muchos
intermediarios de mensajes opcionalmente admiten mensajera
transaccional e incluso permiten al intermediario modificar bases de
datos transaccionalmente durante la ejecucin de la transformacin.
Estas transacciones son coordinadas por un gestor de transacciones
ACID, como el proporcionado con la tecnologa MOM subyacente.

Antes de seguir adelante, sin embargo, se debe enfatizar que los

corredores de mensajes, como todo en la arquitectura del software y
las tecnologas, tienen sus desventajas.

En primer lugar, muchas son tecnologas propietarias, y esto conduce a

bloqueo de proveedores. Es el precio que usted paga por todas esas
sofisticadas herramientas de desarrollo y despliegue. Segundo, en
aplicaciones de mensajera de gran volumen, el corredor puede
convertirse en un cuello de botella. La mayora de los productos de
corretaje de mensajes apoyan la agrupacin de intermediarios para
aumentar el rendimiento, la escalabilidad y la fiabilidad, pero esto
se produce a costa de complejidad y de dlares.

Orquestacin de procesos empresariales

Los procesos de negocio en las empresas modernas pueden ser complejos

en cuanto al nmero de las aplicaciones empresariales que se deben
tener acceso y actualizar para completar el negocio.
En los procesos empresariales de larga duracin, como el procesamiento
de pedidos de las transacciones ACID, que bloquean todos los recursos
hasta que se completa la transaccin, no es factible. Esto se debe a
que bloquean los datos en los sistemas por minutos, horas o incluso
semanas para lograr el aislamiento de las transacciones. Los datos
bloqueados no se pueden acceder por transacciones simultneas, y por
lo tanto la contencin de bloqueo causar esperar a estos (o ms
probable fracaso a travs de tiempo de espera) hasta que los bloqueos
se sueltan.
Tal situacin es improbable que produzca negocios de alto rendimiento
y escalables. Por lo tanto, el comportamiento transaccional para los
procesos de larga duracin se suele manejar agrupando una serie de
actividades de proceso en un mbito de transacciones de larga
duracin.
Las transacciones de largo plazo comprenden mltiples actividades de
proceso que no bloquea los elementos de datos que modifican en los
distintos sistemas empresariales. Las actualizaciones son
hechos y comprometidos localmente en cada sistema empresarial. Sin
embargo, si alguna del mbito de transaccin falla, el diseador debe
especificar una funcin de compensacin; el papel del compensador es
deshacer los efectos de la transaccin que ya han comprometido.
Esencialmente esto significa deshacer los cambios que la transaccin
haba hecho, dejando los datos en el mismo estado en que estaba antes
de que se iniciara la transaccin.
Las transacciones de larga duracin son notoriamente difciles de
implementar correctamente. Y a veces son algo imposibles de
implementar con sensatez, cmo compensar un proceso de negocio que ha
enviado un correo electrnico confirmando que una orden ha
ha enviado o ha enviado una factura? As, las soluciones tecnolgicas
para compensar las transacciones no eliminan ninguno de estos
problemas fundamentales. Sin embargo, ellos s proporcionan al
diseador una herramienta para hacer la existencia de una transaccin
de larga duracin explcita y un marco de ejecucin que llama
automticamente al compensador cuando ocurren fallas. Para muchos
problemas, esto es suficiente para construir una solucin.
Problemas de arquitectura de integracin

La dificultad de integrar aplicaciones heterogneas en las grandes

empresas es un problema serio. Si bien hay muchas cuestiones que
abordar en la integracin empresarial, este es un problema
arquitectnico relativo a la modificabilidad.

Otro nombre para una arquitectura punto a punto es una "arquitectura

de espagueti", por razones obvias. Al usar este trmino, muy pocas
personas se estn refiriendo a los espaguetis con las connotaciones
positivas usualmente asociadas con la sabrosa comida italiana. De
hecho, cuando la disciplina de la integracin empresarial floreci a
finales de los aos noventa, el dogma emergente era que las
arquitecturas de los espaguetis se deban evitar a toda costa.
La solucin promovida, por muchas buenas razones, era usar message
brokers.

Es as como los message brokers son muy tiles, pero no una panacea
por cualquier medio para arquitecturas de integracin. Sin embargo,
existe un enfoque de diseo que puede utilizarse que posee la
escalabilidad de una arquitectura punto a punto con la modificabilidad
caractersticas de la solucin basada en broker.
La solucin consiste en definir un modelo de datos empresariales
(tambin conocido como modelo de datos) que se convierte en el formato
de destino para todas las transformaciones de aplicaciones. Por
ejemplo, un problema comn es que todos los sistemas de su empresa
tienen diferentes formatos de datos para definir la informacin del
cliente. Cuando una aplicacin integra
con otro, l (o un intermediario de mensajes) debe transformar su
mensaje de cliente formato de mensaje de destino.

Qu es un Enterprise Service Bus?

Ver el trmino "ESB" utilizado ampliamente en la Arquitectura

Orientada a Servicios. Cuando descubr que representaba
Enterprise Service Bus, me sent muy decepcionado. De todos modos,
aqu est mi interpretacin algo cnica de donde vino el acrnimo
ESB.
En algn lugar a mediados de la ltima dcada, SOA se estaba
convirtiendo la " siguiente gran cosa " en la integracin empresarial.
Los vendedores de software necesitaban algo nuevo para ayudarles a
vender su tecnologa de integracin para soportar una SOA, por lo que
uno de ellos (no estoy seguro de quin fue primero) acu el trmino
ESB. De repente, cada vendedor tena un ESB, que era bsicamente su
corredor de mensajes y orquestacin de procesos de negocios, por
supuesto, la capacidad de integrar servicio web. Si miras debajo de
las cubiertas de un ESB, encontrars todos los elementos tcnicos
y los enfoques de integracin de software descritos antes.
Hay un montn de definiciones por ah para ESBs. Todos ms o menos de
acuerdo en que un ESB proporciona mecanismos fundamentales para
arquitecturas de integracin complejas a travs de
impulsado por eventos y basado en estndares. Hay un debate sobre
ESB es una tecnologa o un patrn de diseo de integracin de
software, pero no vale la pena involucrarse en esos debates. Usted
puede comprar o descargar productos denominados ESB, y stos
proporcionan tpicamente una infraestructura middleware basada en
mensajera que tiene la capacidad de conectarse a puntos extremos
externos del sistema en una variedad de protocolos - TCP / IP, SOAP,
JMS, FTP y muchos ms.