JAX-WS. A Api “Coroa” do Java. Introdução ao Soap!

Como sempre, vamos voltar um pouco às origens, mas antes porque decidi escrever um artigo sobre tal tecnologia?

Percebi que alguns colegas que começaram a pouco tempo na área como dev Java em algumas entrevistas, vez ou outra são pegos e perdem pontos quando são perguntados sobre SOAP e etc, como já vivenciei essa tecnologia entendo que para facilitar o entendimento o primeiro passo seria falar sobre alguns caras importantes desse meio antes de chegar no SOAP propriamente dito. Então logo de início iremos falar sobre JAX-WS.

Lembrando que esse artigo antecede o próximo a ser escrito sobre uma introdução com implementação do SOAP em uma aplicação.

Outra coisinha, minha intenção com os artigos que escrevo e mostrar como funciona tal tecnologia, suas bases e etc, aprender a lidar mesmo nós só vamos no dia a dia, por mais que o tutorial seja hiper mega Step By Step. De Acordo? Então Bora!

Conta comigo 1,2,3 o que significa JAX-WS? Simples, Java API para XML Web Services trata-se de uma tecnologia para construir Web Service, define regras para a comunicação com a implementação SOAP por exemplo, essa e feita via arquivo XML, mais uma coisa, essa tecnologia fornece varias anotações que facilitam no desenvolvimento. Fácil não?


Por que Nasceu?

Então la atrás há muito tempo, quando os primeiros Web Services nasceram as bibliotecas para tal serviço ficava a cargo dos servidores de aplicação, isso significa ser necessário conhecimento nos servidores. Ai já viu, a humanidade sempre buscando facilitar, eis que com a chegada do Java 1.6 novas bibliotecas foram criadas para Web Services e embutidas na JRE, ai começam a ganhar popularidade os Web Services com SOAP, aqui que entra o JAX-WS, esse carinha se trata, na verdade, de uma especificação para Web Services, a comissão do Java sempre procurou padronizar as coisas para não virar a casa da mãe Joana, ai que surge o JAX-WS para especificar um padrão a ser seguindo na construção de Web Services, tipo com o que aconteceu com a JPA lá no início, outra especificação que surgiu para padronizar as suas implementações.

Mas Antes, Vamos Sanar de Vez a Dúvida entre Web Service e API.

Application Programming Interface ou comumente falada API, é uma interface que conecta dois programas, realizando a comunicação entre eles e ditando (especificando) como dois ‘softwares’ em questão devem se conversar(integrar). Então esse e o principal (não o único) sentido para definição do termo API, e por meio dessa ponte que as empresas podem utilizar serviços terceirizados e trocar dados.

Já os Web Services se comunicam através de redes e podem ser combinados para a execução de operações complexas, utilizando principalmente (XML, SOAP, HTTP, WSDL etc…) com o intuito de interagir com outros softwares da Web trocando dados.

A mesma coisa que API?

Rolou um bug ai? Se vc pensou que… Então todo Web Service é considerado uma API, sim você acertou! Web Services são os caras que vieram antes desse modelo de integrações que temos hoje, o nome meio que mudou hoje falamos em Web API´s, mas não viaje não, por que tenho que ressaltar uma parada importante que, nem toda API pode ser considerada como um Web Service.


Mais ai, qual a diff?

Tanto APIs quanto Web Services podem trabalhar em máquinas ou redes, mas existem alguns pontos diferentes para cada um. Vamos la…

Com as APIs, o cliente que consome os dados não precisa saber qual método chamar no servidor, o próprio sistema que recebe essa chamada já sabe o que fazer, e já encaminha para o devido processamento. Além disso, as APIs são consideradas mais flexíveis porque os sistemas do cliente e do servidor podem se comunicar mesmo que cada um utilize linguagens diferentes na implementação, com Web Services também dá, mas tem lá suas complexidades há mais, pois temos na comunicação do Web Service com Soap um contrato o WSDL, esse geralmente escrito e definido em uma linguagem(no nosso caso aqui Java) e o cliente precisa desse contrato para implementar a integração do seu lado, dai surge a complexidade com linguagens diferentes.


Também deve-se considerar o esforço empregado para que os dados sejam empacotados e desempacotados, a tal da

serialização/desserialização em uma API e em um, Web Service.

PS: Basicamente, a grosso modo e nosso contexto aqui, a serialização é o processo onde é feita a conversão da estrutura de dados para ser possível compartilhar esses dados… no meu “baianês”, se ligue mermão, e o que acontece quando enviamos um objeto e nossa aplicação converte para JSON, XML ou o inverso.


Quando a serialização e realizada por uma API, esse processo é menos trabalhoso, por isso as APIs são ótimas em fluxos onde envolvem dispositivos móveis.

Já os parrudos Web Services funciona de maneira mais eficiente quando a solução em questão acontece de máquina para máquina. Como hoje em dia tudo e Web e Mobile entendemos então o porquê da popularização das API´s. Pois, como vimos aqui essas bonitinhas trabalham melhor no nível de software para software.

Agora Vamos Voltar Para o JAX-WS…

Você pode estar se perguntando, como funciona então esse tal de SOAP?

Bom como falei antes esse artigo antecede o próximo artigo onde iremos implementar um Web Service com SOAP, mas vamos falar a grosso modo como seria esse funcionamento até para te introduzir no assunto.

Tipo assim, uma requisição a uma operação do Web Service é representada por um protocolo baseado em XML, nesse caso o SOAP. O SOAP define a estrutura do envelope, essas requests e responses são transmitidas como mensagens SOAP (arquivos XML) sobre HTTP, (sim o HTTP está nesse meio), por baixo dos panos tem mais umas techs que funcionam ali a ex em alguns casos o JAX-B, responsável por converter objeto em XML e o inverso também, ou seja, empacota e desempacotam, a tal da desserialização e serialização que falamos acima, fazendo uma analogia ao Spring MVC seria como o que a biblioteca Jackson faz.

Bom deu para entender não e? Se não deu fica tranquilo o próximo post sobre SOAP ta aqui.

E o Tal do Jax-RS, onde entra nessa história toda?

JAX-RS — API Java para Web Services RESTful. Meio que a modernização do Jax-WS os serviços da web, são representados como recursos e podem lidos por URI (Uniform Resource Identifiers). A chamada remota, é representada como uma solicitação HTTP direta, não como o exemplo que falamos acima, onde tinha o SOAP chamando HTTP por baixo, outra diferença e que o Jax-WS precisa de um arquivo WSDL para gerar código executável que os clientes usam para chamar o Web Service, mais uma coisinha o Jax-RS também e mais flexível, pode usar vários tipos MIME diferentes . Muito usado na conversação de dados XML ou troca de dados JSON (JavaScript Object Notation) …

Agora Você Já Sabe Sobre a Especificação(JAX-WS), Vamos Colocar a Mão na Implementação(SOAP) e Implementar.

Vamos ao próximo post. Me acompanhe…