Aquele blog de SOA

Olá Pessoal, dentro da categoria de discussões mais técnicas deste blog vamos falar hoje de Web Services Description Language – WSDL. Juntamente com SOAP e UDDI, o WSDL forma o tripé dos padrões voltados para SOA. Sendo assim, é de extrema importância que possamos entender em detalhes suas partes e, principalmente, as razões de design levadas em consideração na sua especificação. Vamos lá, então!

O WSDL descreve a interface do serviço de forma estruturada e padronizada usando XML. É importante entender que diferentemente das linguagens de definição de interfaces – IDL anteriores (Corba, COM), o WSDL envolve duas partes diferentes: abstrata e concreta. A parte abstrata descreve a interface do serviço propriamente dita, ou seja, descreve como o serviço pode ser invocado por seus clientes. A interface de um serviço pode ser descrita através das operações e dos parâmetros de ida e volta. Muito similar ao um método de classe Java, por exemplo: int registrarPedidoCompra(Pedido pPedido). Inclusive existem anotações no Java e .Net que permitem fazer um mapeamento automático para elementos do WSDL. Já a parte concreta define o protocolo e o endereço onde o serviço estará disponibilizado. Observe que esta separação é proposital, pois um mesmo serviço pode ser disponibilizado através de endereços e protocolos diferentes.

Estrutura do WSDL

Vamos agora destrinchar cada parte do WSDL. Para exemplificar vamos pensar num serviço de registro de pedido de compra que recebe com parâmetro uma entidade “Pedido” e retorna um “id” (inteiro) do pedido registrado:

Types: permite especificar os tipos que serão trocados nas mensagens de ida e volta do serviço. Permite usar XML Schema para definir as estruturas de dados. No nosso exemplo, a entidade “Pedido” e o tipo inteiro seriam definidos aqui.

Message: permite descrever as mensagens que são trocadas entre o serviço e o consumidor do serviço. Uma mensagem pode possuir várias partes, sendo que cada parte possui um nome e um tipo de dados. No nosso exemplo, são definidas duas mensagens, a primeira, é usada para fazer a requisição do serviço e possui uma parte apenas (nome: pPedido, tipo: Pedido). A segunda, define a resposta do serviço e também possui somente uma parte que define do tipo de retorno (nome: qualquer um, tipo: int).

PortType: define um conjunto de operações suportadas pelo serviço e que possuem uma relação entre si. Baseado nesta definição você deve está imaginando qual é a estrutura que agrupa as operações no mundo orientado a objeto? A resposta é Classe! É ela mesmo. Assim como classe possui operações, portType também possui. Cada operação dentro do portType possui elementos do tipo Message. No nosso exemplo, o portType poderia ter um nome sugestivo como “PedidoPortType” e dentro dele a operação “registrarPedidoCompra”.

Uma coisa que eu sempre me perguntei, por que os caras que especificaram o WSDL deram este nome. Não teria um nomezinho melhor pra dar não? O nome “Classe” também acho que não seria adequado, pois o WSDL tem propósitos de absorver linguagens que não são orientadas a objetos. Enfim, a conclusão que tirei é que eles mandaram mal e resolveram corrigir este erro na versão 2.0 do WSDL. A propósito, a versão 2.0 do WSDL ainda não pegou, por isso não estou falando dela neste blog. Mas para matar a curiosidade o termo PorType foi alterado para Interface.

Binding: provê detalhes de como as mensagens serão transmitidas. Por exemplo, o protocolo que irá carregar a mensagem do serviço até seu consumidor e vice e versa. Apesar de parecer intuitivo usar SOAP, o WSDL não fixa o uso deste protocolo. Inclusive podem ser usados outros protocolos como o HTTP e o SMTP puros. Pra falar a verdade, nunca utilizei um serviço que não fosse com SOAP. Inclusive, se alguém tiver tido esta experiência e quiser compartilhar com a gente agradeço.

Service e ports: por fim, os últimos elementos especificam a localização (endereço URL ou email) onde o serviço está disponível e o encoding utilizado, respectivamente. Encoding é um tema que merece um artigo só pra ele. Mas podemos resumir que o encoding define como que uma estrutura de dados é representada em XML, ou seja, dado um objeto na memória (ex: Pedido) como que ele é mapeado para XML e dado um XML como que ele é mapeado para um objeto na memória.

Bom pessoal, por enquanto é só. “Me lembrei daqueles desenhos antigos do pernalonga que falava por enquanto é só pessoal”. Nas próximas publicações vou detalhar cada parte apresentada aqui. Por favor, deixe seu comentário, sugestões, opiniões e críticas.