Artigo Java Magazine 55 - Web services WS-*

Web services WS-*

Uma abordagem prática

Implementação de web services utilizando padrões WS-I

Na edição anterior, realizamos uma análise sobre o momento atual das arquiteturas orientadas a serviços (service oriented architectures - SOA) e fizemos um comparativo entre ersos aspectos das duas formas de implementação dos web services: WS-* e REST. Prosseguindo com o tema, agora aprofundaremos a discussão do WS-* com um artigo prático. Finalizaremos na próxima edição, com uma cobertura similar do REST.

Os web services WS-* surgiram no final da década de 90, quando alguns fabricantes de middleware perceberam a necessidade de padronizar as implementações de SOA que estavam surgindo. Isto era fundamental para garantir a interoperabilidade de aplicações, sem a qual a visão de SOA não faria sentido.

A evolução dos serviços WS-* se caracterizou pela velocidade das especificações bastante superior à velocidade das aplicações práticas destes padrões. Rapidamente se chegou a um ponto no qual ficava praticamente impossível acompanhar o ritmo da documentação gerada pelo consórcio de empresas envolvidas, e isto certamente elevou a complexidade das implementações.

O objetivo deste artigo é partir de um problema real de arquitetura orientada a serviços, e então realizar a modelagem e implementação utilizando os artefatos e recomendações contidas em alguns dos documentos do grupo WS-I (Web Services Interoperability Organization), responsável por garantir a interoperabilidade de web services desenvolvidos em diferentes plataformas.

Especialmente para nós que trabalhamos com Java, o WS-I teve papel muito importante, pois um conjunto de definições chamado Basic Profile 1.0 foi utilizado como referência para todas as implementações da pilha de padrões WS-* da plataforma Java, como os servidores de aplicações Java EE e frameworks independentes como o Apache Axis e o XFire. Um fato de fundamental importância a respeito do Basic Profile é que a Microsoft também adotou estas definições para a pilha de SOA .NET, então o uso do mesmo é necessário para integrações bem sucedidas entre as duas plataformas.

Para contextualizar a apresentação dos conceitos desta linha de web services, utilizaremos um exemplo de serviços do Mercado Livre, envolvidos na realização de leilões. Para limitar o escopo do problema de forma adequada à exposição em um artigo, consideraremos apenas a venda como leilão de itens unitários, com vários interessados apresentando suas ofertas até que o vendedor decida encerrar o leilão aceitando a melhor oferta.

Apresentação do problema

O problema que buscaremos resolver envolve serviços relacionados a um leilão do Mercado Livre. Num leilão típico, um usuário cadastrado no site coloca para venda um produto (novo ou usado), definindo um valor para o lance inicial e então aguarda pelas ofertas de compra por parte de outros usuários interessados no produto.

Após receber algumas ofertas pelo produto, em determinado momento o vendedor decide aceitar a melhor oferta recebida, e então vende o produto para o comprador que fez esta oferta, encerrando o leilão. Em seguida ocorrem os trâmites de pagamento e entrega do produto (que não trataremos aqui) e no final, vendedor e comprador avaliam um ao outro, o que é essencial para os usuários sentirem maior segurança ao realizar negociações futuras.

Na modelagem desta aplicação, quatro classes serão utilizadas: Usuário, Item, Oferta e Avaliação. Os serviços a serem oferecidos podem ser vistos no quadro “Serviços oferecidos no processo de leilão”.

Serviços oferecidos no processo de leilão

A primeira etapa na elaboração de uma arquitetura orientada a serviços é a identificação dos serviços que serão disponibilizados para interação com a aplicação e/ou empresa em questão.

No nosso exemplo do leilão, os serviços envolvidos manipulam Usuários, Itens, Ofertas e Avaliações, conforme identificado na modelagem. A Tabela 1 descreve as operações que poderão ser realizadas por quem estiver se integrando ao processo de leilão.