Serviços e Microsserviços

De Aulas

Afluentes: Sistemas Distribuídos e Mobile

Contextualização - Cliente-Servidor

  • O modelo de serviço de software é baseado no modelo cliente-servidor
  • O modelo Cliente-Servidor é uma estrutura distribuída de tarefas e carga de trabalho entre servidores (host) de recursos ou serviços para dispositivos computacionais clientes;
  • Os serviços podem estar em dispositivos remotos e/ou no próprio cliente;
  • Exemplos de funcionalidades no servidor: correio eletrônico, páginas web, acesso a banco de dados, etc.;
  • Exemplos de programas clientes: Thunderbird (e-mail), navegador web, Spotify, etc.;
  • A internet é usada como um meio muito comum para disponibilizar programas servidores;
  • Esse modelo é uma das ideias principais da da computação em rede e computação na nuvem;
Modelo cliente-servidor.png

Do lado do Cliente

  1. efetua uma requisição a um servidor por um ip e uma porta usando um protocolo comum
  2. aguarda a resposta (pode ter um timeout)
  3. recebe uma ou mais respostas e as processas
  • Um cliente pode se conectar a vários servidores.

Do lado do Servidor

  1. o computador do servidor inicia o programa servidor
  2. o programa servidor fica ouvindo uma porta, ou melhor aguardando uma requisição de um cliente
  3. um cliente se conecta fazendo uma requisição
  4. o servidor pode, para interagir com vários clientes, criar processos filhos conectados em portas auxiliares para tratar cada conexão
  5. responde a requisição do cliente
  6. fecha a conexão

Problemática

  • Programas servidores podem ouvir em diversas portas diferentes
  • Cada porta é registrada/padronizada para um tipo de protocolo, SSH, POP, IMAP, SMTP, HTTP, etc..
  • Um grande número de serviços fornecido por muitos clientes espalhados no mundo iria requerer uma padronização nova para uma nova porta específica, mas cada servidor poderia ter um grande número de serviços a fornecer, tornando essa forma inviável
  • Computadores servidores necessitam de um gerenciamento de segurança via firewall, sendo necessário bloquear diversas portas que não são necessárias e liberar apenas as que possuem tratamento correto de segurança

Solução

  • Uso da Web na porta 80, ou 443 na versão encriptografada, ou porta 8080 para alguns servidores como Apache Tomcat, Node.JS, etc.
  • os serviços ficam disponibilizados na estrutura de subpastas do servidor web
  • A segurança está no uso de uma conexão segura e gerenciamento de segurança no serviço específico.
  • São chamados de Serviços Web

Serviço Web

  • serviço:
    • componente de software;
    • possui uma implementação bem definida de uma funcionalidade de negócios;
    • possui uma interface de publicação e e descoberta para consumidores de serviços;
    • podem ser agrupados para a criação de diferentes aplicações e processos de negócios utilizando-se de um modelo de comunicação baseado na troca de mensagens com baixo acoplamento[1].
  • Serviços Web:
    • do inglês web service;
    • sistemas de software, ou programas de computador, que buscam a interoperabilidade através da interação entre um computador e uma rede;
    • se comunicam por meio de mensagens baseadas no protocolo HTTP (HiperText Transfer Protocol);


Tplnote Bulbgraph.png

Os serviços web trouxeram um novo paradigma suportando sistemas distribuídos fracamente acoplados com a descoberta e execução de serviços[2].

Arquitetura Orientada a Serviços

Web services.png
  • Service Oriented Architecture - SOA

A Arquitetura Orientada a Serviço "é um paradigma para organização e utilização de competências distribuídas que estão sob o controle de diferentes domínios proprietários"[3].

Ou seja, as pessoas e organizações criam competências para resolver problemas específicos conforme suas necessidades. Estas são modeladas através de um conjunto de componentes que compõe a arquitetura e podem ser invocados por meio da descrição de suas interfaces, que podem ser publicadas e descobertas[4].


Tplnote Bulbgraph.png

O ponto central do paradigma da Engenharia de Sistemas orientados a Objetos (SOSE – Service-Oriented System Engineering) é o conceito de serviço, bem como a estratégia para expor sistema de capacidades para os consumidores como os serviços através do Service-Oriented Architecture (SOA). Neste contexto, a tecnologia de serviços Web é apenas uma maneira de realizar eficientemente os conceitos de serviços e SOA. O serviço faz um acordo contratual entre fornecedor e consumidor. Além de uma interface comum que define operação assinaturas, um serviço também pode ter atributos que lhe são próprias, tais como o acordo de nível de serviço, das políticas, das dependências, e assim por diante[5].

  • Tem como base componentes baseados em serviços.
  • Surgiu para reduzir o tempo, custos e recursos gastos para uma integração rápida e flexivel de sistemas envolvidos nas organizações.
  • Enfoca no aumento da agilidade na implementação de novos produtos e processos e na composição de novos processos por meio da orquestração de componentes já prontos.
  • Orquestração é a configuração, o gerenciamento e a coordenação automatizada de serviços, aplicações e sistemas de computador.
  • Abrange a possibilidade do reuso de sistemas e aplicações legadas.
  • As aplicações de negócio são divididas em funções e processos de negócios individuais, compartilhados, independentes de plataforma e reutilizáveis, chamados de serviços.
  • Para tornar os serviços disponíveis e viabilizados para o uso por terceiros, deve ser disponibilizada uma descrição desse serviço contendo as informações necessárias para a interação com ele, tais como suas entradas, saídas e semânticas associadas.

Os requisitos de uma arquitetura SOA, segundo Singh e Huhns[6] são:

  • Baixo acoplamento: Os serviços da arquitetura não devem ter uma dependência forte entre si.
  • Independência de implementação: Não se deve depender de características específicas de linguagens de programação ou ambientes de execução.
  • Configuração flexível: Os diferentes serviços devem poder ser ligados entre si de forma dinâmica e configurável.
  • Tempo de vida longo: Os serviços devem existir por tempo suficiente para que sejam descobertos e utilizados até se obter confiança em seu comportamento.
  • Granularidade: As funcionalidades de um sistema devem ser divididas em vários serviços.
  • Distribuição: Os serviços devem ficar distribuídos, para aproveitar melhor os recursos computacionais.
  • SOAP (originalmente chamado de Simple Object Access Protocol) - é o protocolo de comunicação entre os serviços web e seus clientes.
  • objetiva uma comunicação leve para trocar informações estruturadas em ambientes distribuídos e descentralizados.
  • possui três elementos principais[7]:
    • o protocolo de comunicação;
    • a descrições dos serviços;
    • e a descoberta de serviços.
  • Utiliza a linguagem XML (Extensible Modeling Language);
  • Usa o WSDL (Web Services Definition Language) para descrever formalmente os serviços web;
  • Usa o XML Schema para especificar a estrutura e os tipos dos dados que estão contidos nas mensagens;
  • Utiliza o UDDI (Universal Descripition, Discovery and Integration) como diretório de registro de serviços, acessados por meio de mensagens SOAP[8].

Mensagens SOAP

Soap message.gif

A estrutura hierárquica das mensagens SOAP, ou Envelopes SOAP, é constituída por dois elementos básicos:

  • Cabeçalho (Header):
    • opcional.
    • suas informações não fazem parte da carga útil do envelope.
    • possui informações de controle que podem ser inspecionados ou alterados no percurso que a mensagem faz na rede por diferentes nós.
  • Corpo (Body):
    • obrigatório.
    • possui a carga útil da mensagem
    • Seu conteúdo pode ser um conjunto de elementos arbitrários ou pode ser a representação de uma RPC (Remote Procedure Call).
    • Também pode conter um elemento de exceção (Fault) para os casos da mensagem representar uma resposta com informações sobre um problema.
  • Os tipos de nós pelas quais as mensagens podem passar são o Emissor, os nós Intermediários e o Receptor Final para a qual a mensagem é destinada.

WSDL (Web Service Description Language)

  • definido em uma gramática XML;
  • descreve componentes de softwares na forma de serviços web distribuídos com seus detalhes (localização, forma de invocação, etc.)[9];
  • descreve os serviços e o meio para integrá-los de forma automática caracterizando-se como uma estrutura de grande importância para o funcionamento dos serviços web[10].
  • permite descrever pontos de acesso e suas mensagens independente do formato da mensagem ou do protocolo de rede utilizado
  • permite tratar as mensagens como descrições abstratas dos dados sendo trocados e permite agrupar os conjuntos das operações na forma de um tipo abstrato, a ser mapeado posteriormente para um protocolo e tipo de dados concretos[11].

Elementos WSDL

  • definitions: Elemento raiz de um documento WSDL.
  • types: Definições de tipos de dados, conforme algum esquema.
  • message: Mensagem representando uma requisição ou uma resposta.
  • portType: Agrupa mensagens em operações em uma interface abstrata, que na nomenclatura WSDL se chama tipo de port.
  • binding: Liga um tipo de port a um protocolo e um formato de dados específicos.
  • service: Declara um serviço, definido por ports, que são combinações de uma ligação com um endereço de rede.

Diretório de Registro de Serviços UDDI

  • Do inglês Universal Description, Discovery and Integration;
  • utiliza como base a linguagem XML;
  • especificação OASIS para definir um conjunto de serviços para suportar a descrição da descoberta de
    • serviços,
    • negócios,
    • outros provedores de serviços
    • e as interfaces para o acesso aos serviços
  • ou seja, é uma forma padrão de publicar e localizar negócios e interfaces de seus serviços em um registro[12].
  • fornece um mecanismo funcional padrão interoperável para ambientes de softwares baseados em serviços web para classificação, catalogação e gerenciamento destes serviços.
  • Um registro UDDI possui cinco tipos de dados para facilitar a rápida localização e entendimento das informações contidas[13]:
    • businessEntity: informações não técnicas conhecidas sobre o negócio (nome, descrição, endereço e informações do contato) e os serviços oferecidos;
    • businessService: descreve um único serviço web (ou um conjunto de serviços relacionados);
    • businessTemplate: informações técnicas sobre como acessar um serviço web específico;
    • tModel: informações sobre a categoria do serviço, do comportamento, convenções utilizadas, especificações e padrões compatíveis;
    • publisherAssertion: fornece um mecanismo básico para relacionar os elementos businessEntity.

Exemplo de Chamada SOA em PHP

<?php
$wsdl = "https://arisa.com.br/~arisa/ws/lib/math.php?wsdl";
$a = 52;
$b = 34;
try {
    $client = new SoapClient($wsdl);
    $ret = $client->__soapCall("sum", array(
        "a" => $a,
        "b" => $b));
    echo $ret . PHP_EOL;
} catch (Exception $e) {
    echo($e->getMessage());
}

Microsserviços

  • Termo criado em 2011 em uma conferência de Arquitetura de Software
  • Representa um estilo de arquitetura de sistemas (e não o tamanho dos serviços)
  • É uma arquitetura orientada a Micro Serviços
  • Objetiva desenvolver sistemas flexíveis, escaláveis e manutenção simples
  • Filosofia: Fazer algo e fazer bem (do inglês: Do One Thing & Do It Well)
  • Assim, os serviços são para realizar uma única função
  • Inspiração: no artigo Unix Time-Sharing System: Forward de 1978.


Tplnote Bulbgraph.png

A arquitetura de micro serviços é utilizada para desenvolver uma aplicação como um conjunto de pequenos serviços, que funcionam com seu próprio processo. Cada serviço é desenvolvido em torno de um conjunto de regras de negócio específicas, e é implementado de forma independente.

Benefícios

  • Maior estabilidade na manutenção e evolução: com apenas uma função, é mais fácil de gerenciar e dar manutenção;
  • Baixo acoplamento e interdependência: manutenção em um serviço não interfere diretamente nas outras funcionalidades do sistema;
  • Escalabilidade: serviços, servidores, máquinas virtuais e containers podem estar organizados de forma independente, possibilitando o crescimento flexível do sistema;
  • Redução de custos: as aplicações só utilizam os serviços necessários;
  • Flexibilidade de tecnologia: os serviços utilizandos não precisam ser da mesma tecnologia nem entre eles nem com o cliente;
  • Facilidade de atualização: ao alterar um serviço, não é necessário reinicializar o sistema todo ou parar o uso de outros serviços;

REST

Tplnote Bulbgraph.png

O termo REST (Representational State Transfer), Transferência de Estado Representaciconal foi descrito originalmente na Tese de Doutorado de Roy Fielding em 2000 como um design de arquitetura de software para servir aplicações em rede, tal como a própria World Wide Web (HTTP 1.1)

  • Hoje é visto como qualquer interface web simples (usando JSON, XML, YAML, texto puro) sob HTTP sem abstrações adicionais de protocolos baseados em padrões de mensagens como SOAP.
  • O REST define um conjunto de restrições a serem utilizadas para se criar serviços Web;
  • Quando os serviços web estão em conformidade com o estilo arquitetural REST, são chamados de RESTful;
  • Fornecem interoperabilidade entre sistemas computacionais conectados na Internet;
  • Recursos Web são qualquer coisa ou entidade que pode ser identificada, nomeada, endereçada ou manipulada na Web
  • No modelo RESTful:
    • solicitações feitas a um URI de um recurso deve provocar uma resposta com uma carga útil formatada em HTML, JSON, XML ou outro formato;
    • respostas devem fornecer links de hipertexto para outros recursos;
    • No HTTP é possível o uso dos métodos vistos na última aula: GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS e TRACE.
  • Sistemas RESTful buscam:
    • desempenho,
    • confiabilidade
    • e capacidade de crescimento rápido
  • Reutilizam componentes que podem ser gerenciados e atualizados sem afetar o sistema como um todo, mesmo enquanto em execução.
  • Existem diversas Implementações públicas

Princípios

  • Protocolo Cliente/Servidor sem estado: as mensagens HTTP contém toda informação necessária para a requisição, não sendo necessário armazenar o estado das comunicações no cliente, nem no servidor.
  • Operações bem definidas: o HTTP tem seus métodos POST, GET, PUT e DELETE bem definidos para gerenciar as operações CRUD de persistência de dados de uma aplicação.
  • Sintaxe padrão e universão: os recursos são identificados pelas suas URIs específicas;
  • Utilização de hipermídia: sendo que é baseado tipcamente no HTML ou XML, é possível navegar de um recurso REST a outros por meio de links.

Exemplos de Consumo de serviços REST

REST vs SOAP

REST vs SOAP[14]
REST SOAP
Origem Criado em 2000 por Roy Fielding como um trabalho acadêmico. Criado em 1009 por Dave Winer e outros em colaboração com a Microsoft.
Conceito Básico Disponibiliza dados na forma de recursos (nouns), tais como "user" ou "invoice". Disponibiliza dados na forma de serviços (verb + noun), tais como "getUser" ou "PayInvoice".
Prós
  • Segue a filosofia da Open Web;
  • Implementação e manutenção relativamente fácil;
  • Separação clara da implementação de cliente e servidor;
  • A comunicação não é controlada por uma única entidade;
  • Informações podem ser armazenadas no cliente para previnir múltiplas chamadas;
  • Pode retornar múltiplos formatos de dados (JSON, XML, YAML, etc.).
  • Segue uma abordagem empresarial formal;
  • Trabalha no topo de qualquer protocolo de comunicação, mesmo que assíncrono;
  • Informações sobre objetos são comunicados aos clientes;
  • Segurança e autorização fazem parte do protocolo;
  • Pode ser descrito totalmente usando o WSDL.
Contra
  • Só trabalha no topo do protocolo HTTP;
  • É difícil impor autorização e segurança em cima do HTTP;
  • Gasta muita banda na comunicação de metadados;
  • Difícil de implementar e não é muito popular entre os desenvolvedores Web e Mobile;
  • Só usa a linguagem XML;
Quando usar
  • Quando clientes e servidores estão na Web;
  • Quando as informações sobe os objetos não necessitam ser comunicadas aos clientes;
  • Quando clientes precisam acessar objetos disponíveis nos sevidores;
  • Quando é necessário um contrato formal entre cliente e servidor;
Quando não usar
  • Quando é necessário um contrato entre cliente e servidor;
  • Quando as transações envolvem múltiplas chamadas;
  • Quando a maioria dos desenvolvendores necessitam uma API fácil de usar;
  • Quando a largura de banda é limitada;
Casos de uso comum
  • Serviços de mídia social;
  • Redes Sociais;
  • Serviços de Web Chat;
  • Serviços móveis.
  • Serviços de finanças;
  • Portais de pagamento;
  • Serviços de telecomunicações.
Exemplos Populares
  • API Twitter;
  • API Linkedin.
  • API SOAP Paypal;
  • API SOAP Clickatell SMS.

Referências

  1. ↑ O'BRIEN, L.; BASS, L.; MERSON, P. Quality Attributes and Service-Oriented Architectures. Technical Note - Software Engineering Institute, Carnegie Mellon University. 2005.
  2. ↑ PAUROBALLY, S.; JENNINGS, N.R. Developing Agent Web Service Agreements. Proceedings of the IEEE/WIC/ACM International Conference on Web Intelligence (WI'05). 2005.
  3. ↑ ESTEFAN, J. A.; LASKEY, K.; MCCABE, F.; THORNTON, D. Reference Architecture for Services Oriented Architecture Version 1.0. OASIS. Disponível em: <http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf>. Acessado em: 10 dez. 2008.
  4. ↑ BOOTH, D.; HAAS, H.; MCCABE, F.; NEWCOMER, E.; et al. Web Services Architecture. Disponível em: <http://www.w3.org/TR/ws-arch/> Acessado em Fevereiro/2009. 2004.
  5. ↑ STOJANOVIC, Z.; DAHANAYAKE, A. Service-oriented software system engineering: challenges and pratices. Idea Group Inc. Hershely, PA. 2005.
  6. ↑ SINGH, M. P. and HUHNS, M. N. Service-Oriented Computing: Semantics, Processes, Agents. John Wiley & Sons, New York, NY, EUA, 1a. Edição. 2005.
  7. ↑ HAAS, H; e BROWN, A.; 2004. Web Services Glossary. Disponível em: <http://www.w3.org/TR/ws-gloss/>, Acessado em Dez/2008.
  8. ↑ WANG, H., HUANG, J. Z., QU, Y., e XIE, J. Web services: problems and future directions. Journal of Web Semantics, 1(3):241–320. 2005.
  9. ↑ CHRISTENSEN, E.; CURBERA, F.; MEREDITH, G.; WEERAWARANA, S. Web Services Description Language (WSDL) 1.1. <http://www.w3.org/TR/wsdl>. Accessed in Mar/2009. 2001.
  10. ↑ CERAMI, E. Web Services Essentials. O’Reilly & Associates, Sebastopol, CA, EUA, 1a. edição. 2002.
  11. ↑ CHAPPELL, D. A. e JEWELL, T. Java Web Services. O’Reilly & Associates, Sebastopol, CA, EUA. 1a. Edição. 2002.
  12. ↑ BRYAN, D.; DRALUK, V.; EHNEBUSKE, D.; GLOVER, T.; et al. UDDI Version 2.04 API Specification. Dipsonível em: <http://uddi.org/pubs/ProgrammersAPI_v2.htm>. Acessado em Março/2009. 2002.
  13. ↑ ORT, E.; MANDAVA, R. Web Services Developer Pack Part 1: Registration and the JAXR API. The Java Web Services Developer Pack. <http://java.sun.com/developer/technicalArticles/WebServices/WSPack>. Accessed in Mai/2009. 2002.
  14. ↑ https://nordicapis.com/rest-vs-soap-nordic-apis-infographic-comparison/
Disponível em “https://saulo.arisa.com.br/wiki/index.php?title=Serviços_e_Microsserviços&oldid=7613”