PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS

Apresentação em tema: "PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS"— Transcrição da apresentação:

1 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

2 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

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

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

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

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

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

8 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

9 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

10 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

11 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

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

13 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

14 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

15 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

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

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

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

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

20 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

21 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 d FOWLER, Martin. Padrões de arquitetura de aplicações corporativas. Porto Alegre: Bookman, 2006.