M
ODELO
M
ATEMÁTICO PARA
C
ÁLCULO DO
M
AKESPAN EM
P
ROCESSOS DE
I
NTEGRAÇÃO DE
A
PLICAÇÕES
E
MPRESARIAIS
S
ANDRA
B
EATRIZ
N
EUCKAMP
U
NIVERSIDADE
R
EGIONAL DO
N
OROESTE DO
E
STADO DO
R
IO
G
RANDE DO
S
UL
DISSERTAÇÃO DE MESTRADO ORIENTADOR:
DR. RAFAEL ZANCAN FRANTZ COORIENTADOR:
DRA. FABRICIACARNEIROROOS FRANTZ
R e s e a r c h G r o u p
Computing
Applied
First published in February 2012 by
Applied Computing Research Group - GCA Department of Exact Sciences and Engineering Rua Lulu Ilgenfritz, 480 - São Geraldo
Ijuí, 98700-000, Brazil.
Copyright c MMXII Applied Computing Research Group
http://www.gca.unijui.edu.br gca@unijui.edu.br
In keeping with the traditional purpose of furthering science, education and research, it is the policy of the publisher, whenever possible, to permit non-commercial use and redistribution of the information contained in the documents whose copyright they own. You however are not allowed to take money for the distribution or use of these results except for a nominal charge for photocopying, sending copies, or whichever means you use redistribute them. The results in this document have been tested carefully, but they are not guaranteed for any particular purpose. The publisher or the holder of the copyright do not offer any warranties or representations, nor do they accept any liabilities with respect to them.
Financiamento: Bolsa de mestrado concedida Coordenação de Aperfeiçoamento
de Pessoal de Nível Superior (CAPES). A pesquisa desenvolvida neste trabalho também contou com recursos de projeto de pesquisa concedidos ao Grupo de Pesquisa em Computação Aplicada pela Fundação de Amparo à Pesquisa do Estado do Rio Grande do Sul (FAPERGS), sob o termo de outorga de no17/2551-0001206-2.
Dedico este trabalho a todos aqueles que me apoiaram durante esta trajetória de muitas
aprendizagens.
Conteúdo
Índice de abreviaturas . . . .
vii
Índice de símbolos . . . .
ix
Agradecimentos . . . .
xi
Resumo . . . .
xiii
Abstract . . . .
xv
1 Introdução . . . .
1
1.1 Contexto da Pesquisa . . . 1 1.2 Motivação . . . 3 1.3 Objetivos . . . 4 1.3.1 Geral . . . .4 1.3.2 Específicos . . . .4 1.4 Metodologia . . . 41.5 Resumo das Contribuições . . . 5
1.6 Estrutura do Documento . . . 7
2 Revisão da Literatura . . . .
9
2.1 Integração de Aplicações Empresariais . . . 9
2.1.1 Estilos de integração . . . .12
2.1.2 Topologias de integração . . . .15
2.2 Plataformas de integração . . . 17
2.2.1 Linguagem de domínio específico . . . .18
2.2.2 Motor de Execução . . . .21
2.3 Teoria dos Grafos . . . 24
ii Conteúdo
2.4 Definição de Verificação e Validação . . . 29
2.4.1 Técnicas de Verificação . . . .30
2.5 Trabalhos Relacionados . . . 31
2.5.1 Algoritmos de agendamento e escalonamento . . . .33
2.5.2 Modelos matemáticos . . . .34
2.5.3 Fluxos de trabalho . . . .35
2.6 Resumo do Capítulo . . . 36
3 Modelo Matemático Proposto . . . .
39
3.1 Formulação do Problema . . . 39
3.2 Modelo Matemático . . . 41
3.3 Resumo do Capítulo . . . 47
4 Experimento . . . .
49
4.1 Questão de Pesquisa e Hipótese . . . 49
4.2 Ambiente da Experimentação . . . 50
4.3 Variáveis . . . 50
4.4 Execução e Coleta de Dados . . . 50
4.5 Resultados . . . 52
4.6 Discussão . . . 52
4.7 Ameaças à Validade . . . 58
4.8 Resumo do Capítulo . . . 58
5 Conclusões e Trabalhos Futuros . . . .
61
Índice de figuras
1.1 Publicações trabalhadas e envidas no período do mestrado. . . .6
2.1 Ambiente de integração de aplicações empresariais. . . .10
2.2 Estilo de Transferência de Arquivos. . . .13
2.3 Estilo de Base de Dados Compartilhada. . . .14
2.4 Estilo de Chamada de Procedimento Remoto. . . .14
2.5 Estilo de Sistema de Mensagem. . . .15
2.6 Notação e conceitos da tecnologia Guaraná [16]. . . 19
2.7 Modelo conceitual do motor de execução. . . .24
2.8 Grafo com custo associado as arestas. . . .26
2.9 Grafo simples. . . .26
2.10 Grafo direcionado. . . .27
3.1 DAG para representar um fluxo de integração. . . .41
4.1 Modelo conceitual para o processo de integração Café [19]. . . .51
4.2 Valores de makespan para um conjunto de 1 até 50 threads. . . .53
4.3 Grafo para o processo de integração Café [19]. . . .54
4.4 Maior caminho para o cálculo de makespan. . . .55
4.5 Valores de makespan encontrados no modelo e no experimento. . . .57
Índice de tabelas
2.1 Trabalhos relacionados. . . .33
4.1 Relação de tarefas e tempos do processo de integração. . . .53
4.2 Makespan encontrado através do modelo matemático. . . .57
Índice de abreviaturas
EAI - Integração de Aplicações Empresariais ( do inglês Enterprise Application Integration)
DSL - Linguagem de Domínio Específico (do inglês Domain Specific Language)
API - Interface de Programação de Aplicativo (do inglês Application Programming Interface)
DAG - Grafo Acíclico Direcionado (do inglês Directed Acyclic Graph) GCA - Grupo de Computação Aplicada ( do inglês Applied Computing
Research Group)
S-SPGs - Grafos Mínimos em Série Paralela ( do inglês Minimal Series Parallel Graphs)
MOS - Escalonamento Multiobjetivo (do inglês Multi-objective Scheduling) ACO - Colônia de Formigas (do inglês Ant Colony)
BAT - Algoritmo do Morcego (do inglês Bat Algorithm) VMs - Máquinas Virtuais (do inglês Virtual Machines)
Índice de símbolos
V - conjunto de nós do grafo E - arestas do grafo
G - grafo composto por nós e arestas j - índice que representa tarefas i - índice que representa tarefas
Ti, Tj- tarefas com uma ordem de dependência onde j > i
L - distância entre Ti e Tj
S - conjunto de tempos de cada mensagem ao passar pelo canal
k - índice dos valores de tempo possíveis para os caminhos do fluxo de integração
n - número de tarefas do fluxo de integração
Tx- tempo das tarefas que fazem parte dos caminhos do fluxo de integração
Tt- tempo máximo encontrado a partir dos tempos de Tx
C - tempo de troca de contexto
F - tempo de adquirir recurso para executar uma tarefa G(x) - função que associa os valores aleatórios de C e F Tg- tempo de gestão de recursos computacionais
m - taxa de chegada das mensagens no processo r - número dethreads utilizadas
x Índice de símbolos
Mak - makespan de um processo de integração Mf- makespan final
Agradecimentos
A
gradeço primeiramente aos professores orientadores do Grupo de Pesquisa em Computação Aplicada (GCA) Dr. Rafael Z. Frantz e Dra. Fabricia Carneiro Roos Frantz por todo apoio durante a realização deste trabalho. Também agradeço à CAPES, pela Bolsa de mestrado taxa PROSUP/CAPES concedida.Resumo
Research is creating new knowledge.
Neil Armstrong, Astronauta (1930-2012)
A
plicações são usualmente utilizadas por empresas para aperfeiçoar seus processos de negócios. Essas aplicações compõem um ecossistema de software que é heterogêneo sendo desenvolvidas sem preocupação com uma possível integração, dificultando assim a sua reutilização. A área de integração de aplicações empresariais proporciona metodologias, técnicas e ferramentas que são utilizadas no desenvolvimento de processos de integração. Um processo de integração pode ser dividido em dois níveis: um de execução do processo e outro de gestão de recursos. O problema abordado nessa dissertação consiste em identificar os elementos presentes nestes níveis que impactam no tempo de execução do processo (makespan). Conhecer e poder determinar o tempo de execução de um processo de integração é um problema que envolve o conhecimento de todos os elementos que formam o fluxo de trabalho. Nesse contexto, esta pesquisa propõe que o makespan pode ser determinado através de um modelo matemático. Este modelo pode ser utilizado para determinar o makespan de qualquer processo de integração. Utilizando a Teoria dos Grafos é possível representar o fluxo de trabalho de um processo de integração através de um grafo acíclico direcionado (DAG). Utilizando dados coletados de um sistema real foi possível verificar os valores encontrados pelo modelo matemático.Palavras-Chaves: Integração de Aplicações Empresariais, Teoria dos Grafos, Processo de Integração, Modelagem Matemática.
Abstract
Once made equal to man,
woman becomes his superior.
Socrates, Philosopher (469 BC - 399 BC)
A
pplications are often used by companies to streamline their business processes. These applications make up a software ecosystem that is heterogeneous being developed without concern for possible integration, making it difficult to reuse it. The area of enterprise application integration provides methodologies, techniques and tools that are used in the development of integration processes. An integration process can be divided into two levels: one process execution and the other resource management. The problem addressed in this dissertation is to identify the elements present at these levels that impact the execution time of the process. Knowing and being able to determine the execution time of an integration process is a problem that involves knowledge of all the elements that make up the workflow. In this context, this research proposes that this execution time (makespan) can be determined through a mathematical model. This model can be used to determine the makespan of any integration process. Using the Graph Theory it is possible to represent the workflow of an integration process through a directed acyclic graph (DAG). Using data collected from a real system it was possible to verify the values found by the mathematical model.Keywords: Integration of Business Applications, Graph Theory, Integration Process, Mathematical Modeling.
Capítulo 1
Introdução
An investment in knowledge pays
the best interest.
Benjamin Franklin, Politician (1706-1790)
1.1 Contexto da Pesquisa
A competitividade e esforço das empresas em busca da excelência têm impulsionado sua procura por alternativas tecnológicas para dar suporte aos seus processos de negócios. As aplicações de software que são adquiridas pelas empresas ao longo do tempo visam atender atividades específicas dentro das atividades de processos de negócio, e constituem o seu ecossistema de software [42].
O ecossistema de software costuma ser bastante heterogêneo em função das aplicações serem desenvolvidas com distintas tecnologias, rodar em sistemas operacionais distintos ou ainda usarem modelos de dados distintos. É comum que um processo de negócio envolva duas ou mais aplicações, assim, para fazer com que estas aplicações trabalhem em conjunto, a empresa precisa integra-las de preferência com o mínimo de impacto possível no funcionamento individual das mesmas.
A área de Integração de Aplicações Empresariais (EAI) proporciona metodologias, técnicas e ferramentas que, através de um processo de integração, conectam o conjunto de aplicações que estão envolvidas no processo de negócio, de modo que estas aplicações colaborem uma com as outras, seja compartilhando dados ou funcionalidades [28]. Os processos de
2 Capítulo 1. Introdução
integração são compostos por tarefas e possuem um fluxo de trabalho, onde uma tarefa sucede a outra conforme uma relação de dependência em que a tarefa sucessora depende das antecessoras. Tarefa implementam um padrão de integração documentado por Hohpe e Woolf [28] para processar dados encapsulados em mensagens.
As plataformas de integração são ferramentas de software especializadas para projetar, implementar, monitorar e executar processos de integração. Diversas plataformas de integração são inspiradas nos padrões de Hohpe e Woolf [28] e implementadas com a linguagem de programação Java. O estilo de integração destas plataformas é baseado em um sistema intitulado Sistema de Mensagens. Normalmente, as plataformas de integração fornecem uma linguagem de domínio específico (DSL), um kit de ferramentas de desenvolvimento, um motor de execução e uma ferramenta de monitoramento [20].
O tempo de execução do fluxo de trabalho (makespan) é o tempo necessário para concluir todas as tarefas no fluxo de trabalho do processo de integração. Uma definição equivalente é o tempo máximo de execução entre todos os caminhos em todo o fluxo de trabalho. Conhecer e determinar o tempo de execução de um processo de integração, é um problema que envolve o conhecimento das tarefas que formam o fluxo de trabalho do processo. O tempo de execução possui impacto no desempenho do processo de integração uma vez que representa o tempo que uma mensagem leva para ser processada por todas as tarefas que integram o fluxo de trabalho do processo.
Deste modo, conhecer e poder estimar esse tempo auxilia os engenheiros de software na tarefa de configurar o motor de execução, de modo a minimizar a utilização de recursos computacionais. Assim, conhecer o tempo de execução de um processo de integração permite atender requisitos de qualidade de serviço dos processos.
A Teoria dos Grafos pode ser utilizada como uma ferramenta para auxiliar a determinar o makespan de processos de integração, visto que esta teoria considera o fluxo de trabalho dos grafos de maneira semelhante ao de processos de integração. Além disso, o formalismo desta teoria pode ser atrelado aos elementos que constituem o makespan de um processo de integração. A revisão da literatura foram encontrados trabalhos com foco em determinar o makespan, geralmente aparecendo em modelos para diversas áreas de conhecimento. No entanto, não foram encontrados trabalhos cujo foco é desenvolver um modelo matemático para determinar o makespan de processos de integração.
1.2. Motivação 3
1.2 Motivação
Na pesquisa científica, a modelagem matemática tem o objetivo de prever o comportamento de um sistema em cenários específicos, cuja experimentação real não é possível, seja por questão de custos ou de demanda de tempo [7]. A utilização da modelagem matemática facilita o entendimento do sistema estudado, podendo ser uma ferramenta relevante em um processo de tomada de decisão.
Para obter uma estimativa do tempo de execução de um fluxo de trabalho é necessário identificar quais são os tempos de execução dos elementos que formam esse fluxo. Estimar omakespan é uma parte essencial da otimização de um processo de integração e afeta de forma direta o resultado da otimização do processo, independentemente da técnica utilizada. Em outras áreas há estudos sobre essa estimativa do makespan, mas isso não foi estudado de forma diligente para processos de integração de aplicações, e nem vem sendo tão bem desenvolvido quanto problemas de agendamento e de escalonamento.
Para estimar o makespan de um processo de integração, é necessário identificar as estimativas de tempo de execução das tarefas que formam este processo, além disso, é pertinente levar em conta a heterogeneidade das mesmas e também dos recursos de computacionais utilizados na execução. O tempo de transferência de dados e de troca de contexto, são elementos estocásticos por natureza.
Identificados os tempos envolvidos no makespan dos processos de integração, pode ser desenvolvido um modelo matemático. O formalismo da Teoria dos Grafos pode servir como uma ferramenta matemática para contemplar esses tempos e determinar o makespan dos processos de integração. Conhecer o tempo de execução através de um modelo descritivo pode fornecer informações e auxiliar ao engenheiro de software responsável pela configuração do motor de execução das plataformas de integração.
Ao configurar o motor de execução, o número de threads que será utilizada é geralmente escolhido a priori pelos engenheiros de software. Se o número de threads no pool for superdimensionado, isso pode causar um desperdício de recursos computacionais. Por outro lado, se o número de
threads no pool for subdimensionado, isso causará uma execução mais lenta e poderá não atender aos atributos de qualidade [63].
4 Capítulo 1. Introdução O makespan para processos de integração de aplicações empresariais pode ser determinado através da utilização de um modelo matemático, que permite identificar e descrever os tempos de execução de um fluxo de trabalho, tendo como base o formalismo da Teoria dos Grafos.
1.3 Objetivos
Prever o tempo de execução de um processo de integração representa um passo importante para a diminuição dos custos deste processo, como os recursos computacionais utilizados. Neste sentido, esta dissertação tem os seguintes objetivos:
1.3.1 Geral
Desenvolver um modelo matemático com base no formalismo matemático da Teoria dos Grafos para descrever o tempo de execução do fluxo de trabalho de um processo de integração e identificar as variáveis que impactam esse tempo.
1.3.2 Específicos
• Estudar, a partir da literatura, os elementos e as caraterísticas que fazem parte do fluxo de trabalho de um processo de integração.
• Apresentar as especificidades e os elementos do fluxo de trabalho de um processo de integração que impactam no seu tempo de execução. • Demonstrar a equivalência entre os elementos do fluxo de trabalho de
um processo de integração com os elementos da Teoria dos Grafos. • Elaborar um modelo matemático utilizando a Teoria dos Grafos, que
seja equivalente e represente o fluxo de trabalho de um processo de integração.
1.4 Metodologia
Do ponto de vista da sua natureza, esta é uma pesquisa aplicada, pois objetiva gerar conhecimentos para aplicação prática dirigida à solução de um problema específico, no caso, o makespan de processos de integração. Do
1.5. Resumo das Contribuições 5
ponto de vista dos objetivos, esta é uma pesquisa explicativa, visto que procura explicar os porquês domakespan e suas causas, por meio do registro, da análise, da classificação e da interpretação de processos de integração. Os meios técnicos da investigação desta pesquisa, ou seja, os procedimentos técnicos são de uma pesquisa experimental, quando determinamos um objeto de estudo, selecionamos as variáveis que seriam capazes de influenciá-lo, definimos as formas de controle e de observação dos efeitos que a variável produz neste objeto.
A base lógica da investigação desta pesquisa considerou uma abordagem hipotético-dedutiva, que iniciou-se com a formulação do problema e com sua descrição clara e precisa, a fim de obter um modelo simplificado e identificar outros conhecimentos e instrumentos, relevantes ao problema. Foram realizadas leituras dos referenciais teóricos, as quais conduziram discussões entre os integrantes do grupo de pesquisa GCA durante apresentações em seminários, permitindo deste modo o compartilhamento de ideias relevantes para a pesquisa.
Após esse estudo preparatório, na fase de observação foram estudados com base na literatura os elementos relacionados ao processo de integração que têm relação com o tempo de execução, além disso, também foi estudado o funcionamento do fluxo de trabalho de processos de integração. Ainda nesta fase, foram analisados os elementos da Teoria dos Grafos que melhor se aplicavam ao fluxo de trabalho dos processos de integração estudados.
A fase seguinte foi a da formulação de hipóteses, ou descrições-tentativa, consistentes com o que foi observado. Essas hipóteses foram utilizadas para fazer prognósticos, os quais foram comprovados ou não por meio de testes, experimentos ou observações mais detalhadas. A partir disso, foi organizada uma equivalência entre os elementos do processo de integração e a Teoria dos Grafos. Assim, foi possível elaborar um modelo utilizando o formalismo matemático da Teoria dos Grafos.
Após a elaboração do modelo matemático, foi realizada a verificação do mesmo através da comparação dos resultados do modelo matemático com os dados obtidos a partir de sistemas reais. Por fim, na última etapa desta pesquisa, foi realizada a transcrição dos resultados alcançados para esta dissertação.
1.5 Resumo das Contribuições
Esta dissertação é parte integrante do projeto de pesquisa “Desenvolvimento de um Motor de Execução Eficiente para Plataformas de
6 Capítulo 1. Introdução 2018 Locais/Regionais 2017 SFCT SC18 CRICTE CRICTE CRICTE SFCT
Autor principal Coautor
2 5 6 1 4 8 2019 3
Figura 1.1:Publicações trabalhadas e envidas no período do mestrado.
Integração de Aplicações Adaptado à Computação em Nuvem”, do grupo GCA. Busca-se, com este trabalho, contribuir para melhorar a qualidade dos processos de integração desenvolvidas pelos engenheiros de software. As principais publicações e contribuições estão listadas a seguir, conforme a Figura1.1.
• No evento XXIII Jornada de Pesquisa do Salão de Conhecimento 2018 -SC18 foi publicado um artigo que abordou os primeiros elementos que compõem o modelo matemático, identificando que omakespan possui tempos de execução das tarefas e do caminho que configura o fluxo do processo de integração [44].
• No evento Congresso Regional de Iniciação Científica e Tecnológica em Engenharia - CRICTE foram consideradas novas variáveis para o modelo matemático já desenvolvido até então. Assim, puderam ser inseridos os tempos de gestão de recursos computacionais que utilizados pelo motor de execução do processo de integração [45]. • Também apresentados no evento Congresso Regional de Iniciação
Científica e Tecnológica em Engenharia - CRICTE, onde a participação foi como coautora nos dois trabalhos. Um dos trabalhos considerava um modelo matemático que utilizavamakespan como uma ferramenta para determinar o número mínimo dethreads para motores de execução de plataformas de integração de aplicações [50]. Enquanto outro trabalho realizava uma revisão bibliográfica sobre a minimização do makespan
como estratégia para otimizar plataformas de integração[37].
• Na sexta edição do evento local Seminário de Formação Científica e Tecnológica (SFCT), foi apresentado uma versão do modelo matemático que pode ser dividida em dois níveis: de execução e de gestão de
1.6. Estrutura do Documento 7
recursos computacionais [46]. Outro trabalho apresentado no evento teve a participação como coautora, e fazia uma revisão bibliográfica para determinar qual o melhor método para otimizar os motores de execução de plataformas de integração. [36].
1.6 Estrutura do Documento
Essa dissertação está organizada da seguinte maneira:
Capítulo1. Compreende essa introdução. A Seção1.1descreve o contexto de pesquisa; a Seção 1.2 explica a motivação do trabalho de pesquisa. A Seção 1.3 descreve o objetivo geral e os objetivos específicos; a Seção1.4apresenta a metodologia utilizada para o desenvolvimento do trabalho; a Seção1.5demonstra todas as publicações realizadas durante o período do mestrado.
Capítulo2. Proporciona para o leitor uma revisão da literatura técnica e científica relacionadas à pesquisa desenvolvida nessa dissertação. A Seção2.1proporciona uma breve introdução da integração de aplicações empresariais, apresentando os estilos e topologias de integração; a Seção 2.2 apresenta elementos das plataformas de integração, como a linguagem de domínio específico e também o motor de execução; a Seção2.3 apresenta a Teoria dos Grafos evidenciando seus elementos e suas principais características; a Seção 2.4 introduz as definições de verificação e de validação, além de mostrar as principais técnicas de verificação utilizadas; a Seção 2.5, introduz os trabalhos relacionados identificados ao longo dessa pesquisa.
Capítulo3. Apresenta o modelo matemático desenvolvido durante esta pesquisa; a Seção3.1 apresenta a descrição do problema de pesquisa; a Seção3.2 demonstra o modelo matemático construído, considerando o fluxo de trabalho de um processo de integração para determinar o seu tempo de execução.
Capítulo4. Introduz o protocolo que aplicamos para conduzir este estudo experimental; a Seção 4.1 apresenta a questão de pesquisa à ser respondida pelo experimento e a hipótese levantada; a Seção 4.2
descreve o ambiente de experimentação utilizado; a Seção4.3apresenta as variáveis dependente e independentes consideradas no experimento; a Seção 4.4 descreve a execução do experimento e como foi realizada a coleta dos dados; a Seção4.5 apresenta os resultados do experimento; a
8 Capítulo 1. Introdução
Seção4.6contém a análise e comparação do experimento com o modelo matemático elaborado no decorrer da pesquisa; a Seção4.7apresenta as ameaças a validade.
Capítulo5. Apresenta as conclusões chegadas a partir da pesquisa desenvolvida nessa dissertação, e comenta as possíveis direções de pesquisa que podem ser desenvolvidas a partir deste trabalho.
Capítulo 2
Revisão da Literatura
Success is a lousy teacher.
It seduces smart people into thinking they can’t lose.
Bill Gates, Business magnate & author (1955)
P
ara o desenvolvimento deste trabalho é necessário conhecer um conjunto de temas fundamentais que dizem respeito ao contexto da pesquisa. A Seção2.1trata da integração de aplicações empresariais, enquanto a Seção 2.2 apresenta elementos das plataformas de integração. A Seção2.3aborda elementos da Teoria dos Grafos utilizada para a modelagem matemática realizada neste trabalho. A Seção 2.4 apresenta a definição de verificação e validação e algumas técnicas que podem ser utilizadas para verificar o modelo matemático a ser proposto. Por fim, a Seção 2.5 discute os trabalhos relacionados à modelos matemáticos que têm como foco o estudo e minimização do makespan, e a Seção 2.6 resume o capítulo.2.1 Integração de Aplicações Empresariais
A constante evolução tecnológica reflete em modificações na dinâmica de negócios das empresas, o que demanda uma frequente adaptação em seus processos de negócio. O suporte computacional necessário para implantar os processos de negócios desponta na forma de aplicações, estas que se tornaram indispensáveis nos ambientes de negócio. As empresas costumam desenvolver de forma independente suas próprias aplicações, personalizar ou adquirir de terceiros pacotes de software, o que, no decorrer dos anos,
10 Capítulo 2. Revisão da Literatura
Figura 2.1:Ambiente de integração de aplicações empresariais.
acarreta em um ecossistema desoftware heterogêneo, principalmente no que diz respeito a tecnologias de desenvolvimento e modelos de dados utilizados. Essa heterogeneidade entre as aplicações constitui um problema que dificulta a reutilização de aplicações sempre que há necessidade de criar ou modificar um processo de negócio na empresa. Isso porque nem sempre a empresa possui especialistas habilitados para trabalhar com essa multiplicidade de tecnologias. Deste modo, o ecossistema de software da empresa torna-se ineficiente, pois as aplicações existentes não fornecem uma interface que permita uma troca de dados ou compartilhamento de funcionalidades entre as aplicações, ou seja, a integração de aplicações nem sempre é uma tarefa trivial.
Uma alternativa é desenvolver soluções de integração, também conhecidas como processos de integração, os quais orquestram as aplicações do ecossistema desoftware, fornecendo aos usuários uma visão de alto nível das aplicações integradas com as quais um processo de negócio interage. De modo geral, o ambiente de uma integração de aplicações pode ser observado na Figura 2.1, onde as diferentes aplicações de um ecossistema de software
fazem parte de um processo de integração, que funciona como uma camada intermediária entre as aplicações da empresa e o processo de negócio a ser realizado [16].
O campo de estudos da Integração de Aplicações Empresariais (EAI) consiste em uma resposta há décadas de construção de aplicativos monolíticos, que não foram projetados para funcionar em conjunto com outros aplicativos Hohpe e Woolf [28]. Tendo como objetivo possibilitar
2.1. Integração de Aplicações Empresariais 11
que as aplicações já adquiridas pelas empresas, que apesar de estarem previamente segregadas, possam dar conta dos novos processos de negócios que venham a surgir dentro da empresa. Segundo Frantz et al. [19], a integração faz com que seja preservada a sincronização de dados e viabilizada a incorporação de novas funcionalidades entre as aplicações, sem que as mesmas tenham seu funcionamento prejudicado.
Deste modo, a EAI possibilita que um determinado grupo de aplicações que compõem o ecossistema desoftware de uma empresa, possam trabalhar de forma conjunta efetivamente, maximizando os benefícios de cada aplicação e do sistema de informação como um todo, tendo como objetivo, segundo Juric et al. [33], atender os processos de negócios desta empresa.
As empresas buscam utilizar a EAI para estabelecer a comunicação entre suas aplicações, fazendo com que, apesar de serem focadas em domínios específicos, elas possam ser utilizadas como parte de um todo. Para orquestrar estas aplicações de maneira integrada é necessário o que chamamos de processo de integração, que nos permite reutilizar os dados ou funcionalidades pertencentes as aplicações da empresa, de modo que seja possível implementar os processos de negócio.
Um processo de negócio pode ser suportado por um ou mais processos de integração, no entanto cada processo vai orquestrar apenas um subgrupo de aplicações do ecossistema de software da empresa. O objetivo de um processo de integração pode ser, por exemplo, integrar funcionalidades de algumas aplicações e dados de outra aplicação. É importante considerar que uma funcionalidade de uma aplicação pode ser útil para vários processos de negócios, deste modo, ela pode ser utilizada em outros processos de integração [19].
A demanda pela utilização de recursos disponibilizados pelas aplicações por mais de um processo de integração, é um exemplo dos desafios relacionados as aplicações que dão suporte aos processos de negócios, pois o ideal seria que cada processo de integração apresentasse um baixo acoplamento. Um baixo acoplamento consiste em quanto uma aplicação do ecossistema de software depende de outra para funcionar.
Além dos fatores já citados, outras dificuldades acontecem em decorrência das constantes mudanças nos processos de negócios, pois de acordo com Hohpe e Woolf [28], conforme estas ocorrem, podem exigir que sejam incluídas mais aplicações no processo de integração, modificando o processo constantemente.
12 Capítulo 2. Revisão da Literatura
No que se refere as grandes diferenças entre as aplicações, seja no âmbito de diferentes sistemas operacionais, diferentes distribuições ou tipos de dados e framework, a dificuldade está em encontrar um profissional que trabalhe com este ambiente. Grande parte das aplicações que fazem parte do ecossistema de software das empresas não foram projetadas para serem integradas, ou estão obsoletas. As aplicações que são ditas monolíticas, apesar de ainda serem utilizadas dentro da empresa, não se tem mais acesso ao código fonte, deixando assim de receber manutenção e evoluir.
Uma parcela das aplicações das empresas está presente na nuvem, também existe uma tendência para que as aplicações migrem cada vez mais das máquinas reais para as virtuais. Assim, é importante considerar o fato de que as redes de internet nem sempre são tão rápidas quanto o esperado, ou pior ainda, não são confiáveis o suficiente para fazer com que os dados que fluem entre as aplicações que estão nas nuvens estejam em segurança.
No entanto, apesar de as empresas buscarem utilizar da integração de aplicações para obter maior rapidez nos seus processos de negócios, o custo para fazer com que as aplicações “conversem” entre si pode ser maior do que o custo inicial de adquiri-las. Segundo Juric et al. [33] para diminuir os custos de integração, os projetos devem ser realizados no menor tempo possível, buscando fornecer resultados rapidamente, já que os recursos para a integração são limitados [40]. Assim, para evitar custos adicionais desnecessários com a implementação de um processo de integração, é essencial realizar analises para garantir que o processo não possua nenhum problema, principalmente em no que diz respeito ao seu desempenho.
2.1.1 Estilos de integração
As abordagens que podem ser utilizadas para realizar a EAI são intituladas de Estilos de Integração, de modo que, os quatro principais estilos baseados na obra de Hohpe e Woolf [28] são listados a seguir:
Transferência de Arquivos - Acontece quando os arquivos de dados são produzidos por uma aplicação e são repassados para serem utilizados por outra. Como essa transferência pode ser implementada em diferentes plataformas e linguagens, este estilo é dito como o mais comum. No entanto, este estilo de integração pode ser utilizado apenas para compartilhar dados e não funcionalidades. Os dados a serem compartilhados devem estar em um formato comum, que seja padronizado entre todas as aplicações que fazem parte do conjunto
2.1. Integração de Aplicações Empresariais 13
integrado ou que seja passível de converter de formato. Os dados gerados pela aplicação de origem são armazenados e tratados em lotes. Para realizar o envio destes dados geralmente existe um gatilho, no entanto as aplicações de origem e destino devem estar em acordo sobre quando este arquivo estará pronto para ser importado, ou seja, quanto ao tempo para a sua leitura, além de quando será possível que os dados sejam apagados. Neste âmbito, o custo computacional e a preocupação em gerenciar os arquivos produzidos mantendo o formato de seus dados aumenta, na medida em que os dados gerados pela aplicação de origem são importados por muitas aplicações de destino, ou quando o fluxo de importação é muito alto. Deste modo, a utilização deste estilo é recomendada para cenários onde a integração ocorre eventualmente e em intervalos pontuados. Sendo que, a principal vantagem que este estilo apresenta é a de baixo acoplamento entre as integrações, utiliza-se um mecanismo comum de transferência de dados, o que faz com que não seja necessário conhecer ou interferir no funcionamento das aplicações envolvidas. A Figura 2.2 representa um modelo da transferência de arquivos.
Figura 2.2:Estilo de Transferência de Arquivos.
Base de Dados Compartilhada - Este estilo ocorre quando as aplicações envolvidas na integração acessam uma mesma base de dados. As diferentes aplicações envolvidas não apresentam ligações entre si, somente com o banco de dados. A vantagem deste estilo é de que os dados podem ser compartilhados pelas aplicações de forma rápida e consistente, além de permitir que os dados sempre estejam atualizados e sem duplicações. No entanto, quando se tem esse banco de dados centralizado e único, a sincronização e padronização dos dados são tarefas necessárias mas que acabam por ser onerosas. Deve ser criado um modelo único de dados, o que torna custoso dar o suporte
14 Capítulo 2. Revisão da Literatura
necessário a cada uma das aplicações, além disto, existe a complexidade de implementar este banco. Quanto mais acessos, o atendimento simultâneo das diferentes aplicações acarreta em uma modelagem dos dados mais complicada. A Figura2.3representa um modelo deste estilo de integração.
Figura 2.3:Estilo de Base de Dados Compartilhada.
Chamada de Procedimento Remoto - Ao contrário dos estilos tratados anteriormente, busca a integração de processos, onde uma aplicação invoca procedimentos de outra. OSkeleton é uma interface através da qual a aplicação disponibiliza algumas de suas funcionalidades, que são acessadas através da interfaceStub. Na Figura2.4 pode se perceber que a Aplicação A realiza a comunicação através de seu Stub, que por conseguinte se comunica com o Skeleton da aplicação B, fazendo por meio desta comunicação uma chamada de procedimento. A aplicação B então executa o procedimento solicitado e retorna o resultado da execução para a aplicação A, através dos mesmos meios que realizaram a chamada.
2.1. Integração de Aplicações Empresariais 15
Este estilo traz como vantagens o encapsulamento das aplicações, pois a aplicação A que realiza a chamada não tem acesso direto aos dados internos da aplicação B. No entanto, existe uma forte dependência entre as aplicações envolvidas, pois o seu acoplamento é alto, assim caso uma das aplicações falhe o resultado da integração é afetado.
Sistema de Mensagem - Utiliza de um Message Bus para realizar a integração, que acontece quando, duas ou mais aplicações encaminham mensagens para indicar que ocorreu algum evento que seja do interesse das demais. Estas mensagens que as aplicações enviam são pacotes de dados, que utilizam-se de caminhos lógicos intitulados slots para conectar as aplicações e enviar as mensagens. As aplicações envolvidas são divididas em Emissora e Receptora, pois enquanto a primeira escreve a mensagem no slot, enviando-a, a segunda recebe e lê esta mensagem no slot. A mensagem utilizada por este estilo é uma estrutura ordenada de dados que é dividida em duas partes, cabeçalho e corpo, sendo que o cabeçalho contém meta-informações acerca da mensagem, como por exemplo, seu autor e origem. Já o corpo da mensagem é ignorado pelo sistema de mensagens pois contém os dados que estão sendo transmitidos. Quem coordena e faz o gerenciamento dos envios e recebimentos das mensagens é o sistema de mensagens, cuja principal tarefa é realizar a transferência das mensagens. O slot utilizado por este estilo permite a escalabilidade e desacoplamento entre as aplicações, pois além de realizar a troca de mensagens, o uso de filtros também possibilita que sejam executadas ações como filtragem e transformação das mensagens. A Figura 2.5 representa um modelo de sistema de mensagens.
Figura 2.5:Estilo de Sistema de Mensagem.
2.1.2 Topologias de integração
Para realizar a integração podem ser utilizadas plataformas especializadas para este fim, sendo assim, os processos de integração são estruturados
16 Capítulo 2. Revisão da Literatura
através de topologias de integração. As topologias definem como as aplicações irão se comunicar, sendo as mais empregadas na EAI:
point-to-point, hub-and-spoke emessage bus.
Point-to-point tem por objetivo conectar as aplicações, uma com as outras, de forma a permitir o compartilhamento de dados ou de funcionalidades, e para tanto modifica o código fonte das mesmas. Deste modo, não há necessidade de uma plataforma específica para realizar a integração, visto que as alterações são realizadas diretamente no algoritmo, conectando ponto a ponto as aplicações necessárias para o processo de integração. Como as aplicações estão ligadas, é pertinente que as duas sempre estejam funcionando ao mesmo tempo. Inicialmente a implementação desta topologia é simples, pois envolve apenas duas aplicações, no entanto conforme novas aplicações são agregadas ao processo de integração, elas começam a apresentar um número de conexões que cresce exponencialmente. Nesta topologia quando for implementado o estilo de Transferência de Arquivo, as aplicações a serem conectadas precisam saber o nome do arquivo e seu tipo, deste modo, aquele que programar a transferência do arquivo deve coordenar estes fatores. As Chamadas de Procedimento Remoto são utilizadas nesta topologia para que as aplicações possam compartilhar uma dada funcionalidade, ou seja, existe a aplicação que faz uma chamada pela funcionalidade enquanto a outra executa-a retornando apenas um resultado.
Hub-and-spoke possui um centro de referência, sendo implementada através da criação de uma estrutura central de comunicação chamada de hub, que conecta as diferentes aplicações através de ligações, chamadas de spokes. Assim, uma aplicação manda uma mensagem para outra aplicação, através do hub, que é o responsável por encaminhar estas mensagens, através do spoke, que executa o papel de distribuidor das mensagens. Nesta topologia, as mensagens que passam pelohub devem levar no seu cabeçalho a aplicação para a qual devem ser enviadas, isto é, o endereço de destino. Nesta topologia a comunicação acontece através da utilização de mensagens, o que, segundo Hohpe e Woolf [28] reduz o número de ligações necessárias no conjunto de aplicações a ser integrado. Neste sentido, uma mensagem é um pacote de informação, cujo cabeçalho possui as informações de origem e destino ou de prioridade, enquanto o corpo tem as informações que estão sendo compartilhadas pela aplicação de destino.
2.2. Plataformas de integração 17
Message bus realiza a comunicação através de uma infraestrutura que é semelhante ao hub-and-spoke, pois possui um elemento central, fazendo com que cada conjunto de aplicações não se comunique de forma direta. Deste modo, o Message Bus é baseado em slots que conectam as diferentes aplicações da solução de integração, permitindo que as aplicações trabalhem de maneira conjunta, embora não estejam ligadas. Na topologia menssage bus quando uma aplicação deseja enviar uma mensagem para outra, esta precisa apenas saber qual deve ser o slot da aplicação, pois é o slot que vai definir o fluxo de mensagens entre as aplicações. Nesta topologia não há necessidade de que as aplicações integradas utilizem o mesmo formato de dados, visto que podem ser criados adaptadores entre o menssage bus e cada uma das aplicações integradas. Além disso, existe a possibilidade de trabalhar com uma complexidade maior de integração, pois estes adaptadores podem executar outras tarefas como roteamento, monitoramento e até mesmo a correção de erros. Outra facilidade é de que nesta topologia se tem a vantagem de permitir que as aplicações trabalhem de forma conjunta, mas sem comprometer o seu funcionamento individual, isto é, se uma das aplicações não puder ser executada, ela não irá comprometer o funcionamento das demais aplicações.
Comparando as topologias acima citadas, a topologia de Message Bus apresenta vantagens sobre a topologia Hub-and-Spoke, como por exemplo, quando se tratam dos adaptadores que com oHub executam apenas a tarefa de roteamento, ao contrário da anterior. Outro fator importante diz respeito ao custo de implementação das topologias, pois enquanto a topologia Point-to-Point tem um menor custo e tempo de implementação, esta também apresenta o maior custo para executar a manutenção, devido ao alto nível de acoplamento entre as aplicações integradas. Enquanto que a Message Bus
apresenta um maior custo e tempo de implementação, mas que, a longo prazo tem uma manutenção muito mais barata.
2.2 Plataformas de integração
Para realizar a integração de aplicações são utilizadas plataformas especializadas para este fim, que dão suporte para a modelagem e implementação dos processos de integração, dentre as plataformas de integração de código aberto podemos citar, o Ibsen e Anstey [30], o Fisher et al. [15], Dossot et al. [13] e Frantz et al. [19].
Um processo de integração possui dois níveis conceituais envolvidos no seu desenvolvimento: nível de projeto do processo e nível da sua execução.
18 Capítulo 2. Revisão da Literatura
No nível de projeto está o processo conceitual com suas portas, tarefas,slotse etc, elementos que fazem parte da linguagem de domínio específico de cada plataforma de integração. Enquanto no nível de execução do processo está a sua execução em uma máquina concreta com seus recursos computacionais e os tempos de gestão desses recursos, elementos estes intrínsecos ao motor de execução das plataformas de integração.
O estilo de integração utilizado pelas principais plataformas de integração é o Sistema de Mensagem (Messaging). Este estilo utiliza de umMessage Bus
para realizar a integração, que acontece quando, duas ou mais aplicações encaminham mensagens para indicar que ocorreu algum evento que seja do interesse das demais. Estas mensagens que as aplicações enviam são pacotes de dados, que utilizam-se de caminhos lógicos intitulados Canais para conectar as aplicações e enviar as mensagens. As aplicações envolvidas são divididas em Emissora e Receptora, pois enquanto a primeira escreve a mensagem no slot, enviando-a, a segunda recebe e lê esta mensagem no slot. A mensagem utilizada por este estilo é uma estrutura ordenada de dados.
Normalmente, as plataformas de integração fornecem uma linguagem de domínio específico (DSL), um kit de ferramentas de desenvolvimento, um motor de execução e uma ferramenta de monitoramento [20]. A DSL possibilita desenvolver um modelo conceitual que descreva num nível abstrato o processo de integração. Já o kit de desenvolvimento é um conjunto de ferramentas de software que transforma o modelo desenvolvido em um código executável, ou seja, ela permite a implementação do processo. O motor de execução proporciona o suporte necessário à execução dos processos de integração, sendo ele o responsável pelo gerenciamento dos recursos computacionais que executam o processo. A ferramenta de monitoramento é utilizada para detectar a ocorrência de possíveis erros no decorrer da execução de processos de integração.
2.2.1 Linguagem de domínio específico
As plataformas de integração são utilizadas para dar apoio aos processos de modelagem e implementação dos processos de integração. Deste modo, um modelo do processo é expressado através da DSL. Segundo Ghosh [22], DSL é uma linguagem desenvolvida especificamente para um domínio concreto, de maneira que sua linguagem precisa captar toda a semântica e vocabulário de seu domínio.
Uma DSL costuma ser de fácil entendimento e ajuda a expressar uma abstração que está muito próxima ao domínio do problema. Apesar de ser
2.2. Plataformas de integração 19
limitada, e com expressividade voltada ao seu domínio, o esforço para seu desenvolvimento é alto, pois é necessário que sua aplicabilidade esteja bem clara, sendo muito restrita ao domínio. Cada DSL possui uma sintaxe concreta, sintaxe abstrata, semântica, um meta-modelo e o próprio modelo.
A tecnologia Guaraná é usualmente utilizada no grupo de pesquisa, portanto foi escolhida para realizar a experimentação e desenvolvimento deste trabalho. Essa plataforma proporciona uma linguagem de domínio específico que permite projetar processos de integração a um alto nível de abstração utilizando uma sintaxe concreta gráfica e conceitos de modelagem intuitivos que são baseados nos padrões de integração documentados por Hohpe e Woolf [28] . Os modelos conceituais projetados na tecnologia Guaraná utilizando uma linguagem gráfica, sendo independentes de plataforma, de modo que os engenheiros de software não dependem de conhecimentos específicos em tecnologias de integração de baixo nível para construir processos de integração.
A DSL é transformada em código executável por uma biblioteca Java que permite a implementação do código através de uma Interface de Programação de Aplicativos (API). Para executar esse código, as plataformas de integração utilizam os motores de execução, que neste âmbito, interpretam o processo de integração que foi modelado a partir da DSL. O ponto inicial dos conceitos é o processo de integração, que segundo Frantz et al. [19] representa um conjunto de processos que cooperam com o objetivo de integrar várias aplicações. Um processo pode ser visto, de maneira simplificada, como um processador de mensagens.
20 Capítulo 2. Revisão da Literatura
A Figura2.6 mostra a notação gráfica utilizada pela tecnologia Guaraná e apresenta também os principais conceitos envolvidos em um processo de integração. Esses conceitos são descritos no que segue.
Aplicação: Programas utilizados pelas empresas para solucionar uma necessidade específica em seus processos de negócio.
Processo de integração: A organização de um processo de integração acontece através de uma arquitetura de pipe-and-filters [3], isto é, o fluxo de dados se dá através de slots (pipes) que atuam comobuffers, e que tem a função de interligar as entradas e saídas dos filtros (filters), neste caso intitulados como tarefas.
Portas: Responsáveis por fazer a comunicação com as aplicações. Estas portas podem ser: (a) de entrada, (b) saída, (c) solicitação ou resposta. As portas possibilitam o envio e recebimento de mensagens. Assim, a porta de entrada envia uma mensagem para um slot e este a disponibiliza para uma tarefa. Já a porta de saída lê sempre uma mensagem a partir de um slot e a deixa disponível para o elemento seguinte no fluxo. Portas de solicitação e resposta permitem a comunicação entre o processo e as aplicações integradas. A finalidade de uma porta é abstrair os detalhes necessários para interagir com um componente de ligação, que, por sua vez, abstrai os detalhes necessários para interagir com um aplicativo ou com um processo.
Tarefa: Executa processamento sobre mensagens. Representa uma operação atômica que pode ser executada em mensagens, como dividir, agregar, converter, cortar, filtrar, correlacionar, mesclar, replicar, distribuir, enriquecer, simplificar, promover, rebaixar e atrasar. Pode ter uma ou mais entradas, por meio da qual recebe as mensagens e uma ou mais saídas, através das quais as mensagens resultantes do processamento são despachadas. Dependendo do tipo de operação, uma tarefa pode ser sem estado ou com estado. Em uma tarefa sem estado, a conclusão de sua operação não depende de mensagens anteriores ou futuras; ao contrário, a operação de uma tarefa com estado depende de mensagens anteriores ou futuras a serem concluídas.
Slot: É umbuffer que liga uma entrada de uma tarefa com a saída de uma outra tarefa, permitindo um processamento assíncrono de mensagens pelas tarefas. Umslot pode seguir diferentes disciplinas para organizar as mensagens que serão executas pela tarefa, como, por exemplo, uma saída baseada em prioridade. Cada slot recebe a mensagem que
2.2. Plataformas de integração 21
já foi processada da tarefa anterior e a deixa disponível para ser processada pela tarefa seguinte. Quando uma mensagem foi processada e despachada para o slot seguinte, a tarefa já esta apta para processar outra mensagem que aguarda no seuslot de entrada.
Mensagens também são um conceito importante dentro do processo de integração. Uma mensagem é uma abstração de uma parte da informação que é trocada e transformada por meio do processo de integração. É composta por um cabeçalho, um corpo e um ou mais anexos. Uma mensagem compõe-se de cabeçalho e corpo. O cabeçalho inclui propriedades personalizadas já pré-definidas, como identificador de mensagens, identificador de correlação e prioridade da mensagem. O corpo da mensagem contém os dados de carga, cujo tipo é definido pelo parâmetro de modelo na classe da mensagem. Anexos permitem que as mensagens transportem dados extras associados como uma imagem ou uma mensagem de e-mail.
De modo conceitual, um processo de integração é composto de um ou vários processos de integração onde as mensagens seguem o fluxo de integração formado pelo encadeamento de tarefas e slots. O fluxo de integração é implementado segundo o padrão arquitetural Pipes&Filters [3], onde filtros são implementados por tarefas. A execução de uma tarefa depende da disponibilidade de mensagens em todos os slots conectados à suas entradas. Os slots possibilitam a assincronia em um processo de integração e armazenam as mensagens até que estas possam ser processadas pela próxima tarefa no fluxo de integração.
2.2.2 Motor de Execução
Os motores de integração adotam como política de agendamento de tarefas as heurísticas de prioridade e a FIFO, além disso, utilizam a API Executor do Java para criar um pool global de threads, para fazer a alocação dos recursos computacionais para a execução dos processos de integração, dado que, as threads são utilizadas para processar as tarefas que compõe o fluxo de integração dos processos.
O motor de execução de uma plataforma de integração é o responsável em proporcionar o suporte essencial à execução de uma solução de integração. O núcleo do motor de execução, é construído com a API Executor, sendo considerado a parte central e mais importante do mesmo, visto que, ele o responsável pela coordenação das atividades que fazem parte de uma instância executada. Este elemento central do motor de execução também é
22 Capítulo 2. Revisão da Literatura
o responsável por executar as tarefas que vêm do fluxo da solução de integração, e possui em execução uma fila de tarefas, um conjunto dethreads
e três monitores [17].
O motor de execução interpreta um processo de integração implementado, executando as tarefas do processo por meio de recursos computacionais presentes neste motor, dentre as quais estão as threads de execução [57]. As
threads são usadas para proporcionar que as tarefas sejam executadas de forma simultânea, por meio da programaçãomultithreads [12].
Até a versão 5.0 do Java, seus recursos oferecidos deixavam sob a responsabilidade do programador a gerência dasthreads para os programas. No entanto, a versão 5.0 já inclui o pacote API Executor, que conta com recursos para auxiliar na utilização das threads [56]. As classes dessa API fornecem configurações que dão flexibilidade para pools dethreads, que vão desde indicar o número máximo de threads mantidas no pool sem executar, até o número máximo de threads permitidas no pool, entre outras, como o tipo de fila que será usada para manter as tarefas antes da execução.
Há várias opções de filas de tarefas na concurrency API do Java, que atendem a diferentes necessidades como: mensageria, produtor-consumidor, tarefas paralelas e assim por diante [56]. Nas plataformas de integração o estilo de integração segue um sistema de mensageria, assim, durante a execução de uma solução de integração, a fila de tarefas (work queue) segue o preceito de que o primeiro elemento que entra será o primeiro elemento a ser executado (FIFO).
A fila de tarefas deve armazenar as unidades de trabalho (work units), que são anotações referentes as tarefas que devem ser processadas e quando estas tarefas podem ser executadas. Em geral as tarefas são executadas o mais rápido possível, no entanto, é possível definir um tempo específico para que uma tarefa seja executada, o que auxilia na implementação de tarefas que precisem ser executadas seguindo alguma periodicidade [19].
Os recursos computacionais presentes no motor de execução e que permitem executar um programa são as chamadas threads. Considerando o contexto do motor de execução, asthreads representam o quanto de recurso computacional esta sendo alocado para processar as unidades de trabalho presentes na fila de tarefas [18]. Deste modo, sempre que chegarem novos elementos na fila de tarefas, as threads são informadas e concorrem para executar a unidade de trabalho.
A thread então consulta se a unidade de trabalho pode ser executada instantaneamente, se possível, a thread retira ela da fila para que a mesma
2.2. Plataformas de integração 23
possa ser executada. Caso a unidade de trabalho não possa ser executada imediatamente, ela permanece na fila, enquanto a thread entra em estado de espera enquanto não há uma nova entrada na fila de tarefas. Esta estratégia permite que as threads continuem trabalhando desde que exista uma tarefa pronta para ser executada [19].
Os monitores coletam e fornecem estatísticas sobre o uso da memória, da CPU e da fila de trabalho. O monitor de memória registra informações sobre como o sistema está utilizando a memória. O monitor dasthreads registra o tempo utilizado pelas threads na execução de unidades de trabalho, bem como o tempo de execução do sistema. O monitor da fila registra o tamanho da fila e o número total de unidades de trabalho que foram processadas. Os monitores foram implementados como threads independentes que são executados em intervalos regulares, coletam as informações anteriores, armazenam-na em um arquivo e ficam ociosas o mais rápido possível [16].
O Executor é iniciado a partir do carregamento e análise do seu arquivo de configuração da inicialização do sistema de log e da criação de uma fila de tarefas. O arquivo de configuração do Executor tem formato XML [8], e determina circunstâncias importantes como o número de threads que o motor vai utilizar, onde os monitores devem escrever as estatísticas geradas durante a execução, qual deve ser a periodicidade que será realizado o monitoramento e o arquivo de log devem ser reportadas as advertências e exceções que podem acontecer no decorrer da execução. Tendo inicializado o
Executor, o motor de execução pode ser inicializado de acordo com o Engenheiro de Software responsável, assim, quando o motor é iniciado, as
threads e monitores também são ativados [19].
As threads são iniciadas de forma assíncrona, implementando um ciclo que permite que as threads pesquisem a fila de tarefas enquanto a execução da solução de integração não estiver parada. O processamento de uma unidade de trabalho requer a execução de operação de invocação na tarefa associada, e para cada notificação de tarefa que o Executor recebe, o mesmo cria uma nova unidade de trabalho e anexa-a à fila de trabalho [16].
A partir da compreensão doExecutor podemos visualizar na Figura2.7o funcionamento do motor de execução. A fila de tarefas recebe por meio de uma entrada as unidades de trabalho, ou tarefas (T1,T2). Estas tarefas são provenientes de uma solução de integração, que apesar de possuir um fluxo de integração definido, tem uma distribuição aleatória para as entradas, isto é, podem entrar novas tarefas a qualquer momento. Para executar estar unidades de trabalho estão disponíveis um conjunto de threads, que após
24 Capítulo 2. Revisão da Literatura
Figura 2.7:Modelo conceitual do motor de execução.
executar a tarefa devolvem a mesma para a fila de tarefas que encaminha a tarefa concluída para a saída, seguindo este processo a cada novas entradas de tarefas [19].
Segundo estudos experimentais, a arquitetura pool de threads pode trazer um impacto no desempenho [2], visto que para manter os recursos computacionais trabalhando de forma eficiente, os mesmos devem acompanhar a carga de trabalho requisitada [10]. O tamanho do pool têm uma relação de dependência com o processo de integração à ser executado, assim a configuração do motor de execução é fundamental para garantir que o processo de integração tenha um bom desempenho, ou seja, para que possa alcançar as condições de serviço que o usuário necessita. Neste sentido, configurar o motor diz respeito à destinar a quantidade ideal de threads no pool, para atender aos requisitos solicitados. Sendo que, atualmente esse processo de dimensionamento do pool de threads é feito com base no conhecimento empírico dos engenheiros de software.
2.3 Teoria dos Grafos
O processo de busca de uma visão bem estruturada da realidade é fundamentalmente um fenômeno de modelagem. Podemos denominar de modelo cada interpretação de um sistema formal criado axiomaticamente. Como o objetivo básico da modelagem é alcançar uma compreensão aceitável da realidade, os modelos devem ser formulados de modo a demonstrarem apenas os principais elementos da realidade, simplificando ao máximo o método de solução utilizado. Os modelos possuem diversas vantagens, além do fato de simplificarem a representação de determinado sistema, podem revelar relacionamentos não aparentes, bem como facilitar a experimentação
2.3. Teoria dos Grafos 25
(ou o aprendizado por tentativa e erro controlado), o que não é, normalmente, viável em sistemas reais [23].
A teoria dos grafos é um ramo da matemática que estuda as relações entre os objetos de um determinado conjunto, por ser uma abstração, esta teoria permite a codificação dos relacionamentos entre objetos. De acordo com Rabuske [53] ela proporciona uma ferramenta simples, acessível e poderosa para construção de modelos. Um grafo é composto por um conjunto finito e não vazio V, e E uma relação binária sobre V. Os elementos V são pontos, e o par ordenado (v,w) ǫ E, onde v,w ǫ V é a linha que liga v a w [53]. A semântica dos grafos é bem definida, uma vez que são estruturas algébricas e podem ser utilizados para explicar situações complexas de uma forma compacta, visual e muito intuitiva [6].
Deste modo, um grafo G é definido como sendo um par ordenado (V,E), onde V é um conjunto enquanto E é uma relação binária sobre V, cuja representação de grafo é dada por G(V,E). Os elementos de V são chamados de vértices ou nós, enquanto os pares ordenados de E são denominados de arestas ou arcos do grafo. Uma aresta é ditaincidente com os vértices que ela liga. Quando uma aresta é incidente a um único vértice é denominadalaço. Se dois vértices são ligados por uma aresta então eles são ditosadjacentes [53].
As arestas dos grafos podem ser direcionadas, nesse caso os grafos são chamados de Dígrafos e suas arestas são definidas por pares ordenados de vértices, representando a origem e o destino. Ainda, é possível atribuir valores algébricos ou rótulos para os vértices e as arestas, chamados de atributos [32]. Em um grafo com pesos, uma função adicional E → R associa um valor a cada aresta, o que pode ser considerado seu “custo”, tais grafos surgem em problemas de rota ótima, por exemplo e são intitulados de grafos ponderados. A Figura2.8 apresenta um grafo que possui um custo associado as suas arestas.
Dependendo da aplicação dada ao grafo, arestas podem ter ou não direção, pode também ser permitido ou não que arestas liguem um nó a ele mesmo. Se as arestas do grafo têm uma direção associada, que é indicada por uma seta na representação gráfica, temos um dígrafo, ou seja, um grafo orientado. Um grafo com um único nó e sem arestas é conhecido como grafo trivial. Um grafo é conexo se existe um caminho entre qualquer par de nós, caso contrário ele é chamado desconexo. Por exemplo, se não existir um caminho entre um nó p e qualquer outro nó do grafo, então este grafo é chamado desconexo. Dois nós estão conectados se existe um caminho entre eles no grafo [53].
26 Capítulo 2. Revisão da Literatura
Figura 2.8:Grafo com custo associado as arestas.
Figura 2.9:Grafo simples.
Um grafo é denominado multigrafo se ele possui laços ou arestas paralelas, caso contrário, ele é chamado de grafo simples. A Figura 2.9
demonstra um grafo simples, cujas arestas que ligam os vértices não possuem qualquer orientação. Um grafo simples é chamado também de
grafo completo quando cada par distinto de vértices é adjacente. Um grafo completo é representado por Kn, onde n é o número de vértices deste grafo.
Todo grafo completo de n vértices possui m = n 2
arestas. O grau de um nó é o número de arestas incidentes a ele. SeE é finito, então a valência total dos nós é o dobro do número de arestas.
Na Figura 2.9, por exemplo, estamos considerando uma relação simétrica e sem laços, onde existe no máximo uma aresta entre quaisquer dois vértices (sem arestas paralelas). O número de arestas de um grafo simples e completo G é expressado pela Equação2.1, onde v é o número de vértices do grafo.
2.3. Teoria dos Grafos 27
E = v
2. (v − 2) (2.1)
Em um grafo direcionado, distingue-se o grau de saída que é o número de arestas saindo de um nó, e o grau de entrada que é o número de arestas entrando em um nó. O grau de um nó em um grafo direcionado é igual à soma dos graus de saída e de entrada. O grau de um nó é definido somente quando o número de arestas incidentes sobre o nó é finito [53]. A Figura2.10
traz um exemplo de um grafo direcionado.
Figura 2.10:Grafo direcionado.
Dois grafos são ditosisomorfos quando é possível coincidir os vértices de suas representações gráficas, preservando as adjacências das arestas dos mesmos. Subgrafos existem quando arestas e vértices de V possuem um subconjunto, ou seja, o grafo G′(V′, E′) é um subgrafo de G(V, E).
Define-se o grau de um vértice v pertencente à V como Define-sendo o número de arestas incidentes a v. Um grafo é considerado regular de grau r quando todos os seus vértices possuem um grau r [32].
A representação mais usual de um grafo é através do desenho de vértices e arestas. No entanto, em um computador ele pode ser representado de várias maneiras, e a eficiência do algoritmo vai depender da escolha de como representa-lo. Um grafo finito direcionado ou não-direcionado, com n nós, geralmente é representado por uma matriz de adjacência: uma matriz n-por-n cujo valor na linha i e coluna j fornece o número de arestas do i-ésimo ao j-ésimo nós, como pode ser observado na Equação2.2a seguir.
ai,j= 1 se e somente se existe (vi, vj) ǫ E 0 caso contrário (2.2)
28 Capítulo 2. Revisão da Literatura
Caso um grafo possua um número wi,j associado a cada aresta, este grafo
é denominado ponderado e o número wi,jé chamado de custo da aresta. Um
grafo que possui esta característica pode ser representado por sua matriz de custo W=[wi,j] determinada na Equação2.3.
wi,j = 1 custo da aresta, se (vi, vj) ǫ E 0 ou ∞, caso contrário (2.3) Ao observar a estrutura de adjacência, um vértice y em um grafo dirigido é chamado um sucessor de um ou outro vértice x, se existe uma aresta dirigida de x para y, deste modo, o vértice x é denominado um antecessor de y. Um grafo pode ser descrito por sua estrutura de adjacência (adj), assim, para cada vértice v, adj(v) é uma lista que compreende todos os sucessores de v [53].
Um grafo é dito conexo se for possível partir de um vértice e através das arestas visitar qualquer outro. Esta visita sucessiva de vértices é chamada de
caminho. Caminho é uma sequência de nós tal que sempre existe uma aresta de um nó para o seguinte. Um caminho é chamado simples se nenhum dos nós no caminho se repete. Ocomprimento do caminho é o número de arestas que o caminho usa, contando-se arestas múltiplas vezes. O custo de um caminho num grafo balanceado é a soma dos custos das arestas atravessadas. Dois caminhos são independentes se não tiverem nenhum nó em comum, exceto o primeiro e o último. As propriedades de dígrafos tornam a sua conexidade mais complexa devido à orientação das arestas.
Dados dois vértices v e w pertencentes ao grafo G(V,E),o comprimento d e menor caminho entre v e w denomina-se distância. No caso deste caminho não existir, a distância é considerada infinita. Para considerar esta métrica a notação de distância entre os vértices v e w é dada por d(v,w). Para todo vértice u, v e w de G(V,E), pode ser definido que d(u,v) ≥ 0 com d(u,v) = 0 se e somente se u = v. Além disso, d(u,v) = d(v,u) ocorre somente se o vértice for não orientado, bem como d(u,v) + d(v,w) ≥ d(u,w). A excentricidade de um vértice v, denotada por [e(v)], é a máxima das distâncias d(v,u) na Equação2.4.
∀u ǫ G, e(v) = MAX d(v, u) (2.4)
A teoria dos grafos é um ramo da matemática que estuda as relações entre os objetos de um determinado conjunto. Estruturas que podem ser
