MODERNIZAÇÃO DE SISTEMAS LEGADOS: um estudo de caso sobre 
integração de sistema legado Delphi/DCOM com barramento de serv...
2 
 
 
 
1. INTRODUÇÃO 
Um sistema computacional ​deve estar alinhado com os requisitos de negócio e                      ...
3 
Este trabalho apresenta­se dividido em seis seções, descritas a seguir. Na seção 2                         
expõe­se a ...
4 
mudanças mais urgentes e eficazes em termos de custos (SOMMERVILLE, 2011). Assim a                         
evolução de...
5 
 
De acordo com a primeira lei de Lehman (1997), um sistema deve ser continuamente                           
adaptado ...
6 
alterar o sistema legado para reconstituí­lo em um novo formato e a subsequente                         
implementação ...
7 
interface web; ​data modernization ​com xml, onde um servidor xml atua como intermediador e                           
...
8 
No presente artigo foi realizada uma pesquisa descritiva com base em um estudo de                           
caso conce...
9 
C. Migrar para ​web os serviços ofertados através de protocolo baseado em SOAP ​(Simple                         
Object...
10 
identificação de candidatos a serviço menos complexo. O sistema proposto para esse estudo                         
de ...
11 
Os dados referentes às interfaces escolhidas do sistema legado estão representadas na                       
figura 2....
12 
 
Figura 3: Servçio IwsConsultaPaginaDocumento e operações.  
Fonte: Elaborado pelo autor (2015) 
 
 
A interface lega...
13 
 
Figura 5: Chamada a interface legada.  
Fonte: Elaborado pelo autor (2015) 
 
Se o método consultarDadosBiblioteca n...
14 
 
Figura 6: Transformação dos dados em XML. 
Fonte: Elaborado pelo autor (2015) 
 
O resultado do código da Figura 6 é...
15 
temos um ​webservice ​operacional. Uma visão geral da ferramenta para construção de                       
webservice ...
16 
alcançado. Na seção 4.4 será trabalhado a integração deste novo serviço a um barramento de                            ...
17 
 
Figura 9: visão geral dos ​endpoints ​adicionados ao Mule ESB. 
Fonte: Elaborado pelo autor (2015) 
 
O primeiro ​en...
18 
 
Uma vez que resposta do ​webservice ​está no formato XML, faz­se necessário                       
convertê­la para ...
19 
 
5. RESULTADOS 
Finalizada a etapa de ligação do ​webservice ao barramento de serviços, efetuou­se a                 ...
20 
 
Figura 12: Imagem da página do livro. 
Fonte: Elaborado pelo autor (2015) 
 
Esta prova de conceito buscou demonstra...
21 
tendo uma visão clara de custos que este sistema produz com o passar do tempo e quais as                              ...
22 
7. REFERÊNCIAS BIBLIOGRÁFICAS 
 
BHATTACHARYA, Shantanu. ​Integrate legacy systems into your SOA initiative: ​Convert ...
23 
LEHMAN, M M. et al. ​Metrics and Laws of Software Evolution: ​The Nineties View. Ieee 
Computer Society, Washington, S...
24 
 
 
 
Próximos SlideShares
Carregando em…5
×

MODERNIZAÇÃO DE SISTEMAS LEGADOS: um estudo de caso sobre integração de sistema legado Delphi/DCOM com barramento de serviços corporativos

370 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
370
No SlideShare
0
A partir de incorporações
0
Número de incorporações
9
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

MODERNIZAÇÃO DE SISTEMAS LEGADOS: um estudo de caso sobre integração de sistema legado Delphi/DCOM com barramento de serviços corporativos

  1. 1. MODERNIZAÇÃO DE SISTEMAS LEGADOS: um estudo de caso sobre  integração de sistema legado Delphi/DCOM com barramento de serviços  corporativos    Paulo Leonardo Vieira Rodrigues  1 Fabrício Martins  2     RESUMO  Este artigo tem como objetivo fornecer uma visão geral a respeito de sistemas legados, das                              técnicas e tecnologias que auxiliam e proporcionam a modernização de tais sistemas, e as                            justificativas do ponto de vista do negócio para que tal modernização seja executada. As                            técnicas de modernização denominadas ​white­box e ​black­box ​são aqui apresentadas e                      discutidas. Essa modernização é orientada por princípios SOA (​Service­Oriented                  Architecture​) e suas tecnologias habilitadoras. Este trabalho empregou a modalidade de                      estudo de caso, onde um sistema em três camadas desenvolvido em Delphi 5 com tecnologia                              DCOM (​Distributed Component Object Model​) é integrado a um barramento de serviços                        corporativo por meio da técnica ​black­box ​e do uso da metodologia de empacotamento ou                            wrapping​. O barramento de serviços utilizado neste estudo de caso foi o ESB (​Enterprise                            Service Bus​) Mule. Algumas funcionalidades do sistema legado foram empacotadas e                      disponibilizadas através de um serviço SOAP (​Simple Object Access Protocol​), que resultou                        em uma interface com possibilidade de integração a um barramento de serviços.     Palavras­chave​: Sistemas legados. Modernização. SOA. Black­box. Mule. Delphi.    ABSTRACT  This article aims to provide an overview about legacy systems, techniques, and technologies                          that assists and provides the modernization of legacy systems, and the justifications from the                            business viewpoint for this modernization be performed. The modernization techniques called                      white­box and black­box are shown and discussed. Such modernization is guided by                        principles of SOA (Service­Oriented Architecture) and its enabling technologies. This paper                      is a case study, where a system of three layers developed in Delphi 5 with DCOM                                (Distributed Component Object Model​) ​technology is integrated into a bus corporate services                        through the black­box technique and the use of packaging or wrapping methodology. The bus                            services used in this case study was the Mule ESB. Some features of legacy system were                                packaged and made available through a SOAP (Simple Object Access Protocol​) service,                        which resulted in an interface with the possibility of integrating a bus service.    Keywords​: Legacy systems. Modernization. SOA. Black­box. Mule. Delphi.          1 ​Aluno do curso de M.B.A. (​Master of Business Administration​) em Arquitetura de Software pelo Instituto de                                  Gestão em Tecnologia da Informação. Graduado em Sistemas de Energia pelo Instituto Federal de Santa                              Catarina.  2 Doutor em Ciência da Informação pela UFMG, professor orientador e de pós­graduação no Instituto de Gestão                                  em Tecnologia da Informação.  
  2. 2. 2        1. INTRODUÇÃO  Um sistema computacional ​deve estar alinhado com os requisitos de negócio e                        manter­se tecnologicamente atualizado. Mas isso pode ser uma tarefa árdua, já que requisitos                          de negócios mudam e a própria tecnologia evoluí, podendo tornar o sistema legado ou                            obsoleto até mesmo a partir da entrada em ambiente de produção.  Apesar de quase sempre existir razões para que estes sistemas continuem em                        funcionamento, seja do ponto de vista do negócio ou do ponto de vista técnico, com o passar                                  do tempo eles inevitavelmente terão de se integrar a novas tecnologias ou a novos requisitos                              de negócio e, se nesse momento houver dificuldade ou custos elevados, pode significar que é                              o momento de se pensar em modernização.   Muitas vezes os sistemas legados não podem ser substituídos no curto e médio prazo,                            é uma tarefa difícil saber em que ponto isto deverá acontecer, sendo mais árdua ainda a tarefa                                  de garantir que a substituição não irá impactar negativamente na organização. Neste ponto                          surge a pergunta: como estender o ciclo de vida de um sistema legado a partir de técnicas de                                    modernização?  Este trabalho propõe­se a responder este questionamento, uma vez que a elaboração                          desde estudo objetiva demonstrar algumas técnicas de modernização de sistemas legados e                        expor uma forma de encapsulamento da aplicação legada, que poderá fornecer uma acréscimo                          no tempo de vida do sistema legado e, ao mesmo tempo, a possibilidade de integração com                                novas tecnologias e incorporação de novos requisitos de negócio.  Para este fim, o artigo será focado especificamente nos seguintes objetivos:  ● Utilizar o método ​wrapping para encapsular as interfaces do sistema legado através da                          técnica ​black­box ​;  ● Demonstrar a possibilidade de integração para um sistema legado, desenvolvido em                      Delphi com tecnologias de 3 camadas através de DCOM a sistemas com interfaces                          baseadas em WSDL e comunicação SOAP;  ● Integrar o sistema legado à um barramento de serviço corporativo, e por consequência,                          atender a um nível mínimo de princípios SOA.      
  3. 3. 3  Este trabalho apresenta­se dividido em seis seções, descritas a seguir. Na seção 2                          expõe­se a teoria por traz da modernização de sistemas legados, já na seção 3 são                              apresentadas as bases metodológicas. Na seção 4 é apresentado o estudo de caso alvo do                              trabalho. Na seção 5 são apresentados os resultados obtidos com a sugestão do estudo de caso                                da seção 4, e por fim, na seção 6 são apresentadas as considerações finais.     2. REFERENCIAL TEÓRICO  2.1 ­ Sistemas Legados e a Modernização   Mudanças fazem parte da vida de muitos sistemas, já que as necessidades da                          organização podem mudar durante o tempo de vida do sistema, ​bugs são corrigidos e algumas                              vezes os sistemas ainda tem que se adaptar a novos ambientes (SOMMERVILLE, 2011).    Para Seacord (2003), um sistema se torna legado quando ele começa a mostrar forte                            resistência à mudança ou à evolução. Já ​Sommerville (2011, p. 245, tradução nossa) define                            sistema legado como: "Sistemas legados são sistemas antigos que continuam úteis e podem                          ser críticos para o funcionamento do negócio. Foram criados em tecnologia antiga e que                            possuem alto custo de manutenção".   Manter sistemas legados em uso evitam impactos negativos que a sua substituição                        poderia trazer, no entanto, as alterações no sistema legado ficam mais caras conforme o                            sistema envelhece, e em particular, alterações em sistemas com alguns anos tendem a ser mais                              caras  (SOMMERVILLE, 2011).   As razões para este encarecimento são várias:   ● sistema construído em linguagem antiga que exige profissionais mais caros;   ● documentação inadequada ou desatualizada que exige mais tempo para entendimento;    ● muitos anos de manutenção que acabaram por corromper a estrutura do sistema,                        fazendo ele incrivelmente difícil de ser entendido;   ● partes diferentes implementadas por equipes diferentes que não possuíam o mesmo                      estilo de programação;   ● as regras não estão documentadas e não são conhecidas pela equipe de manutenção,                          sendo necessário avaliar a regra a partir do código fonte.  Logo, é necessário ter ferramentas que permitam gerenciar as mudanças, ou seja,                        assegurar que a evolução do sistema seja um processo gerido e que seja dada prioridade às                                   
  4. 4. 4  mudanças mais urgentes e eficazes em termos de custos (SOMMERVILLE, 2011). Assim a                          evolução de um sistema cobre uma ampla gama de atividades de desenvolvimento, que pode                            ir desde a adição de uma linha de código até uma completa reimplementação do sistema. Para                                Weiderman (1997), a atividade de evolução de um sistema pode ser divida em três categorias:                              manutenção, modernização e substituição. De acordo com Seacord (2003):    ● Manutenção é um processo incremental e iterativo onde pequenas alterações são                      efetuadas, como a correção de problemas, e nunca devem envolver alterações na                        estrutura do sistema.  ● Modernização incluí mudanças que podem alterar partes da estrutura do sistema ou                        estender certas funcionalidades, atendendo a novos requisitos do negócio e geralmente                      envolve alterações maiores do que as de manutenção, mas conserva significativamente                      as partes do sistema.  ● Substituição requer uma reconstrução total do sistema e isso pode ser alcançado                        através de duas abordagens: de maneira incremental, utilizando o método de ​wrapping                        ou através da abordagem "big­bang", onde o sistema é totalmente substituído por um                          novo.    A Figura 1 ilustra o momento em que as atividades de manutenção, modernização e                            substituição são aplicadas no ciclo de vida dos sistemas.     Figura 1: Ciclo de vida de um sistema de informação.   Fonte: ​Comella­Dorda (2000a)     
  5. 5. 5    De acordo com a primeira lei de Lehman (1997), um sistema deve ser continuamente                            adaptado ou ele se tornará progressivamente menos satisfatório. E essa adaptação poderá ser                          alcançada através de sua manutenção e modernização. Geralmente é a modernização que                        possibilita estender o tempo de vida de um sistema, uma vez que ela permite que novos                                requisitos de negócio sejam adicionados ao sistema legado. Essa modernização pode ser                        classificada em duas categorias diferentes de acordo com o nível de compreensão requirido do                            sistema: modernização ​black­box​ e modernização ​white­box ​(SEACORD, 2003)​.   A modenização ​black­box ​tem como pré­requisito o conhecimento das entradas e                      saídas do sistema legado, ou seja, requer o conhecimento comportamental dos sistemas,                        necessitando que sejam conhecidas suas interfaces. Esse tipo de modernização                    frequentemente utiliza o método do empacotamento ou ​wrapping​.  O método de empacotamento consiste basicamente em empacotar o sistema legado em                        uma camada que esconde a complexidade não requerida do sistema legado, expondo uma                          nova e moderna interface (SEACORD, 2003). Neste tipo de abordagem somente as interfaces                          do sistema legados necessitam ser conhecidas, não sendo preciso conhecer o código interno                          do sistema. Essa técnica permite o reaproveitamento do sistema legado da forma em que está,                              sem inserir novas alterações no seu código, o que permite que a integração seja feita com                                menos esforço e custos.   Segundo Harry (2000), o empacotamento pode ser feito em diferentes níveis de acordo                          com o que se deseja acessar no sistema legado: nível de processo, nível transacional, nível de                                programa, nível de modulo e nível procedural, sendo este último considerado a forma mais                            simples de empacotamento, mas também a mais desafiadora, uma vez que cada procedimento                          no sistema legado passa a se comportar como se fosse um modulo distinto do sistema legado.  Este tipo de modernização possui o ponto negativo de abrir mão do entendimento do                            código interno do sistema, como seria possível na modernização ​white­box, o que poderia                          causar enganos.  A modernização ​white­box é mais extensiva e complexa do que a abordagem                        black­box​. Essa abordagem tem como requisito o entendimento interno do sistema legado e                          propõe uma engenharia reversa do sistema para entender seu funcionamento. Para Chikofsky                        (1990, p. 15, tradução nossa), a reengenharia do sistema legado é definida como "examinar e                                 
  6. 6. 6  alterar o sistema legado para reconstituí­lo em um novo formato e a subsequente                          implementação deste novo formato".   Basicamente, os principais desafios que promovem a reengenharia de um sistema                        legado são: o sistema é monolítico e deve ser divido em partes para serem comercializadas ou                                combinadas de formas diferentes; melhorar a manutenção e a portabilidade; aumentar a                        eficiência; migrar para outra plataforma; adotar novas tecnologias.  A técnica de reengenharia pode ser divida, segundo Demeyer (2009), em três fases:   ● forward engineering​, que é o processo de partir do alto nível de abstração e lógica,                              criando desenhos independentes, até a implementação física do sistema;   ● engenharia reversa, que é a reconstrução de alto nível de modelos e artefatos a partir                              do código fonte até alcançar o entendimento do sistema. A engenharia reversa também                          produz uma redocumentação do sistema;   ● reengenharia, que nesse contexto representa uma transformação de baixo nível em                      outra representação de baixo nível estruturada mantendo o mesmo nível relativo de                        abstração e o mesmo comportamento externo do sistema. Um exemplo comum seria                        um comportamento do sistema cujo código responsável é ruim, comumente conhecido                      por código "​spaghetti​" e é feita uma refatoração neste código, mantendo o                        comportamento externo, mas alterando o código para uma estrutura melhor definida.  Embora tanto a abordagem ​white­box quanto a ​black­box permitam o uso de                          encapsulamento ou ​wrapping​, o método é comumente associado como uma técnica da                        abordagem ​black­box​, porém nem sempre é possível empregar tal técnica sem algum nível de                            reengenharia no sistema legado e análise do código para entender a relação entre as interfaces                              do sistema.    2.2 ­ Técnicas de Modernização  Para Comella­Dorda (2000b), um sistema legado pode ser modernizado no nível                      funcional (lógico), no nível de dados, ou no nível de interface de usuário, e para cada um                                  destes níveis, técnicas diferentes devem ser aplicadas.   Dentre as técnicas mais comuns de modernização, pode­se destacar a técnica ​screen                        scrapping​, ​que é utilizada para empacotar as interfaces de usuário e fornecer uma nova                            interface, como por exemplo, interface texto para interface gráfica, ou interface gráfica para                             
  7. 7. 7  interface web; ​data modernization ​com xml, onde um servidor xml atua como intermediador e                            tradutor entre o repositório de dados legados e um consumidor deste xml; e técnicas de                              modernização funcional ou lógica do sistema. Estas, por sua vez, podem ser implementadas                          através do encapsulamento orientado a objetos e o encapsulamento orientado a componentes.  Temos também a modernização através da integração SOA (​Service­oriented                  architecture​), onde a lógica e os dados do sistemas legados são expostos na forma de                              webservices e posteriormente registrados em um sistema de gerenciamento de serviços SOA                        (MALINOVA, 2010). Este tipo de modernização pode ser combinado com as técnicas                        reengenharia ou de empacotamento, de acordo com a necessidade ou não de alteração no                            sistema legado. ​Webservices ​baseados em SOA tendem a ser interoperáveis, reusável e                        flexíveis.    2.3 ­ Barramento de Serviços  O barramento de serviços é considerado o coração da infraestrutura orientada a                        serviços, uma vez que, segundo Markus (2009), “ele oferece as capacidades que permitem                          criar ambientes distribuídos desacoplados”. Para que um ambiente SOA seja efetivo, é                        necessário que haja um canal comum onde os serviços possam se comunicar. Uma das formas                              de atender este requisito é através do uso do ​Enterprise Service Bus ​ou ESB.  No mercado há uma variedade de sistemas que se propoem a desempenhar este papel e                              são fornecidos por diferentes empresas, no entanto, para que sejam considerados um ESB,                          deve­se atentar ao mínimo de recursos que tais sistemas devem disponibilizar, como recursos                          de conectividade, transformação, roteamento, tratamento de exceções e monitoramento                  (MARKUS, 2009). Nesse sentido, a empresa MuleSoft disponibiliza o sistema ESB chamado                        MuleESB, que por possuir uma versão gratuita e que atende aos recursos mínimos                          necessários, será considerado para o estudo de caso proposto.    3. METODOLOGIA  Para Prodanov (2013, p. 14) a "metodologia é a aplicação de procedimentos e técnicas                            que devem ser observados para construção do conhecimento, com o propósito de comprovar                          sua validade e utilidade nos diversos âmbitos da sociedade".      
  8. 8. 8  No presente artigo foi realizada uma pesquisa descritiva com base em um estudo de                            caso concebido pelo autor, com o propósito de responder ao problema de pesquisa deste                            trabalho.  Ainda de acordo Prodanov (2013) a abordagem do problema é qualitativa, pois os                          dados coletados foram analisados pelo método indutivo e não são empregados métodos e                          técnicas estatísticas. O objetivo caracteriza­se por pesquisa exploratória, pois visa                    proporcionar mais informações sobre o assunto investigado, envolve levantamentos                  bibliográficos, assim é possível explicar melhor as características do trabalho. Como                      procedimento técnico foi utilizada a pesquisa bibliográfica no qual a coleta de dados foi                            elaborada através de fontes bibliográficas como livros, artigos científicos e revistas.    4. ESTUDO DE CASO  O estudo de caso proposto neste trabalho tem como base um sistema legado                          desenvolvido em linguagem e tecnologia antiga, este sistema é implementado em Delphi 5,                          utilizando arquitetura de três camadas com tecnologia DCOM. O sistema legado com essas                          características foi escolhido para este estudo de caso em função da proximidade do autor deste                              trabalho com um caso real, análogo ao aqui proposto.  Pretende­se demonstrar como os dados e lógica de um sistema legado podem ser                          reaproveitados, nesse caso, apenas a camada de lógica e dados serão tratadas, ignorando a                            camada de interface com o usuário, o que segundo Comella­Dorda (2000b) pode ser                          classificado como modernização funcional, uma vez que em contraste com a modernização de                          dados, a modernização funcional (ou lógica) engloba além dos dados, também o                        encapsulamento da lógica embutida no sistema legado.  Zou (2005) propõe alguns passos para migração de serviços DCOM para Webservices:  A. Identificar os componentes legados, onde os componentes do sistema monolítico são                      identificados e recuperá­los conforme a especificação de requisitos do usuário;  B. Migrar os componentes identificados para uma plataforma orientadas a objetos, ou                      seja, migrar os componentes recuperados para coleções de classes que encapsularão                      funcionalidades específicas do sistema legado e que poderão ser oferecidos como                      serviços, utilizando XML para especificar tais serviços;     
  9. 9. 9  C. Migrar para ​web os serviços ofertados através de protocolo baseado em SOAP ​(Simple                          Object Access Protocol​) que permitirá que tais serviços sejam consumidos em                      ambientes baseados em ​Webservices.    Segundo Malinova (2010), ao optar pela modernização através de SOA, algumas                      atividades estratégicas devem ser discutidas, tais como:  A. Identificar os candidatos a serviços: o que podemos definir como serviço e                        quais serviços trazem o maior valor para o negócio, com o menor custo;  B. Salvar o código legado: identificar códigos legados que são importantes e                      reusáveis, extraí­los e reconstruí­los em módulos separados com sua própria                    interface;  C. Empacotamento ou encapsulamento do código salvo e modularizado para que                    ao fim seja possível publicar suas interfaces através de ​Web Services                      Description Languages (WSDL);.  D. Ligar o serviços criados às ferramentas de ​Business Process.    Nesse estudo de caso, foram considerados os procedimentos A, B e C propostos por                            Zou (2005). Os procedimentos propostos por Malinova (2010) também foram considerados,                      no entanto, o passo D nesse artigo limita­se à integração do sistema ao barramento de                              serviços, não havendo integração com um módulo de ​Business Process ou BPEL. O                          barramento de serviços escolhido para esse estudo de caso é Mule ESB.    4.1 ­ Identificação dos Candidatos a serviços  Um componente de software pode ser considerado, de acordo com Zou (2005), “um                          pacote que pode ser entregue de forma independente e que oferece serviços através de                            interfaces públicas” (2010, p. 12, apud Brown & Barn, 1999, tradução nossa). Desta forma, as                              funcionalidades legadas devem ser transformadas em um pacote que ofereça funcionalidades                      facilmente integráveis com softwares existentes ou COTS (​Commercial Off­The­Shelf​).  O sistema legado aqui proposto possui arquitetura tipo três camadas, ou seja, possuí a                            camada de apresentação, de lógica e de dados separadas uma da outra. Por seguir esse modelo                                arquitetural, a lógica de negócio já está relativamente isolada, tornando o trabalho de                             
  10. 10. 10  identificação de candidatos a serviço menos complexo. O sistema proposto para esse estudo                          de caso tem como objetivo realizar o controle de livros, permitindo que os usuários salvem e                                recuperem seus livros, e também que tais livros sejam agrupados em coleções.  Especificamente para esse estudo, optou­se por trabalhar com apenas duas interfaces                      públicas do sistema legado, que atendem a um processo de negócio cujo objetivo é                            disponibilizar os livros e páginas para o usuário. A primeira interface pública disponibiliza                          uma lista de livros com suas páginas, através de identificador do livro e o identificador de                                cada página, e tem como parâmetro de entrada o identificador da biblioteca do usuário. A                              segunda interface pública disponibiliza a página em si, através de documento binário no                          formato PDF e tem como parâmetro de entrada o identificador da página e o identificador do                                livro.  Apesar do sistema legado utilizar­se da arquitetura N­camadas e possuir interfaces                      públicas, ele foi construído como se fosse uma grande aplicação monolítica onde todas as                            interfaces públicas estão compiladas em um mesmo executável, não sendo possível a                        distribuição destes serviços de forma separada.  Uma possível solução no campo da reengenharia seria aplicar técnicas de análise para                          identificação dos componentes neste sistema monolítico, com foco no agrupamento e                      decomposição de funcionalidades, baseado em coesão e acoplamento dos serviços entre si, o                          que produziria subsistemas. No entanto, não há garantias que estes subsistemas seriam os                          melhores candidatos a se tornarem softwares distribuídos. A razão é simples: o agrupamento                          depende fortemente de recursos estáticos do código (acoplamento e coesão), em oposição a                          requisitos dinâmicos que são impostos pela nova arquitetura distribuída (Zou, 2010).   Ainda para Zou “é particularmente difícil recuperar apenas através de agrupamento                      componentes com interfaces claras e dependências mínimas com o resto do sistema. Isto se                            deve aos efeitos colaterais provocados pelas modificações incorridas pela manutenção                    prolongada do código legado” (2010, tradução nossa).  Sendo assim, outra alternativa seria não alterar o sistema legado, não executando                        qualquer tipo de reengenharia, e ao invés disto, criar encapsulamentos das interfaces legadas                          de tal forma que se tornem componentes candidatos a serviços. Isto pode ser alcançando                            através do ​wrapping ​como uma técnica ​black­box.        
  11. 11. 11  Os dados referentes às interfaces escolhidas do sistema legado estão representadas na                        figura 2.    Figura 2: Interfaces do sistema legado.   Fonte: ​Elaborado pelo autor (2015)    4.2 ­ Isolamento do Código Legado ­ ​Wrapping  O encapsulamento ou empacotamento das interfaces do código legado em uma nova                        camada permite que toda a complexidade interna deste sistema seja escondida, uma vez que o                              ponto de acesso será substituído por interfaces mais modernas, como uma nova interface                          WSDL, facilitando o acesso por outros softwares e ao mesmo tempo atendando ao princípio                            SOA da interoperabilidade.   Para este propósito foi desenvolvido em Delphi XE 3 uma camada intermediaria que                          será responsável por disponibilizar o serviço de consulta de páginas, através de um WSDL                            específico e por disponibilizar os dados legados através de XML, utilizando comunicação                        SOAP. Optou­se por criar um único serviço para encapsular as duas interfaces.   O funcionamento é simples: um sistema consumidor faz a requisição ao serviço                        passando os dados necessários de acordo com o definido no WSDL. O serviço executa a                              chamada do método legado que encapsulou, recebe os dados de retorno do sistema legado e                              faz as transformações necessárias para que seja devolvida uma resposta compatível com a                          definida no seu WSDL. Como o WSDL é extenso, será disponibilizado apenas um resumo                            que pode ser visto na figura 3.       
  12. 12. 12    Figura 3: Servçio IwsConsultaPaginaDocumento e operações.   Fonte: Elaborado pelo autor (2015)      A interface legada é acessada através de chamadas DCOM. Para isto o DelphiXE 3                            fornece a classe TSocketConnection, que, segundo documentação da empresa Embarcadero,                    detentora do Delphi XE 3, é a classe responsável por gerenciar a comunicação, através de                              sockets do windows, à servidores de aplicação usando DCOM (Embarcadero, 2015). A figura                          4 mostra como a conexão é estabelecida com o sistema legado.    Figura 4: Método responsável por estabelecer a conexão com o sistema legado.   Fonte: Elaborado pelo autor (2015)    Estabelecida a classe de conexão, pode­se efetuar a chamada definida pela interface do                          sistema legado, que, em outras palavras significa efetuar a chamada aos procedimentos                        remotos no servidor de aplicação (RPC). Na figura 5 há um exemplo de chamada a interface                                legada consultarDadosBiblioteca.     
  13. 13. 13    Figura 5: Chamada a interface legada.   Fonte: Elaborado pelo autor (2015)    Se o método consultarDadosBiblioteca não for encontrado no servidor de aplicação                      legado, será retornado um erro. Do contrário, os dados de retorno estarão presentes através da                              propriedade data do objeto AData. Os dados retornados são convertidos para XML de acordo                            com o definido no WSDL. O desenvolvimento análogo foi aplicado à interface legada                          selecionarDadosPagina. No entanto, a interface selecionarDadosPagina tem como saída um                    arquivo binário no formato PDF. Para realizar o tratamento, implementou­se no ​wrapper ​a                          conversão deste PDF para PNG, uma vez que o formato PNG envolve menos esforço para ser                                trabalhado. A figura 6 exibe o exemplo de código­fonte responsável por converter os dados de                              retorno do sistema legado em uma estrutura XML.     
  14. 14. 14    Figura 6: Transformação dos dados em XML.  Fonte: Elaborado pelo autor (2015)    O resultado do código da Figura 6 é uma lista XML contendo os dados de cada                                  página, que será visto com mais detalhes na seção 4.4.   Dessa forma, alcançamos um dos objetivos específicos deste trabalho, que era realizar                        o wrapping de partes do sistema legados e disponibilizá­los através de uma nova interface. Na                              seção 4.3 serão discutido os pormenores da arquitetura de serviços.    4.3 ­ Disponibilização de ​Webservices   O Delphi, desde as versões antigas, já disponibilizava recursos para comunicação                      DCOM, e manteve tais recursos na versão XE 3. Nesta versão também disponibiliza toda uma                              camada de componentes para construção de ​webservices​, que facilitou tanto o acesso ao                          sistema legado como a construção de interfaces modernas baseadas em WSDL. Estes foram                          os motivos para construção do ​wrapper ​com essa ferramenta de desenvolvimento.  No que toca ao desenvolvimento do ​webservice​, optou­se pelo uso do SOAP. A                          ferramenta permite construir de forma muito rápida um ​webservice ​baseado em SOAP. Basta                          selecionar no menu de opções de criação de aplicativos e preencher alguns dados básicos e                                 
  15. 15. 15  temos um ​webservice ​operacional. Uma visão geral da ferramenta para construção de                        webservice ​ pode ser vista na figura 7.      Figura 7: Criação de ​webservice ​SOAP a partir do Delphi XE 3  Fonte: Elaborado pelo autor (2015)    Cada serviço deverá ser definido como uma interface do tipo "IInvokable"                      (Embarcadero, 2015). As operações de cada serviço devem ser definidas nessa nova interface.                          Para este estudo de caso, foi definida a interface "IwsConsultaPaginaDocumento" e dois                        métodos, "ConsultarPagina" e "ConsultarIndicePaginas", que representam as operações                disponíveis para o serviço. Quando a aplicação é compilada, o Delphi trata de gerar o WSDL                                e toda a infraestrutura necessária para comunicação SOAP de acordo com a definição da                            interface criada. A figura 8 mostra o código­fonte da interface definida para o serviço                            "IwsConsultaPaginaDocumento".  Concluída esta etapa, obteve­se as interfaces legadas encapsuladas através do serviço                      "IwsConsultaPaginaDocumento", a serem acessadas através das operações "ConsultarPagina"                e "ConsultarIndicePaginas" por qualquer consumidor que se comunique através de SOAP.   Assim, acredita­se que o objetivo especifico de demonstrar a possibilidade de                      integração de um sistema legado desenvolvido em Delphi 5 com tecnologias de três camadas                            através de DCOM, à sistemas que utilizem interfaces modernas baseadas em SOAP foi                             
  16. 16. 16  alcançado. Na seção 4.4 será trabalhado a integração deste novo serviço a um barramento de                              serviços com a intenção de disponibilizar os dados legados para acesso ​web​.    .   Figura 8: Interface para geração do WSDL.  Fonte: Elaborado pelo autor (2015)    4.4 ­ Ligação do ​Webservice ​ao Barramento de Serviços  Nas seção 4.2 foi implementada uma forma de encapsulamento para algumas das                        interfaces públicas do sistema legado e na seção 4.3 este encapsulamento foi transformado em                            webservices ​e disponibilizado em uma interface moderna. Nesta seção será visto como este                          serviço pode ser aproveitado por outros sistemas.   Pretende­se realizar a comunicação do serviço "IwsConsultaPaginaDocumento" com o                  barramento de serviços Mule ESB para que os dados disponibilizados pelo serviço sejam                          acessados através deu um navegador ​web. Para isso, criou­se dois ​endpoints ​no barramento de                            serviços, referentes às operações "ConsultarPagina" e "ConsultaIndicePaginas". A visão geral                    de cada um deles pode ser vista na figura 9.     
  17. 17. 17    Figura 9: visão geral dos ​endpoints ​adicionados ao Mule ESB.  Fonte: Elaborado pelo autor (2015)    O primeiro ​endpoint​, nomeado de wsConsultaIndicePagina, é acessado através da url                      http://localhost:8081/consultaIndicePaginas?biblioteca=123​, onde 123 é código da biblioteca.              Ao receber esta chamada, o Mule filtra os parâmetros recebidos via GET e o código da                                biblioteca é armazenado em uma variável. No passo seguinte constrói­se o XML a ser enviado                              como requisição SOAP ao ​webservice. ​Esse XML contem o código da biblioteca. E então,                            executa­se a chamada ao ​webservice​, que retornará um XML com a lista de páginas  O XML retornado pelo ​webservice esta no formato exibido na figura 10. O atributo                            requestID é a expressão "cdLivro;cdPágina", em formato base64.    Figura 10: XML retornado pelo webservice.  Fonte: Elaborado pelo autor (2015)     
  18. 18. 18    Uma vez que resposta do ​webservice ​está no formato XML, faz­se necessário                        convertê­la para o formato JSON e devolvê­la ao navegador ​web​. ​O resultado da conversão                            está na figura 11.    Figura 11: XML convertido em JSON.  Fonte: Elaborado pelo autor (2015)    Optou­se por uma resposta no formato de lista para facilitar a implementação ​web​,                          uma vez que a lista de endereços pode ser percorrida e acessada diretamente por funções em                                javascript​.  O segundo ​endpoint​, nomeado wsConsultaPagina é acessado através do endereço                    http://localhost:8081/consultaPagina?request=MTUwOzE=​, onde o parâmetro ​request indica            o código do livro e a página, e está em formato base64. A saída deste ​endpoint ​é um arquivo                                      PNG que contém a página de um livro. Os passos executados por este ​endpoint ​são                              semelhantes ao do ​endpoint ​"wsConsultaIndicePagina", com adição de um enriquecedor de                      mensagem, com o objetivo de converter o arquivo binário presente no XML que está em                              base64, para o formato binário a ser devolvido ao navegador ​web​.     
  19. 19. 19    5. RESULTADOS  Finalizada a etapa de ligação do ​webservice ao barramento de serviços, efetuou­se a                          etapa de verificação do funcionamento. Para isto foi necessário a construção de uma aplicação                            cliente para simular o consumo dos ​endpoints ​do barramento de serviços. Uma página ​web ​foi                              construída para esse propósito, onde o valor de entrada de dados corresponde ao número da                              biblioteca, conforme pode ser visualizado na figura 12.    Figura 12: Página ​web​ para entrada de dados da biblioteca.  Fonte: Elaborado pelo autor (2015)    Nesta primeira etapa realizou­se a requisição ao endereço do ​endpoint de consulta de                           índices de páginas, tendo como retorno uma lista de páginas no formato JSON com a                              referência para cada página de cada livro.  A página ​web possui uma função ​javascript embutida que, para cada item da lista de                               páginas de livro, constrói uma visualização da página do livro com miniaturas das páginas                            seguintes ao rodapé. Para cada página da lista é realizada uma requisição ao ​endpoint                            wsConsultaPagina, inclusive para as miniaturas, com o objetivo de buscar a imagem da                          página do livro. O resultado pode ser visualizado na figura 13.     
  20. 20. 20    Figura 12: Imagem da página do livro.  Fonte: Elaborado pelo autor (2015)    Esta prova de conceito buscou demonstrar a aplicação dos assuntos discutidos neste                        estudo de caso. Como pode ser observado, os dados do sistema legado, antes totalmente                            isolados, passo a passo tornam­se disponíveis para acesso através de um navegador ​web​.                          Juntamente com as etapas de modernização, ao optar­se pelo uso do barramento de serviços                            consegui­se alcançar o acesso aos dados fornecidos pelo sistema legado, bem como aproveitar                          a sua lógica de negócios.    6. CONCLUSÃO  Uma vez criado o sistema, seja qual for, a tendência é que com o passar do tempo ele                                    torne­se obsoleto devido novas tecnologias e necessidades de negócio que se apresentam                        diariamente. Sendo assim, sistemas legados sempre existirão. Logo, o ponto ser levado em                          consideração é a forma de tratar esse legado, pois estes sistemas podem se tornar um                              problema, uma vez que empresas e organizações necessitam ter o gerenciamento do legado,                             
  21. 21. 21  tendo uma visão clara de custos que este sistema produz com o passar do tempo e quais as                                    técnicas a serem aplicadas para reduzi­los.   Este artigo teve o objetivo de demonstrar a possibilidade de estender o tempo de vida                              de um sistema legado a partir do uso de técnicas de modernização, como a ​black­box e                                tecnologias que permitissem a acoplagem do sistema legado a sistemas mais modernos. Para                          isso, utilizou­se de técnicas consideradas eficientes para o proposito, como o ​wrapping​.                        Também aplicou­se alguns conceitos previsto em SOA, como distribuição, coesão e                      interoperabilidade, ao encapsular processos do sistema legados em serviços de                    responsabilidades únicas, permitindo que tecnologias habilitadoras de SOA fossem utilizadas,                    como ​webservice ​e barramento de serviços.   Este trabalho limitou­se a modernização funcional (lógica) para aplicativos três                    camadas baseado em DCOM, deixando tópicos como modernização de interfaces de usuários                        ou modernização através de reengenharia, que exigiriam um artigo dedicado para isso, como                          sugestão para trabalhados futuros.  Sendo assim, pode­se concluir que a modernização através ​black­box ​por meio de                        wrapping​, aliada a um ferramental que atenda á princípios SOA, pode ser uma excelente                            alternativa para estender o tempo de vida de um sistema legado desenvolvido em Delphi 5 e                                que empregue DCOM em sua tecnologia. Isto se justifica devido a possibilidade de integração                            com tecnologias e ambientes modernos ao mesmo tempo que preserva o sistema legado                          inalterado, evitando, por exemplo, que sejam introduzidos erros no sistema legado,                      possibilidade real quando utilizada uma modernização ​white­box​.      Como sugestão de trabalho futuros, ainda pode­se estender o estudo relacionado à                        segurança, distribuição e balanceamento do encapsulamento destes sistemas legados, ou                    ainda, a implementação de BPMN (​Business Process Modeling and Notation​) / BPEL                        (Business Process Execution Language)​, ​uma vez que o sistema tenha sido modernizado para                          uma estrutura de serviços, algo que é viável ao ter o serviço acoplado a um barramento de                                  serviços.             
  22. 22. 22  7. REFERÊNCIAS BIBLIOGRÁFICAS    BHATTACHARYA, Shantanu. ​Integrate legacy systems into your SOA initiative: ​Convert  legacy applications into SOA­based applications. 2007. Disponível em:  <​http://www.ibm.com/developerworks/library/ws­soa­legacyapps/​>. Acesso em: 23 dez.  2015.    CHIKOFSKY, E.j.; CROSS, J.h.. Reverse engineering and design recovery: a taxonomy. ​Ieee  Softw., ​[s.l.], v. 7, n. 1, p.13­17, jan. 1990. Institute of Electrical & Electronics Engineers  (IEEE). DOI: 10.1109/52.43044.    COMELLA­DORDA, Santiago et al. ​A Survey of Legacy System Modernization  Approaches. ​Pittsburgh: Carnegie Mellon University, 2000.    COMELLA­DORDA; WALLNAU; SEACORD. A survey of black­box modernization  approaches for information systems. ​Proceedings International Conference On Software  Maintenance Icsm­94, ​[s.l.], p.173­183, 2000. Institute of Electrical & Electronics Engineers  (IEEE). DOI: 10.1109/icsm.2000.883039.    DEMEYER, Serge; DUCASSE, Stéphane; NIERSTRASZ, Oscar. ​Object­Oriented  Reengineering Patterns. ​Switzerland: Square Bracket Associates, 2009.    EMBARCADERO (Org.). ​Rad Studio Api Documentation:  Datasnap.Win.SConnect.TSocketConnection. Disponível em:  <​http://docwiki.embarcadero.com/Libraries/XE7/en/Datasnap.Win.SConnect.TSocketConnec tion​>. Acesso em: 27 dez. 2015.    HARRY M. SNEED, 9., 2000, Bavaria, Germany. ​Encapsulation of legacy software: ​A  technique for reusing legacy software components. Bavaria, Germany: Ieee Press, 2000. 10 p.       
  23. 23. 23  LEHMAN, M M. et al. ​Metrics and Laws of Software Evolution: ​The Nineties View. Ieee  Computer Society, Washington, Sc: Metrics '97 Proceedings Of The 4th International  Symposium On Software Metrics, 1997.    MALINOVA, Anna. APPROACHES AND TECHNIQUES FOR LEGACY SOFTWARE  MODERNIZATION. ​Bulgaria Scientific Works, ​Bulgaria, v. 37, n. 3, p.77­85, set. 2010.    MARKUS CHRISTEN. Microsoft Brasil. ​Conhecendo melhor as Capacidades do  Enterprise Service Bus. ​2009. Disponível em:  <https://msdn.microsoft.com/pt­br/library/dd920288.aspx>. Acesso em: 04 dez. 2015.    OTANI, Nilo; FIALHO, Francisco Antonio Pereira. ​TCC: ​Métodos e Técnicas. 2. ed.  Florianópolis: Visual Books, 2011. 160 p.    PRODANOV, Cleber Cristiano; FREITAS, Ernani Cesar de. ​Metodologia do Trabalho  Científico: ​Métodos e Técnicas da Pesquisa e do Trabalho Acadêmico. 2. ed. Novo  Hamburgo: Feevale, 2013. 276 p.    SEACORD, Robert C.; PLAKOSH, Daniel; LEWIS, Grace A.. ​Modernizing Legacy  Systems: ​Software Technologies, Engineering Processes, and Business Practices. Michigan:  Addison­wesley, 2003. 332 p.    SOMMERVILLE, Ian. ​Software Engineering. ​9. ed. New York: Addison­wesley, 2011. 773  p.    WEIDERMAN, Nelson H. et al. ​Approaches to Legacy System Evolution. ​Pittsburgh, Pa:  Software Engineering Institute, Carnegie Mellon University, 1997.    ZOU, Ying; KONTOGIANNIS, Kostas. Reengineering Legacy Systems Towards Web  Environments. ​Managing Corporate Information Systems Evolution And Maintenance,  [s.l.], p.138­166, 2005. IGI Global. DOI: 10.4018/978­1­59140­366­1.ch006.     
  24. 24. 24       

×