SOA (Service-Oriented Architecture) - Conceitos e Aplicação · 2016-04-08 · Conceitos básicos...

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


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


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



$server->configureWSDL('server.hello', 'urn:server.hello');



$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');


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


– Testando pelo navegador


– Programando [exemplo1-cliente.php]

require_once('nusoap/nusoap.php');


– 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'));





$saida = $cliente->call('hello', array('Daniel Batista'));

print_r($saida);


– Programando

Documentação em https://sourceforge.net/projects/nusoap/files/nusoap-docs/


– Programando

apt-get install perl libsoap-lite-perl (na verdade esse seria o passo 2)


– Programando [exemplo1-cliente.pl] use SOAP::Lite;


– Programando use SOAP::Lite;

my $url = 'http://servidor/exemplo1-servico.php?wsdl';




my $service = SOAP::Lite->service($url);




my $service = SOAP::Lite->service($url);

print "A saída do serviço é: ", $service->hello("Daniel Batista"), "\n";


– 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”?


(Já vimos no navegador)

● 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)


– 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)


– 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


– 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)<?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


– 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)


– Três principais características: extensibilidade, neutralidade e independência

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


– Bom pela neutralidade

– Melhor ainda quando usando HTTP (infra de rede já configurada)


– Ruim por usar XML tanto para mensagens pequenas quanto para transportar binários

● Necessário usar SOAP Message Transmission Optimization Mechanism (MTOM)


– 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)


– 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


– Interoperabilidade fácil

– Maior responsabilidade na hora de escrever e manter os ``módulos'', por isso importante serem pequenos


– 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


– 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


– 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


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


– 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


– 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


– 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, ...


– 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)) {



if (isset($_GET["nome"])) {




$retorno = hello($_GET["nome"]);




$retorno = hello($_GET["nome"]);}

else {

$retorno = "Nome faltando";}

}

● Passo 3: escrever o código do serviço else {

$retorno = "Ação inexistente";

}



}



}



}



}

exit(json_encode($retorno));


– 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


– Testando pelo navegador


– Programando [exemplo1-cliente-rest.php]

$retorno = file_get_contents('http://servidor/exemplo1-servico-rest.php?action=hello&nome=Daniel%20Batista');


– Programando


$retorno = json_decode($retorno);


– Programando



print_r($retorno);


– Programando

● 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


– Fácil para humanos lerem e escreverem

– Fácil para máquinas processarem e gerarem

– Independente de linguagem


– 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){

"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


– Foi proposto para receber requisições SOAP e devolver WSDLs dos serviços

– Mais informações em http://uddi.xml.org/uddi-101


– 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");





$retorno = busca($_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');


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


– 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/


– http://martinfowler.com/articles/microservices.html

SOA (Service-Oriented Architecture) - Conceitos e Aplicação · 2016-04-08 · Conceitos básicos...

Documents

Transcript of SOA (Service-Oriented Architecture) - Conceitos e Aplicação · 2016-04-08 · Conceitos básicos...