Clique aqui para ler todos os artigos desta edição Web Services Use WSDL com vários Web Services por Gerrard Lindsay
Este artigo discute Este artigo usa as seguintes tecnologias: · Os mistérios dos namespaces XML e a WSDL (Web Services Description Language) · Compartilhamento de tipos entre vários Web services sem precisar escrever código de cliente · A ferramenta WSDL.exe .Net framework, C#, xml e web services Download: WSDL.exe (147KB) Chapéu Web Services
As soluções empresariais geralmente agregam informações de diferentes aplicativos internos e de fontes externas. Os Web services foram adotados rapidamente como um método para consumir de maneira fácil e confiável os diversos dados exigidos por essas soluções. Isso faz com que surjam situações inevitáveis, nas quais uma única solução requer o consumo de vários Web services complementares, que quase sempre compartilham tipos XML específicos ao domínio ou à empresa. Infelizmente, as muitas ferramentas que ajudaram a impelir a crescente adoção dos Web services, bem como as abstrações que eles possibilitam, podem freqüentemente impedir que os desenvolvedores espiem por trás dos panos os padrões XML que compõem a pilha dos Web services. Este artigo oferecerá uma solução que possibilitará o compartilhamento de tipos entre os proxies criados para Web services complementares e, ao mesmo tempo, fornecerá uma oportunidade de examinar a WSDL (Web Services Description Language) e sua interação com as ferramentas de Web services que tanto conhecemos e amamos.
A primeira vez que tentei criar dois Web services complementares para compartilhar um tipo XML comum, tive uma infeliz surpresa. Cada um dos proxies que foram criados em meu aplicativo cliente possuía uma representação de objeto separada para a mensagem comum, em um namespace em C# separado. Precisei copiar cada uma dessas propriedades manualmente da instância de uma classe para outra, o que parecia um artefato desnecessário da implementação atual das ferramentas.
No final das contas, tropecei em uma técnica que permite que você exponha um contrato individual de Web service que encapsula vários endpoints de Web services por meio da criação de um arquivo WSDL com vários vínculos. Essa explicitação define as relações entre os serviços e também tem a vantagem de gerar proxies que podem compartilhar as classes managed que representam as mensagens comuns.
É possível compartilhar os tipos definidos por vários contratos no mesmo namespace editando manualmente os proxies gerados pela ferramenta após o fato. No entanto, a combinação de vínculos de Web service a um único arquivo WSDL permite que o implementador do Web service defina a relação compartilhada, em vez de colocar a carga nos desenvolvedores que criam os clientes para os serviços. Essa técnica também evita que você precise recriar essas alterações na classe do proxy cada vez que alterar o contrato de serviço durante o desenvolvimento.
Namespaces XML versus Namespaces CLR
Antes de prosseguir, é importante que você se certifique de que compreende o conceito de namespaces, bem como a diferença entre os namespaces no contexto do XML e os namespaces no contexto do managed code. Os dois tipos de namespace têm um objetivo similar: ajudar os desenvolvedores a evitar colisões de nome. Eles permitem que um único grupo de itens inclua vários itens com nomes idênticos, mas diferentes significados. Isso possibilita que você use o nome "Order" para representar tanto um pedido do cliente como a seqüência de um item no carrinho de compras. Desse modo, os namespaces atuam como sobrenomes, usados para diferenciar "John Smith" de "John Brown." Vamos dar uma olhada nisso examinando o namespace XML mostrado na Listagem 1.
Listagem 1 Exemplo de namespace xml
xmlns:o="http://www.example.com/OrderService"
xmlns:s="http://www.example.com/ShoppingCartService ">
Na Listagem 1, o elemento Order de um esquema criado pela empresa que usa o namespace http://www.example.com/OrderService pode conviver em harmonia com o elemento Order de um esquema criado pela empresa que usa o namespace http://www.example.com/ShoppingCartService. As URIs usadas como namespace XML estão freqüentemente, mas não sempre, na forma de URLs. No entanto, não é necessário (e geralmente não é o caso) que esses URLs apontem realmente para um arquivo de esquema ou para qualquer outro recurso real.
Para evitar que os arquivos XML se tornem insuportavelmente detalhados (em geral uma das principais reclamações do formato XML), é possível usar prefixos de namespace como abreviação da referência de URI real que define um namespace. Quando o prefixo do namespace é anexado ao nome local de um elemento em um namespace, com a ajuda de um ponto-e—vírgula você obtém o nome qualificado do elemento. Veja aqui um exemplo:
"o" + ":" + "Order" = "o:Order"
Da mesma forma, os namespaces no mundo gerenciado separam as classes que contêm nomes idênticos. Um ótimo exemplo disso é que a biblioteca do Windows® Forms contém System.Windows.Forms.Button, e a biblioteca do ASP.NET contém uma classe denominada System.Web.UI.WebControls.Button sem nenhum problema. Embora meu exemplo use classes em diferentes assemblies, é importante ter em mente que é sempre possível ter várias classes com o mesmo nome em uma única montagem, desde que ambas residam em namespaces diferentes.
A propósito, o que é um binding?
Antes de me aprofundar na solução, vamos separar um momento para uma rápida revisão sobre as partes móveis que compõem um arquivo WSDL. Vou me concentrar em um Web service literal de documento que opera sobre HTTP. Existem muitas opções, tais como SoapHeaders, e diferentes transportes e codificações, porque a WSDL destina-se a ser um padrão muito extensível. O arquivo WSDL simples descreverá um serviço cujo corpo contém um documento XML personalizado, a parte do documento, definida no serviço XSD (XML Schema Definition Language), a parte literal. Caso deseje informações mais detalhadas sobre Web services codificados/RPC, WSDL, SOAP ou outros padrões XML que compõem a pilha de Web services, visite MSDN Web Services Developer Center (http://msdn.microsoft.com/webservices/). Nesse meio tempo, farei um rápido tour sobre os contratos de serviço.
WSDL é o padrão que descreve o formato das mensagens que são transportadas pelos envelopes SOAP. Um arquivo WSDL é um documento XML que atua como um contrato para um Web service. Ele pode ser usado por consumidores do Web service como um guia para a criação e validação de payloads XML enviados para aquele serviço ou dele recebidos. Vamos dar uma rápida olhada no esqueleto de um arquivo WSDL, conforme mostrado na Listagem 2, para ter uma idéia melhor de seus componentes. Lembre-se de que isso não é um contrato de serviço válido. Eu o simplifiquei para este exemplo, removendo determinados atributos e declarações de namespace de modo a poder me concentrar nas partes mais interessantes.
Listagem 2 Arquivo WSDL simplificado
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:my="http://example.com/supersimplewebservice"
...
