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

O WSDL (Web Service Description Language) é uma linguagem que descreve componentes de softwares na forma de serviços web distribuídos com seus detalhes (localização, forma de invocação, etc.) definido em uma gramática XML (Christensen et al., 2001). Lindemann (2006) afirma que o conceito para a definição de interfaces não é específico do WSDL e já era utilizado por tecnologias tais como CORBA (Common Object Request Broker Architecture) e DCOM (Distributed Component Object Model) que se utilizavam da IDL (Interface Definition Language). Contudo, o WSDL é construído em cima da linguagem XML, possibilitando a validação de um documento WSDL através de um processador XML. A linguagem para descrição de serviços web, WSDL, é derivada do XML e se diferencia das outras linguagens de descrição de interface, tal como a IDL (Interface Description Language) da OMG (OMG, 2002), pelo seu nível de extensibilidade. A linguagem WSDL provê uma linguagem comum para descrever 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 (Cerami, 2002). Christensen et al. (2001) apresenta os elementos WSDL que descreve um serviço Web em conformidade com as seguintes especificações: • 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. A WSDL 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 (Chappell e Jewell, 2002).

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.