Tema 3 3

783 views
655 views

Published on

Published in: Education, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
783
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Tema 3 3

  1. 1. Servicios Web Programación de Red. Ingeniería en Informática
  2. 2. Servicios WebObjetivos: Conocer el concepto de Servicios Web y toda la tecnología asociada Conocer los protocolos más importantes asociados a Servicios Web Estudiar SOAP, WSDL y UDDI (WSIL) Dar un visión general sobre orquestación de Servicios Web Conocer algunos aspectos de seguridad en Servicios Web 2
  3. 3. Servicios Web Concepto de Servicio Web. SOAP. WSDL. UDDI (WSIL). Orquestación de Servicios Web. Seguridad 3
  4. 4. Orquestación de Servicios Web Tipos de Integración. Sistemas de Gestión de Flujos. Introducción a Sistemas EAI. Arquitectura de Sistemas EAI. Orquestación de Servicios Web. 4
  5. 5. Tipos de Integración Tipos de Integración  Integración de Plataforma  Comunicación de aplicaciones en diferentes máquinas  Independencia de localización, hardware, SO y lenguaje de programación  Los Servicios Web constituyen una buena solución para este problema  Integración de Datos  Independencia de arquitectura de almacenamiento  Independencia de heterogeneidades de formato  Independencia de heterogeneidades de esquema  Independencia de combinación de datos  Sistemas EII ⇒ Enterprise Information Integration 5
  6. 6. Tipos de Integración Tipos de Integración  Integración de Aplicaciones/Procesos (en intranets)  Creación rápida de aplicaciones basadas en otras aplicaciones existentes  Procesos de negocio modelados como flujos ⇒ Sistemas de gestión de flujos  Integración B2B (Business to Business) ⇒ Integración de aplicaciones en Internet  Independencia de en qué organización (empresa) se encuentran las aplicaciones que se comunican  Pregunta: ¿Qué debemos considerar cuando las aplicaciones que se comunican pertenecen a organizaciones diferentes? ⇒ seguridad (↑), acoplamiento (↓), estándares propios o sectoriales, etc. 6
  7. 7. Tipos de Integración Integración de Aplicaciones ⇒ Sistemas EAI  Sistemas EAI ⇒ Enterprise Application Integration  Lógica de control inter-aplicación  Soporte para envío/recepción de mensajes síncronos y asíncronos  Transacciones multi-aplicación  Soporte para la creación sencilla de wrappers (adaptadores) para las aplicaciones existentes  Las soluciones deben basarse en estándares ⇒ Los Servicios Web juegan un papel crucial mediante los estándares emergentes para la orquestación (WS-BPEL) y la coreografía (WSCI) de Servicios Web  En intranets son una realidad y deben de evolucionar para dar mayor soporte a comunicaciones B2B (Internet) 7
  8. 8. Orquestación de Servicios Web Tipos de Integración. Sistemas de Gestión de Flujos. Introducción a Sistemas EAI. Arquitectura de Sistemas EAI. Orquestación de Servicios Web. 8
  9. 9. Sistemas de Gestión de Flujos Procesos de Negocio  Los procesos básicos de una organización involucran la interacción entre múltiples aplicaciones preexistentes  Estos procesos pueden modelarse como flujos (workflows) que especifican cómo deben colaborar entre sí las distintas entidades (aplicaciones/personas) para llevar a cabo el proceso  Un flujo (workflow) debe especificar aspectos tales como:  La secuencia de acciones a realizar por cada entidad  Los datos intercambiados entre las entidades y la manera en que deben ser transformados  Reglas para la toma de decisiones  Restricciones a satisfacer 9
  10. 10. Sistemas de Gestión de Flujos Sistemas de Gestión de Flujos  Casi todos los procesos de negocio pueden modelarse como flujos ⇒ Escribiendo un wrapper (envoltorio o adaptador) para cada aplicación  Se define una interfaz remota estándar (por ejemplo un Web Service) para el wrapper (adaptador), que permita acceder a las funcionalidades soportadas por aplicación  El wrapper (adaptador) debe ser genérico y válido para soportar las necesidades de todos los procesos que pretendan interactuar con la aplicación  La información de entrada y salida a cada aplicación se deberá modelar de acuerdo a algún formato de intercambio estándar (por ejemplo XML) 10
  11. 11. Sistemas de Gestión de Flujos Sistemas de Gestión de Flujos  Ventajas  Crear un nuevo proceso de negocio “no” implica programar  El soporte para el intercambio de mensajes, las transacciones y otros mecanismos genéricos de diseño es proporcionado para todos los procesos de negocio por la plataforma de gestión de flujos  La respuesta a cambios es más rápida  Todos los procesos de negocio son gestionados de la misma forma y desde un único punto ⇒ Facilita la administración, autenticación, seguridad, etc.  Algunas herramientas ya traen implementados adaptadores (wrappers) típicos, al igual que flujos típicos (incidencias, pedidos, etc.) 11
  12. 12. Orquestación de Servicios Web Tipos de Integración. Sistemas de Gestión de Flujos. Introducción a Sistemas EAI. Arquitectura de Sistemas EAI. Orquestación de Servicios Web. 12
  13. 13. Introducción a Sistemas EAI Sistemas EAI (Enterprise Application Integration)  Lógica de control inter-aplicación  Soporte para envío/recepción de mensajes síncronos y asíncronos  Transacciones multi-aplicación  Soporte para la creación sencilla de wrappers (adaptadores) para las aplicaciones existentes  Las soluciones deben basarse en estándares ⇒ Los Servicios Web juegan un papel crucial mediante los estándares emergentes para la orquestación (WS-BPEL) y la coreografía (WSCI) de Servicios Web  En intranets son una realidad y deben de evolucionar para dar mayor soporte a comunicaciones B2B (Internet) 13
  14. 14. Introducción a Sistemas EAI Sistemas EAI ⇒ Evolución  1ª Generación: WMS (Workflow Management Systems)  Orientado a que las entidades involucradas en los procesos de negocio sean personas ⇒ Las acciones a realizar dentro de un flujo consisten fundamentalmente en el rellenado o la interpretación de formularios por parte de los usuarios (personas)  Dificultades de integración con aplicaciones existentes  Falta de funcionalidad ⇒ Sin soporte para transacciones y poca escalabilidad  Visión de muy alto nivel ⇒ No se ocupa de peculiaridades técnicas de las aplicaciones involucradas y en la práctica, involucra gran cantidad de “trabajo manual” de integración por parte de las personas 14
  15. 15. Introducción a Sistemas EAI Sistemas EAI ⇒ Evolución  2ª Generación: Sistemas EAI (Enterprise Application Integration)  Centrados en coordinar aplicaciones, en lugar de personas  Wrappers (conectores o adaptadores) pre-construidos para tecnologías habituales. Por ejemplo JCA → J2EE Connector Architecture  XML como lenguaje de comunicación inter-aplicación  Reglas de transformación de documentos XML para definir traducciones entre los lenguajes de cada aplicación  Soporte transaccional  Escalabilidad y tolerancia a fallos ⇒ Basados en arquitecturas distribuidas  Centrado fundamentalmente en intranets (perspectiva intra- organización) 15  Lenguajes propietarios
  16. 16. Introducción a Sistemas EAI Sistemas EAI ⇒ Evolución  3ª Generación: Orquestación de Servicios Web → Salto a B2B (Internet)  Perspectiva inter-organización  Aumentan las preocupaciones de seguridad  Aumentan los requisitos de autonomía y asincronismo de las aplicaciones  Surgen nuevas posibilidades ⇒ Por ejemplo el descubrimiento de nuevos servicios relevantes disponible en Internet (UDDI)  WS-BPEL ⇒ Web Service Business Process Execution Language 16
  17. 17. Orquestación de Servicios Web Tipos de Integración. Sistemas de Gestión de Flujos. Introducción a Sistemas EAI. Arquitectura de Sistemas EAI. Orquestación de Servicios Web. 17
  18. 18. Arquitectura de Sistemas EAI Sistemas EAI  Cada aplicación tiene asociado un adaptador (o conector, o “wrapper”) específico:  Hacen que todas las aplicaciones se ajusten a un modelo común.  Se ocupan de la comunicación inter-aplicación (Corba, RMI, Servicios Web, etc.)  Traducen mensajes del lenguaje del sistema EAI al lenguaje de la aplicación y las respuestas de la aplicación al lenguaje EAI.  Un “Concentrador” (“Hub”) central:  Controla las interacciones entre las aplicaciones para ejecutar un flujo.  Funcionalidades de conversión de datos (“Data Mapping”).  Autorización → seguridad, usuarios, permisos, etc.  Notificaciones. 18  Trazabilidad.
  19. 19. Arquitectura de Sistemas EAI Sistemas Hub @ Spoke 19
  20. 20. Arquitectura de Sistemas EAI Adaptadores  Aplicaciones no hablan directamente entre sí sino a través del hub.  La mayoría de sistemas EAI incluyen adaptadores pre- construidos fácilmente configurables para algunos casos:  Servicios Web, Corba, etc.  Aplicaciones de fabricantes populares: ERPs, CRMs, Gestores de contenidos, etc.  Para el resto de aplicaciones (normalmente un elevado porcentaje), es necesario programar de forma manual todo o parte del adaptador implementando alguna interfaz.  Se pretende que el programador de adaptadores tenga que ocuparse sólo de proporcionar el “camino de acceso” a la aplicación, sin lógica ni post-procesamiento complejo. No siempre es posible. 20
  21. 21. Arquitectura de Sistemas EAI Servicio de mensajes  Un sistema EAI requiere de funcionalidades de creación, envío y recepción de mensajes:  Garantía de entrega, de orden de mensajes...  Garantía de integridad y privacidad de mensajes.  Notificaciones de error.  Diferentes semánticas de envío (“once and only once”, “at least once”, etc.)  Mensajes multicast.  Mensajes síncronos y/o asíncronos.  Mensajes punto a punto: Colas de mensajes.  Mecanismos de subscripción: jerarquías de temas.  Muchos sistemas utilizan implementaciones de JMS (Java Message Service). 21
  22. 22. Orquestación de Servicios Web Tipos de Integración. Sistemas de Gestión de Flujos. Introducción a Sistemas EAI. Arquitectura de Sistemas EAI. Orquestación de Servicios Web. 22
  23. 23. Orquestación de Servicios Web Interacción entre servicios 23
  24. 24. Orquestación de Servicios Web Estándares WS para SOA (Systems Oriented Arquitecture) 24
  25. 25. Orquestación de Servicios Web Estándares WS para SOA (Systems Oriented Arquitecture) 25
  26. 26. Orquestación de Servicios Web Orquestación de servicios Web  Conectar servicios web entre sí para crear procesos de negocio de alto nivel.  Se trata de subsumir la funcionalidad básica del EAI dentro de un marco válido también para aplicaciones Business to Business (B2B).  La orquestación de servicios Web se basa en un modelo centralizado en el cual las interacciones no se realizan directamente entre los servicios Web sino que existe una entidad encargada de definir la lógica de interacción.  Normas propuestas ⇒ XLANG, WSFL (Web Services Flow Language), WS-BPEL (Business Process Execution Language for Web Services), WSCI (Web Service Choreography Interface), BPML 26 (Business Process Modeling Language), etc.
  27. 27. Orquestación de Servicios Web BPML ⇒ Propuesta por SUN, CSC, Intalio y otros (incluye WSCI).  Similar a WS-BPEL en la construcción de flujos que definen el comportamiento de un Servicio Web. Más completo en algunos aspectos.  Utiliza WSCI para definir los intercambios entre los Servicios Web que forman parte del proceso. WSCI ⇒ Propuesta por SUN, SAP, BEA e Intalio.  WSCI no define un flujo de tareas ejecutable ⇒ En su lugar, define un proceso mediante los intercambios de mensajes entre Servicios Web que participan en la realización del mismo.  Cada Servicio Web es visto como una caja negra y no se pueden definir declarativamente las operaciones que suceden en su interior. 27  No existe un Servicio Web “rector”.
  28. 28. Orquestación de Servicios Web WS-BPEL ⇒ Business Process Execution Language for Web Services.  Esta especificación modela el comportamiento de los diversos WS que puedan participar en la interacción de un proceso de negocio.  Tiene una sintaxis en XML para la descripción de la lógica de control necesaria para coordinar los WS que participen en un flujo de proceso. Esta gramática es ejecutada por un motor de orquestación que coordina todas las actividades y compensa el proceso global cuando ocurre algún error. 28
  29. 29. Orquestación de Servicios Web Orquestación de servicios Web  El W3C ha lanzado un grupo de trabajo dedicado a la orquestación de servicios Web. Considera WSCI, pero no WS- BPEL (no ha sido enviado como propuesta y sus costes de licencia, en principio, no son gratuitos). Utiliza WSCI para definir los intercambios entre los servicios Web que forman parte del proceso.  Los que proponen WS-BPEL tienen un peso enorme en la industria y parece imponerse como norma “de facto”.  WS-BPEL está estandarizado por OASIS desde la versión 2.0. ⇒ http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf  WS-BPEL nace de la necesidad de manejar lenguajes distintos entre la programación a gran escala y la programación detallada, ya que en su esencia, ambos tipos de desarrollo requieren de distintos grados de comunicación con otros servicios. 29
  30. 30. Orquestación de Servicios Web Orquestación vs. Coreografía  Un modelo de orquestación provee un ámbito específicamente enfocado en la vista de un participante en particular.  En cambio, un modelo coreográfico abarca todos los participantes y sus interacciones asociadas, dando una vista global del sistema.  La coreografía de servicios Web (WS-Choreography) es una especificación de W3C que define procesos de modelo de negocio basados en XML, los cuales describen protocolos de colaboración entre participantes de un servicio Web.  La orquestación describe un control central del comportamiento como un director de orquesta, mientras que la coreografía trata sobre el control distribuido del comportamiento donde participantes individuales realizan procesos basados en eventos externos. 30
  31. 31. Orquestación de Servicios Web Orquestación vs. Coreografía 31
  32. 32. Orquestación de Servicios Web WS-BPEL (Introducción)  (Web Services) Business Process Execution Language, WS- BPEL (Lenguaje de Ejecución de Procesos de Negocio con Servicios Web) ⇒ Es un lenguaje estandarizado por OASIS para la composición de servicios Web  WS-BPEL está desarrollado a partir de WSFL y XLANG, ambos lenguajes orientados a la descripción de servicios Web ⇒ Antes de su estandarización se denominaba BPEL4WS.  WS-BPEL consiste en un lenguaje basado en XML diseñado para el control centralizado de la invocación de diferentes servicios Web, con cierta lógica de negocio añadida que ayuda a la programación en gran escala (desarrollo de software de gran tamaño que involucra grandes procesos de desarrollo, evolución y mantenimiento).  WS-BPEL concebido por Oracle, IBM, SAP, Microsoft, etc. 32
  33. 33. Orquestación de Servicios Web WS-BPEL (Introducción)  WS-BPEL ⇒ Es el encargado de orquestar todo el proceso ordenando qué servicio Web ejecutar y en qué momento.  WS-BPEL ⇒ Proporciona métodos de definición y soporte para flujos de trabajo y procesos de negocio.  WS-BPEL ⇒ Depende del uso de WSDL para describir los mensajes entrantes y salientes → Mensaje = invocación de operación (modelo de interacción orientado al mensaje).  WS-BPEL ⇒ Modelo de lenguaje extensible de componentes para permitir escribir expresiones y consultas en múltiples lenguajes (soporta Xpath).  WS-BPEL ⇒ Permite construcciones de programación estructurada incluyendo "if-then-elseif-else", "while", "sequence“, flow, etc.  WS-BPEL ⇒ Permite el encapsulamiento de lógica con variables locales, manejadores de fallo, manejadores de compensación y 33 manejadores de eventos.
  34. 34. Orquestación de Servicios Web WS-BPEL (Introducción) ⇒ Objetivos de Diseño  Definir procesos de negocio que interactúan con entidades externas mediante operaciones de un servicio Web definidas usando WSDL y que se manifiestan a sí mismas como WS.  Definir procesos de negocio utilizando un lenguaje basado en XML.  Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio.  Proveer sistemas de control jerárquicos y de estilo gráfico, que permitan que su uso sea lo más fusionado posible.  Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. 34
  35. 35. Orquestación de Servicios Web WS-BPEL (Introducción) ⇒ Objetivos de Diseño  Proporcionar funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control.  Ofrecer la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida.  Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera que permita la recuperación de fallos para partes de procesos de negocios a largo plazo.  Usar servicios Web como modelo para la descomposición y ensamblado de procesos.  Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y 35 extensible.
  36. 36. Orquestación de Servicios Web WS-BPEL (Introducción)  La versión actual es la 2.0, aunque algunas implementaciones aún soportan sólo la 1.1.  Estandarizado por Oasis (http://www.oasis- open.org/home/index.php) ⇒ http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=wsbpel  Se utiliza para:  Procesos abstractos ⇒ Definir conversaciones y protocolos para el uso de un servicio Web o de la forma de colaborar de varios servicios Web.  Procesos ejecutables ⇒ Flujos donde cada entidad involucrada es un servicio Web y que, a su vez, ofrecen al exterior una interfaz de servicio Web.  Patrocinado por grandes empresas de informática ⇒ IBM, Microsoft, SAP, Siebel y BEA. 36
  37. 37. Orquestación de Servicios Web WS-BPEL (Introducción)  La mayoría de sistemas EAI actuales están empezando a soportar WS-BPEL.  Los servicios Web son sólo uno de los formatos de interfaz que utilizan.  WS-BPEL tiene el potencial para convertirse en un estándar para este tipo de sistemas.  WS-BPEL tiene algunas carencias  Es necesario formas más sencillas para manipular datos.  XML no es un lenguaje cómodo para escribir código “a mano” y en los entornos actuales es difícil evitarlo.  Algunos defienden el poder incrustar código Java en los flujos BPEL. Otros ven esto como contrario a la filosofía básica de los sistemas de Workflow. 37
  38. 38. Orquestación de Servicios Web WS-BPEL (Introducción)  Principales elementos de WS-BPEL  Socios (“PartnerLinks”) ⇒ Entidades que participan en el flujo.  Variables.  Actividades.  Manejadores:  Manejadores de eventos.  Manejadores de fallos (excepciones).  Manejadores de compensación (operaciones deshacer).  Conjuntos de correlación.  Un Flujo WS-BPEL ofrece a su vez una interfaz de servicio Web hacia el exterior.  Normalmente un proceso WS-BPEL se compone de:  Un archivo con el proceso a ejecutar (.BPEL). 38  Una serie de archivos WSDL de apoyo (definiciones).
  39. 39. Orquestación de Servicios Web WS-BPEL (Socios)  Los socios representan a los servicios Web invocados por el proceso. Se basan en dos elementos:  Tipo de Enlace del Socio (Partner Link Type):  Define un enlace genérico para una categoría de servicios web.  Similar a la definición de una interfaz en lenguajes OO.  Ejemplo: obtención de cartelera, búsqueda de libros, compra de libros.  Enlace del Socio (Partner Link):  Define el servicio web que realmente se invocará.  Similar a una implementación de una interfaz en lenguajes OO. 39
  40. 40. Orquestación de Servicios Web WS-BPEL (Socios)  Tipos de enlaces entre socios  “PartnerLinkTypes” ⇒ Define una colección de roles.  En lugar de definir la relación entre dos servicios Web en términos de “proceso” y “servicio externo” (que adopta el punto de vista del servicio “proceso”), se define de forma neutra.  Cada rol indica una lista de tipos de puerto (portTypes). Un servicio Web puede jugar ese rol si implementa esos tipos de puerto.  Un enlace de socio (PartnerLink) se especifica dándole un nombre, indicando un “partner link type” y especificando el rol jugado por el partner en ese “partner link type”.  Definición de un PartnerLinkType ⇒ Se definen en archivos WSDL utilizados por el proceso BPEL, y no directamente en el proceso BPEL. 40
  41. 41. Orquestación de Servicios Web WS-BPEL (Enlaces entre Socios)  Definición de enlaces (PartnerLinks → instancias del tipo de enlace) en el proceso BPEL: <partnerLinks> <partnerLink name="bookSearcher" partnerLinkType="lns:bookSearchLinkType" partnerRole="bookSearchEngine"/> </partnerLinks>  El alias debe apuntar a la URI del fichero WSDL conteniendo lns la definición del tipo de enlace bookSearchLinkType.  Se define una instancia del tipo de enlace bookSearchLinkType:  Se especifica el nombre de la instancia (bookSearcher).  Se utilizan los atributos partnerRole y/o myRole para indicar quién juega cada rol del tipo de enlace (el proceso o el socio).  No se especifica el “binding” (deployment time). 41
  42. 42. Orquestación de Servicios Web WS-BPEL (Variables)  Las variables se utilizan para guardar los datos utilizados dentro del proceso.  Variables pueden ser:  Mensajes completos definidos en una especificación WSDL.  Un valor de un tipo XML simple (enteros, flotantes, etc.) o compuesto (XML Schema).  Elementos XML.  El tipo de las variables se define en la especificación WSDL del servicio (o en otros WSDL externos).  Ejemplos: <variable name=“searchRequest" messageType=“searchdef:bookSearchMessage"/> <variable name=“searchResponse" messageType=“searchdef:bookSearchReturn"/> 42 <variable name=“numResults“ type=“xsd:int"/>
  43. 43. Orquestación de Servicios Web WS-BPEL (Actividades primitivas)  Actividades primitivas:  Invoke ⇒ Invocar una operación en un servicio web.  Receive ⇒ Esperar a la recepción de una invocación sobre una operación del sitio web.  Reply ⇒ Generar la respuesta de una operación entrada/salida.  Wait ⇒ Esperar un tiempo.  Assign ⇒ Asignar valores a variables.  Throw ⇒ Lanzar excepciones.  Rethrow ⇒ Relanzar excepciones desde dentro de manejadores de error.  Exit ⇒ Terminar la instancia.  Empty ⇒ No hacer nada.  ExtensionActivity ⇒ Para añadir extensiones propietarias.  Validate ⇒ Permite validar el esquema de variables XML. 43
  44. 44. Orquestación de Servicios Web WS-BPEL (Actividades estructuradas)  Las actividades primitivas pueden ser combinadas utilizando las siguientes estructuras de control:  Sequence ⇒ Secuencia de actividades.  Flow ⇒ Ejecutar actividades en paralelo. Las restricciones de orden pueden especificarse mediante “links” (enlaces).  If ⇒ Estructura condicional para escoger entre un conjunto de actividades.  While, Repeat, ForEach ⇒ Creación de bucles.  Pick ⇒ Ejecutar uno de varios caminos alternativos, en función de que se produzca un evento u otro.  Scope ⇒ Define un bloque de actividades (utilizado en transacciones).  Compensate ⇒ Define las actividades de un bloque de compensación. 44
  45. 45. Orquestación de Servicios Web WS-BPEL (Manejadores)  Manejadores de fallos (Fault Handlers). Se ejecutan cuando se lanza una excepción ⇒ Similar al manejo de excepciones en LP.  Manejadores de compensación (Compensation Handlers). Se ejecutan para deshacer una operación ⇒ Relacionados con el tratamiento de transacciones.  Manejadores de eventos. Se ejecutan cuando se recibe un mensaje particular o se produce una determinada alerta.  Los manejadores deben asociarse a un ámbito (“scope”), concepto muy similar al de “bloque de código” en los LP  Si salta una excepción dentro de un scope determinado, se invoca el correspondiente manejador de fallo.  Los manejadores de eventos están activos mientras el flujo de control permanece dentro del bloque. Se ejecutan si llega un determinado mensaje o se da una cierta condición. 45
  46. 46. Orquestación de Servicios Web WS-BPEL (Conjuntos de correlación)  BPEL especifica procesos abstractos (por ejemplo, procesar una orden de compra o el tratamiento de una incidencia).  Surge el problema de cómo puede identificar cada instancia los mensajes concretos que se refieren a ella (por ejemplo, los mensajes involucrados en el procesamiento de una orden de compra concreta).  La idea básica es asignar un nombre a una parte del mensaje útil para identificar una instancia concreta (por ejemplo, número de orden de compra). Entonces, el sistema asignará a cada instancia el mensaje que tenga el valor asociado a ella (por ejemplo asignará los mensajes asociados a un número de orden de compra a la instancia encargada de procesar dicha orden).  Los conjuntos de correlación son un concepto discutido en BPEL, ya que es un concepto lioso de demasiado bajo nivel 46
  47. 47. Orquestación de Servicios Web WS-BPEL (Conclusiones)  BPEL sigue las ideas básicas de los sistemas de gestión de flujos, y las aplica para la orquestación de servicios Web.  BPEL está pensado para que los procesos sean creados gráficamente ya que crearlos directamente en XML no es factible para procesos complejos.  Algunas direcciones Web interesantes:  http://soa.netbeans.org/soa/  http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=int roduccion-BPEL-openesb  http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=int roduccion-BPEL-openesb2  http://www.bajaryoutube.com/videos/bpel-tutorial-teil-1-bytid- lqiYIFPd1Wc.html 47
  48. 48. Orquestación de Servicios Web Orquestación de servicios Web (Microsoft Biztalk Server)  Algunas direcciones Web interesantes:  http://msdn.microsoft.com/es-es/library/aa561986(v=BTS.10).aspx  http://msdn.microsoft.com/es-es/library/aa577497(v=BTS.10).aspx  http://msdn.microsoft.com/es-es/library/aa560270(v=BTS.10).aspx  http://msdn.microsoft.com/es-es/library/aa577489(v=BTS.10).aspx  http://msdn.microsoft.com/es-es/library/aa559238(v=bts.10).aspx  http://msdn.microsoft.com/es-es/library/aa547115(v=BTS.10).aspx  http://msdn.microsoft.com/es-es/library/aa577901(v=BTS.10).aspx 48
  49. 49. Orquestación de Servicios Web Windows Workflow Foundation (WF)  Algunas direcciones Web interesantes:  http://msdn.microsoft.com/es-es/library/bb628617(v=VS.90).aspx  http://msdn.microsoft.com/es-es/netframework/aa663328 49

×