Linguagens

A composição de workflows é um passo importante através do qual usuários especificam as tarefas e suas dependências, seja de maneira concreta ou abstrata, de forma a repre- sentar a análise desejada. São várias as maneiras de representar as tarefas e como estão relacionadas. Em alguns casos o workflow contém tanto as etapas de computação como os dados usados por elas. Em outros casos a composição é feita em duas fases, onde a primeira descreve o modelo de processamento e em uma segunda fase é descrito o mo- delo de dados [212]. A escolha ou definição de uma linguagem para que o usuário possa descrever os workflows é fundamental. A linguagem deve descrever o processo de negócio e expor claramente as regras e procedimentos que devem ser respeitados. A seguir são apresentadas algumas linguagens propostas para workflow.

• GSFL: Grid Services Flow Language é uma linguagem baseada em XML que per-

mite descrever workflows envolvendo serviços em grades OGSA [213]. Sua arquite- tura é composta por um conjunto de modelos, cujos mais significativos são:

Modelo de provedores de serviços: contém a lista de serviços que fazem parte

do workflow. Especifica os provedores do serviço, indicados através do nome, tipo e o localizador (que pode ser estático, fábrica ou registro).

Modelo de atividade: especifica as atividades a serem executadas, indicando o

nome e a referência para a operação que implementa a atividade (serviço, o portType e a operação).

Modelo de Composição: descreve a composição dos serviços participantes. Des-

creve o fluxo de controle e de dados entre as operações dos serviços. É dividido nos modelos Export (define as atividade que expõem operações) e Notification (define a comunicação direta entre os serviços).

Modelo de ciclo de vida: define o ciclo de vida dos serviços e das atividades do

workflow. Ordena os serviços como um DAG usando links de precedência, e também ordena as atividades através de links de precedência.

GSFL claramente usa WS-BPEL como base e incorpora diretivas para atender aos requisitos das grades, como por exemplo, o localizador indicar o serviço como fábrica.

• JSDL: Job Submission Description Language é uma especificação do OGF [46] para descrever os requerimentos de uma tarefa computacional para submissões em recursos das grades [214]. Em JSDL os documentos são descritos em XML e tem seus marcadores (elementos) definidos conforme um “XML Schema”. Esses documentos são organizados da seguinte forma: JobDefinition é o elemento raiz e que contém um filho obrigatório chamado JobDescription onde estão os elementos que descrevem a tarefa. Esses elementos são JobIdentification, Application, Resource e DataStaging. A JSDL foi projetada para descrever a submissão de uma tarefa individual a ser exe- cutada em um recurso. Ela pode ser usada como parte integrante de uma linguagem de workflow que envolve, não só a submissão de tarefas, mas também as dependên- cias entre elas. Além disso, workflows estão envolvidos com outras atividades como tratamento de falhas e monitoramento da execução. JSDL não é apropriada para descrições de workflow.

• Karajan: parte integrante do Java CoG Kit [215], é um framework composto de

uma linguagem e um motor de workflow. A linguagem projetada oferece duas pos- sibilidades de uso. Uma possibilidade é usar uma sintaxe baseada em XML, com origem no GridAnt [216], com facilidades como estruturas de controle. Outra opção é usar uma sintaxe simplificada para gerar scripts, limitada mas que oferece um mecanismo para prototipação ágil. Uma opção pode ser convertida na outra. A lin- guagem provê primitivas para seqüências genéricas, execuções paralelas, execuções condicionais, variáveis e suporta tipos de dados comuns. Tem alguns recursos dife- renciados que foram criados para atender a requisitos do ambiente. Esses recursos são:

Providers: é um marcador (tag) que permite abstrair o middleware onde está o recurso a ser usado na execução. O programador não necessita levar em conta as particularidades no uso dos recursos. É uma facilidade importante.

Element: permite a definição de novos elementos na linguagem. É semelhante à definição de funções em linguagens procedurais.

Task: é uma abstração que permite fácil adaptação aos diversos protocolos do middleware. Três marcadores podem ser usados nesse caso. O marcador execute (execução de uma tarefa em um host remoto), transfer (transferência de arquivos, geralmente relacionados à execução) e authenticate (para autenticação).

Namespace: define elementos que podem ser usados como prefixos na indicação do caminho do recurso. O Namespace criado pode ser usado como qualquer variável dentro do workflow.

próxima de um programador do que de um usuário. Além disso não oferece recursos para a execução direta de serviços.

• XML-based Description Language: é uma linguagem e um ambiente de exe- cução para orquestração de tarefas em grades [217]. O trabalho propõe uma ferra- menta flexível com recursos avançados para monitoramento, tratamento de falhas, liberação de recursos e que permita o desenvolvimento de aplicações robustas. Usa o Java CoG Kit como plataforma de desenvolvimento e propõe uma linguagem ba- seada no Karajan, com o objetivo principal de atender desenvolvedores e usuários avançados. A linguagem oferece suporte a vários tipos de tarefas como: execução computacional (<job>), transferência de arquivos (<filetransfer>), invocação de serviços (<service>), envio de e-mails (<mail>), e uso de scripts e objetos Java (<java>, <jobject>). A linguagem apresenta algumas limitações não oferecendo, por exemplo, estruturas para controle de fluxo (if, while, etc). Além disso é orientada a desenvolvedores o que dificulta o seu uso por usuários menos experientes.

• Simple Conceptual Unified Flow Language (SCUFL): No Taverna, o mo- delo de dados pode ser representado graficamente ou descrito através de uma lin- gaugem baseada em XML denominada Simple Conceptual Unified Flow Language (SCUFL) [176]. O modelo consiste em entradas, saídas, processadores, controle de dados e de fluxo. Além disso, para especificar a ordem de execução, o fluxo de controle pode também ser acionado por estados de transição durante a execução de processadores antecessores. Comparando com WS-BPEL, SCUFL permite especifi- car estratégias sobre os conjuntos de dados. Em nível de execução SCUFL provê a propriedade Thread para especificar quantas instâncias concorrentes podem enviar requisições em paralelo. Essa opção é particularmente interessante quando usada com serviços, pois estes são capazes de manipular vários processos simultâneos. Essa facilidade reduz o tempo de espera, pois permite ao motor de workflow enviar os dados para a próxima etapa enquanto o serviço está em execução.

• Pegasus DAX: DAX é linguagem para descrição de workflows abstratos usada pelo Pegasus [218]. DAX, um acrônimo para Directed Acyclic Graph in XML, é baseada em XML e pode ser criada através de APIs geradoras que estão disponíveis para Java, Perl e Python. Um workflow descrito em DAX contém um cabeçalho e três seções. O cabeçalho contém as indicações para esquemas XML e a indicação do esquema DAX (versão) usada na descrição. Na primeira seção, opcional, são defini- dos os arquivos a serem usados no workflow bem como se serão fornecidos (input) ou gerados (output) pelo workflow. A segunda seção descreve as tarefas. Para cada tarefa são informados o nome lógico do executável, seus argumentos, arquivos de

entrada e de saída. E na terceira seção são definidas as dependências entre as ta- refas (marcadores child e parent). Não são permitidas dependências cíclicas. DAX é uma especificação voltada ao desempenho com informações importantes que fa- cilitam a tarefa de escalonamento e permite provisionar os dados enquanto tarefas estão em execução. No entanto, é destinada à execução de tarefas não oferecendo suporte a serviços. Além disso, não provê qualquer informação sobre domínios e am- bientes operacionais dificultando a preparação automática sob demanda de recursos computacionais de forma automatizada.

• Swift: Swift é uma scripting language projetada para compor programas em apli- cações paralelas que podem ser executadas em processadores com vários núcleos, clusters, grades e nuvens. É direcionada a usuários especializados como cientistas e engenheiros, que desejam executar aplicações de longa duração em vários domínios muitas vezes envolvendo grandes quantidades de dados. Swift é focada na compo- sição, coordenação e execução de tarefas independentes. Ela usa uma sintaxe que se assemelha a da Linguagem C, com funções e expressões com semântica orientada ao fluxo de dados e paralelismo implícito que pode envolver MPI (Message Passing Interface). Swift avalia as expressões executando em paralelo expressões que não te- nham dependência de dados entre si. Em geral os motores de workflow que aceitam submissões em linguagem Swift oferecem opções para o fornecimento de informações sobre o ambiente no momento da execução. Apesar das facilidades para execuções paralelas em ambiente distribuído, a Swift requer noções de programação do usuá- rio, é orientada a tarefas não tratando serviços, e não oferece diretivas que permitam especificar detalhes sobre o domínio onde devem ser executadas as tarefas.

• WS-BPEL: a Business Process Execution Language for Web Services (BPEL4WS ou WSBPEL) [39] é de fato o padrão para a composição de serviços em aplicações de negócios. O acesso a um processo é exposto pelo mecanismo de execução atra- vés de uma interface de serviço Web, permitindo que o processo para ser acessado por serviços Web clientes ou para ser usado como uma atividade básica em outros processos. Ela oferece um rico vocabulário e mecanismos de controle para expressar sequências de atividades como receber, invocar e responder, execuções sequenciais e paralelas, ciclos, tratamento de erros, bem como mecanismos de compensação para realizar ações de reversão (roll-back actions). WS-BPEL trabalha bem para pro- cessos cujos hosts são conhecidos ou fixados previamente (chamados de processos estáticos), tendo desvantagens quando se trata de escolher dinamicamente os hosts em tempo de execução. Em processos de negócios, onde os parceiros são conhecidos não há restrições, mas em modelos de computação intensiva encontrados em work- flows científicos WS-BPEL pode ter sérias restrições. WS-BPEL transfere dados

através de mensagens XML tendo restrições no suporte à interação entre grandes conjuntos de dados, o que requer o uso de formas alternativas para manter o desem- penho. WS-BPEL permite agregar tipos de dados através de esquemas XML, mas não provê suporte para mapear a visão lógica com representações físicas. Apesar dessas restrições no mundo científico, vários trabalhos usam WS-BPEL como base agregando soluções alternativas [219, 220, 211, 182, 221], pois são reconhecidas as vantagens da WS-BPEL no tratamento de serviços.

A CEOL é uma linguagem compacta baseada em XML, que contém primitivas que permitem ao usuário descrever o relacionamento entre tarefas e serviços for- temente acoplados, formando um workflow para ser usado em ambientes híbridos. A CEOL acrescenta aos conceitos de orquestração de serviços propostos em WS- BPEL e GPOL [222, 14] diretivas para tratar requisitos específicos do ambiente híbrido, como manutenção de estado, serviços potencialmente transientes, notifi- cação, serviços orientados a dados, serviços orientados a grupos, além de tratar workflows abstratos onde não são identificados os recursos onde os serviços devem ser executados. Ao permitir a definição de workflows abstratos a CEOL endereça um importante requisito da nuvem onde os recursos computacionais são providos através de instâncias de máquinas virtuais que são criadas sob demanda.