Embed Size (px)
DESCRIPTION
SOA Conceptos
Citation preview
SOAPRINCIPIOS DE DISEÑO DE
SERVICIOS - IIAbimael Desales López
El framework de web services
Un framework de tecnología es una colección de cosas. Puede incluir una o más arquitecturas, tecnologías, conceptos, modelos, y aún sub-frameworks. El framework establecido por los web services está compuesto por todas estas partes.Específicamente este framework está caracterizado por: Una existencia abstracta (neutral a proveedores) definida por organizaciones
estandarizadas e implementada por plataformas de tecnologías (propietarias) Bloques de construcción core que incluyen web services, descripciones de
servicios, y mensajes Una compatibilidad de comunicaciones centrada alrededor de descripciones de
servicios basadas en WSDL Un framework de mensajería compuesto de tecnología SOAP y conceptos Una arquitectura de descubrimiento y registro de descripciones de servicios a
veces realizada a través de UDDI Una arquitectura bien definida que soporta patrones y composiciones de
mensajería Una segunda generación de extensiones de web services (especificaciones ws-
*)
El framework de web services
Otra adición recomendada a la lista anterior es WS-I Basic Profile. Proporciona estándares y mejores prácticas que gobiernan el uso de características WSDL, SOAP, y UDDI. Por lo tanto, mucho de lo que está compuesto el framework de web services puede estar estandarizado por el Basic Profile.
En su totalidad, este framework de tecnología está conceptualmente en alineación con los principios de orientación a servicios. Manifestar soluciones de automatización de servicios en el mundo real requiere el uso de una tecnología capaz de preservar la orientación a servicios fundamental, mientras implementa funcionalidad de negocio del mundo real.Los web services proporcionan el potencial de cumplir con estas requerimientos primitivos, pero necesitan estar intencionalmente diseñados para hacerlo. Esto es debido a que el framework de web services es flexible y adaptable. Los web services pueden estar diseñados para duplicar el comportamiento y funcionalidad encontrada en sistemas distribuidos propietarios, o pueden ser diseñados para ser totalmente compatibles con SOA.
El framework de web services
Fundamentalmente, cada web service puede estar asociado con: Una clasificación temporal basada en los roles que asume
durante el procesamiento de un mensaje. Una clasificación permanente basada en la lógica de aplicación
que proporciona y los roles que asume en el entorno de una solución
Exploraremos ambas de estas clasificaciones más adelante: Roles de servicios (clasificaciones temporales) Modelos de servicios (clasificaciones permanentes)
El framework de web services
ROLES DE SERVICIOS Un web service es capaz de asumir diferentes roles, dependiendo del contexto en el cual es usado. Por ejemplo, un servicio puede actuar como el iniciador, relayer, o el recipiente de un mensaje. Por lo tanto, un servicio no es etiquetado exclusivamente como un cliente o servidor, sino en lugar de ello como una unidad de software capaz de alternar su rol, dependiendo de su responsabilidad de procesamiento en un escenario dado.No es común para un web service cambiar su rol más de una vez en una tarea de negocio dada. En especial no es común para un web service en una SOA asumir diferentes roles en tareas de negocio diferentes.Proveedor de ServicioEl rol proveedor de servicio es asumido por un web service bajo las siguientes condiciones: El web service es invocado vía una fuente externa, como un
solicitador de servicio
El framework de web services
Figura 5.2. Como el receptor de la solicitud de un mensaje, el web service es clasificado como un proveedor de servicio.
El web service proporciona una descripción del servicio publicada ofreciendo información sobre sus características y comportamiento. Entidad proveedora de servicio (la organización o individuo que provee el web service)Agente proveedor de servicio (el mismo web service, actuando como un agente en nombre de su dueño)
El framework de web services
Solicitante de servicioCualquier unidad de lógica de procesamiento capaz de emitir una solicitud de mensaje que puede ser comprendida por el proveedor de servicio es clasificada como solicitante de servicio. Un web service es siempre un proveedor de servicio pero también puede actuar como un solicitante de servicio.Un web service toma en el rol de solicitante de servicio bajo las siguientes circunstancias: El web service invoca un proveedor de servicios enviándole un
mensaje.
El framework de web services
Figura 5.3El emisor de la solicitud de mensaje es clasificado como un solicitante de servicio.
El web service busca y evalúa el proveedor de servicio más adecuado estudiando las descripciones de servicio disponibles.
Nota:Otro término frecuentemente usado en vez de solicitante de servicio es consumidor de servicio.
El framework de web services
IntermediariosEl framework de comunicaciones establecido por los web services contrasta con la naturaleza predecible de los canales de comunicaciones punto a punto. Aunque menos flexible y menos escalable, la comunicación punto a punto fue muy fácil de diseñar. La comunicación de web services está basada en el uso de rutas de mensajería, las cuales pueden ser mejor descritas como punto a -*rutas. Esto es debido a que una vez un proveedor de servicio emite un mensaje, puede ser procesado por múltiples enrutamientos intermedios y agentes de procesamiento antes de que llegue a su último destino.Los web services y agentes de servicio que enrutan y procesan un mensaje después de que es inicialmente enviado y antes de que llegue a su último destino son referenciados como intermediarios o servicios intermediarios, siempre transitan a través de los roles proveedor de servicio y el solicitante de servicio.
El framework de web services
Figura 5.5Las transiciones del servicio intermediario a través de los roles proveedor de servicio y solicitante de servicio mientras procesa un mensaje.
El framework de web services
Hay dos tipos de intermediarios. El primero conocido como un intermediario pasivo, es típicamente responsable para enrutar mensajes a un ubicación siguiente (Fig. 5.6). Puede usar información en el encabezado del mensaje SOAP para determinar la ruta del enrutamiento, o puede emplear lógica nativa de enrutamiento para llevar a cabo algún nivel de balanceo de carga. De cualquier forma, lo que hace este tipo de intermediario pasivo es que no modifica el mensaje.
Figura 5.6Un servicio intermediariopasivo procesando un mensaje sin alterar sucontenido
El framework de web services
Al igual que los servicios intermediarios pasivos, los intermediarios activos también enrutan mensajes a un destino de reenvío. Sin embargo, antes de transmitir un mensaje, estos servicios procesan activamente y alteran el contenido del mensaje (Figura 5.7). Típicamente, los intermediarios activos bloquearán bloques de encabezado SOAP y ejecutarán alguna acción en respuesta a la información que encuentran ahí. Casi siempre alteran los datos en los bloques de encabezado y pueden insertar o aún eliminar bloques de encabezado completamente.
Figura 5.7Un servicio intermediarioactivo
El framework de web services
Emisor inicial y receptor finalLos emisores iniciales son simplemente solicitantes de servicios que inician la transmisión de un mensaje. Por lo tanto, el emisor inicial es siempre el primer web service en la ruta de un mensaje. La contraparte a este rol es receptor final. Esta etiqueta identifica a los proveedores de servicio que existen como el último web service contra la ruta de un mensaje.
Figura 5.8Web services actuando como emisoinicial y receptor final.
Nota que los servicios intermediariosnunca pueden ser emisores iniciales oreceptores finales en el alcance de unaactividad de servicio.
El framework de web services
Composiciones de ServiciosComo el nombre lo sugiere, este término particular no aplica a un solo servicio, sino a una relación compuesta entre una colección de servicios. Cualquier servicio puede enlistar uno o más servicios adicionales para completar una tarea dada. Además, cualquiera de los servicios enlistados pueden llamar a otros servicios para completar una tarea dada. Por lo tanto, cada servicio que participa en una composición asume un rol individual de miembro de la composición de servicio (Fig. 5.10).
Figura 5.10Una composición de serviciosconsistente de cuatro miembros.
El framework de web services
Típicamente los web services necesitan estar diseñados con la composición de servicios en mente para ser miembros de composición efectivos. Los principios de orientación a servicios ponen un énfasis en la componibilidad, permitiendo que algunos web services sean diseñados en tal forma que puedan ser jalados en composiciones de servicios futuras sin un conocimiento previo de cómo serán utilizados.El concepto de componibilidad de servicios es muy importante a los entornos orientados a servicios. De hecho, la composición de servicios es frecuentemente gobernada por extensiones de composición WS-*, como son WS-BPEL y WS-CDL, los cuales introducen los conceptos relacionados de orquestación y coreografía, respectivamente.
El framework de web services
MODELOS DE SERVICIOSLos roles que hemos explorado hasta aquí son independientes a la naturaleza de la funcionalidad que está siendo proporcionada por el web service. Son estados genéricos que un servicio puede ingresar en un contexto genérico. La manera en la cual los servicios son utilizados en el mundo real, aunque, ha llevado a clasificación basada en la naturaleza de la lógica de aplicación que proporcionan, así como en sus roles relacionados al negocio en la solución general. Estas clasificaciones son conocidas como modelos de servicios.Las secciones que siguen describen el conjunto básico de modelos de servicios comunes.
El framework de web services
Modelo de Servicios de NegocioEn una SOA, el servicio de negocio representa el bloque de construcción más fundamental. Encapsula un conjunto distinto de lógica de negocio en una frontera funcional bien definida. Es completamente autónoma pero aún no está limitada a ejecutarse en aislamiento, ya que los servicios de negocio frecuentemente esperan participar en composiciones de servicios.Los servicios de negocio son usados en SOA de la forma siguiente: Como bloques de construcción fundamental para la representación de
lógica de negocio Para representar una entidad corporativa o conjunto de información Para representar lógica de procesamiento de negocio Como miembros de la composición de servicios
Para más referencia, cuando se construye una SOA alrededor de capas de abstracción, el modelo de servicios de negocio puede corresponder a la capa de servicios de negocio.
El framework de web services
Modelo de servicios utilitariosCualquier web service genérico o agente de servicio diseñado para potencial reutilización puede ser clasificado como servicio utilitario. La clave para llevar a cabo esta clasificación es que la funcionalidad reutilizable es completamente genérica y no específica a la aplicación en naturaleza.Los servicios utilitarios son usados en SOAs de la siguiente forma: Como servicios que permiten las características de reutilización en SOA Como servicios intermediarios independientes a la solución Como servicios que promueven la característica de interoperabilidad
intrínseca de SOA Como servicios con el más alto grado de autonomía
Cuando se trabajan con las capas de abstracción de servicios, un servicio utilitario es más comúnmente asociado con la capa de servicio de aplicación. Como resultado, un servicio utilitario puede ser referenciado como un servicio de aplicación de utilidad.
El framework de web services
Modelo de servicio ControladorLas composiciones de servicios están compuestas de un conjunto de servicios independientes que contribuyen cada uno a la ejecución de la tarea de negocio general. El ensamble y coordinación de estos servicios es frecuentemente en sí misma una tarea y puede ser asignada como la función primaria de un servicio dedicado de un servicio dedicado que es completamente capaz de ejecutar una tarea de negocio de forma independiente. El servicio controlador cumple este rol, actuando como el servicio padre a los miembros de la composición de servicios.
Los servicios controladores son usados en SOAs de la forma siguiente: Para soportar e implementar el principio de componibilidad Para aprovechar la reutilización de oportunidades Para soportar la autonomía en otros serviciosNota que los servicios controladores por sí mismos pueden llegar a ser miembros de composición de servicios subordinados. En este caso, la composición coordinada por un controlador está, en su completitud, compuesta en composiciones más grandes. En este caso, podría haber un servicio controlador maestro que actúa como el padre a la composición del servicio completa, así como un subcontrolador, responsable para coordinar una porción de la composición (Fig. 5.12).
El framework de web services
Figura 5.12Una composición de servicio consistente de un controlador maestro, un sub-controlador, cuatro servicios de negocio, y un servicio utilitario.
El modelo de servicios controlador es usado frecuentemente cuando se construye una SOA especializada con capas de abstracción de servicio especializadas.
¡¡GRACIAS!!
No se olvide visitarnos en nuestra página y regalarnos un like:
https://www.facebook.com/JavaDevelopersMexico
