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 HORIZONTE03/12/2011

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAISInstituto de Ciências Exatas e Informática

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

QUESTIONÁRIO - RESULTADOREST

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

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.