Linguagem Guaraná DSL no Contexto da administração pública municipal - um caso de estudo

Universidade Regional do Noroeste do

Estado do Rio Grande do Sul – UNIJUÍ

Grupo de Pesquisa em Computação Aplicada (GCA)

Ivan Eduardo Metz Kühne

Linguagem Guaraná DSL no Contexto da

Administração Pública Municipal - Um Caso de

Estudo

Ijuí, RS, Brasil

2017

Ivan Eduardo Metz Kühne

Linguagem Guaraná DSL no Contexto da Administração

Pública Municipal - Um Caso de Estudo

Trabalho de Conclusão de Curso apresentado ao curso de Ciência da Computação da Uni-versidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ) como um dos requisitos para a obtenção do título de Bacharel em Ciência da Computação.

Orientador: Dra. Fabricia Carneiro Roos Frantz

Ijuí, RS, Brasil

2017

Ivan Eduardo Metz Kühne

Linguagem Guaraná DSL no Contexto da Administração

Pública Municipal - Um Caso de Estudo

Trabalho de Conclusão de Curso apresentado ao curso de Ciência da Computação da Uni-versidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ) como um dos requisitos para a obtenção do título de Bacharel em Ciência da Computação.

Dra. Fabricia Carneiro Roos Frantz

Orientadora

Dr. Rafael Zancan Frantz

Convidado

Ijuí, RS, Brasil

2017

Agradecimentos

Agradeço ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) pela concessão das bolsas de iniciação tecnológica e científica que permitiram a realização da pesquisa que serviu de base para o desenvolvimento deste trabalho de conclusão de curso.

Agradeço aos professores do curso de graduação por sua participação em minha formação profissional e pessoal, em especial ao meu orientador nas atividades como bolsista de iniciação tecnológica e científica, professor Doutor Rafael Zancan Frantz, e à minha orientadora nesse Trabalho de Conclusão de Curso, professora Doutora Fabricia Carneiro Roos Frantz.

Resumo

Pode ser observada uma tendência crescente no uso de sistemas informatizados em or-ganizações de diversas naturezas. Entretanto, a simples adição de novas aplicações nem sempre atinge às necessidades dessas organizações de forma satisfatória. Pode ser necessário recorrer às metodologias, técnicas e ferramentas do campo da Integração de Aplicações Empresariais. Entre essas, podemos citar a linguagem Guaraná DSL, que foi criada com o objetivo de possibilitar a modelagem de soluções de integração em alto nível de abstração. Nesse trabalho é discutida a possibilidade de uso da linguagem Guaraná DSL para a modelagem de uma solução de integração para um caso de estudo identificado no contexto da administração pública da cidade de Ijuí – RS.

Palavras-chaves: Integração de Aplicações Empresariais, Linguagem de Domínio

Abstract

A growing tendency in the use of computer-based systems can be ob-served in organizations of different kinds. However, it is not everytime that the simple addition of new software properly satisfies the needs of these organizations. It can be necessary to call upon the methods, technics and tools of the field of Enterprise Application Integration. Among them, we can name the language Guaraná DSL, created with the purpose of suporting the modeling of integration solutions in a high level of abstraction. In this work is discussed the possibility of using the language Guaraná DSL in the modeling of a integration solution for a study case identified in the context of the town of Ijuí – RS public administration.

Key-words: Enterprise Application Integration, Domain-Specific Language, Public

Lista de ilustrações

Figura 1 – Modelo de transferência de arquivos. . . 16

Figura 2 – Modelo de compartilhamento de banco de dados. . . 17

Figura 3 – Modelo de chamada de procedimento remoto. . . 18

Figura 4 – Modelo de envio de mensagens. . . 19

Figura 5 – Modelo da topologia point-to-point. . . 20

Figura 6 – Modelo da topologia hub-and-spoke. . . 21

Figura 7 – Representação da tarefa composta Enquirer. . . 30

Figura 8 – Padrão equivalente à tarefa composta Enquirer. . . 30

Lista de abreviaturas e siglas

DSL Linguagem de Domínio Específico EAI Integração de Aplicações Empresariais

GCA Grupo de Pesquisa em Computação Aplicada IDE Ambiente Integrado de Desenvolvimento SDK Kit de Desenvolvimento de Software SGBD Sistema Gerenciador de Bancos de Dados

Sumário

2.1 Fatores a serem considerados para a integração . . . 14

2.2 Estilos de Integração . . . 15

2.2.1 Transferência de Arquivos . . . 15

2.2.2 Compartilhamento de Banco de Dados . . . 17

2.2.3 Chamada de Procedimento Remoto . . . 18

2.2.4 Envio de Mensagens . . . 19 2.3 Topologias de Integração . . . 20 2.3.1 Point-to-point. . . 20 2.3.2 Hub-and-spoke . . . 21 2.3.3 Message Bus . . . 22 2.4 Ferramentas de Integração . . . 22 2.4.1 Linguagem Guaraná DSL . . . 23 2.4.2 Guaraná SDK . . . 24 2.4.3 Spring Integration. . . 25 2.4.4 Apache Camel . . . 25

2.4.5 Mule Runtime Engine . . . 26

2.5 Resumo do Capítulo . . . 26

3 CASO DE ESTUDO . . . 28

3.1 Ecossistema de Software . . . 28

3.2 Solução de Integração Proposta . . . 29

3.3 Resumo do Capítulo . . . 33

Conclusão. . . 34

10

1 Introdução

Atualmente pode ser observado, de forma empírica, que uma quantidade cada vez maior de organizações depende do uso de sistemas informatizados para a execução de seus processos de negócio. A quantidade de processos que depende dessas aplicações dentro de cada uma delas é variável, mas em geral tem mostrado uma tendência crescente. Ao conjunto dessas aplicações dentro de cada organização é dado o nome de ecossistema de software. Esse ecossistema apoia tarefas diversas, como a contabilidade, a emissão de notas fiscais, a comunicação com os clientes e o controle de estoque.

De acordo comHohpe (2003), essas demandas que são supridas pelas aplicações não são estáticas: elas vão se alterando ao longo do ciclo de vida das organizações. Dessa forma, pode tornar-se necessária a adição de novas aplicações ao ecossistema de software. Essas novas aplicações podem ser desenvolvidas dentro da própria empresa, encomendadas de empresas especializadas ou compradas como “software de prateleira”. Entretanto, há casos em que essa simples adição de novas aplicações não consegue cumprir com os novos requisitos. Assim, torna-se necessário que as novas aplicações sejam integradas, de forma a compartilhar dados e funcionalidades, além da criação de novas funcionalidades a partir das já existentes, conforme Frantz, Quintero e Corchuelo (2011).

A integração de aplicações não é uma tarefa fácil, uma vez que as aplicações podem ter sido criadas usando-se linguagens de programação diferentes, diferentes formatos de dados, criadas por pessoas diferentes (o que pode levar ao uso de diferentes abordagens na solução dos problemas) e em épocas diferentes (o que pode levar ao uso de diferentes paradigmas tecnológicos). Além disso, as aplicações normalmente não são criadas tendo em vista a sua futura integração.

Para o sucesso nessa difícil tarefa, foi desenvolvido ao longo dos anos, dentro da Engenharia de Software, o campo da Integração de Aplicações Empresariais (EAI). Esse campo fornece metodologias, técnicas e ferramentas para que aplicações que não foram desenvolvidas com a capacidade original de se comunicar possam trabalhar conjuntamente. Dessa forma, podem ser atingidos os novos requisitos que se apresentam para as empresas, em questões como a racionalização e otimização de processos, a diminuição dos custos com mão-de-obra e a manutenção da competitividade.

Dentre as ferramentas desenvolvidas ao longo dos anos no campo da EAI, podemos citar o Spring Integration, o Apache Camel, o Mule Runtime Engine e o Guaraná SDK, que são plataformas de integração especializadas. O presente trabalho vai ser desenvolvido com base no estudo da viabilidade do uso da linguagem Guaraná DSL, que é a linguagem de domínio específico (DSL) associada à ferramenta Guaraná SDK, para a modelagem de

Capítulo 1. Introdução 11

soluções de integração no contexto da administração pública. Para subsidiar esse estudo, será identificado um caso de estudo na administração pública municipal da cidade de Ijuí – RS. Em seguida, será proposta e modelada uma solução de integração para o caso de

estudo identificado.

1.1

Motivação

O tema geral do trabalho, que é a EAI, foi escolhido de forma a contribuir com as atividades desenvolvidas pelo Grupo de Pesquisa em Computação Aplicada (GCA), desta universidade, que trabalha com o estudo desse campo da Engenharia de Software e com o desenvolvimento de ferramentas para o mesmo. O tema da modelagem de soluções de integração no contexto da administração pública, de forma mais específica, foi objeto de estudo durante as atividades de iniciação tecnológica e científica desenvolvidas junto a esse grupo.

A linguagem Guaraná DSL foi originalmente projetada para a modelagem de soluções de integração no contexto empresarial. Entretanto, é desejável saber se ela pode ser utilizada satisfatoriamente na modelagem de soluções de integração para organizações de outras naturezas, como aquelas ligadas à administração pública.

Em trabalhos anteriores de outros integrantes do GCA foi constatada a adequação da linguagem Guaraná DSL para a modelagem de soluções no contexto empresarial e no contexto acadêmico. Como exemplo, temos os trabalhos de Silva et al.(2015) e Cargnin et al. (2015), respectivamente. Entretanto, ainda não foi verificado se ela oferece um suporte adequado à modelagem de soluções de integração no contexto da administração pública. O objetivo do presente trabalho é realizar essa verificação.

1.2

Objetivos

Os objetivos desse trabalho se dividem em geral e específicos. Eles são apresentados a seguir.

1.2.1

Geral

O objetivo deste trabalho é identificar se a linguagem Guaraná DSL, criada origi-nalmente para a modelagem conceitual de soluções de integração no contexto empresarial privado, pode ser usada da mesma maneira para a modelagem de soluções no contexto da administração pública.

Capítulo 1. Introdução 12

1.2.2

Específicos

(a) estudar sobre o campo da EAI;

(b) estudar sobre a linguagem Guaraná DSL;

(c) identificar um caso de uso no contexto da administração pública;

(d) propor e modelar uma solução de integração para o caso de uso identificado; (e) avaliar o suporte da linguagem Guaraná DSL para a modelagem de soluções de

integração no contexto da administração pública.

1.3

Metodologia

A metodologia desse trabalho está dividida em cinco etapas. Inicialmente foi realizada uma revisão da literatura técnica e científica relacionada com o tema da pesquisa. Dessa forma foram estudados os conceitos de EAI e DSL, fundamentais para a elaboração do restante do trabalho. Em seguida foi estudada a literatura relativa à linguagem Guaraná DSL.

Após esse estudo preliminar, foi identificado um caso de estudo compatível com a proposta de pesquisa. Com base no estudo desse caso, foi proposta e modelada uma solução de integração para o mesmo, através do uso dessa linguagem. Finalmente, com base nessa solução de integração, foi avaliada a viabilidade do uso da linguagem Guaraná DSL para a modelagem de soluções no contexto da administração pública.

1.4

Contribuições

Durante a elaboração desse trabalho, foi possível realizar a escrita e publicação dos seguintes resumos, que se encontram nos anexos:

(a) KÜHNE, I.E. M.. Modelagem de uma Solução de Integração no Contexto da

Admi-nistração Pública Municipal. In: V Seminário de Formação Científica e

Tecno-lógica, Ijuí - RS. 2016. p. 23-24.

(b) KÜHNE, I. E. M.; FRANTZ, R.Z.. Modelagem de uma Solução de Integração para

Automatizar a Emissão dos Boletos de IPTU e ISSQN no Município de Ijuí. In: VI

Seminário de Inovação e Tecnologia, Ijuí - RS. 2016. p. 1-5.

O resumo publicado no VI Seminário de Inovação e Tecnologia foi escolhido como Trabalho-Destaque em sua área do conhecimento. Além dessas publicações, também

Capítulo 1. Introdução 13

participei do painel temático “Exposição das Linhas e Projetos de Grupos de Pesquisa e Experiências Acadêmicas do DCEEng”, dentro do Salão do Conhecimento 2016, falando sobre as atividades desenvolvidas como bolsista no GCA.

1.5

Estrutura do documento

No capítulo 2 está descrito o conceito de EAI, que é fundamental para o desenvolvi-mento do trabalho, incluindo os estilos e topologias de integração existente. Nesse capítulo também são apresentadas algumas ferramentas de integração existentes no mercado. No capítulo 3 é apresentado o caso de estudo escolhido e o ecossistema de software associado a ele, bem como a solução de interação proposta e a sua modelagem através da linguagem Guaraná DSL.

14

2 Referencial Teórico

O campo da EAI oferece metodologias, técnicas e ferramentas para que consigamos fazer trabalhar em conjunto aplicações que não foram criadas tendo em vista essa finali-dade. Ele permite que as demandas crescentes das organizações, apontadas por Hohpe e Woolf(2004), sejam supridas sem que haja a necessidade de criação de novos softwares especializados, o que exigiria um esforço maior no processo de adaptação dos métodos de trabalho, além de ser um processo de alto custo. Com a aplicação da EAI, até mesmo o trabalho com sistemas legados se mantém possível, uma vez que eles podem ser integrados com as novas aplicações que passam a fazer parte do ecossistema de software ao longo do tempo.

A seguir são abordados os fatores a serem considerados para a integração, os estilos e topologias de integração possíveis, as DSLs e a linguagem Guaraná DSL e, por fim, algumas plataformas de integração existentes.

2.1

Fatores a serem considerados para a integração

Quando se deseja projetar uma solução de integração, devem ser levados em conta alguns fatores. Entre esses fatores, estão os tópicos específicos de cada ecossistema analisado e as limitações impostas ao processo de integração. Segundo Hohpe e Woolf (2004), entre os tópicos específicos, devem ser analisados pontos como:

(a) escolha entre compartilhamento de dados ou de funcionalidades; (b) acoplamento desejado entre as aplicações;

(c) simplicidade desejada; (d) tecnologia escolhida;

(e) modelo de dados;

(f) preferência entre comunicação síncrona ou assíncrona.

Entre as limitações impostas, pode-se citar:

(a) uso de linguagens de programação diferentes; (b) uso de formatos de dados diferentes;

Capítulo 2. Referencial Teórico 15

(c) desenvolvimento por pessoas diferentes (o que pode levar ao uso de abordagens diferentes na solução dos problemas);

(d) desenvolvimento em épocas diferentes (o que pode levar ao uso de paradigmas tecnológicos diferentes);

(e) o desenvolvimento não ter em vista a futura integração.

Além dessas limitações, temos alguns desafios fundamentais, também elencados por Hohpe e Woolf (2004):

(a) as redes de computadores não são confiáveis, fazendo as soluções precisarem lidar com uma série de problemas que não ocorreriam se elas estivessem rodando em um único computador;

(b) as redes de computadores são lentas, fazendo a comunicação ser várias ordens de magnitude mais lenta do que aquela que ocorre nos barramentos internos dos computadores;

(c) quaisquer duas aplicações são diferentes, fazendo a solução de integração precisar lidar com essa diferença;

(d) a mudança é inevitável, fazendo a solução de integração precisar acompanhar as mudanças das aplicações que ela integra.

Através da análise dos tópicos específicos e das respostas necessárias às limitações e aos desafios impostos, o engenheiro de software fica mais capacitado a escolher quais ferramentas, estilos e topologias deve utilizar para projetar e implementar a solução de integração desejada.

2.2

Estilos de Integração

Existem quatro diferentes estilos de integração de aplicações que foram desenvol-vidos ao longo dos anos: a transferência de arquivos, o compartilhamento de banco de dados, a chamada de procedimento remoto e o envio de mensagens. Para cada operação de integração, dependendo de seus detalhes específicos, pode ser escolhido um deles ou mesmo uma combinação entre eles. A seguir são discutidos esses quatro estilos de integração.

2.2.1

Transferência de Arquivos

A transferência de arquivos está representada na Figura1. Nessa figura, a aplicação A cria um arquivo, que é traduzido para o formato canônico pelo integrador de exportação.

Capítulo 2. Referencial Teórico 16

Em seguida, o arquivo é recebido pelo integrador de importação, que o converte para o formato que a aplicação B precisa e o repassa para a mesma.

Figura 1 – Modelo de transferência de arquivos.

Fonte: Do autor (2015).

A transferência de arquivos é um estilo considerado de fácil implementação, por não depender de ferramentas sofisticadas e geralmente poder ser implementado dentro da própria organização. Nesse estilo, uma das aplicações a ser integrada escreve um arquivo, que em seguida é repassado para a outra aplicação. Normalmente esse arquivo é escrito em um formato que facilita o intercâmbio de dados, como o XML. Caso as duas aplicações usem formatos de arquivos diferentes, é necessário o uso de integradores, que fazem a conversão de um formato de arquivo para outro.

Geralmente esse estilo é adotado quando não há necessidade de interação frequente entre as duas aplicações. Dessa forma, pode ser estabelecido um período, como semanal-mente ou diariasemanal-mente, para a leitura dos arquivos disponibilizados pela primeira aplicação. As duas aplicações precisam concordar quanto a esse período de leitura dos arquivos. A escolha desse período precisa ser feita de forma criteriosa, de forma a evitar que a organização fique com seus dados dessincronizadas. Esse estilo não é indicado em caso de necessidade de grande volume de comunicação entre as aplicações, uma vez que o processo de criação e processamento de arquivos é uma operação computacionalmente custosa. O maior desafio em relação ao uso desse estilo de integração é a gerência dos arquivos produzidos, de forma que se garanta a leitura de todos, sem que haja a perda de nenhum deles.

A principal vantagem desse estilo é que não é necessário muito conhecimento e interferência sobre o funcionamento interno das aplicações. É necessário apenas um mecanismo comum de transferência de dados, que possui a propriedade de poder ser utilizado por diversas linguagens de programação e plataformas. Com isso, reduz-se a quantidade de hardware e software especializado que é necessária. Outro ponto vantajoso é que o acoplamento entre as aplicações é baixo, uma vez que cada software pode ser modificado internamente sem afetar a integração, bastando que ele continue produzindo arquivos com o mesmo formato e especificação.

Capítulo 2. Referencial Teórico 17

2.2.2

Compartilhamento de Banco de Dados

O compartilhamento de banco de dados está representado na Figura2. Nessa figura existem três aplicações diferentes, sendo que cada uma delas está ligada ao mesmo banco de dados. Podemos ver que não há comunicação direta entre essas três aplicações.

Figura 2 – Modelo de compartilhamento de banco de dados.

Fonte: Do autor (2015).

O compartilhamento banco de dados ocorre através do acesso de mais de uma aplicação à mesma base de dados. É utilizado quando se deseja que os dados sejam compartilhados de maneira rápida e consistente. Eles são atualizados de forma oportuna para todos os usuários, o que reduz as inconsistências e aumenta a confiabilidade do sistema integrado.

A utilização desse estilo também evita que os dados precisem ser duplicados para atender às diversas aplicações, o que reduz a utilização de espaço de armazenamento. Outra vantagem é que não há necessidade de comunicação direta entre as diversas aplicações, já que cada uma delas se comunica unicamente com o banco de dados.

Um fator que facilita o uso do compartilhamento de banco de dados é a ampla adoção de sistemas gerenciadores de bancos de dados (SGBD) que trabalham com lingua-gens baseadas no padrão Structured Query Language (SQL). Uma variedade grande de aplicações, linguagens de programação e ambientes de desenvolvimento consegue trabalhar em conjunto com esses SGBDs, muitas vezes com ferramentas sofisticadas. Dessa forma, não há necessidade de preocupação com os diferentes formatos de dados, como ocorre na integração através da transferência de arquivos.

Quando é utilizado o compartilhamento de banco de dados, é criado um único modelo de dados, que busca atender aos requisitos de todas as aplicações de forma simultânea. Isso pode levar à necessidade de uma modelagem muito complexa, que acaba sendo de difícil entendimento por parte dos engenheiros de software. Outro problema que pode ocorrer é a diminuição do desempenho as solução de integração, devido ao acesso concorrente ao banco de dados, uma vez que diversas aplicações podem precisar ler e modificar os dados ao mesmo tempo.

Capítulo 2. Referencial Teórico 18

2.2.3

Chamada de Procedimento Remoto

A chamada de procedimento remoto está representada na Figura 3. Nessa figura, a aplicação A se comunica, através do seu stub, com o skeleton disponibilizado pela aplicação B, fazendo uma chamada de procedimento. Isso faz com que a aplicação B execute o procedimento solicitado e envie a resposta para a aplicação A.

Figura 3 – Modelo de chamada de procedimento remoto.

Fonte: Do autor (2015).

A chamada de procedimento remoto ocorre com a imposição de interfaces de comu-nicação nas aplicações que se pretende integrar. A aplicação servidora recebe uma interface chamada skeleton, através da qual ela disponibiliza algumas das suas funcionalidades. Enquanto isso, as aplicações clientes recebem, cada uma, uma interface chamada stub, através da qual elas podem acessar a aplicação servidora, requisitando as funcionalidades disponibilizadas.

Esse estilo de integração apresenta a vantagem do encapsulamento: as aplicações clientes não acessam diretamente os dados internos da aplicação servidora: o acesso se dá apenas através da interface disponibilizada. Mesmo quando a aplicação cliente precisa modificar os dados da aplicação servidora, ela não o faz de forma direta, mas através da interface que fornece métodos que interagem com esses dados. Esse encapsulamento é especialmente vantajoso nos casos em que uma única chamada a um método pode desencadear uma série de modificações nos dados da aplicação servidora. Além disso, caso existam diversas aplicações clientes, cada uma delas pode ter acesso a uma interface diferente, em que os dados são enxergados de forma distinta.

Uma desvantagem desse estilo de integração é que as chamadas a procedimentos remotos podem ser demoradas por envolverem a rede local ou a internet, onde a comunicação é muito mais lenta do que aquela que ocorre nos barramentos internos de um computador. Se esse aspecto não for considerado, o resultado final da integração pode ser um sistema extremamente lento. Outra desvantagem é que o acoplamento entre as aplicações ainda é alto, já que esse estilo implica na modificação das aplicações através da adição de código para que se permita a comunicação direta entre elas, embora o encapsulamento ajude a diminuir esse acoplamento.

Capítulo 2. Referencial Teórico 19

2.2.4

Envio de Mensagens

O envio de mensagens está representado na Figura 4, onde há um message bus conectando as quatro diferentes aplicações. Esse bus é responsável por receber as mensagens enviadas por cada aplicação e repassá-las para as aplicações de destino. O message bus é uma das topologias de integração existentes e será discutido em maiores detalhes na sessão 2.3 (Topologias de Integração).

Figura 4 – Modelo de envio de mensagens.

Fonte: Do autor (2015).

O envio de mensagens é implementado a partir da criação de um message bus, ao qual são conectadas as aplicações a serem integradas. De forma análoga a um barramento físico, esse bus é responsável por receber a mensagem enviada por cada aplicação e enca-minhar para a aplicação de destino. Esse estilo apresenta algumas vantagens importantes, como a comunicação assíncrona, a integração entre linguagens e plataformas, o controle de fluxo e a comunicação confiável.

A comunicação assíncrona faz com que as duas aplicações não precisem estar funcionando ao mesmo tempo para que a comunicação ocorra. A integração entre linguagens e plataformas se refere ao fato desse estilo de integração se basear nos pontos comuns entre as aplicações, em pontos como as tecnologias e paradigmas utilizados, de forma que é alcançado um “menor denominador comum” que permite o trabalho conjunto de diferentes sistemas.

O controle de fluxo se refere à limitação que o sistema pode fazer sobre a quantidade de mensagens enviadas pela aplicação de origem, de forma a não sobrecarregar a aplicação de destino. Por fim, a comunicação confiável se deve ao conceito store and forward utilizado na transmissão de mensagens: o canal de mensagens armazena a mensagem que está sendo enviada no computador de origem, seja em memória ou em disco. Em seguida ela é enviada ao computador de destino, armazenada nele e só então apagada do computador de origem. Esse processo pode ser tentado quantas vezes forem necessárias até que seja bem-sucedido. Segundo Hohpe (2003), o envio de mensagens funciona de forma mais imediata do que a transferência de arquivos, melhor encapsulada do que o compartilhamento de banco

Capítulo 2. Referencial Teórico 20

de dados e mais confiável do que a chamada de procedimento remoto. Isso faz o envio de mensagens ser o estilo de integração preferido por esses autores. Segundo eles, o maior imediatismo em relação à transferência de arquivos vem do fato das mensagens não serem recebidas em intervalos pré-determinados, mas assim que a aplicação receptora estiver disponível. O melhor encapsulamento em relação ao compartilha-mento de banco de dados vem do fato dos dados não serem acessados de forma direta (o que poderia alterá-los de maneira não desejada), mas através de uma estrutura criada para o compartilhamento dessas informações. Finalmente, a maior confiabilidade em relação à chamada de procedi-mento remoto se deve aos canais de transmissão de mensagens, que conseguem um maior controle sobre os processos de envio e recebimento.

2.3

Topologias de Integração

As topologias de integração definem o estilo arquitetônico utilizado para a co-municação entre as aplicações. Dentro da EAI, as três topologias mais utilizadas são a point-to-point, a hub-and-spoke e a message bus. Segundo Clifford(2005), uma solução de integração não precisa se basear em uma única topologia, mas pode usar uma combinação entre elas. Assim, uma solução de integração pode possuir aspectos bilaterais (relativos à topologia point-to-point), aspectos centralizados (relativos à topologia hub-and-spoke) e aspectos baseados em padrões (relativos à topologia message bus). A seguir são discutidas essas três topologias.

2.3.1

Point-to-point

A topologia point-to-point está representada na Figura 5, onde podemos ver que há uma conexão direta entre cada par de aplicações. Quando isso ocorre, há necessidade de modificação nas aplicações através da inclusão de código, de forma que se permita o compartilhamento de dados ou funcionalidades.

Figura 5 – Modelo da topologia point-to-point.

Capítulo 2. Referencial Teórico 21

A topologia point-to-point conecta diretamente cada par de aplicações integradas. Sua utilização mais usual é em combinação com o estilo de integração chamada de proce-dimento remoto. Quando ocorre essa combinação, existe a garantia de que o proceproce-dimento invocado será executado uma única vez ou, em caso de erro, não será executado. Dessa forma, não há a repetição de procedimentos destinados a serem executados uma única vez.

A implementação dessa topologia começa simples, devido ao fato de geralmente envolver apenas duas aplicações. Entretanto, ela pode se tornar complexa rapidamente em caso de aumento de número de aplicações integra-das, já que o número de conexões necessárias para integrar as aplicações cresce de maneira exponencial. Em razão desse crescimento exponencial, o uso da topologia point-to-point só é recomendado nos casos em que o números de aplicações a serem integradas é pequeno.

Nessa topologia, as decisões são tomadas de forma bilateral, mas o processamento é local. As decisões são assim porque há necessidade de ambas as aplicações concordarem quanto ao mecanismo da integração. O uso dessa topologia faz com que as aplicações fiquem fortemente acopladas. Assim, é necessário que o mecanismo de integração seja refeito em caso de substituição ou de mudança drástica em alguma delas.

2.3.2

Hub-and-spoke

Conforme a Figura6, a topologia hub-and-spoke é implementada a partir da criação de um mecanismo central de comunicação (hub), do qual partem as ligações (spokes) que se conectam às diferentes aplicações.

Figura 6 – Modelo da topologia hub-and-spoke.

Fonte: Do autor (2015).

Conforme Hohpe(2003), o uso dessa topologia reduz o número de ligações necessá-rias em relação à topologia point-to-point, uma vez que as aplicações não precisam estar ligadas diretamente entre si, bastando que cada uma delas esteja ligada ao hub através de um spoke. Dessa forma, o número de ligações necessárias passa a crescer de forma linear, deixando de ser exponencial.

Capítulo 2. Referencial Teórico 22

Segundo Clifford (2005), o uso dessa topologia pode simplificar o processo de integração, uma vez que ela pode conectar aplicações com diferentes formatos e meios de transmissão de dados. Além disso, o hub pode fazer modificações no formato dos dados e pode selecionar para onde enviá-los. Esses fatores de comunicação entre aplicações com formatos de dados diferentes e de modificação no formato dos dados são definidos como importantes também por Hohpe (2003), que introduz o conceito de modelo canônico. O que o autor sugere é que pode haver um formato canônico de dados, para o qual os dados enviados pelas aplicações são convertidos pelo hub. Em seguida, o hub faz uma nova conversão, dessa vez para o formato requerido pela aplicação de destino. Desta forma, as aplicações podem se comunicar, independentemente do formato de dados utilizado por cada uma delas.

2.3.3

Message Bus

Segundo Hohpe e Woolf (2004), um message bus é criado a partir da combinação de um modelo de dados comum, um conjunto de comandos comum e uma infraestrutura de mensagens que permite que diferentes sistemas se comuniquem através de um conjunto compartilhado de interfaces. A topologia message bus, que está representada na Figura4, é baseada em canais de mensagem que conectam as diferentes aplicações. Entretanto, ela se destaca por possuir um backbone central que faz com que a conexão entre cada conjunto de aplicações não seja direta. Essa topologia é implementada a partir da criação desse backbone, que servirá como uma central de comunicação entre as aplicações. Em seguida, as aplicações são ligadas a essa central.

Quando uma aplicação deseja enviar uma mensagem para outra, ela precisa saber apenas qual é o canal em que ela deverá enviar a mensagem. É o backbone que fica responsável por definir o fluxo de mensagens entre as aplicações. O uso dessa topologia permite que as aplicações trabalhem de forma conjunta, embora desacoplada. Desse modo, quando uma aplicação não está sendo executada, não há impacto sobre as demais. É possível até que aplicações sejam adicionadas ou removidas sem comprometer o funcionamento do conjunto.

2.4

Ferramentas de Integração

Entre as técnicas oferecidas pelo campo da EAI está o uso de DSLs, que podem ser utilizadas para a modelagem das soluções de integração. Conforme Ghosh (2010), uma DSL é semelhante a uma linguagem de programação. Entretanto, cada DSL é limitada à resolução de problemas dentro do domínio para o qual foi criada. Nesse ponto, ela é diferente das linguagens de propósito geral (GPL), que são capazes de modelar soluções para uma ampla gama de problemas.

Capítulo 2. Referencial Teórico 23

A vantagem do uso das DSLs é que, dentro desse domínio para o qual cada uma foi criada, elas são extremamente expressivas, de forma que podem ser compreendidas até por pessoas que não possuem familiaridade com linguagens de programação tradicionais. Outro fator que facilita essa compreensão é que a sintaxe e semântica das DSLs modelam conceitos no nível de abstração do domínio do problema, não no nível de abstração do domínio da solução.

Para fazermos a integração, podemos contar com a ajuda de algumas plataformas de integração especializadas. Entre elas, podemos citar o Guaraná SDK, o Spring Integration, o Apache Camel e o Mule Runtime Engine. Todas essas são plataformas baseadas em Java que se destinam a dar apoio aos processos de modelagem e implementação de integração de soluções empresariais, sendo que as três últimas são ferramentas open source. A modelagem pode ser feita em um ambiente integrado de desenvolvimento (IDE) que possui uma interface gráfica baseada em Eclipse. Esse ambiente apresenta vantagens como a coloração da sintaxe, o recurso de sugerir nomes de classes e métodos, documentação e um utilitário para debugging.

Cada um dessas quatro soluções oferece um kit de desenvolvimento de software (SDK), uma linguagem de domínio específico, uma biblioteca Java para implementação das soluções modeladas e um motor de execução para as soluções de integração. Elas também oferecem um possui um mecanismo de detecção de erros, para lidar com aqueles que eventualmente ocorrem durante os seus processos.

O SDK é um conjunto de ferramentas para o desenvolvimento de software, que permite ou facilita a criação de aplicações na plataforma em questão. Essa criação pode ser feita de duas maneiras: através do uso de uma DSL ou através da configuração de arquivos.

O motor de execução é um componente de software que, nesse assunto em particular, interpreta a solução de integração modelada e permite que ela seja executada para o usuário. Com isso, podemos transformar a solução de integração modelada conceitualmente em uma solução computacional real. Mesmo que não se deseje transformar a solução de integração em uma solução real, podemos assistir a uma simulação da integração e analisar o seu funcionamento em busca de eventuais problemas com sua performance.

A seguir é discutida a linguagem Guaraná DSL e, posteriormente, cada uma das quatro plataformas de integração citadas.

2.4.1

Linguagem Guaraná DSL

ConformeFrantz (2012), a linguagem Guaraná DSL foi projetada para a criação de soluções de integração de aplicações empresariais em um alto nível de abstração e oferece suporte aos padrões documentados por Hohpe e Woolf(2004). Como é característico das

Capítulo 2. Referencial Teórico 24

DSLs, seu alto nível de abstração permite que as soluções concebidas e modeladas sejam compreensíveis por profissionais sem familiaridade com a área de Engenharia de Software, como gerentes e administradores. Além disso, conforme o autor, ela pode ser utilizada como uma linguagem comum, embora ainda simples, para a comunicação no campo da EAI.

A Guaraná DSL possui uma sintaxe abstrata e uma sintaxe concreta. A sintaxe abstrata é um metamodelo associado ao núcleo da DSL. Ela é composta por soluções de integração, processos, portas, links, tarefas e slots. A sintaxe concreta é utilizada para representar as classes proporcionadas pela sintaxe abstrata. Ela é gráfica e extremamente intuitiva, podendo ser usada por engenheiros de software para a modelagem conceitual de soluções de integração.

2.4.2

Guaraná SDK

A plataforma Guaraná SDK foi desenvolvido pelo Grupo de Pesquisa em Computa-ção Aplicada e está associada à linguagem Guaraná DSL. O motor de execuComputa-ção do Guaraná SDK foi desenvolvido inicialmente em versão acadêmica, como uma prova de conceito dentro do esforço para permitir que as soluções de integração modeladas conceitualmente com a Guaraná DSL sejam transformadas em soluções computacionais reais. Esse motor de execução foi criado através da implementação em linguagem Java dos componentes da sintaxe abstrata da Guaraná DSL.

A plataforma Guaraná SDK se diferencia de outras semelhantes por possuir um mecanismo externo de controle de erros. Outro diferencial é o uso de um modelo de execução baseado em tarefas, não em processos. De acordo com Frantz, Corchuelo e Molina-Jiménez

(2012), a diferença entre esses modelos está na granularidade da execução. No modelo de execução baseado em tarefas, o motor pode controlar tanto as instâncias de processos quanto as tarefas internas. No modelo baseado em processo, o motor controla as instâncias de processo como um todo, não podendo interagir com suas tarefas internas. Dessa forma, ele requer o uso de um mecanismo para reunir as mensagens, correlacioná-las e decidir quando uma nova instância de processo pode ser iniciada. Além disso, cada instância de processo requer a alocação de uma thread exclusiva, o que pode ter um impacto negativo no desempenho nos casos em que uma instância de processo envia uma chamada e espera por um longo tempo até obter a resposta.

Como o modelo baseado em tarefas lida com as tarefas que estão dentro de uma instância de processo, ele pode fazer a alocação das threads com maior eficiência: nenhuma thread deve permanecer parada enquanto houver uma tarefa pronta para ser executada, independentemente do processo a que ela pertencer. Devido a essas características do modelo baseado em tarefas, o Guaraná SDK permite um uso mais eficiente dos recursos do sistema.

Capítulo 2. Referencial Teórico 25

2.4.3

Spring Integration

A plataforma Spring Integration é mantida pela Pivotal Software e faz parte do Spring Framework, que é um framework baseado em Java. Ela trabalha com os conceitos de mensagem, terminal e canal de mensagens e estende o modelo de programação do Spring de forma a oferecer suporte aos padrões de integração documentados por Hohpe e Woolf(2004).

Conforme a Pivotal Software (2017), essa plataforma possibilita a criação de sistemas baseados em envio de mensagens extremamente leves. Esses sistemas podem servir para a comunicação interna em aplicações baseadas em Spring ou, através do uso de adaptadores, permitir a comunicação com aplicações externas. Esses adaptadores proporcionam um nível alto de abstração em cima do suporte que o Spring oferece à comunicação remota, ao envio de mensagens e ao agendamento de tarefas.

Ainda segundo a Pivotal Software (2017), o principal objetivo dessa plataforma de integração é oferecer um modelo simples para a criação de soluções de integração, ao mesmo tempo que mantém a separação de conceitos ("separation of concerns") que é essencial para a produção de um código passível de passar por manutenção e testes. Conforme Spacey (2016), o software produzido de acordo com esse conceito é separado em camadas e componentes com funcionalidades distintas, com o mínimo possível de sobreposição. Dessa forma, os riscos associados às alterações são reduzidos, uma vez que elas são associadas a um único componente.

2.4.4

Apache Camel

O Apache Camel é disponibilizado pela Apache Software Foundation. Conforme a The Apache Software Foundation (2015), essa organização, anteriormente conhecida como Apache Group, não possui fins lucrativos e tem por missão prover software para o bem público. Ela foi fundada em 1999 e atualmente possui cerca de 500 membros e 4500 colaboradores, sendo mantida financeiramente por doadores individuais e por patrocinadores corporativos. A organização mantém alguns outros projetos além do Apache Camel, dos quais o mais conhecido é o servidor Apache HTTP Server.

Segundo a The Apache Software Foundation (2017), o Apache Camel é uma plataforma de integração open source baseada nos padrões de integração documentados porHohpe e Woolf(2004), que trabalha com os conceitos de trocas, terminais, processadores e rotas de mensagem. Os padrões de integração e as rotas de mensagens são construídos através do uso de DSLs ou através da configuração de arquivos XML. A primeira opção de uso de DSL é a linguagem baseada em Java, a Java DSL. Entretanto, a plataforma oferece algumas outras opções de DSL, como a Scala DSL e a Groovy DSL. Essa plataforma oferece suporte para integração perfeita com outros frameworks, como CDI, Spring, Blueprint e

Capítulo 2. Referencial Teórico 26

Guice.

2.4.5

Mule Runtime Engine

O Mule Runtime Engine é mantido pela MuleSoft, INC., companhia fundada em 2006. Segundo a Mulesoft, INC. (2017), essa é a única plataforma unificada, existente na indústria, capaz de gerenciar a conectividade e a orquestração de dados e aplicações em um único pacote leve e poderoso. Ela também é a única plataforma capaz de garantir a integração de sistemas legados, aplicações do tipo "Software as a Service"(SaaS) e interfaces de programação de aplicativos (API), com opções híbridas de implantação que garantem o máximo de flexibilidade. Essa implantação é escalável, de forma que embora seja leve o suficiente para rodar no notebook de um engenheiro de software ou em uma arquitetura de microserviços, pode processar milhões de transações em uma aplicação em nuvem.

A arquitetura aberta do Mule Runtime Engine permite que ele ofereça suporte aos padrões abertos, sem estar limitado a eles. Através de pontos de acesso bem definidos e APIs, ele pode ser modificado e personalizado para oferecer suporte a tecnologias novas, personalizadas ou legadas, sem que seu funcionamento interno seja comprometido. Todo componente dessa plataforma possui um papel claro e completamente desacoplado de qualquer outro componente. Dessa forma, os engenheiros de software podem criar soluções de integração usando qualquer combinação de componentes necessária.

Composta a partir da associação do Mule Runtime Engine com outros componentes desenvolvidos pela MuleSoft, INC., existe a ferramenta Anypoint Platform. Segundo a Mulesoft, INC. (2017), essa plataforma é unificada, altamente produtiva e híbrida, sendo capaz de criar uma rede de aplicações integrando aplicativos, dados e dispositivos. As redes de aplicações podem ser criadas e modificadas de forma rápida, através das ferramentas e padrões amigáveis oferecidas aos engenheiros de software. Essas redes podem ser compostas com uso de templates pré-compilados, componentes e outros blocos de construção reutilizáveis, sem necessidade de codificação.

2.5

Resumo do Capítulo

Este capítulo constituiu-se de um referencial teórico sobre EAI, apresentando alguns conceitos fundamentais para o desenvolvimento do restante do trabalho. Foram abordados os fatores que devem ser observados para a integração, o que inclui as limitações e os desafios fundamentais.

Foram abordados os quatro estilos de integração existentes: a transferência de arquivos, o compartilhamento de banco de dados, a chamada de procedimento remoto e o envio de mensagens. Foram abordados também três topologias de integração possíveis: a point-to-point, a hub-and-spoke e a message bus.

Capítulo 2. Referencial Teórico 27

Como exemplo de ferramentas disponíveis para a modelagem de soluções de inte-gração, foi apresentado o conceito de DSL e a linguagem Guaraná DSL, bem como quatro plataformas de integração existentes no mercado: o Guaraná SDK, o Spring Integration, o Apache Camel e o Mule Runtime Engine.

28

3 Caso de Estudo

Foi feita uma consulta com os profissionais do setor de informática da prefeitura municipal de Ijuí - RS a fim de se identificar um ecossistema de software compatível com a proposta da pesquisa. Como resultado dessa consulta, foi escolhido o ecossistema envolvido com a geração dos boletos do Imposto Predial e Territorial Urbano (IPTU) e do Imposto sobre Serviços de Qualquer Natureza (ISSQN). Ambos são impostos municipais de periodicidade anual e são calculados com base em informações contabilizadas pela Secretaria Municipal da Fazenda.

3.1

Ecossistema de Software

A partir da análise do ecossistema de software analisado, foi possível identificar os cinco elementos que o compõe, que são o SGBD, o servidor de email e as aplicações ARCetil, DEISS e NFE 2.0. A seguir é descrito cada um desses elementos.

(a) SGBD: armazena as informações de cada contribuinte e é administrado pela Secretaria Municipal da Fazenda. Ele está em local físico distinto e se comunica com o restante do ecossistema por fibra ótica;

(b) Servidor de e-mail: responsável por enviar o boleto e a nota fiscal eletrônica gerados para cada contribuinte;

(c) Aplicação ARCetil: responsável pela elaboração dos boletos, incluindo o cálculo do imposto devido, usando para isso as informações disponibilizadas pelo banco de dados;

(d) Aplicação DEISS: responsável pela elaboração da declaração de entrega, que é enviada à ARCetil para que seja arquivada;

(e) Aplicação NFE 2.0: responsável pela geração da nota fiscal eletrônica a partir das informações de cada boleto.

O processamento dos tributos pode ser ativado de três maneiras. Ele ocorre de forma automática em uma data predeterminada, mas o contribuinte que está com débitos em atraso pode solicitar a emissão de uma via atualizada através da internet ou diretamente no balcão de atendimento. Atualmente, essas aplicações são integradas de forma manual, havendo uma pessoa responsável pela operação de cada uma delas. Esse método de trabalho é menos ágil e mais propenso a erros em relação a um ecossistema de software integrado de forma automatizada.

Capítulo 3. Caso de Estudo 29

3.2

Solução de Integração Proposta

A solução de integração proposta utiliza cinco tarefas daquelas disponibilizadas pela linguagem Guaraná DSL: Filter, Merger, Replicator, Translator e Inquirer. As quatro primeiras são tarefas simples, enquanto a última é uma tarefa composta a partir das tarefas Replicator, Translator, Correlator e ContextBasedContentEnricher.

A seguir é descrito o funcionamento de cada uma dessas tarefas simples, conforme

Frantz (2012).

(a) ContextBasedContentEnricher: adiciona conteúdo dinâmico, originado de uma men-sagem relacionada ao contexto, ao corpo de uma menmen-sagem base;

(b) Correlator: analisa as mensagens de entrada e produz, na sua saída, conjuntos de mensagens correlacionadas;

(c) Filter: remove mensagens indesejadas;

(d) Merger: combina mensagens de diferentes slots de entrada em um mesmo slot de saída;

(e) Replicator: replica uma mesma mensagem de entrada para cada um dos slots de saída;

(f) Translator: transforma de um esquema para outro o corpo de uma mensagem.

A Figura 7 apresenta o funcionamento da tarefa Inquirer. Essa tarefa composta recebe a mensagem base e faz uma requisição à aplicação externa, através da porta de solicitação. Em seguida, ocorre, também através da porta de solicitação, o recebimento da mensagem de resposta, que é utilizada para enriquecer o conteúdo da mensagem base.

A Figura 8 apresenta o padrão de funcionamento da tarefa composta Inquirer. A mensagem base é recebida por um Replicator, que faz com que uma cópia dela seja remetida para um Translator e outra para um Correlator. A mensagem recebida pelo Correlator tem o seu corpo transformado para um esquema compatível com a aplicação externa e é enviado para ela através da porta de solicitação. Depois do processamento da mensagem pela aplicação externa, esta envia uma mensagem de resposta ao processo. Essa mensagem é recebida através da porta de solicitação e enviada para outra tarefa Translator, que é responsável por converter o seu esquema em outro, compatível com o formato canônico do processo.

A mensagem transformada é enviada para o Correlator. Essa tarefa é responsável por garantir que a mensagem de resposta seja relacionada com a mensagem base correta, especialmente quando se trabalha com portas assíncronas. Por fim, as duas mensagens

Capítulo 3. Caso de Estudo 30

Figura 7 – Representação da tarefa composta Enquirer.

Fonte:Frantz (2012).

Figura 8 – Padrão equivalente à tarefa composta Enquirer.

Fonte:Frantz (2012).

correlacionadas são enviadas para o ContextBasedContentEnricher, que é responsável por acrescentar o conteúdo da mensagem de resposta ao corpo da mensagem base.

A Figura9 apresenta a modelagem da solução de integração proposta, que busca integrar as aplicações do ecossistema de software através do envio de mensagens. O processo conta com três portas de entrada (P1, P2 e P3), que recebem as mensagens de solicitação para a geração da documentação de acordo com o método que elas são feitas: de forma automática, via internet ou através do balcão de atendimento, respectivamente. Essas três portas encaminham as mensagens para a mesma tarefa Merger T1, que combina esses três fluxos de mensagem em um único slot de saída. Esse slot encaminha a mensagem para a tarefa Inquirer T2, reponsável por fazer a consulta ao banco de dados externo

Capítulo 3. Caso de Estudo 31

através da porta de solicitação P4. Essa consulta é necessária para a obtenção dos dados do contribuinte, contabilizados pela Secretaria Municipal da Fazenda, que são utilizados no cálculo do imposto devido. Uma vez que seja obtido o retorno do banco de dados, através da mensagem de resposta, a tarefa T2 acrescenta essas informações ao corpo da mensagem base.

Figura 9 – Modelagem da solução de integração proposta.

Fonte: Do autor (2017).

A mensagem enriquecida é encaminhada à tarefa Inquirer T3, responsável pela comunicação com a aplicação externa ARCetil através da porta de solicitação P5. Uma vez recebidos os dados que constam na mensagem base, a aplicação gera o boleto com o imposto devido e essas informações retornam ao processo como uma mensagem de resposta através da porta P5, sendo recebidas pela tarefa T3. Essa tarefa é responsável por enriquecer o corpo da mensagem base com essas novas informações recebidas.

Em seguida, a mensagem é encaminhada à tarefa Replicator T4, que possui dois slots de saída. Um desses slots encaminha uma cópia da mensagem à tarefa Inquirer T5, responsável pela comunicação com a tarefa externa DEISS através da porta de solicitação P6. Uma vez recebida a mensagem, essa aplicação gera um documento chamado declaração de entrega. Os dados referentes a esse documento retornam ao processo como

Capítulo 3. Caso de Estudo 32

uma mensagem de resposta através da porta P6 e são acrescentados pela tarefa T5 à sua cópia da mensagem base.

Essa mensagem enriquecida é encaminhada à tarefa Translator T6, que a converte para um formato compatível com a aplicação ARCetil. Depois de feita essa conversão, ela é enviada para essa aplicação para ser arquivada, através da porta de saída P7.

O outro slot da tarefa T4 encaminha uma cópia da mensagem à tarefa Inquirer T7, responsável pela comunicação com a aplicação externa NFE 2.0 através da porta de solicitação P8. A partir dos dados da mensagem recebida, essa aplicação gera a nota fiscal eletrônica correspondente. As informações relativas à nota fiscal criada retornam ao sistema como uma mensagem de resposta através da porta P8 e são acrescentadas ao corpo da mensagem base pela tarefa T7.

A mensagem enriquecida é encaminhada à tarefa Filter T8, que elimina do fluxo de mensagens aquelas que não contém um endereço de e-mail válido. Caso a mensagem não seja descartada, ela segue para a tarefa Translator T9, que a converte para um formato compatível com o servidor de e-mail. Em seguida, elas são encaminhadas através da porta de saída P9 para esse servidor, de onde são, finalmente, enviadas para o contribuinte.

Considerou-se todas as portas de solicitação como assíncronas, uma vez que não há garantia de que as mensagens de resposta sejam recebidas na mesma ordem que as mensagens de solicitação foram enviadas. As tarefas Correlator, componentes da tarefa composta Inquirer, garantem que cada mensagem de resposta seja combinada com a mensagem original correta, uma vez que seja recebida pelo processo.

Acredita-se que a solução proposta pode integrar o ecossistema de software de forma satisfatória, fazendo com que as aplicações possam trabalhar de forma conjunta e de forma automatizada. Com isso pode ser verificado que a Linguagem Guaraná DSL oferece um suporte adequado à modelagem de soluções de integração no contexto da administração pública. No presente caso de estudo não foi identificada nenhuma diferença em relação à modelagem de soluções de integração para organizações privadas, quando comparada ao processo apresentado no trabalho de Silva et al. (2015).

A solução de integração proposta atingiu os objetivos propostos, mostrando-se uma alternativa viável para o ecossistema de software abordado. A implementação real da solução de integração, embora fora do escopo desse trabalho, poderia aumentar a eficiência do ecossistema, tornando o processo de emissão dos boletos menos sujeito a erros.

Capítulo 3. Caso de Estudo 33

3.3

Resumo do Capítulo

Este capítulo apresentou o caso de estudo escolhido, que é o ecossistema de software responsável pela geração dos boletos de IPTU e ISSQN na prefeitura de Ijuí - RS. Foram abordadas os componentes esse ecossistema, que são o banco de dados, o servidor de email e as aplicações. Em seguida, foi apresentada a modelagem da solução de integração proposta para esse ecossistema, baseada no envio de mensagens. Por fim, foi apresentada a análise sobre a adequação da linguagem Guaraná DSL ao contexto da administração pública, que se mostrou positiva.

34

Conclusão

O campo da EAI oferece metodologias, técnicas e ferramentas para que consigamos fazer trabalhar em conjunto aplicações que não foram criadas tendo em vista essa finalidade. Devido ao fato desse campo não ser estudado no curso de graduação em Ciência da Computação, mesmo nos componentes relativos à Engenharia de Software, foi necessário o estudo de vários tópicos referentes a ele, de forma que pudessem ser atingidos os objetivos propostos para esse trabalho.

Foram tratados os fatores que devem ser levados em conta para a criação de cada solução de integração, como os tópicos específicos e as limitações relativas a cada caso em particular. Em seguida foram abordados os estilos de integração existentes, que são a transferência de arquivos, o compartilhamento de banco de dados, a chamada de procedimento de remoto e o envio de mensagens. Foram apresentadas também as topologias de integração mais usuais, que são a point-to-point, a hub-and-spoke e a message bus.

Abordando as ferramentas desenvolvidas no campo da EAI, foram discutidas as DSLs, que são linguagens de programação criadas com o propósito de modelar soluções para problemas de um domínio específico. Dentro das DSLs, foi destacada a Guaraná DSL, linguagem utilizada e avaliada durante o restante do trabalho. Foram apresentadas também quatro plataformas de integração disponíveis no mercado: o Guaraná SDK, o Spring Integration, o Apache Camel e o Mule Runtime Engine.

Como prosseguimento, foi identificado um caso de estudo na administração pública municipal da cidade de Ijuí - RS: o ecossistema de software responsável pela emissão dos boletos do IPTU e do ISSQN. Esse caso de estudo foi escolhido de modo que pudesse ser avaliada a adequação da linguagem Guaraná DSL à modelagem de soluções de integração no contexto da administração pública.

Todos os objetivos intermediários foram atingidos, uma vez que o trabalho permitiu o estudo de diversos conceitos ligados ao campo da EAI. Da mesma forma, a identificação do caso de estudo e a proposta e modelagem de uma solução de integração permitiram avaliar a adequação da linguagem DSL ao contexto da administração pública. A análise sobre essa adequação se mostrou positiva, indicando que o uso da linguagem Guaraná DSl é uma alternativa viável nesse contexto. Não foram encontradas diferenças no processo de modelagem quando comparado com aquele apresentado no trabalho de Silva et al. (2015).

Conclusão 35

Como trabalho futuro, poderia ser identificado um caso de estudo semelhante, no mesmo contexto, onde houvesse interesse na implementação real de uma solução de integração baseada no envio de mensagens. Dessa forma, poderia ser apresentada uma proposta que fosse modelada através da linguagem Guaraná DSL e transformada em uma solução computacional real, através do uso da tecnologia Guaraná SDK.

36

Referências

CARGNIN, R. S. et al. Simulação de uma solução de integração com redes de petri estocásticas para o problema da central telefônica na UNIJUÍ. XX Jornada de Pesquisa, v. 1, n. 1, 2015. Citado na página 11.

CLIFFORD, A. Minimal integration 7: point-to-point, hub, or bus? 2005. Acesso em: 17 Dez. 2015. Disponível em: <http://it.toolbox.com/blogs/minimalit/

minimal-integration-7-pointtopoint-hub-or-bus-6527>. Citado 2 vezes nas páginas 20

e 22.

FRANTZ, R. Z. Enterprise Application Integration - An Easy-to-Mantain Model-Driven

Engineering Approach. Tese (Doutorado) — Universidad de Sevilla, 2012. Citado 3 vezes

nas páginas 23, 29e 30.

FRANTZ, R. Z.; CORCHUELO, R.; MOLINA-JIMÉNEZ, C. A proposal to detect errors in enterprise application integration solutions. Journal of Systems and Software, Elsevier, v. 85, n. 3, p. 480–497, 2012. Citado na página 24.

FRANTZ, R. Z.; QUINTERO, A. M. R.; CORCHUELO, R. A domain especific language to design enterprise aplication integration solutions. International Journal of Cooperative

Information Systems, World Scientific, v. 20, n. 02, p. 143–176, 2011. Citado na página

10.

GHOSH, D. DSLs in Action. [S.l.]: Manning Publications Co., 2010. Citado na página 22. HOHPE, G. Hub and Spoke [or] Zen and the Art of Message Broker Maintenance. 2003. Acesso em: 17 Dez. 2015. Disponível em: <http://www.enterpriseintegrationpatterns.com/ ramblings/03_hubandspoke.html>. Citado 4 vezes nas páginas10,19, 21e 22.

HOHPE, G.; WOOLF, B. Enterprise integration patterns - Designing, building, and

deploying messaging solutions. [S.l.]: Addison-Wesley, 2004. Citado 5 vezes nas páginas

14, 15, 22,23 e25.

Mulesoft, INC. MuleSoft | Integration Platform for Connecting SaaS and Enterprise

Applications. 2017. Acesso em: 04 Maio 2017. Disponível em:<http://www.mulesoft.com/>. Citado na página 26.

Pivotal Software. Spring. 2017. Acesso em: 04 Maio 2017. Disponível em:

<http://spring.io/>. Citado na página 25.

SILVA, E. G. da et al. Desenvolvimento de uma solução de integração de aplicações para automatizar reservas de viagens. XXIII Seminário de Iniciação Científica, v. 1, n. 1, 2015. Citado 3 vezes nas páginas 11, 32e 34.

SPACEY, J. What is Separation Of Concerns? 2016. Acesso em: 03 Maio 2017. Disponível em: <http://simplicable.com/new/separation-of-concerns>. Citado na página 25. The Apache Software Foundation. Apache Camel. 2015. Acesso em: 04 Maio 2017. Disponível em: <http://camel.apache.org/>. Citado na página 25.

Referências 37

The Apache Software Foundation. Welcome to the Apache Software Foundation! 2017. Acesso em: 04 Maio 2017. Disponível em: <http://www.apache.org/>. Citado na página

Modelagem de uma Solução de Integração no

Contexto da Administração Pública Municipal

Ivan E. M. Kühne

Universidade Regional do Noroeste do Estado do Rio Grande do Sul Departamento de Ciências Exatas e Engenharias

Ijuí, RS, Brasil oitentaetres@gmail.com

Resumo—Pode ser observada uma tendência crescente no

uso de sistemas informatizados em organizações de diversas naturezas. Entretanto, a simples adição de novas aplicações nem sempre atinge às necessidades dessas organizações de forma sa-tisfatória. Pode ser necessário recorrer às metodologias, técnicas e ferramentas do campo da Integração de Soluções Empresariais. Entre essas, podemos citar a linguagem Guaraná DSL, que foi criada com o objetivo de possibilitar a modelagem de soluções de integração em alto nível de abstração. Nesse artigo é demonstrado o uso da Guaraná DSL para a modelagem de uma solução de integração para um caso de estudo identificado no contexto da administração pública da cidade de Ijuí - RS: o ecossistema de software envolvido na geração de boletos de impostos municipais. Palavras-chave: Integração de Aplicações Empresariais; Lin-guagem de Domínio Específico; Administração Pública.

I. INTRODUÇÃO

Empiricamente, pode ser observado que a parcela de orga-nizações, seja no setor público ou privado, que dependem de sistemas informatizados para a execução dos seus processos de negócio é cada vez maior. Ao conjunto dessas aplicações dentro de cada organização é dado o nome de ecossistema de

software. Ainda de forma empírica, pode ser observado que, dentro de cada organização, a parcela de processos de negócio que depende do seu ecossistema de software tem mostrado uma tendência crescente.

Entretanto, a simples adição de novas aplicações ao ecossis-tema de software nem sempre cumpre satisfatoriamente com os objetivos da empresa. De acordo com Hohpe and Woolf [3], novas demandas relativas aos processos de negócio vão surgindo ao longo da existência das organizações. Assim, pode tornar-se necessária não só a adição de novas aplicações, mas também a criação de condições para que elas possam trabalhar conjuntamente, através do compartilhamento de informações ou funcionalidades. Essa não é uma tarefa fácil, tendo em vista que as aplicações podem ter sido desenvolvidas em lingua-gens de programação diferentes, usarem diferentes formatos de dados e arquivos e terem sido desenvolvidas em épocas diferentes e por pessoas ou empresas diferentes. Além disso, as aplicações normalmente não são desenvolvidas tendo em vista a sua futura integração.

Para que a integração seja possível, desenvolveu-se ao longo dos anos, dentro da área da Engenharia deSoftware, o campo da Integração de Soluções Empresariais (EAI), que fornece

metodologias, técnicas e ferramentas para construção de so-luções de integração. Segundo Frantz et al. [1], a EAI deve preservar e sincronizar os dados e aplicações já existentes, além de criar novas funcionalidades a partir deles.

II. GUARANÁDSL

Entre as ferramentas desenvolvidas no campo da EAI está a linguagem de domínio específico (DSL) Guaraná DSL. Con-forme Ghosh [2], uma DSL é uma linguagem de programação criada para resolver um tipo específico de problema. Cada DSL é limitada à resolução de problemas dentro do domínio para o qual foi criada, diferentemente das linguagens de propósito geral (GPL), que são capazes de modelar soluções para uma ampla gama de problemas. Entretanto, dentro desse domínio limitado, a DSL é extremamente expressiva, de forma que pode ser compreendida até por pessoas que não possuem familiaridade com linguagens de programação. Outro fator que facilita essa compreensão é que a sintaxe e semântica das DSL modelam conceitos no nível de abstração do domínio do problema, não no nível de abstração do domínio da solução.

A linguagem Guaraná DSL oferece suporte aos padrões de integração documentados por Hohpe and Woolf [3] e se destina à criação de soluções de integração em alto nível de abstração. Como é característico das DSL, seu alto nível de abstração permite que as soluções concebidas e modeladas sejam com-preensíveis por profissionais sem familiaridade com a área de Engenharia de Software, como gerentes e administradores.

III. CASO DEESTUDO

O caso de estudo escolhido para este artigo foi identificado no contexto da administração pública municipal da cidade de Ijuí. Ele consiste no ecossistema de software envolvido no processo de geração de boletos do Imposto Predial e Territorial Urbano (IPTU) e do Imposto sobre Serviços de Qualquer Natureza (ISSQN), ambos de periodicidade anual, para os contribuintes.

A. Ecossistema de Software

O IPTU e o ISSQN são calculados pela aplicação ARcetil. Esse cálculo pode ser ativado de três maneiras. A principal ma-neira é a ativação automática que é feita anualmente para todos os cidadãos cadastrados, em data pré-determinada. Entretanto,

Figura 1. Modelo conceitual da solução de integração proposta.

aqueles contribuintes que possuem vencimentos em aberto podem solicitar uma via atualizada através da internet ou no balcão de atendimento. Os dados necessários para o cálculo do IPTU e do ISSQN são obtidos a partir de uma consulta a um banco de dados que é administrado pela Secretaria Municipal da Fazenda.

Usando os dados obtidos, o ARcetil calcula o imposto devido. A partir do valor desse imposto, a aplicação NFE 2.0 gera a nota fiscal eletrônica, que é enviada para o ci-dadão no formato XML através de um servidor de e-mail. Também a partir do imposto calculado, a aplicação DEISS gera a declaração de entrega, que é arquivada pelo ARcetil. Atualmente a integração entre essas aplicações é feita de forma manual, por um operador responsável por cada uma delas. Essa metodologia de trabalho é menos ágil e mais sujeita a erros em relação a um sistema integrado de forma informatizada.

B. Solução de Integração

O modelo conceitual proposto está representado na Figura 1 e busca integrar as aplicações do ecossistema identificado utilizando o estilo de integração baseado em mensagens [3]. O processo conta com três portas de entrada (P1, P2 e P3), que recebem as requisições para o cálculo de imposto de acordo com o método que elas foram feitas (automático, viainternet

ou via balcão de atendimento). Essas três portas de entrada encaminham as solicitações para a mesma tarefa Merger T1, que é responsável por juntar esses três fluxos de mensagens em um único. Cada mensagem é encaminhada para a tarefa

Replicator T2, que faz com que ela seja duplicada. Uma das cópias é encaminhada para a tarefa Translator T3 e em seguida para a consulta ao banco de dados, através da porta de solicitação P4. Essa passagem pela tarefa Translator T3 é necessária para a conversão da mensagem para um formato compreensível pelo banco de dados.

A outra cópia é encaminhada para a tarefaCorrelator T4. O resultado da consulta retorna à solução de integração através da porta P4 e é encaminhado para a tarefaTranslator T5, respon-sável por traduzi-lo para o formato adequado para o processo. A mensagem traduzida é encaminhada para a tarefaCorrelator

T4, responsável por reunir as mensagens que são relativas a um mesmo contribuinte. As mensagens correlacionadas são enviadas para a tarefaContext-Based Content EnricherT6, que enriquece a mensagem original com as informações retornadas pelo banco de dados.

A mensagem enriquecida é enviada à aplicação ARcetil através da porta de solicitação P5. Essa aplicação é responsável pelo cálculo do imposto devido. O resultado desse cálculo retorna ao processo através da porta P5 e é encaminhado para a tarefaReplicator T7, responsável por duplicar a mensagem. Uma das cópias é encaminhada para a aplicação DEISS através da porta de solicitação P6. Essa aplicação cria a declaração de entrega, que retorna ao processo através da porta P6. Em seguida, a mensagem relativa a essa declaração é encaminhada, através da porta de saída P7, à aplicação ARcetil, onde é processada para que os seus dados sejam arquivados.

A outra cópia criada pela tarefa Replicator T7 é encami-nhada, através da porta de solicitação P8, à aplicação NFE 2.0, que faz a geração da nota fiscal eletrônica correspondente. O resultado dessa operação retorna ao processo através da porta P8 para ser enviado ao contribuinte. Para que isso ocorra, primeiro a mensagem passa pela tarefaFilter T8, que elimina as mensagens que não contém um endereço dee-mail válido. As mensagens restantes são encaminhadas à tarefaTranslator

T9, que faz a tradução para o formato aceito pelo servidor de

e-mail. Em seguida, as mensagens transformadas são enviadas para esse servidor através da porta de saída P9. Finalmente, a nota fiscal eletrônica é enviada ao contribuinte.

IV. CONCLUSÃO

Através do uso da Guaraná DSL, foi possível modelar uma solução de integração no contexto da administração pública. No presente caso de estudo não foi identificada nenhuma diferença em relação à modelagem de soluções de integração para organizações de administração privada.

Em caso de implementação real da solução de integração proposta, poderia-se fazer as cinco aplicações trabalharem de maneira integrada, através da troca de mensagens, sem a necessidade de intervenção manual. A eliminação dessa necessidade diminui, se não suprime, a possibilidade de erros que foi identificada durante a análise do caso de estudo. Assim pode-se perceber mais uma vantagem que a EAI pode agregar aos processos de trabalho das organizações em que ela é implementada, que é a diminuição ou supressão das ocorrências de erro. No futuro podem ser encontrados mais casos de estudo que possuem essa característica e pode ser feita a implementação da solução de integração proposta.

REFERÊNCIAS

[1] Rafael Z. Frantz, Antonia M. Reina Quintero, and Rafael Cor-chuelo. A domain especific language to design enterprise aplica-tion integraaplica-tion soluaplica-tions. Internaaplica-tional Journal of Cooperative

Information Systems, 20(02):143–176, 2011.

[2] Debasish Ghosh. DSLs in action. Manning Publications Co., 2010.

[3] Gregor Hohpe and Bobby Woolf. Enterprise Integration

Pat-terns - Designing, Building, and Deploying Messaging Solutions.