XML Web Services são os blocos básicos de construção para computação distribuída na Internet. Os padrões abertos e o foco na comunicação e colaboração entre usuários e aplicações criaram um ambiente no qual os XML Web Services se tornam a plataforma para integração de aplicações. Os aplicativos são construídos usando XML Web Services a partir de diversas fontes diferentes que funcionam juntas, independentemente de onde estão localizados ou de como são implementados.
Existem tantas definições de XML Web Services quantas empresas criam XML Web Services. Mas quase todas as definições têm o seguinte em comum:
Os XML Web Services fornecem funcionalidades úteis aos usuários da Web por meio de protocolos da Web padrão. Na maioria dos casos, o protocolo SOAP é usado.
Os XML Web Services podem especificar suas interfaces detalhadamente, o que permite aos usuários criar aplicativos clientes para se comunicarem com eles. Essa descrição geralmente está contida em um documento XML denominado documento WSDL (Web Services Description Language).
Os XML Web Services são registrados para que usuários em potencial possam encontrá-los facilmente, o que é realizado por meio do Universal Discovery, Description, and Integration (UDDI).
Este artigo apresentará essas três tecnologias, mas primeiro precisamos explicar por que você deve prestar atenção aos XML Web Services.
Uma das principais vantagens da arquitetura XML Web Services é que ela permite que uma variedade de programas escritos em diferentes linguagens em diferentes plataformas se comuniquem entre si de maneira baseada em padrões. Os usuários que conhecem algo sobre esse setor podem dizer imediatamente: "Espere um minuto, o CORBA e o DCE anterior não assumiram o mesmo compromisso? Qual é a diferença entre este e eles? A diferença mais importante é: SOAP é melhor do que antes?" A abordagem é muito mais simples, portanto há muito menos barreiras para a implementação de SOAP compatível com os padrões. Paul Kulchenko fornece uma lista de implementações SOAP em http://www.soapware.org/directory/4/implementations (em inglês). Na última contagem, a lista continha 79 itens. Como seria de esperar, a maioria das grandes empresas de software fornece implementações SOAP, mas também existem muitas implementações criadas e mantidas por desenvolvedores individuais. Outra grande vantagem dos XML Web Services em relação às soluções anteriores é o uso de protocolos Web padrão - XML, HTTP e TCP/IP. Muitas empresas já estabeleceram uma infra-estrutura Web e seus funcionários possuem o conhecimento e a experiência para mantê-la. Portanto, o custo de introdução de XML Web Services é muito menor do que a introdução de tecnologias anteriores.
Definimos um XML Web Service como um serviço de software fornecido na Web via SOAP, descrito usando um arquivo WSDL e registrado via UDDI. Então, você pode perguntar: "O que você pode fazer com XML Web Services?" Os XML Web Services originais eram frequentemente fontes de informações que podiam ser facilmente incorporadas em aplicativos, como preços de ações, previsões meteorológicas, resultados esportivos e assim por diante. É fácil imaginar uma classe inteira de aplicativos que poderiam ser criados para analisar e resumir as informações de seu interesse e disponibilizar essas informações de diversas maneiras. Por exemplo, você poderia usar uma planilha do Microsoft® Excel para resumir todas as suas finanças; informações - ações, 401K, depósitos bancários, empréstimos, etc. Se essas informações estiverem disponíveis por meio de XML Web Services, o Excel poderá atualizá-las continuamente. Algumas dessas informações são gratuitas e outras podem exigir uma assinatura para obter o serviço correspondente. Muitas dessas informações já estão disponíveis na Web, mas os XML Web Services podem tornar o acesso programático mais fácil e confiável.
Os aplicativos existentes são disponibilizados como XML Web Services, e aplicativos novos e mais poderosos podem ser criados usando XML Web Services como blocos de construção. Por exemplo, um usuário pode desenvolver um aplicativo de compras para obter automaticamente informações de preços de diferentes fornecedores, permitindo ao usuário selecionar um fornecedor, enviar um pedido e, em seguida, acompanhar o envio de mercadorias até que as mercadorias sejam recebidas. Além de fornecer serviços na Web, o aplicativo do fornecedor também pode usar o XML Web Service para verificar o crédito do cliente, receber pagamentos e lidar com procedimentos de frete com empresas de frete.
No futuro, alguns dos aplicativos mais interessantes baseados em XML Web Services serão capazes de aproveitar a Web para realizar tarefas que atualmente são impossíveis. Por exemplo, o serviço de calendário é um dos serviços que serão suportados pelo projeto Microsoft .NET My Services (Inglês). Se seus dentistas e mecânicos fornecem seus horários através deste XML Web Service, você pode agendar consultas com eles pela Web, se preferir, eles também podem agendar limpezas e datas de manutenção de rotina diretamente em seu calendário; É fácil imaginar que se você pudesse programar a Web, você poderia criar centenas de aplicações.
Para obter mais informações sobre XML Web Services e os aplicativos que você pode criar, consulte a página inicial do MSDN Web Services (inglês).
SOAP
SOAP é o protocolo de comunicação do XML Web Service. Ao descrever o SOAP como um protocolo de comunicação, a maioria das pessoas pensa em DCOM ou CORBA e faz perguntas como "Como o SOAP ativa objetos ou "Qual serviço de nomenclatura o SOAP usa?" Embora as implementações SOAP possam incluir esses elementos, eles não são especificados pelo padrão SOAP. SOAP Uma especificação que define o formato XML das mensagens – esta é uma parte obrigatória da especificação. Um segmento XML bem formado contido em um par de elementos SOAP é uma mensagem SOAP. Isso não é simples?
Outras partes da especificação SOAP descrevem como representar dados do programa como XML e como usar SOAP para chamadas de procedimento remoto (RPC). Essas partes opcionais da especificação são usadas para implementar aplicações no estilo RPC, onde o cliente emitirá uma mensagem SOAP (contendo uma função que pode ser chamada e os parâmetros a serem passados para a função) e o servidor retornará uma mensagem contendo os resultados. da execução da função. Atualmente, a maioria das implementações SOAP oferece suporte a aplicativos RPC porque os programadores acostumados a desenvolver aplicativos COM ou CORBA estão familiarizados com o formato RPC. SOAP também oferece suporte a aplicativos de estilo de documento, nos quais uma mensagem SOAP é apenas um wrapper em torno de um documento XML. Os aplicativos SOAP baseados em documentos são muito flexíveis e muitos novos XML Web Services aproveitam esse recurso para criar serviços que são difíceis de implementar usando RPC.
A parte final opcional da especificação SOAP define o estilo das mensagens HTTP que contêm mensagens SOAP. Essa ligação HTTP é importante porque quase todos os sistemas operacionais atuais (e muitos sistemas operacionais anteriores) suportam HTTP. Embora opcional, a ligação HTTP é suportada por quase todas as implementações SOAP porque é o único protocolo padrão para SOAP. Por esta razão, as pessoas muitas vezes acreditam erroneamente que o SOAP deve usar HTTP. Na verdade, algumas implementações também suportam transporte MSMQ, MQ Series, SMTP ou TCP/IP, mas como o HTTP é tão onipresente, quase todos os XML Web Services atuais o utilizam. Como o HTTP é o protocolo central da Web, a infraestrutura de rede da maioria das organizações suporta HTTP e os funcionários já sabem como gerenciá-lo. Hoje, a infraestrutura para segurança, monitoramento e balanceamento de carga HTTP foi estabelecida.
Ao começar a usar SOAP, o mais confuso é a diferença entre a especificação SOAP e suas diversas implementações. A maioria dos usuários de SOAP não escreve mensagens SOAP diretamente, mas usa kits de ferramentas SOAP para criar e analisar mensagens SOAP. Esses kits de ferramentas normalmente convertem chamadas de função de uma linguagem em mensagens SOAP. Por exemplo, o Microsoft SOAP Toolkit 2.0 converte chamadas de função COM em SOAP e o Apache Toolkit converte chamadas de função JAVA em SOAP. Os tipos de chamadas de função e tipos de dados de parâmetros suportados variam de acordo com cada implementação SOAP, portanto, uma função que funciona para um kit de ferramentas pode não funcionar para outro. Esta não é uma limitação do SOAP, mas da implementação específica utilizada.
De longe, o recurso mais atraente do SOAP é que ele pode ser implementado em diversas plataformas de software e hardware. Isso significa que o SOAP pode ser usado para vincular sistemas diferentes dentro e fora da empresa. Várias abordagens foram tentadas no passado para criar um protocolo de comunicação comum que pudesse ser usado para integração de sistemas, mas nenhuma delas obteve a aceitação generalizada que o SOAP obteve. Por que? Porque o SOAP é menor e mais fácil de implementar do que muitos protocolos anteriores. Por exemplo, DCE e CORBA levaram anos para serem implementados, portanto apenas algumas implementações foram lançadas. O SOAP pode aproveitar os analisadores XML e as bibliotecas HTTP existentes para realizar a maior parte do trabalho pesado, de modo que uma implementação do SOAP possa ser concluída em questão de meses. É por isso que existem agora mais de 70 implementações SOAP. É claro que o SOAP não possui todas as funções do DCE ou CORBA. Embora as funções sejam reduzidas, o SOAP é mais fácil de aplicar porque sua complexidade é bastante reduzida.
A popularidade do HTTP e a simplicidade do SOAP permitem chamá-los de praticamente qualquer ambiente, tornando-os uma base ideal para serviços Web XML. Para obter mais informações sobre SOAP, consulte a página inicial do MSDN SOAP (inglês).
Quão seguro é isso?
Freqüentemente, a primeira pergunta feita por usuários novos no SOAP é como o SOAP resolve problemas de segurança. Em seus estágios iniciais de desenvolvimento, o SOAP era visto como um protocolo baseado em HTTP, portanto a segurança do HTTP era considerada suficiente para o SOAP. Afinal, existem milhares de aplicações Web atualmente usando segurança HTTP, então isso é realmente suficiente para SOAP. Portanto, o padrão SOAP atual assume que a segurança é uma questão de transporte e não é tratada como uma questão de segurança.
À medida que o SOAP se expande para um protocolo mais geral e é executado em vários transportes, as questões de segurança tornam-se mais proeminentes. Por exemplo, o HTTP fornece diversas maneiras de autenticar usuários que fazem chamadas SOAP, mas como essa identidade se propaga quando as mensagens são roteadas do transporte HTTP para o transporte SMTP? O SOAP foi projetado como um protocolo de blocos de construção, portanto, felizmente, existem especificações em vigor para fornecer recursos de segurança adicionais para serviços da Web baseados em SOAP. A especificação WS-Security (inglês) define um sistema de criptografia completo, e a especificação WS-License (inglês) define a tecnologia correspondente para garantir a identidade do chamador e garantir que apenas usuários autorizados possam usar serviços da Web.
WSDL
WSDL (Linguagem de Descrição de Serviços Web) significa Linguagem de Descrição de Serviços Web. Para os fins deste artigo, podemos pensar em um arquivo WSDL como um documento XML que descreve um conjunto de mensagens SOAP e como trocá-las. Em outras palavras, WSDL está para SOAP assim como IDL está para CORBA ou COM. Como o WSDL é um documento XML, é fácil de ler e editar, mas na maioria dos casos é gerado e usado por software;
Para visualizar os valores do WSDL, imagine que você deseja chamar um método SOAP fornecido por um de seus parceiros de negócios. Você poderia solicitar alguns exemplos de mensagens SOAP e então escrever seu aplicativo para gerar e usar mensagens semelhantes às amostras, mas é fácil cometer erros. Por exemplo, você pode ver um ID de cliente 2837 e presumir que é um número inteiro, quando na verdade é uma string. O WSDL especifica através de uma notação explícita o que a mensagem de solicitação deve conter e como deve ser a aparência da mensagem de resposta.
A notação usada pelos arquivos WSDL para descrever formatos de mensagens é baseada no padrão XML Schema, o que significa que é uma linguagem de programação agnóstica e baseada em padrões, tornando-a adequada para descrever XML Web Services que podem ser acessados a partir de diferentes plataformas e em diferentes programações. interface de idiomas. Além de descrever o conteúdo da mensagem, o WSDL também define a localização do serviço e qual protocolo de comunicação é utilizado para se comunicar com o serviço. Ou seja, o arquivo WSDL define tudo o que é necessário para escrever um programa que utiliza XML Web Services. Existem diversas ferramentas que podem ler arquivos WSDL e gerar o código necessário para se comunicar com serviços Web XML. Algumas das ferramentas mais poderosas podem ser encontradas no Microsoft Visual Studio® .NET.
Atualmente, muitos kits de ferramentas SOAP incluem ferramentas para gerar arquivos WSDL a partir de interfaces de programas existentes, mas existem poucas ferramentas para escrever WSDL diretamente e o suporte de ferramentas para WSDL é incompleto. Mas em breve haverá ferramentas para escrever arquivos WSDL, seguidas por ferramentas para gerar proxies e stubs (muito parecidas com ferramentas COM IDL), e essas ferramentas se tornarão parte da maioria das implementações SOAP. Até então, o WSDL se tornará o método preferido para a criação de interfaces SOAP para serviços Web XML.
Há uma descrição muito boa do WSDL aqui (em inglês), e você também pode encontrar a especificação WSDL em http://www.w3.org/TR/wsdl (em inglês).
UDDI
Universal Discovery, Description, and Integration (UDDI) são as páginas amarelas dos serviços da Web. Assim como nas tradicionais Páginas Amarelas, você pode pesquisar empresas que oferecem os serviços que você precisa, ler para conhecer os serviços oferecidos e depois entrar em contato com alguém para obter mais informações. Claro, você pode fornecer serviços da Web sem registrá-los no UDDI, o que é como administrar um negócio em seu porão e contar com o boca a boca, mas se quiser expandir seu mercado, você precisa do UDDI para poder ser descoberto por seus clientes; clientes.
As entradas do diretório UDDI são arquivos XML que descrevem os serviços e serviços fornecidos. Uma entrada de diretório UDDI consiste em três partes. As "Páginas Brancas" apresentam empresas que prestam serviços: nome, endereço, informações de contato, etc.; As "Páginas Amarelas" incluem categorias da indústria baseadas em classificações padrão (como o Sistema de Classificação da Indústria da América do Norte e a Classificação Industrial Padrão); informações Acesse a interface do serviço para que os usuários possam escrever aplicativos para consumir o serviço da Web. A definição de um serviço é realizada através de um documento UDDI denominado modelo de tipo (ou tModel). Na maioria dos casos, o tModel contém um arquivo WSDL que descreve a interface SOAP para acessar o XML Web Service, mas o tModel é muito flexível e pode descrever quase qualquer tipo de serviço.
O diretório UDDI também contém vários métodos para procurar os serviços necessários para construir seu aplicativo. Por exemplo, você pode pesquisar prestadores de serviços em uma localização geográfica específica ou pesquisar um tipo específico de negócio. O diretório UDDI fornecerá informações, detalhes de contato, links e dados técnicos para que você possa identificar os serviços que atendem às suas necessidades.
O UDDI permite que você encontre empresas que fornecem os serviços Web de que você precisa. O que você faz se já sabe com quem deseja fazer negócios, mas ainda não sabe o que mais isso pode oferecer? A especificação WS-Inspection (em inglês) permite navegar na coleção de XML Web Services disponíveis em um servidor específico para encontrar o serviço que você precisa.
Para obter mais informações sobre o UDDI, visite http://www.uddi.org/about.html (em inglês).
Outro conteúdo
Até agora, discutimos como se comunicar com XML Web Services (SOAP), como os XML Web Services são descritos (WSDL) e como encontrar XML Web Services (UDDI). Eles formam um conjunto básico de especificações que fornecem a base para integração e agregação de aplicativos. Com base nessas especificações básicas, as empresas podem construir soluções práticas e se beneficiar delas.
Fizemos muito trabalho para implementar XML Web Services, mas ainda há muito trabalho a ser feito. Hoje, as pessoas alcançaram sucesso usando XML Web Services, mas para os desenvolvedores ainda há muitos links para melhorar. Por exemplo, segurança, gerenciamento de operações, processamento de transações e mensagens confiáveis. A Arquitetura Global de Serviços Web XML ajudará os Serviços Web XML a entrar no próximo estágio de evolução, fornecendo um modelo comum e consistente para adicionar novos recursos avançados aos Serviços Web XML de maneira modular e extensível.
Os módulos de segurança mencionados acima (WS-Security [Inglês] e WS-License [Inglês]) fazem parte da especificação Global Web Services Architecture. As necessidades de gerenciamento operacional (como rotear mensagens entre vários servidores e configurar dinamicamente esses servidores para processamento) também fazem parte da Arquitetura Global de Serviços da Web por meio da especificação WS-Routing (inglês) e da especificação WS-Referral (inglês). À medida que a Arquitetura Global de Serviços Web evolui, serão introduzidas especificações que atendam a essas e outras necessidades.