Towards a Framework for Migrating Web Applications to Web Services

Transcrição

1 Towards a Framework for Migrating Web Applications to Web Services Asil A. Almonies, Manar H. Aleffi, James R. Cordy, Thomas R. Dean CASCON 2011 Apresentado por: Alessandra Levcovitz

2 Introdução Proposta apresentada Estudo de caso Conclusão

3 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

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

5 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

6 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

7 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

8 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 funcionalidades do Moodle

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

10 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.)

11 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 funcionalidade da aplicação

12 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 Provê bindings além de SOAP (REST, JASON)

13 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 identifica uma classe como um web indica qual o binding a usar. Ex.: ws = SOAP

14 Conjunto de funções utilitárias para SCA services Identifica a classe como web service Qual o binding a usar ws = SOAP Instancia uma função de um webservice remoto Figure 2: SCA extension Instancia uma função de uma classe local

15 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

16 Exemplo 1: Login Process Características do login no Moodle Múltiplos plugins para login Manual authentication: contas são criadas pelo administrador 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

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

18 Simplified login code

19 Simplified authencticate.php

20 Manual authentication module

21 Passo 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 para a classe Fez para o método de login A nova classe foi habilitada como um serviço remoto A classe original é substituída por um wrapper

22 Classe nova com anotações SCA Classe = WS Parâmetros do método login

23 Wrapper a classe original é substituída por uma casca faz a chamada remota Instancia o serviço Gera automaticamente a WSDL quando o arquivo php é invocado com o parâmetros wsdl

24 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 Invoca login que faz uma chamada ao serviço remoto

25 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

26 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

27 Valida o arquivo (tipo, malware, etc.). Se válido move para o diretório de destino

28 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 erro.

29

30 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. Trata níveis significativos de automatização.

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

32 Dúvidas

33 ws-soa-scasd SDOs are objects that allow you to easily handle XML data without needing to know from where it came. o/ SDO-for-PHP