• Sonuç bulunamadı

Kadıköy STÖ Yaz Okulu

a. Mentorluk Eğitimleri

2. Yerel Kuluçka Eğitimleri

2.1. Kadıköy STÖ Yaz Okulu

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 < u s e r _ p o r t i d _ p o r t =" s t a t e −L"/ > 3 < u s e r _ p o r t i d _ p o r t =" s t a t e −R"/ > 4 < p r o v i d e r _ p o r t i d _ p o r t =" e v e n t −L"/ > 5 < p r o v i d e r _ p o r t i d _ p o r t =" e v e n t −R"/ > 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 < u s e r _ p o r t i d _ c o m p o n e n t =" a p p l i c a t i o n " i d _ p o r t =" s t a t e −L"/ >

3 < p r o v i d e r _ p o r t i d _ c o m p o n e n t =" component−L" i d _ p o r t =" s t a t e "/ >

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 ar- quitetural 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 < p e e r i d _ c o m p o n e n t =" workflow " i d _ p o r t =" compute−s t e p "/ > 3 < p e e r i d _ c o m p o n e n t =" component−L" i d _ p o r t =" compute−s t e p "/ > 4 < p e e r i d _ c o m p o n e n t =" component−R" i d _ p o r t =" compute−s t e p "/ > 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.

Benzer Belgeler