• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SOA: Principios de Diseño de Servicios - Parte II
 

SOA: Principios de Diseño de Servicios - Parte II

on

  • 1,169 views

SOA Conceptos

SOA Conceptos

Statistics

Views

Total Views
1,169
Views on SlideShare
1,169
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    SOA: Principios de Diseño de Servicios - Parte II SOA: Principios de Diseño de Servicios - Parte II Presentation Transcript

    • Abimael Desales López04/2013it.adesales@gmail.com
    • Un framework de tecnología es una colección de cosas. Puede incluir una o másarquitecturas, tecnologías, conceptos, modelos, y aún sub-frameworks. Elframework establecido por los web services está compuesto por todas estaspartes.Específicamente este framework está caracterizado por: Una existencia abstracta (neutral a proveedores) definida por organizacionesestandarizadas e implementada por plataformas de tecnologías (propietarias) Bloques de construcción core que incluyen web services, descripciones deservicios, y mensajes Una compatibilidad de comunicaciones centrada alrededor de descripciones deservicios 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 aveces realizada a través de UDDI Una arquitectura bien definida que soporta patrones y composiciones demensajería Una segunda generación de extensiones de web services (especificaciones ws-*)
    • Otra adición recomendada a la lista anterior es WS-I Basic Profile. Proporcionaestá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 deweb services puede estar estandarizado por el Basic Profile.En su totalidad, este framework de tecnología está conceptualmente enalineación con los principios de orientación a servicios.Manifestar soluciones de automatización de servicios en el mundo real requiereel uso de una tecnología capaz de preservar la orientación a serviciosfundamental, mientras implementa funcionalidad de negocio del mundo real.Los web services proporcionan el potencial de cumplir con estas requerimientosprimitivos, pero necesitan estar intencionalmente diseñados para hacerlo. Estoes debido a que el framework de web services es flexible y adaptable. Los webservices pueden estar diseñados para duplicar el comportamiento yfuncionalidad encontrada en sistemas distribuidos propietarios, o pueden serdiseñados para ser totalmente compatibles con SOA.
    • Fundamentalmente, cada web service puede estar asociado con: Una clasificación temporal basada en los roles que asume durante elprocesamiento de un mensaje. Una clasificación permanente basada en la lógica de aplicación queproporciona y los roles que asume en el entorno de una soluciónExploraremos ambas de estas clasificaciones más adelante: Roles de servicios (clasificaciones temporales) Modelos de servicios (clasificaciones permanentes)
    • ROLES DE SERVICIOSUn web service es capaz de asumir diferentes roles, dependiendo delcontexto en el cual es usado. Por ejemplo, un servicio puede actuar como eliniciador, relayer, o el recipiente de un mensaje. Por lo tanto, un servicio noes etiquetado exclusivamente como un cliente o servidor, sino en lugar deello como una unidad de software capaz de alternar su rol, dependiendo desu responsabilidad de procesamiento en un escenario dado.No es común para un web service cambiar su rol más de una vez en unatarea de negocio dada. En especial no es común para un web service en unaSOA asumir diferentes roles en tareas de negocio diferentes.Proveedor de ServicioEl rol proveedor de servicio es asumido por un web service bajo lassiguientes condiciones: El web service es invocado vía una fuente externa, como un solicitador deservicio
    • Figura 5.2.Como el receptor de la solicitud de unmensaje, el web service es clasificado comoun proveedor de servicio.El web service proporciona una descripcióndel servicio publicada ofreciendoinformación sobre sus características ycomportamiento.Entidad proveedora de servicio (laorganización o individuo que provee el webservice)Agente proveedor de servicio (el mismoweb service, actuando como un agente ennombre de su dueño)
    • Solicitante de servicioCualquier unidad de lógica de procesamiento capaz de emitir una solicitudde mensaje que puede ser comprendida por el proveedor de servicio esclasificada como solicitante de servicio. Un web service es siempre unproveedor de servicio pero también puede actuar como un solicitante deservicio.Un web service toma en el rol de solicitante de servicio bajo las siguientescircunstancias: El web service invoca un proveedor de servicios enviándole un mensaje.
    • Figura 5.3El emisor de la solicitud de mensaje es clasificado como un solicitante deservicio.El web service busca y evalúa elproveedor de servicio másadecuado estudiando lasdescripciones de serviciodisponibles.Nota:Otro término frecuentementeusado en vez de solicitante deservicio es consumidor de servicio.
    • IntermediariosEl framework de comunicaciones establecido por los web services contrastacon la naturaleza predecible de los canales de comunicaciones punto apunto. Aunque menos flexible y menos escalable, la comunicación punto apunto 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 mejordescritas como punto a -*rutas. Esto es debido a que una vez un proveedorde servicio emite un mensaje, puede ser procesado por múltiplesenrutamientos intermedios y agentes de procesamiento antes de que lleguea su último destino.Los web services y agentes de servicio que enrutan y procesan un mensajedespués de que es inicialmente enviado y antes de que llegue a su últimodestino son referenciados como intermediarios o servicios intermediarios,siempre transitan a través de los roles proveedor de servicio y el solicitantede servicio.
    • Figura 5.5Las transiciones del servicio intermediario a través de los roles proveedor deservicio y solicitante de servicio mientras procesa un mensaje.
    • 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 laruta del enrutamiento, o puede emplear lógica nativa de enrutamiento para llevar acabo algún nivel de balanceo de carga. De cualquier forma, lo que hace este tipo deintermediario pasivo es que no modifica el mensaje.Figura 5.6Un servicio intermediariopasivo procesando unmensaje sin alterar sucontenido
    • Al igual que los servicios intermediarios pasivos, los intermediarios activos tambiénenrutan mensajes a un destino de reenvío. Sin embargo, antes de transmitir unmensaje, estos servicios procesan activamente y alteran el contenido del mensaje(Figura 5.7). Típicamente, los intermediarios activos bloquearán bloques deencabezado SOAP y ejecutarán alguna acción en respuesta a la información queencuentran ahí. Casi siempre alteran los datos en los bloques de encabezado ypueden insertar o aún eliminar bloques de encabezado completamente.Figura 5.7Un servicio intermediarioactivo
    • Emisor inicial y receptor finalLos emisores iniciales son simplemente solicitantes de servicios que inician latransmisión de un mensaje. Por lo tanto, el emisor inicial es siempre el primer webservice en la ruta de un mensaje. La contraparte a este rol es receptor final. Estaetiqueta identifica a los proveedores de servicio que existen como el último webservice 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.
    • Composiciones de ServiciosComo el nombre lo sugiere, este término particular no aplica a un solo servicio, sinoa una relación compuesta entre una colección de servicios. Cualquier servicio puedeenlistar uno o más servicios adicionales para completar una tarea dada. Además,cualquiera de los servicios enlistados pueden llamar a otros servicios paracompletar una tarea dada. Por lo tanto, cada servicio que participa en unacomposició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.
    • Típicamente los web services necesitan estar diseñados con la composiciónde servicios en mente para ser miembros de composición efectivos. Losprincipios de orientación a servicios ponen un énfasis en la componibilidad,permitiendo que algunos web services sean diseñados en tal forma quepuedan ser jalados en composiciones de servicios futuras sin unconocimiento previo de cómo serán utilizados.El concepto de componibilidad de servicios es muy importante a losentornos orientados a servicios. De hecho, la composición de servicios esfrecuentemente gobernada por extensiones de composición WS-*, como sonWS-BPEL y WS-CDL, los cuales introducen los conceptos relacionados deorquestación y coreografía, respectivamente.
    • MODELOS DE SERVICIOSLos roles que hemos explorado hasta aquí son independientes a lanaturaleza de la funcionalidad que está siendo proporcionada por el webservice. Son estados genéricos que un servicio puede ingresar en uncontexto genérico. La manera en la cual los servicios son utilizados en elmundo real, aunque, ha llevado a clasificación basada en la naturaleza de lalógica de aplicación que proporcionan, así como en sus roles relacionados alnegocio en la solución general. Estas clasificaciones son conocidas comomodelos de servicios.Las secciones que siguen describen el conjunto básico de modelos deservicios comunes.
    • Modelo de Servicios de NegocioEn una SOA, el servicio de negocio representa el bloque de construcción másfundamental. Encapsula un conjunto distinto de lógica de negocio en unafrontera funcional bien definida. Es completamente autónoma pero aún noestá limitada a ejecutarse en aislamiento, ya que los servicios de negociofrecuentemente 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 denegocio 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 serviciosPara más referencia, cuando se construye una SOA alrededor de capas deabstracción, el modelo de servicios de negocio puede corresponder a lacapa de servicios de negocio.
    • Modelo de servicios utilitariosCualquier web service genérico o agente de servicio diseñado parapotencial reutilización puede ser clasificado como servicio utilitario. La clavepara llevar a cabo esta clasificación es que la funcionalidad reutilizable escompletamente 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 deSOA Como servicios con el más alto grado de autonomíaCuando se trabajan con las capas de abstracción de servicios, un servicioutilitario es más comúnmente asociado con la capa de servicio deaplicación. Como resultado, un servicio utilitario puede ser referenciadocomo un servicio de aplicación de utilidad.
    • Modelo de servicio ControladorLas composiciones de servicios están compuestas de un conjunto de serviciosindependientes que contribuyen cada uno a la ejecución de la tarea de negociogeneral. 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 serviciodedicado de un servicio dedicado que es completamente capaz de ejecutar una tareade negocio de forma independiente. El servicio controlador cumple este rol, actuandocomo 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 decomposición de servicios subordinados. En este caso, la composición coordinadapor un controlador está, en su completitud, compuesta en composiciones másgrandes. En este caso, podría haber un servicio controlador maestro que actúa comoel 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).
    • Figura 5.12Una composición de servicioconsistente de un controladormaestro, un sub-controlador,cuatro servicios de negocio, y unservicio utilitario.El modelo de servicioscontrolador es usadofrecuentemente cuando seconstruye una SOAespecializada con capas deabstracción de servicioespecializadas.
    • No se olvide visitarnos en nuestra página yregalarnos un like:https://www.facebook.com/JavaDevelopersMexico