UMA INFRA-ESTRUTURA DE INTEGRAÇÃO DE SISTEMAS UTILIZANDO NOTIFICAÇÕES POR MEIO DE WEB SERVICES - PDF
UMA INFRA-ESTRUTURA DE INTEGRAÇÃO DE SISTEMAS UTILIZANDO NOTIFICAÇÕES POR MEIO DE WEB SERVICES
Download "UMA INFRA-ESTRUTURA DE INTEGRAÇÃO DE SISTEMAS UTILIZANDO NOTIFICAÇÕES POR MEIO DE WEB SERVICES"
Adelina Sanches Angelim
1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO UMA INFRA-ESTRUTURA DE INTEGRAÇÃO DE SISTEMAS UTILIZANDO NOTIFICAÇÕES POR MEIO DE WEB SERVICES EVERTON SEBASTIANY REISDORFER DEWES Dissertação apresentada como requisito parcial à obtenção do grau de Mestre, pelo Programa de Pós-Graduação em Ciência da Computação da Faculdade de Informática da Pontifícia Universidade Católica do Rio Grande do Sul. Orientadora: Profa. Dra. Karin Becker Porto Alegre 2005
4 AGRADECIMENTOS Aos meus pais, Ilse e José, e a meu irmão Heitor, pelo apoio e motivação. A minha orientadora, Karin Becker, por ter compartilhado comigo seu conhecimento e sua paciência durante o período do mestrado. Ao Programa de Pós-Graduação em Ciência da Computação pela ótima infra-estrutura disponível para os alunos. Ao Centro de Desenvolvimento e Pesquisa (CDPe), do Convênio DELL/PUCRS, pelo financiamento do meu curso de mestrado. Aos meus amigos que souberam compreender as minhas ausências. Muito Obrigado!
5 RESUMO A integração de aplicações pode ser identificada como uma tarefa vital devido a muitos dos requisitos dos sistemas de informação envolverem a comunicação com diferentes parceiros (ex. clientes, fornecedores, aplicativos internos) em tempo real. Porém, o desenvolvimento dessa interoperabilidade é caro e consome tempo. Web Services fornecem uma solução interessante com relação a esses problemas, permitindo aos sistemas trocarem informação com um pequeno esforço de integração e maior flexibilidade. Porém, ainda existem problemas em aberto na integração de sistemas com Web Services. A interoperação com base em mensagens desacopla os sistemas, focando no controle sobre as interações do sistema e a troca de informação. Dessa forma, ela ajuda a resolver alguns dos problemas encontrados na integração direta de sistemas tradicional. A WS-Notification é uma padronização de troca de mensagens para Web Services, composta por um conjunto de especificações abertas que usam Web Services para trocar informações através de mensagens assíncronas. Porém, muitos sistemas de informação (legados) não estão preparados para interoperar com outros sistemas através de mensagens e, conseqüentemente, necessitam ser adaptados especialmente para este tipo de integração. Este trabalho propõe uma Infra-Estrutura de integração que guia a adaptação de sistemas de informação tradicionais e suas integrações, considerando a padronização WS-Notification. O projeto da Infra-Estrutura proposta tem base em questões identificadas que necessitam ser tratadas para a integração de sistemas usando mensagens de notificação. Padrões arquiteturais e de projeto que podem ser aplicados para resolver essas questões foram identificados, resultando na definição de um conjunto de componentes que, juntos, formam a Infra-Estrutura de integração. A Infra-Estrutura é detalhada em termos de seus componentes, das questões que ela trata, bem como dos seus relacionamentos com outros componentes e sistemas aos quais ela é integrada. A Infra-Estrutura foi aplicada em três estudos de caso com diferentes questões de integração e uma análise de desempenho preliminar foi desenvolvida. Palavras-chave: Integração de Sistemas, Web Services, EAI, WS-Notification e Padrões de Projeto.
6 ABSTRACT Application integration is a critical task, since it requires dealing with information systems of different partners (e.g. costumers, suppliers, internal applications) on-line. However, the development of this interoperability is expensive and time consuming. Web Services provide interesting solutions with regard to these problems, allowing systems to exchange information with less integration efforts and more flexibility. However, there are still open problems in the integration of systems with Web Services. Message-based interoperation decouples systems, focusing on the control over system interaction and exchanged information. In this way, it helps solving some of the problems faced in the traditional integration of systems. WS-Notification is a Web Service messaging standard that is composed of a set of open specifications that use Web Services to exchange information among applications through asynchronous messages. However, many (legacy) information systems are not prepared to interoperate with other systems through messages, and therefore, they need to be specifically adapted for this kind of integration. This work proposes an integration Infra-Structure that guides the adaptation of conventional information systems and their integration, considering the standard WS- Notification. The design of the proposed Infra-Structure was based on the identification of issues that must be handled for system integration using message notification. Design and architectural patterns that could be applied to solve these issues were identified, resulting in the definition of a set of components that, together, form the integration Infra-Structure. The Infra-Structure is detailed in terms of its components, the issues they handle, as well as their relationships with other components and with systems that are integrated. The Infra-Structure is applied in three case studies with different integration issues, and a preliminary performance analysis was developed. Key-words: Systems Integration, Web Services, EAI, WS-Notification and Design Patterns.
7 LISTA DE FIGURAS Figura 1 Um cliente interagindo com diversos servidores (1:N) Figura 2 Diversos clientes interagindo com diversos servidores (N:M) Figura 3 - Classificação de sistemas [11] Figura 4 - Estrutura dos Web Services [13] Figura 5 - Ciclo de vida de um serviço composto [23] Figura 6 - Representação dos principais elementos do WS-Notification Figura 7 - Descrição do modelo [25] Figura 8 - Padrões estruturais da arquitetura Broker dos sistemas de negócios [25] Figura 9 - Um exemplo de múltiplos domínios [25] Figura 10 - Funcionamento do padrão Service Activator apresentado em [28] Figura 11 - Duas formas de interação entre cliente e servidor Figura 12 - Interação síncrona versus interação assíncrona Figura 13 - Encapsulamento de uma mensagem JMS em uma mensagem Notify Figura 14 - Transformação de uma chamada RPC em uma mensagem Notify Figura 15 - Transformação de uma mensagem em uma chamada RPC Figura 16 - Componentes da Infra-Estrutura de Integração Figura 17 - Adaptador Publisher Figura 18 - Funcionamento do componente Adaptador Publisher Figura 19 - Proxy NotificationConsumer Figura 20 - Mensagens do Adaptador Publisher para o Proxy NotificationConsumer Figura 21 - Mensagens do Adaptador Subscriber para o Proxy NotificationConsumer Figura 22 -Adaptador Subscriber Figura 23 - Funcionamento do Adaptador Subscriber para o recebimento de mensagens Figura 24 - Funcionamento do Adaptador Subscriber para sistemas servidores com resposta Figura 25 - Controlador de Respostas Figura 26 - Funcionamento do Controlador de Respostas Figura 27 - Adaptador Controlador de Respostas Figura 28 - Funcionamento do Adaptador Controlador de Respostas Figura 29 - Infra-Estrutura de Integração Figura 30 - Classes que implementam a interface NotificationConsumer Figura 31 - Infra-Estrutura com utilização de resposta direta ao Controlador de Respostas Figura 32 - Estrutura do padrão Proxy aplicado para o acesso a um Sistema Servidor
8 Figura 33 - Estrutura da WS-I SCM Figura 34 - Estrutura do NotificationBroker utilizado Figura 35 - Domínio do estudo de caso WS-I SCM Warehouse Figura 36 - Estrutura do Adaptador Publisher aplicado ao WS-I SCM Vendas Figura 37 - Estrutura dos Adaptadores Subscriber criados para as Warehouse Figura 38 - Estrutura do componente Adaptador Subscriber aplicado ao WS-I SCM Vendas Figura 39 - Domínio de funcionamento do estudo de caso WS-I SCM Manufacturer Figura 40 - Adaptador Subscriber implementado para as Manufacturer Figura 41 - Domínio do estudo de caso WS-I SCM Retailer Figura 42 - Comparação dos testes 1 e 2 (uma conexão) Figura 43 - Comparação dos testes 3 e 4 (três conexões) Figura 44 - Comparação dos testes 1 e 2 (uma conexão) Figura 45 - Comparação dos testes 3 e 4 (três conexões) Figura 46 - Comparação dos testes 1 e 2 (uma conexão) Figura 47 - Comparação dos testes 3 e 4 (três conexões)
9 LISTA DE TABELAS Tabela 1 - Problemas de adaptação vs. Componentes da Infra-Estrutura Tabela 2 - Padrões de Projeto/Arquiteturais vs. Componentes da Infra-Estrutura Tabela 3 - Descrição das classes participantes do Adaptador Publisher Tabela 4 - Descrição das classes participantes do Proxy NotificationConsumer Tabela 5 - Descrição das classes participantes do Adaptador Subscriber Tabela 6 Relação entre os elementos do Padrão Blackboard e do Controlador de Mediação Tabela 7 - Descrição das classes participantes do Controlador de Respostas Tabela 8 - Descrição das classes participantes do Adaptador Controlador de Respostas Tabela 9 - Estudos de caso e os componentes reusáveis da Infra-Estrutura Tabela 10 - Elementos identificados para a adaptação Tabela 11 - Configurações necessárias para o estudo de caso WS-I SCM Warehouse Tabela 12 - Elementos identificados para a adaptação Tabela 13 - Configurações necessárias para o estudo de caso WS-I SCM Manufacturer Tabela 14 - Elementos identificados para a adaptação Tabela 15 - Configurações necessárias para o estudo de caso WS-I SCM Retailer Tabela 16 - Configurações do ACT para cada teste realizado Tabela 17 - Diferença de tempo utilizado para finalizar os testes Tabela 18 - Configurações do ACT para cada teste realizado Tabela 19 - Diferença de tempo utilizado para finalizar os testes Tabela 20 - Configurações do ACT para cada teste realizado Tabela 21 - Diferença de tempo utilizado para finalizar os testes
10 LISTA DE ABREVIATURAS Sigla ACT BPEL4WS BSC CORBA DBC EAI EDA EDI EJB HTML HTTP IIS J2EE JMS JSP MSDE MSMQ RPC SCM SGML SMTP SOA SOAP UDDI UML URI W3C WS WSDL WSFL WS-I WSIL XLANG XML XSD Descrição Application Center Test Business Process Execution Language for Web Services Business-Service-Computing Common Object Request Broker Architecture Desenvolvimento Baseado em Componentes Enterprise Application Integration Event-Driven Architecture Electronic Data Interchange Enterprise JavaBeans HyperText Markup Language Hypertext Transfer Protocol Internet Information Services Java 2 Enterprise Edition Java Message Service JavaServer Pages Microsoft SQL Server Desktop Engine Microsoft Message Queuing Remote Procedure Call Supply Chain Management Standard Generalized Markup Language Simple Mail Transfer Protocol Service Oriented Architecture Simple Object Access Protocol Universal Description, Discovery and Integration Unified Modeling Language Universal Resource Indicator World Wide Web Consortium Web Services Web Services Description Language Web Services Flow Language Web Services Interoperability Web Services Inspection Language Web Services for Business Process Design Extensible Markup Language XML Schema
11 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS ESTRUTURA DO DOCUMENTO SISTEMAS DE INFORMAÇÃO SISTEMA ALTAMENTE DECOMPONÍVEL SISTEMA SEMI-DECOMPONÍVEL SISTEMA MONOLÍTICO OU NÃO DECOMPONÍVEL RESUMO WEB SERVICES E WS-NOTIFICATION CONCEITOS BÁSICOS DE WEB SERVICES PROBLEMAS RELACIONADOS À UTILIZAÇÃO DE WEB SERVICES CICLO DE VIDA PARA O DESENVOLVIMENTO BASEADO EM WEB SERVICES UTILIZANDO EDA PARA A INTEGRAÇÃO DE APLICAÇÕES RESUMO TRABALHOS RELACIONADOS CRIAÇÃO DE WEB SERVICES DIRIGIDA A NEGÓCIOS INTEGRAÇÃO DE SISTEMAS COM WEB SERVICES WEB SERVICES E COMPONENTES RESUMO INTEGRAÇÃO DE SI COM O MODELO WS-NOTIFICATION PROBLEMAS IDENTIFICADOS PARA INTEGRAÇÃO PROPOSTA DE UMA INFRA-ESTRUTURA INFRA-ESTRUTURA DE INTEGRAÇÃO COMPONENTES IDENTIFICADOS PARA A CONSTRUÇÃO DA INFRA-ESTRUTURA DIRETRIZES PARA A UTILIZAÇÃO DA INFRA-ESTRUTURA CONSIDERAÇÕES E VARIAÇÕES VANTAGENS DA INFRA-ESTRUTURA APLICAÇÃO DA INFRA-ESTRUTURA 70
12 7.1 ESPECIFICAÇÃO WS-I SCM CONSIDERAÇÕES GERAIS ESTUDO DE CASO: WS-I SCM WAREHOUSES ESTUDO DE CASO: WS-I SCM MANUFACTURER ESTUDO DE CASO: WS-I SCM RETAILER TESTES DE DESEMPENHO CONSIDERAÇÕES FINAIS CONCLUSÃO LIMITAÇÕES TRABALHOS FUTUROS REFERÊNCIAS 94
14 14 1 INTRODUÇÃO Atualmente, grandes e pequenas empresas consumidoras de software já possuem boa parte de seus processos internos informatizados. Essas aplicações guardam a inteligência da organização e são o resultado de investimentos realizados em diversas épocas, refletindo na arquitetura de seus sistemas várias fases tecnológicas. Com o passar do tempo, sistemas de software precisam ser mantidos, modificados e integrados a outros sistemas ou, então, se tornam obsoletos. Essa é uma evolução natural, pois, com o crescimento das empresas e alterações constantes dos ambientes de computação, surge a necessidade da melhoria e integração de suas aplicações. A integração de aplicações pode ser identificada como uma tarefa vital devido a muitos dos requisitos dos sistemas de informação envolverem a comunicação com clientes, fornecedores, parceiros e aplicativos internos, muitas vezes em tempo real. Porém, habilitar essa interoperabilidade é, normalmente, um trabalho árduo que consome muito tempo e recursos. A questão de integração de sistemas através de protocolos-padrão que possuem baixo acoplamento não é nova. Por exemplo, EDI (Eletronic Data Interchange) é um mecanismo de integração que possui um baixo acoplamento e permite a integração de sistemas de diferentes plataformas, já sendo utilizado com sucesso em projetos de integração. Web Services [1] [2] vêm ao encontro dos mesmos objetivos, que consistem em permitir que sistemas diferentes troquem informações com o mínimo de esforço de integração e máxima flexibilidade. Web Services são aplicações disponíveis através da Internet que fornecem algum tipo de serviço para outras aplicações, tanto de processamento como de informação. Diferenciam-se de outras aplicações para a Web, pois envolvem, normalmente, comunicação entre sistemas e não são projetados para serem acessados diretamente pelo usuário. Ainda, clientes desses serviços podem ser escritos em qualquer plataforma desde que suportem os protocolos utilizados pelos Web Services. O uso de tais tecnologias padronizadas reduz a heterogeneidade e, dessa forma, facilita a integração de aplicações [3]. Uma arquitetura de software diz respeito à organização do sistema de software por completo [4] [5] [6] [7], e envolve a seleção dos elementos estruturais, suas interfaces e a composição desses elementos. Essa arquitetura é utilizada como uma estrutura básica que permite o entendimento dos componentes do sistema e seus relacionamentos internos e externos. Os Web Services renovaram a idéia de arquitetura orientada a serviços (Service Oriented Architecture - SOA). SOA é, em essência, uma forma de projetar um sistema de software para fornecer serviços tanto para aplicações de usuário quanto para outros serviços através da
15 15 utilização de publicações e descobertas de interfaces [8]. Uma arquitetura orientada a serviços pode oferecer muitos benefícios, como uma redução no custo de manutenção em sistemas de informação que sofrem alterações constantes, acelerando o processo de desenvolvimento através do reuso, melhorando a utilização de recursos e reduzindo a redundância. Além dos benefícios já apresentados, SOA consiste em uma arquitetura que promove o baixo acoplamento, o que facilita o reuso e permite que as aplicações funcionem independentemente. A utilização de Web Services para a integração de aplicações pode ser realizada com diversos formatos e configurações em uma arquitetura orientada a serviços. Um cenário normal é a integração direta entre um cliente e um servidor remoto. Essa solicitação, muitas vezes, tem um caráter de sincronização de estados, ou seja, realiza uma busca por informações que eventualmente tenham sido alteradas ou adicionadas, o que pode não ter ocorrido. Essa é uma forma totalmente síncrona de interação, na qual o cliente fica paralisado até que o servidor retorne os dados solicitados. Em uma situação comum, como esquematizada na Figura 1, uma aplicação cliente entra em contato com diversas aplicações servidoras para a realização de suas tarefas. Já do ponto de vista do servidor, é possível que existam diversos clientes acessando os seus serviços, cada qual com seu objetivo específico. Pode-se, então, visualizar um cenário no qual existe uma combinação de interações de diversos clientes para diversos servidores (Figura 2). Servidor 1 Cliente Servidor 2 Servidor n Figura 1 Um cliente interagindo com diversos servidores (1:N). Cliente 1 Cliente 2 Cliente n Servidor 1 Servidor 2 Servidor m Figura 2 Diversos clientes interagindo com diversos servidores (N:M). Essa configuração típica de grandes empresas é ineficiente, pois: 1. Para a integração, é necessário realizar a adaptação de diversos sistemas, tanto clientes como servidores, para que possam interoperar. Se existem 5 clientes distintos e 5 servidores distintos a serem acessados, podem ser necessárias até 25 adaptações.
16 16 2. Para a manutenção, cada alteração na interface de um servidor implicará modificação de todos os clientes que acessam o seu serviço. De forma análoga, a modificação de um cliente requer que ele seja novamente adaptado para o funcionamento com os servidores. 3. Sua execução acaba por sobrecarregar os servidores, pois a busca de dados para sincronização de estados faz com que os clientes realizem chamadas desnecessárias a serviços. A utilização de comunicação assíncrona é uma forma de aperfeiçoar a troca de informações, pois permite a realização de tarefas em paralelo, economizando o tempo de espera por respostas e tornando o trabalho dos sistemas mais eficiente. É nesse ponto que as arquiteturas dirigidas a eventos (Event-Driven Architecture - EDA) tornam-se interessantes. Elas permitem que diversos sistemas cooperem de forma não intrusiva, estimulando o paralelismo de aplicações. EDA é um paradigma arquitetural baseado na utilização de eventos como gatilhos, que informam diversos assinantes sobre um evento de tal forma que cada um deles possa tomar uma ação apropriada. Para o gerenciamento dos eventos, utiliza-se o padrão arquitetural Broker [9], que tem por função distribuir um conjunto de notificações e repassá-las para os sistemas interessados. Assim, sistemas podem trocar informações dinamicamente, sem necessariamente conhecerem seus parceiros de interação, sendo possível alterar regras, rotear mensagens entre diversos Brokers, filtrar e transformar mensagens, antes destas chegarem aos seus destinatários. Além disso, o baixo acoplamento permite a substituição parcial ou total de qualquer um dos sistemas que participam de uma arquitetura, de maneira totalmente transparente para clientes ou servidores. Neste trabalho, apresenta-se um estudo sobre a integração de sistemas através de um NotificationBroker. Resumidamente, ele é especificado na WS-Notification, sendo uma padronização para a utilização de eventos sobre Web Services, tendo como objetivo o gerenciamento de envio e recebimento de mensagens entre elementos publicadores e assinantes. Como resultado deste estudo, propõe-se uma Infra-Estrutura capaz de facilitar a integração de sistemas com a padronização WS-Notification, permitindo que esses, de maneira transparente, possam trocar informações com os mais diversos sistemas, e que sua evolução ou até mesmo substituição não afete os demais participantes da arquitetura. Isso significa um ganho de esforço no que se refere ao projeto de adaptação e extensão de sistemas de informação, já que a Infra-Estrutura proposta identifica componentes necessários à integração através de
17 17 notificações entre Web Services, detalhando seu papel, bem como os relacionamentos e interação com os demais componentes e sistemas a serem integrados. A base da Infra-Estrutura proposta é a utilização de padrões de projeto e padrões arquiteturais ([9], [10]) como auxílio na solução das principais questões encontradas para integração de sistemas via Web Services, encontradas ao longo do desenvolvimento deste trabalho. Padrões tornaram-se parte integral do projeto e arquitetura de software, e os benefícios de sua utilização podem ser aplicados também aos Web Services. 1.1 Objetivos Dadas as características de integração de sistemas, é extremamente útil ter uma estrutura que auxilie a configuração, adaptação e extensão de (sub)sistemas em um ambiente orientado a eventos. Assim, o objetivo deste trabalho é propor uma Infra-Estrutura que auxilie na integração de sistemas de informação através de mensagens, considerando que os sistemas a serem integrados não estejam originalmente preparados para interoperarem segundo o paradigma EDA. Para o desenvolvimento deste trabalho, foram definidos os seguintes objetivos específicos: 1. Identificação de problemas existentes na integração de sistemas através de Web Services, e a contribuição de EDA à solução dos mesmos; 2. Identificação de questões de integração que devem ser resolvidas para que sistemas possam trabalhar de forma transparente com EDA; 3. Identificação de padrões de projeto e padrões arquiteturais que resolvam as questões de integração identificadas; 4. Especificação de uma Infra-Estrutura de integração que traga resposta às questões de integração identificadas, usando padrões de projeto/arquiteturais existentes; 5. Desenvolvimento de um estudo de caso, mostrando a aplicabilidade da Infra-Estrutura proposta, bem como testes de desempenho. 1.2 Estrutura do Documento O restante deste documento está organizado da seguinte forma: O Capítulo 2 apresenta a classificação utilizada no decorrer do trabalho para a distinção dos sistemas de informação, permitindo, assim, limitar o seu escopo. O Capítulo 3 apresenta os principais conceitos utilizados à continuação deste trabalho, servindo como base para o entendimento das soluções propostas. No Capítulo 4 são apresentados os principais trabalhos relacionados a este, bem como a contextualização desses trabalhos relação a este. O Capítulo 5 apresenta a idéia da Infra-
18 18 Estrutura, o seu planejamento e as questões que ela soluciona. No Capítulo 6 é apresentado o projeto dos componentes da Infra-Estrutura e de sua interação. Ainda apresenta as diretrizes para a aplicação da Infra-Estrutura e algumas variações que podem ser utilizadas. O Capítulo 7 traz os estudos de caso da aplicação da Infra-Estrutura, os resultados dos testes de desempenho realizados e a análise dos mesmos. O Capítulo 8 apresenta as conclusões e considerações finais sobre o trabalho realizado.
19 19 2 SISTEMAS DE INFORMAÇÃO O objetivo deste capítulo é apresentar uma breve introdução à classificação de sistemas e, com base nela, contextualizar o tipo de sistema que este trabalho irá abranger. As classificações apresentadas a seguir foram construídas em um contexto de adaptação e manutenção de sistemas legados, porém, são genéricas o suficiente para permitirem a sua utilização mesmo sobre sistemas novos ou que ainda estão em construção. Sistemas legados são definidos em [11] como aplicações que ainda são utilizadas pelas empresas, porém, que não possuem mais suporte ou atualização por parte do seu fornecedor. Tal fator limita a possibilidade de introdução de novas funcionalidades ou manutenção de funcionalidades antigas. Utilizando o raciocínio inverso, sistemas não legados são os que ainda são mantidos por equipes de suporte, tendo sua manutenção e evolução garantidas. Segundo [12], todos os sistemas de informação possuem três componentes: interfaces, aplicações e serviços de banco de dados. As arquiteturas de sistema de informação variam amplamente de um espectro estruturadas (isto é, modulares, capazes de serem decompostas em partes e módulos) até sem estrutura (isto é, não decomponíveis). Durante a revisão bibliográfica sobre classificação de sistemas, duas abordagens bastante semelhantes foram encontradas. A proposta de [12] classifica os tipos de sistemas em três grupos: totalmente decomponíveis, semi-decomponíveis e monolíticos. A proposta de [11] refina a classe de semi-decomponíveis em duas classes: semi-decomponíveis de dados e semi-decomponíveis de programas. A classificação está descrita na Figura 3 e o detalhamento, apresentado nas próximas subseções. Interface com o Usuário Processamento Lógico Interface com o Usuário Processamento Lógico Interface com o Usuário Processamento Lógico Interface com o Usuário Processamento Lógico Dados Dados Dados Dados Muito Altamente Decomponível Friendly Dados Decomponíveis Neighborly Programa Decomponível Neighborly Monolítico Hostile Figura 3 - Classificação de sistemas [11].
20 Sistema altamente decomponível O melhor tipo de sistema para propósitos de migração são os altamente decomponíveis, no qual as interfaces de usuário, as aplicações e os serviços de banco de dados podem ser considerados como componentes distintos, com interfaces bem definidas. Ou seja, é uma coleção independente de módulos de aplicação que possuem suas próprias interfaces, cada qual trocando informações com os serviços de banco de dados, possuindo uma interface de usuário ou uma interface de sistema. É através dessas interfaces que esse tipo de sistema troca dados com um ou mais sistemas de informação estrangeiros. Ambas as interfaces (de usuário e de sistemas) precisam ser consideradas separadamente, já que se diferem significantemente em termos de tecnologia, projeto, requisitos de desempenho e impacto [12]. Uma definição parecida é apresentada por [11], onde esse tipo de sistema é tido como bem estruturado, contendo uma separação clara entre interface com o usuário, lógica de processamento da aplicação e serviços de acesso a dados. Ainda, permite o acesso direto às suas funcionalidades, independência de cada módulo sem dependência hierárquica e com interfaces bem definidas em todas as camadas. Esse tipo de sistema, normalmente, é bastante amigável para ser transformado e suas interfaces são acessíveis para outras aplicações. Seus componentes podem ser acessados diretamente e a sua migração, realizada gradualmente. 2.2 Sistema Semi-Decomponível Sistemas semi-decomponíveis são mais difíceis de serem migrados em contraste com os sistemas altamente decomponíveis. Para [11], é possível separar essa categoria em duas: sistemas decomponíveis de dados e sistemas decomponíveis de programas. As duas características principais dos sistemas decomponíveis de dados são: separação em camada de acesso a dados e camada de interface com o usuário/processamento de dados. Nessa categoria de sistema, os dados podem ser acessados diretamente, por exemplo, utilizando aplicações ou ferramentas remotas devido às interfaces bem definidas dos serviços de dados. Já a lógica de aplicação não pode ser acessada diretamente por outras aplicações, por estar altamente acoplada com a interface do usuário. Sistemas decomponíveis de programas são aplicações semi-estruturadas semelhantes aos sistemas decomponíveis de dados, porém as camadas são: interface do usuário e as aplicações de processamento/dados. Portanto, as interfaces para acesso através de outros programas são bem definidas, porém os dados não podem ser acessados diretamente.
21 Sistema monolítico ou Não Decomponível Esse tipo de sistema é visto como uma peça única, pois os seus componentes básicos não são divisíveis. Os usuários finais e o sistema de informações interagem diretamente um com o outro, aparentemente de maneira desestruturada de componentes ou módulos [12]. Para [11], nessa categoria, todo o sistema aparece como um único bloco, com uma única camada. Tais dados de aplicação podem ser acessados apenas através do terminal de usuário da aplicação, sendo indisponíveis para acesso por meio de outros softwares. 2.4 Resumo Para que seja possível avaliar os resultados da aplicação de uma nova tecnologia em sistemas pré-existentes, deve-se, primeiramente, definir qual o tipo de sistema no qual o estudo será aplicado. Nesse sentido, a classificação de sistemas serve como um guia para que o estudo possa ser repetido em outros sistemas e seus resultados, comparados. Além disso, a classificação, segundo as categorias apresentadas, é bastante simples. Tais categorias foram concebidas com o foco na migração de sistemas legados através do encapsulamento ou reengenharia, porém, podem ser utilizadas para classificar qualquer tipo de sistema devido a sua generalidade. A abordagem proposta neste trabalho faz o uso de sistemas tanto legados como não legados, e a categoria na qual o sistema a ser integrado se encontra deve ser levada em consideração, principalmente porque limitações impostas por certos tipos de sistemas podem tornar as técnicas estudadas ineficientes. O que se espera de um sistema, no escopo deste trabalho, são interfaces de aplicação bem definidas e acessíveis, permitindo o reuso da lógica do sistema através de uma integração com baixo acoplamento. Dessa forma, um sistema altamente decomponível pode ser aplicado no presente estudo, devido às suas interfaces de aplicação bem definidas, permitindo que seja possível utilizar diretamente a lógica do sistema. Os sistemas decomponíveis de programas também podem ser enquadrados no escopo deste trabalho, pois o acesso direto aos dados não é requerido. Porém, os sistemas decomponíveis de dados não podem ser utilizados, uma vez que a lógica do sistema não pode ser acessada diretamente. Para o escopo atual, o foco é a integração de sistemas, enquadrando, dessa forma, esses dois tipos de sistemas nos objetivos deste trabalho. Assim, será trabalhada apenas a análise dos sistemas preexistentes, mantendo o foco na solução das questões de interoperabilidade entre eles.
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
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
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
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
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
Sistemas Distribuídos Arquiteturas Middlewares
Sistemas Distribuídos Arquiteturas s Arquitetura Arquitetura de um sistema é sua estrutura em termos dos componentes e seus relacionamentos Objetivo: garantir que a estrutura satisfará as demandas presentes
Sistemas Distribuídos 11 Objetivos Este capítulo apresenta uma introdução aos sistemas distribuídos em geral Arquiteturas de cliente servidor Características das arquiteturas de 2 e 3 camadas Ambiente
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,
Sistemas distribuídos:comunicação
M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.
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
UFG - Instituto de Informática Curso: Sistemas de Informação Arquitetura de Software Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 4 Estilos Arquitetônicos Estilos Arquiteturais Dataflow
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
Ambientes Visuais. Ambientes Visuais
Ambientes Visuais Inicialmente, apenas especialistas utilizavam os computadores, sendo que os primeiros desenvolvidos ocupavam grandes áreas e tinham um poder de processamento reduzido. Porém, a contínua
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
Serviços Web: Arquitetura
Web services. Um web service é qualquer software que está disponível através da Internet através de uma interface XML.
Web services Um web service é qualquer software que está disponível através da Internet através de uma interface XML. XML é utilizado para codificar toda a comunicação de/para um web service. Web services
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
Sistemas Distribuídos na Web. Pedro Ferreira DI - FCUL
Sistemas Distribuídos na Web Pedro Ferreira DI - FCUL Arquitetura da Web Criada por Tim Berners-Lee no CERN de Geneva Propósito: partilha de documentos Desde 1994 mantida pelo World Wide Web Consortium
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
Web Services e SOAP. Alexandre Zua CaldeiraTecnologias de Middleware 2006/2007 20.10.2006. Faculdade de Ciências da Universidade de Lisboa
Alexandre Zua Caldeira Tecnologias de Middleware 2006/2007 Faculdade de Ciências da Universidade de Lisboa 20.10.2006 1 Introdução Definições Limitações do Middleware Estudado Integração com Web Services
Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.
Implementar servidores de Web/FTP e DFS Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.br Conteúdo programático Introdução ao protocolo HTTP Serviço web
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
Metas de um Sistema Distribuído
Metas de um Sistema Distribuído 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
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
Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os
Padrões Arquiteturais. Sistemas Distribuídos: Broker
Padrões Arquiteturais Sistemas Distribuídos: Broker Sistemas Distribuídos Tendências: Sistemas Comp. com múltiplas CPUs Redes locais com centenas de hospedeiros Benefícios Economia Desempenho e escalabilidade
PROGRAMAÇÃO SERVIDOR WEBSERVICES EM SISTEMAS WEB. Prof. Dr. Daniel Caetano 2012-1
PROGRAMAÇÃO SERVIDOR EM SISTEMAS WEB WEBSERVICES Prof. Dr. Daniel Caetano 2012-1 Objetivos Compreender o que é um WebService e sua utilidade Compreender a lógica de funcionamento de um WebService Capacitar
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
Padrões de projeto 1
Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois
11/20/10. Resoluções: Teste de Áudio. Não suporto esses malucos de TI. Só inventam despesas. Não acredito que teremos que pagar por mais softwares.
Não suporto esses malucos de TI. Só inventam despesas. Não acredito que teremos que pagar por mais softwares. Teste de Áudio Quero adaptar os softs que já temos e você não sabe como faz e diz que não é
R/3 e SAP WAS. 8/28/2003 José Alves Marques. R/3 e SAP WAS(2)
R/3 e SAP WAS O R/3 é um ERP Enterprise Resource Planning Um ERP é o sistema empresarial que disponibiliza módulos para os processos de negócio - de uma empresa Um ERP permite aumentar a eficiência dos
Universidade Federal de Minas Gerais. Sistemas Operacionais. Aula 23. Sistemas Operacionais Distribuídos
Aula 23 Distribuídos SOs de Rede Em sistemas operacionais de rede você sabe quando é local e quando é remoto. Assim, o trabalho não muda, com exceção de comandos para acesso remoto: - telnet - ftp - etc.
Paradigma Cliente/Servidor
Paradigma Cliente/Servidor Mário Meireles Teixeira UFMA Departamento de Informática Dezembro, 2012 Comunicação em Sistemas Distribuídos! Os processos em um SD estão lógica e fisicamente separados. Precisam
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