Introdução às tecnologias Web Services: SOA, SOAP, WSDL e UDDI - Parte1  Leia mais em: Introdução às tecnologias Web Services: SOA, SOAP, WSDL e UDDI - Parte1
Autor: Amarildo Matos | Publicado: 2016-02-24T14:00:00-08:00


devmedia.com.br/introducao-as-tecnologias-web-services-soa-soap-wsdl-e-uddi-parte1/2873

Acima o Link da Fonte descrita Abaixo 










Antes de nos aprofundarmos nos conceitos e tecnologia de web 
services, vejamos um pouco sua evolução. No ano de 2000, a W3C (World 
Wide Web Consortium) aceitou a submissão do Simple Object Access 
Protocol (SOAP). Este formato de mensagem baseado em XML estabeleceu uma
 estrutura de transmissão para comunicação entre aplicações (ou entre 
serviços) via HTTP. Sendo uma tecnologia não amarrada a fornecedor, o 
SOAP disponibilizou uma alternativa atrativa em relação aos protocolos 
proprietários tradicionais, tais como CORBA e DCOM.
&nbsp;&nbsp;&nbsp;No decorrer do ano seguinte, o W3C publicou a especificação WSDL. 
Uma nova implementação do XML, este padrão forneceu uma linguagem para 
descrever a interface dos web services. Posteriormente suplementada pela
 especificação UDDI (Universal Description, Discovery and Integration), 
que proporcionou um mecanismo padrão para a descoberta dinâmica (dynamic
 discovering) de descrições de serviço, a primeira geração da plataforma
 de Web services foi estabelecida. A&nbsp;Figura 1&nbsp;ilustra em alto nível o relacionamento entre estes padrões.

Figura 1: O relacionamento entre especificações de primeira geração

Is accessed using: é acessado utilizando;
Enables discovery of: permite a descoberta de;
Describes: descreve;
Enables communication between: permite a comunicação entre;
Binds to: ligação para.

Desde então, os web services foram adotados por vendedores e 
fabricantes num ritmo considerável. Suporte amplo da indústria seguiu-se
 à popularidade e importância desta plataforma e de princípios de 
projeto orientados a serviço. Isto levou à criação de uma segunda 
geração de especificação de Web services.

Web services e a arquitetura orientada a serviços (SOA)
Entendendo serviços
O conceito de serviços em uma aplicação existe faz algum tempo. 
Serviços, assim como componentes, são considerados blocos de construção 
independentes, os quais coletivamente representam um ambiente de 
aplicação. No entanto, diferente de componentes tradicionais, serviços 
têm algumas características únicas que lhes permitem participar como 
parte de uma arquitetura orientada a serviços.
Uma destas características é a completa autonomia em relação a outros
 serviços. Isto significa que cada serviço é responsável por seu próprio
 domínio, o que tipicamente significa limitar seu alcance para uma 
função de negócio específica (ou um grupo de funções relacionadas).
Este enfoque de projeto resulta na criação de unidades isoladas de 
funcionalidades de negócio ligadas fracamente entre si. Isto é possível 
por causa da definição de uma estrutura padrão de comunicação. Devido à 
independência que esses serviços desfrutam dentro desta estrutura, a 
lógica de programação que encapsulam não tem necessidade de obedecer a 
nenhuma outra plataforma ou conjunto de tecnologias.
XML Web services
O tipo de serviço mais largamente aceito e bem sucedido é o XML Web 
service, que será daqui em diante chamado apenas de web service, ou 
simplesmente service. Este tipo de serviço possui dois requisitos 
fundamentais:

comunica-se via protocolos internet (normalmente HTTP);
envia e recebe dados formatados como documentos XML.

A ampla aceitação do web service resultou no surgimento de um 
conjunto de tecnologias suplementares que se tornaram um padrão de fato.
 Assim ao desenvolver nossos web services devemos considerar o uso de 
tecnologias que:

forneça uma descrição de serviço que, no mínimo, consista de um documento WSDL;
seja capaz de transportar documentos XML utilizando SOAP sobre HTTP.

Estas tecnologias não modificam a funcionalidade do núcleo de um 
serviço web, tanto como o faz sua habilidade para se representar e 
comunicar num modo padrão. Muitas das convenções de arquitetura 
expressadas neste artigo assumem que SOAP e WSDL fazem parte da 
estrutura de web services descrita.
Além disto, é normal que um Web service seja:

capaz de agir como o solicitante e o provedor de um serviço;
registrado com um discovery agent através do qual possam ser localizados.

Numa conversação típica com um web service, o cliente iniciador do pedido é um web service também. Como mostrado na&nbsp;Figura 2,
 qualquer interface exposta por este client service também o qualifica 
como um serviço a partir do qual outros serviços podem solicitar 
informação. Posto isto, web services não se encaixam no modelo clássico 
de cliente-servidor. Na verdade, eles tendem a estabelecer um sistema 
ponto-a-ponto, onde cada serviço pode atuar como cliente ou servidor.

Figura 2: Troca de papéis do Web services durante uma conversação

Now I´m like a client: agora sou um cliente;
Now I´m like a server: agora sou um servidor;
Service: serviços;
Could you do this for me: poderia fazer isso por mim?;
Ok, i´ll get right on it: Ok;
Now I´ve got to ask you to do something: agora eu gostaria de lhe pedir algo;
Yeah, alright. I´ll take care of if: Tudo bem, é só falar.

Service-oriented architecture (SOA)
Como mencionado anteriormente, adicionar uma aplicação com uns poucos
 web services não é nenhum problema. Esta integração limitada pode ser 
apropriada para uma experiência de aprendizado, ou para complementar a 
arquitetura de uma aplicação existente com uma peça de funcionalidade 
baseada em serviços que atende a um requisito específico do projeto. No 
entanto, isto não estabelece uma arquitetura orientada a serviço. Existe
 uma clara diferença entre:

uma aplicação que usa web service;
uma aplicação baseada numa arquitetura orientada a serviços.

Uma SOA é um modelo de projeto com um conceito profundamente amarrado
 à questão do encapsulamento de aplicação. A arquitetura resultante 
estabelece essencialmente um paradigma de projeto, no qual web services 
são os blocos de construção chave. Isto quer dizer que ao migrar a 
arquitetura da sua aplicação para uma SOA, estabelece-se um compromisso 
com os princípios de projeto de web services e a tecnologia 
correspondente, como partes fundamentais do seu ambiente técnico.
Uma SOA baseada em XML web service é construída sobre camadas de 
tecnologia XML estabelecidas, focada em expor a lógica de aplicação 
existente como um serviço fracamente acoplado. Para apoiar este modelo, 
uma SOA promove o uso de um mecanismo de discovery por serviços via um 
service broker ou discovery agent.
A&nbsp;Figura 3&nbsp;mostra como uma SOA altera a arquitetura 
multicamada existente, ao introduzir uma camada lógica que, através do 
uso de interfaces programáticas padrão (providas pelo web services), 
estabelece um ponto comum de integração. Esta camada de integração de 
serviços constitui a base para um novo modelo que pode se estender além 
do escopo de uma única aplicação, unificando plataformas legadas 
díspares em um ambiente aberto. Quando web services são utilizados para 
integração cruzada de aplicações (ver&nbsp;Figura&nbsp;4), elas se estabelecem como parte da infra-estrutura do sistema.

Figura 3: Uma representação lógica de uma arquitetura orientada a serviços

Presentation: apresentação;
Integration: integração;
Business: negócio;
Data: dado;
Service interface: interface de serviço.


Figura 4: Uma representação lógica de uma arquitetura de integração orientada a serviço
É importante se conscientizar quanto ao acréscimo de complexidade de 
projeto introduzido pelo SOA. Mais ainda do que em um ambiente n-camada,
 projetistas de aplicação devem considerar de uma forma completa como a 
introdução de serviços vai afetar dados existentes e modelos de negócio.
Na medida em que a utilização de serviços se diversifica, o 
significado dos requisitos de segurança e escalabilidade são 
amplificados. Ambientes orientados a serviço bem projetados tentarão 
vencer estes desafios com infra-estrutura adequada, ao invés de utilizar
 soluções sob medida, específicas de aplicação
Os papéis e cenários ilustrados nas próximas duas seções estão 
limitados somente ao assunto web service. A estrutura de mensagens SOAP 
subjacente será explicada em separado, no próximo artigo desta série.

Papéis web service
Serviços podem assumir diferentes papéis quando envolvidos em 
diversos cenários de interação. Dependendo do contexto pelo qual é 
visualizado, assim como o estado da tarefa rodando no momento, o mesmo 
web service pode trocar de papéis ou ser designado para múltiplos papéis
 simultâneos:
Provedor de serviços
Agindo como um provedor de serviços, um web service expõe uma 
interface pública através da qual pode ser chamado por solicitantes do 
serviço. Um provedor de serviços disponibiliza esta interface publicando
 uma descrição do serviço. Num modelo cliente-servidor, o provedor de 
serviço pode ser comparado ao servidor.
O termo “provedor de serviço” pode também ser usado para descrever a organização ou ambiente que hospeda (provê) o web service.
Um provedor de serviço pode também agir como um solicitante de 
serviço. Por exemplo, um web service pode atuar como um provedor de 
serviço quando um solicitante de serviço lhe pede para executar uma 
função. Pode então atuar como um solicitante de serviço quando mais 
tarde contata o solicitante de serviço original (agora agindo como um 
provedor de serviço) para solicitar informação de status.
Solicitante de serviço
Um solicitante de serviço é o remetente de uma mensagem web service 
ou o programa de software solicitando um web service específico. O 
solicitante de serviço é comparável ao cliente dentro de um modelo 
cliente-servidor padrão. Solicitantes de serviços são às vezes chamados 
de consumidores de serviços.
Um solicitante de serviço pode também ser um provedor de serviço. Por
 exemplo, num modelo de solicitação e resposta, o web service iniciador 
primeiro age como um solicitante de serviço ao requerer informações do 
provedor de serviço. O mesmo web service então, faz o papel de um 
provedor de serviço ao responder à solicitação original.
Intermediário
O papel de intermediário é assumido pelo web service quando ele 
recebe a mensagem de um solicitante de serviço e a passa adiante para o 
provedor de serviço. Neste caso, ele&nbsp;&nbsp;pode também agir como um provedor 
de serviço (recebendo a mensagem) e como um solicitante de serviço 
(passando adiante a mensagem).
Intermediários podem existir em muitas formas diferentes. Alguns são 
passivos e simplesmente re-transmitem ou roteam as mensagens, enquanto 
outros processam ativamente uma mensagem antes de repassá-la. 
Tipicamente, aos intermediários só é permitido o processamento e 
modificação do cabeçalho da mensagem. Para preservar a integridade da 
mensagem, seus dados não devem ser alterados.
Remetente inicial
Como o web service responsável por iniciar a transmissão da mensagem,
 remetentes iniciais também podem ser considerados solicitantes de 
serviço. Este termo existe para ajudar a diferenciar o primeiro web 
service que envia uma mensagem, dos intermediários também qualificados 
como solicitantes de serviço.
Receptor final
O último Web service a receber uma mensagem é o receptor final. Estes
 serviços representam o destino final de uma mensagem e também podem ser
 considerados provedores de serviço.

Interação web service
Quando mensagens são passadas entre dois ou mais web services, uma 
variedade de cenários de interação pode acontecer. A seguir, termos 
comuns utilizados para identificar e etiquetar estes cenários serão 
apresentados.
Caminho da mensagem
A rota pela qual a mensagem viaja é o caminho da mensagem. Deve 
consistir de um remetente inicial e um receptor final e pode conter 
nenhum, um, ou mais de um intermediários. A&nbsp;Figura 5&nbsp;ilustra um caminho de mensagem simples.
O caminho de transmissão atual percorrido por uma mensagem pode ser 
dinamicamente determinado por roteadores intermediários. A lógica de 
roteamento pode ser ativada em resposta à carga de requisitos de 
balanceamento, ou pode ser baseada nas características da mensagem e 
outras variáveis lidas e processadas pelo intermediário em tempo de 
execução. A&nbsp;Figura 6 descreve como uma mensagem é 
enviada via um ou dois caminhos de mensagem possíveis, tal como é 
determinado pelo roteador intermediário.

Figura 5: Um caminho de mensagem formado por três Web services

Message path: caminho da mensagem.


Figura 6: Uma mensagem dinamicamente determinada por um roteador intermediário

Dynamically determined message path: caminho da mensagem determinada dinamicamente.


Padrão de troca de mensagens
Serviços que interagem em um ambiente orientado a serviços 
tipicamente se enquadram em determinados padrões de troca de mensagens. 
Padrões típicos incluem:

solicite e responda (request and response);
publique e subscreva (publish and subscribe);
fire and forget - um para um;
fire and forget - um para muitos ou difusão;

O padrão pedido e resposta é o mais comum quando se está simulando 
intercâmbio de dados síncronizados. Os demais padrões são usados 
principalmente para facilitar transferência de dados assíncrona.
Correlação
Correlação (Correlation) é a técnica utilizada para casar mensagens 
enviadas através de caminhos de mensagem diferentes. É comumente 
empregada num padrão de intercâmbio de pedido e resposta de mensagem, 
onde a mensagem de resposta deve estar associada à mensagem original que
 iniciou a solicitação. Embutir valores de ID sincronizados dentro de 
mensagens relacionadas é uma técnica frequentemente utilizada para 
conseguir correlação.
Coreografia
Regras que governam características de comportamento relacionadas à 
forma como um grupo de web services interagem podem ser aplicadas como 
uma coreografia (choreography). Estas regras incluem a seqüência na qual
 web services podem ser chamados, condições que se aplicam à seqüência 
que está sendo transportada e o padrão de uso que irá definir os 
cenários de interação permitidos. O escopo de uma coreografia está 
tipicamente amarrado ao de uma atividade ou tarefa (ver exemplo na&nbsp;Figura 7).

Figura 7: A seqüência de interação de um grupo de serviços sendo comandados por uma coreografia

Correlation: correlação.


Atividade
Padrões de intercâmbio de mensagens formam a base para atividades de 
serviços (também conhecidos como tarefas). Uma atividade consiste de um 
grupo de web services que interagem e colaboram para realizar uma função
 ou um grupo lógico de funções. A&nbsp;Figura 8&nbsp;mostra uma 
atividade de serviço simples. A diferença entre uma coreografia e uma 
atividade está no fato de que a atividade é geralmente associada com uma
 função de aplicação específica, tal como a execução de uma tarefa de 
negócio.

Figura 8: Uma atividade de serviço envolvendo três serviços

Activity: atividade.


Descrição da estrutura de web services
Um web service é descrito através de uma coleção de documentos de 
definição. Estes atuam como blocos de construção para uma descrição de 
serviço:

Abstrato + Concreto = Definição de Serviço;
Definição de Serviço + Definições Complementares = Descrição de Serviço.

A&nbsp;Figura 9&nbsp;ilustra a relação entre esses documentos.

Figura 9: Conteúdo de uma descrição de serviço

Service description: descrição do serviço;
Service definifion: definição do serviço;
Supplementary definitions: definições suplementares;
Abstract: abstrato;
Concret: concreto;
service interface definition: definição da interface do serviço;
service implementation definition: definição da implementação do serviço.

Abstrato
A descrição de uma interface web service, independente dos detalhes 
de implementação, é chamada de abstrato (abstract). Descrições deste 
elemento são fornecidas adiante neste artigo, como parte do tutorial do 
WSDL.
Concreto
Localização e informação de implementação específicas sobre um web 
service constituem as partes concretas (concrete) de um documento WSDL. 
Elas são representadas pelos elementos de ligação (binding), serviço 
(service) e ponto-de-término (endpoint ou port).
Definição de serviço
Geralmente, o conteúdo de um documento WSDL constitui uma definição 
de serviço (service definition) que inclui as definições da interface 
(abstrato) e da implementação (concreto).
Descrição de serviço
Frequentemente, uma descrição de serviço é um único documento WSDL 
que fornece uma definição de serviço. No entanto, pode também incluir 
vários documentos de definição adicionais que irão fornecer informações 
complementares.

Introdução aos web services de primeira geração
A estrutura W3C para web services está fundamentada em três especificações XML fundamentais:

Linguagem para definição de web service (Web Services Definition Language - WSDL);
Simple Object Access Protocol (SOAP);
Universal Description, Discovery, and Integration (UDDI).

Estes padrões de tecnologia, acoplados aos princípios de projeto 
orientado a serviço, formam um SOA fundamentado na tecnologia XML. Esta 
arquitetura de web services de primeira geração permite a criação de web
 services independentes capazes de encapsular unidades isoladas de 
funcionalidades de negócio. Esta tecnologia tem também algumas 
limitações, que tem sido contempladas numa segunda geração de 
especificações. A seção a seguir, fornece um tutorial introdutório para a
 tecnologia WSDL. SOAP e UDDI serão vistos no próximo artigo da série.

Linguagem para definição de Web Services (WSDL)
Web services devem ser definidos numa forma consistente para que 
possam ser descobertos e “interfaceados” com outros serviços e 
aplicações. A WSDL é uma especificação W3C que fornece a linguagem mais 
avançada para a descrição de definições de web services.
A camada de integração introduzida pela&nbsp;estrutura&nbsp;de web services 
estabelece um padrão, universalmente reconhecido e com interface 
programática suportada. Tal como mostrado na&nbsp;Figura 10, WSDL permite a comunicação entre essas camadas ao fornecer descrições padronizadas.

Figura 10: Documentos WSDL representando aplicações web services

Application: aplicação;
Integration layer: camada de integração;
WSDL document providing the service interface for application b: 
documento WSDLl provendo a interface para o serviço da aplicação b;
WSDL document providing the service interface for application a: 
documento WSDL provendo a interface para o serviço da aplicação a.

A melhor forma de entender como é definido um web service e como ele é
 expresso por um documento WSDL, é caminhar através de cada construtor 
que coletivamente representa essa definição. Comecemos com o 
elemento&nbsp;definitions&nbsp;raiz, o qual age como o conteiner para a definição 
do serviço (ver&nbsp;Listagem 1).
Listagem 1:&nbsp;Uma definição de serviço, tal como é expressa pelo construtor definitions


 
 ...
 
 
 ...
 
 
 ...
 
 
 ...
 


Uma definição WSDL pode conter coleções dos seguintes construtores primários:

Interface;
Message;
Service;
Binding.

A&nbsp;Figura 11&nbsp;ilustra como os primeiros dois 
construtores representam a definição da interface de serviço e os 
últimos dois fornecem os detalhes de implementação do serviço.

Figura 11: O conteúdo de um documento WSDL, tal como se relaciona com uma definição de serviço

Web service definition: definição do web service;
WSDL document: documento WSDL.


Definição de interface abstrata
Interfaces de web services individuais são representadas por 
elementos&nbsp;interface&nbsp;WSDL. Estes construtores contêm um grupo de 
operações lógicas correlatas. Numa arquitetura baseada em componentes, 
um elemento&nbsp;interface&nbsp;WSDL é análogo à interface do componente. Uma 
operação, portanto, é equivalente a um método de componente, por 
representar uma única ação ou função. A&nbsp;Listagem 2&nbsp;apresenta um exemplo de interface.
Listagem 2:&nbsp;Uma interface representada pelo elemento interface


 
  
  ...
  
 


Um elemento&nbsp;operation&nbsp;típico consiste de um grupo de mensagens de 
entrada e saída correlatas. A execução de uma operation requer a 
transmissão ou intercâmbio destas mensagens entre o serviço solicitante e
 o provedor de serviço.
Mensagens operation são representadas por construtores&nbsp;message&nbsp;que 
são declarados sob os elementos&nbsp;definitions. Os nomes das mensagens são 
então referenciados nos elementos filho das 
operation&nbsp;input&nbsp;ou&nbsp;output&nbsp;(ver&nbsp;Listagem 3).
Listagem 3:&nbsp;O elemento input dentro do construtor operation referenciando um bloco de mensagem


 
 ...
 
 
  
   
  
 


Um elemento&nbsp;message&nbsp;pode conter um ou mais parâmetros input ou output
 que pertencem a uma operation. Cada elemento&nbsp;part&nbsp;define um destes 
parâmetros. Ele fornece um conjunto nome/valor (name/value), junto com o
 tipo de dado associado. Em uma arquitetura baseada em componentes, 
um&nbsp;part&nbsp;WSDL equivale a um parâmetro de input ou output (ou um valor de 
retorno) de um método de componente (ver&nbsp;Listagem 4).
Listagem 4:&nbsp;Um bloco de mensagem com um construtor part representando parâmetros operation


 
  
   Field Guide
  
  
   Mr. T
  
 


A seguir, um breve resumo dos construtores fundamentais que podem ser
 montados para estabelecer uma definição de interface abstrata:

Interfaces: representam interfaces de serviço e podem conter múltiplos operations;
Operations: representam uma função web service e podem referenciar múltiplas messages;
Messages: representam uma coleção de parâmetros input ou output e podem conter múltiplas parts;
Parts: representam parâmetros de dados operation tanto de chegada como de partida.


Definição concrete (implementação)
Sobre os detalhes de implementação, usando os elementos descritos 
nesta seção, um documento WSDL pode estabelecer detalhes “concrete” de 
ligação para protocolos, tais como SOAP e HTTP.
Dentro de um documento WSDL, o elemento&nbsp;service&nbsp;representa um ou mais
 pontos-de-término nos quais o web service pode ser acessado. Estes 
pontos-de-têrmino consistem de informações de localização e protocolo e 
são armazenados numa coleção de elementos&nbsp;endpoint&nbsp;(ver&nbsp;Listagem 5).
Listagem 5:&nbsp;O elemento ponto-de-término


 
  
  ...concrete implementation details...
  
 


Agora que descrevemos como um web service pode ser acessado, 
precisamos definir os requisitos de chamada para cada uma das suas 
operations. Os elementos&nbsp;binding&nbsp;associam às operations informações de 
formato de protocolo e mensagem. O construtor&nbsp;operation&nbsp;que reside 
dentro do bloco&nbsp;binding&nbsp;é semelhante a sua contrapartida na 
seção&nbsp;interface&nbsp;(ver&nbsp;Listagem 6).
Listagem 6:&nbsp;O elemento binding representando uma operation existente


 
  
   
    
   
  
 


A descrição de informação concrete dentro de um documento WSDL pode ser resumida assim:

elementos service: hospedam coleções de ponto-de-término representados individualmente por elementos endpoint;
elementos endpoint: contem dados endpoint, incluindo endereço físico e informação de protocolo;
elementos binding: se auto-associam a construtores operation;
cada endpoint pode referenciar um elemento binding e, portanto, fornecer informação endpoint para a operation subordinada.