1. Uso de Padrões no
Desenvolvimento de Web
Services
Um Estudo de Caso
Rafael Salerno de Oliveira
Prof Ms Vinícius Costa de Souza
S

2. Motivação
Integração
Multiplataforma
Disponibilização
Independência
de Tecnologia

3. Objetivo
• Como Reduz a Complexidade
• Comunicação Comum entre
Desenvolvedores
• Como proporciona Evolução

4. O que é um Web Service?
S É uma Solução que possibilita:
S Comunicação entre Aplicações Diferentes
S Interação com Diferentes Plataformas

5. Características
Infraestrutura aberta
Transparência de Linguagem
Design modular
“Isolar o Cliente”

6. Principais Tipos

7. Meio da Comunicação

8. Conteúdo da Comunicação

9. Padrões/Estilos de API para
Web Services
• RPC API
• Message API
• Resource API

10. RPC API
Remote Procedure Call

11. Message API

12. Resource API

13. Tipos de Padrões de Interação
Cliente-Servidor
• Request/Response
• Request/Acknowledge
• Media Type Negotiation
• Linked Service.

14. Request/Response

15. Request/Response

16. Request/Acknowledge
Steps no Server:
1. Recebe um Request
2. Envia um Identificador(token) ou uma URL
3. Processsa a requisição em backgroud
4. Recebe o Identificador e envia o

17. Request/Acknowledge

18. Media Type Negotiation

19. Linked Service

20. Linked Service

21. Padrões de
Request/Response
S Service Controller
S Data Transfer Object

22. Service Controller
- Controlam a execução de tarefas de negócios e
coordenam o acesso à recursos.
- Front Controller

23. Data Transfer Object

24. Data Transfer Object

25. Estilos de Implementação de
Web Service
Considerações para implementação do serviço
Web:
S Atomicidade - tudo ou nada
S Não gerenciar estados
S Ações quando houver composição de serviços

26. Estilos de Implementação de
Web Service
S Operation Script
S Command Invoker

27. Estilos de Implementação de
Web Service
S Transaction Script

28. Padrões de Infra- Estrutura
para Web Service
S Service Connector
S Service Descriptor
S Service Interceptor
S Idempotent Retry

29. Service Connector
S Esconde detalhes da
comunicação entre APIs
relacionadas
Idempotent Retry
S Tratar problemas relacionados a
erro de conexão

30. Service Descriptor

31. Service Interceptor

32. Benefícios do uso de padrões
de projeto
Diminuem
o
retrabalho

33. Metodologia
S Público alvo
S Técnica utiliza amostragem por conveniência
S Observação do pesquisador.
S Questionário direcionado a profissionais de
TI

34. Estudo de Caso
S Foi utilizado uma aplicação usada por uma
empresa de pesquisa de medicamentos.
S Algumas funcionalidades:
 Monitoramento de Portfólio de Medicamentos
 Pesquisa e Recomendação de Medicamentos
 Agrupamento de Medicamento
 Histórico do medicamento

35. Estudo de Caso
S P1 - Sem Padrões de Projeto para web
Services
S P2 - Com Padrões de Projeto para web
Services
S As duas aplicações realizam o mesmo
trabalho
S Tem entradas e saídas iguais o que facilita a
comparação

36. Estudo Comparativo
S O que foi Comparado :
 Padrões de Projetos
 Frameworks
 Número de Linhas de Código
 Complexidade Ciclomática (IF,WHILE e FOR)
 Manutenibilidade (facilidade, precisão, segurança na

37. Complexidade Ciclomática
M=D+1 onde:
D=ponto de decisão (IF,FOR,WHILE)
Valores de Referência:
− 1-10, métodos simples, sem muito risco
− 11-20, métodos medianamente complexos, com
risco moderado
− 21-50, métodos complexos, com risco alto
− 51 ou mais, métodos instáveis de altíssimo risco.
(MCCABE,1976)

39. Resultados Obtidos
Projeto 2
• Padrão Arquitetural SOA
• Estilo de RPC API
• Linked Service com serviço raiz com pontos de
entrada
• Data Transfer Object para tratar dados
recebidos e Enviados e deixar o cliente a parte

40. Resultados Obtidos
• Operation Transcripts para ter um único ponto
de controle transacional
• Comand Invoker para que o Serviço não
conheça o modelo de domínio e fazer com que
o cliente conheça apenas interfaces de saída
• Service Interceptor para realizar validações

41. Resultados Obtidos
• O projeto 2 teve aproximadamente 1200 linhas a mais
que o projeto 1
• Complexidade Ciclomática foi considerada:
P1 - “medianamente complexo, com risco
moderado”

42. Resultados Obtidos
P1
P2

43. Resultados Obtidos
• A manutenibilidade foi de 1h e 30 min a menos
no projeto 2
Casos de manutenção:
• Suporte a relatórios em CSV
• Manutenção no agrupamento por medicamentos
do mesmo tipo
• Ordenação de medicamentos após o
agrupamento do mesmo tipo

44. Estudo Qualitativo
S Pesquisa com dez profissionais
S Objetivo :
Importância dos padrões de projeto
É determinado pelo tempo de
experiência?

45. Estudo Qualitativo
Experiência na área de TI em anos:
5 anos
6 anos 8 anos 5 anos 12 anos
3 anos
1 ano 4 anos 5 anos
2 anos

46. Estudo Qualitativo

47. Estudo Qualitativo

48. Estudo Qualitativo

49. Estudo Qualitativo

50. Conclusão do Estudo
Qualitativo
S A maior parte das pessoas sabem que os
Padrões de projeto tem benefícios
S A complexidade e quando se usar pode
estar ligado a tempo de experiência
S Dependendo do contexto que se trabalha
a pessoas acham que o framework pode
ser mais importante que o Padrão de

51. Considerações Finais
• Complexidade
• Manutenção
•
Código Duplicado
• Comunicação

52. Referencial