Daniel Macêdo Batista – IME/USP – [email protected]
Março - 2016
SOA (Service-Oriented Architecture) - Conceitos e Aplicação
• 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
• 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
Conceitos básicos de SOA e serviços
• 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)
• (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
● 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
● 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...)
● Composto por outros serviços
– Orquestração
● Composto por outros serviços
– Coreografia
● 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
● 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
● 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
● 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
● Tudo começa (na verdade estamos no passo 2!!) com 1 serviço escrito em alguma linguagem de programação, um web service...
● O serviço estará no provedor de serviços. Preciso saber sobre ele
– UDDI (Universal Description Discovery and Integration)
● O serviço estará no provedor de serviços. Preciso saber sobre ele
– WSDL (Web Services Description Language)
● Já sei sobre o serviço, preciso invocá-lo
– Servidor web (porta 80 já aberta, “todo” lugar já tem um)
● Já sei sobre o serviço, preciso invocá-lo
– SOAP (Simple Object Access Protocol) ou REST (Representational State Transfer)
Alguns exemplos simples
● 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, ...)
● 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
● Passo 3: escrever o código do serviço e divulgá-lo [exemplo1-servico.php]require_once('nusoap/nusoap.php')
● Passo 3: escrever o código do serviço e divulgá-lorequire_once('nusoap/nusoap.php');
$server = new nusoap_server;
● Passo 3: escrever o código do serviço e divulgá-lorequire_once('nusoap/nusoap.php');
$server = new nusoap_server;
$server->configureWSDL('server.hello', 'urn:server.hello');
● Passo 3: escrever o código do serviço e divulgá-lorequire_once('nusoap/nusoap.php');
$server = new nusoap_server;
$server->configureWSDL('server.hello', 'urn:server.hello');
$server->wsdl->schemaTargetNamespace = 'urn:server.hello');
● 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');
● Passo 3: escrever o código do serviço e divulgá-lo
function hello($nome) {
return 'Olá '. $nome;
}
● 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);
● Passo 4: usar o serviço
– Testando pelo navegador● http://servidor/exemplo1-servico.php● http://servidor/exemplo1-servico.php?
wsdl
● Passo 4: usar o serviço
– Testando pelo navegador
● Passo 4: usar o serviço
– Testando pelo navegador
● Passo 4: usar o serviço
– Programando [exemplo1-cliente.php]
require_once('nusoap/nusoap.php');
● Passo 4: usar o serviço
– Programando require_once('nusoap/nusoap.php');
$wsdl = 'http://servidor/exemplo1-servico.php?wsdl';
● Passo 4: usar o serviço
– Programando require_once('nusoap/nusoap.php');
$wsdl = 'http://servidor/exemplo1-servico.php?wsdl';
$cliente = new nusoap_client($wsdl);
● Passo 4: usar o serviço
– Programando require_once('nusoap/nusoap.php');
$wsdl = 'http://servidor/exemplo1-servico.php?wsdl';
$cliente = new nusoap_client($wsdl);
$saida = $cliente->call('hello', array('Daniel Batista'));
● Passo 4: usar o serviço
– Programando require_once('nusoap/nusoap.php');
$wsdl = 'http://servidor/exemplo1-servico.php?wsdl';
$cliente = new nusoap_client($wsdl);
$saida = $cliente->call('hello', array('Daniel Batista'));
print_r($saida);
● Passo 4: usar o serviço
– Programando
Documentação em https://sourceforge.net/projects/nusoap/files/nusoap-docs/
● Passo 4: usar o serviço
– Programando
apt-get install perl libsoap-lite-perl (na verdade esse seria o passo 2)
● Passo 4: usar o serviço
– Programando [exemplo1-cliente.pl] use SOAP::Lite;
● Passo 4: usar o serviço
– Programando use SOAP::Lite;
my $url = 'http://servidor/exemplo1-servico.php?wsdl';
● Passo 4: usar o serviço
– Programando use SOAP::Lite;
my $url = 'http://servidor/exemplo1-servico.php?wsdl';
my $service = SOAP::Lite->service($url);
● Passo 4: usar o serviço
– Programando use SOAP::Lite;
my $url = 'http://servidor/exemplo1-servico.php?wsdl';
my $service = SOAP::Lite->service($url);
print "A saída do serviço é: ", $service->hello("Daniel Batista"), "\n";
● Passo 4: usar o serviço
– Programandodaniel@cliente:/tmp$ ./exemplo1-cliente.pl
A saída do serviço é: Olá Daniel Batista
Mais informações em https://sourceforge.net/projects/soaplite/
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
(Já vimos no navegador)
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● 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
● 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
● 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)
XML, WSDL e SOAP
● 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)
● 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)
● 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 https://www.w3.org/XML/
● 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
● 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 https://www.w3.org/2002/ws/desc/
● WSDL (Web Services Description Language)
● WSDL (Web Services Description Language)<?xml version="1.0" encoding="ISO-8859-1"?>
<definitions xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="urn:server.hello" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="urn:server.hello">
● WSDL (Web Services Description Language)<types>
<xsd:schema targetNamespace="urn:server.hello"
>
<xsd:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
<xsd:import namespace="http://schemas.xmlsoap.org/wsdl/" />
</xsd:schema>
</types>
● 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>
● WSDL (Web Services Description Language)<binding name="server.helloBinding" type="tns:server.helloPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="hello">
<soap:operation soapAction="urn:server.hello#hello" style="rpc"/>
<input><soap:body use="encoded" namespace="urn:server.hello" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/></input>
<output><soap:body use="encoded" namespace="urn:server.hello" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/></output>
</operation>
</binding>
● WSDL (Web Services Description Language)<service name="server.hello">
<port name="server.helloPort" binding="tns:server.helloBinding">
<soap:address location="http://servidor/exemplo1-servico.php"/>
</port>
</service>
</definitions>
● 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
● 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 (e-mail)
● SOAP (Simple Object Access Protocol)
– Três principais características: extensibilidade, neutralidade e independência
● SOAP (Simple Object Access Protocol)
● SOAP (Simple Object Access Protocol)<?xml
version="1.0"
encoding="UTF-8"
?>
● SOAP (Simple Object Access Protocol)<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:server.hello"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
● 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>
● SOAP (Simple Object Access Protocol)
– Bom pela neutralidade
– Melhor ainda quando usando HTTP (infra de rede já configurada)
● 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)
● SOAP (Simple Object Access Protocol)
– Ruim pela verbosidade exigida do HTTP (Tudo usando POST)
– Mais informações em https://www.w3.org/TR/soap/
REST, JSON e UDDI com exemplos
● 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)
● 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
● 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
● 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!
● 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
● 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
● 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
● 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
● REST (Representational State Transfer)
– Tipicamente vai operar sobre HTTP usando os possíveis métodos do protocolo (GET, POST, DELETE, PUT, etc...)
● 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
● Para um serviço web ser RESTfull:
– Ter uma URI (Uniform Resource Identifier) base (http://servidor/recurso/)
– Usar algum formato de mídia da Internet (JSON geralmente é o mais usado mas pode usar XML por exemplo)
● 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
● 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 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
● 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, ...
● 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]
● 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
● 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, ...)
● 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
● Passo 3: escrever o código do serviço [exemplo1-servico-rest.php]
$urls_validas = array("hello");
● Passo 3: escrever o código do serviço $urls_validas = array("hello");
if (isset($_GET["action"]) && in_array($_GET["action"], $urls_validas)) {
● 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"])) {
● 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"]);
● 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";}
}
● Passo 3: escrever o código do serviço else {
$retorno = "Ação inexistente";
}
● Passo 3: escrever o código do serviço else {
$retorno = "Ação inexistente";
}
function hello($nome) {
return 'Olá '. $nome;
}
● Passo 3: escrever o código do serviço else {
$retorno = "Ação inexistente";
}
function hello($nome) {
return 'Olá '. $nome;
}
exit(json_encode($retorno));
● Passo 4: usar o serviço
– Testando pelo navegador● http://servidor/exemplo1-servico-rest.php● http://servidor/exemplo1-servico-rest.php?action=hello● http://servidor/exemplo1-servico-rest.php?
action=hello&nome=Daniel%20Batista
● Passo 4: usar o serviço
– Testando pelo navegador
● Passo 4: usar o serviço
– Testando pelo navegador
● Passo 4: usar o serviço
– Testando pelo navegador
● Passo 4: usar o serviço
– Programando [exemplo1-cliente-rest.php]
$retorno = file_get_contents('http://servidor/exemplo1-servico-rest.php?action=hello&nome=Daniel%20Batista');
● Passo 4: usar o serviço
– Programando
$retorno = file_get_contents('http://servidor/exemplo1-servico-rest.php?action=hello&nome=Daniel%20Batista');
$retorno = json_decode($retorno);
● Passo 4: usar o serviço
– Programando
$retorno = file_get_contents('http://servidor/exemplo1-servico-rest.php?action=hello&nome=Daniel%20Batista');
$retorno = json_decode($retorno);
print_r($retorno);
● Passo 4: usar o serviço
– Programando
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● O que aconteceu “nos bastidores”?
● 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!
● Observações
– Processamento em cima dos métodos do HTTP (desnecessário instalar algum pacote extra)
Uso demasiado do POST não mais!
● Observações
– Dois problemas do SOAP melhorados
– Responsabilidade na hora de escrever os módulos continua
– Possibilidade de testar aos poucos continua
● 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
● JSON (JavaScript Object Notation)
– Fácil para humanos lerem e escreverem
– Fácil para máquinas processarem e gerarem
– Independente de linguagem
● 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)
● JSON (JavaScript Object Notation)
● JSON (JavaScript Object Notation)
● JSON (JavaScript Object Notation)
● JSON (JavaScript Object Notation)
● JSON (JavaScript Object Notation)
● JSON (JavaScript Object Notation){
"id": 1,
"name": "Daniel Batista",
"nota": 7.50,
"tags": ["mestrado", "doutorado"]
}
– Mais informações em http://www.json.org
● 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
● UDDI (Universal Description, Discovery and Integration)
– Foi proposto para receber requisições SOAP e devolver WSDLs dos serviços
– Mais informações em http://uddi.xml.org/uddi-101
● 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
Microserviços e composição de serviços
• 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)
• Microserviços
– Serviços web podem ser esses processos
– Requisições aos serviços podem fazer o papel das APIs
• 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
• Microserviços
– Fáceis de substituir
– Organizados por funcionalidade
– Independente de tecnologia (usar a linguagem que melhor resolve o problema)
• Microserviços
– Uma consequência (mesmo usando REST) é que muitos serviços → mais uso da rede → maior latência na aplicação
• Microserviços
– Mais informações em http://martinfowler.com/articles/microservices.html
• 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
• 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
Alguns exemplos com acesso a BD
• 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)
• 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)
● 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
● Exemplo 2 [exemplo2-servico-rest.php] $urls_validas = array("busca");
● Exemplo 2 $urls_validas = array("busca");
if (isset($_GET["action"]) && in_array($_GET["action"], $urls_validas)) {
● Exemplo 2 $urls_validas = array("busca");
if (isset($_GET["action"]) && in_array($_GET["action"], $urls_validas)) {
if (isset($_GET["nome"])) {
$retorno = busca($_GET["nome"]);}
● 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";}
● Exemplo 2 function busca($nome) {
$mysqli = mysqli_connect("localhost", "usuario", "senha", "professores");
● Exemplo 2 function busca($nome) {
$mysqli = mysqli_connect("localhost", "usuario", "senha", "professores");
mysqli_set_charset($mysqli, 'utf8mb4');
● 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;}
● Exemplo 2 exit(json_encode($retorno));
● Exemplo 2 [exemplo2-cliente-rest.php] $retorno = file_get_contents('http://servidor/exemplo2-servico-rest.php?action=busca&nome=Daniel');
$retorno = json_decode($retorno);
print_r($retorno);
● Exemplo 2
Conclusões e discussão
• 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
• 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
• 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
• 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
• 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
• 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)
• 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)
• Referências– Códigos em http://www.ime.usp.br/~batista/codigos-soa.tar.gz
– Patricia Araujo de Oliveira. Seleção de Serviços Web em Coreografias. 2014. 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. 2013. Dissertação (Mestrado em Ciência da Computação) - Universidade de São Paulo, União Européia. Orientador: Daniel Macêdo Batista.
• ReferênciasObs.: Todas as páginas foram acessadas pela última vez em 28 de Março de 2016
– http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-ra-v1.0-cs01.pdf
– http://www.opengroup.org/soa/source-book/intro/index.htm
– https://pt.wikipedia.org/wiki/Web_service#/media/File:Webservices.png
– https://sourceforge.net/projects/nusoap/files/nusoap-docs/0.9.5/nusoap-docs-0.9.5.zip/download
– http://www.ahowto.net/php/creating-webservice-server-and-client-using-nusoap/
– http://www.java-samples.com/showtutorial.php?tutorialid=1733
• ReferênciasObs.: Todas as páginas foram acessadas pela última vez em 28 de Março de 2016
– https://en.wikipedia.org/wiki/Web_Services_Description_Language#/media/File:WSDL_11vs20.png
– https://en.wikipedia.org/wiki/File:SOAP.svg
– https://en.wikipedia.org/wiki/Web_Services_Description_Language
– https://www.w3.org/TR/2007/REC-soap12-part0-20070427/
– http://www.restapitutorial.com/lessons/whatisrest.html
– http://blog.ijasoneverett.com/2013/02/rest-api-a-simple-php-tutorial/
– http://www.json.org/
• ReferênciasObs.: Todas as páginas foram acessadas pela última vez em 28 de Março de 2016
– http://martinfowler.com/articles/microservices.html
Top Related