Serviços e Microsserviços

Afluentes: Sistemas Distribuídos e Mobile

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

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.

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.

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

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

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

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

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.