UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS

Tamanho: px
Começar a partir da página:

Download "UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS"

Transcrição

1 UNIVERSIDADE FEDERAL DO ABC PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO REINALDO DE SOUZA GONZAGA UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS Santo André 2014

2

3 PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO REINALDO DE SOUZA GONZAGA UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal do ABC UFABC como requisito parcial para a obtenção do Título de Mestre em Ciência da Computação. Orientadora: Prof.ª Dr.ª Fabiana Soares Santana Santo André 2014

4 UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS Reinaldo de Souza Gonzaga Área de Concentração: Ciência da Computação Linha de Pesquisa: Arquitetura de Software Banca Examinadora: Prof.ª Dra. Fabiana Soares Santana UFABC Orientadora e Presidente Prof. Dr. Edson Pinheiro Pimentel UFABC Titular Interno Prof. Dr. Pedro Luiz Pizzigatti Corrêa POLI-USP Titular Externo Prof. Dr. Luiz Carlos da Silva Rozante UFABC Suplente Interno Prof.ª Dra Anarosa Alves Franco Brandão POLI-USP Suplente Externo

5 Este exemplar foi revisado e alterado em relação à versão original, de acordo com as observações levantadas pela banca no dia da defesa, sob responsabilidade única do autor e com a anuência de seu orientador. Santo André, de de 20. Assinatura do autor: Assinatura do orientador:

6 FICHA CATALOGRÁFICA Gonzaga, Reinaldo de Souza. UMA ABORDAGEM ARQUITETURAL PARA A ORQUESTRAÇÃO DINÂMICA DE SERVIÇOS. Gonzaga, R. S. -- Santo André, p. DISSERTAÇÃO DE MESTRADO - Centro de Matemática, Computação e Cognição, Universidade Federal do ABC. 1.Arquitetura de Software; 2. Arquiteturas Orientadas a Serviço; 3. Orquestração Dinâmica de Serviços. I. Universidade Federal do ABC; II. Centro de Matemática, Computação e Cognição.

7 Agradecimentos A todas as pessoas que direta ou indiretamente foram impactadas pela minha ausência no convívio social, mas que compreenderam que o motivo era justo e necessário. À Fabiana, que consegue a incrível proeza de ser mais boazinha do que minha avó. Sua paciência e disponibilidade para me ajudar desmitificaram o conceito que eu tinha de um orientador antes de iniciar o mestrado. Aos amigos e chefes do trabalho, que permitiram a minha ausência em diversas ocasiões.

8 Resumo A arquitetura orientada a serviços (SOA Service Oriented Architecture) é um paradigma amplamente utilizado na engenharia de software para prover soluções de software reutilizáveis e integráveis baseadas em serviços. O barramento de serviços (ESB Enterprise Service Bus) é uma das estruturas mais importantes para as soluções baseadas em SOA, pois é responsável por conectar e intermediar todas as comunicações entre aplicações e serviços. A seleção dinâmica de serviços é um problema complexo e a grande maioria das soluções existentes são eficazes somente quando atendidas premissas para os serviços que não condizem com a realidade dos padrões de especificação de serviços existentes. Este trabalho apresenta uma proposta de solução arquitetural para incorporar a seleção dinâmica de serviços aos ESBs e permitir a incorporação das diversas soluções para seleção dinâmica de serviços propostas sem alterar os atuais padrões de serviços. Além da nova proposta arquitetural, o trabalho apresenta os resultados de um estudo de caso onde a proposta arquitetural foi incorporada ao Mule ESB, no qual um algoritmo para seleção de serviços baseado em tabelas de decisão adaptativas foi desenvolvido e inserido. Os resultados obtidos nos testes com a solução implementada foram promissores. Palavras-chave: Seleção dinâmica de serviços, SOA, ESB.

9 Abstract Service oriented architecture (SOA) is a widely applied paradigm in software engineering to provide reusable and integrable software solutions based on services. The Enterprise Service Bus (ESB) is one of the most important structures for SOA-based solutions because it is responsible for connecting and mediating all communication between applications and services. Dynamic service selection is a complex problem and most existing solutions to it are effective only when met assumptions for services that do not match the reality of the standards defined for the existing services. This work presents an architectural proposal to embed dynamic selection of services into ESBs to allow the incorporation of the various solutions proposed for dynamic service selection without changing the current services standards. In addition to the new architectural proposal, the work presents the results of a case study where the architectural proposal was incorporated into the Mule ESB and an algorithm for dynamic service selection based on adaptive decision tables was developed and implemented. The results with the implemented solution were promising. Keywords: Dynamic service selection, SOA, ESB.

10 Sumário Lista de Figuras Lista de Tabelas Lista de Siglas Introdução Descrição do problema Objetivos Objetivo Geral Objetivos Específicos Metodologia Revisão Bibliográfica Arquitetura de Software Arquitetura Orientada a Serviços (SOA) ESB (Enterprise Service Bus) Trabalhos Relacionados Proposta Arquitetural para o Barramento de Serviços Algoritmo para Seleção de Serviços Proposta Arquitetural de Alteração do ESB Estudo de Caso: Implementação da Solução Proposta aplicando Algoritmo Baseado em Tabelas de Decisão Adaptativas Implementação da Solução Proposta Execução e Testes da Solução Teste de Sucesso... 47

11 Teste de Tempo de Resposta Teste de Indisponibilidade Conclusão Referências Bibliográficas Apêndice A... 61

12 Lista de Figuras Figura 1: Evolução dos paradigmas de arquitetura Figura 2: Fluxo de uma arquitetura SOA Figura 3: Etapas para aplicação de SOA Figura 4: Entreprise Service Bus Figura 5: Estrutura interna de um ESB Figura 6: Fluxo de integração através do ESB Figura 7: Exemplo de consulta utilizando linguagem SWSQL Figura 8: Proposta de solução arquitetural Figura 9: Desenvolvimento do ESB Figura 10: Arquivo com metadados dos serviços disponíveis Figura 11: Web Services utilizados Figura 12: Trecho de código executado pelos Web Services Figura 13: Aplicação cliente Figura 14: Aplicação cliente Figura 15: Classificação e status dos serviços disponíveis Figura 16: Resultado na aplicação cliente Figura 17: Aplicação cliente Figura 18: Classificação e status dos serviços disponíveis Figura 19: Classificação e status dos serviços disponíveis Figura 20: Resultado na aplicação cliente Figura 21: Aplicação cliente Figura 22: Classificação e status dos serviços disponíveis Figura 23: Classificação e status dos serviços disponíveis Figura 24: Resultado na aplicação cliente... 55

13 Lista de Tabelas Tabela 1: Tabela de decisão adaptativa Tabela 2: Algoritmo de seleção dinâmica Tabela 3: Exemplo de variáveis de qualidade de serviços Tabela 4: Exemplo de tabela de decisão adaptativa preenchida... 37

14 Lista de Siglas ESB FTP HTTP IEEE JDBC MOM OWL POP3 QOS REST SMTP SOA SOAP SOC TCP TI UDDI UDP UMO Enterprise Service Bus File Transfer Protocol Hypertext Transfer Protocol Instituto de Engenheiros Eletricistas e Eletrônicos Java Database Connectivity Message Oriented Middleware Web Ontology Language Post Office Protocol Quality of service Representational state transfer Simple Mail Transfer Protocol Service Oriented Architecture Simple Object Access Protocol Service Oriented Computing Transmission Control Protocol Tecnologia da Informação Universal Description, Discovery and Integration User Datagram Protocol Universal Message Object

15 15 1 Introdução A constante evolução do hardware tem disponibilizado um grande poder computacional para as aplicações de software. Entretanto, para que as aplicações de software consigam usufruir adequadamente deste poder computacional, é necessário aumentar a produtividade de software (FOX; PATTERSON, 2012). As linguagens de programação de alto nível, a criação de sintaxes mais simples e intuitivas e o uso de ferramentas e ambientes para automatizar o desenvolvimento de software, dentre outros, são alternativas para aumentar a produtividade, pois transferem grande parte dos processos manuais e repetitivos do desenvolvedor para o computador. Dentre os processos de aumento de produtividade no desenvolvimento de software, o reuso é um conceito fundamental (GRISS, 1997). O reuso pode ser aplicado ao código, à arquitetura e também aos processos relacionados ao desenvolvimento de software. Paradigmas como programação orientada a objetos e computação orientada a serviços podem trazer ganhos significativos para a produtividade através do reuso e da integração de componentes (FOX; PATTERSON, 2012). A evolução dos paradigmas arquiteturais tem se apresentado como um dos principais conceitos em discussões sobre como a computação pode suportar o desenvolvimento, o controle e a gestão de negócios. O valor dos projetos de integração de uma empresa ou organização é diretamente proporcional à sua complexidade (BASS, CLEMENTS e KAZMAN, 2003), ou seja, quanto mais abrangente e complexo tornam-se os softwares de uma organização, maior é a dificuldade e o trabalho para a organização de seus componentes. Organizações deparam-se diariamente com a necessidade de maximizar o uso de seus recursos e, consequentemente, existe uma grande expectativa em torno da redução de custos associados ao desenvolvimento e aquisição de software (ENDREI et al. 2004). Além da redução de custos, os critérios para avaliar a evolução dos paradigmas arquiteturais compreendem a facilidade para a manutenção dos sistemas corporativos, as melhorias na escalabilidade dos sistemas, o potencial de reuso e a capacidade de integração e

16 16 interoperabilidade. O paradigma computacional orientado a serviços (SOC Service Oriented Computing) permite a execução de transações através de diversas plataformas, provendo a interoperabilidade de software. Arquitetura orientada a serviços (SOA Service Oriented Architecture) é um paradigma arquitetural para SOC (HUHNS; SINGH, 2005). A adoção de SOA geralmente requer um grande esforço financeiro e computacional. Entretanto, os custos com o desenvolvimento das aplicações tendem a diminuir ao longo do tempo, devido à aplicação de reuso em larga escala, inclusive de sistemas legados (ENDREI et al. 2004) (MACKENZIE et al., 2006). Apesar dos benefícios proporcionados pela arquitetura de software baseada em serviços, existem também problemas que surgem com a sua adoção. A maioria destes problemas está relacionada à gestão e orquestração dos serviços e à sua qualidade. A orquestração de serviços trata da execução de processos de negócio definidos a partir da interação entre serviços computacionais internos e externos ao ambiente empresarial (PELTZ, 2003). A qualidade dos serviços (QoS Quality of Service) pode ser representada por variáveis como disponibilidade, segurança, tempo de resposta e tempo de processamento, entre outros (LIU et al., 2004; MENASCÉ, 2002). A gestão e orquestração de serviços em aplicações baseadas em SOA podem ser realizadas através de uma solução conhecida como barramento de serviços (ESB Enterprise Service Bus). Alguns dos aspectos mais relevantes que um ESB deve prover são a seleção e execução de serviços de forma automática (CASATI et al., 2004). Em uma solução baseada em serviços, pode existir mais de uma opção de serviços, providos por provedores diferentes, que executam a mesma funcionalidade. Dessa forma, seria possível efetuar a seleção de serviços de maneira dinâmica, ou seja, em tempo de execução; e não através de serviços pré-definidos na fase de desenvolvimento da aplicação. Diversas técnicas podem ser aplicadas para a escolha de um serviço ou conjunto de serviços a partir de uma lista de serviços existentes para a mesma funcionalidade. Porém, é importante notar que muitas variáveis que aferem a qualidade dos serviços podem sofrer alterações com o tempo, o que pode afetar o seu desempenho e, por consequência, o desempenho da aplicação (SANTANA et al., 2009). Diversas propostas para a seleção dinâmica de serviços foram apresentadas (SHAIKHALI et al., 2003; SCHMIDT et al., 2005; YU; REIFF-MARGANIEC, 2008; DUJMOVIC, 1973; YAGER, 1988; TOMA et al., 2007; PATHAK et al., 2005; LIN et al., 2004; SOYDAN BILGIN; SINGH, 2004; CAVERLEE et al., 2004; FENG et al., 2007;

17 17 SANTANA et al., 2009b; YANG et al., 2005; CASATI et al., 2004; MATAI; HAN, A partir da análise das propostas apresentadas, pode-se notar que, além de não existir um padrão entre elas, adotam premissas para o seu funcionamento que não estão presentes nas especificações de serviços existentes. Por exemplo, os algoritmos propostos nas soluções estudadas pressupõem a existência de atributos de qualidade de serviço que não fazem parte da especificação padrão de web services, ou seja, esses algoritmos estão baseados em informações não disponíveis para a maioria dos serviços disponíveis na Internet e apenas uma mudança nos padrões atuais permitiria a adoção dessas soluções. Da mesma forma, os ESBs não estão preparados para implementar essas soluções. Para se obter uma solução mais abrangente e genérica para o problema da seleção dinâmica de serviços, é preciso ou redefinir os padrões para publicação de serviços na Internet ou prover uma alteração na arquitetura dos ESBs para que a seleção de serviços possa ser feita com base em informações armazenadas ou inferidas localmente sobre os serviços utilizados. Dessa forma, a implementação das soluções propostas para a seleção dinâmica de serviços se torna viável e os ESBs podem fazer a seleção dinâmica de serviços de forma independente e mais eficiente. 1.1 Descrição do problema Durante a análise dos problemas existentes relacionados com a infraestrutura e com as aplicações para soluções orientadas a serviços, foi observado que o ranqueamento e a seleção dinâmica de serviços são áreas de pesquisa que ainda não estão devidamente contempladas pelas ferramentas ou propostas disponíveis. O ranqueamento e a seleção dinâmica de serviços se aplicam principalmente aos casos em que existem diversos provedores de serviços que oferecem a mesma competência. Nesses casos, variáveis como tempo de resposta, tempo de execução do serviço, disponibilidade, confiabilidade e custo do serviço devem ser consideradas para definir qual dos serviços providos deve ser utilizado (BERANDER et al., 2005; FENG et al., 2007). A orquestração de serviços pode ser feita de forma dinâmica, decidindo e selecionando o serviço a ser utilizado no momento de sua instanciação. Iniciativas para a seleção e orquestração dinâmica de serviços foram apresentadas, envolvendo áreas de pesquisa que variam de ontologias a algoritmos em grafos, mas estas

18 18 iniciativas se restringem a soluções algorítmicas que consideram determinadas hipóteses sobre os serviços que não são válidas universalmente. Por exemplo, existem hipóteses sobre a descrição dos serviços usando ontologias e sobre os atributos de qualidade, que infelizmente ainda não são a realidade da maioria dos serviços registrados disponíveis no mercado e, como ainda não fazem parte de nenhum padrão definido pelo W3C [http://www.w3.org/] ou equivalente, talvez nunca sejam incorporados aos web services. 1.2 Objetivos Objetivo Geral Este trabalho tem como objetivo principal propor uma solução arquitetural para incorporar a seleção dinâmica de serviços aos ESBs disponíveis no mercado Objetivos Específicos Implementar a solução arquitetural proposta em um ESB de mercado. Incorporar o algoritmo de seleção baseado em tabelas de decisão adaptativas (SANTANA et al., 2009b) na solução implementada. Permitir, a partir da solução proposta, que diversos algoritmos possam ser incorporados aos ESBs através da mesma solução arquitetural, tornando-os mais flexíveis e eficientes do ponto de vista da seleção dinâmica de serviços. Executar uma série de experimentos com a solução implementada, para avaliar o comportamento da orquestração de serviços pelo ESB. 1.3 Metodologia Segundo os conceitos propostos por Silva e Menezes (2005), este trabalho está classificado da seguinte forma: Quanto à natureza do trabalho: Aplicado, pois é destinado a uma aplicação prática

19 19 para orquestração dinâmica de serviços. Quanto à forma de abordagem: Qualitativa, pois a abordagem proposta não utiliza modelos quantitativos na sua analise e desenvolvimento. Quanto aos objetivos do trabalho: Exploratório, pois consiste em levantamento bibliográfico sobre o tema seguido de uma proposta de abordagem e implementação. Quanto aos procedimentos técnicos: Experimental, pois determina um objeto de estudo, selecionando as principais variáveis que o influenciam e definindo as formas de controle e de observação dos efeitos que estas variáveis exercem no objeto. A partir da classificação definida acima, a metodologia adotada e que gerou este trabalho seguiu as seguintes etapas: 1. Revisão bibliográfica da literatura relacionada, incluindo livros, artigos de conferências, periódicos e especificações. O conteúdo detalhado desta etapa está descrito no capítulo 02. Além da bibliografia baseada em livros dos principais autores sobre o tema, foram também pesquisados sites de artigos científicos e anais relacionados ao tema para uma exposição mais atual sobre o estado da arte em torno do assunto. 2. Análise de trabalhos relacionados ao problema abordado. 3. Estudo de tecnologias: XML, Web Services, SOAP, WSDL. Para desenvolver formas de se seleção dinâmica de serviços. Java. Para desenvolvimento de componentes arquiteturais e da camada lógica de Web Services. Ferramentas disponíveis no mercado para barramento de serviços (ESB). 4. Projeto de uma solução para o problema estudado. 5. Implementação da solução proposta e projetada, através de um estudo de caso prático. 6. Preparação de ambientes e cenários para testar a solução implementada. 7. Testes com a solução desenvolvida. 8. Avaliação dos resultados obtidos. 9. Elaboração da dissertação. Para o desenvolvimento das aplicações foram utilizadas as seguintes ferramentas: 1. MuleSoft - Versão 3.4

20 20 Ferramenta ESB open source para integração de aplicações e orquestração de serviços em arquiteturas SOA. 2. NetBeans IDE - Versão 7.4 Ferramenta de código-fonte aberto para desenvolvimento de aplicações Java web, desktop e móveis. O trabalho está organizado da seguinte maneira: O capitulo 1 apresenta uma introdução apresentando a descrição do problema abordado, a justificativa e os objetivos deste trabalho. O capitulo 2 apresenta uma revisão bibliográfica sobre os conceitos necessários para o desenvolvimento do trabalho. Entre eles, estão conceitos sobre arquitetura de software orientada a serviços e barramento de serviços, além de uma seção que discute trabalhos relacionados à seleção dinâmica de serviços. O capitulo 3 apresenta a proposta para a solução do problema de orquestração dinâmica de serviços e o estudo de caso desenvolvido para ilustrar a aplicação e teste da solução proposta. Por fim, o capitulo 4 apresenta as conclusões do trabalho bem como possíveis trabalhos futuros relacionados ao tema.

21 21 2 Revisão Bibliográfica Neste capítulo são apresentados os principais conceitos presentes na literatura relacionados à arquitetura de software, arquitetura orientada a serviços e barramento de serviços, além de uma revisão bibliográfica das soluções propostas para a orquestração dinâmica de serviços. 2.1 Arquitetura de Software Arquitetura de um software é o conjunto de estruturas compostas pelos elementos de software, suas propriedades externamente visíveis e o relacionamento entre eles. Ela também pode ser entendida como a abstração das informações presentes nos elementos que compõem o software e que não estão diretamente relacionados com a sua interação com os demais elementos (BASS et al., 2003). Padrão arquitetural é a descrição dos elementos de uma arquitetura, seus relacionamentos e suas restrições. Um modelo de referência em arquitetura de software estipula um padrão de decomposição de um problema conhecido em partes menores, as quais devem resolver o problema de forma cooperativa. Arquitetura de referência é o mapeamento do modelo de referência sobre os elementos de software, que implementam as funcionalidades definidas no modelo de referência de maneira cooperativa. Padrões arquiteturais, modelos de referência e arquiteturas de referência não são arquiteturas, mas sim conceitos que capturam os elementos de uma arquitetura de software (SANTANA, 2009). A orientação a serviços é recomendada principalmente para sistemas que apresentem fortes requisitos de interoperabilidade e integração, especialmente no caso de integração de aplicações desenvolvidas com tecnologias diferentes, uma vez que os serviços podem ser expandidos e integrados conforme a necessidade.

22 22 O desenvolvimento de aplicações baseadas em SOC (Service Oriented Computing) permite a integração de serviços disponibilizados por provedores distribuídos em todo o mundo. Logo, as aplicações podem ser projetadas baseadas em processos de negócios, que representam as etapas para solucionar o problema computacional. Durante a execução de um processo de negócio, é possível integrar diversos e diferentes sistemas, disponíveis em diferentes provedores, e as etapas do processo podem ser providas por provedores internos ou externos (SANTANA et al., 2009). A evolução do ambiente corporativo exigiu ao longo do tempo também uma evolução dos paradigmas arquiteturais existentes. Necessidades como flexibilidade e agilidade no atendimento de requisitos de negócio e facilidade na integração de diferentes aplicações e sistemas de maneira financeiramente viavel para o negócio refletiram nos paradigmas arquiteturais, que por sua vez, evoluiram para adaptar-se às necessidades do cenario teconológico atual. A figura 1 demonstra esta evolução ocorrida na linha do tempo, partindo do paradigma de arquitetura monolítico, no qual toda a aplicação era desenvolvida em um único bloco, contendo base de dados, interface do usuário, lógica de negócios, etc; evoluindo para outros modelos como cliente servidor; 3 camadas, nas quais há separação entre as camadas de dados, lógica de negócios e interface com os usuários; até chegar a uma arquitetura baseada em serviços, tida como mais evoluida comparada as anteriores, uma vez que atende requisitos como facilidade de reuso, integração, manutenção, dentre outros. Monolítico Estruturado Cliente Servidor 3 Camadas N Camadas Serviços Figura 1: Evolução dos paradigmas de arquitetura 2.2 Arquitetura Orientada a Serviços (SOA) SOA (Service Oriented Architecture) é um paradigma de arquitetura relacionado ao conceito de computação orientada a serviços (HUHNS; SINGH, 2005), que tem sido amplamente adotado em projetos de desenvolvimento de softwares com o objetivo de tornálos reutilizáveis e com alta capacidade de integração (MACKENZIE et al., 2006).

23 23 Em uma arquitetura SOA, os componentes de software são denominados serviços e são providos geralmente em repositórios centrais, onde podem ser consultados e consumidos (STAL, 2002). SOA geralmente faz uso de web services para disponibilização e utilização de serviços. Neste padrão de arquitetura, um web service é um serviço que pode ser identificado e acessado através de uma URI (Uniform Resource Indentifier) específica na web. A iteração entre web services geralmente utiliza as tecnologias SOAP (Simple Object Access Protocol), XML (extensible Markup Language) e WSDL (Web Services Description Language), que é responsável pela descrição do serviço (PAPAZOGLOU, 2007). Os serviços providos através de web services, bem como suas respectivas descrições, podem ser armazenados nos repositórios conhecidos como UDDI, onde podem ser consultados e consequentemente consumidos. A Figura 2 exemplifica o fluxo dos conceitos de uma arquitetura baseada em serviços, onde podemos visualizar um provedor de serviços, que registra seus serviços em um repositório central. As aplicações consumidoras de serviços podem então consultar estes repositórios para descobrir serviços disponíveis e informações de como se conectar a um provedor de serviços específico. Uma vez determinado o provedor, a aplicação consumidora pode então obter a descrição do serviço que especifica como o serviço pode ser utilizado. Repositório de Serviços Consumidores de Serviços Provedores de Serviços Figura 2: Fluxo de uma arquitetura SOA Aplicações SOA compostas por componentes de serviço associam interfaces de serviços e lógica de negócios em um modelo conceitual único, tornando possível a extensão, especialização e criação de novas aplicações (PAPAZOGLOU, 2007). Conforme explanado anteriormente, tecnologias orientadas a serviços propiciam diversos benefícios aos cenários tecnológicos atuais das organizações. Como algumas destas

24 24 vantagens é possível citar: Encapsulamento SOA provê uma camada de abstração que possibilita ao negócio encapsular seus sistemas legado através de serviços, que permite continuar a utilização destes recursos sem a necessidade de reconstruí-los do zero. Isolamento da complexidade do desenvolvimento Em uma arquitetura baseada em serviços, a integração e interface para o desenvolvimento é baseado em torno da especificação do serviço. Isto provê transparência no desenvolvimento do serviço e minimiza impactos em casos de alterações de infraestrutura e implementações, ou seja, disponibilizando às demais camadas envolvidas no sistema uma interface de comunicação definida através da especificação dos serviços, é possível isolar a parte complexa do desenvolvimento. Agilidade de desenvolvimento A capacidade de aproveitamento de componentes e serviços reduz o tempo de desenvolvimento existente no ciclo de vida de novas aplicações, permitindo ao negócio um menor tempo entre a análise de um produto e sua disponibilização no mercado. Redução de custos e aumento de reuso A flexibilidade proporcionada pelo desenvolvimento orientado a serviços resulta em menor duplicação de recursos, maior potencial de reuso e consequentemente uma maior redução de custos. Entretanto, arquitetura orientada a serviços não é uma bala de prata para todos os problemas existentes no desenvolvimento de softwares. Além disto, a migração para SOA não é uma tarefa fácil, sendo recomendada uma abordagem de migração ou adoção em etapas. Aplicações SOA compostas por componentes de serviço associam interfaces de serviços e lógica de negócios em um modelo conceitual único, tornando possível a extensão, especialização e criação de novas aplicações (PAPAZOGLOU, 2007). Uma abordagem prática para SOA é apresentada por (ENDREI et al. 2004), através de um método composto por sete etapas que descrevem as principais atividades necessárias para a implementação de uma solução baseada em SOA. A Figura 3, extraída de Endrei et al. (2004), ilustra estas etapas. A primeira etapa é responsável pela decomposição do problema através de áreas funcionais, as quais são decompostas em processos e subprocessos de negócios para

25 25 identificação de casos de uso que são potencias candidatos a serviços. A próxima etapa (que está diretamente ligada a primeira e por isto identificada como etapa 1b na figura) é responsável pelo mapeamento e interação com os sistemas legados. Na segunda etapa, deve ser feita a construção do modelo de serviços. A etapa três corresponde à analise dos subsistemas, onde deve ser feito o refinamento dos casos de uso, analisando o fluxo do processo de todos os subsistemas com o intuito de identificar potenciais candidatos a componentes de negócio e suas funcionalidades. A quarta etapa é onde deve ser feita a alocação dos serviços, definindo em que componente o serviço será implementado. Na etapa cinco, deve ser elaborada a especificação dos componentes que estão no escopo do projeto, bem como seus serviços, regras, atributos e dependências. Na sexta etapa, os componentes especificados até o momento devem ser estruturados através da adoção de padrões arquiteturais. Na etapa sete deve ser executado o mapeamento tecnológico, onde são definidas as estratégias para implementação dos componentes e serviços.

26 26 1A Identificação do Domínio 3 Análise dos Sub Sistemas Modelo de Serviços 2 Componentes dos Sistemas Legados 1B 4 Alocação dos Serviços 5 Especificação dos Componentes Estruturação baseada nos padrões arquiteturais 6 Repositório de Componentes de Serviços 7 Mapeamento Tecnológico Repositório de Serviços Figura 3: Etapas para aplicação de SOA Uma arquitetura SOA facilita a gestão de sistemas corporativos, melhorando a escalabilidade e reduzindo custos através da colaboração e reuso de soluções (MACKENZIE et al., 2006). 2.3 ESB (Enterprise Service Bus) O cenário tecnológico atual da maioria das organizações é composto por centenas de aplicações, as quais muitas vezes são constituídas por diferentes tecnologias. Entretanto, para atender as necessidades de negócio destas organizações, deveria ser possível que suas aplicações operassem de maneira integrada. A implementação de uma solução baseada em SOA para estes cenários requer uma estrutura para gerenciar serviços (CHAPPELL, 2004;

27 27 MENGE, 2007), conhecida como Barramento Empresarial de Serviços ou Enterprise Service Bus, ESB. Conforme ilustrado na Figura 4, um barramento de serviços funciona como um middleware que conecta e intermedia todas as comunicações entre consumidores e provedores de serviços, servidores de banco de dados, servidores de aplicações, sistemas legados, servidores de e sistemas cliente, entre outros. Figura 4: Entreprise Service Bus Existem diferentes definições formais para o conceito de ESB na literatura. Segundo (MENGE, 2007), ESB é um padrão de infraestrutura de integração distribuído e baseado em mensagens, ou seja, utiliza-se o conceito conhecido como MOM (Message-Oriented Middleware) para gerenciar as aplicações conectadas a ele através de mensagens assíncronas. ESBs são normalmente constituídos por estruturas conhecidas como containers de serviços distribuídos através de um ambiente de rede. Conforme podemos visualizar na Figura 5, adaptada de Menge (2007), containers são disponibilizados no barramento de mensagens armazenando componentes de integração como roteadores, transmissores, adaptadores de aplicações, entre outros mecanismos de comunicação. As aplicações são conectadas ao barramento através de adaptadores ou outros mecanismos que implementem o conceito de mensagens como MOM.

28 28 Barramento de Menssagens Container Adaptador de Aplicação Aplicação Figura 5: Estrutura interna de um ESB Um ESB deve possuir características e funcionalidades específicas, como manipulação de requisições, roteamento, mediação entre aplicações e serviços, adaptadores para aplicações de diferentes tecnologias, mecanismos de segurança, ferramentas para gestão da infraestrutura de integração, orquestração de processos, manipulador de eventos gerados pelos sistemas envolvidos e, em alguns casos, um ambiente de desenvolvimento e testes (MENGE, 2007). Existem diversas soluções de ESB disponíveis no mercado. Algumas delas são desenvolvidas e mantidas por organizações privadas, enquanto outras são soluções de software livre. O Mule ESB é um ESB de código aberto muito utilizado para integração de aplicações de software baseadas em serviço. Ele utiliza o conceito de container de serviços, além de possuir uma grande variedade de mecanismos de comunicação suportados, como SOAP, REST, HTTP, FTP, TCP, UDP, SMTP, POP3 e JDBC, entre outros (MULESOFT, 2014). O conceito de integração baseado em containers é altamente modular no Mule ESB (MULESOFT, 2014), o que permite que implementações com a sua estrutura consistam basicamente de múltiplas instancias de componentes do barramento, as quais são distribuídas através de uma rede e interconectadas através de algum dos mecanismos de comunicação suportados pela ferramenta. O Mule ESB provê todos os serviços de integração que são essenciais a um ESB, incluindo a orquestração de serviços a partir de processos de negócio descritos em WS-BPEL

29 29 (Web Services Business Process Execution Language). Um exemplo de componentes envolvidos no fluxo executado pela arquitetura do Mule ESB durante o envio de uma mensagem entre duas aplicações pode ser visualizado na Figura 6. A figura apresenta a sequencia padrão de estruturas pelas quais transitam as mensagens entre duas aplicações como transportadores de mensagem, roteadores, componentes de manipulação, dentre outros. A mensagem é trafegada e roteada através do barramento e, após ser manipulada e transformada por um componente, é enviada ao roteador de saída que também pode executar operações de manipulação e transformação antes de entregar a mensagem à aplicação destino (MENGE, 2007) (MULESOFT). A transformação realizada pelo componente pode ser, por exemplo, a execução das regras de negócio sobre a mensagem recebida. Transportador Roteador de Entrada Componente Roteador de Saída Transportador Figura 6: Fluxo de integração através do ESB O Mule ESB é um ESB de código aberto e baseado em Java, que permite aos desenvolvedores conectar aplicações de diferentes tecnologias de maneira eficiente. Por essas características e por atender a todos os requisitos necessários para um ESB padrão de mercado em termos arquiteturais e práticos, o Mule ESB foi escolhido para o desenvolvimento do estudo de caso que será apresentado nesse trabalho. 2.4 Trabalhos Relacionados De acordo com O Reilly (2005), a Web 2.0 deve promover o uso da web como uma plataforma onde os serviços substituem os tradicionais pacotes de software com maior eficiência em termos de escalabilidade e custo. Já a Web 3.0 (HENDLER, 2009) deve incorporar conceitos de web semântica, principalmente com base no uso de RDF (Resource Description Framework) e de OWL (Web Ontology Language) (BERNERS-LEE et al.,

30 ). Nesse cenário, onde existe a possibilidade de existir diversos serviços para prover a mesma funcionalidade com atributos de qualidade similares, a seleção dinâmica de serviços merece destaque e o assunto que tem sido estudado mesmo antes de surgirem as propostas concretas para a Web 2.0 e 3.0. Dentre os principais trabalhos que tratam da seleção dinâmica de serviços, merecem destaque: 1. (SHAIKHALI et al., 2003) propõe em seu trabalho uma alteração dos UDDIs atuais de maneira a incorporar neles funcionalidades que possibilitam especificar o período de tempo que a descrição de um serviço deve permanecer no repositório. Incluir no repositório áreas privadas para armazenar descrições de partes ou métodos dos serviços que por segurança ou outros motivos e necessidades não devem ser disponibilizados na mesma área onde estão publicadas as demais informações dos serviços. Adicionalmente na configuração dos UDDIs são implementadas propriedades para descrever e armazenar informações como variáveis de qualidade de serviços (QoS), dentre outras. Estes UDDIs modificados proveriam também uma interface com métodos que possibilitariam executar ações no repositório como armazenar serviços, localizar serviços, obter detalhes do serviço, definir o período em que o serviço deve ficar disponível no repositório dentre outros. A seleção de serviços é pré-processada por uma estrutura chamada pelo autor de QoS Broker fora do UDDI através de algoritmos baseados em média. 2. A ideia central do trabalho apresentado por (SOYDAN BILGIN; SINGH, 2004) é prover uma nova linguagem chamada SWSQL (Semantic Web services Query and Manipulation Language) utilizada pelos provedores e consumidores de serviços para efetuar inserções, modificações e consultas de variáveis de qualidade e descrição de serviços. A SWSQL é baseada em ontologias e no conceito de modelo de dados relacional. Neste contexto, os serviços são identificados nos repositórios através de um identificador e os valores de suas variáveis de qualidade identificados através de uma tabela relacional contendo tuplas formadas por este identificador e pelas ontologias, onde são armazenadas as informações das variáveis de serviços.

31 31 A Figura 7 demonstra um exemplo de consulta utilizando alguns elementos da sintaxe da linguagem SWSQL. Nela procura-se o identificador do serviço (servicekey) dentre todos os serviços deste domínio com a variável rangeofcars com valor igual a média (Averange). Conforme é possível notar na sintaxe, as variáveis utilizadas para efetuar a consulta e que consequentemente armazenam as informações dos serviços são especificadas através de elementos da linguagem DAML (DARPA Agent Markup Language), que é precursora do OWL e, portanto, também consideram que o repositório de serviços foi construído com base em ontologias e conceitos de qualidade de serviços para a construção do algoritmo. Figura 7: Exemplo de consulta utilizando linguagem SWSQL 3. (CAVERLEE et al., 2004) baseia seu trabalho em três passos: analise de tendências para possíveis origens da localização de serviços; analise e classificação do conjunto de serviços obtidos no passo anterior; aproveitamento dos resultados para obter relacionamentos relevantes. No primeiro passo, a partir de técnicas probabilísticas aplicadas sobre uma base sumarizadas de informações sobre serviços disponíveis, obtém-se uma série de prováveis serviços tidos como aptos para a utilização. Uma vez definido um conjunto de prováveis serviços, utiliza-se um mecanismo, também baseado em probabilidade e tendências, para definir uma classificação entre os elementos

32 32 deste conjunto. A terceira e última etapa do processo adotado neste trabalho utiliza conceitos de mineração e classificação de dados para inferir relacionamentos entre serviços similares gerando com isto, informações de similaridade e relacionamento para serem utilizados como base para futuras pesquisas. 4. (YU; REIFF-MARGANIEC, 2008) apresenta em seu trabalho uma série de propriedades presentes nos serviços, tidas como não funcionais, e discute como as abordagens atuais de descrição e seleção de serviços utilizam estas propriedades. Segundo ele, diversas abordagens apresentam propostas viáveis para efetuar a seleção de serviços baseada nestes atributos, entretanto, todas requerem premissas como extensões dos repositórios existentes ou algoritmos de seleção baseados em web semântica. Contudo, conclui em seu trabalho que todas as abordagens utilizadas baseiam-se em semânticas através de ontologias. 5. (SHIREESHA, 2013) propõe uma alteração no repositório (UDDI) para que o mesmo exerça a função de unidade central na seleção de serviços. Este repositório possui internamente as funções de processamento, coleta e armazenamento de informações sobre os serviços nele descritos. O repositório é suprido de feedbacks emitidos pelos atuais consumidores dos serviços com suas respectivas variáveis de qualidade (QoS), que por sua vez são utilizados na etapa de processamento. Nesta etapa, é aplicado o seguinte algoritmo para determinar o serviço a ser selecionado: a) Executar a pesquisa a partir da descrição do serviço; b) Organizar todos os serviços obtidos da pesquisa realizada por suas assinaturas e parâmetros; c) Obter os parâmetros de serviço desejados; d) Agrupar o resultado e ordená-lo baseado na relevância dos itens obtidos; e) Se não obtiver um resultado relevante, permitir à aplicação cliente reavaliar as restrições. Voltar ao passo b; 6. A definição de novos conjuntos de metadados para a descrição dos serviços (SCHMIDT et al., 2005), considerando as novas informações nos filtros de seleção já aplicados para a seleção de serviços;

33 33 7. Os algoritmos para a descoberta e seleção de serviços usando ontologias (TOMA et al., 2007; PATHAK et al., 2005) e algoritmos combinando ontologias com teoria dos grafos (LIN et al., 2004), baseados em uma solução proprietária que utiliza um repositório de serviços baseado em ontologias; 8. Os algoritmos baseados em tecnologia adaptativa (FENG et al., 2007; SANTANA et al., 2009b); 9. Os algoritmos baseados em qualidade de serviço (YANG et al., 2005), como disponibilidade e tempo de resposta; 10. Os algoritmos que consideram a análise probabilística de dados históricos (CASATI et al., 2004); 11. Os algoritmos baseados em inteligência artificial, como redes neurais e técnicas de aprendizado (MATAI; HAN, 2007). É importante notar que todas essas soluções trabalham com atributos de serviços que normalmente não estão disponíveis nos web services ou outros serviços utilizados pelas empresas de mercado. Portanto, a sua adoção depende também da aceitação dessas propostas e da adoção desses novos padrões pela comunidade, já que a interoperabilidade é fundamental para a Web 3.0.

34 34 3 Proposta Arquitetural para o Barramento de Serviços Neste capítulo, são apresentadas a descrição do algoritmo de seleção de serviços utilizado neste trabalho e uma proposta arquitetural para a orquestração dinâmica de serviços dentro do ESB. 3.1 Algoritmo para Seleção de Serviços Para o estudo de caso apresentado nesse trabalho, foi escolhido o algoritmo para seleção de serviços proposto em Santana et al. (2009b). Este algoritmo foi escolhido porque ele permite o uso dos atributos de QoS para a seleção dos serviços, o que é necessário para a implementação da solução proposta, apresentada na seção 3.2. O algoritmo se baseia em uma estrutura de tabela de decisão adaptativa para o ranqueamento e a seleção dos serviços. Uma possível tabela para a solução deste tipo de problema é ilustrada na Tabela 1, onde consta uma tabela com as linhas c1, c2,, cn para representar as condições, as linhas a1, a2,, am para representar as ações, e as linhas ba1, ba2,, bak para representar as funções adaptativas, que definem as ações a serem tomadas de maneira adaptativa pelo algoritmo durante a sua execução (NETO, 2001). Na implementação da tabela de decisão adaptativa para esse trabalho, as linhas de condições foram definidas como os valores para as variáveis que definem a qualidade dos serviços, como segurança, tempo de resposta e disponibilidade, entre outros. As linhas com as funções adaptativas são responsáveis por aplicar as regras de atualização nas variáveis de condição, por exemplo diminuindo ou aumentando os valores das variáveis. As linhas de ações são responsáveis por executar as regras definidas de acordo com as condições avaliadas a cada momento.

35 35 Condição Ação Função C1 C2... Cn A1 A2... An Ba1 Ba2... Ban Tabela de Decisão Adaptativa n Tabela 1: Tabela de decisão adaptativa O algoritmo utilizado neste trabalho baseia-se na estrutura de tabela de decisão adaptativa para efetuar a seleção dinâmica de serviços. A Tabela 2 apresenta um pseudocódigo deste algoritmo, através do qual é possível melhor compreender seu funcionamento. Implementado internamente ao barramento de serviços, este algoritmo funciona aguardando por requisições que exijam sua orquestração. Uma vez recebida uma requisição, o algoritmo verifica a base de serviços disponíveis para executar a tarefa requisitada e seleciona o serviço melhor ranqueado dentre os disponíveis. Este ranqueamento é definido de acordo com variáveis de qualidade inerentes aos serviços, por exemplo, tempo de resposta, indisponibilidade, segurança, etc. Identificado o serviço a ser utilizado, o barramento efetua sua chamada e valida seu retorno. Neste ponto do algoritmo, inicia-se o conceito da tabela de decisão adaptativa discutida neste trabalho, onde, na validação do retorno é verificada a ocorrência ou não de alguma condição, definidas na tabela de decisão pelas linhas de condições. Uma vez identificada a ocorrência de uma das condições pré-estabelecidas, o algoritmo executa a ação diretamente relacionada a esta condição (definida na tabela de decisão através das linhas de ação). Seguido desta ação, o algoritmo aplica na base de serviços disponíveis uma função de adaptação (definida na tabela de decisão pelas das linhas de funções adaptativas), a fim de atualizar as variáveis relacionadas a este serviço e consequentemente reclassificar o ranqueamento de serviços existente, para que as próximas requisições possam

36 36 ser executadas sobre o ambiente atualizado. Algoritmo: Tabela de Decisão Adaptativa Inicio Enquanto Houver Requisição { Receber Requisição; Verificar Serviço Melhor Ranqueado; Executar Chamada do Serviço; Validar Retorno { Caso Condição 01; Executar Ação 01; Aplicar Função Adaptativa 01; Caso Condição 02; Executar Ação 02; Aplicar Função Adaptativa 02; Caso Condição N; Executar Ação N; Aplicar Função Adaptativa N; } Retornar Dados do Serviço; } Fim Tabela 2: Algoritmo de seleção dinâmica Um exemplo de funcionamento, onde é possível visualizar a fusão entre o algoritmo de seleção e a estrutura da tabela de decisão adaptativa é demonstrado a partir da Tabela 3 e Tabela 4. A Tabela 3 contém um exemplo de base com quatro serviços disponíveis para executar uma determinada tarefa. Baseado nas variáveis de qualidade tempo de resposta e indisponibilidade é definida a classificação destes serviços, no qual o serviço com ID 02 é o melhor ranqueado. Id do Serviço Tempo de Resposta Flag de Indisponibilidade S N N S Posição Tabela 3: Exemplo de variáveis de qualidade de serviços

37 37 A Tabela 4 foi preenchida com alguns exemplos de cenários possíveis numa aplicação da tabela de decisão adaptativa. Durante uma simulação de execução do ambiente neste cenário, ao receber uma requisição para executar esta funcionalidade, o barramento consultaria a base ilustrada na Tabela 3 onde estaria definido o serviço com id 2 como melhor ranqueado. O ESB por sua vez efetua a chamada deste serviço e analisa o retorno. Caso, por exemplo, nesta validação seja identificada a condição 02 definida na tabela de decisão ilustrada na Tabela 4, o algoritmo de seleção dinâmica executaria a ação 02 que, conforme definido neste exemplo, utilizaria o retorno do serviço. Paralelamente a esta ação, o algoritmo aplicaria uma função adaptativa que atualizaria a variável tempo de resposta referente a este serviço na base ilustrada na Tabela 3 com o novo valor constatado. Uma vez atualizado o valor desta variável a classificação dos serviços automaticamente sofre uma reordenação, pois conforme mencionado, este ranqueamento é baseado no valor das variáveis de qualidade dos serviços. Após a reclassificação, o serviço com id 02 não seria mais o primeiro, posição esta que seria ocupada agora pelo serviço com id 03, ou seja, numa próxima requisição será este o serviço definido para executar a funcionalidade solicitada. Serviço 01 Serviço 02 Serviço 03 Serviço 04 Condição 01 Serviço Serviço Serviço Indisponível Serviço Indisponível Indisponível Indisponível Condição 02 Tempo de Tempo de Tempo de Resposta Tempo de Resposta Resposta >5000 Resposta >5000 >5000 >5000 Ação 01 Executar Serviço Executar Serviço Executar Serviço Executar Serviço Posição 2 Posição 2 Posição 2 Posição 2 Ação 02 Utilizar Retorno Utilizar Retorno Utilizar Retorno Utilizar Retorno Função 01 Atualizar flag Atualizar flag Atualizar flag Atualizar flag Indisponibilidade Indisponibilidade Indisponibilidade Indisponibilidade Função 02 Atualizar Tempo Atualizar Tempo Atualizar Tempo Atualizar Tempo Resposta Resposta Resposta Resposta Tabela 4: Exemplo de tabela de decisão adaptativa preenchida 3.2 Proposta Arquitetural de Alteração do ESB Este trabalho apresenta uma proposta arquitetural para alterar o barramento de serviços. Originalmente, todo ESB contém um service engine, que é o elemento arquitetural responsável pela mediação dos serviços. O service engine, por exemplo, pode acessar um

38 38 UDDI para obter informações sobre determinado serviço antes que ele possa ser invocado. Para viabilizar a orquestração dinâmica de serviços baseados em QoS e outros critérios de seleção dinâmica, por exemplo a partir dos diversos métodos propostos e apresentados em 3.4, deve-se permitir a incorporação de algoritmos para ranqueamento e seleção de serviços aos ESBs. Uma solução para esse problema é alterar o service engine, incorporando a ele novos elementos arquiteturais que permitam que ele passe a ser inteligente, ou seja, que ele possa executar algoritmos inteligentes. Nessa solução, o service engine passaria a ser composto por um localizador de serviços (Service Searcher), uma base de dados com informações sobre os serviços (Services Repository) e uma estrutura responsável pela seleção efetiva dos serviços (Solution Manager), onde os algoritmos poderiam ser disponibilizados. A proposta está ilustrada na Figura 8, construída a partir da proposta original apresentada em Santana (2009a). O Service Searcher deve fazer a busca pelos serviços nos diferentes repositórios: UDDIs, repositórios semânticos (Semantic Services Repository, proposta da Web 3.0) e outros possíveis repositórios que venham a surgir (Other types of repositories for services). Informações sobre os serviços devem ser armazenadas no Services Repository. O armazenamento deve ser feito usando metadados, o que exige a criação de um esquema XML (XML-Schema), de forma que o acesso ao repositório obedeça a padrões de dados específicos. Isso é importante para que o Solution Manager trabalhe adequadamente, para prover a interoperabilidade e para o eventual compartilhamento de informações entre ESBs no futuro, caso uma solução distribuída se mostre mais viável para a seleção de serviços. O Solution Manager deve implementar os algoritmos para o ranqueamento e seleção dinâmica de serviços. Idealmente, os algoritmos devem ser implementados na forma de plug-ins. Assim, o responsável pela gestão da infraestrutura pode definir o algoritmo ou a solução mais adequada, dentre as oferecidas pelo ESB, para a sua aplicação.

39 39 Figura 8: Proposta de solução arquitetural Vale notar que a definição de um XML-Schema para o Mule ESB não faz parte do escopo desse trabalho. Porém, alguns metadados foram definidos para viabilizar o desenvolvimento do estudo de caso apresentado no Capítulo 4. O encadeamento de serviços também não é abrangido na analise feita neste trabalho, embora seja possível aplicar os conceitos propostos aqui num cenário que utiliza composição de serviços para executar uma determinada funcionalidade.

40 40 4 Estudo de Caso: Implementação da Solução Proposta aplicando Algoritmo Baseado em Tabelas de Decisão Adaptativas Neste capítulo é apresentado o estudo de caso onde foram implementadas a solução arquitetural proposta alterando o Mule ESB e a aplicação cliente, que foi construída para testar a nova solução. 4.1 Implementação da Solução Proposta A implementação da solução proposta neste trabalho baseia-se no desenvolvimento de componentes e configurações no barramento de serviços Mule ESB, a fim de permitir que a aplicação obtenha autonomia para efetuar uma seleção dinâmica dos serviços em tempo de execução. Conforme descrito anteriormente, em um contexto orientado a serviços o ESB é o componente que intermedia duas ou mais aplicações e/ou serviços aguardando por requisições que exijam sua ação. Ao receber uma requisição, por exemplo, envolvendo orquestração de serviços, tem a responsabilidade de executar os seguintes processos: 1. Manipular o conteúdo recebido; 2. Selecionar dinamicamente o web service disponível; 3. Encaminhar o conteúdo para o web service selecionado; 4. Receber o resultado do processamento executado pelo web service; 5. Manipular o conteúdo recebido e devolvê-lo à aplicação.

41 41 A Figura 9 ilustra os três fluxos implementados no barramento e que executam a orquestração dinâmica de serviços. O código fonte desta implementação efetuada no Mule pode ser consultada no Apêndice A, ao final deste trabalho. O fluxo ConsultaArquivoXML é responsável por obter as informações dos serviços disponíveis, armazenadas em um arquivo XML. O fluxo AtualizarArquivoXML é responsável por atualizar estas informações no arquivo XML. O fluxo Principal contém os componentes responsáveis pela orquestração e seleção dos serviços, bem como as manipulações necessárias durante o roteamento dos dados através do barramento. Figura 9: Desenvolvimento do ESB

42 42 A seguir, são detalhados separadamente os principais componentes presentes nos fluxos desta aplicação. O primeiro ícone ilustrado no fluxo Principal da Figura 8 é um HTTP EndPoint. Trata-se do componente responsável por ficar aguardando em uma entrada específica do ESB à espera de requisições que sejam para lá direcionadas. Ao receber uma requisição, este componente tem a função de capturar o conteúdo recebido, executar as manipulações necessárias nos dados de maneira a deixá-los em um formato compreendido pelos demais componentes do barramento, e encaminhá-lo para o próximo componente. Este componente tem a função de encapsular os dados recebidos em um formato SOAP para que seja possível encaminhá-lo como entrada para ser processado pelo web service. Este componente, ilustrado nos fluxos ConsultaArquivoXML e AtualizaArquivoXML, tem a função de inserir no barramento o diretório contendo um arquivo de configuração onde são armazenadas algumas informações sobre os serviços disponíveis para a funcionalidade requerida. Neste exemplo, utilizamos um arquivo do tipo XML com a estrutura ilustrada na Figura 10. Nele, são inseridas as informações que representam as variáveis de qualidade dos web services. Para facilitar a ilustração e demonstração, neste exemplo foram utilizados os atributos de QoS tempo de resposta e disponibilidade.

43 43 Figura 10: Arquivo com metadados dos serviços disponíveis Este arquivo é o que constitui a base de metadados apresentada na proposta de alteração da arquitetura do barramento de serviços deste trabalho. Este componente tem a função de mapear em tempo de execução os dados do arquivo XML obtido no componente anterior para um objeto Java, onde será possível manipular os dados em memória e em tempo de execução. Presente nos fluxos ConsultaArquivoXML e AtualizaArquivoXML, este componente representa um objeto Java (POJO - Plain Old Java Object), onde são mapeados e armazenados os dados obtidos do arquivo XML com as variáveis de qualidade dos web services, tornando possível efetuar operações de ordenação e seleção sobre eles. Este componente tem a função de armazenar em uma variável de sessão, o ID do serviço, que está na primeira posição do ranking presente no arquivo XML.

44 44 Presente duas vezes no fluxo Principal. Sua primeira utilização no fluxo tem a função de rotear a mensagem entre os web services disponíveis. Para isto ele utiliza o ID do serviço armazenado na variável de sessão para definir qual web service utilizar. Este componente tem a função de encaminhar a entrada encapsulada no componente SOAP para o web service. Dado que pode existir mais de um web service disponível e que pode ser utilizado, existirá um componente HTTP para cada opção de web service. Neste exemplo, foram definidos três web services, logo, três componentes. Presente pela segunda vez no fluxo Principal, este componente tem a função de decidir, a partir do retorno do serviço, quais são as ações que o barramento deve tomar. Neste exemplo, existem três possíveis ações a serem tomadas, baseadas nas seguintes condições: 1. O web service retornou os dados corretamente e com tempo de resposta dentro do esperado; 2. O web service retornou os dados corretamente, mas com tempo de resposta superior ao esperado; 3. O web service não retornou os dados, ou seja, considera-se que houve indisponibilidade do serviço; Cada uma das condições acima leva o barramento de serviços a seguir um determinado fluxo e executar uma sequência de ações no tráfego da mensagem. Além das ações, cada condição dispara também no barramento a execução de funções adaptativas, de maneira a atualizar dinamicamente as próximas ações a serem tomadas no caso de uma recorrência da condição encontrada. A descrição dos próximos componentes contempla as ações e funções adaptativas aplicadas em cada uma das condições descritas acima.

45 45 Este componente é executado caso a decisão seja seguir o fluxo atual e devolver o retorno do serviço para que a aplicação possa apresentar o resultado ao usuário. Este componente está presente três vezes no fluxo Principal. Ele funciona apenas como um direcionador para outros fluxos do barramento. Neste exemplo, ele executa os sub fluxos ConsultaArquivoXML e AtualizaArquivoXML. 4.2 Execução e Testes da Solução Para testar a proposta de solução para a seleção dinâmica de serviços apresentada e desenvolvida neste trabalho, foram desenvolvidos uma série de web services armazenados localmente. Para o desenvolvimento destes serviços, foram utilizados os mecanismos para construção de web services presentes no ambiente de desenvolvimento da ferramenta NetBeans. Cabe salientar que esta proposta de solução aplica-se a qualquer tipo de web service existente dentro dos padrões estabelecidos pela W3C. A utilização de web services próprios neste trabalho tem unicamente o intuito de tornar mais fácil a validação e homologação dos resultados, uma vez que deste modo é possível termos uma quantidade maior de diferentes web services que executam uma mesma funcionalidade, o que não seria tão facilmente possível caso utilizássemos web services externos. Além disto, o ambiente controlado e o armazenamento local dos web services permite a simulação de casos de teste como indisponibilidade dos serviços e tempos de resposta e um maior controle sobre as variáveis envolvidas, a fim de aumentar a relação causa-efeito e a acurácia dos testes. Dado que o intuito deste estudo de caso é avaliar a implementação da proposta de solução apresentada, a funcionalidade dos web services desenvolvidos para os testes restringem-se a simplesmente receber um valor de entrada e devolvê-lo à aplicação com a uma informação que identifique o web service que processou os dados recebidos. A Figura 11 ilustra o trecho de código de um dos web services que executa este processamento e a Figura

46 46 12 ilustra a estrutura com os três web services desenvolvidos e utilizados para os testes. Figura 11: Web Services utilizados Figura 12: Trecho de código executado pelos Web Services Aplicação cliente é a aplicação que irá utilizar os recursos arquiteturais do barramento de serviços para executar uma determinada tarefa. Neste trabalho, foi adotada uma aplicação web hipotética que utiliza funcionalidades de um web service para executar uma determinada tarefa. Neste caso de uso, como aplicação utilizou-se uma página web, ilustrada na Figura 13, composta simplesmente por um campo onde o usuário pode digitar um texto e um botão responsável por capturar e encaminhar o conteúdo digitado pelo usuário para ser processado pelo web service. O desenvolvimento desta página consiste basicamente de código HTML (HyperText Markup Language) simples, efetuado no ambiente de desenvolvimento da ferramenta NetBeans [https://netbeans.org/] e armazenado localmente. Internamente a esta página, existe um formulário, ou seja, um form em linguagem HTML, que envia o conteúdo do campo de

47 47 texto para um endereço especifico, que neste exemplo é um diretório local. Figura 13: Aplicação cliente A validação da solução proposta e desenvolvida neste trabalho foi estruturada em três testes: 1) Teste de sucesso, onde o web service executa sua tarefa e retorna para a aplicação conforme esperado; 2) Um teste onde o web service executa sua tarefa e retorna para a aplicação, entretanto com tempo de resposta superior ao esperado; e 3) Um teste de falha, onde o web service não retorna para a aplicação, simulando indisponibilidade do serviço Teste de Sucesso Neste teste, o usuário insere um texto no campo de entrada e clica no botão Enviar, conforme Figura 14.

48 48 Figura 14: Aplicação cliente A aplicação, por sua vez, encaminha o texto digitado pelo usuário para a entrada do barramento de serviços onde um componente do Mule ESB está configurado aguardando por requisições. O Mule ESB, por sua vez, executa as manipulações necessárias nos dados de entrada recebidos conforme especificado na implementação da solução deste trabalho. Neste momento do teste existem três serviços disponíveis e cadastrados no barramento para executar esta funcionalidade. A Figura 15 apresenta o arquivo XML que representa os metadados dos serviços cadastrados no momento do teste. Por ela, é possível notar que o serviço com ID 01 é o primeiro serviço na classificação estabelecida entre os três existentes. Esta posição do serviço foi obtida com base nas suas variáveis de QoS tempo de resposta e indisponibilidade (falha), que são melhores do que as dos demais serviços.

49 49 Figura 15: Classificação e status dos serviços disponíveis Conforme implementado, o Mule ESB verifica este arquivo e chama o serviço correspondente ao ID 01 do arquivo, encaminhando os dados de entrada recebidos da aplicação. O serviço executa o processamento dos dados recebidos e devolve ao Mule ESB. O Mule ESB verifica a ocorrência ou não de falha e o tempo de resposta, que neste exemplo está dentro do esperado. A partir dessa condição, o Mule ESB executa as manipulações especificadas na solução e devolve o conteúdo retornado pelo serviço para a aplicação, que por sua vez apresenta o resultado ao usuário conforme Figura 16. Figura 16: Resultado na aplicação cliente

50 Teste de Tempo de Resposta Neste teste o usuário insere um texto no campo de entrada e clica no botão Enviar, conforme Figura 17. Figura 17: Aplicação cliente A aplicação, por sua vez, encaminha o texto digitado pelo usuário para a entrada do barramento de serviços onde um componente do Mule ESB está configurado aguardando por requisições. O Mule ESB, por sua vez, executa as manipulações necessárias nos dados de entrada recebidos conforme especificado na implementação da solução deste trabalho. Neste momento do teste, existem três serviços disponíveis e cadastrados no barramento para executar esta funcionalidade, como no teste anterior. A Figura 18 apresenta o arquivo XML que representa os metadados dos serviços cadastrados no momento do teste. O serviço com ID 01 é o primeiro serviço na classificação estabelecida entre os três existentes, considerando os atributos de QoS tempo de resposta e indisponibilidade (falha).

51 51 Figura 18: Classificação e status dos serviços disponíveis Conforme implementado, o Mule ESB verifica este arquivo e chama o serviço correspondente ao ID 01 do arquivo, encaminhando os dados de entrada recebidos da aplicação. O serviço executa o processamento dos dados recebidos e devolve ao ESB. Entretanto, no intuito de efetuar um teste de tempo de resposta maior do que esperado, inseriu-se no processamento deste serviço um comando Sleep para que o retorno ocorra somente após 8000 milissegundos, ou seja, um tempo maior do que os 3000 milissegundos considerados como tempo aceitável para uma boa performance da aplicação. Por sua vez, o ESB verifica a ocorrência ou não de falha e o tempo de resposta, que neste exemplo está acima do esperado. Dado esta condição, o ESB atualiza o arquivo de metadados dos serviços, alterando a variável tempo do serviço de ID 01 com o valor do tempo de resposta aferido pelo ESB. Após esta atualização, o arquivo fica conforme visualizado na Figura 19, onde podemos observar que houve uma reclassificação dos serviços disponíveis, onde o serviço com ID 01 está agora na posição dois, dado que o valor de sua variável de qualidade tempo é de 8000.

52 52 Figura 19: Classificação e status dos serviços disponíveis Conforme especificado na implementação da proposta, dado que o serviço retornou a solicitação, mesmo que com tempo acima do esperado, o Mule ESB executa as manipulações especificadas na solução e devolve o conteúdo retornado pelo serviço para a aplicação, que por sua vez apresenta o resultado ao usuário conforme Figura 20. Figura 20: Resultado na aplicação cliente Teste de Indisponibilidade Neste teste o usuário insere um texto no campo de entrada e clica no botão Enviar conforme Figura 21.

53 53 Figura 21: Aplicação cliente A aplicação encaminha o texto digitado pelo usuário para a entrada do barramento de serviços onde um componente do Mule ESB está configurado aguardando por requisições. O Mule ESB executa as manipulações necessárias nos dados de entrada recebidos conforme especificado na implementação da solução deste trabalho. Neste momento do teste, existem três serviços disponíveis e cadastrados no Mule ESB para executar esta funcionalidade. A Figura 22 apresenta o arquivo XML que representa os metadados dos serviços cadastrados. Por ela, pode-se notar que o serviço com ID 02 é o primeiro serviço na classificação estabelecida entre os três existentes, conforme resultado do teste anterior. Figura 22: Classificação e status dos serviços disponíveis

54 54 Conforme implementado, o Mule ESB verifica este arquivo e chama o serviço correspondente ao ID 02 do arquivo, encaminhando os dados de entrada recebidos da aplicação. No intuito de efetuar um teste de indisponibilidade, inseriu-se neste serviço uma indisponibilidade intencional, ou seja, o serviço não retorna os dados processados para a aplicação, disparando com isto uma falha de disponibilidade no ESB. Dado esta condição, o ESB atualiza o arquivo de metadados dos serviços, alterando a variável falha do serviço de ID 02 com o valor S, indicando que este serviço apresentou uma indisponibilidade. Após esta atualização, o arquivo fica conforme visualizado na Figura 23, onde se pode observar que houve uma reclassificação dos serviços disponíveis, onde o serviço com ID 02 está agora na posição três, dado que o valor de sua variável de qualidade falha é S. Figura 23: Classificação e status dos serviços disponíveis Conforme especificado na implementação da proposta, dado que o serviço não retornou a solicitação, o ESB reexecuta o fluxo dentro do barramento, iniciando novamente a leitura do arquivo de metadados dos serviços disponíveis. Uma vez que o arquivo já foi atualizado depois da indisponibilidade apresentada pelo serviço anterior, o ESB seleciona o serviço melhor classificado no arquivo e chama o serviço correspondente ao ID 01 encaminhando os dados de entrada recebidos da aplicação. O serviço por sua vez executa o processamento sob os dados recebidos e devolve ao

55 55 ESB. O ESB verifica a ocorrência ou não de falha e o tempo de resposta, que neste exemplo está dentro do esperado. Dado esta condição o ESB executa as manipulações especificadas na solução e devolve o conteúdo retornado pelo serviço para a aplicação, que por sua vez apresenta o resultado ao usuário conforme Figura 24. Figura 24: Resultado na aplicação cliente Portanto, os três testes apresentaram os resultados esperados, mostrando a reclassificação dos serviços com bases nos atributos de QoS tempo de resposta e indisponibilidade do serviço e o resultado da implementação das alterações arquiteturais implementadas no Mule ESB.

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Arquitetura Orientada a Serviço

Arquitetura Orientada a Serviço Arquitetura Orientada a Fabio Perez Marzullo IEEE Body of Knowledge on Services Computing Sponsored by Technical Committee on Services Computing, IEEE Computer Society 1 SOA e Web Services SOA é um modelo

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento.

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento. SOA Arquitetura Orientada a Serviços Conceitos e Aplicações Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Conceitode SOA SOA - Service OrientedArchitecture (Arquitetura

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 14 SOA e ESB Service-Oriented

Leia mais

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES Sistema de Informação e Tecnologia FEQ 0411 Prof Luciel Henrique de Oliveira luciel@uol.com.br Capítulo 5 INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES PRADO, Edmir P.V.; SOUZA, Cesar A. de. (org). Fundamentos

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

REST Um Estilo de Arquitetura de Sistemas Distribuídos

REST Um Estilo de Arquitetura de Sistemas Distribuídos REST Um Estilo de Arquitetura de Sistemas Distribuídos Márcio Alves de Araújo¹, Mauro Antônio Correia Júnior¹ 1 Faculdade de Computação Universidade Federal de Uberlândia (UFU) Monte Carmelo MG Brasil

Leia mais

Microsoft.NET. Desenvolvimento Baseado em Componentes

Microsoft.NET. Desenvolvimento Baseado em Componentes Microsoft.NET Lirisnei Gomes de Sousa lirisnei@hotmail.com Jair C Leite jair@dimap.ufrn.br Desenvolvimento Baseado em Componentes Resolução de problemas específicos, mas que podem ser re-utilizados em

Leia mais

Modelagem de Sistemas Web. Ferramentas e metodologias para projeto de sistemas web

Modelagem de Sistemas Web. Ferramentas e metodologias para projeto de sistemas web Modelagem de Sistemas Web Aula 4 Ferramentas e metodologias para projeto de sistemas web Ferramentas e metodologias para projeto de sistemas web Ferramentas CASE Fontes: Sarajane e Marques Peres Introdução

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services Web Services Existem diferentes tipos de comunicação em um sistema distribuído: Sockets Invocação

Leia mais

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com. Consumindo um Web Service através de uma Aplicação Comercial em Android Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.br 08/2014 Agenda Introdução Conceitos Web Service Por que utilizar

Leia mais

Arquitetura de Software: Uma Central para Gestão da execução de serviços

Arquitetura de Software: Uma Central para Gestão da execução de serviços Arquitetura de Software: Uma Central para Gestão da execução de serviços ADILSON FERREIRA DA SILVA Centro Paula Souza São Paulo Brasil afs.software@gmail.com Prof.a. Dr.a. MARILIA MACORIN DE AZEVEDO Centro

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

Leia mais

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas Criação de uma Serviço de Geração de Relatórios Goiânia 12/2011 Versionamento 12/12/2011 Hugo Marciano... 1.0

Leia mais

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações Universidade de São Paulo Escola Politécnica Programa de Educação Continuada em Engenharia PROGRAMA DE MBA em Gestão e Engenharia do Produto O Produto Internet e suas Aplicações Tecnologias de Informação

Leia mais

AUTOMAÇÃO SUPERVISÃO E CONTROLE E A APLICAÇÃO DA ARQUITETURA ORIENTADA A SERVIÇOS SOA.

AUTOMAÇÃO SUPERVISÃO E CONTROLE E A APLICAÇÃO DA ARQUITETURA ORIENTADA A SERVIÇOS SOA. AUTOMAÇÃO SUPERVISÃO E CONTROLE E A APLICAÇÃO DA ARQUITETURA ORIENTADA A SERVIÇOS SOA. Uma significativa parcela dos sistemas de automação de grandes empresas são legados de tecnologias de gerações anteriores,

Leia mais

Integração de sistemas utilizando Web Services do tipo REST

Integração de sistemas utilizando Web Services do tipo REST Integração de sistemas utilizando Web Services do tipo REST Jhonatan Wilson Aparecido Garbo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil jhowgarbo@gmail.com jaime@unipar.br

Leia mais

Infra estrutura da Tecnologia da Informação

Infra estrutura da Tecnologia da Informação Infra estrutura da Tecnologia da Informação Capítulo 3 Adaptado do material de apoio ao Livro Sistemas de Informação Gerenciais, 7ª ed., de K. Laudon e J. Laudon, Prentice Hall, 2005 CEA460 Gestão da Informação

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com Mecanismos de Comunicação Protocolos de Aplicação Mecanismos de comunicação

Leia mais

Serviços Web: Arquitetura

Serviços Web: Arquitetura Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1. Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1. Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3 INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1 Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3 INTRODUÇÃO Atualmente empresas de diversos portes estão encontrando nos web services soluções para seus

Leia mais

Serviços Web: Introdução

Serviços Web: Introdução Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Web Services. Integração de aplicações na Web. Sistemas Distribuídos

Web Services. Integração de aplicações na Web. Sistemas Distribuídos Web Services Integração de aplicações na Web Integração de Aplicações na Web Interoperação entre ambientes heterogêneos desafios diversidade de componentes: EJB, CORBA, DCOM... diversidade de linguagens:

Leia mais

SOA - Service Oriented Architecture. Marcelo Canevello Ferreira

SOA - Service Oriented Architecture. Marcelo Canevello Ferreira SOA - Service Oriented Architecture Marcelo Canevello Ferreira Índice Arquitetura baseada em componentes Introdução a SOA Principais conceitos de SOA SOA Framework Abordagem de integração Conclusões Evolução

Leia mais

Integração Orientada a Serviços

Integração Orientada a Serviços Integração Orientada a Serviços Porto Alegre, Agosto de 2006 Agenda Sobre a e-core SOA O que é? Web Services x SOA Principal Motivação - Integração SOI ESB BPEL JBI ServiceMix Solução Proposta A Empresa

Leia mais

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos ESB Enterprise Service Bus Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos Resumo Introdução Definição Problemas atuais e Vantagens Evolução do ESB ESB versus EAI, MOM, Workfow, SOA

Leia mais

Aplicação de arquitetura orientada a serviços na modelagem de um sistema de monitoramento de ovinos e bovinos confinados

Aplicação de arquitetura orientada a serviços na modelagem de um sistema de monitoramento de ovinos e bovinos confinados Aplicação de arquitetura orientada a serviços na modelagem de um sistema de monitoramento de ovinos e bovinos confinados Juciara Nepomuceno de Souza, Kleber Padovani de Souza, Leonardo Souza Silva 1 Universidade

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

Arquiteturas SOA, WOA, e REST

Arquiteturas SOA, WOA, e REST Arquiteturas SOA, WOA, e REST Aplicação de Software Social Fred Figueiredo Luiz Borges Pedro Pires Arquiteturas SOA, WOA e REST Desenvolvimento de aplicações orientadas ao fornecimento de serviços que

Leia mais

Anexo VI Edital nº 03361/2008. Projeto de Integração das informações de Identificação Civil. 1. Definições de interoperabilidade adotadas pela SENASP

Anexo VI Edital nº 03361/2008. Projeto de Integração das informações de Identificação Civil. 1. Definições de interoperabilidade adotadas pela SENASP Anexo VI Edital nº 03361/2008 Projeto de Integração das informações de Identificação Civil 1. Definições de interoperabilidade adotadas pela SENASP A Senasp procura adotar os padrões de interoperabilidade

Leia mais

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS WORKFLOW Mapeamento de Processos de Negócio Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS É proibido a reprodução total ou parcial de qualquer forma ou por qualquer meio sem a expressa autorização

Leia mais

Arquitetura Orientada a Serviços (SOA) Copyright e-core LTDA, 2010. Todos os direitos reservados.

Arquitetura Orientada a Serviços (SOA) Copyright e-core LTDA, 2010. Todos os direitos reservados. Arquitetura Orientada a Serviços (SOA) Visão Geral e-coree Estabelecida em 1999 Escritórios rios no Brasil e EUA Aproximadamente 100 profissionais Atua em prestação de serviços offshore desde 2004 Roteiro

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

Padrões Abertos, Componentização e SOA A chave para a evolução e criação de uma nova geração de sistemas de gestão comercial

Padrões Abertos, Componentização e SOA A chave para a evolução e criação de uma nova geração de sistemas de gestão comercial Padrões Abertos, Componentização e SOA A chave para a evolução e criação de uma nova geração de sistemas de gestão comercial Sindo V. Dias Antônio C. Mosca Rogério A. Rondini Agenda Cenário do Setor de

Leia mais

Kassius Vargas Prestes

Kassius Vargas Prestes Kassius Vargas Prestes Agenda 1. Introdução Web Services 2. XML, SOAP 3. Apache Tomcat 4. Axis 5. Instalação Tomcat e Axis 6. Criação de um Web Service 7. Criação de um cliente Baixar http://www.inf.ufrgs.br/~kvprestes/webservices/

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Semântica para Sharepoint. Busca semântica utilizando ontologias

Semântica para Sharepoint. Busca semântica utilizando ontologias Semântica para Sharepoint Busca semântica utilizando ontologias Índice 1 Introdução... 2 2 Arquitetura... 3 3 Componentes do Produto... 4 3.1 OntoBroker... 4 3.2 OntoStudio... 4 3.3 SemanticCore para SharePoint...

Leia mais

soluções transversais SOLUÇÕES middleware

soluções transversais SOLUÇÕES middleware soluções transversais SOLUÇÕES middleware RESUMO DA SOLUÇÃO ITbank framework 4g performance orquestração interoperabilidade O Middleware SOA ITBank framework 4g implementa uma arquitetura SOA com orquestração

Leia mais

Modelos e Arquiteturas de Sistemas Computacionais

Modelos e Arquiteturas de Sistemas Computacionais Modelos e Arquiteturas de Sistemas Computacionais Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas SUMÁRIO Importância da definição da Arquitetura

Leia mais

Universidade Federal de Pernambuco Centro de Informática Graduação em Ciência da Computação. Proposta Trabalho de Graduação

Universidade Federal de Pernambuco Centro de Informática Graduação em Ciência da Computação. Proposta Trabalho de Graduação Universidade Federal de Pernambuco Centro de Informática Graduação em Ciência da Computação Proposta Trabalho de Graduação Um Mecanismo de Monitoramento e Seleção de Serviços Baseado em Atributos de Qualidade

Leia mais

Introdução a Arquiteturas ESB I N S T I T U T O D E G E S TÃ O E M T E C N OLOGIA D A I N F OR M A Ç Ã O

Introdução a Arquiteturas ESB I N S T I T U T O D E G E S TÃ O E M T E C N OLOGIA D A I N F OR M A Ç Ã O Introdução a Arquiteturas ESB Uma típica sala de TV Uma TV e um DVD. Uma típica sala de TV em operação Conexão ponto a ponto entre a sala de TV e o DVD. A sala de TV dos seus sonhos Uma TV Digital, sistemas

Leia mais

CA Nimsoft Monitor para servidores

CA Nimsoft Monitor para servidores DOCUMENTAÇÃO TÉCNICA Setembro de 2012 CA Nimsoft Monitor para servidores agility made possible CA Nimsoft para monitoramento de servidores sumário CA Nimsoft Monitor para servidores 3 visão geral da solução

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

Linha de Produto para BPM

Linha de Produto para BPM Linha de Produto para BPM Prof. Dr. Marcelo Fantinato m.fantinato@usp.br Sistemas de Informação, EACH/USP Agenda Fundamentos LP para BPM Estabelecimento de Contratos Exemplo de Aplicação Trabalhos em Andamento/Próximos

Leia mais

Usando Service Design Thinking para criar SOA Corporativo

Usando Service Design Thinking para criar SOA Corporativo Usando Service Design Thinking para criar SOA Corporativo Hilton Menezes 2013 Introdução Uma área de Tecnologia da Informação - TI ágil pode contribuir significativamente para que o negócio possa fazer

Leia mais

e-ping - Padrões de Interoperabilidade de Governo Eletrônico www.governoeletronico.gov.br www.eping.e.gov.br

e-ping - Padrões de Interoperabilidade de Governo Eletrônico www.governoeletronico.gov.br www.eping.e.gov.br e-ping - Padrões de Interoperabilidade de Governo Eletrônico www.governoeletronico.gov.br www.eping.e.gov.br e PING: Segmentação Interconexão Segurança Meios de acesso Organização e intercâmbio de informações

Leia mais

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Ivan Guilherme 1, Jonas Queiroz 1, Caio Marques 2 1 Universidade Estadual Paulista, IGCE, DEMAC, Caixa

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS TM RELATÓRIO EXECUTIVO DE NEGÓCIOS A visão da computação em nuvem por Aad van Schetsen, vicepresidente da Compuware Uniface, que mostra por que

Leia mais

SOA-1: Fundamentos da Arquitetura Orientada a Serviços. Douglas Charcon System Engineer

SOA-1: Fundamentos da Arquitetura Orientada a Serviços. Douglas Charcon System Engineer SOA-1: Fundamentos da Arquitetura Orientada a Serviços Douglas Charcon System Engineer Agenda Direcionadores de Negócios Arquitetura Orientada a Serviços Enterprise Service Bus Enhanced SOA Resumo 2 Busca

Leia mais

Definição de Padrões. Padrões Arquiteturais. Padrões Arquiteturais. Arquiteturas de Referência. Da arquitetura a implementação. Elementos de um Padrão

Definição de Padrões. Padrões Arquiteturais. Padrões Arquiteturais. Arquiteturas de Referência. Da arquitetura a implementação. Elementos de um Padrão DCC / ICEx / UFMG Definição de Padrões Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Um padrão é uma descrição do problema e a essência da sua solução Documenta boas soluções para problemas recorrentes

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

UNIVERSIDADE FEDERAL DE MATO GROSSO INSTITUTO DE COMPUTAÇÃO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

UNIVERSIDADE FEDERAL DE MATO GROSSO INSTITUTO DE COMPUTAÇÃO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO UNIVERSIDADE FEDERAL DE MATO GROSSO INSTITUTO DE COMPUTAÇÃO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO RELATÓRIO DE ESTÁGIO SUPERVISIONADO PROPOSIÇÃO DE UMA NOVA ARQUITETURA BASEADA EM

Leia mais

Sistemas de Informações Gerenciais Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Sistemas de Informações Gerenciais Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Sistemas de Informações Gerenciais Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Capítulo 4 Infra-Estrutura de TI: Hardware e Software 2 1 OBJETIVOS

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE. Kellen Kristine Perazzoli 1, Manassés Ribeiro 2 RESUMO

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE. Kellen Kristine Perazzoli 1, Manassés Ribeiro 2 RESUMO INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE Kellen Kristine Perazzoli, Manassés Ribeiro RESUMO O grande avanço tecnológico vivenciado nos últimos anos, os web services vem sendo utilizados trazendo

Leia mais

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP HTTP (Hypertext Transfer Protocol ) Protocolo usado na Internet para transferir as páginas da WWW (WEB). HTTPS (HyperText Transfer

Leia mais

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Visão Geral Desafio Solução Uma implementação SOA (Service Oriented Architecture) bem-sucedida

Leia mais

Gerenciamento de Rede Baseado em Políticas

Gerenciamento de Rede Baseado em Políticas Gerenciamento de Rede Baseado em Políticas (Policy-Based Networking) Ademir José de Carvalho Junior Recife, Fevereiro de 2007 Resumo: A complexidade das redes baseadas em IP atualmente segue crescendo

Leia mais

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Agenda Introdução Aplicações interativas de TV Digital Desafios de layout e usabilidade Laboratório de usabilidade Desafios

Leia mais

Obtendo Qualidade com SOA

Obtendo Qualidade com SOA Obtendo Qualidade com SOA Daniel Garcia Gerente de Prática BPM/SOA daniel.garcia@kaizen.com.br 11 de Novembro de 2009 Copyright 2009 Kaizen Consultoria e Serviços. All rights reserved Agenda Sobre a Kaizen

Leia mais

Comunicado Técnico 11

Comunicado Técnico 11 Comunicado Técnico 11 ISSN 2177-854X Maio. 2011 Uberaba - MG Web Services e XML Comunicação Inteligente entre Sistemas Responsáveis: Daniela Justiniano de Sousa E-mail: dsol_dani21@hotmail.com Graduada

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Estruturação da Arquitetura Estadual de Sistemas de Informação por Meio da Orientação a Serviços

Estruturação da Arquitetura Estadual de Sistemas de Informação por Meio da Orientação a Serviços Estruturação da Arquitetura Estadual de Sistemas de Informação por Meio da Orientação a Serviços Relato de Experiência da ATI-PE WCGE 2010 20/07/2010 1 Introdução 2 Sobre a ATI Agência Estadual de Tecnologia

Leia mais

CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB

CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB Deusa Cesconeti e Jean Eduardo Glazar Departamento de Ciência da Computação Faculdade de Aracruz UNIARACRUZ {dcescone, jean}@fsjb.edu.br RESUMO

Leia mais

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural Arquitetura e Protocolos de Rede TCP/IP Modelo Arquitetural Motivação Realidade Atual Ampla adoção das diversas tecnologias de redes de computadores Evolução das tecnologias de comunicação Redução dos

Leia mais

JXTA. Alessandro Vasconcelos Ferreira de Lima. avfl@cin.ufpe.br

JXTA. Alessandro Vasconcelos Ferreira de Lima. avfl@cin.ufpe.br JXTA Alessandro Vasconcelos Ferreira de Lima Roteiro Motivação Introdução Arquitetura de JXTA Elementos de JXTA Os Protocolos Comparações e Desvantagens Conclusão Motivação Limitações do Modelo Cliente

Leia mais

Introdução a Web Services

Introdução a Web Services Introdução a Web Services Mário Meireles Teixeira DEINF/UFMA O que é um Web Service? Web Service / Serviço Web É uma aplicação, identificada por um URI, cujas interfaces podem ser definidas, descritas

Leia mais

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge. Projeto Demoiselle Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.net Palestrantes: Antônio Carlos Tiboni Luciana Campos Mota 20/07/2009

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

Leia mais

HENRIQUE SHOITI FUGITA. MAPOS: Método de Análise e Projeto Orientado a Serviços

HENRIQUE SHOITI FUGITA. MAPOS: Método de Análise e Projeto Orientado a Serviços HENRIQUE SHOITI FUGITA MAPOS: Método de Análise e Projeto Orientado a Serviços SÃO PAULO 2009 HENRIQUE SHOITI FUGITA MAPOS: Método de Análise e Projeto Orientado a Serviços Dissertação apresentada à Escola

Leia mais

Proposição de Novos Serviços para o SEMSuS: Middleware para Redes de Sensores sem fio baseado em Serviços Semânticos

Proposição de Novos Serviços para o SEMSuS: Middleware para Redes de Sensores sem fio baseado em Serviços Semânticos Proposição de Novos Serviços para o SEMSuS: Middleware para Redes de Sensores sem fio baseado em Serviços Semânticos Marianna Angélica de Araújo 1, Francisco Cassimiro Neto 2, Cláudia Maria Fernandes Araújo

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Integração de Dados Plataforma Hub Magento E-Commerce

Integração de Dados Plataforma Hub Magento E-Commerce Integração de Dados Plataforma Hub Magento E-Commerce Facilitando Negócios Conectando softwares com Magento Plataforma de E-Commerce Integração de Dados Plataforma Hub Magento E-Commerce Este documento

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

Introdução 17. 1 Introdução

Introdução 17. 1 Introdução Introdução 17 1 Introdução O volume de informações que gerenciamos tem crescido a cada dia. Realizamos milhões de pesquisas na Web, postamos mensagens em blogs, enviamos mensagens de correio eletrônico,

Leia mais

Softwares de Sistemas e de Aplicação

Softwares de Sistemas e de Aplicação Fundamentos dos Sistemas de Informação Softwares de Sistemas e de Aplicação Profª. Esp. Milena Resende - milenaresende@fimes.edu.br Visão Geral de Software O que é um software? Qual a função do software?

Leia mais

Porque adotar SOA. (Service Oriented Architecture) SOA. Por Ricardo de Castro Barbosa. Publicado Setembro/2008. 1 Portal BPM - www.portalbpm.com.

Porque adotar SOA. (Service Oriented Architecture) SOA. Por Ricardo de Castro Barbosa. Publicado Setembro/2008. 1 Portal BPM - www.portalbpm.com. SOA Porque adotar SOA (Service Oriented Architecture) Por Ricardo de Castro Barbosa Publicado Setembro/2008 Ricardo de Castro Barbosa é sócio da SOA- Savoir Faire (www.soa-savoirfaire.com.br) empresa dedicada

Leia mais