Concordo com o que você afirma, é exatamente o que eu quis passar com o post :)

[]s

Parabéns pelo blog.
abcs,

Que isso cara, de forma nenhuma levei a mal, a idéia é justamente reunir conteúdo que agregue e se realmente eu estiver errado, não vejo problema algum em afirmar isso e alterar o post. Mas vamos lá ao que você disse:

1) De fato UDDI não é TÃO usado, apesar de sua idéia ser bem interessante (para quem não conhece é como se fosse aquela listas de telefone, só que para webservices). Mas não é só pelo fato de UDDi não ser TÃO usado, que podemos desconsiderar algumas vantagens de web services WS-* em relação a web services REST, certo? E também não é só pq ele é usado que devemos ignorar a sua existência e sua utilildade, O XMLHTTP (o famoso ajax) por exemplo, já existia há um bom tempo e só foi ser usado efetivamente de 3 anos pra cá. Sem contar que um dos pilares de SOA é “permitir que serviços sejam descobertos”, baseado em SOA, UDDI é importante. Mas tem gente que usa sim: http://registry.gbif.net/uddi/web

2) Eu não afirmei que fazer POST em um formulário vc está usando uma ARQUITETURA RESTful, eu disse que ao fazer um POST em um formulário indiretamente você está usando REST, afinal no seu conceito mais puro REST diz “… onde o usuário progride com uma aplicação selecionando as ligações (transições do estado), tendo como resultado a página seguinte (que representa o estado seguinte da aplicação) que está sendo transferida ao usuário e apresentada para seu uso.”
Mas está longe de ser uma arquitetura REST, talvez eu tenha me expressado mal, se eu tivesse citado que quando você acessa uma página você está usando REST (afinal o maior exemplo de uma arquitetura REST é a web) seria melhor do que o exemplo do POST.

3) A questão da ordem de grandeza acho que não é discutível. O que vale considerar é que se você tiver uma aplicação que acessa serviços (resquests/responses) o tempo todo no final das contas o somatório de bytes desses requests/response será BEM menor no caso de você ter usado REST ou de você ter usado SOAP.

4) Ah não? Então você está me dizendo que você conhecer todos as especificações de WS-* é tão prático e fácil do que conhecer como funciona uma arquitetura RESTful? Você consegue gerar um WSDL na mão? Sem IDE?

5) Sim, estou MUITO errado, concordo :) Existem maneiras de se fazer isso. Com COMET, por exemplo, mas você há de concordar que não é algo tão usado sim, existem maneiras, mas não existe um consenso.

E fique a vontade para fazer suas observações, a idéia é debatermos e aprendendermos, eu por exemplo já aprendi algumas coisas com suas observações :)

Abraço!

1 – UDDI é pouquíssimo usado. Eu nunca o colocaria como uma vantagem, nem como algo positivo.
2 – Fazer POST em um formulário implica em usar HTTP, mas está longe de significar uma arquitetura RESTFul.
3 – Requests/Responses REST não são infinitamente menores. São menores, mas a ordem de grandeza é pequena. Essa diferença de tamanho só representará uma diferença realmente relevante se houver um throughput de rede bem alto.
4 – A quantidade de especificações que o desenvolvedor precisa conhecer não faz com que uma tecnologia seja mais “humana” que a outra.
5 – De onde você tirou que “Serviços REST também não permitem requisições assíncronas”? Isso tá MUITO errado.

Não leve a mal minhas observações, o objetivo é que sejam construtivas.

Que bom saber que o que está escrito nesse post está tão próximo das questões que você estudou para seu MBA.

Depois, se for possível, disponibiliza conosco esse seu artigo :)

Um abraço!

Na verdade as referências são mais a minha experiência e o que eu leio do que qualquer outra coisa hehe, mas se você procurar no Google pelos assuntos citados no post, vc acha bastante referência boa.

Se você precisar de alguma coisa e eu puder ajudar, pode contar comigo.

Abs,

Meu e-mail é gilton_nasc@yahoo.com.br, caso queira enviar as referências.
Mais uma vez, obrigado pela atenção e pelo artigo, parabéns!!

Em relação à segurança, acho que, depois da sua resposta, estou mesmo muito perto da minha solução, porque o meu WS que vou expor pede sempre login e password, e não faz nada, sem primeiro autenticar (usa o casclient) e depois autorizar (usa um sistema proprietário nosso de perfis). Assim, se eu expor o WS por https, já o login e password viajam encriptados e com isto, estou lançado..

Sim, você poder usar HTTPS, mas a única coisa que o HTTPS vai te garantir é que os dados entre o cliente o serviço estarão criptografados, porém se o serviço estiver exposto para toda internet, nada impede que qualquer um possa acessá-los.

Você pode resolver o problema do acesso de algumas maneiras, uma é solicitar login/senha, outra é só permitir chamadas de determinado IP (caso exista essa possibilidade).

No formato que você está usando os seus serviços, no caso WS-* (SOAP/WSDL), você deve usufruir da especificação WS-Security, que é um padrão de segurança para Web Services.

Aproveitando, eu te indicaria reconsiderar a possibilidade de usar outro framework sem ser o Axis, recentemente usamos na minha empresa o Axis2 e tivemos uma série de problemas em ambiente de produção, fora que esse negócio de gerar stubs/xml beans com o Axis tb não é muito prático, estamos usando o Spring-WS que tem um formato um pouco diferente (contract-first) do que o Axis (contract-last), mas é bem mais estável, tem uma ótima documentação e é mais prático, só tem uma curva de aprendizado maior.

Abaixo alguns links:

Spring-WS Security
http://static.springframework.org/spring-ws/sites/1.5/reference/html/security.html

WS-Security
http://www.ibm.com/developerworks/webservices/library/ws-security.html
http://www.guj.com.br/posts/list/44941.java

Segurança no Axis
http://ws.apache.org/axis/java/security.html

Só para fazer um adendo: caso você opte por usuário/senha, não será necessário enviar usuário e senha em toda requisição, existe algumas maneiras de fazer isso, como autenticação com SSO, Username Token Profile, Geração de Keys, fora que você pode manter estado entre as chamadas (stateful) evitando que essas informações devam ser passadas toda chamada.

Bem, é isso, abraço e boa sorte :)

Se for esse caso, você quer expor esses serviços para que apenas determinadas pessoas acessem? Se você puder detalhar isso um pouco melhor, fica mais fácil ajudar…

Abs!

Como sempre discute-se o menos importante, mesmo pq comparar REST (ou melhor ROA) com SOA é quase como comparar laranjas com maçãs, um é modelagem baseado em serviços enquanto o outro é em recursos.