Subconjunto Arquitetural - SAFeSWL (SAFe Scientific Workflow Language)

4.6 SAFeSWL (SAFe Scientific Workflow Language)

4.6.0.1 Subconjunto Arquitetural

Através do subconjunto de linguagem arquitetural de SAFeSWL, os provedores podem especificar os componentes e bindings que formam a arquitetura de um sistema de computação paralela, como aquele apresentado na Figura 23. Cada componente de solução possui um contrato contextual a ele anexado, que orientará a seleção de uma implementação apropriada, de acordo com os requisitos especificados.

Os elementos do arquivo arquitetural são baseados em XML, sendo bastante intuitivos. O arquivo é organizado em seções, delimitadas pelos seguintes elementos em forma de tags:

• A tag <application> é usada para definir o componente Application, declarando suas portas usuárias e provedoras;

• A tag <workflow> é usada para definir o componente Workflow, declarando suas portas de ações;

• A tag <solution> é usada para definir o corpo do sistema de computação paralela, onde os componentes de solução são especificados por meio das tags <computation>, <connector>, <repository>, e <platform>, sendo uma para cada espécie de compo-

nentes da HPC Shelf;

• A tag <env_binding> é usada para declarar um binding de serviço, que conecta portas usuárias às portas provedoras;

conjunto de portas de ações, contendo um mesmo conjunto de nomes de ações.

A gramática XSD (XML Scheme Definition) foi especificada para documentar a sintaxe do arquivo arquitetural, bem como para facilitar a construção de um analisador sintático. A Figura 25 descreve sua estrutura geral, através de um diagrama fornecido por um plugin da plataforma Eclipse, usado para manipular arquivos XML. Nessa Figura, pode-se ver o tipo do elemento de nível superior, chamado Architecture, representado pela tag <architecture>, bem como os tipos de seu elementos internos: o componente de aplicação (Component), o componente workflow (Workflow), os componentes de solução (Solution), os bindings de serviços (BindingEnvironment) e os bindings de ações (BindingTask).

1 < a p p l i c a t i o n i d _ c o m p o n e n t =" a p p l i c a t i o n "> 2 3 4 5 6 < / a p p l i c a t i o n >

Código 1 – Exemplo de XML Arquitetural: O Componente Application

1 < s e r v i c e _ b i n d i n g >

2

3

4 < / s e r v i c e _ b i n d i n g >

Código 2 – Exemplo de XML Arquitetural: Um Binding de Serviço

O Código 1 contém a declaração de um componente Application na sintaxe arquitetural do SAFeSWL. Basicamente, apresentam-se as portas usuárias e provedoras de um sistema de computação paralela hipotético, cuja arquitetura é descrita na Figura 26. Por exemplo, <user_port id_port = “state-L”> declara que uma porta usuária está conectada, através da declaração <service_binding> mostrada no Código 2, à porta provedora de um componente component-L. Uma vez que é uma porta de serviço, state-L lida com um interesse não funcio- nal. Por exemplo, no sistema de computação paralela visto na Figura 26, application monitora o estado de component-L e component-R durante a execução, através das respectivas portas usuárias state-L e state-R. Além disso, application é notificado sobre eventos gerados por esses componentes através das portas provedoras event-L e event-R, respectivamente.

Figura 26 – Application 1 < a c t i o n _ b i n d i n g > 2 3 4 5 < / a c t i o n _ b i n d i n g >

Código 3 – Exemplo de XML Arquitetural: Um Binding de Ações

O Código 3 exemplifica a declaração de um binding de ação envolvendo três portas de ações, denominadas compute-step, dos componentes workflow, component-L e component-R. A portacompute-step tem quatro nomes de ação: INITIALIZE, COMPUTE_STEP, TERMINATE_FLAG e FINALIZE, como ilustrado no Código 4, onde o componente workflow é declarado. 1 < workflow i d _ c o m p o n e n t =" workflow "> 2 < a c t i o n _ p o r t i d _ p o r t =" compute−s t e p "> 3 < a c t i o n name=" INITIALIZE "/ > 4 < a c t i o n name="COMPUTE_STEP"/ > 5 < a c t i o n name="TERMINATE_FLAG"/ > 6 < a c t i o n name=" FINALIZE "/ > 7 < / a c t i o n _ p o r t > 8 < / workflow >

Código 4 – Exemplo de XML Arquitetural: O Componente Workflow

As portas de ações lidam com interesses funcionais, desencadeando as operações computacionais que definem o progresso da execução do workflow. Dessa forma, no exemplo, os nomes de ações de component-step representam operações funcionais executadas pelos

TASK::= Skip | Perform action | Start handle action | Wait handle | Cancel handle | Sequence TASK_{+ | Parallel TASK+ | Repeat TASK | Break | Continue |} Select{component action: TASK}+

Skiprepresenta uma ação vazia. Perform representa uma invocação de ação síncrona, que se completará após todos os parceiros de componente ativar a mesma ação, através de um binding de ação. Por sua vez, Start, Wait e Cancel são usados para invocação de ações assíncronas, onde uma invocação de ação é iniciada por Start. Em seguida, a tarefa de orquestração pode aguardar a conclusão da ação, executando Wait para o mesmo handle, ou cancelá-la, por meio da execução de Cancel. Sequencee Parallel representam respectivamente a invocação serial e paralela de um conjunto de tarefas. Repeat representa a execução iterativa de uma tarefa até que Break seja executado. Continue força o início de uma nova iteração. Finalmente, Selectrepresenta uma escolha entre um conjunto de tarefas, de acordo com a invocação de um conjunto de ações em sentinela.

Figura 27 – Sintaxe Abstrata do Subconjunto de Orquestração de SAFeSWL

componentes component-L e component-R, em uma ordem prescrita. O componente workflow é responsável por orquestrar essas ações de acordo com os requisitos da aplicação.

O arquivo de descrição arquitetural é processado pelo SAFe para declarar automati- camente as portas de componentes, bem como para conectá-las através de bindings, preparando o sistema de computação paralela para a execução do workflow, mesmo antes dos componentes de solução terem sido implantados e instanciados.

No documento Um arcabouço baseado em componentes para computação paralela de larga escala sobre grafos (páginas 96-99)