Serviços da Web - Guia rápido

Livros e organizações diferentes fornecem definições diferentes para Web Services. Alguns deles estão listados aqui.

Um serviço da web é qualquer software que se torna disponível na Internet e usa um sistema de mensagens XML padronizado. XML é usado para codificar todas as comunicações para um serviço da web. Por exemplo, um cliente chama um serviço da web enviando uma mensagem XML e, em seguida, aguarda uma resposta XML correspondente. Como toda a comunicação é em XML, os serviços da web não estão vinculados a nenhum sistema operacional ou linguagem de programação - Java pode se comunicar com Perl; Os aplicativos do Windows podem se comunicar com os aplicativos do Unix.
Os serviços da Web são aplicativos autocontidos, modulares, distribuídos e dinâmicos que podem ser descritos, publicados, localizados ou chamados pela rede para criar produtos, processos e cadeias de suprimentos. Esses aplicativos podem ser locais, distribuídos ou baseados na web. Os serviços da Web baseiam-se em padrões abertos, como TCP / IP, HTTP, Java, HTML e XML.
Os serviços da Web são sistemas de troca de informações baseados em XML que usam a Internet para interação direta de aplicativo a aplicativo. Esses sistemas podem incluir programas, objetos, mensagens ou documentos.
Um serviço da web é uma coleção de protocolos e padrões abertos usados para trocar dados entre aplicativos ou sistemas. Os aplicativos de software escritos em várias linguagens de programação e em execução em várias plataformas podem usar serviços da web para trocar dados em redes de computadores como a Internet de maneira semelhante à comunicação entre processos em um único computador. Essa interoperabilidade (por exemplo, entre aplicativos Java e Python ou Windows e Linux) se deve ao uso de padrões abertos.

Para resumir, um serviço web completo é, portanto, qualquer serviço que -

Está disponível na Internet ou em redes privadas (intranet)
Usa um sistema de mensagens XML padronizado
Não está vinculado a nenhum sistema operacional ou linguagem de programação
É autodescritivo por meio de uma gramática XML comum
É detectável por meio de um mecanismo de localização simples

Componentes de serviços da Web

A plataforma básica de serviços da web é XML + HTTP. Todos os serviços da web padrão funcionam usando os seguintes componentes -

SOAP (protocolo de acesso a objetos simples)
UDDI (descrição universal, descoberta e integração)
WSDL (linguagem de descrição de serviços da Web)

Todos esses componentes foram discutidos no capítulo Arquitetura de Serviços da Web .

Como funciona um serviço da Web?

Um serviço da web permite a comunicação entre vários aplicativos usando padrões abertos, como HTML, XML, WSDL e SOAP. Um serviço da web tem a ajuda de -

XML para marcar os dados
SOAP para transferir uma mensagem
WSDL para descrever a disponibilidade do serviço.

Você pode construir um serviço da web baseado em Java no Solaris que é acessível a partir de seu programa Visual Basic executado no Windows.

Você também pode usar C # para construir novos serviços da web no Windows que podem ser chamados a partir de seu aplicativo da web baseado em JavaServer Pages (JSP) e executado no Linux.

Exemplo

Considere um sistema simples de gerenciamento de contas e processamento de pedidos. A equipe de contabilidade usa um aplicativo cliente desenvolvido com Visual Basic ou JSP para criar novas contas e inserir novos pedidos de clientes.

A lógica de processamento deste sistema é escrita em Java e reside em uma máquina Solaris, que também interage com um banco de dados para armazenar informações.

As etapas para realizar esta operação são as seguintes -

O programa cliente agrupa as informações de registro da conta em uma mensagem SOAP.
Essa mensagem SOAP é enviada ao serviço da web como o corpo de uma solicitação HTTP POST.
O serviço da web descompacta a solicitação SOAP e a converte em um comando que o aplicativo pode entender.
O aplicativo processa as informações conforme necessário e responde com um novo número de conta exclusivo para esse cliente.
Em seguida, o serviço da web empacota a resposta em outra mensagem SOAP, que ele envia de volta ao programa cliente em resposta à sua solicitação HTTP.
O programa cliente descompacta a mensagem SOAP para obter os resultados do processo de registro da conta.

Aqui estão os benefícios de usar os serviços da Web -

Expondo a função existente na rede

Um serviço da web é uma unidade de código gerenciado que pode ser chamada remotamente usando HTTP. Ou seja, ele pode ser ativado por meio de solicitações HTTP. Os serviços da Web permitem que você exponha a funcionalidade de seu código existente na rede. Depois de exposto na rede, outros aplicativos podem usar a funcionalidade do seu programa.

Interoperabilidade

Os serviços da Web permitem que vários aplicativos se comuniquem e compartilhem dados e serviços entre si. Outros aplicativos também podem usar os serviços da web. Por exemplo, um aplicativo VB ou .NET pode se comunicar com os serviços da Web Java e vice-versa. Os serviços da Web são usados para tornar a plataforma do aplicativo e tecnologia independente.

Protocolo Padronizado

Os serviços da Web usam o protocolo padrão da indústria para a comunicação. Todas as quatro camadas (camadas de transporte de serviço, mensagem XML, descrição de serviço e descoberta de serviço) usam protocolos bem definidos na pilha de protocolo de serviços da web. Essa padronização da pilha de protocolos oferece ao negócio muitas vantagens, como uma ampla gama de opções, redução no custo devido à competição e aumento na qualidade.

Comunicação de baixo custo

Os serviços da Web usam o protocolo SOAP sobre HTTP, portanto, você pode usar sua Internet de baixo custo existente para implementar serviços da Web. Essa solução é muito mais barata em comparação com soluções proprietárias como EDI / B2B. Além do SOAP sobre HTTP, os serviços da web também podem ser implementados em outros mecanismos de transporte confiáveis, como o FTP.

Os serviços da Web têm as seguintes características comportamentais especiais -

Baseado em XML

Os serviços da Web usam XML nas camadas de representação e transporte de dados. O uso de XML elimina qualquer rede, sistema operacional ou ligação de plataforma. Os aplicativos baseados em serviços da Web são altamente interoperáveis em seu nível central.

Fracamente acoplada

Um consumidor de um serviço da web não está vinculado a esse serviço da web diretamente. A interface do serviço da web pode mudar ao longo do tempo sem comprometer a capacidade do cliente de interagir com o serviço. Um sistema fortemente acoplado implica que a lógica do cliente e do servidor estão intimamente ligadas uma à outra, implicando que, se uma interface for alterada, a outra deverá ser atualizada. A adoção de uma arquitetura fracamente acoplada tende a tornar os sistemas de software mais gerenciáveis e permite uma integração mais simples entre diferentes sistemas.

Grão Grosso

As tecnologias orientadas a objetos, como Java, expõem seus serviços por meio de métodos individuais. Um método individual é uma operação muito fina para fornecer qualquer capacidade útil em um nível corporativo. Construir um programa Java do zero requer a criação de vários métodos de baixa granularidade que são então compostos em um serviço de baixa granularidade que é consumido por um cliente ou outro serviço.

Os negócios e as interfaces que eles expõem devem ser de granulação grossa. A tecnologia de serviços da Web fornece uma maneira natural de definir serviços de granulação grossa que acessam a quantidade certa de lógica de negócios.

Capacidade de ser síncrono ou assíncrono

A sincronicidade refere-se à vinculação do cliente à execução do serviço. Em chamadas síncronas, o cliente bloqueia e espera que o serviço conclua sua operação antes de continuar. As operações assíncronas permitem que um cliente invoque um serviço e execute outras funções.

Os clientes assíncronos recuperam seus resultados em um momento posterior, enquanto os clientes síncronos recebem seus resultados quando o serviço é concluído. A capacidade assíncrona é um fator chave na ativação de sistemas fracamente acoplados.

Oferece suporte a chamadas de procedimento remoto (RPCs)

Os serviços da Web permitem que os clientes invoquem procedimentos, funções e métodos em objetos remotos usando um protocolo baseado em XML. Os procedimentos remotos expõem os parâmetros de entrada e saída que um serviço da web deve oferecer suporte.

O desenvolvimento de componentes por meio de Enterprise JavaBeans (EJBs) e Componentes .NET tem se tornado cada vez mais parte das arquiteturas e implantações corporativas nos últimos dois anos. Ambas as tecnologias são distribuídas e acessíveis por meio de uma variedade de mecanismos RPC.

Um serviço da Web oferece suporte a RPC fornecendo serviços próprios, equivalentes aos de um componente tradicional, ou traduzindo as chamadas recebidas em uma chamada de um componente EJB ou .NET.

Suporta Troca de Documentos

Uma das principais vantagens do XML é sua maneira genérica de representar não apenas dados, mas também documentos complexos. Esses documentos podem ser tão simples quanto representar um endereço atual, ou podem ser tão complexos quanto representar um livro inteiro ou uma solicitação de cotação (RFQ). Os serviços da Web suportam a troca transparente de documentos para facilitar a integração de negócios.

Existem duas maneiras de visualizar a arquitetura do serviço da web -

A primeira é examinar as funções individuais de cada ator de serviço da web.
A segunda é examinar a pilha de protocolos de serviço da web emergente.

Funções de serviço da web

Existem três funções principais na arquitetura de serviço da web -

Provedor de serviço

Este é o provedor do serviço da web. O provedor de serviços implementa o serviço e o disponibiliza na Internet.

Solicitante de serviço

Este é qualquer consumidor do serviço da web. O solicitante utiliza um serviço da web existente abrindo uma conexão de rede e enviando uma solicitação XML.

Registro de serviço

Este é um diretório de serviços logicamente centralizado. O registro fornece um local central onde os desenvolvedores podem publicar novos serviços ou encontrar os existentes. Portanto, atua como uma câmara de compensação centralizada para empresas e seus serviços.

Pilha de protocolo de serviço da web

Uma segunda opção para visualizar a arquitetura de serviço da web é examinar a pilha de protocolos de serviço da web emergente. A pilha ainda está evoluindo, mas atualmente possui quatro camadas principais.

Transporte de serviço

Essa camada é responsável por transportar mensagens entre aplicativos. Atualmente, essa camada inclui protocolo de transporte de hipertexto (HTTP), protocolo de transferência de correio simples (SMTP), protocolo de transferência de arquivo (FTP) e protocolos mais recentes, como o protocolo de troca extensível de blocos (BEEP).

Mensagem XML

Essa camada é responsável por codificar mensagens em um formato XML comum para que as mensagens possam ser entendidas em qualquer uma das extremidades. Atualmente, esta camada inclui XML-RPC e SOAP.

Descrição do Serviço

Essa camada é responsável por descrever a interface pública para um serviço da web específico. Atualmente, a descrição do serviço é tratada por meio do Web Service Description Language (WSDL).

Descoberta de serviço

Essa camada é responsável por centralizar os serviços em um registro comum e fornecer funcionalidade de publicação / localização fácil. Atualmente, a descoberta de serviço é tratada por meio de Descrição Universal, Descoberta e Integração (UDDI).

Conforme os serviços da web evoluem, camadas adicionais podem ser adicionadas e tecnologias adicionais podem ser adicionadas a cada camada.

O próximo capítulo explica os componentes dos serviços da web.

Poucas palavras sobre transporte de serviço

A parte inferior da pilha de protocolo de serviço da web é o transporte de serviço. Essa camada é responsável por realmente transportar mensagens XML entre dois computadores.

Protocolo de transferência de hipertexto (HTTP)

Atualmente, HTTP é a opção mais popular para transporte de serviço. O HTTP é simples, estável e amplamente implantado. Além disso, a maioria dos firewalls permite tráfego HTTP. Isso permite que mensagens XMLRPC ou SOAP sejam disfarçadas como mensagens HTTP. Isso é bom se você deseja integrar aplicativos remotos, mas levanta uma série de questões de segurança.

Protocolo de troca extensível de blocos (BEEP)

Esta é uma alternativa promissora ao HTTP. BEEP é uma nova estrutura da IETF (Internet Engineering Task Force) para a construção de novos protocolos. O BEEP é colocado em camadas diretamente no TCP e inclui vários recursos integrados, incluindo um protocolo de handshake inicial, autenticação, segurança e tratamento de erros. Usando o BEEP, é possível criar novos protocolos para uma variedade de aplicativos, incluindo mensagens instantâneas, transferência de arquivos, distribuição de conteúdo e gerenciamento de rede.

SOAP não está vinculado a nenhum protocolo de transporte específico. Na verdade, você pode usar SOAP via HTTP, SMTP ou FTP. Uma ideia promissora é, portanto, usar SOAP em vez de BEEP.

Nos últimos anos, três tecnologias primárias surgiram como padrões mundiais que constituem o núcleo da tecnologia de serviços da Web atual. Essas tecnologias são discutidas abaixo.

XML-RPC

Este é o protocolo mais simples baseado em XML para troca de informações entre computadores.

XML-RPC é um protocolo simples que usa mensagens XML para executar RPCs.
As solicitações são codificadas em XML e enviadas via HTTP POST.
As respostas XML são incorporadas ao corpo da resposta HTTP.
XML-RPC é independente de plataforma.
XML-RPC permite que diversos aplicativos se comuniquem.
Um cliente Java pode falar XML-RPC com um servidor Perl.
XML-RPC é a maneira mais fácil de começar com os serviços da web.

Para saber mais sobre XML-RPC, visite nosso Tutorial XML-RPC .

SABONETE

SOAP é um protocolo baseado em XML para troca de informações entre computadores.

SOAP é um protocolo de comunicação.
SOAP é para comunicação entre aplicativos.
SOAP é um formato para enviar mensagens.
SOAP é projetado para se comunicar via Internet.
SOAP é independente de plataforma.
SOAP é independente de linguagem.
SOAP é simples e extensível.
SOAP permite contornar firewalls.
SOAP será desenvolvido como um padrão W3C.

Para saber mais sobre o SOAP, visite nosso Tutorial SOAP .

WSDL

WSDL é uma linguagem baseada em XML para descrever serviços da web e como acessá-los.

WSDL significa Web Services Description Language.
WSDL foi desenvolvido em conjunto pela Microsoft e IBM.
WSDL é um protocolo baseado em XML para troca de informações em ambientes descentralizados e distribuídos.
WSDL é o formato padrão para descrever um serviço da web.
A definição WSDL descreve como acessar um serviço da web e quais operações ele executará.
WSDL é uma linguagem para descrever como fazer interface com serviços baseados em XML.
WSDL é parte integrante do UDDI, um registro de negócios mundial baseado em XML.
WSDL é a linguagem que o UDDI usa.
WSDL é pronunciado como 'wiz-dull' e soletrado como 'WSD-L'.

Para saber mais sobre WSDL, visite nosso Tutorial WSDL .

UDDI

UDDI é um padrão baseado em XML para descrever, publicar e localizar serviços da web.

UDDI significa Descrição Universal, Descoberta e Integração.
UDDI é uma especificação para um registro distribuído de serviços da web.
UDDI é uma estrutura aberta e independente de plataforma.
O UDDI pode se comunicar por meio do protocolo SOAP, CORBA e Java RMI.
UDDI usa WSDL para descrever interfaces para serviços da web.
UDDI é visto com SOAP e WSDL como um dos três padrões básicos de serviços da web.
UDDI é uma iniciativa aberta do setor que permite às empresas se descobrirem e definirem como elas interagem na Internet.

Para saber mais sobre UDDI, visite nosso Tutorial UDDI .

Com base na arquitetura de serviço da web, criamos os dois componentes a seguir como parte da implementação de serviços da web -

Provedor de serviços ou editor

Este é o provedor do serviço da web. O provedor de serviços implementa o serviço e o disponibiliza na Internet ou intranet.

Vamos escrever e publicar um serviço web simples usando .NET SDK.

Solicitante ou consumidor de serviço

Este é qualquer consumidor do serviço da web. O solicitante utiliza um serviço da web existente abrindo uma conexão de rede e enviando uma solicitação XML.

Também escreveremos dois solicitantes de serviço da web: um consumidor baseado na web (aplicativo ASP.NET) e outro consumidor baseado em aplicativo do Windows.

A seguir, apresentamos nosso primeiro exemplo de serviço da web que funciona como um provedor de serviços e expõe dois métodos (add e SayHello) como os serviços da web a serem usados pelos aplicativos. Este é um modelo padrão para um serviço da web. Os serviços da Web .NET usam a extensão .asmx. Observe que um método exposto como um serviço da web tem o atributo WebMethod. Salve este arquivo como FirstService.asmx no diretório virtual do IIS (conforme explicado na configuração do IIS; por exemplo, c: \ MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

Para testar um serviço da web, ele deve ser publicado. Um serviço da web pode ser publicado em uma intranet ou na Internet. Publicaremos este serviço da web no IIS em execução em uma máquina local. Vamos começar configurando o IIS.

Abra Iniciar → Configurações → Painel de controle → Ferramentas administrativas → Gerenciador de serviços de Internet.
Expanda e clique com o botão direito no site padrão; selecione Novo & # rarr; Diretório virtual. O Assistente de criação de diretório virtual é aberto. Clique em Avançar.
A tela "Alias do diretório virtual" é aberta. Digite o nome do diretório virtual. Por exemplo, MyWebServices. Clique em Avançar.
A tela "Diretório de conteúdo do site" é aberta.
Insira o nome do caminho do diretório para o diretório virtual. Por exemplo, c: \ MyWebServices. Clique em Avançar.
A tela "Permissão de acesso" é aberta. Altere as configurações de acordo com seus requisitos. Vamos manter as configurações padrão para este exercício.
Clique no botão Avançar. Ele completa a configuração do IIS.
Clique em Concluir para completar a configuração.

Para testar se o IIS foi configurado corretamente, copie um arquivo HTML (por exemplo, x.html) no diretório virtual (C: \ MyWebServices) criado acima. Agora, abra o Internet Explorer e digitehttp://localhost/MyWebServices/x.html. Deve abrir o arquivo x.html.

Note- Se não funcionar, tente substituir o host local pelo endereço IP de sua máquina. Se ainda não funcionar, verifique se o IIS está em execução; você pode precisar reconfigurar o IIS e o diretório virtual.

Para testar este serviço da web, copie FirstService.asmx no diretório virtual IIS criado acima (C: \ MyWebServices). Abra o serviço da web no Internet Explorer (http: //localhost/MyWebServices/FirstService.asmx). Deve abrir sua página de serviço da web. A página deve ter links para dois métodos expostos como serviços da web por nosso aplicativo. Parabéns! Você escreveu seu primeiro serviço da web!

Testando o serviço da web

Como acabamos de ver, escrever serviços da Web é fácil no .NET Framework. Escrever consumidores de serviços da Web também é fácil na estrutura .NET; no entanto, é um pouco mais complicado. Conforme dito anteriormente, escreveremos dois tipos de consumidores de serviço, um baseado na web e outro baseado em aplicativos do Windows. Vamos escrever nosso primeiro consumidor de serviço da web.

Consumidor de serviço baseado na web

Escreva um consumidor baseado na web conforme mostrado abaixo. Chame-o de WebApp.aspx. Observe que é um aplicativo ASP.NET. Salve-o no diretório virtual do serviço da web (c: \ MyWebServices \ WebApp.axpx).

Este aplicativo possui dois campos de texto que são usados para obter os números do usuário a serem adicionados. Ele tem um botão, Executar, que quando clicado obtém os serviços da web Adicionar e SayHello.

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

Depois que o consumidor é criado, precisamos criar um proxy para o serviço da web a ser consumido. Esse trabalho é feito automaticamente pelo Visual Studio .NET para nós, ao fazer referência a um serviço da web que foi adicionado. Aqui estão as etapas a serem seguidas -

Crie um proxy para o serviço da Web a ser consumido. O proxy é criado usando o utilitário WSDL fornecido com o .NET SDK. Este utilitário extrai informações do serviço da Web e cria um proxy. O proxy é válido apenas para um determinado serviço da Web. Se precisar consumir outros serviços da Web, você também precisará criar um proxy para esse serviço. O Visual Studio .NET cria um proxy automaticamente para você quando a referência de serviço da Web é adicionada. Crie um proxy para o serviço da Web usando o utilitário WSDL fornecido com o .NET SDK. Ele criará o arquivo FirstSevice.cs no diretório atual. Precisamos compilá-lo para criar FirstService.dll (proxy) para o Web Service.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

Coloque o proxy compilado no diretório bin do diretório virtual do serviço da Web (c: \ MyWebServices \ bin). O IIS (Serviços de Informações da Internet) procura o proxy neste diretório.
Crie o consumidor de serviço, da mesma forma que já fizemos. Observe que um objeto do proxy de serviço da Web é instanciado no consumidor. Este proxy se encarrega de interagir com o serviço.
Digite a URL do consumidor no IE para testá-la (por exemplo, http: //localhost/MyWebServices/WebApp.aspx).

Consumidor de serviço da Web baseado em aplicativo do Windows

Escrever um consumidor de serviço da Web baseado em aplicativo do Windows é o mesmo que escrever qualquer outro aplicativo do Windows. Você só precisa criar o proxy (o que já fizemos) e fazer referência a esse proxy ao compilar o aplicativo. A seguir está nosso aplicativo do Windows que usa o serviço da web. Este aplicativo cria um objeto de serviço da web (é claro, proxy) e chama os métodos SayHello e Add nele.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Compile-o usando c:\>csc /r:FirstService.dll WinApp.cs. Ele criará WinApp.exe. Execute-o para testar o aplicativo e o serviço da web.

Agora, surge a pergunta: como você pode ter certeza de que esse aplicativo está realmente chamando o serviço da web?

É simples de testar. Pare o servidor da web para que o serviço da web não possa ser contatado. Agora, execute o aplicativo WinApp. Ele irá disparar uma exceção de tempo de execução. Agora, inicie o servidor da web novamente. Deve funcionar.

A segurança é crítica para os serviços da web. No entanto, nem as especificações XML-RPC nem SOAP apresentam quaisquer requisitos de segurança ou autenticação explícitos.

Existem três problemas de segurança específicos com serviços da web -

Confidentiality
Authentication
Segurança de rede

Confidencialidade

Se um cliente enviar uma solicitação XML a um servidor, podemos garantir que a comunicação permaneça confidencial?

A resposta está aqui -

XML-RPC e SOAP são executados principalmente em HTTP.
HTTP tem suporte para Secure Sockets Layer (SSL).
A comunicação pode ser criptografada via SSL.
SSL é uma tecnologia comprovada e amplamente implantada.

Um único serviço da web pode consistir em uma cadeia de aplicativos. Por exemplo, um grande serviço pode unir os serviços de três outros aplicativos. Nesse caso, SSL não é adequado; as mensagens precisam ser criptografadas em cada nó ao longo do caminho do serviço e cada nó representa um elo potencial fraco na cadeia. Atualmente, não há uma solução acordada para esse problema, mas uma solução promissora é o W3C XML Encryption Standard. Este padrão fornece uma estrutura para criptografar e descriptografar documentos XML inteiros ou apenas partes de um documento XML. Você pode verificar em www.w3.org/Encryption

Autenticação

Se um cliente se conecta a um serviço da web, como identificamos o usuário? O usuário está autorizado a usar o serviço?

As opções a seguir podem ser consideradas, mas não há um consenso claro sobre um esquema de autenticação forte.

O HTTP inclui suporte integrado para autenticação Básica e Digest e, portanto, os serviços podem ser protegidos da mesma maneira que os documentos HTML são protegidos atualmente.
A assinatura digital SOAP (SOAP-DSIG) aproveita a criptografia de chave pública para assinar digitalmente mensagens SOAP. Ele permite que o cliente ou servidor valide a identidade da outra parte. Verifique em www.w3.org/TR/SOAP-dsig .
A Organização para o Avanço de Padrões de Informações Estruturadas (OASIS) está trabalhando na Linguagem de Marcação para Asserção de Segurança (SAML).

Segurança de rede

Atualmente, não há uma resposta fácil para esse problema e ele tem sido objeto de muito debate. Por enquanto, se você realmente deseja filtrar mensagens SOAP ou XML-RPC, uma possibilidade é filtrar todas as solicitações HTTP POST que definem seu tipo de conteúdo como text / xml.

Outra alternativa é filtrar o atributo de cabeçalho SOAPAction HTTP. Os fornecedores de firewall também estão desenvolvendo ferramentas explicitamente projetadas para filtrar o tráfego de serviço da web.

Este capítulo dá uma ideia de todos os padrões mais recentes relacionados a serviços da web.

Transportes

BEEP, o Blocks Extensible Exchange Protocol (anteriormente referido como BXXP), é uma estrutura para construir protocolos de aplicativos. Ele foi padronizado pela IETF e faz para os protocolos da Internet o que o XML fez para os dados.

Protocolo de troca extensível de blocos (BEEP)

Mensagens

Esses padrões e especificações de mensagens têm o objetivo de fornecer uma estrutura para a troca de informações em um ambiente distribuído e descentralizado.

SOAP 1.1 (Nota)
SOAP 1.2 (Especificação)
Web Services Attachments Profile 1.0
Mecanismo de Otimização de Transmissão de Mensagem SOAP

Descrição e descoberta

Os serviços da Web são significativos apenas se os usuários em potencial encontrarem informações suficientes para permitir sua execução. O foco dessas especificações e padrões é a definição de um conjunto de serviços de suporte à descrição e descoberta de negócios, organizações e outros provedores de serviços da Web; os serviços da web que disponibilizam; e as interfaces técnicas que podem ser usadas para acessar esses serviços.

UDDI 3.0
WSDL 1.1 (Nota)
WSDL 1.2 (esboço de trabalho)
WSDL 2.0 (Grupo de Trabalho)

Segurança

Usando essas especificações de segurança, os aplicativos podem se envolver em comunicação segura projetada para funcionar com a estrutura geral de serviços da web.

Web Services Security 1.0
Security Assertion Markup Language (SAML)

Gestão

A gerenciabilidade de serviços da web é definida como um conjunto de recursos para descobrir a existência, disponibilidade, integridade, desempenho, uso, bem como o controle e configuração de um serviço da web dentro da arquitetura de serviços da web. À medida que os serviços da web se tornam difusos e essenciais para as operações de negócios, a tarefa de gerenciá-los e implementá-los é fundamental para o sucesso das operações de negócios.

Gerenciamento Distribuído de Serviços da Web

Neste tutorial, você aprendeu como usar os serviços da web. No entanto, um serviço da web também inclui componentes como WSDL, UDDI e SOAP que contribuem para torná-lo ativo. A próxima etapa é aprender WSDL, UDDI e SOAP.

WSDL

WSDL é uma linguagem baseada em XML para descrever serviços da web e como acessá-los.

WSDL descreve um serviço da web, junto com o formato da mensagem e os detalhes do protocolo para o serviço da web.

Para saber mais sobre WSDL, visite nosso Tutorial WSDL .

UDDI

UDDI é um padrão baseado em XML para descrever, publicar e localizar serviços da web.

Para saber mais sobre UDDI, visite nosso Tutorial UDDI .

SABONETE

SOAP é um protocolo simples baseado em XML que permite que os aplicativos troquem informações sobre HTTP.

Para saber mais sobre o SOAP, visite nosso Tutorial SOAP .