6.2 orquestación de servicios web - tic.udc.esfbellas/teaching/adoo-2003-2004/tema6apart... ·...

6.2 Orquestación de servicios Web

Introducción (1)

n Orquestación de Servicios Web:n Conectar servicios web entre sí para crear procesos de

negocio de alto nivel.n Se trata de subsumir la funcionalidad básica del EAI dentro

de un marco válido también para aplicaciones Business toBusiness (B2B).

n Normas propuestas:n Primeras propuestas:

n XLANG. Propuesta por Microsoft dentro de su software BizTalk Server.

n WSFL. Propuesta por IBM.n BPEL4WS. Subsume a XLANG y WSFL. Propuesta por IBM,

Microsoft y BEA.n Inicialmente, permite definir un flujo que combina diversos

Servicios Web, ofreciendo a su vez una interfaz de Servicio Web hacia el exterior (Servicio Web “rector”).

Introducción (2)

n Normas propuestas (cont):n WSCI. Propuesta por SUN, SAP, BEA e Intalio.

n WSCI no define un flujo de tareas ejecutable. n En su lugar, define un proceso mediante los intercambios de

mensajes entre Servicios Web que participan en la realización del mismo.

n Cada Servicio Web es visto como una caja negra y no se pueden definir declarativamente las operaciones que suceden en su interior.

n No existe un Servicio Web “rector”.

n BPML. Propuesta por SUN, CSC, Intalio y otros (incluye WSCI).n Similar a BPEL4WS en la construcción de flujos que definen el

comportamiento de un Servicio Web.n Utiliza WSCI para definir los intercambios entre los Servicios

Web que forman parte del proceso.

Introducción (y 3)

n El W3C ha lanzado un grupo de trabajo dedicado a la orquestación de Servicios Web. Considera WSCI y BPML, pero no BPEL4WS (no ha sido enviado como propuesta y sus costes de licencia, en principio, no son gratuitos).

n Pero los proponentes de BPEL4WS tienen un peso enorme en la industria…

n Posible escenario final: BPEL4WS para definir procesos ejecutables y WSCI para definir procesos abstractos.

Introducción a BPEL4WS (1)

n Business Process spEcification Language for Web Services

n Es la especificación para la composición de servicios web que actualmente parece contar con más apoyos.

n Utilizado para:n Procesos abstractos: Definir conversaciones y protocolos

para el uso de un servicio web o de la forma de colaborar de varios servicios web.

n Procesos ejecutables: Flujos dónde cada entidad involucrada es un servicio web y que, a su vez, ofrecen al exterior una interfaz de Servicio Web.

n Patrocinado por IBM, BEA, Microsoft, SAP, …

Introducción a BPEL4WS (2)

n La mayoría de sistemas EAI actuales no utilizan BPEL4WS sino lenguajes propietarios.

n Además, los Web Services son sólo uno de los formatos de interfaz que utilizan.

n Sin embargo, las capacidades permitidas por BPEL4WS son similares a las de estos sistemas, por lo que nos servirán también para aprender sus fundamentos básicos.

n BPEL4WS tiene el potencial para convertirse en un estándar para este tipo de sistemas tanto en aplicaciones inter-organización como intra-organización (B2B), pero ese potencial aún está por materializarse.

Introducción a BPEL4WS (y 3)

n Elementos de BPEL4WS:n Socios (“Partners”): Entidades.n Variables.n Actividades.n Manejadores:

n Manejadores de eventos.n Manejadores de fallos (excepciones).n Manejadores de compensación (operaciones deshacer).

n Conjuntos de correlación.

n Un Flujo BPEL4WS ofrece a su vez una interfaz Web Service hacia el exterior.

n Normalmente un proceso BPEL4WS se compone de:n Un fichero con el proceso a ejecutar (.BPEL)n Una serie de ficheros WSDL de apoyo (definiciones).

Socios

n Los socios representan a los servicios web invocados por el proceso. Se basan en tres elementos:n Tipo de Enlace del Socio (Partner Link Type):

n Define un enlace genérico para una categoría de servicios web.n Similar a la definición de una clase en lenguajes OO. n Ejemplo: obtención de cartelera, búsqueda de libros, compra de libros.

n Enlace del Socio (Partner Link):n Define el servicio web que realmente se invocará.n Similar a una instancia de una clase en lenguajes OO.n Amazon_search (Enlace del tipo “búsqueda de libros”),

Amazon_purchase (enlace del tipo “compra de libros”), Cinentradas_get (enlace del tipo “obtener cartelera”).

n Socio (Partner):n Pueden usarse para agrupar todos los enlaces del mismo “socio físico”.n Socio “Amazon” agrupa los enlaces Amazon_search y

Amazon_purchase.

Tipos de enlaces entre socios (1)

n “Partner Link Types”.n 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.

n Define una colección de roles.n Cada rol indica una lista de tipos de puerto

(portTypes). Un servicio web puede jugar ese rol si implementa esos tipos de puerto.

n Un enlace de socio (Partner Link) es especificado dándole un nombre, indicando un “partner link type” y especificando el rol jugado por el partner en ese “partner link type”.


n Definición de un PartnerLinkType:n Normalmente se definen en ficheros WSDL utilizados por el

proceso BPEL, y no directamente en el proceso BPEL.n Definición tipo de puerto (WSDL externo):

<portType name=“bookSearchPT">

<operation name=“bookSearch">

<input message=“searchdef:bookSearchMessage"/>

<output message=“searchdef:bookSearchResults"/>

</operation>

</portType>

n Definición PartnerLinkType (WSDL externo)<plnk:partnerLinkType name=“bookSearchLinkType">

<plnk:role name=“bookSearchEngine">

<plnk:portType name="apns:bookSearchPT"/>

</plnk:role>

</plnk:partnerLinkType>


n Comentarios:n La definición del tipo de puerto es la estándar en WSDL:

n Una operación bookSearch recibe como entrada un mensaje de tipo bookSearchMessage y devuelve un mensaje de tipo bookSearchResults.

n La definición del tipo de enlace especifica un único rol (bookSearchEngine) que está ligado al tipo de puerto anterior.

n En la URI asociada al alias searchdef, estarían definidos los mensajes bookSearchMessage (consulta) y bookSearchResults (resultados).

n plnk estaría asociado a una URI de la especificación de BPEL.

n apns estaría asociado a la URI del fichero WSDL dónde se ha definido el tipo de puerto.

Tipos de enlaces entre socios (y 4)

n Comentarios:n Este tipo de enlace podría utilizarse para cualquier servicio

de búsqueda de libros cuya interfaz fuese coherente con el tipo de puerto especificado (e.g. AmazonSearch, CorteInglesSearch).

n Requiere estándares inter-organización:n Mensajes de consulta y lista de resultados tendrían que tener

los mismos formatos en todos los servicios de búsqueda.n La operación de búsqueda tendría que tener también la misma

interfaz.

n Hay numerosos intentos de estandarizar las comunicaciones B2B en diferentes áreas:n Ejemplo: ebXML (http://www.ebxml.org).n En gran parte, es todavía un esfuerzo en curso.

Enlaces entre socios

n Definición de enlaces (PartnerLinks: instancias del tipo de enlace) en el proceso BPEL:<partnerLinks>

<partnerLink name=“bookSearcher"

partnerLinkType="lns:bookSearchLinkType"

partnerRole=“bookSearchEngine"/>

</partnerLinks>

n Comentarios:n Se define una instancia del tipo de enlace bookSearchLinkType:

n Se especifica el nombre de la instancia (bookSearcher).n Se utilizan los atributos partnerRole y/o myRole para indicar quién

juega cada rol del tipo de enlace (el proceso o el socio). En este caso se supone que se está definiendo un cliente de búsqueda. Si esta fuese la definición de un servicio buscador, se utilizaría myRole=“bookSearchEngine” y no se utilizaría partnerRole.

n No se especifica el “binding” (deployment time).n El alias lns debe apuntar a la URI del fichero WSDL conteniendo la

definición del tipo de enlace bookSearchLinkType.

Variables

n Las variables se utilizan para guardar los datos utilizados dentro del proceso.

n Variables pueden ser:n Mensajes completos definidos en la especificación WSDL del

servicio que usa dicho mensaje.n Un valor de un tipo básico XML (enteros, flotantes, etc.)n Elementos compuestos XML.

n El tipo de las variables se define en la especificación WSDL delservicio (o en otros WSDL externos).

n Ejemplos:<variable name=“searchRequest"

messageType=“searchdef:bookSearchMessage"/>

<variable name=“searchResponse"

messageType=“searchdef:bookSearchResults"/>

<variable name=“numResults"

type=“xsd:int"/>

<variable name=“searchResult"

element=“searchdef:searchResult"/>

Actividades primitivas

n Actividades primitivas:n Invoke. Invocar una operación en un servicio web.n Receive. Esperar a la recepción de una invocación sobre una

operación del sitio web.n Reply. Generar la respuesta de una operación

entrada/salida.n Wait. Esperar un tiempo.n Assign. Asignar valores a variables.n Throw. Lanzar excepciones.n Terminate. Terminar la instancia.n Empty. No hacer nada.

Actividades primitivas: Invoke

n Actividades primitivas: Invoke

<invoke name="invokeBookSearch" partnerLink=“bookSearcher"

portType="apns:bookSearchPT"

operation=“bookSearch"inputVariable=“searchRequest"

outputVariable=“searchResponse">

</invoke>

n Comentariosn Se identifica el enlace de socio, el tipo de puerto, la operación, la

variable que contiene el mensaje de petición y la variable dónde se almacenará la respuesta de la misma.

Actividades primitivas: Receive

n Actividades primitivas: Receive

<receive name="receivePetition" partnerLink=“bookSearcher"

portType="apns:bookSearchPT"

operation=“bookSearch" variable=“searchRequest"createInstance="yes">

n Comentariosn Se identifica el enlace de socio, el tipo de puerto, la operación y la

variable para guardar el mensaje que llega.n createInstance="yes” se utiliza para arrancar una nueva instancia

de un proceso BPEL (un proceso BPEL se inicia normalmente al recibir un mensaje). Si el receive no se corresponde con el mensaje inicial que arranca un flujo, no tendría este atributo.

Operación asíncrona

n El proceso realiza una petición invocando una operación (asociada a un puerto) del servicio webexterno.

n El servicio web externo responde invocando una operación (asociada a un puerto) del servicio web del proceso.

n La operación y puerto que el servicio externo debe usar en su respuesta pueden ser pasados como parámetro en la invocación inicial.

n La situación se ve de forma simétrica desde ambos puntos de vista (proceso y servicio externo), dependiendo de quién inicie la comunicación.

Actividades primitivas: Reply

n Actividades primitivas: Reply

<reply name="replyPetition" partnerLink=“bookSearcher" portType="apns:bookSearchPT"

operation=“bookSearch" variable=“searchResponse">

</reply>

n Comentariosn Se identifica el enlace de socio, el tipo de puerto, la operación y la

variable que contiene el mensaje de respuesta.

Actividades primitivas: Assign

n Actividades primitivas: Assignn Permite todo tipo de manipulaciones de datos en los documentos

intercambiados.n Se basa fuertemente en Xpath y en una serie de funciones

predefinidas.n Xpath (http://www.w3.org/TR/xpath) es un lenguaje que permite:

n Direccionar partes concretas de un documento XML (actúa como un lenguaje de consulta simple sobre documentos XML).

n También incluye ciertas funciones de manipulación de datos.n Es un componente básico necesario para especificar consultas y

transformaciones sobre documentos XML. Se utiliza en XSLT, XQuery, etc.

n Veremos sólo una idea intuitiva de su funcionamiento.

Actividades primitivas: Assign (2)

n Consultas XPath: Identifican secciones específicas dentro de documentos XML complejos. Ejemplo:

<searchresponse>

<numberResults> 10 </numberReults>

<searchresults>

<searchresult>

<title> Veinte años despues </title>

<author> Alejandro Dumas </author>

<price currency=“euro”> 15 </price>

</searchresult>

<searchresult>

<title> Suave es la noche </title>

<author> Scott Fitzgerald </author>

<price currency=“euro”> 25 </price>

</searchresult>

…

</searchresults>

…

</searchresponse>

n /searchresponse/searchresults/searchresult[1]/title identifica el título del primer libro de la lista.


n Consultas XPath. También soportan:n Comodines. ‘/searchresponse/*’ extrae todos los

elementos hijos de searchresponse.n Rutas relativas. ‘//searchresult/title’ extrae todos los

títulos.n Acceso a atributos: //searchresult/price[@currency=‘euro’]selecciona todos los precios de resultados de búsqueda cuya moneda es el euro.

n Funciones y condiciones complejas: manipulación de cadenas, operaciones aritméticas,…

n Las rutas pueden utilizar diferentes primitivas de navegación por árbol: child (por defecto), parent, ancestor, descendant, …

n Y muchas funcionalidades más...


n Ejemplos de expresiones Xpathn Constantes:

n 100. Enterosn ’ADOO’. Cadenas

n Etc.

n Funciones:n concat (‘cadena 1’,’cadena2’). Concatenación de

cadenas.n formatDate (‘2004-05-03T15:56:00’, ‘MMM dd, yyy’). Manipulación de fechas.

n Etc.


n Actividades primitivas: Assignn Una actividad assign contiene uno o más elementos copy,

cada uno de ellos con un elemento from y un elemento to(sus tipos deben ser compatibles)

n El elemento from puede especificar:n Una variable conteniendo un mensaje completo.n Una parte dentro del mensaje contenido en una variable

(recuérdese que un mensaje puede contener varias partes, dónde habitualmente una parte representa a un parámetro dentro de un mensaje de entrada o de salida asociado a una operación).

n Una expresión Xpath cualquiera:n Constanten Actuando sobre un mensaje contenido en una variable mediante

expresiones y consultas Xpath.n Las funciones Xpath que se utilicen pueden ser estándar o del

grupo de las añadidas específicamente dentro de BPEL4WS.


n Ejemplos de uso de Assign:n Copia de un valor constante a una variable

<assign name="assign"><copy><from expression=“10"/><to variable=“searchResponse" part=“numberResults"/>

</copy></assign>

n Copia de XML constante a una variable:<assign name="assign">

<copy><from><searchresult> … </searchresult><searchresult> … </searchresult>

</from><to variable=“searchResponse" part=“searchresults"/>

</copy></assign>

n Comentario: Hemos supuesto que el mensaje en searchResponse tiene dos partes: numberResults y searchResults (distinto del usado en el ejemplo de consultasXpath, dónde todo estaba en una sola parte).


n Ejemplos de uso de Assign:n Copiar variables (también podrían usarse partes).

<assign name="assign">

<copy>

<from variable=“data"/>

<to variable=“searchResponse“/>

</copy>

</assign>

n Accediendo variables con elementos complejos:<assign name="assign">

<copy><from variable=“data”

query=“/searchresponse/searchresults/searchresult[1]/title”>

<to variable=“firstResult" query=“/title”/></copy>

</assign>

n Nota: Se supone que las variables utilizadas han sidodefinidas con los tipos adecuados.


n Ejemplos de uso de Assign:n Expresiones matemáticas:


<copy>

<from expression=“bpws:getVariableData(‘data’,‘Results’,’/numberResults’)+1"/>

<to variable=“searchResponse“ query =“/numberResults”/>

</copy>

</assign>

n getVariableData es una función de BPEL4WS que permite acceder a los contenidos de una variable. Los parámetros especifican unavariable, una parte dentro del mensaje contenido en la misma y una consulta Xpath.

n NOTA: Se supone que las variables utilizadas han sido definidascon los tipos adecuados.

Actividades primitivas: Assign (y 9)

n Ejemplos de uso de Assign:n Concatenando cadenas:


<copy>

<from expression=“ concat(‘Title of first result:’, bpws:getVariableData(‘searchResponse’,’SearchResults’,’/searchresponse/searchresults/searchresult[1]/title’)) ”/>

<to variable=“data“ query =“/title”/>

</copy>

</assign>

n NOTA: Se supone que las variables utilizadas han sido definidascon los tipos adecuados.

Actividades estructuradas

n Las actividades primitivas pueden ser combinadas utilizando las siguientes estructuras de control:n Sequence. Secuencia de actividades.n Flow. Ejecutar actividades en paralelo. Las restricciones de

orden pueden especificarse mediante “links” (enlaces).n Switch. Estructura condicional para escoger entre un

conjunto de actividades.n While. Creación de bucles.n Pick. Ejecutar uno de varios caminos alternativos, en función

de que se produzca un evento u otro.n Scope. Define un bloque de actividades (utilizado en

transacciones).n Compensate. Define las actividades de un bloque de

compensación.

Actividades estructuradas: Sequence

n Actividades estructuradas: Sequencen Ejecuta secuencialmente una serie de actividades.

Ejemplo:

<sequence>

<receive> … </receive>

<invoke> …</invoke>

<assign> …</assign>

<reply> …</reply></sequence>

Actividades estructuradas: Flow

n Actividades estructuradas: Flown Ejecuta en paralelo una serie de actividades.

Ejemplo:

<flow>

<links> …</links>

<invoke name “invokeProvider1”> … </invoke>

<invoke name “invokeProvider2”> …</invoke>

…</flow>

n Pueden establecerse dependencias entre algunas tareas utilizando links (los veremos más adelante). Permiten:n Secuencializar ciertos pasos cuando sea necesario.n En ciertos casos, sirven para implementar bifurcaciones

(alternativa a switch).

Actividades estructuradas: Switch

n Actividades estructuradas: Switch. Estructura de bifurcación:

<switch>

<case condition= "bpws:getVariableData(‘data’,’part’,’/number’) > 100">

<flow>

…</flow>

</case>

<case condition="bpws:getVariableData(‘data’,’part’,’/number’) >= 0">

<sequence>

…

</sequence>

</case>

<otherwise><throw faultName="FLT:InvalidValue"/>

</otherwise>

</switch>

Actividades estructuradas: While

n Actividades estructuradas: While. Estructura repetitiva:

<variable name="orderDetails" type="xsd:integer"/>

...

<while condition= "bpws:getVariableData(orderDetails) > 100">

<sequence>

…

</sequence>

</while>

Actividades estructuradas: Pick

n Actividades estructuradas: Pick:<pick>

<onMessage partnerLink="buyer"portType="orderEntry"operation="inputLineItem"variable="lineItem">

<sequence> …</sequence>

</onMessage><onMessage partnerLink="buyer"

portType="orderEntry"operation="orderComplete"variable="completionDetail">

<sequence> …</sequence>

</onMessage>…

</pick>

n Se ejecutará la acción cuyo evento asociado ocurra antes.

Actividades: Links

n Las actividades en BPEL pueden verse como nodos en un grafo, dónde los enlaces entre nodos determinan el flujo de control entre actividades.

n Las actividades tienen dos elementos opcionales para establecer dependencias entre los enlaces del grafo que conforman el flujo:n Target. La actividad es destino del enlace especificado. Esto

quiere decir que la actividad no comenzará hasta que dicho enlace se active (normalmente, al finalizar otra actividad).

n Source. La actividad es fuente del enlace especificado. Cuando la actividad termine, activará el enlace, posiblemente desencadenando la ejecución de otras actividades que tengan ese enlace como target.

n Manejando estas dependencias, es posible construir estructuras condicionales, flujos en paralelo, etc.

n Más adelante veremos un ejemplo detallado.

Manejadores (1)

n Manejadores de fallos (Fault Handlers). Se ejecutan cuando se lanza una excepción.n Similar al manejo de excepciones en lenguajes de

programación.

n Manejadores de compensación (Compensationhandlers). Se ejecutan para deshacer una operación.n Relacionados con el tratamiento de transacciones.

n Manejadores de eventos. Se ejecutan cuando se recibe un mensaje particular o se produce una determinada alerta. n Ej: comprador envía un mensaje de cancelación.

Manejadores (y 2)

n Los manejadores deben asociarse a un ámbito (“scope”), concepto muy similar al de “bloque de código” en los lenguajes de programación:n Si salta una excepción dentro de un scope determinado, se

invoca el correspondiente manejador de fallo.n Si hay que deshacer los efectos de un scope (e.g.

transacción), se llama al manejador de compensación del bloque. Si hay bloques anidados, se llama a sus manejadores de compensación en orden inverso de ejecución.

n Loa 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.

Conjuntos de correlación (1)

n BPEL especifica procesos abstractos (e.g. procesar una orden de compra o el tratamiento de una incidencia).

n Surge el problema de cómo puede identificar cada instancia los mensajes concretos que se refieren a ella (e.g. los mensajes involucrados en el procesamiento de una orden de compra concreta).

n La idea básica es asignar un nombre a una parte del mensaje útil para identificar una instancia concreta (e.g. número de orden de compra). Entonces, el sistema asignará a cada instancia el mensaje que tenga el valor asociado a ella (e.g. asignará los mensajes asociados a un número de orden de compra a la instancia encargada de procesar dicha orden).

Conjuntos de correlación (y 2)

n Los conjuntos de correlación son muy discutidos en BPEL y es posible que terminen siendo suprimidos o no utilizados.n Son un concepto engorroso de demasiado bajo nivel.n Son bastante dependientes de la implementación.n Hay maneras más sencillas de resolver este problema sin

que el programador del proceso tenga que preocuparse por ello:n Cuando el procedimiento arranca, se le asigna un id. generado

automáticamente.

n ¿Por qué están entonces? Debido a ciertas consideraciones de implementación que no está claro que se vayan a seguir en la práctica.

n Nos olvidaremos de ellos en los ejemplos.

Conclusiones

n BPEL sigue las ideas básicas de los sistemas de gestión de flujos, y las aplica para la orquestación de Servicios Web.

n BPEL es también bastante próximo a JAVA. Las implementaciones existentes compilan los flujos a JAVA.

n BPEL está pensado para que los procesos sean creados gráficamente ya que crearlos directamente en XML no es factible para procesos complejos (veremos algo más sobre esto).

n Especificación: http://www-106.ibm.com/developerworks/library/ws-bpel/

n Pocas implementaciones por ahora: BPWS4J (http://www.alphaworks.ibm.com/tech/bpws4j), Collaxa, …

Ejemplo (1)

n Un vendedor de ordenadores on-line realiza el siguiente proceso para comprobar si puede servir un pedido:1. Recibe una petición de un usuario pidiendo oferta por un

producto.2. Se comprueba si el cliente está al día de los pagos y tiene

crédito. Si no, rechaza el pedido.3. Consulta a su aplicación de almacén para saber si dispone

de existencias. La aplicación de almacén indica también el precio por unidad del producto.

4. Si hay existencias, confirma directamente la aceptación del pedido.

5. Si no hay existencias en almacén, se emite un pedido a dos proveedores y se escoge la oferta de menor precio.

Ejemplo (2)

n Hay involucrados los siguientes socios:n Cliente:

n Emite un pedido de acuerdo a un formato estándar (e.g. fijado por una organización de estándares B2B), que constará de: n Nombre del producto.n Cantidad.n Nombre del cliente.

n Espera como respuesta un mensaje indicando la aceptación o denegación del pedido y un precio para el mismo (en caso de ser aceptado).

Ejemplo (3)

n Hay involucrados los siguientes socios:n Aplicación de crédito.

n Tiene una operación que permite saber si un cliente está o no al día de los pagos.

n Recibe como parámetro el nombre del cliente.n Devuelve un mensaje indicando si el cliente está o no al día.

n Aplicación de almacén:n Expone una operación qué permite conocer si hay o no

existencias de un producto determinado.n Recibe como parámetros.

n El nombre del producto.n La cantidad de items deseada.

n Devuelve la aceptación o rechazo de la petición y el precio por unidad del producto solicitado.

Ejemplo (y 4)

n Hay involucrados los siguientes socios (cont):n Proveedores:

n Exponen la misma interfaz para servir pedidos que la que nuestro proceso expone a sus clientes.

n Recibe un pedido: nombre de cliente, producto cantidad.n Devuelve la aceptación o no del mismo y su precio.

Estructura de ficheros (1)

n Estructura de ficheros. Tendremos:n Ficheros WSDL para definir de forma abstracta las

operaciones y mensajes de cada uno de los tres tipos de enlaces que tenemos: realización de pedidos, consultas de crédito y consultas de stock.n Estos ficheros serán reutilizables en distintas aplicaciones y

con distintos servicios web, siempre que sean conformes a esta interfaz.

n Si hay organizaciones que fijen estándares inter-organización (e.g. ebXML en B2B), estos WSDL pueden ser proporcionados por estas organizaciones a todos los interesados, y las aplicaciones comerciales pueden tener pre-programado el tratamiento de estos formatos.

Estructura de ficheros (y 2)

n Estructura de ficheros (cont):n Ficheros WSDL para los servicios web concretos.

n Importarán el WSDL que define de forma genérica su funcionamiento, y además añadirán las secciones de “binding” y definición del servicio (es necesario saber la ruta física a los servicios).

n Otros ficheros WSDL con definiciones útiles para el proceso BPEL (en nuestro ejemplo, no hay).

n El proceso BPEL en sí mismo.

n NOTA:n Por brevedad, en este punto ignoraremos el tratamiento de

errores.

WSDL Servicios de pedidos (1)

n Modela a los proveedores y a nuestro propio proceso (quizás es un WSDL fijado por alguna organización B2B).

<definitions targetNamespace="http://tempuri.org/services/orderapprover"

xmlns:orderdef="http://tempuri.org/services/orderapprover"xmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="orderInformationMessage"><part name="client" type="xsd:string"/><part name="productName" type="xsd:string"/><part name="amount" type="xsd:int"/>

</message>

<message name="approvalMessage"><part name="accept" type="xsd:string"/><part name="price" type="xsd:int"/>

</message>

WSDL Servicios de pedidos (y 2)

<portType name="orderApprovalPT">

<operation name="approve">

<input message="orderdef:orderInformationMessage"/>

<output message=“orderdef:approvalMessage"/>

</operation>

</portType>

<plnk:partnerLinkType name="orderApprovalLinkType">

<plnk:role name="approver">

<plnk:portType name="orderdef:orderApproverPT"/>

</plnk:role>

</plnk:partnerLinkType></definitions>

n Notas:n Nótese que no se definen bindings aquí, ya que son

especificaciones no ligadas a un servicio concreto.

WSDL Servicio de crédito (1)

n Modela a la aplicación de crédito.<message name="creditInformationMessage">

<part name="requesterName" type="xsd:string"/>

</message>

<message name="creditResponseMessage">

<part name="accept" type="xsd:string"/>

</message>

<portType name="creditApprovalPT"><operation name="checkCredit">

<input message= “creditdef:creditInformationMessage"/>

<output message=“creditdef:creditResponseMessage"/>

</operation>

</portType>

WSDL Servicio de crédito (y 2)

<plnk:partnerLinkType name=“creditApprovalLinkType">

<plnk:role name="approver">

<plnk:portType name=“creditdef:creditApproverPT"/>

</plnk:role>


n Notas:n Se muestra ya sólo la definición de mensajes, operaciones y

tipos de enlace.n Nótese que no se definen bindings aquí, ya que son


WSDL Almacén (1)

n Modela a la aplicación de almacén.

<message name=“stockRequestMessage"><part name=“productName" type="xsd:string"/><part name=“amount" type="xsd:int"/>

</message>

<message name=“stockResponseMessage"><part name="accept" type="xsd:string"/><part name="unitPrice" type="xsd:int"/>

</message>

<portType name=“stockApprovalPT"><operation name="checkStock">

<input message=“stockdef:stockRequestMessage"/><output message=“stockdef:stockResponseMessage"/>

</operation></portType>

WSDL Almacén (y 2)

<<plnk:partnerLinkType name="stockApprovalLinkType">

<plnk:role name="stockapprover">

<plnk:portType name="stockdef:stockApprovalPT"/></plnk:role>


n Notas:n Se muestra ya sólo la definición de mensajes, operaciones y

tipos de enlace.n Nótese que no se definen bindings aquí, ya que son


WSDL de servicios web concretos

n Importarán el WSDL genérico para el tipo de enlace que implementan y añadirán su información de binding y la definición del servicio. Ejemplo:

<binding name="SOAPBinding" type=“orderdef:orderApprovalPT"><soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="approve"><soap:operation soapAction="" style="rpc"/>…</operation>

</binding><service name=“Provider 1">

<documentation>Provider1 Service</documentation><port name="SOAPPort" binding="tns:SOAPBinding"><soap:address

location="http://www.provider1.com:8080/orders/servlet/rpcrouter"/></port>

</service>

Proceso BPEL

n Debemos definir:n Variables.n Enlaces a socios.n Faults y su procesamiento (no lo veremos).n Flujo de actividades.

n Todas las definiciones deben ir dentro de un elemento process:

<process name="orderApprovalProcess" targetNamespace="http://myOrganization.com/orderprocessing"suppressJoinFailure="yes"xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"xmlns:orderdef="http://tempuri.org/services/orderapprover" xmlns:creditdef="http://tempuri.org/services/creditapprover"xmlns:stockdef=http://tempuri.org/services/stockapprover…

>…

</process>

Variables (1)

n Definición de Variables. Necesitamos:n Variables para almacenar el pedido recibido del cliente

(request) y nuestra respuesta al mismo (orderResponse).n Variables para la consulta a la aplicación de crédito

(creditRequest) y para almacenar la respuesta (creditResponse).

n Variables para la consulta a la aplicación de almacén (stockRequest) y para almacenar la respuesta (stockResponse).

n Variables para almacenar la petición a los proveedores (llega una para ambos: requestProviders) y para almacenar su respuesta (responseProvider1, responseProvider2).

Variables (y 2)

n Definición de Variables:<variables><variable name="request"

messageType="orderdef:orderInformationMessage"/><variable name="orderResponse"

messageType=“orderdef:approvalMessage"/><variable name="creditRequest"

messageType="creditdef:creditInformationMessage"/><variable name="creditResponse"

messageType="creditdef:creditResponseMessage"/><variable name="stockRequest"

messageType="stockdef:stockRequestMessage"/><variable name="stockResponse"

messageType="stockdef:stockResponseMessage"/><variable name="requestProviders"

messageType="orderdef:orderInformationMessage"/><variable name="provider1Response"

messageType="orderdef:approvalMessage"/><variable name="provider2Response"

messageType="orderdef:approvalMessage"/></variables>

Enlaces a socios (1)

n Enlaces a socios. Necesitamos enlaces para:n Cliente. Seguirá el tipo de enlace para pedidos y nuestro

proceso jugará el rol de ‘approver’.n Aplicación de crédito. Seguirá el tipo de enlace para

consulta de crédito y será la aplicación externa la que juegue el rol de ‘approver’.

n Aplicación de almacén. Seguirá el tipo de enlace para consulta de almacén y será la aplicación externa la que juegue el rol de ‘stockapprover’.

n Proveedor 1. Seguirá el tipo de enlace para pedidos y será la aplicación externa la que juegue el rol de ‘approver’.

n Proveedor 2. Seguirá el tipo de enlace para pedidos y será la aplicación externa la que juegue el rol de ‘approver’.

Enlaces a socios (2)

n Enlaces a socios:<partnerLinks>

<partnerLink name="customer"

partnerLinkType=“orderdef:orderApprovalLinkType"

myRole="approver"/><partnerLink name="creditapprover"

partnerLinkType=“creditdef:creditApprovalLinkType"

partnerRole="approver"/>

<partnerLink name="stock"

partnerLinkType=“stockdef:stockApprovalLinkType"

partnerRole="approver"/><partnerLink name="provider1"


partnerRole="approver"/>

<partnerLink name="provider2"


partnerRole="approver"/></partnerLinks>

Enlaces a socios (y 3)

n Nota:n Es importante notar que al definir los enlaces a socios NO

se especifica qué servicio concreto implementa cada enlace a socio con lo que, en principio, no podría saberse qué información de binding se corresponde con cada servicio.

n En realidad, esto se considera externo al flujo BPEL y se realiza en tiempo de ‘deploy’ de la aplicación BPEL.

n Concretamente, el entorno de desarrollo BPEL debe permitir configurar con qué servicio concreto debe asociarse cada enlace a socio.

Flujo de tareas

n Construiremos el flujo con la actividad estructurada flow (ejecución en paralelo) y utilizaremos links para establecer dependencias entre las tareas, serializando los pasos que nos interesen.

<flow><links><link name="receiveToPrepareCreditMessage"/><link name="invokeCreditApplication"/><link name="creditApprovalToAskStock"/><link name="creditApprovalToReject"/><link name="invokeStock"/><link name="stockApprovalToReply"/><link name="stockApprovalToAskProviders"/><link name="invokeProviders"/><link name="invokeProvider1ToSetMessage"/><link name="invokeProvider2ToSetMessage"/><link name="setMessageToReply"/>

</links>…

</flow> n También consideraremos construir el flujo como una secuencia de

acciones que utilice flow para la invocación a los proveedores.

Recibir mensaje del cliente

n Recibimos el mensaje y activamos a las actividades que dependan del link receiveToPrepareCreditMessage.

<receive name="receiveOrder" partnerLink="customer"

portType=“orderdef:orderApprovalPT"

operation="approve" variable="request"

createInstance="yes">

<source linkName="receiveToPrepareCreditMessage"/>

</receive>

n Tal y como el nombre del link indica, lo siguiente es preparar el mensaje para invocar a la aplicación de crédito.

Invocando a la aplicación de crédito (1)

n Preparamos el mensaje:



<assign name="assignPrepareCreditMessage"><copy>

<from variable="request" part="client"/>

<to variable="creditRequest" part="requesterName"/>

</copy>

<target linkName="receiveToPrepareCreditMessage"/>

<source linkName="invokeCreditApplication"/>

</assign>

n Se copia el nombre del cliente desde el pedido del cliente a la petición a la aplicación de crédito.

n La actividad se ejecuta sólo al activarse el link receiveToPrepareCreditMessage (activado en el receive) -> ejecución secuencial.

n La actividad activa el link invokeCreditApplication.

Invocando a la aplicación de crédito (2)

n Invocamos a la aplicación de crédito:

<invoke name="invokeCreditApplication" partnerLink="creditapprover"

portType=“creditdef:creditApprovalPT"

operation="checkCredit"inputVariable="creditRequest"

outputVariable="creditResponse">

<target linkName="invokeCreditApplication"/>

<source linkName="creditApprovalToAskStock"

transitionCondition="bpws:getVariableData('creditResponse', 'accept')='yes'"/>

<source linkName="creditApprovalToReject" transitionCondition="bpws:getVariableData('creditResponse', 'accept')!='yes'"/></invoke>

Invocando a la aplicación de crédito (y 3)

n La actividad sólo se ejecuta al activarse el enlace invokeCreditApplication, que era activado una vez preparado el mensaje necesario para la invocación.

n Se utilizan ‘condiciones de transición’ en los enlaces fuente para implementar una estructura condicional:n Si la respuesta es ‘yes’, se activa

creditApprovalToAskStock (seguir con el flujo).n Si la respuesta es distinta, se activa

creditApprovalToReject (prepararse para denegar el pedido).

Rechazo por falta de crédito

n Si el cliente no tiene crédito, debe prepararse el mensaje de rechazo:



<assign name="assignNoCredit">

<target linkName="creditApprovalToReject"/>

<source linkName="setMessageToReply"/>

<copy><from expression="'no credit'"/>

<to variable="orderResponse" part="accept"/>

</copy>

</assign>

n Si se activa el enlace creditApprovalToReject, se prepara una respuesta con el texto ‘no credit’ y se activa el enlace setMessageToReply (que, como veremos más adelante, activa el envío de la respuesta al cliente).

Invocación al almacén (1)

n Se prepara el mensaje para la invocación:<assign name="assignPrepareStock"><target linkName="creditApprovalToAskStock"/><source linkName="invokeStock"/><copy><from variable="request" part="productName"/><to variable="stockRequest" part="productName"/>

</copy><copy><from variable="request" part="amount"/><to variable="stockRequest" part="amount”/>

</copy></assign>

n Nótese que no se puede usar directamente request como variable para el envío porque no son del mismo tipo.

n Los links juegan el papel habitual

Invocación al almacén (y 2)

n Se realiza la invocación:

<invoke name="invokeStock" partnerLink=“stock" portType=“stockdef:stockApprovalPT" operation=“checkStock" inputVariable="stockRequest" outputVariable="stockResponse">

<target linkName="invokeStock"/><source linkName="stockApprovalToReply"

transitionCondition="bpws:getVariableData('stockResponse', 'accept')='yes'"/><source linkName="stockApprovalToAskProviders"

transitionCondition="bpws:getVariableData('stockResponse', 'accept')!='yes'"/></invoke>

n Condiciones de transición:n Si hay existencias en almacén, nos prepararemos para

responder afirmativamente al pedido.n Si no, nos prepararemos para emitir pedido a proveedores.

Preparar respuesta con info almacén



<assign name="assignStock">

<copy><from expression="'yes'"/>

<to variable="orderResponse" part="accept"/>

</copy>

<copy>

<from expression="bpws:getVariableData(request,amount)* bpws:getVariableData(stockResponse,unitPrice)"/>

<to variable="orderResponse" part="price"/>

</copy>

<target linkName="stockApprovalToReply"/><source linkName="setMessageToReply"/>

</assign>

n El precio se calcula multiplicando el precio unitario por la cantidad.

n Se activa el enlace setMessageToReply, que desencadenará la respuesta.

Invocación a proveedores (1)

<assign name="assignProviders"><copy><from variable="request"/><to variable="requestProviders"/>

</copy><copy><from expression="'MyOrganizationName'"/><to variable="requestProviders" part="client"/>

</copy><target linkName="stockApprovalToAskProviders"/><source linkName="invokeProviders"/>

</assign>

n Se ejecuta sólo si se ha activado el enlace stockApprovalToAskProviders (no hay stock).

n Se copia el pedido inicial a la variable para la invocación y se cambia el nombre del cliente (que será el nombre de la propia organización).

Invocación a proveedores (2)

n Se invoca a ambos proveedores:

<invoke name="invokeProvider1"

partnerLink=“provider1" portType=“orderdef:orderApprovalPT"

operation="approve"

inputVariable="requestProviders"

outputVariable="provider1Response">

<target linkName="invokeProviders"/><source linkName="invokeProvider1ToSetMessage"/>

</invoke>

<invoke name="invokeProvider2"

partnerLink=“provider2" portType=“orderdef:orderApprovalPT"

operation="approve" inputVariable="requestProviders"

outputVariable="provider2Response">

<target linkName="invokeProviders"/>

<source linkName="invokeProvider2ToSetMessage"/>

</invoke>

Invocación a proveedores (y 3)

n La invocación a ambos proveedores depende del link invokeProviders. Por tanto, al activarse dicho link, ambas tareas se ejecutan en paralelo.

n Al terminar, cada invocación activa un link diferente: invokeProvider1ToSetMessage e invokeProvider2ToSetMessage.

n La siguiente actividad debe activarse sólo al activarse ambos links (es decir, una vez terminadas ambas invocaciones).

Escoger el precio mínimo (1)

<switchjoincondition="bpws:getLinkStatus('invokeProvider1ToSetMessage') and bpws:getLinkStatus('invokeProvider2ToSetMessage')">

<case condition=“(bpws:getVariableData(‘provider1Response’,’price’) < bpws:getVariableData(‘provider2Response’,’price')) and (bpws:getVariableData(‘provider1Response’,’accept’)=‘yes’)"><assign><copy>

<from variable="provider1Response"/><to variable="orderResponse"/>

</copy></assign>

</case>


n Esta actividad debe realizarse tras la activación de los dos links de salida desde las invocaciones a los proveedores.

n Para ello se usa una joinCondition en la definición de la actividad:n La función predefinida getLinkStatus permite acceder al

estado de un link.n Se especifica que la actividad debe empezar sólo si ambos

links están activos (por defecto, hubiese llegado con uno de ellos).

Escoger el precio mínimo (y 4)

n Se utiliza un switch para escoger el de menor precio. Si el precio del proveedor1 es menor que el del proveedor2 y además el proveedor1 aceptó el pedido, se copia como respuesta al cliente la respuesta del proveedor1 y, en caso contrario, la del proveedor 2.

n Se asume que si un proveedor no acepta el pedido, indicará accept=‘no’ y precio=0.n De esta forma, el comportamiento es correcto incluso si

ninguno de los dos proveedores tienen el producto.

Respuesta al cliente

n Finalmente, se responde al cliente.



<reply name="reply" partnerLink="customer" portType=“orderdef:orderApprovalPT"

operation="approve" variable="orderResponse">

<target linkName="setMessageToReply"/>

</reply>

n A esta actividad puede haberse llegado:n Si la aplicación de créditos denegó el pedido.n Si había existencias en stock.n Si no las había y hubo que invocar a los proveedores.

n En todos los casos, la variable orderResponsecontiene el valor correcto.

Links vs Actividades estructuradas (1)

n Hemos realizado el ejemplo utilizando links para controlar el flujo de ejecución de las actividades.n Links: Sigue el estilo de WSFL (IBM).

n Hay otro enfoque posible:n Actividades estructuradas: Sigue el estilo de

XLANG (Microsoft).

n BPEL4WS surge de la fusión de WSFL y XLANG, por lo que permite ambos enfoques y su combinación.

Ejemplo con Actividades Estructuradas (1)

n Básicamente, el ejemplo sigue el esquema de secuencia de actividades (sequence).

n Hay determinadas decisiones condicionales (switch).

n En la invocación a los proveedores, se produce la ejecución en paralelo de ambas peticiones (flow).

Ejemplo con actividades estructuradas (2)

<sequence><receive name=“receiveOrder”…></receive><assign name=“assignPrepareCreditMessage”>…</assign><invoke name=“invokeCreditApplication…></invoke><switch>

<case condition=“bpws:getVariableData('creditResponse', 'accept')='yes'”><sequence>

<assign name=“assignPrepareStock”>…</assign><invoke name=“invokeStock”…></invoke><switch>

<case condition=“bpws:getVariableData('stockResponse', 'accept')='yes'”>

<sequence><assign name=“assignStock”>…</assign>

Ejemplo con actividades estructuradas (3)

<reply name=“replyGoodsInStock”…></reply>

</sequence> </case><otherwise>

<sequence> <assign name=“assignProviders”>…</assign><flow>

<invoke name=“invokeProvider1”…></invoke><invoke name=“invokeProvider2”…></invoke>

</flow><switch name=“chooseBestPrice”>…</switch><reply name=“replyProviders”…></reply>

</sequence></otherwise>

</switch></sequence>

</case>

Ejemplo con actividades estructuradas (y 4)

<otherwise>

<sequence>

<assign name=“assignNoCredit”>

…

</assign>

<reply name=“replyNoCredit”…>

</reply>

</sequence>

</otherwise>

</switch>

</sequence>

Links vs Actividades estructuradas (2)

n Determinadas situaciones son modelables de forma más natural con un enfoque u otro. Por ejemplo:n Con actividades estructuradas, repetimos tres

veces la actividad reply.n A veces switch es más natural que condiciones de

transición (e.g. no siempre es fácil especificar una condición otherwise).

n Puede combinarse un enfoque con otro según convenga.

Links vs Actividades estructuradas (y 3)

n Ciertas situaciones complejas no pueden expresarse con actividades estructuradas y sí con links:n Se ejecutan en paralelo dos hilos de dos

actividades cada uno (la secuencia A1-A2 se ejecuta en paralelo a la secuencia B1-B2).

n Existen ciertas condiciones de sincronización entre actividades de un hilo y de otro. Por ejemplo: B2 no debe empezar hasta que haya terminado A1

Generación gráfica

n Editar a mano flujos complejos es un proceso largo y propenso a errores.

n Herramientas gráficas proporcionan un entorno visual dónde pueden crearse actividades y conectarlas a través de enlaces, formando un grafo.n Enfoque de enlaces se expresa mejor mediante este método

n Los atributos de las actividades pueden configurarse utilizando “vistas de propiedades” a las que puede accederse desde cada actividad.

n La herramienta se encarga de comprobar e impedir ciertos errores:n Asegurarse de que la primera actividad contenida en un proceso

es estructurada.n Avisar de atributos obligatorios sin valor.n … y un amplio etcétera.

6.2 orquestación de servicios web - tic.udc.esfbellas/teaching/adoo-2003-2004/tema6apart... ·...

Documents