Mudanças entre as edições de "Serviços e Microsserviços"

De Aulas
Linha 73: Linha 73:
 
* Para tornar os serviços disponíveis e viabilizados para o uso por terceiros, dev 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.
 
* Para tornar os serviços disponíveis e viabilizados para o uso por terceiros, dev 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<ref>SINGH, M. P. and HUHNS, M. N. Service-Oriented Computing: Semantics, Processes, Agents. John Wiley & Sons, New York, NY, EUA, 1a. Edição. 2005.</ref> são:
Os requisitos de uma arquitetura SOA, segundo Singh e Huhns<ref>SINGH, M. P. and HUHNS, M. N. Service-Oriented Computing: Semantics, Processes, Agents. John Wiley & Sons, New York, NY, EUA, 1a. Edição. 2005.</ref> são:
 
  
 
* '''Baixo acoplamento''': Os serviços da arquitetura não devem ter uma dependência forte entre si.
 
* '''Baixo acoplamento''': Os serviços da arquitetura não devem ter uma dependência forte entre si.

Edição das 13h41min de 30 de agosto de 2021

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 ddas ideias principais da da computação em rede e computação na nuvem;

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

  • 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, dev 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

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 umaresposta.
  • portType: Agrupa mensagens em operações em uma interfaceabstrata, que na nomenclatura WSDL se chama tipo de port.
  • binding: Liga um tipo de port a um protocolo e um formato dedados específicos.
  • service: Declara um serviço, definido por ports, que sãocombinaçõ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.

REST

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.