BPEL - Business Process Execution Language

Estamos a entrar numa nova era, caracterizada pela separação da informação das aplicações, conduzindo a arquitecturas distribuídas orientadas a serviços. O significado, a função, os relacionamentos e a apresentação da informação são autodescritivos e incorporados na própria informação, através de vocabulários de esquemas e referências a folhas de estilo. A informação é gerada e publicada sem o conhecimento de como a mesma é consumida ou utilizada. Simultaneamente, as aplicações serão capazes de consumir a informação e os métodos de outras aplicações, assim como elas mesmas serem consumidas. Os processos serão autoconfiguráveis e automodificáveis, baseados nas interacções no nível de evento entre o conjunto de regras e a informação. Aplicações completamente novas, novos modelos de negócios, em que a informação irá definir a nossa experiência do mundo, irão envolver este paradigma.

Os processos de negócios no mundo real são complexos. Na maioria dos casos, incorporam o controlo de integridade, como suporte de transacções ACID, persistência de estados nas interacções de longo prazo, operações paralelas e em cadeia, mecanismos de compensação e excepções, confirmações de recebimento e capacidades de correlação.

O amadurecimento das tecnologias relacionadas com a descrição e execução de processos, e das tecnologias promotoras da interoperabilidade sobre a Internet, baseadas em XML, tem motivado o interesse crescente da comunidade científica pela área dos processos de negócio interorganizacionais. Esta área caracteriza-se pela descrição, execução e controlo de processos participados por diferentes organizações, e onde não existe um controle centralizado da sua execução.

Uma forma expedita de formalizar os processos interorganizacionais consiste na utilização de uma descrição global e única, contendo as actividades acordadas entre todos os participantes, unidas num único fluxo. É exemplo deste tipo de descrição a linguagem Business Process Execution Language, também designada por Business Process Execution Language for Web Services.

A Linguagem de execução de processos de negócios para Web Services, ou BPEL4WS, ou simplesmente BPEL, é uma linguagem de excelência para conseguir resolver os problemas associados ao crescente aumento da complexidade dos processos. O valor da capacidade de desenhar, implantar e documentar um comportamento altamente contingente e sofisticado, usando uma metodologia de construção visual, torna-se mais e mais clara. Este é especialmente o caso após um período de tempo, quando os processos necessitam de modificações ou o desenho do processo serve de base para outro.

A linguagem BPEL foi desenvolvida através da colaboração entre a Microsoft, IBM e BEA, e combina a XLANG e WSFL, as gerações anteriores de linguagens de processos criadas pela Microsoft e pela IBM, respectivamente. A função fundamental para a qual o BPEL foi criado está em orquestrar e coordenar os Web Services de forma que eles possam actuar no comportamento transaccional e colaborativo. A especificação BPEL foi enviada para o corpo de standards OASIS para revisão e eventual designação como um protocolo standard, a fim de ser disponibilizado e utilizado por qualquer pessoa.

O BPEL tornou-se um passo importante no desenvolvimento de aplicações numa área com processos de negócio flexíveis, com unidades distribuídas, independentes de plataforma. Esta especificação é uma linguagem baseada em XML que explicita a lógica do fluxo de processos de negócio através de um conjunto de actividades de um processo, e do controle de dependências entre essas actividades.

Na qualidade de linguagem standard de orquestração de Web Services, a linguagem BPEL irá exercer uma função fundamental na adopção das tecnologias de Web Services. Apesar dos Web Services fornecem a metodologia para mensagens de aplicação para aplicação, e a chamada de métodos através de redes sem fronteiras, não podem por si sós satisfazer os requisitos operacionais de um processo de negócios, que se comporta como um conjunto de actividades ordenadas e contingentes, cujo resultado da execução produzido é esperado e repetitivo no tempo.

A linguagem BPEL, quando implantada e suportada num ambiente de gestão de processos de negócios (BPM), permite que os Web Services alcancem este objectivo acima referido.

Imagem 1. Exemplo de modelação de um processo em BPEL.

BPEL e Web Services

Grande parte do esforço na construção dos Web Services tem como objectivo atingir a interoperabilidade universal entre aplicações, usando para isso standards web. De modo a permitir uma integração flexível entre sistemas heterogéneos numa grande variedade de domínios, incluindo o business-to-consumer, business-to-business and enterprise application integration. Foram definidas, no contexto dos Web Services, as seguintes especificações básicas:

• SOAP
• Web ServicesDescription Language (WSDL)
• Universal Description, Discovery, and Integration (UDDI)
  

O SOAP define o protocolo das mensagens xml usadas para um serviço básico de interoperabilidade. O WSDL introduz uma gramática comum para descrever os serviços disponibilizados. O UDDI garante a infra-estrutura necessária para publicar e descobrir serviços usando para tal a semântica. Em conjunto, estas especificações permitem que aplicações distintas se encontrem e interajam utilizando um modelo "loosely coupled" e independente da plataforma.

Imagem 2. BPEL4WS

A integração de sistemas requer mais do que a capacidade de conseguir interações simples utilisando protocolos standards. O verdadeiro potencial dos web services como plataforma de integração vai ser atingido apenas quando as aplicações e os processos de negócio forem capazes de integrar as suas interacções complexas usando um modelo de integração de processos standard.

O modelo de interacção que é directamente suportado pelo wsdl é essencialmente um modelo sem estado de interacções síncronas ou assíncronas sem ligação. Os modelos para a interacção de negócio assumem tipicamente sequências de trocas de mensagens ponto a ponto, tanto síncronas como assíncronas, com estado, interacções de longa duração entre dois ou mais intervenientes.

Para definir estas interacções entre componentes de negócio, é necessário existir uma descrição formal do protocolo de troca de mensagens entre si. A definição destes protocolos de negócio envolve precisamente a especificação das mensagens mutuamente visíveis e o comportamento na troca das mesmas para cada uma das partes envolvidas, sem impacto na sua implementação interna.

Existem duas boas razões para separar os aspectos públicos do comportamento dos componentes de negócio, dos aspectos internos para aspectos externos. Uma dessas razões prende-se com o facto dos componentes de negócio não pretenderem revelar as suas decisões e a gestão de dados aos seus parceiros de negócio. A outra razão tem a ver com o facto de que, mesmo quando a situação anterior não se coloca, a separação das partes privadas das públicas nos componentes de negócio, garante a liberdade de alterar a parte privada do processo sem afectar o protocolo público do negócio.

O BPEL4WS utiliza a noção das propriedades da mensagem para identificar os dados relevantes da mensagem embebidos no corpo da mesma. As propriedades podem ser vistas como dados "transparentes" relevantes para aspectos públicos, em contraste com os dados "opacos" que as funções internas ou privadas usam.

• Os dados transparentes afectam o protocolo de negócio público de uma forma directa;
• Os dados "opacos" são significantes principalmente para sistemas de backoffice e afectam o protocolo de negócio criando apenas aspectos não determinísticos, uma vez que a forma como afectam a decisão é opaca.
  

Podemos então salientar que todos os dados que são utilizados para influenciar o comportamento de um protocolo de negócio devem ser transparentes; logo, vistos como propriedades e que o efeito implícito de dados opacos manifesta-se através de aspectos não determinísticos no comportamento dos serviços envolvidos no protocolo.

O BPEL4WS permite explicitamente o uso de valores não determinísticos para que seja possível capturar a essência do comportamento público, enquanto que se escondem os aspectos privados.

Os aspectos básicos do BPEL4WS podem ser aplicados numa de duas formas:

• Um processo BPEL4WS pode definir uma regra do protocolo de negócio, usando para tal a noção do processo abstracto. Por exemplo, no protocolo de uma cadeia de fornecimento, o comprador e o fornecedor representam dois papeis distintos, cada um com o seu próprio processo abstracto. A sua relação é tipicamente modelada como um "partner lynk". Um processo abstracto usa todos os conceitos do BPEL4WS, mas faz um tratamento de dados de tal forma que reflecte o nível de abstracção necessário para descrever os aspectos públicos do protocolo de negócio. Mais concretamente, os processos abstractos tratam apenas de dados relevantes ao protocolo. O BPEL4WS disponibiliza uma forma de identificar dados relevantes ao protocolo, como propriedades da mensagem.
• O BPEL4WS pode ser usado para definir um processo de negócio executável. A lógica e o estado do processo determinam a natureza e a sequência das interacções dos Web Services, efectuadas em cada um dos parceiros de negócio, assim como os protocolos de interacção. Enquanto que uma definição de um processo BPEL4WS não precisa de ser completa do ponto de vista de uma implementação privada, a linguagem define efectivamente um formato de execução portável para processos de negócio que contam exclusivamente com os recursos dos Web Services e com ficheiros xml.
  

Mesmo quando os aspectos das implementações privadas usam funcionalidades dependentes da plataforma, o que acontece provavelmente na maioria dos casos, a continuidade do modelo conceptual básico entre processos abstractos e executáveis em BPEL4WS faz com que seja possível exportar e importar os aspectos públicos incorporados nos protocolos de negócio, como templates de processos, sendo mantida ao mesmo tempo a intenção e a estrutura dos protocolos. Este é, sem dúvida o aspecto mais atraente na utilização do BPEL4WS, do ponto de vista de desbloquear o potencial dos Web Services , uma vez que permite a construção de ferramentas e de outras tecnologias que aumentam em grande parte o nível de automatismo, baixando assim o custo inerente ao estabelecimento de processos de negócio extra-organizações.

O BPEL4WS define um modelo e uma gramática para descrever o comportamento de um processo de negócio com base em interacções entre os processos e os seus parceiros. A interacção com cada parceiro ganha forma através de Web Services. A estrutura de relação ao nível da interface é encapsulada no Partner Link. O processo BPEL2WS define como a interacção de múltiplos serviços com os seus parceiros é coordenadaspara atingir um objectivo de negócio.

O BPEL4WS está colocado no topo de várias especificações xml: WSDL 1.1, XML Schema 1.0, e XPath 1.0. As mensagens wsdl e as definições XML Schema disponibilizam o modelo de dados utilizado pelos processos BPEL4WS. O XPath disponibiliza suporte para a manipulação de dados. Todos os recursos externos e parceiros são representados como serviços WSDL. O BPEL4WS disponibiliza extensibilidade para acomodar versões futuras deste standard.

Imagem 3: Demonstração da Lógica de processos embebida.

BPEL e Java

A definição de processos de negócio com o BPEL são aplicações auto-suficientes que usam Web Services como actividades que implementam funções de negócio. O BPEL não tenta ser uma linguagem de programação comum. Em vez disso, assume um papel de combinação com outras linguagens de programação que são usadas para implementar funções de negócio.

Uma das combinações possíveis é combinar BPEL com Java. Esta junção de tecnologias permite construir aplicações completas de processos de negócio. Ao permitir que o BPEL e o Java trabalhem em conjunto, o BPELJ permite que cada uma das linguagens faça aquilo que faz melhor.

As tarefas mais apropriadas para serem tratadas no BPEL são:

• Descrever a lógica dos processos de negócio.
• Enviar mensagens para os Web Services.
• Aceitar uma mensagem, de um conjunto de mensagens passíveis de serem recebidas.
• Reencaminhar mensagens para a sua função correcta no processo correcto.
• Manter múltiplas execuções ininterruptas de processos.
• Definir um conjunto de actividades de deverão ocorrer numa determinada altura com uma determinada ordem.
  

As tarefas mais apropriadas para serem tratadas em Java são:

• Calcular um valor a ser colocado num documento.
• Construir um documento que vai ser enviado para um Web Service usando informação de outros documento e serviços.
• Retirar informação de um documento que seja recebido, valores, conversões, etc.
• Calcular um valor que vai ser usado para afectar a sequência de um processo.
• Efectuar acções sem ter que criar um Web Service.

Produzido em 2006