Galera. Boa noite.
Que livro, em português, vocês indicariam para estudar web service ?
Obrigado.
Olá
Não acredito que exista. Poucos livros de TI são traduzidos. A maioria não é bem traduzida.
Vai aqui o velho, antipático porém valioso conselho: se não consegue ler inglês com fluência, já sabe qual assunto precisa estudar com mais afinco na área de TI. Sem ao menos ler inglês bem, dificilmente sobreviverá na área.
[]s
Luca
Um outro ponto interessante é que comprar livros em inglês (na amazon por exemplo) além da maior variedade, costuma ficar mais barato que comprar os mesmos livros aqui no Brasil traduzidos para o português.
Olá
Bem… para dizer a verdade… existem vários livros em português como você mesmo já deve ter achado no Google. Eu tenho um livro em português que achei muito bom no tempo em que ainda acreditava que web services com SOAP fazia algum sentido. Chama-se SOA e Web Services em Java (é ainda do tempo da porcaria chamada JAX-RPC que a própria Sun jogou no lixo).
[]s
Luca
[quote=Luca]Olá
Bem… para dizer a verdade… existem vários livros em português como você mesmo já deve ter achado no Google. Eu tenho um livro em português que achei muito bom no tempo em que ainda acreditava que web services com SOAP fazia algum sentido. Chama-se SOA e Web Services em Java (é ainda do tempo da porcaria chamada JAX-RPC que a própria Sun jogou no lixo).
[]s
Luca
[/quote]
Olá Luca.
Não descordo de você. Inglês deve ser o nosso idioma. Infelizmente não tive essa cultura no início dos meus estudos. Agora, tenho que correr atrás do prejuízo.
Mas enfim. Você acha que essa tecnologia não faz sentido por que ? Será que vale a pena eu investir meu tempo estudando isso ? Mesmo que não vale a pena tenho que estudar alguma coisa porque as vagas no mercado praticamente todas pedem conhecimento de web service. O que você orienta focar então nesta tecnologia ?
Abraços!
Na verdade webservices valem a pena sim, o que ele quis dizer é que o JAX-RPC.
A Sun agora tem outras especificações para uso de webservices JAX-WS (WS-* SOAP) e JAX-RS (Rest).
Abraços,
Olá
As empresas acreditam em web services usando SOAP, WSDL, WS-* e outras tranqueiras. Há “consultores” que sobrevivem disto. Há grandes vendedores de “soluções”. Portanto há mercado para isto e até acho que vale a pena aprender.
Só que é uma droga, é RPC elevado a porcarésima potência. Basta começar a trabalhar com isto para perceber como é complicado. Há meios de se esconder parte da complexidade debaixo do tapete usando geradores do código (milhares de linhas Java e XML). Mas um dia alguém terá que lidar com toda esta nojeira gerada.
Ainda há muito espaço no mercado para quem entende de web services burrocráticos. Se seu objetivo é ganhar sua graninha, vá em frente.
Mas se quer participar de projetos de integração de sistemas baseados em coisas mais simples, mais gostosas de trabalhar e na minha opinião de mais futuro, aprenda também REST. Aliás o melhor caminho é aprender scheme, SOAP, WSDL, WS-*, etc. e depois aprender REST.
O livrinho que indiquei é bom porque é bem facinho de ler. Mas na parte de código Java está obsoleto. Não leia nada que tenha JAX-RPC na frase a não ser que seja para falar mal.
[]s
Luca
Olá
O livro RESTFul Web Services é muito bom (em inglês, não sei da tradução) mas exige um mínimo de conhecimentos de Ruby e Rails. Se você conhece um tiquinho de Ruby já vale a pena comprá-lo.
[]s
Luca
[quote=Luca]Olá
As empresas acreditam em web services usando SOAP, WSDL, WS-* e outras tranqueiras. Há “consultores” que sobrevivem disto. Há grandes vendedores de “soluções”. Portanto há mercado para isto e até acho que vale a pena aprender.
Só que é uma droga, é RPC elevado a porcarésima potência. Basta começar a trabalhar com isto para perceber como é complicado. Há meios de se esconder parte da complexidade debaixo do tapete usando geradores do código (milhares de linhas Java e XML). Mas um dia alguém terá que lidar com toda esta nojeira gerada.
Ainda há muito espaço no mercado para quem entende de web services burrocráticos. Se seu objetivo é ganhar sua graninha, vá em frente.
Mas se quer participar de projetos de integração de sistemas baseados em coisas mais simples, mais gostosas de trabalhar e na minha opinião de mais futuro, aprenda também REST. Aliás o melhor caminho é aprender scheme, SOAP, WSDL, WS-*, etc. e depois aprender REST.
O livrinho que indiquei é bom porque é bem facinho de ler. Mas na parte de código Java está obsoleto. Não leia nada que tenha JAX-RPC na frase a não ser que seja para falar mal.
[]s
Luca[/quote]
Essa minha preocupação de aprender webservice é porque estou numa empresa que consome webservice de várias empresas.
Estou tendo dificuldade de compreender aquele arquivo xml para criar minha classe java. Dentro deste arquivo preciso identificar
o que é uma classe, o que é um atributo, quais o métodos preciso chamar…etc.
Pelo que entendi preciso saber mais sobre webservice cliente. Neste caso entra essas siglas JAX-RPC e essas outras. OU isso fico
no lado servidor.
Caraca…é difícil até explicar a minha dúvida.
Luca.
Essa minha preocupação de aprender webservice é porque estou numa empresa que consome webservice de várias empresas.
Olá
JAX-RPC era a API antiga de web services do JEE, Hoje se deve usar JAX-WS como já disseram aqui.
No seu caso acho que não há como fugir. Precisará aprender como consumir o que os outros fazem. Os livros citados aqui devem servir.
Ministrei um tutorial de web services (WS, scheme, XML-RPC, SOAP, WSDL-UDDI, Axis2 e REST) no ConexãoJava de 2006. É bem antigo e apenas introdutório. São 7 PDFs para serem lidos de acordo com a numeração. Não precisa endender tudo para ter uma noção geral. Quem ainda não tem o Dropbox como back up on line pode passar a usar de graça em https://www.dropbox.com/referrals/NTIwOTMyMTU5 (ganho mais 250 Mb caso alguém entre)
ConexãoJava 2006-Tutorial Web services - Luca Bastos e Daniel Quirino
[]s
Luca
[quote=Luca]Olá
As empresas acreditam em web services usando SOAP, WSDL, WS-* e outras tranqueiras. Há “consultores” que sobrevivem disto. Há grandes vendedores de “soluções”. Portanto há mercado para isto e até acho que vale a pena aprender.
Só que é uma droga, é RPC elevado a porcarésima potência. Basta começar a trabalhar com isto para perceber como é complicado. Há meios de se esconder parte da complexidade debaixo do tapete usando geradores do código (milhares de linhas Java e XML). Mas um dia alguém terá que lidar com toda esta nojeira gerada.
Ainda há muito espaço no mercado para quem entende de web services burrocráticos. Se seu objetivo é ganhar sua graninha, vá em frente.
Mas se quer participar de projetos de integração de sistemas baseados em coisas mais simples, mais gostosas de trabalhar e na minha opinião de mais futuro, aprenda também REST. Aliás o melhor caminho é aprender scheme, SOAP, WSDL, WS-*, etc. e depois aprender REST.
O livrinho que indiquei é bom porque é bem facinho de ler. Mas na parte de código Java está obsoleto. Não leia nada que tenha JAX-RPC na frase a não ser que seja para falar mal.
[]s
[/quote]
Oi Luca, vou discordar fortemente agora de você. Primeiro que WebServices não está atrelado à RPC, pois vc tem 2 opções e uma delas, a que deve ser utilizada, é Document Style.
Quanto à necessidade do SOAP, existem uma série de cenários onde não se pode fazer com arquitetura Restful, por exemplo propagar a segurança em 3 sistemas distintos usando certificado digital. Outro exemplo é quando um processo precisa fazer uma coordenação entre 3 outros processos subjacentes para completar a execução do seu problema de negócio, por Restful ser statless, você não consegue manter o estado do processamento.
Se você tiver que traduzir protocolo para trabalhar com Mensageria de forma Assíncrona para aumento de performance, se for usar alguma técnica de Throttling com persistência em FileStore, se for capturar erros de sistema em forma de estrutura de dados e não somente um “enum” de erros, logo você tem uma porrada de cenários, principalmente no que tange integração onde o WS* são infinitamente mais simples do que soluções proprietárias de EAI como Tuxedo como tínhamos antes.
Basta qualquer um pegar um Lightweight ESB como Apache Camel e olhar o conjunto de patterns de integração que o mesmo trata em cima de SOAP - http://camel.apache.org/enterprise-integration-patterns.html
Vejo muitos “Restafarians” falando mal de ESB e integração, mas não possuem experiência na prática de ter que integrar mainframe, SAP, sistema de biling arcaico e por aí vai.
Um clássico que sempre vejo é o pessoal comparar BPM por exemplo à sistema de workflow, quando na verdade, BPM está ligado à engenharia de software para mapeamento de processos de negócio, otimização e analisar gaps.
Para o pessoal que quer aprender WebServices, aprenda de verdade SOAP e WSDL e não apenas API geradoras. Aprenda aas motivações de cada especificação WS*, antes de aprender a tecnologia.
Como Pattern, tudo depende da motivação e você não vai sair usando a stack inteira, somente pedaços em situações específicas.
Kenobi[/quote]
Olá
[quote=Kenobi]
Oi Luca, vou discordar fortemente agora de você. Primeiro que WebServices não está atrelado à RPC, pois vc tem 2 opções e uma delas, a que deve ser utilizada, é Document Style.
Quanto à necessidade do SOAP, …[/quote]
Então… não acho que haja tanta discordância assim.
-
Nem sempre a turma usa Document Style que realmente deveria ser sempre o adotado. Ainda há muito RPC por aí com acoplagem excessiva.
-
Quanto a questão de coordenação isto pode ser resolvido usando mecanismos compensatórios.
Nunca disse que se pode eliminar o uso de SOAP 100% até porque há muito legado ou sistemas de clientes por aí fara integrar onde não podemos alterar o modo de integração.
Mas sempre que for possível a escolha, como por exemplo onde cabem transações compensatórias, eu preferiria usar REST
Concordo e assino embaixo.
[]s
Luca
Luca até entendi no caso de transações, você usar Compensations. Mas pra ficar claro, eu quis dizer um processo “composto” por 3 outros subjacentes definidos, onde você precisa manter o estado do processo, enquanto processa “consultas” por exemplo.
É mais fácil utilizar uma solução de orquestração, até mesmo com REST. O Activiti BPM, projeto novo do pessoal do core team da jBoss que foi pra alfresco, está começando já com interface REST 
Olá
[quote=Kenobi]Luca até entendi no caso de transações, você usar Compensations. Mas pra ficar claro, eu quis dizer um processo “composto” por 3 outros subjacentes definidos, onde você precisa manter o estado do processo, enquanto processa “consultas” por exemplo.
É mais fácil utilizar uma solução de orquestração, até mesmo com REST. O Activiti BPM, projeto novo do pessoal do core team da jBoss que foi pra alfresco, está começando já com interface REST [/quote]
Bem, não tenho idéia do que seja “Compensations”. Se for o mesmo que penso de transações compensatórias, não vejo porque não serviria.
REST não é bala de prata. Mas o problema é que há muita gente por aí que pensa que SOAP é (sei que não é seu caso).
Recomendo ao autor do post inicial que estude web services tradicional. A empresa dele vai usar. Mas recomendo a todos que tentem usar REST principalmente quando escreverem web services que ficarão a disposição de clientes externos. Sigam exemplos das grandes empresas como Amazon, eBay e outras. E leiam este tópico http://www.guj.com.br/posts/list/15/44429.java#430677
[]s
Luca
Meus dois herois “discutindo” para o bem de todos
Vejo muitos "Restafarians" falando mal de ESB e integração, mas não possuem experiência na prática de ter que integrar mainframe, SAP, sistema de biling arcaico e por aí vai. Concordo. Existem muitas generalizações, infelizmente a galera esquece que, se REST serve para X% dos casos onde se usa outras coisas, este X não é 100% – como nos casos onde vc não pode ter tanta latência. O Jim Webber, na palestra dele de sistemas Restful (acho que vi na globo.com a mesma q foi apresentada na Caellum e na TW/RS) comenta sobre usar Atom para varios sistemas que não precisam responder em milissegundos, achei bem sóbrio este pensamento. Entretanto em sistemas mais complexos imagino que nem ESB resolve, tendo que passar para coisas muito loucas.
Infelizmente existem no mercado quem foi pego pelos buzzwords. É SOA, Cloud, Fabrica de Software, agora falam em Agile (com o PMP escolhendo as tarefas do time, numa inversão de valores completa) e até Rest. Quem sobrevive ao bla-bla-bla faz um trabalho, imagino, maneirissimo.
Sem falar que as vezes a tecnologia vem ao nosso favor: Algum tempo atras comecei a redesenhar um sistema importante daqui do trampo que faz uma série de processamentos distribuidos. Como a ordem de algumas tarefas era importante, necessitava de uma certa ordem nas coisas, e ai por cima acumularam-se varias regras de negócio, questões de performance e, principalmente, limitações tecnológicas e fisicas. Porem no redesenho de tudo algumas coisas ficaram muito claras: se hoje eu tenho uma quantidade de storage maior e uma largura de banda maior entre as filiais e o datacenter por que não centralizar o processamento, fazendo os clientes meros “formularios de upload”? O Luca e o Kenobi me deram varias ideias naquela época mas o principal foi ver que era possivel “centralizar” os processos numa cloud e delegar certas tarefas para outras aplicações. Se o projeto vai sair, não sei, mas re-pensar no design, nos caminhos que tomamos é sempre importante – mas sem extremismos.
Por fim, o importante é olhar nos sistemas como um todo e ver o acoplamento, os gargalos, etc. Certas decisões de design podem criar legados terriveis que sobreviverão por mais tempo que nós – felizmente não existe bala de prata pra isso, só trabalhando pra ver (e contar com gente boa).
Fico muitíssimo lisonjeado pelo “herói” mas o Luca é o meu herói também Então discutir somente de maneira saudável, afinal, somos amigos além do mais :-).
Expor serviços em REST para clientes externos normalmente é uma boa prática, pois a maior parte dos serviços que se expõe pra fora da empresa precisam ser assíncronos ou síncronos de rápido processamento (poucas regras). Normalmente as questões de resolução de negócio, nas entranhas da empresa, podem processar até em CORBA (não sabemos) e o entry point precisa ser simplificado e se possível um modelo de contrato - Hypermedia, baseado nas Entidades - EntityServices, e utilizar técnicas de DDD pra tal 8)
Então, se dentro de uma empresa, cheia de regras e constraints, eu resolvo integrar 3 ou mais sistemas usando todo o tipo de tecnologia WS-*como transaction, autorization, security, etc, Não estou cometendo o equivoco de criar sistemas altamente acoplados ou isso é inevitavel (e, quem sabe, desejavel)? Pq pensando em como a web funciona, tão stateless, não consigo ver um caso pratico que não possa ser ‘simplificado’ - haja visto minha experiência de poucos anos com essa parada.
Se seu sistema é baseado em outros 3, não importa o que utilize, você estará sempre dependente dos demais.
Pense nas especificações WS-* como patterns e motivações. Você precisa criptografar parte da mensagem ? Você precisa Coordenar 3 processos simultâneos ? E por aí vai.
Utilizar Rest para integração é um pouco mais complicado (meu ponto de vista), principalmente quando se tem que lidar com mensagens assíncronas, tradução de protocolo ( nem tudo está em cima de HTTP).
Se for criação de um sistema do zero SOA, aí sim Restful seria uma excelente alternativa, mas precisa levar em conta vários outros requisitos como tempo de resposta.
Fiz uma orquestração Síncrona para um cliente que o processamento levava quase 1:30h. Otimizamos demais, colocamos cacheamento e o escambal, caiu para 27 minutos.
Quando redesenhamos o mesmo processo de forma Assíncrona , caiu pra menos de 5 minutos.
Então vai depdender muito também do que precisa, como o próprio Jim Webber disse.
Certo. Mas parece que REST só não é indicado em caso de legado ou de tempo de resposta… :twisted: