definitions

O elemento definitions contém a definição das variáveis e dos serviços que serão usados no processo (process). A sintaxe para definitions é:

<definitions name=“xsd:Name”> <variables>*

<services>* </definitions>

O elemento <definitions> tem em name o seu único atributo. Esse atributo é opcional, e quando usado, deve ser uma identificação única para as definições do workflow. Essa identificação poderá ser útil no monitoramento da execução.

O elemento <variables> contém a definição das variáveis que serão usadas durante a execução do workflow. O elemento <variables> (Seção 4.3.6) é formado por um ou mais elementos <variable> (Seção 4.3.6), onde são descritas as propriedades de cada variável do workflow. O elemento não é necessário se não forem usadas variáveis no processo.

O elemento <services> (Seção 4.3.7) contém um ou mais elementos <service>. Cada elemento <service> descreve um dos serviço que será invocado durante a execução do workflow. Se nenhum serviço for usado no workflow, não é necessário incluir o elemento <services> em <definitions>.

4.3.5 process

O elemento <process> define os passos a serem executados pelo workflow. Em <process> são executadas tarefas e invocados os serviços definidos em <definitions>. O elemento <process> usa as variáveis como argumento em chamadas, para salvar valores retornados por serviços ou para fazer pequenos cálculos. Em <process> o usuário pode combinar livremente as atividades e estabelecer um tratamento de falhas global para todos os ser- viços e tarefas. A sua sintaxe é:

<process name=“xsd:Name” met=“xsd:integer” aet=“xsd:integer” targetNamespace=“xsd:anyURI ” xmlns:xsd=“http://www.w3.org/2001/XMLSchema”> <faultHandlers>? Atividade+ </process>

O atributo name deve ser uma identificação única do processo. Essa identificação é usada pelo monitoramento da execução. Os atributos met e aet sinalizam o tempo máximo e médio para a execução do workflow conforme já descrito no elemento raiz <workflow>. O atributo targetNamespace é o namespace local do processo. Ele é semelhante ao namespace global especificado no elemento <workflow>. O elemento <process> aceita a indicação de outros espaços de nomes que devem ser incorporados ao processo. A CEOL

permite qualquer combinação de atividades como elementos em process.

O elemento faultHandlers aciona o tratamento de falhas geral para o processo (Seção 4.3.8). Se não houver uma indicação de local no serviço invocado, será usado o tratamento padrão aqui indicado caso uma falha ocorra.

4.3.6 variables e variable

Variáveis suportam a manutenção de estado dos serviços do workflow. Além disso, são necessárias variáveis para apoiar a passagem de informações entre os serviços. A CEOL permite ao usuário criar variáveis através dos elementos <variables> e <variable>. A sintaxe desses elementos é:

<variables> <variable> name=“xsd:Name” type=“ceo:VariableType” value=“xsd:string”? < /variable>+ </variables>

O elemento <variables> agrupa todas as definições de variáveis do workflow. Ele não tem atributos e deve conter pelo menos um elemento <variable> em sua definição.

Não é o objetivo das variáveis conter um grande volume de dados a serem trocados entre os serviços ou tarefas. A troca de grandes volumes deve ser feita através de arquivos. Nesse caso as variáveis podem ser usadas para passar a localização de onde estão os dados. Cada variável deve ser definida através do elemento <variable>. O atributo name indica o nome de cada variável e deve ser único dentro do workflow. O atributo Va- riableType, referenciado como um tipo simples do XML Schema, define o tipo de cada variável. Os tipos válidos são: string, boolean, decimal, integer, float e double conforme XMS Schema mostrado na Seção 4.5. Não é permitido declarar tipos diferentes para a mesma variável. O atributo opcional value deve conter uma string que represente um va- lor válido conforme o tipo declarado. Esse é o valor inicial atribuído à variável declarada. O valor padrão é zero para valores numéricos e string nula para variáveis do tipo string. Por exemplo:

<variable name=“Quantidade” type=“integer” value=“10”/> declara a variável Quantidade, tipo inteiro e valor inicial 10.

A responsabilidade pela consistência de conteúdo nas variáveis é do usuário.

4.3.7 services e gsh

Uma característica importante do CEO é permitir ao usuário invocar serviços no workflow. Para invocar um serviço, o usuário deve declará-lo em <definitions> para usá-lo em <process>. A definição do serviço informa sua localização, seu tipo e fornece um nome único para referenciá-lo no processo. Essa definição é feita através do elemento <gsh>, e todos os serviços devem estar declarados no elemento <services>. A sintaxe para os elementos <gsh> e <services> é:

<gsh>

name=“xsd:Name” gshId=“xsd:integer”

<rr dId=“xsd:string” image=“xsd:string” flavor=“xsd:string”/>? host=[“xsd:anyURI ” | “local” | “anyHost”]?

hostId=“xsd:integer” hostClass=“xsd:Name” port=“xsd:positiveInteger” protocol=“xsd:string” uri=“xsa:anyURI ”? fal=“xsd:anyURI ”? sal=“xsd:anyURI ”? type=“[Factory | Instance]” tsn=“xsd:string”? provider=“tns:ProviderType”? ret-type=“ceo:VariableType”? < /gsh> <services> Atributos-gerais <gsh>+ <vpc vpcid=“xsd:string” subnet=“xsd:string”> <ph phname=“xsd:string” phid=“xsd:string” phIP=“xsd:anyURI ”/> <gsh>+ < /vpc>* </services>

O atributo name indica o nome (apelido) de cada serviço, único dentro do workflow, e que será usado nas atividades do processo pelo atributo gsh. O atributo gshId, opcional para o usuário, é uma identificação numérica do serviço. Seu uso é interno. A CEOL

tem dois nomes de gsh reservados. CEO-SNI e CEO-ENI não podem ser usados nas declarações feitas pelo usuário. Eles estão automaticamente disponíveis para referenciar o recurso computacional onde o CEO Controller do domínio está hospedado. CEO-SNI é importante para indicar a origem de arquivos fornecidos pelo usuário necessários à execução (Upload). De forma análoga, CEO-ENI deve ser usado para copiar os arquivos gerados pelo workflow que devem ser enviados ao usuário (Download). Com CEO-SNI e CEO-ENI o usuário trata de forma abstrata o CEO Controller independente de onde este esteja fisicamente.

O elemento opcional <rr> (resource requirements) permite definir os requisitos do recurso computacional onde será executado o serviço. Através dele é possível indicar o domínio (dId) onde obter o recurso computacional e informar pelo par imagem (image) e configuração (flavor) como a VM deve ser criada. O domínio deve estar devidamente cadastrado no arquivo de configuração do ambiente (Apêndice B) e o preenchimento de image e flavor deve ser coerente com os requisitos do domínio indicado. Se usado, o elemento <rr> tem prioridade sobre as informações fornecidas pelo elemento <er>.

Um conjunto de atributos pode ser usado de forma combinada para indicar a locali- zação do serviço. O atributo uri contém a localização completa do serviço. Ele contém o protocolo (protocol), o hospedeiro (host), a porta (port), e o serviço alvo (tsn - target service name). Um exemplo de uri é: uri=“http://10.3.77.19:8443/wrsf/services/factip/- FactIPService”, onde “http” é o protocolo, “10.3.77.19” é o IP do hospedeiro onde será executado o serviço, “8443” é a porta associada ao container e “/wrsf/services/factip/- FactIPService” é a identificação do serviço alvo. O atributo host indica a localização dentro do ambiente e pode ser preenchido com o nome do hospedeiro (host=“Apolo”), com o IP (host=“10.3.77.19”), com local (host=“local”) ou anyHost (host=“anyHost”). Destinado a ambientes “oportunistas”, o valor anyHost é uma das formas de indicar que o workflow é abstrato e o CEO deve escolher a melhor opção de recurso. A outra forma é simplesmente não usando o atributo host e não indicando qualquer localização do re- curso computacional. Em algumas atividades pode ser necessário executar um serviço no host onde está o CEO Controller (uma operação de upload, por exemplo). Ocorre que no ambiente da nuvem o usuário desconhece a localização do CEO Controller. Preen- chendo o atributo host com o valor local o usuário estará indicando que o serviço deve ser hospedado no mesmo host onde está o CEO Controller. O atributo hostId, opcional, é preenchido em ordem crescente a cada gsh declarado. O usuário pode usá-lo quando desejar forçar o uso do mesmo hospedeiro para vários serviços, pois mesmo deixando a escolha dos recursos para o CEO o usuário pode organizar a distribuição dos serviços nos recursos. E finalmente o atributo hostclass indica os requisitos mínimos necessários ao recurso para que possa executar o serviço. Esse atributo deve ser preenchido com uma opção previamente configurada no ambiente, conforme ilustrado no Apêndice B.5.

O atributo ret-type, referenciado como um tipo simples do XML Schema, define o tipo para o valor de retorno após a execução do serviço. São os mesmos tipos aceitos na definição de variáveis.

O atributo type indica qual o tipo de serviço a ser invocado. Pode ser Factory ou Instance. Esse atributo está relacionado com o conceito de “Fábrica de Serviços” usado em outros serviços do CEO (Run Service, Maestro, etc). Se o tipo indicado for Factory, o Maestro criará uma nova instância desse serviço para usá-la durante a execução do processo. Esse recurso é muito flexível permitindo ao usuário criar várias instâncias do mesmo serviço nos recursos do domínio. O tipo Instance indica que o serviço só pode ter uma instância em cada recurso computacional. O RMS do CEO é um serviço desse tipo, pois não pode haver duas instâncias monitorando o mesmo recurso simultanemente. O Maestro controla o ciclo de vida das instâncias do workflow eliminando-as ao término da execução. O valor padrão para type é Factory.

O atributo provider indica qual é o tipo de provedor onde está o serviço alvo. Ele serve para indicar diferenças operacionais no uso do serviço. Por exemplo, em domínio de grade provida pelo Globus Toolkit, pode ser GT4 ou GT5, indicando a versão do middleware. Existem pequenos detalhes operacionais entre elas que podem alterar a declaração dos serviços. O atributo pode ser usado de forma similar para indicar diferenças nos middlewares para nuvem.

Os atributos fal (Factory Addressing Locator) e sal (Service Addresing Locator) devem indicar a localização dos stubs do serviço alvo. Se o serviço for do tipo Instance é necessário indicar apenas o atributo sal.

O elemento <vpc> permite organizar os serviços do workflow de forma que possam ser executados em recursos computacionais agrupados em uma VPC (Virtual Private Cloud) do ambiente. Através da VPC ações como a troca de informações entre os serviços po- dem ser otimizadas, uma vez que os recursos computacionais estão fisicamente próximos e isolados em uma subrede. O elemento <vpc> tem dois atributos para identificar a VPC (vpcid e subnet) e usa o elemento <ph> (public host) para declarar a localização do ser- vidor público que dá acesso à VPC (phname, phid e phIP). Os serviços que usam a VPC devem ser indicados através de elementos <gsh> dentro de <vpc>, quantos forem neces- sários. O uso do elemento <vpc> não impede o uso de outros serviços. A CEOL permite compor serviços agrupados em VPC com outros serviços que usam recursos “isolados”.

O elemento <services> agrupa todas as definições de serviços que são usados no workflow. Em Atributos-gerais é possível incluir todos os atributos aceitos em <gsh> exceto o nome (name). Todo atributo definido nessa área será tratado com uma definição “global” para todo <gsh> em <services>. Caso haja uma definição para o mesmo atributo dentro do <gsh> (“local”) terá prioridade sobre a “global”.

4.3.8 faultHandlers

O Maestro e o Run Service mantêm um conjunto de variáveis para acompanhar a execução do workflow. Essas variáveis são atualizadas pelo Maestro a cada passo da execução e são acessadas pelo Run Service através de métodos exclusivos, e podem ser consultadas pelo usuário através do Dashboard. Parte desse conjunto de variáveis está relacionada com o controle de falhas.

Através do elemento opcional <faultHandlers> é possível definir o tratamento perso- nalizado para falhas que ocorrerem no workflow. A sintaxe de faultHandlers é:

<faultHandlers> <catch faultName=“xsd:Name” faultVariable=“xsd:Name”?> Atividade* < /catch>* <catchAll> Atividade* < /catchAll>? </faultHandlers>

O elemento <faultHandlers> não tem atributos e pode ser constituído por um ele- mento <catchAll> ou por um ou mais elementos <catch>. Esses elementos oferecem facilidades para acessar o conjunto de variáveis que são usadas para indicar falhas que possam ocorrer. Podem ser usados um ou vários elementos <catch>. Em cada um deles é possível sinalizar com o atributo faultName a falha a ser rastreada, e com o atributo faultVariable a variável associada a essa falha. O elemento <catch> permite indicar uma ou mais atividades que são úteis no tratamento da falha. O elemento <catchAll> aciona a captura de todas as falhas que possam ocorrer no workflow e também permite indicar atividades. O CEO permite também acompanhar erros através das variáveis do workflow. O fragmento de código a seguir mostra a captura de um erro relacionado à variável imf1 e que está relacionada a um serviço do workflow. Se houver um erro será apresentada a mensagem “Service Error”.

<ceo:faultHandlers>

<ceo:catch faultVariable="imf1">

<ceo:execute executable="/bin/echo" <ceo:argument value="Service Error"/> </ceo:execute>

</ceo:catch> </ceo:faultHandlers>

4.3.9 fileLocation e fileCopy

Esses não são elementos da linguagem mas XML Schemas que são usados em vários ele- mentos CEOL que tratam com arquivos. O esquema fileLocation define um padrão para o preenchimento de atributos que indicam a localização de um arquivo. Sua sintaxe é:

<xsd:simpleType name=“fileLocation”> <xsd:restriction base=“xsd:string”>

<xsd:pattern value=“.*@.*:.* ”/> </xsd:restriction>

</xsd:simpleType>

O padrão de preenchimento indica que o valor tem três partes, uma do início até o caractere ’@’, a segunda entre os caracteres ’@’ e ’:’ e a terceira após o caractere ’:’. A primeira parte deve ser preenchida com a identificação do usuário com permissão de acesso ao arquivo. A segunda indica o recurso onde está o arquivo e pode ser preenchida com um IP, um nome de hospedeiro devidamente configurado no CEO ou um gsh declarado no workflow. E a terceira parte deve conter a localização do arquivo no recurso computacio- nal (File Path). A opção de usar um gsh na segunda parte é importante e destinada aos workflows abstratos. O Maestro fará os acertos necessários susbtituindo dinamicamente o gsh pela localização do recurso computacional durante a execução do workflow. Um exemplo de uso desse esquema é:

<ceo:whereisfile type=“ceo:fileLocation” value=“user–01@gsh–01:wrkf–01.ceol”/> O esquema fileCopy define como deve ser feita a copia de arquivo entre recursos com- putacionais do ambiente. Sua sintaxe é:

<xsd:complexType name=“fileCopy”>

<xsd:attribute name=“tagname” type=“xsd:Name”/> <xsd:attribute name=“pidSource” type=“xsd:integer”/>? <xsd:attribute name=“source” type=“ceo:fileLocation”/> <xsd:attribute name=“pidDestination” type=“xsd:integer”/>? <xsd:attribute name=“destination” type=“ceo:fileLocation”/> <xsd:attribute name=“fs” type=“xsd:long”/>?

<xsd:attribute name=“afs” type=“xsd:long”/> </xsd:simpleType>

O atributo tagname é usado pelo sistema de monitoramento para identificar o tempo gasto na copia do arquivo. Os atributos source e destination indicam a localização do arquivo e onde deve ser feita a cópia. Devem ser preenchidos com o tipo de “localiza- ção” permitida pelo CEO e detalhada na definição do esquema fileLocation. Os atributos pidSource e pidDestination podem indicar (ou forçar) a dependência de dado entre dois serviços. O atributo pidSource deve ser preenchido com o pid da atividade que gera o arquivo enquanto pidDestination deve ser preenchido com o pid da atividade executada no recurso computacional para onde deve ser feita a cópia. Detalhes sobre como o Ma- estro trata a dependência de dados entre as atividades, incluindo o uso de pidSource e pidDestination estão na Seção 5.4.1.

O atributo fs (file size) indica o tamanho do arquivo a ser copiado, enquanto que afs (average file size) é preenchido com o tamanho médio dos arquivos copiados pela atividade. O atributo afs não é vinculado a fileCopy mas sim à atividade que o usa, invokes ou transfers, por exemplo.

4.3.10 invoke

O elemento <invoke> é usado para invocar uma operação de um serviço. O elemento <invoke> pode funcionar de forma síncrona ou assíncrona. Quando usado dentro do elemento flow, o processamento segue não aguardando o término da execução do invoke. Em um elemento flow todos os elementos são acionados simultaneamente. No entanto, se o invoke não estiver dentro de um flow, o processamento do workflow fica aguardando o término da execução do invoke para então continuar o processamento. A sintaxe desse elemento é: <invoke> gsh=“xsd:Name” operation=“xsd:Name” pid=“xsd:integer” tagname=“xsd:Name” met=“xsd:integer” aet=“xsd:integer” filein=“ceo:fileCopy”* <argument> [variable=“xsd:Name” | value=“xsd:string”]

type=“ceo:VariableType” </argument>* fileout=“ceo:fileCopy”* <return> [variable=“xsd:Name” | value=“xsd:string”] type=“ceo:VariableType”? </return>?

[<faultHandlers?> | <catch*> | <catchAll?>]

</invoke>

O atributo gsh indica o apelido do serviço alvo e deve ser o mesmo usado nas definições (<services> em <definitions>). O atributo operation é o nome de uma operação válida para o serviço (métodos da classe). O usuário deve conhecer previamente as operações disponíveis nos serviços que serão usados. O atributo pid, preenchido sequencialmente pelo CEO caso o usuário não o faça, indica a ordem de execução da atividade dentro do workflow. Ele pode ser usado para indicar a dependência de dados entre as atividades do workflow. O atributo tagname é usado pelo sistema de monitoramento para identificar o tempo gasto na copia do arquivo. Os atributos met e aet sinalizam o tempo máximo e médio para a execução do workflow conforme já descrito no elemento raiz <workflow>.

Os elementos <filein> e <fileout> tratam a dependência de dados entre os serviços do workflow. O elemento <filein>, que aceita repetições, deve ser usado para copiar arquivos que serão usados pela operação (operation) do <invoke>. O Maestro–WES executa todos os fileins da atividade antes de efetivamente executar a operação. De forma análoga, <fileout> pode ser usado para copiar arquivos gerados pela operação já preparando os arquivos para atividades futuras.

Os elementos <argument> e <return> estão associados logicamente ao atributo ope- ration. O elemento <argument> deve ser usado para definir argumentos a serem passados para a operação do serviço. Para cada argumento requisitado pela operação desejada, um elemento <argument> deve ser declarado. Os seus atributos são iguais aos já apresentados no elemento <variable> descrito anteriormente. O usuário pode indicar um valor como argumento (atributo value), ou indicar uma variável (atributo variable), cujo conteúdo será passado como argumento. Ou seja, o Maestro–WES usa passagem de argumentos por valor e não por referência. O tipo do argumento (atributo type) deve ser coerente com as definições da operação escolhida.

O elemento <return> pode ser usado para salvar o retorno da operação executada em uma das variáveis definidas no workflow. Seus atributos são semelhantes aos encontrados em <argument>.

O CEO acompanha a execução do workflow adicionando no arquivo de log os er- ros que possam ocorrer. Por exemplo, se a operação (operation) indicada no invoke não existir, o CEO incluirá a mensagem “Invalid Operation”. Opcionalmente os ele- mentos <faultHandlers>, <catch> e <catchAll> podem ser usados para tratar falhas no <invoke>. Por exemplo, se ao tentar invocar um serviço for sinalizado que “as credenciais do usuário” estão vencidas, é possível renová-las usando a atividade <execute>, ou infor- mar que essa ação deve ser feita (Atividade echo). A declaração local de <faultHandlers> tem prioridade sobre a declaração geral feita em <process>.

O fragmento de código a seguir ilustra o uso da atividade invoke: