Este documento discute a modernização de sistemas legados através da integração de um sistema desenvolvido em Delphi com DCOM a um barramento de serviços corporativos utilizando a técnica black-box e empacotamento de funcionalidades como serviços SOAP.

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