PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS Instituto de Ciências Exatas e Informática Análise teórica e prática de serviços web baseados em SOAP e REST sob a perspectiva dos arquitetos de software Rafael Cruz Teixeira Orientador: Pedro Alves de Oliveira BELO HORIZONTE 03/12/2011

roteiro Contextualização do trabalho Motivação e Problema. Objetivos. Referencial Teórico Metodologia Experimento. Questionário. Considerações Finais Problemas e Limitações. Conclusão. Trabalhos futuros. Principais referências

Contexto Tema Arquiteturas para serviços web Os padrões arquiteturais estudados foram REST (Representational State Transfer – Transferência de estado representacional) e SOAP (Simple Object Access Protocol – Protocolo de acesso simples a objetos).

problema Escolha entre arquiteturas para projetar e desenvolver serviços Confiança Falta de conhecimento das possibilidades

Objetivos Objetivo Geral: Criar um guia introdutório às duas principais arquiteturas para a construção de serviços web Objetivos específicos Estudar ambas as arquiteturas, REST e SOAP, e levantar vantagens e desvantagens de cada uma com base na experiência dos arquitetos de software. Definir o que leva um arquiteto de software a escolher uma arquitetura de serviços Apontar critérios que podem ajudar na escolha da arquitetura de serviços.

Referencial teórico Estilos arquiteturais Agrupamento de conceitos de desenvolvimento de software que carregam características específicas de desempenho, forma de comunicação, forma de armazenamento das informações, com objetivos específicos de segurança, de velocidade de comunicação, de estruturação.

Referencial teórico Sistemas distribuídos Camadas Cliente-Servidor Objetos Distribuídos

Referencial teórico SOA Estilo arquitetural que propõe que as funcionalidades providas por sistemas sejam disponibilizadas na forma de serviços. Um serviço É uma representação lógica de uma regra de negócio Pode ser composto por outros serviços

Referencial teórico SOA Importância Centralização e uniformização das regras de negócio Controle e conhecimento dos serviços oferecidos Soa requer forte governança de serviços para que os mesmos não se degenerem

Referencial Teórico Arquiteturas SOA Web Services Simple Object Access Protocol (SOAP) XML, WSDL, XSD, Schema Representational State Transfer (REST) Híbrido Serviços, Sistemas, Comunicação

Experimento Descrição Upload de Arquivos REST SOAP Especificação do ambiente de desenvolvimento. Java 1.6 JBoss AXIS Jersey Hibernate MySQL Padrões de projeto Camadas Façade EJB

Experimento - resultado As provas de conceito demonstraram o quão simples pode ser desenvolver um projeto pequeno em ambas as arquiteturas, o que reforça a simplicidade do REST e ajuda a desfazer o mito de complexidade do SOAP. O desenvolvimento demonstrou que o desenho das aplicações podem ser muito semelhantes, mesmo baseadas em REST ou SOAP. A utilização de padrões de projeto permite a separação de responsabilidades de forma a manter isolada cada camada da aplicação. As duas arquiteturas apresentaram boa documentação. SOAP possui documentação mais formal e teórica, acompanhada de muitos exemplos. Já REST não possui tanta formalização.

Questionário Questionário Elaboração de um questionário para levantar as experiências e as decisões tomadas pelos arquitetos 10 arquitetos entrevistados Parte 1 Questionário sobre dados gerais do arquiteto, como formação e experiência. Parte 2 Questionário sobre as situações vividas com o uso de arquiteturas orientadas a serviços. Parte 3 Questionário sobre experiência com o uso de REST ou SOAP Citar pros, contras e cenarios

Questionário - resultado REST Prós Contras Fácil interoperabilidade entre as diversas implementações de REST. Formalismo pobre Praticidade na escrita de código Difícil de documentar Bom desempenho Fraca cultura empresarial Escalabilidade Não integra bem com SOAP Simplicidade Protocolos menos complexos Flexibilidade

Questionário - resultado SOAP Prós Contras Uso de WSDL para definição de tipos e interfaces Precisa-se escrever muito código para trabalhar com situações complexas Existem muitas API maduras Alta complexidade do protocolo de comunicação Existem muitas ferramentas de teste Ineficiente na gerência de recursos como banda e CPU Confiabilidade Não integra bem com REST Padrão de mercado Muito prolixo Segurança comprovada Necessita de ferramentas e frameworks para que se consiga um mínimo de produtividade

Questionário - resultado Cenários de Utilização de REST Quando simplicidade da arquitetura e desempenho forem requisitos básicos. Quando se utiliza metodologias ágeis de desenvolvimento de software. Quando o nível de segurança exigido não é muito alto. Quando os serviços ou integrações tiverem um escopo pequeno. Quando os requisitos forem pouco complexos e extensos. Quando é necessário ter grande escalabilidade.

Questionário - resultado Cenários de Utilização de SOAP Quando houver definição muito formal do serviço, como por exemplo, a definição da comunicação entre entidades distintas. Quando o ambiente for robusto o bastante para agüentar a carga de trabalho. Por exemplo, com a utilização das plataformas SAP e Oracle. Quando a segurança do tráfego de informações for um requisito essencial. Quando o cliente deseja utilizar essa arquitetura. Quando a integração a ser feita contempla sistemas com dados fortemente tipados. Quando o alvo da integração utiliza SOAP. Quando é necessária alta confiabilidade e formalização de contratos, tanto de operações como de parâmetros.

Problemas e limitações Definir o foco do trabalho Questionário Extenso Perguntas muito abstratas e às vezes repetitivas Respostas muito subjetivas

Conclusão O desenvolvimento das provas de conceito mostrou que é simples desenvolver aplicações que utilizam REST e SOAP. As API existentes encapsulam toda a complexidade dos protocolos utilizados. Com os resultados obtidos no questionário nota-se claramente que o contexto influencia muito na decisão de uma arquitetura. O tipo de projeto, a cultura da empresa, os requisitos e o domínio das tecnologias propostas influenciam diretamente nas escolhas dos arquitetos de software.

Trabalhos futuros Realizar comparação quantitativa entre REST e SOAP Evoluir as provas de conceito e avaliar a complexidade de desenvolvimento quando o requisito exigir mais da aplicação Elaborar uma documentação formal de REST

Principais referências FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000. COULOURIS, George; DOLLIMORE, Jean; KINDENBERG, Tim. Sistemas Distribuídos; Conceitos e Projeto. 4. ed. Porto Alegre: Bookman, 2007. TANENBAUM, Andrew S; STEEN, Maarten Van. Sistemas Distribuídos; Princípios e Paradigmas. 2. ed. São Paulo: Pearson Education, 2007. GARLAN, D; PERRY, D. Introduction to the Special Issue on Software Architecture; IEEE Transactions on Software Engineering, April 1995, pp 269-274.d FOWLER, Martin. Padrões de arquitetura de aplicações corporativas. Porto Alegre: Bookman, 2006.