Arquitecturas Orientadas a Servicios y Tecnologías Background Las arquitecturas orientadas al servicio y los servicios Web son el último paso en el desarrollo del middleware de integración de aplicaciones. Tratan de solucionar los problemas de interoperabilidad del pasado y proporcionan una base para futuras aplicaciones aplicaciones distribuidas distribuidas a escala de Internet. También 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 estándares tecnológicos para la integración de aplicaciones y la computación distribuida. La realidad es que las aplicaciones empresariales a gran escala están cada vez más tejidas entre aplicaciones, paquetes y componentes que nunca fueron diseñados para trabajar juntos e incluso pueden funcionar en plataformas incompatibles. Esto da lugar a una necesidad crítica de interoperabilidad, que se hace aún más importante a medida que las organizaciones comienzan a construir una nueva generación 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 mayoría de las tecnologías de integración existentes son cerradas o propietarias y sólo admiten la integración de aplicaciones basadas en la misma tecnología, a menos que las organizaciones estén dispuestas a soportar el costo de comprar o escribir código de adaptador complejo y especial.
La figura muestra una típica aplicación de venta al por menor basada en Internet. Los clientes ven una sola aplicación transparente que les permite realizar pedidos de libros y música y realizar pagos. En realidad, esta aplicación consiste en un pequeño núcleo de lógica 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 aplicación mediante navegadores Web o pueden ejecutar aplicaciones cliente más amigables y inteligentes que realizan llamadas directamente a los servicios de fondo proporcionados por la aplicación principal del minorista. Estos mismos servicios también se pueden utilizar para apoyar los servicios de outsourcing de la entrega de la orden proporcionados a los minoristas especializados, permitiéndoles poseer y funcionar sus propios frentes de tienda en línea y confiar en el minorista para los servicios tales como manejar órdenes y aceptar pagos. Esta aplicación podría ser construida utilizando cualquiera de las tecnologías de middleware discutidas en capítulos anteriores. Sin embargo, el arquitecto de cualquier sistema de este tipo se enfrentará a cuestiones difíciles y complejas que garanticen la interoperabilidad y la robustez. Estas son precisamente las áreas atendidas por arquitecturas orientadas a servicios y tecnologías de servicios web. Los principios básicos subyacentes a las arquitecturas orientadas al servicio se expresan a menudo como cuatro principios: Los límites son explícitos Los servicios son autónomos
Compartir esquemas y contratos, no implementaciones La compatibilidad del servicio se basa en la política Echemos un vistazo a cada uno de ellos.
Los límites son explícitos El primero de los principios reconoce que los servicios son aplicaciones independientes, no sólo el código que está vinculado a su programa que se puede llamar a casi ningún costo. El acceso a un servicio requiere, al menos, cruzar los límites que separan procesos y probablemente atravesando redes y haciendo autenticación de usuario entre dominios. Cada uno de estos límites (proceso, máquina, confianza) que tiene que ser cruzado reduce el rendimiento, aumenta la complejidad y aumenta las fracaso.
Los servicios son autónomos Los servicios son aplicaciones autónomas independientes, no clases o componentes que están estrechamente vinculados a las aplicaciones cliente. Los servicios están destinados a ser desplegados en una red, posiblemente la Internet, donde se pueden integrar fácilmente en cualquier aplicación que les resulte útil. Los servicios no necesitan saber nada acerca de las aplicaciones cliente y pueden aceptar solicitudes de servicio entrante s desde cualquier lugar, siempre y cuando los mensajes de solicitud estén 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 autónomos, también son responsables de su propia seguridad y tienen que protegerse contra posibles llamadas malintencionadas.
Compartir esquemas y contratos, no implementaciones
Todo lo que una aplicación 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 estén correctamente formateados.
La compatibilidad de los servicios se basa en la política Las políticas son colecciones de instrucciones legibles por máquina que permiten a un servicio definir sus requisitos para cosas como seguridad y fiabilidad. Estas políticas 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 políticas independientes y obtenerse dinámicamente en tiempo de ejecución. Las políticas basadas en contrato pueden considerarse sólo una parte de la documentación de un servicio, pero también pueden ser utilizadas por herramientas de desarrollo para generar automáticamente código compatible para clientes y servicios. La separación de las políticas de los contratos también permite que las aplicaciones cliente se adapten dinámicamente para satisfacer los requisitos de un proveedor de servicios particular. Esto será cada vez más útil a medida que los servicios se normalizan y se ofrecen por los proveedores de la competencia. El uso de políticas dinámicas permite a nuestros desarrolladores escribir una sola aplicación que admita ambos métodos de autenticación y selecciona dinámicamente cuál 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 estándares de tecnología de integración diseñados específic amente para satisfacer los requisitos que surgen de las arquitecturas y sistemas orientados al servicio por su simplicidad y interoperabilidad. Todas las tecnologías de integración de aplicaciones, incluidos los servicios Web, sólo proporcionan cuatro funciones básicas 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 estándares WS*)
SOAP, WSDL y UDDI fueron los primeros estándares de servicios web que se publicaron, pero sólo cumplen con los requisitos más básicos para la integración 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 estándares (comúnmente llamados "WS- *"), expuestos por primera vez por IBM y Microsoft en un taller del W3C en 2001. Los servicios web son estándares XML. Los servicios se definen mediante XML y los servicios de solicitud de aplicaciones mediante el envío de mensajes XML y los estándares de servicios Web hacen uso extensivo de otros estándares XML existentes siempre que sea posible. Existen varios estándares de servicios Web y estos pueden ser organizados en las categorías que se muestran en la Figura
Otro objetivo de los estándares 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 envían 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, verificación de seguridad o incluso agregando o restando bits del contenido del mensaje.
SOAP y Mensajería SOAP era el estándar de servicios web original y sigue siendo el más importante y usado. Especifica un simple pero extensible XML basado en protocolo de comunicación aplicación-a-aplicación, aproximadamente equivalente a RPC de DCE o Java RMI, pero mucho menos compleja y mucho más fácil de implementar. Todo el SOAP estándar 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: Información general sobre el mensaje
Cuerpo: Datos del mensaje o documento actual que se está enviando
Los clientes SOAP envían 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 estándares 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 electrónico (SMTP), colas de mensajes, y WSAddressing 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 políticas que se ejecutan a través de los estándares de servicios Web. Los servicios SOAP normalmente se describen utilizando WSDL y puede localizarse mediante la búsqueda en un directorio UDDI. Los servicios pueden describir sus requerimientos de seguridad y fiabilidad utilizando declaraciones de políticas, definidas WS-Policy framework y normas de políticas especializadas como WS-SecurityPolicy. Estas políticas se pueden adjuntar a una definición de servicio WSDL o mantenerse en una política 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 más interesantes de estos estándares, dependiendo de lo importante que creas poder descubrir y vincular a los servicios de tu aplicación. Las organizaciones desarrollan grandes sistemas complejos de servicios Web sin el uso de directorios UDDI, utilizando otros métodos de búsqueda de servicios como el contacto personal o listas publicadas de servicios en sitios Web. Todo esto podría cambiar en el futuro, especialmente cuando las asociaciones de la industria comienzan a publicar definiciones de servicio común y la necesidad de publicar directorios de proveedores de servicios calificados. WSDL se utiliza para describir servicios Web, incluyendo sus interfaces, métodos y parámetros.
Seguridad, Transacciones y Fiabilidad Uno de los problemas que enfrentan la mayoría 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 tecnológica común 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 través de la mayoría de firewalls. Este uso de HTTP es convencional pero también crea posibles problemas de seguridad. WS-Security y sus direcciones standards asociadas a estos problemas de los sistemas de criptográficos para identificar los callers, (autentificación), y garantizar la integridad (firma digital) Estos estándares están diseñados para ser extensibles, los que se adaptan para nuevas tecnologías de seguridad y algoritmos, y también integración con tecnología de seguridad legal. Existen dos tipos de servicios web de negocios compatibles con estándares. WS-AtomicTransactions admite compatibilidad convencional distribuida ACID y los niveles de confianza y las respuestas de tiempo rápido que hacen este estándar sólo para aplicaciones internas de integración de aplicaciones. WS-BusinessActivity es un framework y un conjunto de protocolos elementales para coordinar la terminación 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 tecnologías estándar HTTP y Web significa que los servicios Web RESTful pueden aprovechar toda la infraestructura Web, como el almacenamiento en caché y la indexación.
Tecnologías Avanzadas de Middleware Message Broker La mensajería básica que utiliza MOM y las tecnologías de suscripción de publicación es suficiente para muchas aplicaciones. Cuando los formatos de mensajes no están totalmente de acuerdo entre las distintas aplicaciones que se comunican utilizando la MOM surge un problema, que ocurre comúnmente en el dominio de la integración empresarial, donde el problema básico es la creación de aplicaciones empresariales a partir de grandes y complejos sistemas empresariales heredados que nunca fueron diseñados para trabajar juntos e intercambiar información. La integración empresarial es todo un campo de estudio en sí mismo. Aquí es donde los corredores de mensajes ofrecen una solución alternativa potencialmente atractiva. Arquitectónicamente, un corredor es un patrón 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 lógica de negocios relacionados con la integración se puede ejecutar dentro del corredor. Una solución de intermediario de mensajes es atractiva porque desacopla completamente el componente interfaz heredados. El componente web mensaje y el intermediario transforma necesario para cada sistema heredado.
web y los componentes de simplemente ensambla y emite un el mensaje en el formato A continuación, envía un mensaje
de salida a los componentes de la interfaz del sistema heredado en el formato preciso que deseen. Otra atracción es la simplificación de todos los componentes del sistema, ya que ahora no tienen que preocuparse por la transformación del formato del mensaje. La lógica de transformación de mensajes se localiza dentro del intermediario de mensajes y se convierte en la responsabilidad del grupo de integración 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 sólo necesita estar en contacto con el grupo de integración, cuyo trabajo consiste en actualizar correctamente las transformaciones. Las tecnologías de Message Broker comienzan a sobresalir en esta etapa, ya que proporcionan herramientas especializadas para:
Representar gráficamente las transformaciones complejas de los mensajes entre los formatos de entrada y de salida. Las transformaciones pueden ser simples en términos de mover un valor de campo de entrada a un campo de salida o pueden definirse utilizando lenguajes de secuencias de comandos (típicamente específicos del producto) que pueden realizar varios formatos, conversiones de datos y transformaciones matemáticas.
Motores de transformación de mensajes de varios segmentos de alto rendimiento que pueden manejar múltiples solicitudes de transformación simultánea.
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 lógica, y emiten el mensaje resultante o mensajes a sus destinos. Los corredores funcionan mejor cuando estas transformaciones son de corta duración y se ejecutan rápidamente en, por ejemplo, unos pocos milisegundos. Esto se debe a que son típicamente optimizado para el rendimiento y, por tanto, tratar de evitar gastos generales que ralentizar las transformaciones. Por lo tanto, si un broker o su máquina host se bloquea, se basa en el hecho de que la transformación fallida simplemente puede ser ejecutada de nuevo desde el principio, lo que significa que no se necesita administración costosa del estado y de las transacciones. Tenga en cuenta, sin embargo, que muchos intermediarios de mensajes opcionalmente admiten mensajería
transaccional e incluso permiten al intermediario modificar bases de datos transaccionalmente durante la ejecución de la transformación. Estas transacciones son coordinadas por un gestor de transacciones ACID, como el proporcionado con la tecnología 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 tecnologías, tienen sus desventajas. En primer lugar, muchas son tecnologías 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 mensajería de gran volumen, el corredor puede convertirse en un cuello de botella. La mayoría de los productos de corretaje de mensajes apoyan la agrupación de intermediarios para aumentar el rendimiento, la escalabilidad y la fiabilidad, pero esto se produce a costa de complejidad y de dólares.
Orquestación de procesos empresariales Los procesos de negocio en las empresas modernas pueden ser complejos en cuanto al número de las aplicaciones empresariales que se deben tener acceso y actualizar para completar el negocio. En los procesos empresariales de larga duración, como el procesamiento de pedidos de las transacciones ACID, que bloquean todos los recursos hasta que se completa la transacción, 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 simultáneas, y por lo tanto la contención de bloqueo causará esperar a estos (o más probable fracaso a través de tiempo de espera) hasta que los bloqueos se sueltan. Tal situación es improbable que produzca negocios de alto rendimiento y escalables. Por lo tanto, el comportamiento transaccional para los procesos de larga duración se suele manejar agrupando una serie de actividades de proceso en un ámbito de transacciones de larga duración. Las transacciones de largo plazo comprenden múltiples 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 transacción falla, el diseñador debe especificar una función de compensación; el papel del compensador es deshacer los efectos de la transacción que ya han comprometido. Esencialmente esto significa deshacer los cambios que la transacción había hecho, dejando los datos en el mismo estado en que estaba antes de que se iniciara la transacción. Las transacciones de larga duración son notoriamente difíciles de implementar correctamente. Y a veces son algo imposibles de implementar con sensatez, ¿cómo compensar un proceso de negocio que ha enviado un correo electrónico confirmando que una orden ha ha enviado o ha enviado una factura? Así, las soluciones tecnológicas para compensar las transacciones no eliminan ninguno de estos problemas fundamentales. Sin embargo, ellos sí proporcionan al diseñador una herramienta para hacer la existencia de una transacción de larga duración explícita y un marco de ejecución que llama automáticamente al compensador cuando ocurren fallas. Para muchos problemas, esto es suficiente para construir una solución.
Problemas de arquitectura de integración
La dificultad de integrar aplicaciones heterogéneas en las grandes empresas es un problema serio. Si bien hay muchas cuestiones que abordar en la integración empresarial, este es un problema arquitectónico relativo a la modificabilidad. Otro nombre para una arquitectura punto a punto es una "arquitectura de espagueti", por razones obvias. Al usar este término, muy pocas personas se están refiriendo a los espaguetis con las connotaciones positivas usualmente asociadas con la sabrosa comida italiana. De hecho, cuando la disciplina de la integración empresarial floreció a finales de los años noventa, el dogma emergente era que las arquitecturas de los espaguetis se debían evitar a toda costa. La solución 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 integración. Sin embargo, existe un enfoque de diseño que puede utilizarse que posee la escalabilidad de una arquitectura punto a punto con la modificabilidad características de la solución basada en broker. La solución consiste en definir un modelo de datos empresariales (también conocido como modelo de datos) que se convierte en el formato de destino para todas las transformaciones de aplicaciones. Por ejemplo, un problema común es que todos los sistemas de su empresa tienen diferentes formatos de datos para definir la información del cliente. Cuando una aplicación 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 término "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 interpretación algo cínica de donde vino el acrónimo ESB. En algún lugar a mediados de la última década, SOA se estaba convirtiendo la " siguiente gran cosa " en la integración empresarial. Los vendedores de software necesitaban algo nuevo para ayudarles a vender su tecnología de integración para soportar una SOA, por lo que uno de ellos (no estoy seguro de quién fue primero) acuñó el término ESB. De repente, cada vendedor tenía un ESB, que era básicamente su corredor de mensajes y orquestación de procesos de negocios, por supuesto, la capacidad de integrar servicio web. Si miras debajo de las cubiertas de un ESB, encontrarás todos los elementos técnicos y los enfoques de integración de software descritos antes. Hay un montón de definiciones por ahí para ESBs. Todos más o menos de acuerdo en que un ESB proporciona mecanismos fundamentales para arquitecturas de integración complejas a través de impulsado por eventos y basado en estándares. Hay un debate sobre ESB es una tecnología o un patrón de diseño de integración de software, pero no vale la pena involucrarse en esos debates. Usted puede comprar o descargar productos denominados ESB, y éstos
proporcionan típicamente una infraestructura middleware basada en mensajería que tiene la capacidad de conectarse a puntos extremos externos del sistema en una variedad de protocolos - TCP / IP, SOAP, JMS, FTP y muchos más.
