SOA (Service-Oriented Architecture) Conceitos e Aplicação. Daniel Macêdo Batista IME/USP Março

Transcrição

1 SOA (Service-Oriented Architecture) Conceitos e Aplicação Daniel Macêdo Batista IME/USP batista@ime.usp.br Março

2 Objetivos do curso Melhores práticas Benefícios de SOA SOAP e REST Migração para SOA Exemplos Em resumo, a ideia é desmistificar o tópico

3 Roteiro Manhã (2h10m): Conceitos básicos de SOA e serviços Alguns exemplos simples XML, WSDL e SOAP Primeira parte da tarde (1h50m): REST, JSON e UDDI com exemplos Microserviços e composição de serviços Segunda parte da tarde (1h50m): Alguns exemplos com acesso a BD Conclusões e discussão

4 Conceitos básicos de SOA e serviços

5 O que é SOA (Service-Oriented Architecture Arquitetura Orientada a Serviços)? Um estilo arquitetural para projetos de sofware que suporta orientação a serviço (segundo o OpenGroup) Paradigma para troca de valores entre participantes que agem de forma independente (segundo o OASIS)

6 (Focando na definição do OpenGroup) O que é um serviço? Representação lógica de atividades de negócio Auto-contido Pode ser composto por outros serviços Uma caixa-preta para os consumidores

7 Representação lógica de atividades de negócio Informar a temperatura atual em uma cidade seria um serviço fornecido por uma companhia de previsão do tempo Informar a média de um aluno seria um serviço fornecido por uma universidade Passar a pensar nas ações

8 Auto-contido Todas as dependências de software do serviço de meteorologia são resolvidas pela companhia de previsão de tempo (consultar informações de satélite, fazer cálculos complexos, etc ) O mesmo vale para a média (verificação de permissões, acesso ao BD, etc...)

9 Composto por outros serviços Orquestração

10 Composto por outros serviços Coreografia

11 Caixa-preta Não importa como foi implementado e sim se responde adequadamente às solicitações Importante ser independente de tecnologia ou plataforma Quem vai acessar o serviço só quer usar

12 Na prática o que tudo isso quer dizer e como é feito? 1) Pensar em sistemas como conjuntos de serviços que reflitam as atividades 2) Implementar cada serviço como um código independente e pequeno (Reuso) 3) Disponibilizar os serviços via rede com suas descrições

13 Na prática o que tudo isso quer dizer e como é feito? 4) Se necessário, compor serviços para ter o sistema final 5) Quando necessário, tratar os dados devolvidos pelos serviços evitando mudanças constantes nos serviços

14 Na prática o que tudo isso quer dizer e como é feito?. SOA vai definir como integrar diversos pedaços de código espalhados pela rede (interface, protocolo e funcionalidade). No fim das contas estamos falando de programação modular

15 Tudo começa (na verdade estamos no passo 2!!) com 1 serviço escrito em alguma linguagem de programação, um web service...

16 O serviço estará no provedor de serviços. Preciso saber sobre ele UDDI (Universal Description Discovery and Integration)

17 O serviço estará no provedor de serviços. Preciso saber sobre ele WSDL (Web Services Description Language)

18 Já sei sobre o serviço, preciso invocá-lo Servidor web (porta 80 já aberta, todo lugar já tem um)

19 Já sei sobre o serviço, preciso invocá-lo SOAP (Simple Object Access Protocol) ou REST (Representational State Transfer)

20 Alguns exemplos simples

21 Exemplo 1: uma aplicação baseada em um serviço que recebe um nome e devolve um Olá <nome> Passo 1: Instalar um servidor web (ex.: Apache) Não necessário se só vai usar! Passo 2: Ter algum compilador ou interpretador com suporte a serviços (ex.: Java, PHP, perl,...)

22 Passo 1: Instalar um servidor web (ex.: Apache) apt-get install apache2 Passo 2: Ter algum compilador ou interpretador com suporte a serviços (ex.: PHP) apt-get install php5-common libapache2-mod-php5 php5-cli libnusoap-php

23 Passo 3: escrever o código do serviço e divulgá-lo [exemplo1-servico.php] require_once('nusoap/nusoap.php')

24 Passo 3: escrever o código do serviço e divulgá-lo require_once('nusoap/nusoap.php'); $server = new nusoap_server;

25 Passo 3: escrever o código do serviço e divulgá-lo require_once('nusoap/nusoap.php'); $server = new nusoap_server; $server->configurewsdl('server.hello', 'urn:server.hello');

26 Passo 3: escrever o código do serviço e divulgá-lo require_once('nusoap/nusoap.php'); $server = new nusoap_server; $server->configurewsdl('server.hello', 'urn:server.hello'); $server->wsdl->schematargetnamespace = 'urn:server.hello');

27 Passo 3: escrever o código do serviço e divulgá-lo $server->register('hello', array('nome' => 'xsd:string'), array('return' => 'xsd:string'), 'urn:server.hello', 'urn:server.hello#hello', 'rpc', 'encoded', 'servico que retorna o nome');

28 Passo 3: escrever o código do serviço e divulgá-lo function hello($nome) { return 'Olá '. $nome; }

29 Passo 3: escrever o código do serviço e divulgá-lo function hello($nome) { return 'Olá '. $nome; } $HTTP_RAW_POST_DATA=isset($HTTP_RAW_POST_DATA)? $HTTP_RAW_POST_DATA : ''; $server->service($http_raw_post_data);

30 Passo 4: usar o serviço Testando pelo navegador wsdl

31 Passo 4: usar o serviço Testando pelo navegador

32 Passo 4: usar o serviço Testando pelo navegador

33 Passo 4: usar o serviço Programando [exemplo1-cliente.php] require_once('nusoap/nusoap.php');

34 Passo 4: usar o serviço Programando require_once('nusoap/nusoap.php'); $wsdl = ' wsdl';

35 Passo 4: usar o serviço Programando require_once('nusoap/nusoap.php'); $wsdl = ' wsdl'; $cliente = new nusoap_client($wsdl);

36 Passo 4: usar o serviço Programando require_once('nusoap/nusoap.php'); $wsdl = ' wsdl'; $cliente = new nusoap_client($wsdl); $saida = $cliente->call('hello', array('daniel Batista'));

37 Passo 4: usar o serviço Programando require_once('nusoap/nusoap.php'); $wsdl = ' wsdl'; $cliente = new nusoap_client($wsdl); $saida = $cliente->call('hello', array('daniel Batista')); print_r($saida);

38 Passo 4: usar o serviço Programando Documentação em

39 Passo 4: usar o serviço Programando apt-get install perl libsoap-lite-perl verdade esse seria o passo 2) (na

40 Passo 4: usar o serviço Programando [exemplo1-cliente.pl] use SOAP::Lite;

41 Passo 4: usar o serviço Programando use SOAP::Lite; my $url = ' wsdl';

42 Passo 4: usar o serviço Programando use SOAP::Lite; my $url = ' wsdl'; my $service = SOAP::Lite->service($url);

43 Passo 4: usar o serviço Programando use SOAP::Lite; my $url = ' wsdl'; my $service = SOAP::Lite->service($url); print "A saída do serviço é: ", $service>hello("daniel Batista"), "\n";

44 Passo 4: usar o serviço Programando daniel@cliente:/tmp$./exemplo1-cliente.pl A saída do serviço é: Olá Daniel Batista Mais informações em

45 O que aconteceu nos bastidores?

46 O que aconteceu nos bastidores?

47 O que aconteceu nos bastidores? (Já vimos no navegador)

48 O que aconteceu nos bastidores?

49 O que aconteceu nos bastidores?

50 O que aconteceu nos bastidores?

51 O que aconteceu nos bastidores?

52 O que aconteceu nos bastidores?

53 Observações Acesso à rede é crítico (mas de fato já era) O acesso ao WSDL pode usar cache (menos uso de rede) O acesso ao servidor com o serviço pode ser via HTTPS (segurança) O exemplo tem dois servidores HTTP por causa do php

54 Observações Tudo pode rodar no mesmo servidor (no nosso caso havia apenas 1 servidor apache) Não está preso à linguagem Se a linguagem tem suporte a serviços, pode integrar com outros sistemas

55 Observações O hello não está tão bom. Ideal é devolver o mínimo possível de informação (se fosse inverter a string, mudaria o serviço?) Cuidado ao modificar serviços existentes! (Documentação) O SOAP no fim das contas foi XML + HTTP (foi usado 2 vezes)

56 XML, WSDL e SOAP

57 XML (Extensible Markup Language) Linguagem de marcação com conjuntos de regras para documentos A ideia é que seja amigável para humanos e máquinas (este segundo, útil para web services)

58 XML (Extensible Markup Language) Apesar de ser descrito como voltado para documentos, pode representar qualquer estrutura de dados (bom para o caso de interoperabilidade por causa das regras bom para web services)

59 XML (Extensible Markup Language) No caso de web services, pode ser usado em vários momentos do processamento. Esquemas com as regras para cada momento são importantes Já vimos exemplos. Mais detalhes adiante Mais informações em

60 WSDL (Web Services Description Language) Linguagem de definição de interface Descreve as funcionalidades de um serviço web Funciona como a assinatura de uma função em programação convencional

61 WSDL (Web Services Description Language) A ideia não é criar um arquivo com essa linguagem manualmente Baseada em XML (XML Schema) Atualmente está na versão 2.0 Mais informações em

62 WSDL (Web Services Description Language)

63 WSDL (Web Services Description Language) <?xml version="1.0" encoding="iso "?> <definitions xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" xmlns:soap-enc=" xmlns:tns="urn:server.hello" xmlns:soap=" xmlns:wsdl=" xmlns=" targetnamespace="urn:server.hello">

64 WSDL (Web Services Description Language) <types> <xsd:schema targetnamespace="urn:server.hello" > <xsd:import namespace=" /> <xsd:import namespace=" /> </xsd:schema> </types>

65 WSDL (Web Services Description Language) <message name="hellorequest"> <part name="nome" type="xsd:string" /></message> <message name="helloresponse"> <part name="return" type="xsd:string" /></message> <porttype name="server.helloporttype"> <operation name="hello"> <documentation>servico que retorna o nome</documentation> <input message="tns:hellorequest"/> <output message="tns:helloresponse"/> </operation> </porttype>

66 WSDL (Web Services Description Language) <binding name="server.hellobinding" type="tns:server.helloporttype"> <soap:binding style="rpc" transport=" <operation name="hello"> <soap:operation soapaction="urn:server.hello#hello" style="rpc"/> <input><soap:body use="encoded" namespace="urn:server.hello" encodingstyle=" <output><soap:body use="encoded" namespace="urn:server.hello" encodingstyle=" </operation> </binding>

67 WSDL (Web Services Description Language) <service name="server.hello"> <port name="server.helloport" binding="tns:server.hellobinding"> <soap:address location=" </port> </service> </definitions>

68 SOAP (Simple Object Access Protocol) Define informação baseada em XML usada para trocar informação estruturada entre nós de um ambiente descentralizado e distribuído Paradigma de troca de mensagens em uma via (one way) sem manutenção de estado

69 SOAP (Simple Object Access Protocol) Mensagens SOAP são escritas em XML Mensagens SOAP são transportadas principalmente sobre protocolos da camada de aplicação HTTP ou SMTP ( )

70 SOAP (Simple Object Access Protocol) Três principais características: extensibilidade, neutralidade e independência

71 SOAP (Simple Object Access Protocol)

72 SOAP (Simple Object Access Protocol) <?xml version="1.0" encoding="utf-8"?>

73 SOAP (Simple Object Access Protocol) <SOAP-ENV:Envelope SOAP-ENV:encodingStyle=" xmlns:soap-enc=" xmlns:soap-env=" xmlns:soap=" xmlns:tns="urn:server.hello" xmlns:wsdl=" xmlns:xsd=" xmlns:xsi=" >

74 SOAP (Simple Object Access Protocol) <SOAP-ENV:Body> <tns:hello> <nome xsi:type="xsd:string"> Daniel Batista </nome> </tns:hello> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

75 SOAP (Simple Object Access Protocol) Bom pela neutralidade Melhor ainda quando usando HTTP (infra de rede já configurada)

76 SOAP (Simple Object Access Protocol) Ruim por usar XML tanto para mensagens pequenas quanto para transportar binários Necessário usar SOAP Message Transmission Optimization Mechanism (MTOM)

77 SOAP (Simple Object Access Protocol) Ruim pela verbosidade exigida do HTTP (Tudo usando POST) Mais informações em

78 REST, JSON e UDDI com exemplos

79 Algumas informações importantes do que vimos até agora Pensar no sistema como conjunto de serviços deixa ele mais próximo do mundo real Servidor HTTP está na base da infra para SOA (latência da rede pode ser problema)

80 Algumas informações importantes do que vimos até agora Aplicar SOA força (facilita) o reuso Aplicações passam a ser conjuntos de módulos menores (os serviços) Serviços podem estar escritos em qualquer linguagem

81 Algumas informações importantes do que vimos até agora Interoperabilidade fácil Maior responsabilidade na hora de escrever e manter os ``módulos'', por isso importante serem pequenos

82 Algumas informações importantes do que vimos até agora Quantidade de informação trocada é excessiva Uso do POST no HTTP para tudo não é uma boa prática Testar aos poucos é fundamental!

83 Já que a rede é um gargalo, seria interessante otimizar as mensagens trocadas de forma fácil Já que o HTTP tem muitos métodos, seria interessante tirar proveito deles ao acessar serviços

84 REST (Representational State Transfer) Diferente do SOAP, não é um protocolo, mas um estilo arquitetural de software para sistemas de hipermídia distribuídos A ideia é ter componentes para compor as aplicações

85 REST (Representational State Transfer) Ignora detalhes de implementação dos componentes e sintaxe de protocolos Foca nos papeis dos componentes, restrições quando interagem e interpretação dos elementos de dados

86 REST (Representational State Transfer) Seguindo as restrições do REST busca-se: desempenho, escalabilidade, simplicidade, facilidade de modificação, visibilidade, portabilidade e confiabilidade Seguindo as restrições do REST: RESTfull

87 REST (Representational State Transfer) Tipicamente vai operar sobre HTTP usando os possíveis métodos do protocolo (GET, POST, DELETE, PUT, etc...)

88 REST (Representational State Transfer) Tudo que foi visto até agora sobre REST casa muito bem com serviços web! Serviços web que seguem o estilo de REST são chamados APIs RESTfull

89 Para um serviço web ser RESTfull: Ter uma URI (Uniform Resource Identifier) base ( Usar algum formato de mídia da Internet (JSON geralmente é o mais usado mas pode usar XML por exemplo)

90 Para um serviço web ser RESTfull: Usar métodos padrão do HTTP Usar links de hipertexto para acesso aos recursos e mudança de estado

91 REST (Representational State Transfer) O que se vê na prática é um predomínio de REST quando o assunto é serviços web Mais informações em ertation/rest_arch_style.htm

92 Na prática o que tudo isso quer dizer e como é feito? Pensar em coisas ao invés de ações Os recursos serão acessados em links usando GET, POST, etc... Pensar em substantivos ao invés de verbos O servidor vai processar o GET, POST,...

93 Na prática o que tudo isso quer dizer e como é feito? Recurso: pessoa (Daniel) [URL] Serviço: informação de contato (via GET) [URL] Representação: nome, endereço, telefone (via JSON ou XML por exemplo) [Retorno]

94 Na prática o que tudo isso quer dizer e como é feito? (com um exemplo simples o mesmo anteriormente) Exemplo 1: uma aplicação baseada em um serviço que recebe um nome e devolve um Olá <nome> mas agora usando REST

95 Passo 1: Instalar um servidor web (ex.: Apache) Não necessário se só vai usar! Passo 2: Ter algum compilador ou interpretador com suporte a serviços (ex.: Java, PHP, perl,...)

96 Passo 1: Instalar um servidor web (ex.: Apache) apt-get install apache2 Passo 2: Ter algum compilador ou interpretador com suporte a serviços (ex.: PHP) apt-get install php5-common libapache2-mod-php5 php5-cli

97 Passo 3: escrever o código do serviço [exemplo1-servico-rest.php] $urls_validas = array("hello");

98 Passo 3: escrever o código do serviço $urls_validas = array("hello"); if (isset($_get["action"]) && in_array($_get["action"], $urls_validas)) {

99 Passo 3: escrever o código do serviço $urls_validas = array("hello"); if (isset($_get["action"]) && in_array($_get["action"], $urls_validas)) { if (isset($_get["nome"])) {

100 Passo 3: escrever o código do serviço $urls_validas = array("hello"); if (isset($_get["action"]) && in_array($_get["action"], $urls_validas)) { if (isset($_get["nome"])) { $retorno = hello($_get["nome"]);

101 Passo 3: escrever o código do serviço $urls_validas = array("hello"); if (isset($_get["action"]) && in_array($_get["action"], $urls_validas)) { if (isset($_get["nome"])) { $retorno = hello($_get["nome"]);} else { $retorno = "Nome faltando";} }

102 Passo 3: escrever o código do serviço else { $retorno = "Ação inexistente"; }

103 Passo 3: escrever o código do serviço else { $retorno = "Ação inexistente"; } function hello($nome) { return 'Olá '. $nome; }

104 Passo 3: escrever o código do serviço else { $retorno = "Ação inexistente"; } function hello($nome) { return 'Olá '. $nome; } exit(json_encode($retorno));

105 Passo 4: usar o serviço Testando pelo navegador action=hello&nome=daniel%20batista

106 Passo 4: usar o serviço Testando pelo navegador

107 Passo 4: usar o serviço Testando pelo navegador

108 Passo 4: usar o serviço Testando pelo navegador

109 Passo 4: usar o serviço Programando [exemplo1-cliente-rest.php] $retorno = file_get_contents(' -servico-rest.php?action=hello&nome=daniel %20Batista');

110 Passo 4: usar o serviço Programando $retorno = file_get_contents(' -servico-rest.php?action=hello&nome=daniel %20Batista'); $retorno = json_decode($retorno);

111 Passo 4: usar o serviço Programando $retorno = file_get_contents(' -servico-rest.php?action=hello&nome=daniel %20Batista'); $retorno = json_decode($retorno); print_r($retorno);

112 Passo 4: usar o serviço Programando

113 O que aconteceu nos bastidores?

114 O que aconteceu nos bastidores?

115 O que aconteceu nos bastidores?

116 O que aconteceu nos bastidores?

117 O que aconteceu nos bastidores?

118 Observações Menos código no cliente e no servidor (mesmo fazendo várias checagens que não foram feitas com SOAP) Menos trocas de mensagens Mensagens menores Melhor uso da rede OK!

119 Observações Processamento em cima dos métodos do HTTP (desnecessário instalar algum pacote extra) Uso demasiado do POST não mais!

120 Observações Dois problemas do SOAP melhorados Responsabilidade na hora de escrever os módulos continua Possibilidade de testar aos poucos continua

121 JSON (JavaScript Object Notation) O exemplo anterior com REST retornou dados via JSON (bem mais enxuto que XML) JSON é um formato leve para troca de dados

122 JSON (JavaScript Object Notation) Fácil para humanos lerem e escreverem Fácil para máquinas processarem e gerarem Independente de linguagem

123 JSON (JavaScript Object Notation) Construído sobre duas estruturas: Uma coleção de pares nome/valor (como um objeto) Uma lista ordenada de valores (como um array)

124 JSON (JavaScript Object Notation)

125 JSON (JavaScript Object Notation)

126 JSON (JavaScript Object Notation)

127 JSON (JavaScript Object Notation)

128 JSON (JavaScript Object Notation)

129 JSON (JavaScript Object Notation) { "id": 1, "name": "Daniel Batista", "nota": 7.50, "tags": ["mestrado", "doutorado"] } Mais informações em

130 UDDI (Universal Description, Discovery and Integration) Protocolo padronizado pela OASIS que define métodos para publicar e descobrir serviços em SOA Possibilita a criação de um servidor com registros de serviços web

131 UDDI (Universal Description, Discovery and Integration) Foi proposto para receber requisições SOAP e devolver WSDLs dos serviços Mais informações em

132 UDDI (Universal Description, Discovery and Integration) Embora apareça em muitos documentos sobre SOA, na prática é pouco usado e apenas internamente em organizações

133 Microserviços e composição de serviços

134 Microserviços Mais um estilo arquitetural para desenvolvimento de software (já vimos SOA e REST) Aplicações complexas devem ser formadas por pequenos processos independentes que se comunicam via APIs (similar ao do Unix)

135 Microserviços Serviços web podem ser esses processos Requisições aos serviços podem fazer o papel das APIs

136 Microserviços O importante é que os serviços tenham baixíssimo acoplamento e sejam focados em realizar uma tarefa pequena (a ideia da programação modular ao extremo) Diferente de SOA, um conjunto de microserviços é voltado para uma única aplicação, não para diversas

137 Microserviços Fáceis de substituir Organizados por funcionalidade Independente de tecnologia (usar a linguagem que melhor resolve o problema)

138 Microserviços Uma consequência (mesmo usando REST) é que muitos serviços mais uso da rede maior latência na aplicação

139 Microserviços Mais informações em ices.html

140 Composição de serviços Não faz muito sentido num cenário de microserviços porque conta com o reuso de serviços existentes A ideia é ter um serviço formado por outros serviços

141 Composição de serviços Na orquestração de serviços, há um serviço principal regendo toda a execução Na coreografia de serviços, os serviços comunicam-se entre si sabendo qual é o próximo passo mas sem ter noção da aplicação como um todo

142 Alguns exemplos com acesso a BD

143 Por que serviços web para acesso a BD ao invés de acesso direto ao BD ou replicação? Clientes mais leves (menos uso de CPU, mais tempo de bateria) Facilidade em realizar migrações (até se mudar de SGBD)

144 Por que serviços web para acesso a BD ao invés de acesso direto ao BD ou replicação? A camada a mais por causa do serviço pode aumentar a segurança (questionável) Facilidade para implementar cache A latência da rede não é um problema (se o BD está tão ou mais longe que o servidor web por exemplo)

145 Exemplo 2: uma aplicação baseada em um serviço que recebe um nome e devolve as informações desse nome que estão armazenadas em um BD

146 Exemplo 2 [exemplo2-servico-rest.php] $urls_validas = array("busca");

147 Exemplo 2 $urls_validas = array("busca"); if (isset($_get["action"]) && in_array($_get["action"], $urls_validas)) {

148 Exemplo 2 $urls_validas = array("busca"); if (isset($_get["action"]) && in_array($_get["action"], $urls_validas)) { if (isset($_get["nome"])) { $retorno = busca($_get["nome"]);}

149 Exemplo 2 $urls_validas = array("busca"); if (isset($_get["action"]) && in_array($_get["action"], $urls_validas)) { if (isset($_get["nome"])) { $retorno = busca($_get["nome"]);} else { $retorno = "Nome faltando";}} else { $retorno = "Ação inexistente";}

150 Exemplo 2 function busca($nome) { $mysqli = mysqli_connect("localhost", "usuario", "senha", "professores");

151 Exemplo 2 function busca($nome) { $mysqli = mysqli_connect("localhost", "usuario", "senha", "professores"); mysqli_set_charset($mysqli, 'utf8mb4');

152 Exemplo 2 $resultado = array(); $saida_query = mysqli_query ($mysqli, "SELECT * FROM PESSOA WHERE NOME LIKE '$nome%'"); while($linha = mysqli_fetch_array ($saida_query)) { $dados = array( 'nome' => $linha['nome'], 'endereco' => $linha['endereco'], 'nascimento' => $linha['nascimento'] ); array_push($resultado, $dados); } return $resultado;}

153 Exemplo 2 exit(json_encode($retorno));

154 Exemplo 2 [exemplo2-cliente-rest.php] $retorno = file_get_contents(' $retorno = json_decode($retorno); print_r($retorno);

155 Exemplo 2

156 Conclusões e discussão

157 Prós e contras de SOA Mudança de paradigma Possível aumento na latência dos sistemas Grande dependência da rede Interoperabilidade entre diferentes linguagens e plataformas Infra de rede já montada

158 Prós e contras de SOA Reusabilidade dos serviços Com uma boa biblioteca de serviços, foco no negócio e não na implementação

159 Quanto custa migrar (já tendo um servidor web)? Se for REST, provavelmente nada a mais a ser instalado Se for SOAP, alguns poucos pacotes Provavelmente a linguagem de preferência poderá ser mantida

160 Quanto custa migrar (já tendo um servidor web)? Necessário avaliar a carga no servidor após um tempo Capacitação (não muitas horas) da equipe

161 SOAP vs. REST APIs REST vem sendo oferecidas pelos principais provedores de conteúdo (Twitter, Facebook, Amazon, ) SOAP só se tiver que interagir com algo que já use SOAP por conta da carga extra na rede e códigos grandes

162 Microserviços vs. SOA Microserviços só se forem desenvolvidos poucos sistemas baseados em SOA Não usar microserviços se boa parte dos serviços será reusada em muitos projetos Não usar microserviços se a rede é um problema (questionável)

163 Replicação de dados vs. Serviços Dar preferência por serviços (mais uma camada facilita mudanças no SGBD sem modificações para o cliente) Evitar replicação garante dados sempre atualizados e reduz tráfego na rede (questionável)

164 Referências Códigos em Patricia Araujo de Oliveira. Seleção de Serviços Web em Coreografias Dissertação (Mestrado em Ciência da Computação) - Universidade de São Paulo, Coordenação de Aperfeiçoamento de Pessoal de Nível Superior. Orientador: Daniel Macêdo Batista. Victoriano Alfonso Phocco Diaz. Detecção de violações de SLA em coreografias de serviços Web Dissertação (Mestrado em Ciência da Computação) - Universidade de São Paulo, União Européia. Orientador: Daniel Macêdo Batista.

165 Referências Obs.: Todas as páginas foram acessadas pela última vez em 28 de Março de

166 Referências Obs.: Todas as páginas foram acessadas pela última vez em 28 de Março de File:WSDL_11vs20.png

167 Referências Obs.: Todas as páginas foram acessadas pela última vez em 28 de Março de