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 1Fabrí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

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étodowrapping 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

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

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 dewrapping

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

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

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

interface web;data modernizationcom 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

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

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

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

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

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

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

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 webservicebaseado em SOAP. Basta

selecionar no menu de opções de criação de aplicativos e preencher alguns dados básicos e

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

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 navegadorweb. Para isso, criou­se doisendpointsno 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

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

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 desteendpointé 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

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 dosendpointsdo barramento de serviços. Uma páginawebfoi

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 doendpoint 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

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

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

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

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