Página de Dissertação

João Sobreira

IPBrick - API para integração de aplicações “third party”

Problema

Num mundo em que cada vez mais serviços estão disponíveis e a sua complexidade se torna cada vez maior é então necessária e vantajosa a cooperação entre entidades especializadas em áreas distintas. Esta cooperação prevê uma fase de integração, sendo portanto crucial que esta seja célere e eficaz de maneira a tornar o serviço funcional no menor intervalo de tempo possível.

Sendo a IPBrick uma solução tecnológica de prestação de serviços de comunicação e intranet entre outros, é comum o interesse de aplicações de terceiros na utilização destes serviços em funcionalidades disponibilizadas. A falta de ferramentas que permitam entidades externas desenvolveram as suas aplicações independentemente com certeza de compatibilidade com a solução IPBrick leva a uma necessidade de intervenção da equipa de desenvolvimento da IPBrick SA nesta fase de integração.


Objetivos

É a intenção deste projecto a revisão e extensão da API existente no sistema IPBrick no que toca a integração de aplicações “third-party”. Tendo em consideração a existência de uma API elaborada mas não completa, uma revisão ajudará a identificar a base sobre a qual as funcionalidades previstas poderão ser desenvolvidas como extensão da API atual. Atualmente a integração de uma aplicação “third-party” no sistema é feita pela equipa IPBrick isto porque os pacotes precisam de incluir comandos de acesso direto ao sistema. Esta situação levanta dois problemas:

  1. Nenhuma aplicação destinada ao sistema IPBrick pode ser desenvolvida isoladamente por uma entidade externa;
  2. Decorre uma ocupação de recursos por parte da IPBrick no desenvolvimento da integração da aplicação na plataforma.

Surge então a necessidade do desenvolvimento de ferramentas para que entidades externas o possam fazer individualmente com certeza de que existe compatibilidade, comunicação e integração do seu produto e assegurando o acesso seguro e controlado ao sistema.

Planeamento

Relatórios Semanais

Semana 1 - 17 a 23 de Fevereiro

Trabalho Realizado A primeira semana após a entrega do relatório de PDI serviu, como definido no planeamento, para teste das ferramentas e início de teste da solução SOAP. Foi testada a ferramenta SOAP UI como plugin para o IDE Eclipse, juntamente com o plugin de desenvolvimento em PHP, o PDT (PHP Development Tools) e como ferramenta isolada. Foi também testado, mas não finalizado, a solução SOAP para o projeto. Foi utilizada a framework NuSOAP para elaboração do ficheiro de descrição WSDL. Para teste, foram desenvolvidos ficheiros de teste de servidor e cliente, ambos alojados numa máquina IPBRick e a extensão Poster do browser Firefox para envio de pedidos HTTP mais complexos.

Dificuldades Houve algumas dificuldades na configuração do plugin SOAP UI para o Eclipse no que toca ao reconhecimento de projetos. Por essa razão, para testes futuros em que seja necessária a utilização desta ferramenta será usada a externa.

Previsão para a próxima semana Com a finalização do teste à tecnologia SOAP, iniciar-se-ão os testes à tecnologia REST.


Semana 2 - 24 de Fevereiro a 2 de Março

Trabalho Realizado Foram finalizados os testes à tecnologia SOAP e iniciados os testes à tecnologia REST. Para esta última fase, procedeu-se ao estudo do modelo de arquitetura de software MVC de maneira elaborar uma estrutura de camadas funcional e eficaz, quer nas aplicações de teste, quer na aplicação final. No final da semana foi definido então um esboço para a estrutura da API a desenvolver.

Dificuldades Ao iniciar o desenvolvimento da aplicação de teste da tecnologia REST, houve a necessidade de estudar e analizar um esquema adequado para a aplicação. Também surgiu a necessidade de reencaminhar os pedidos HTTP de diferente URIs para um mesmo "ponto de entrada", sendo para tal utilizada uma configuração definida num ficheiro .htaccess.

Previsão para a próxima semana É prevista a elaboração de uma aplicação com um esquema base bastante aproximado ao final, assim como início da integração da API no código do sistema IPBrick.


Semana 3 - 3 a 9 de Março

Trabalho Realizado Após finalizado o teste da tecnologia REST, foi escolhida esta como solução tecnológica para o produto final por razão que serão mencionadas com mais detalhe na dissertação. Foi iniciada então a integração da aplicação desenvolvida no código IPBrick, sendo para tal escolhido o serviço de gestão de utilizadores e contas, pois era a que oferecia mais funcionalidades e uma biblioteca mais adequada.

Dificuldades Houve algumas dificuldades na adaptação e compreensão do código e bases de dados já presentes no sistema IPBrick.

Previsão para a próxima semana É prevista a finalização da integração do serviço de gestão de utilizadores na próxima semana e início da integração de outro serviço.


Semana 4 - 10 a 16 de Março

Trabalho Realizado Foi continuada e terminada a integração do serviço de gestão de utilizadores com a interface previamente desenvolvida, com funcionalidades de adição, modificação, obtenção e remoção de uma conta. Também foi contemplada a adição de funcionalidade para um pedido HTTP OPTIONS para informação sobre as acções possíveis sobre um serviço.

Dificuldades Nada a apontar.

Previsão para a próxima semana Início da integração do serviço de gestão de firewall.


Semana 5 - 17 a 23 de Março

Trabalho Realizado Foi iniciada e continuada a integração do serviço de gestão de regras firewall, com as funcionalidades de adição e remoção de regras. Foi também iniciada a integração do serviço de gestão de Virtual Hosts.

Dificuldades Ao invés da utilização do ficheiro .htaccess no directório para reencaminhamento de pedidos, serão utilizadas as configurações de Virtual Host do sistema IPBrick.

Previsão para a próxima semana Após a finalização da integração do serviço Virtual Host, iniciar-se-à a integração do serviço de gestão de registos DNS.


Semana 6 - 24 a 30 de Março

Trabalho Realizado Foi finalizado o serviço de gestão de Virtual Hosts iniciado na semana anterior e iniciada a criação de um pacote de testes para todas as funcionalidades da API.

Dificuldades Nada a apontar.

Previsão para a próxima semana Para a próxima semana estará previsto a finalização, instalação e teste do pacote de testes que tem vindo a ser criado. Estas funcionalidades serão identificadas como parte de uma versão alpha1 da API.


Semana 7 - 31 de Março a 6 de Abril

Trabalho Realizado O pacote de testes foi criado e testado oficialmente a 4 de Abril, data da versão alpha1, já com formato de template para aplicações futuras.

Dificuldades Foi discutido em reunião com o orientador uma nova estrutura da dissertação e necessidade de elaboração e aprovação de uma análise de requisitos final.

Previsão para a próxima semana Na semana seguinte está previsto o início de integração de novos serviços, neste caso o serviço de gestão de registos DNS.


Semana 8 - 7 a 13 de Abril

Trabalho Realizado Foi inicializado e finalizado o serviço de gestão de registos DNS, abrangendo estes os registos A, PTR, NS, SRV e MX assim como os ficheiros de configuração das zonas. Após finalizado este serviço, foi iniciada a atualização do pacote de testes para uma versão denominada alpha2.

Dificuldades Por necessidade de esclarecimento da utilização dos registos TXT no sistema IPBrick, estes foram adiados para uma posterior atualização.

Previsão para a próxima semana Lançamento da versão alpha2 e teste do novo pacote.


Semana 9 - 14 a 20 de Abril

Trabalho Realizado O novo pacote de testes da versão alpha2 foi então atualizado e testado com versão final a 14 de Abril. Foi inicializada a atualização da estrutura de erros da API para um sistema mais modular e iniciada a implementação do serviço de gestão de rotas SMTP.

Dificuldades Para efetuar o teste dos registos foi necessário, posteriormente, proceder-se a criação manual de uma rota SMTP. Esta necessidade levou à ideia de implementar esta funcionalidade na API em questão.

Previsão para a próxima semana Após finalização do serviço de gestão de rotas SMTP, irá proceder-se à optimização da API com retorno de códigos de erros e códigos HTTP adequeados que irão ajudar nos testes futuros. Também foi discutida e será implementada uma ferramenta que permita o cancelamento de uma instalação a decorrer.


Semana 10 - 21 a 27 de Abril

Trabalho Realizado De maneira a ser possível cancelar uma instalação foi implementada uma ferramenta que permita automaticamente apagar elementos criados pela aplicação. O registo de acessos e erros em ficheiros de log no sistema foi também implementada na API e foi inicializada a optimização de valores de retorno com foco nos códigos de resposta HTTP.

Dificuldades Foi ponderada a possibilidade de equipar a API com um mecanismo de retoma de uma instalação. Esta possibilidade foi abandonada por dificuldade de arranjar um solução eficaz e viável de implementação no sistema.

Previsão para a próxima semana Visto todos os serviços previstos já se encontrarem implementados, proceder-se-á à adição de todas as funcionalidade possiveis dos mesmos no que toca às acções disponíveis. O código de erro de retorno será também um foco nas próximas semanas, tendo provavelmente de ser refeito como um módulo de maneira a tornar-se mais escalável.


Semana 11 - 28 de Abril a 4 de Maio

Trabalho Realizado Foi iniciada a mudança para uma estrutura modular de código de erros internos e HTTP com optimização dos seus valores de retorno.

Dificuldades A mudança para um sistema modular de mensagens de erro trouxe a necessidade de efetuar uma revisão e alterações globais a nível da API e escolha de uma estratégia para adaptação aos códigos retornados pelas bibliotecas da IPBrick.

Previsão para a próxima semana O foco primário irá para a definição e optimização de uma estrutura final da API antes de iniciar a adição das funcionalidades restantes dos serviços. A identificação do facto de alguns nomes dos parâmetros de retorno se encontrarem em português levou à necessidade de implementar uma etapa adicional de tradução no módulo modulador de respostas.


Semana 12 - 5 a 11 de Maio

Trabalho Realizado A estrutura final ficou definida com a etapa de tradução que foi implementada ao longo desta semana. Foi continuada a atualização das mensagens de retorno e iniciada a adição de funcionalidades em falta nos serviços já implementados.

Dificuldades Nada a apontar.

Previsão para a próxima semana O objetivo para as próximas duas semanas será o de terminar a adição das funcionalidades esperadas e adaptação do código à nova estrutura de mensagens de retorno.


Semana 13 - 12 a 18 de Maio

Trabalho Realizado Durante esta semana foi finalizada a adição de funcionalidades previstas com prioridade menos elevada e feitos testes de coerência dos atributos enviados e recebidos.

Dificuldades Nada a apontar.

Previsão para a próxima semana Finalização de adaptação do código à nova estrutura de erros.


Semana 14 - 19 a 25 de Maio

Trabalho Realizado Adição dos códigos de erros das bibliotecas criadas à biblioteca de erros da IPBrick. Finalização de adaptação do código à nova estrutura de mensagens de retorno.

Dificuldades Nada a apontar.

Previsão para a próxima semana Início dos testes e demonstração da solução.


Semana 15 - 26 de Maio a 1 de Junho

Trabalho Realizado Início do teste de eficácia e segurança.

Dificuldades Foi necessária a implementação de scripts Groovy de maneira a garantir que todos os casos de teste eram iniciados com um pedido de inicio de instalação e finalizados com um pedido de término da instalação e que, nos testes de eficácia, todos os atributos enviados eram produzidos de maneira aleatória.

Previsão para a próxima semana Está prevista a disponibilização de uma aplicação para efetuação de testes na próxima semana.


Semana 16 - 2 a 8 de Junho

Trabalho Realizado Finalização dos testes de segurança e eficácia e início dos testes de integração de uma aplicação.

Dificuldades Foram identificados alguns problemas nos testes de integração da aplicação visto esta tratar-se de um pacote direccionado para uma versão não atualizada da IPBrick. A maioria destes problemas foram solucionados com a ajuda de staff da IPBrick.

Previsão para a próxima semana Finalização da integração da aplicação e, caso haja disponibilidade, integração de outra aplicação com diferentes funcionalidades.


Semana 17 - 9 a 15 de Junho

Trabalho Realizado Adição de gestão de uma base de dados de configurações predefinidas na API.

Dificuldades Aquando integração da aplicação fornecida foi possível identificar a necessidade da inclusão da gestão de uma base de dados de configurações predefinidas na API. Será ainda necessário a integração de uma aplicação adicional da qual a aplicação fornecida depende.

Previsão para a próxima semana Adaptação e integração da aplicação queuestats.


Semana 18 - 16 a 22 de Junho

Trabalho Realizado Adaptação e integração da aplicação queuestats e últimos testes de funcionamento da API.

Dificuldades Nada a apontar

Previsão para a próxima semana Criação de um pacote contento a solução desenvolvida.


Semana 19 - 23 a 29 de Junho

Trabalho Realizado Criação de um pacote contento a solução desenvolvida para incorporação no sistema de controlo de versões da IPBrick.

Dificuldades Nada a apontar

Equipa

  • Estudante: João Lopes Ferreira Sobreira
  • Orientador: Prof. Dr. João Manuel Couto das Neves (FEUP)
  • Co-orientador: Eng. Miguel Ramalhão Ribeiro (IPBrick SA)

Bibliografia

  1. Gartner. "WOA: Putting the Web Back in Web Services". Acedido em 31 de Janeiro, 2014. http://blogs.gartner.com/nick_gall/2008/11/19/ woa-putting-the-web-back-in-web-services/.
  2. ProgrammableWeb. "API Directory". Acedido em 16 de Fevereiro, 2014. http://www.programmableweb.com/ apis/directory.
  3. Ng, Alex, Shiping Chen e Paul Greenfield. "An evaluation of contemporary commercial SOAP implementations." Artigo apresentado em "5th Australasian Workshop on Software and System Architectures (AWSA 2004)", Melbourne, Vic., 2004.
  4. RFC 4627 - "The application/json Media Type for JavaScript Object Notation (JSON)".
  5. XML.com. He, Hao. "What Is Service-Oriented Architecture". Acedido em 14 de Fevereiro, 2014. http://www.xml.com/pub/a/ws/2003/09/30/soa.html.
  6. Endrei, Mark, Jenny Ang, Ali Arsanjani, Sook Chua, Philippe Comte, Pal Krogdahl, Min Luo, e Tony Newling. "Patterns: Service-Oriented Architecture and Web Services", 2004.
  7. Nurseitov, Nurzhan, Michael Paulson, Randall Reynolds e Clemente Izurieta. "Comparison of JSON and XML Data Interchange Formats: A Case Study". CAINE. 2009.
  8. W3C. "Web Services Architecture". Acedido em 16 de Fevereiro, 2014. http://www.w3.org/TR/ws-arch/.
  9. Microsoft. "Understanding SOAP". Acedido em 2 de Fevereiro, 2014. http://msdn.microsoft.com/en-us/library/ ms995800.aspx.
  10. Potti, Pavan Kumar. "On the Design of Web Services: SOAP vs REST". dissertação de Mestrado. University of North Florida. 2011.
  11. Huang, Nan-Chao. "A Cross PlatformWeb Service Implementation Using SOAP". dissertação de Mestrado não-publicada. Knowledge Systems Institute. 2003.
  12. Microsoft. "Understanding WSDL". Acedido em 2 de Fevereiro, 2014. http://msdn.microsoft.com/en-us/library/ ms996486.aspx.
  13. W3C. "Web Service Definition Language (WSDL)" Acedido em 16 de Fevereiro, 2014. http://www.w3.org/TR/wsdl.
  14. Fielding, Roy Thomas. "Architectural styles and the design of network-based software architectures". dissertação de Doutoramento. University of California. 2000.
  15. Feng, Xinyang e Ying Fan. "REST: An alternative to RPC for Web services architecture". Artigo apresentado em "2009 First International Conference on Future Information Networks", Beijing, China, 2009.

Documentos