Towards a Framework for Migrating
Web Applications to Web Services
Asil A. Almonies, Manar H. Aleffi, James R. Cordy, Thomas R. Dean
CASCON 2011
• Introdução
• Proposta apresentada • Estudo de caso
Introdução
• Migrar aplicações web tradicionais para web
services é um passo para modernização de web-based business systems
• Há carência em propostas de como migrar “web applications” dinâmicas para web
services
• São apresentados requisitos para um processo semi-automático para migrar “dynamic legacy web applications” para web services SOA
• Muitas aplicações web são implementadas usando linguagens de script como PHP e Python
• Estas linguagens são dinamicamente tipadas, reflexivas e permitem mudanças dinâmicas no código.
• As implementações são feitas em paradigmas de programação diferentes.
• Desafios:
– Analisar e refatorar o código legado com o propósito de migrar para SOA
– Identificar, no código legado, serviços que tenham valor para o negócio
• Há necessidade de ferramentas e técnicas para:
– Analisar sistemas web grandes desenvolvidos em linguagens de script
– Identificar a parte do código que implementa lógica de negócio e extrair serviços
– Tratar as características específicas das linguagens de script
Web applications - características
• Conjunto de:
– web pages (.aspx, .jsp, HTML) – Módulos
– Código executável
– Arquivos de imagens – Etc.
• Estão tratando, cada vez mais, processos de negócio mais complexos
Proposta para reestruturar aplicações
Web
• Usar web services e SOA para implementar um conjunto de serviços que tratam os
processos de negócio
• Cada serviço atende uma área de negócio • Serviços de processos de negócio distintos
podem comunicar-se entre si
• Um serviço pode ser usado por mais de um sistema
Contribuições do trabalho
• Explorar as questões a avaliar na migração de aplicações web monolíticas dinâmicas para
SOA para criar futuramente um framework para migração “semi-automática”.
• Fazer uma demonstração manual do uso do processo proposto usando duas
Processo proposto para identificar e
separar serviços
• Objetivos a perseguir na migração de web
applications para web services:
– Plasticidade da “user-interface”: capacidade da interface de se adaptar a mudança mantendo a usabilidade
– Load balancing: distribuir o processamento – Code refactoring
• O processo proposto explora a migração de
aplicações web dinâmicas para SOA com um nível significativo de automação.
Passos do processo proposto
1. Identificar os potenciais “business services” no código legado
2. Separar os serviços da aplicação web usando duas tecnologias:
– Service Component Architecture (SCA)
• Provê uma forma fácil para criar e acessar serviços em PHP
– Service Data Object (SDO)
• Provê uma interface PHP uniforme para tratar diferentes
formas de obtenção dos dados (acesso a BD, parâmetros de web services, etc.)
3. Migrar os serviços “separados” no passo 2 para componentes SOA
• Decidir quais serviços devem ser selecionados é uma grande questão
• Definir critérios para identificar os serviços
relevantes, que fazem sentido migrar para SOA
4. Reintegrar os serviços selecionados na nova aplicação, sem alterar a usabilidade e
PHP SOAP Implementations: SCA
• Algumas extensões para desenvolvimento de web services em PHP
– NuSOAP – PEAR
– SCA (Service Component Architecture) e SDO (Service Data Objects)
• Fácil de instalar, adotar e entender
SCA e SDO
• SCA
– Biblioteca dinâmica que estende o interpretador PHP, composta de um conjunto de funções utilitárias
definidas através de um include em “SCA/SCA.php” – Identifica e realiza as chamadas aos serviços SCA – Pesquisa por “anotações” feitas através de
comentários para identificar uma classe PHP como web services
– @service: identifica uma classe como um web service – @binding indica qual o “binding” a usar. Ex.: ws =
Figure 2: SCA extension Identifica a classe como web service Qual o binding a usar ws = SOAP Conjunto de funções utilitárias para SCA services
Instancia uma função de uma classe local Instancia uma
função de um webservice remoto
Estudo de caso
• Sistema escolhido: Moodle (open source)
– Aplicação web monolítica desenvolvida em PHP
• Passo 1 do processo proposto:
– Analisou o Moodle manualmente, numa avaliação top-down,
– Dividiu funcionalidades em “sub-funcionalidades” – Identificou potenciais serviços independentes
• Funcionalidades escolhidas para o estudo:
– login - migrar para web service
– File upload service – investigar a plasticidade da interface
Exemplo 1: Login Process
• Características do login no Moodle
– Múltiplos plugins para login
• Manual authentication: contas são criadas pelo administrador
• Email authentication: contas são criadas pelos usuários • LDAP authentication
• Nologin
– Factory routine que escolhe o método correto de login baseado em informações de configuração
Manual authentication
Contém todos os tipos de plugins de autenticação (o manual é um deles) Identifica o plugin de autenticação a usar - manual Contém a página de login defaultPasso 2: Login New Service
• Criou uma cópia do código original da “autenticação manual” com um novo nome (file name = class name ) • Adicionou o comando para biblioteca SCA
– include “SCA/SCA.php”;
• Fez anotações @service e @binding.soap para a classe • Fez anotações @param e @return para o método de
login
• A nova classe foi habilitada como um serviço remoto • A classe original é substituída por um “wrapper”
Classe nova com anotações SCA
Classe = WS
Parâmetros do método login
Wrapper – a classe original é
substituída por uma “casca”
Gera automaticamente a WSDL quando o arquivo php é invocado com o parâmetros wsdl
faz a chamada
• Versão PHP do SCA gera automaticamente a WSDL se o arquivo php é invocado
remotamente com o parâmetro wsdl
e.g. http ://hostname/MyService.php?wsdl
• Logo:
– Login/index.php
• Instancia a factory login de authentication.php • A factory instancia a “wrapper class” em
authmanualSOA.php
Exemplo 2: File Handling
Objetivo deste 2º experimento
1. Serviço: Converter a funcionalidade de “file upload” do Moodle em serviço.
2. Plasticidade: Após convertido o serviço, a interface atual “multi-page”pode ser
convertida para uma interface Ajax mais interativa
Características da funcionalidade de
upload
• Vários arquivos
– Principal código do módulo de arquivos =
files/index.php -
– Bibliotecas que implementam o upload de arquivo
• adminlib.php – funções usadas por administrados
• filelib.php e file.php – funções para analisar o conteúdo e
tipo do arquivo
• uploadlib.php – contém a classe que trata da funcionalidade
de upload
• Lógica de apresentação e lógica de
gerenciamento do arquivo estão espalhadas por toda a classe de upload
Valida o arquivo (tipo, malware, etc.).
Se válido move para o diretório de destino
O que foi feito?
• As rotinas de gerenciamento de arquivo da
biblioteca uploadlib.php foram agrupadas numa única classe “UploadService” e convertidas para “local service”
• Exemplo: método movefile da nova classe • Upload manager class foi convertida para
chamar as funções SOA de “UploadService”.
• O agrupamento dos códigos de gerenciamento de arquivo em serviço separou o gerenciamento dos arquivos do gerenciamento das mensagens de
Conclusões
• A proposta apresentada é uma solução nova para o problema de migração de sistemas
legados web dinâmicos para arquitetura orientada a serviço
• É um dos primeiros trabalhos feitos com
migração de aplicações web monolíticas para SOA.
Trabalho futuro
• Expor a funcionalidade de “upload” via protocolo SOAP
• Escolher mais funcionalidades do Moodle a migrar para validar plasticidade e load
balancing
• Automatizar o processo de identificação de serviços usando TXL
• Usar os serviços extraídos em duas aplicações distintas.
• http://www.ibm.com/developerworks/library/ ws-soa-scasd
• SDOs are objects that allow you to easily handle XML data without needing to know from where it came. o/
• http://searchsoa.techtarget.com/tip/SCA-and-SDO-for-PHP
