Articulo Prueba

BPEL
1. INTRODUCCION
Conceptos que se deben considerar para describir los procesos de negocio Los procesos de negocio que dependen del comportamiento de los datos. Por ejemplo,
una cadena de proceso de oferta depende de los datos tales como el número de
elementos que figuran en una orden, el valor total del pedido o la entrega del pedido. Para
definir la intensión del negocio se requiere el uso de condicionales y tiempos de espera.
 La capacidad de especificar las condiciones excepcionales y sus consecuencias, incluidas en
las secuencias de recuperación, es igual de importante para los procesos de negocio como
la capacidad para definir el comportamiento cuando todo va bien.
 Las interacciones de larga duración incluyen unidades múltiples, a menudo son unidades
de trabajo anidadas, cada uno con sus propios datos y requisitos. Para conocer el éxito o el
fracaso de estos procesos de negocio es necesario conocer los resultados de cada uno de
los procesos intervinientes.
Los conceptos básicos de WS-BPEL se pueden aplicar de dos maneras, Abstracto o
ejecutable
Un proceso abstracto, es un proceso parcialmente especificado que no está destinado a ser
ejecutado y que debe ser declara como abstracto. Se pueden ocultar algunos de los detalles
concretos del funcionamiento. Un proceso ejecutable es un proceso totalmente especificado.
Además de las funciones disponibles en los procesos ejecutables, los procesos abstractos
proporcionan 2 mecanismos para ocultar detalles de funcionamiento. (1) Uso explicito de tokens
ocultos y (2) La omisión.
Un proceso abstracto cumple una función descriptiva, con varios casos de uso. Un caso de uso
podría describir los comportamientos de algunos o todos los servicios ofrecidos por un proceso
ejecutable. Otro caso de uso podría definir una plantilla de procesos que incorporan las mejores
prácticas de un dominio específico. Esta plantilla captura la lógica del proceso que es compatible
con una representación de diseño, mientras que excluye los detalles de ejecución que serán
completados cuando se realice un mapeo del proceso ejecutable.
Independientemente del caso de uso y su propósito específico todos los procesos abstractos
comparten una base sintáctica común. Tienen diferentes requisitos según el nivel de opacidad y
restricciones en cada parte del proceso de definición según sea omitido u oculto.
Una base especifica común de las características que definen la sintaxis universal de los procesos
abstractos. Teniendo en cuenta esta base común un perfil de uso provee las especificaciones
necesarias y la semántica basada en WS-BPEL ejecutable para un uso partículas de un proceso
abstracto.
En importante recalcar que es posible utilizar WS-BPEL para definir un proceso ejecutable de
negocio. Mientras que un WS-BPEL Proceso abstracto no es requerido para definirlo
completamente, el lenguaje define un formato portátil para la definición del proceso que depende
exclusivamente de los servicios web y los datos xml.
La continuidad del modelo básico conceptual entre los procesos abstractos y los ejecutables in
WS-BPEL permite la exportación y la importación de los aspectos públicos contenidos en los
procesos abstractos como un proceso o una plantilla de roles mientras se mantiene la intensión y
la estructura del comportamiento observable. Esta es una característica clave para el uso de WSBPEL desde el punto de vista de liberar el potencial de los servicios web, ya que permite el
desarrollo de herramientas y tecnologías que aumentas en gran medida el nivel de automatización
y de ese modo reducir los costos en el establecimiento de procesos automatizados de negocio.
WS-BPEL define un modelo y una gramática para describir el comportamiento de un proceso de
negocio basado en las interacciones entre el proceso y sus socios. La interacción con cada socio
ocurren a través de las interfaces de los servicios web, y la estructura de la relación a nivel de
interface es encapsulada en lo que es llamado un partnerLink. El proceso WS-BPEL define cómo
las interacciones de múltiples servicios con estos socios se coordinan para lograr un objetivo de
negocio, así como el estado y la lógica necesaria para esta coordinación. WS-BPEL también
introduce mecanismos sistemáticos para tratar las excepciones de negocio y las fallas de
transformación. Por otra parte, WS-BPEL introduce un mecanismo para definir cómo las
actividades individuales o compuestas dentro de una unidad de trabajo han de ser compensadas
en caso de que se produzca excepciones o un cambio de socio solicitante.
Un proceso WS-BPEL es una definición reutilizable que se puede implementar de diferentes
maneras y en distintos escenarios, mientras que mantiene un comportamiento uniforma a nivel
de aplicación en todos ellos.
2. CONVENCIONES DE NOTACION




MUST: Esta palabra o los términos REQUIRED o SMALL significan que la definición es un
requerimiento absoluto de la especificación
MUST NO: Esta frase o la frase SMALL NOT significa que la definición es una prohibición
absoluta de la especificación
SHOULD: Esta palabra o el adjetivo RECOMMENDED significa que no pueden existir
razones validas en determinadas circunstancias para ignorar un item en particular. Las
consecuencias deben ser comprendidas y analizadas cuidadosamente antes de elegir un
camino diferente
SHOULD NOT: Esta frase o la frase NOT RECOMMENDED significa que pueden existir
razones validas en determinadas circunstancias cuando el comportamiento en particular
es aceptable o incluso útil, pero llena de consecuencias que deben ser entendidas.

MAY: Esta palabra o el adjetivo OPTIONAL significan que un ítem es verdaderamente
opcional. Un vendor o proveedor puede incluir el ítem porque un determinado mercado
lo requiere o porque cree que mejora un producto, mientras que otro proveedor puede
decidir no utilizarlo
Esta especificación usa una sintaxis informal que describe la gramática XML de los fragmentos XML
que siguen:






La sintaxis en presentada como una instancia XML, pero los valores indican los tipos de
datos en lugar de los valores.
La gramática en negrilla no se ha introducido anteriormente en el documento, o es de
interés particular de un ejemplo.
<--description--> es un marcador de posición para elementos de otro namespace (como ##
otras XSD)
Los caracteres que se añaden a otros elementos o atributos de la siguiente manera:
o ?0ó1
o * 0 ó mas
o + 1 ó mas
o “[“ and “]” son usados para indicar que contienen ítem que deben ser tratados
como un grupo con respecto a ?, * ó +
Los elementos y atributos que son separados por “|” y agrupados por (and) son
alternativas sintácticas
El XML namespaces prefixes es usado para indicar el namespace del elemento que será
definido.
Los ejemplos que comienzan con <?xml contienen suficiente información para cumplir con esta
especificación, otros ejemplos son fragmentos y requieren información adicional .
Ningún ejemplo o fragmento explicativo en este documento es totalmente especificado a menos
que se indique lo contrario.
Los esquemas XSD se proporcionan como una definición de las gramáticas.
Esta especificación usa un numero de namespace que se enumeran a continuación. La elección de
cualquiera es arbitraria, no normativa y no semánticamente significante:
 xsi - http://www.w3.org/2001/XMLSchema-instance
 xsd - http://www.w3.org/2001/XMLSchema
 wsdl - http://schemas.xmlsoap.org/wsdl/
 vprop - http://docs.oasis-open.org/wsbpel/2.0/varprop
 sref - http://docs.oasis-open.org/wsbpel/2.0/serviceref
 plnk - http://docs.oasis-open.org/wsbpel/2.0/plnktype
 bpel - http://docs.oasis-open.org/wsbpel/2.0/process/executable
 abstract - http://docs.oasis-open.org/wsbpel/2.0/process/abstract
3. RELACIONES CON OTRAS ESPECIFICACIONES
WSDL tiene la mayor influencia en el lenguaje WS-BPEL. El modelo de procesos WS-BPEL es la capa
superior del modelo de servicio definido por el WSDL 1.1. En el núcleo del modelo de proceso WSBPEL está la noción de “peer to peer” que es la interacción entre los servicios descritos en el
WSDL, tanto proceso como los socios (partners) se exponen como los servicios WSDL. Un proceso
de negocio define la forma de coordinar la interacción entre una instancia del proceso y sus
partners. En este sentido, una definición de procesos WS-BPEL proporciona y/o utiliza un o más
servicios WSDL y proporciona la descripción del comportamiento y las interacciones de una
instancia del proceso en relación con sus partners y recursos a través de interfaces del servicio
web. Es decir WS-BPEL se utiliza para describir el intercambio de mensajes seguido de los procesos
de negocio de un rol un la interacción.
La definición de los procesos WS-BPEL sigue el modelo WSDL de separación entre el contenido del
mensaje abstracto que se utiliza en el proceso de negocio y la información de la implementación
(tipos de mensaje, tipos de puerto versus binding e información de enlace). En particular un
proceso WS-BPEL representa a todos los socios y las interacciones con los socios en términos de la
interface WSDL abstracta (tipos de puertos y operaciones), no se hace referencia a los servicios
reales utilizados por una instancia del proceso.
La parte abstracta del WSDL no define las limitaciones impuestas por los patrones de
comunicación soportados por binding en concreto. Por lo tanto un WS-BPEL puede definir el
comportamiento relativo para un servicio socio que no es soportado por todos los posibles bindig,
y puede suceder que algunos bindigs no son validos para una definición de proceso WSDL.
Es importante tener en cuenta que es factible que la compatibilidad entre los WSDL y el WS-BPEL
no sea total, al menos para estos casos



Fallo de nombres con restricción
Sobrecarga de nombres de operación en los tipos de puerto WSDL
Tipos de puertos que contienen solicitud-respuesta o las operaciones de notificación.
4. ANALIS ESTATICO DE UN PROCESO DE NEGOCIO
WS-BPEL tomo como un principio general que las implementaciones DEBEN realizar un análisis
estático para detectar y rechazar las definiciones de proceso que fallen en este análisis.
Una implementación WS-BPEL puede realizar la comprobación de análisis estático extra más allá
del análisis básico estático requerido.
5. DEFINIR UN PROCESO DE NEGOCIO
Ejemplo inicial
Se describirá un ejemplo sencillo de un proceso WS-BPEL para el manejo de una orden de compra.
El objetivo realizar una introducción a las estructuras más básicas y algunos conceptos
fundamentales del lenguaje.
Las líneas punteadas representan la secuencia.
Las líneas continuas representan relaciones de control que se utilizan para la sincronización a
través de actividades concurrentes
Esta notación no pretende ser una notación grafica definitiva se utiliza de una manera informal
para una mejor comprensión.
Cuando se recibe una orden de compra de un cliente, el proceso se inicia al mismo tiempo por 3
caminos: El cálculo del precio final de la orden, selección de un cargador, y la programación de la
producción y el envió de la orden. Si bien algunos de los procesos se ejecutan al mismo tiempo,
hay dependencias de control y datos entre los 3 caminos. En particular, el precio de envío es
necesario para finalizar el cálculo del precio y la fecha de envío es necesaria para el programa de
cumplimiento total. Cual las 3 rutas simultaneas se han completado, se realiza el procesamiento
de la factura y está se puede enviar al cliente.
El tipo de puerto ofrecido por el servicio web a sus consumidores (clientes) se muestra en el
siguiente documento WSDL. Otras definiciones que son requeridas en el proceso de negocios se
incluyen en el mismo documento WSDL para simplificar los tipos de puertos para los servicios web
que proporcionan el cálculo de los precios, selección y programación de envío, y la programación
de las funciones de producción. Observe que no hay enlaces (binding) o elementos de servicio en
el documento WSDL. En un proceso WS-BPEL se definen por referencia solo los tipos de puertos
involucrados en el proceso y no sus implementaciones posibles. La definición de procesos de
negocio de esta manera permite la reutilización de la definición para procesos compatibles.
Los <partnerLinkType> incluidos en la parte inferior del documento WSDL representan la
interacción entre el servicio de la orden de compra y cada una de las partes con las que
interactúa. Los <partnerLinkType> se pueden usar para representar dependencias entre servicios,
independiente de que los procesos de negocio WS-BPEL sean definidos por uno o más servicios
web. Cada partnerLinkType define máximo 2 “role” name, y una lista de tipos de puerto (port
types) que cada role debe soportar para que la interacción se lleva a cabo con éxito.
Para este ejemplo se definen 4 partnerLinkType. Dos de ellos “purchasingLP y schedulingLP y sus
respectivos roles asociados. Para cada uno de ellos solo se asocio un único role. PurchasingLP
representa la conexión entre el proceso y la solicitud del cliente, donde solo el servicio de orden
de compra puede ofrecer la operación de servicio. ShedulingLP representa la interacción entre el
servicio de orden de compra y el servicio de programación, en los que las operaciones de este
último son invocadas. Los otros dos partnerLinkType “invoicingLT” y “shippinLT” son los
encargados de realizar las operaciones del cálculo de la factura y el servicio de envío cada uno
debe proporcionar la solicitud de la operación como la devolución de las notificaciones.
A continuación encontraremos el WSDL
<wsdl:definitions
targetNamespace="http://manufacturing.org/wsdl/purchase"
xmlns:sns="http://manufacturing.org/xsd/purchase"
xmlns:pos="http://manufacturing.org/wsdl/purchase"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xsd:schema>
<xsd:import namespace="http://manufacturing.org/xsd/purchase"
schemaLocation="http://manufacturing.org/xsd/purchase.xsd" />
</xsd:schema>
</wsdl:types>
<wsdl:message name="POMessage">
<wsdl:part name="customerInfo" type="sns:customerInfoType" />
<wsdl:part name="purchaseOrder" type="sns:purchaseOrderType" />
</wsdl:message>
<wsdl:message name="InvMessage">
<wsdl:part name="IVC" type="sns:InvoiceType" />
</wsdl:message>
<wsdl:message name="orderFaultType">
<wsdl:part name="problemInfo" element=”sns:OrderFault " />
</wsdl:message>
<wsdl:message name="shippingRequestMessage">
<wsdl:part name="customerInfo" element="sns:customerInfo" />
</wsdl:message>
<wsdl:message name="shippingInfoMessage">
<wsdl:part name="shippingInfo" element="sns:shippingInfo" />
</wsdl:message>
<wsdl:message name="scheduleMessage">
<wsdl:part name="schedule" element="sns:scheduleInfo" />
</wsdl:message>
<!-- portTypes supported by the purchase order process -->
<wsdl:portType name="purchaseOrderPT">
<wsdl:operation name="sendPurchaseOrder">
<wsdl:input message="pos:POMessage" />
<wsdl:output message="pos:InvMessage" />
<wsdl:fault name="cannotCompleteOrder"
message="pos:orderFaultType" />
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="invoiceCallbackPT">
<wsdl:operation name="sendInvoice">
<wsdl:input message="pos:InvMessage" />
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="shippingCallbackPT">
<wsdl:operation name="sendSchedule">
<wsdl:input message="pos:scheduleMessage" />
</wsdl:operation>
</wsdl:portType>
<!-- portType supported by the invoice services -->
<wsdl:portType name="computePricePT">
<wsdl:operation name="initiatePriceCalculation">
<wsdl:input message="pos:POMessage" />
</wsdl:operation>
<wsdl:operation name="sendShippingPrice">
<wsdl:input message="pos:shippingInfoMessage" />
</wsdl:operation>
</wsdl:portType>
<!-- portType supported by the shipping service -->
<wsdl:portType name="shippingPT">
<wsdl:operation name="requestShipping">
<wsdl:input message="pos:shippingRequestMessage" />
<wsdl:output message="pos:shippingInfoMessage" />
<wsdl:fault name="cannotCompleteOrder"
message="pos:orderFaultType" />
</wsdl:operation>
</wsdl:portType>
<!-- portType supported by the production scheduling process -->
<wsdl:portType name="schedulingPT">
<wsdl:operation name="requestProductionScheduling">
<wsdl:input message="pos:POMessage" />
</wsdl:operation>
<wsdl:operation name="sendShippingSchedule">
<wsdl:input message="pos:scheduleMessage" />
</wsdl:operation>
</wsdl:portType>
<plnk:partnerLinkType name="purchasingLT">
<plnk:role name="purchaseService"
portType="pos:purchaseOrderPT" />
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT">
<plnk:role name="invoiceService"
portType="pos:computePricePT" />
<plnk:role name="invoiceRequester"
portType="pos:invoiceCallbackPT" />
</plnk:partnerLinkType>
<plnk:partnerLinkType name="shippingLT">
<plnk:role name="shippingService"
portType="pos:shippingPT" />
<plnk:role name="shippingRequester"
portType="pos:shippingCallbackPT" />
</plnk:partnerLinkType>
<plnk:partnerLinkType name="schedulingLT">
<plnk:role name="schedulingService"
portType="pos:schedulingPT" />
</plnk:partnerLinkType>
</wsdl:definitions>
A continuación se definirá el proceso de negocio para la orden de servicio. Hay cuatro secciones
principales en la definición de este proceso. Se debe tener en cuenta que el ejemplo que estamos
tratando es un ejemplo simple. Con el fin de completarlo, los elementos adicionales que pueden
ser necesarios se definen como <correlationSets>




La sección <partnerLinks> define las diferentes partes que interactúan con los procesos en
el curso del procesamiento de la orden. Las 4 definiciones de <partnerLinks> que se
muestran aquí corresponden al remitente de la orden (customer), los proveedores de
precio (invoicing provider) , los proveedores de transporte (shipping provider) y los
servicios de programación de fabricación (scheduling provider). Cada <partnerLink> se
caracteriza por un <partnerLinkType> y/o uno o dos role names. Esta información
identifica la funcionalidad que es proporcionada por el proceso de negocio y por los
partner service para que la relación tenga éxito, esto es, los port types que el proceso de
orden de servicio y los partner necesitan para la implemantacion.
La sección <varables> define los datos variables que son usados por el proceso,
proporcionando sus definiciones en términos de tipos de mensaje WSDL, XML Schema
Types (simple or complex) o los XML Scheme elements
La sección <faultHandlers> contiene los controladores de error definiendo las actividades
que se deben realizar en respuesta a los fallos derivados de la invocación de los servicios
de evaluación y aprobación. En WS-BPEL, todos los defectos, sean internos o como
resultado de la invocación de un servicio, son identificados con un nombre completo. En
general cada fallo WSDL se identifica en WS-BPEL por un nombre completo formado por el
namespace del documento WSDL en que el port type y el tipo de falla son definidos y un
NCName de la falla.
El resto de los <process> contiene la descripción del comportamiento normal para el
manejo de la solicitud de compra. Los principales elementos de esta descripción son
explicados en la sección a continuación , la definición del proceso
<process name="purchaseOrderProcess"
targetNamespace="http://example.com/ws-bp/purchase"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:lns="http://manufacturing.org/wsdl/purchase">
<documentation xml:lang="EN">
A simple example of a WS-BPEL process for handling a purchase
order.
</documentation>
<partnerLinks>
<partnerLink name="purchasing"
partnerLinkType="lns:purchasingLT" myRole="purchaseService" />
<partnerLink name="invoicing" partnerLinkType="lns:invoicingLT"
myRole="invoiceRequester" partnerRole="invoiceService" />
<partnerLink name="shipping" partnerLinkType="lns:shippingLT"
myRole="shippingRequester" partnerRole="shippingService" />
<partnerLink name="scheduling"
partnerLinkType="lns:schedulingLT"
partnerRole="schedulingService" />
</partnerLinks>
<variables>
<variable name="PO" messageType="lns:POMessage" />
<variable name="Invoice" messageType="lns:InvMessage" />
<variable name="shippingRequest"
messageType="lns:shippingRequestMessage" />
<variable name="shippingInfo"
messageType="lns:shippingInfoMessage" />
<variable name="shippingSchedule"
messageType="lns:scheduleMessage" />
</variables>
<faultHandlers>
<catch faultName="lns:cannotCompleteOrder"
faultVariable="POFault"
faultMessageType="lns:orderFaultType">
<reply partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder" variable="POFault"
faultName="cannotCompleteOrder" />
</catch>
</faultHandlers>
<sequence>
<receive partnerLink="purchasing" portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder" variable="PO"
createInstance="yes">
<documentation>Receive Purchase Order</documentation>
</receive>
<flow>
<documentation>
A parallel flow to handle shipping, invoicing and
scheduling
</documentation>
<links>
<link name="ship-to-invoice" />
<link name="ship-to-scheduling" />
</links>
<sequence>
<assign>
<copy>
<from>$PO.customerInfo</from>
<to>$shippingRequest.customerInfo</to>
</copy>
</assign>
<invoke partnerLink="shipping" portType="lns:shippingPT"
operation="requestShipping"
inputVariable="shippingRequest"
outputVariable="shippingInfo">
<documentation>Decide On Shipper</documentation>
<sources>
<source linkName="ship-to-invoice" />
</sources>
</invoke>
<receive partnerLink="shipping"
portType="lns:shippingCallbackPT"
operation="sendSchedule" variable="shippingSchedule">
<documentation>Arrange Logistics</documentation>
<sources>
<source linkName="ship-to-scheduling" />
</sources>
</receive>
</sequence>
<sequence>
<invoke partnerLink="invoicing"
portType="lns:computePricePT"
operation="initiatePriceCalculation"
inputVariable="PO">
<documentation>
Initial Price Calculation
</documentation>
</invoke>
<invoke partnerLink="invoicing"
portType="lns:computePricePT"
operation="sendShippingPrice"
inputVariable="shippingInfo">
<documentation>
Complete Price Calculation
</documentation>
<targets>
<target linkName="ship-to-invoice" />
</targets>
</invoke>
<receive partnerLink="invoicing"
portType="lns:invoiceCallbackPT"
operation="sendInvoice" variable="Invoice" />
</sequence>
<sequence>
<invoke partnerLink="scheduling"
portType="lns:schedulingPT"
operation="requestProductionScheduling"
inputVariable="PO">
<documentation>
Initiate Production Scheduling
</documentation>
</invoke>
<invoke partnerLink="scheduling"
portType="lns:schedulingPT"
operation="sendShippingSchedule"
inputVariable="shippingSchedule">
<documentation>
Complete Production Scheduling
</documentation>
<targets>
<target linkName="ship-to-scheduling" />
</targets>
</invoke>
</sequence>
</flow>
<reply partnerLink="purchasing" portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder" variable="Invoice">
<documentation>Invoice Processing</documentation>
</reply>
</sequence>
</process>
Estructura de un proceso de negocio
Estructura Básica
<process name="NCName" targetNamespace="anyURI"
queryLanguage="anyURI"?
expressionLanguage="anyURI"?
suppressJoinFailure="yes|no"?
exitOnStandardFault="yes|no"?
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">
<extensions>?
<extension namespace="anyURI" mustUnderstand="yes|no" />+
</extensions>
<import namespace="anyURI"?
location="anyURI"?
importType="anyURI" />*
<partnerLinks>?
<!-- Note: At least one role must be specified. -->
<partnerLink name="NCName"
partnerLinkType="QName"
myRole="NCName"?
partnerRole="NCName"?
initializePartnerRole="yes|no"?>+
</partnerLink>
</partnerLinks>
<messageExchanges>?
<messageExchange name="NCName" />+
</messageExchanges>
<variables>?
<variable name="BPELVariableName"
messageType="QName"?
type="QName"?
element="QName"?>+
from-spec?
</variable>
</variables>
<correlationSets>?
<correlationSet name="NCName" properties="QName-list" />+
</correlationSets>
<faultHandlers>?
<!-- Note: There must be at least one faultHandler -->
<catch faultName="QName"?
faultVariable="BPELVariableName"?
( faultMessageType="QName" | faultElement="QName" )? >*
activity
</catch>
<catchAll>?
activity
</catchAll>
</faultHandlers>
<eventHandlers>?
<!-- Note: There must be at least one onEvent or onAlarm. -->
<onEvent partnerLink="NCName"
portType="QName"?
operation="NCName"
( messageType="QName" | element="QName" )?
variable="BPELVariableName"?
messageExchange="NCName"?>*
<correlations>?
<correlation set="NCName" initiate="yes|join|no"? />+
</correlations>
<fromParts>?
<fromPart part="NCName" toVariable="BPELVariableName" />+
</fromParts>
<scope ...>...</scope>
</onEvent>
<onAlarm>*
<!-- Note: There must be at least one expression. -->
(
<for expressionLanguage="anyURI"?>duration-expr</for>
|
<until expressionLanguage="anyURI"?>deadline-expr</until>
)?
<repeatEvery expressionLanguage="anyURI"?>
duration-expr
</repeatEvery>?
<scope ...>...</scope>
</onAlarm>
</eventHandlers>
activity
</process>
Los atributos del nivel superior son:

queryLanguage: Este atributo especifica el lenguaje de consulta utilizado en el proceso de
selección de nodos de asignación. El valor por defecto de este atributo es:
“urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0” lo que representa que se usa [XPath
1.0] de WS-BPEL 2.0

expressionLanguage: Este atributo especifica el lenguaje usado en el <process>. El valor
por defecto de este atributo es: “urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0” lo que
representa que se usa [XPath 1.0] de WS-BPEL 2.0

La sintaxis del proceso abstracto tiene su propio y distinto espacio de nombres
(namespace). Adicionalmente los atributos de nivel superior son definidos para los
procesos abstractos.
El valor de los atributos queryLanguage y expressionLanguage en el elemento <process> son
globales y por defecto se pueden reemplazar en construcciones específicas, tales como
<condition> de una actividad <while>, tal como se define más adelante en este pliego de
condiciones. Además, el atributo queryLanguage también está disponible para su uso en la
definición de WS-BPEL <vprop:propertyAlias> en el WSDL. Los procesos WS-BPEL debé:


Determinar estáticamente que lenguajes son referencia para el quryLanguage o que
atributos expressionLanguage para cada uno de los procesos WS-BPEL definidos para sí
mismo o si no hay ninguna definición propiedad WS-BPEL en el WSDL asociado.
Si cualquier lenguaje de referencia no es soportado por el procesador de WS-BPEL, el WSBPEL DEBE rechazar la definición del proceso WS-BPEL.
Cada proceso de negocio tiene una actividad principal.
Una actividad WS-BPEL puede ser cualquiera de los siguientes:











<receive>
<reply>
<invoke>
<assign>
<throw>
<Salir>
<wait>
<empty>
<sequence>
<if>
<while>










<repeatUntil>
<forEach>
<pick>
<flow>
<scope>
<compensate>
<compensateScope>
<rethrow>
<validate>
<extensionActivity>
La sintaxis de cada uno de estos elementos será descrita a continuación.
<receive> Permite que el proceso de negocio espere para un matching mensaje de llegada. Esta
actividad se completa cuando el mensaje llega. El portType es un atributo opcional. Si el atributo
portType se incluye para facilitar la lectura. El valor del atributo portType DEBE coincidir con la
combinación de partnertLinks especificados y el role especificado implícitamente en la actividad.EL
atributo messageExchange es opcional y es usado para asociar <reply> de la actividad con el
<receive> de la actividad.
<receive partnerLink="NCName"
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
createInstance="yes|no"?
messageExchange="NCName"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="NCName" initiate="yes|join|no"? />+
</correlations>
<fromParts>?
<fromPart part="NCName" toVariable="BPELVariableName" />+
</fromParts>
</receive>
<reply> permite al proceso de negocios enviar un mensaje en respuesta a un mensaje que fue
recibido por una actividad de mensajes entrantes (IMA) es decir <receive>, <onMessage> o
<onEvent>. La combinación de una IMA y un <reply> forma una operación de petición-respuesta
en un portType WSDL para el proceso. El atributo portType en el <reply> en una actividad es
opcional El valor del atributo portType DEBE coincidir con la combinación de partnertLinks
especificados y el role especificado implícitamente en la actividad. EL atributo messageExchange
es opcional y es usado para asociar <reply> de la actividad con un IMA.
<reply partnerLink="NCName"
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
faultName="QName"?
messageExchange="NCName"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="NCName" initiate="yes|join|no"? />+
</correlations>
<toParts>?
<toPart part="NCName" fromVariable="BPELVariableName" />+
</toParts>
</reply>
<invoke> Permite que el proceso de negocio pueda invocar en un sentido una request-response
de un portType ofrecida por un socio. En el caso de request-response, la actividad de invocación se
completa cuando se recibe la respuesta. El atributo portType es opcional.
<invoke partnerLink="NCName"
portType="QName"?
operation="NCName"
inputVariable="BPELVariableName"?
outputVariable="BPELVariableName"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="NCName" initiate="yes|join|no"?
pattern="request|response|request-response"? />+
</correlations>
<catch faultName="QName"?
faultVariable="BPELVariableName"?
faultMessageType="QName"?
faultElement="QName"?>*
activity
</catch>
<catchAll>?
activity
</catchAll>
<compensationHandler>?
activity
</compensationHandler>
<toParts>?
<toPart part="NCName" fromVariable="BPELVariableName" />+
</toParts>
<fromParts>?
<fromPart part="NCName" toVariable="BPELVariableName" />+
</fromParts>
</invoke>
<assign> se utiliza para actualizar los valores de las variables con nuevos datos. La construcción de
un <assign> puede tener cualquier número de tareas elementales, tales como <copy>, asignación
de elementos o actualización de los datos de operaciones.
<assign validate="yes|no"? standard-attributes>
standard-elements
(
<copy keepSrcElementName="yes|no"? ignoreMissingFromData="yes|no"?>
from-spec
to-spec
</copy>
|
<extensionAssignOperation>
assign-element-of-other-namespace
</extensionAssignOperation>
)+
</assign>
<valídate> se utiliza para validar los valores de una variable contra los asociados en la definición
de datos SML y WSDL.
<validate variables="BPELVariableNames" standard-attributes>
standard-elements
</validate>
<throw> es usado para generar un fallo desde el interior del proceso de negocio.
<throw faultName="QName"
faultVariable="BPELVariableName"?
standard-attributes>
standard-elements
</throw>
<wait> se utiliza para esperar un determinado periodo de tiempo o hasta que un momento
determinado se haya alcanzado.
<wait standard-attributes>
standard-elements
(
<for expressionLanguage="anyURI"?>duration-expr</for>
|
<until expressionLanguage="anyURI"?>deadline-expr</until>
)
</wait>
<empty> es una acividad “no-op” en un proceso de negocio. Es útil para la sincronización de
actividades simultáneas.
<empty standard-attributes>
standard-elements
</empty>
<sequence> Se utiliza para definir un conjunto de actividades que se realizaran secuencialmente
en un orden léxico.
<sequence standard-attributes>
standard-elements
activity+
</sequence>
<if> Se utiliza para seleccionar exactamente una actividad para la ejecución de un conjunto de
opciones.
<if standard-attributes>
standard-elements
<condition expressionLanguage="anyURI"?>bool-expr</condition>
activity
<elseif>*
<condition expressionLanguage="anyURI"?>bool-expr</condition>
activity
</elseif>
<else>?
activity
</else>
</if>
<while> Se utiliza para definir que una actividad que se va a repetir hasta que una <condition> se
haga verdadera.
<while standard-attributes>
standard-elements
<condition expressionLanguage="anyURI"?>bool-expr</condition>
activity
</while>
<repeatUntil> se utiliza para definir que la actividad se va a repetir hasta que la <condiction> se
haga realidad. La <condiction> se prueba después de que la actividad secundaria se completa. Una
<repeatUntil> se utiliza para ejecutar al menos una vez la actividad secundaria.
<repeatUntil standard-attributes>
standard-elements
activity
<condition expressionLanguage="anyURI"?>bool-expr</condition>
</repeatUntil>
<forEach> Itera una actividad secundaria exactamente N+1 veces, donde N es igual a la
<finalCounterValue>. Si parallel = yes entonces esto es un <foreEch> paralelo donde N+1
instancias <scope> actividades que se deben realizar en paralelo. Un flujo se crea
dinámicamente con N+1 <scope> actividades secundarias. Un <completionCondiction> se
utiliza dentro de un <forEach> para permitir que una actividad se complete sin ejecutar o
terminar las ramas mencionadas.
<forEach counterName="BPELVariableName" parallel="yes|no"
standard-attributes>
standard-elements
<startCounterValue expressionLanguage="anyURI"?>
unsigned-integer-expression
</startCounterValue>
<finalCounterValue expressionLanguage="anyURI"?>
unsigned-integer-expression
</finalCounterValue>
<completionCondition>?
<branches expressionLanguage="anyURI"?
successfulBranchesOnly="yes|no"?>?
unsigned-integer-expression
</branches>
</completionCondition>
<scope ...>...</scope>
</forEach>
<pick> Se utiliza para esperar por uno o varios posibles mensajes lleguen o por un tiempo
de espera. Cuando alguno de estos disparadores se produce se ejecuta la actividad
secundaria. Cuando la actividad secundaria se completa, la actividad <pick> termina.
El atributo portType en la actividad <onMessage> es opcional. El atributo
<messageExchange> se utiliza para asociar un <reply> con un evento <onMessage>
<pick createInstance="yes|no"? standard-attributes>
standard-elements
<onMessage partnerLink="NCName"
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
messageExchange="NCName"?>+
<correlations>?
<correlation set="NCName" initiate="yes|join|no"? />+
</correlations>
<fromParts>?
<fromPart part="NCName" toVariable="BPELVariableName" />+
</fromParts>
activity
</onMessage>
<onAlarm>*
(
<for expressionLanguage="anyURI"?>duration-expr</for>
|
<until expressionLanguage="anyURI"?>deadline-expr</until>
)
activity
</onAlarm>
</pick>
<flow> Es una actividad que se utiliza para describir una a más actividades que se ejecutan
al mismo tiempo. <link> se especifican para definir el control de las dependencias
explicitas entre las actividades anidadas secundarias.
<flow standard-attributes>
standard-elements
<links>?
<link name="NCName" />+
</links>
activity+
</flow>
<scope> Es una actividad que se utiliza una actividad anidada con sus propios asociados
<partnerLinks>, <messageExchange>, <variables>, <correlationSets>, zfaultHandlers>,
<compensationHandlers>, <terminationHandlers> y <eventHandlers>.
<scope isolated="yes|no"?
standard-attributes>
standard-elements
<partnerLinks>?
... see above under
</partnerLinks>
<messageExchanges>?
... see above under
</messageExchanges>
<variables>?
... see above under
</variables>
<correlationSets>?
... see above under
</correlationSets>
<faultHandlers>?
... see above under
</faultHandlers>
<compensationHandler>?
...
</compensationHandler>
<terminationHandler>?
...
</terminationHandler>
<eventHandlers>?
... see above under
</eventHandlers>
activity
</scope>
exitOnStandardFault="yes|no"?
<process> for syntax ...
<process> for syntax ...
<process> for syntax ...
<process> for syntax ...
<process> for syntax ...
<process> for syntax ...
<compensateScope> Esta actividad se utiliza para comenzar una compensación en un
ámbito interior especificado que ya se ha completado con éxito. Esta actividad solo DEBE
ser utilizada dentro de un faulHandler o de otro controlador de compensación
(compensationHandler) o un controlador de terminación (terminationHandler)
<compensateScope target="NCName" standard-attributes>
standard-elements
</compensateScope>
<compesate> Esta actividad se utiliza para iniciar una compensación en todos los scopes
internos que se hayan completado con éxito, en el orden predeterminado. Esta actividad
DEBE ser utilizada dentro de un faultHandler o en compesationHandler o en un
terminationHandler.
<compensate standard-attributes>
standard-elements
</compensate>
<exit> Esta actividad se utiliza para poner fin de inmediato a una instancia de un proceso
de negocio.
<exit standard-attributes>
standard-elements
</exit>
<rethrow> Esta actividad de utiliza para volver a lanzar una falta que fue originalmente
capturada inmediatamente al cerrar faultHandler
<rethrow standard-attributes>
standard-elements
</rethrow>
<extensionActivity> se utiliza para extender WS-BPEL mediante la introducción de un
nuevo tipo de actividad. El contenido de un <extensionActivity> DEBE ser un solo
elemento que DEBE poner a disposición de WS-BPEL elementos estándar y atributos
estándar.
<extensionActivity>
<anyElementQName standard-attributes>
standard-elements
</anyElementQName>
</extensionActivity>
Los atributos estándar mencionados anteriormente son los siguientes
name="NCName"? suppressJoinFailure="yes|no"?
donde los valores por defecto son los siguientes:


Nombre: Sin valor por defecto (sin nombre)
suppressJoinFailure: Cuando este atributo no se especifica para una actividad,
hereda su valor desde su actividad cerrada más cercana o desde el proceso no
cerrado si la actividad no cerrada especifica este proceso.
Los elementos estándar mencionados anteriormente son los siguientes:
<targets>?
<joinCondition expressionLanguage="anyURI"?>?
bool-expr
</joinCondition>
<target linkName="NCName" />+
</targets>
<sources>?
<source linkName="NCName">+
<transitionCondition expressionLanguage="anyURI"?>?
bool-expr
</transitionCondition>
</source>
</sources>
Idioma de extensibilidad
WS-BPEL soporta la extensibilidad, permitiendo los atributos namespace-qualified aparezcan en
cualquier elemento del WS-BPEL y permitir que elementos de otros namespaces aparezcan dentro
de los elementos definidos en el WS-BPEL.
Existen extensiones obligatorias u opcionales. En caso de extensiones obligatorias no soportadas
por la implementación WS-BPEL, la de definición del proceso debe ser rechazada. Las extensiones
opcionales no son compatibles con una implementación WS-BPEL y deberán ser ignoradas.
WS-BPEL proporciona dos explicit
<extensionActivity>
extension construct:
<extensionAssignOperation> y
Las extensiones son permitidas en WS-BPEL construidas utilizando definiciones WSDL, como
<partnerLink>, <role>, <vprop:property> y <vprop:propertAlias>.
Documento de Vinculación (Document Linking)
Un proceso de deficion WS-BPEL se basa en XML Schemas y WSDL para la definición de tipos de
datos e interfaces de servicio. La definición de procesos se basan también en otras construcciones
tales como partner link types, variable properties y property aliases.
<import namespace="anyURI"?
location="anyURI"?
importType="anyURI" />*
El Elemento <import> se utiliza en un proceso WS-BPEL para declara la dependencia en XML
Schemas o definiciones WSDL. Cualquier numero de elementos <import> pueden aparecer como
elementos hijos <import>. Cada elemento <import> contiene uno o dos atributos opcionales.



Namespace: Este atributo especifica una URL absoluta que identifica las definiciones
importadas. Este atributo es opcional. Un elemento importado sin un atributo namespace
indica que las definiciones externas que son usadas no son de namespace calificado. Si un
namespace se especifica las definiciones importadas DEBEN estar en el namespace. Si no
se especifica ningún namespace, las definiciones importadas no deben contener una
especificación targetNamespace. SI cualquiera de estas reglas no se cumplen entonces la
definición del proceso DEBE
ser rechazada por el WS-BPEL.
El namespace
http://www.w3.org/2001/XMLSchema es importado implícitamente.
Location: El atributo location contiene una URL que indica la ubicación de un documento
que contiene las definiciones pertinentes. La URL location puede ser una URL relativa.
Location es un atributo opcional. Un elemento <import> sin un atributo location indican
que las definiciones externas son usadas por el proceso pero no hace ninguna declaración
acerca de las definiciones que puede encontrar.
importType: Este atributo es obligatorio e identifica el tipo de documento que se importa
al proporcionar una URL absoluta que identifica el lenguaje de codificación usado en el
documento.
Observe que de acuerdo a estas normas, es permitido tener un elemento <import> sin el
namespace y el atributo location , y solo debe contener un atributo importType.
Un proceso de definición WS-BPEL DEBE importar todo los XML Schemas y las definiciones WSDL
que utiliza. Un procesador WS-BPEL deberá verificar que todos las partes de mensajes referencian
un <vprop:propertyAlias>, <from>, <to>, <fromPart> y <toPart>. Un proceo WS-BPEL puede incluir
más de una declaración de importación del mismo namespace y un importType, siempre y cuando
estas declaraciones sean ubicadas en diferentes valores. Un WS-BPEL DEBE rechazar si los
documentos importados contienen conflictos de los componentes usados en la definición del
proceso de importación.
Ciclo de vida de un proceso de negocio ejecutable.
Como se nota en la introducción, el modelo de interacción que es directamente soportado con
WSDL es esencialmente un modelo cliente-servidor de request-response. WS-BPEL se basa en
WSDL con el supuesto que todas las interacciones externas del proceso de negocio ocurren a
través del las operaciones Web Service. Sin embargo, un proceso de negocio WS-BPEL representa
las interacciones de larga duración en la que cada interacción tiene un comienzo, una definición
de comportamiento durante su tiempo de vida y un final.
La creación de una instancia de un proceso WS-BPEL es siempre implícita, las actividades que
reciben los mensajes (<receive>, <pick>) pueden ser anotadas para indicar que la actividad
provoca una nueva instancia del proceso de negocio que se creara. Esto es posible mediante lel
establecimiento del atributo createInstance de esa actividad en “si”. Cuando un mensaje es
recibido por dicha actividad, una instancia del proceso es creada si esta no existe ya.
Si mas de una actividad de inicio existe en un proceso y estas actividades contienen <correlations>
entonces tolas las actividades DEBEN compartir al menos un <correlation> común.
Si un proceso contiene exactamente una actividad de inicio entonces el uso de <correlationSets>
no tiene restricciones. Esto incluye una sección con múltiples <onMessage>.
Una instancia de proceso de negocio termina ya sea de forma normal o anormal. El proceso
termina normalmente cuando la actividad principal y todas las instancias event handlers del proso
están completas sin presentar ningún error.