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

De Aulas
Linha 97: Linha 97:
 
== Diretório de Registro de Serviços UDDI ==
 
== Diretório de Registro de Serviços UDDI ==
  
−
A UDDI (Universal Description, Discovery and Integration) é
+
* Do inglês ''Universal Description, Discovery and Integration'';
−
uma especificação OASIS que tem o objetivo de definir um conjunto de
+
* utiliza como base a linguagem XML;
−
serviços para suportar a descrição da descoberta de serviços, negócios,
+
* especificação OASIS para definir um conjunto de serviços para suportar a descrição da descoberta de
−
outros provedores de serviços e as interfaces para o acesso aos serviços,
+
** serviços,
−
ou seja, é uma forma padrão de publicar e localizar negócios e interfaces
+
** negócios,
−
de seus serviços em um registro (Bryan et al., 2002), (Clement et al.,
+
** outros provedores de serviços
−
2004).
+
** e as interfaces para o acesso aos serviços
−
O UDDI fornece um mecanismo funcional padrão interoperável
+
* ou seja, é uma forma padrão de publicar e localizar negócios e interfaces de seus serviços em um registro<ref>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.</ref>.
−
para ambientes de softwares baseados em serviços web para
+
* 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.
−
classificação, catalogação e gerenciamento destes serviços. Por meio do
+
 
−
UDDI, serviços podem ser descobertos e utilizados por outras
+
* Um registro UDDI possui cinco tipos de dados para facilitar a rápida localização e entendimento das informações contidas<ref>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.</ref>:
−
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 é
 
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
 
composta de cinco tipos de dados que visa facilitar a rápida localização
Linha 131: Linha 118:
 
estruturas de dados, citadas a seguir, têm o objetivo de serem utilizadas
 
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
 
para a realização dos negócios e de serem acessíveis por identificadores
−
únicos (keys): a estrutura chamada “businessEntity” é relativa as
+
únicos (keys):  
−
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
+
* '''businessEntity''': informações não técnicas conhecidas sobre o negócio (nome, descrição,
−
“businessService” possui informações que descrevem um único serviço
+
endereço e informações do contato) e os serviços oferecidos;
−
web (ou um conjunto de serviços relacionados); o “businessTemplate”
+
* '''businessService''': descreve um único serviço web (ou um conjunto de serviços relacionados);
−
possui informações técnicas sobre como acessar um serviço web
+
* '''businessTemplate''': informações técnicas sobre como acessar um serviço web específico;
−
específico; o “tModel” fornece informações sobre a categoria do serviço,
+
* '''tModel''': informações sobre a categoria do serviço, do comportamento, convenções utilizadas, especificações e padrões compatíveis;
−
do comportamento, convenções utilizadas, especificações e padrões
+
* '''publisherAssertion''': fornece um mecanismo básico para relacionar os elementos businessEntity.
−
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 =
 
= Referências =

Edição das 10h54min de 30 de agosto de 2021

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

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


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):

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

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.
  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.
Disponível em “https://saulo.arisa.com.br/wiki/index.php?title=Serviços_e_Microsserviços&oldid=7570”