Serviços e Microsserviços

De Aulas
Revisão de 10h44min de 30 de agosto de 2021 por Admin (discussão | contribs) (→‎WSDL)

Afluentes: Sistemas Distribuídos e Mobile

Histórico

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"[1].

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[2].


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[3].

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

Requisitos

Os requisitos de uma arquitetura SOA, segundo Singh e Huhns[4] 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.

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[5].
  • 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[6].

SOAP

  • 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

A UDDI (Universal Description, Discovery and Integration) é uma especificação OASIS que tem o objetivo de 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 (Bryan et al., 2002), (Clement et al., 2004). O UDDI 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. Por meio do UDDI, serviços podem ser descobertos e utilizados por outras aplicações, tanto para serviços de acesso público como para serviços disponíveis internamente dentro de uma organização. Um provedor de serviços pode utilizar o UDDI para publicar seus serviços de forma que um consumidor de serviços possa encontrá-lo e utilizá-lo conforme suas necessidades. Por conseguinte, o consumidor obtém os metadados necessários para a invocação do serviço (Bryan et al., 2002). O UDDI é implementado tomando como base a linguagem XML para a descrição da estrutura do documento e o protocolo SOAP para a comunicação entre os clientes e o registro (Swithinbak et al., 2005). Consoante Bryan et al. (2002), as informações de um registro UDDI podem proporcionar pesquisas em: “páginas brancas”, retornando informações básicas tais como endereço, contatos e identificadores de uma organização e seus serviços; “páginas amarelas”, com informações em conformidade com uma categoria e taxonomia; e “páginas verdes” com as informações técnicas da descrição e forma de como executar um serviço web. Um registro UDDI pode ser público ou privado e a sua estrutura é composta de cinco tipos de dados que visa facilitar a rápida localização e entendimento dos diferentes tipos de informações que podem estar contidas no registro (Bellwood et al., 2002). Conforme Ort e Mandava (2002) e Cerami (2002), estas estruturas de dados, citadas a seguir, têm o objetivo de serem utilizadas para a realização dos negócios e de serem acessíveis por identificadores únicos (keys): a estrutura chamada “businessEntity” é relativa as 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; o “businessService” possui informações que descrevem um único serviço web (ou um conjunto de serviços relacionados); o “businessTemplate” possui informações técnicas sobre como acessar um serviço web específico; o “tModel” fornece informações sobre a categoria do serviço, do comportamento, convenções utilizadas, especificações e padrões compatíveis; e, por fim, o “publisherAssertion” fornece um mecanismo básico para relacionar os elementos businessEntity. Para Piazza (2007), um registro UDDI não é uma parte essencial para o funcionamento dos serviços Web, uma vez que ele não descreve um serviço individualmente, mas sim o WSDL do serviço. Contudo, quando muitas organizações estão interagindo em uma ou mais oportunidades de negócios, tornar seus serviços visíveis e públicos se torna de vital importância para este cenário.

Referências

  1. ↑ 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.
  2. ↑ 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.
  3. ↑ STOJANOVIC, Z.; DAHANAYAKE, A. Service-oriented software system engineering: challenges and pratices. Idea Group Inc. Hershely, PA. 2005.
  4. ↑ SINGH, M. P. and HUHNS, M. N. Service-Oriented Computing: Semantics, Processes, Agents. John Wiley & Sons, New York, NY, EUA, 1a. Edição. 2005.
  5. ↑ O'BRIEN, L.; BASS, L.; MERSON, P. Quality Attributes and Service-Oriented Architectures. Technical Note - Software Engineering Institute, Carnegie Mellon University. 2005.
  6. ↑ PAUROBALLY, S.; JENNINGS, N.R. Developing Agent Web Service Agreements. Proceedings of the IEEE/WIC/ACM International Conference on Web Intelligence (WI'05). 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.
Disponível em “https://saulo.arisa.com.br/wiki/index.php?title=Serviços_e_Microsserviços&oldid=7568”