Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Richard Monson-Hafael postou um e-mail do leitor Dave Podnar falando sobre os 5 estágios necessários para que se possa trabalhar com Web Service.
[list]1. Negação - É Simple Object Access Protocol (Protocolo de Acesso Simples a Objetos), certo?
2. Envolvimento Saturado - OK, Eu irei ler as especificações SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ, JAX-P... Após, irei verificar o Wiki e finalmente seguir um exemplo mostrando os lados cliente e serviço.
3. Raiva - Não posso acreditar que esses @%#@&* o tornaram tão difícil!
4. Culpa - Todo mundo tá usando Web Services, só pode ser eu, devo estar esquecendo de algo.
5. Aceitação - É o que é, Web Services não são simples ou fáceis.[/list]
O pessoal do TheServerSide comenta sobre o assunto. E no Brasil, o que o pessoal sente sobre Web Services? Quais suas opiniões sobre o modelo e a dificuldade de implementação?
Olha Miojo,
Eu acredito que WebService é uma solução elegante para trabalhar-se com sistemas legados que precisam ser interligados. No entanto, não vejo a solução como definitiva ou única e também não aplicaria em todos os casos, até porque gerar/exportar/importar 'txts'(ou xmls) pode ser uma alternativa mais fácil dependendo da situação.
Nesses últimos tempos, tem havido um 'movimento' contra a idéia de 'WebServices == RPC+XML', em favor de 'WebServices == troca de documentos'. O Spring criou o subprojeto SpringWS, que visa tratar WS não como uma extensão do Spring remoting (RPC), mas como troca de documentos. Na última JavaMag o Osvaldo Doederlein também escreveu um artigo no mesmo sentido.
Realmente, se o objetivo é interoperabilidade, encarar WS como RPC pode dificultar a satisfação do requisito principal (apesar de ser uma implementação mais simples e direta).
Mas creio que o 'normal' no mercado ainda seja isso, 'sistema X chama sistema Y usando XML', porque é mais fácil, porque é mais rápido, porque é mais barato. E pela minha experiência com o Axis, acho que não é tão fácil, rápido e barato assim...
É aquela história do sexo na adolescência: todo mundo diz que faz, quase ninguém faz de verdade, e quem faz, não faz direito... XD _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Mas a grande mierda é que a gente precisa deles... -sigh-- _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Eu também não ligava para webservices, até que um dia eu entendi "realmente" pra que serviam. Quem apenas desenvolve sites pro tio ou faz fibonacci pro professor da faculdade pode continuar achando que é merda, pois não vai ajudar vocês muito mesmo.
É de tão merda que é, a nova onda agora é SOA. O Google com todas suas apis também são uma merda então. Yahoo maps outra merda.
Eu também não ligava para webservices, até que um dia eu entendi "realmente" pra que serviam. Quem apenas desenvolve sites pro tio ou faz fibonacci pro professor da faculdade pode continuar achando que é merda, pois não vai ajudar vocês muito mesmo.
É de tão merda que é, a nova onda agora é SOA. O Google com todas suas apis também são uma merda então. Yahoo maps outra merda.
SOA não necessariamente é feito com Webservices. Aliás, é mais comum ver uma "pseudo SOA" com RMI do que com Webservices.
Eu também não ligava para webservices, até que um dia eu entendi "realmente" pra que serviam. Quem apenas desenvolve sites pro tio ou faz fibonacci pro professor da faculdade pode continuar achando que é merda, pois não vai ajudar vocês muito mesmo.
É de tão merda que é, a nova onda agora é SOA. O Google com todas suas apis também são uma merda então. Yahoo maps outra merda.
Vc está certo.. em partes. IMHO, a nova onda não é WebServices, ou SOA, FDP, PQP, ou seja-la-o-que-for. O que acontece é que o mercado procura por soluções nas quais os WebServices e SOA se propõe a resolver. Agora, não significa que os WebServices vão continuar por muito tempo. Na minha opinião, essa tecnologia serviu mais para abrir a nossa mente e nos fez 'acordar' pra nova realidade. Com certeza daqui algum tempo (espero que seja pouco) surgirão tecnologias que fazem a mesma coisa e de maneira muito mais simples.
Embora o mercado peça por tecnologias complexas, os desenvolvedores pedem por ferramentas mais simples. O que resta é tentar unir as duas coisas. _________________Daniel F. Martins
O problema dos WS's é que eles ainda não são tão compatíveis quanto se diz.
Ja trabalhei com webservices usando Axis, o BEA Workshop etc, e as vezes, os WSDL's gerados por uma ferramenta não são compreendidos por outra..
Agora.. dentro de um ambiente 100% BEA por exemplo, onde todos usam o BEA Workshop (a ide da bea), WebServices funcionam perfeitamente.. e é relativamente simples montar soluções de integração no "estilo" SOA..
O problema dos WS's é que eles ainda não são tão compatíveis quanto se diz.
Ja trabalhei com webservices usando Axis, o BEA Workshop etc, e as vezes, os WSDL's gerados por uma ferramenta não são compreendidos por outra..
Agora.. dentro de um ambiente 100% BEA por exemplo, onde todos usam o BEA Workshop (a ide da bea), WebServices funcionam perfeitamente.. e é relativamente simples montar soluções de integração no "estilo" SOA..
E a causa desse problema é justamente o fato de que WebServices são encarados como 'chamadas de métodos remotos via XML'. Você cria primeiro uma interface Java, pra depois deixar a ferramenta gerar o WSDL pra você. O problema é que, se o que você quer é interoperabilidade, o WSDL deve ser encarado como um contrato, que deve ser elaborado de tal forma a ser interoperável, entre contextos, entre linguagens.
Isso num contexto de exposição de serviços entre empresas, ou de integração entre grandes sistemas de uma mesma empresa (independentes, com muito legado). Nesse caso, alterar contratos/protocolos é difícil, já que todas as empresas/equipes envolvidas têm que concordar com a mudança, o que é praticamente impossível, a não ser que o serviço simplesmente não funcione como está.
Já num contexto onde o que se quer é apenas um sistema 'chamar' outro, ou distribuir o processamento entre servidores, tudo na intranet, e você tem poderes para dizer 'agora é assim e pronto', outras tecnologias (RMI, Hessian, até mesmo EJB) são muito mais apropriadas, por serem mais simples, mais fáceis, mais performáticas (que Web Services feito direito), mas que não são usadas porque a moda agora é SOA via SOAP.
_________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Nao me importo se tem XML ou nao... o que me incomoda eh quando EU tenho que botar a mao no XML...
WebServices tem q ser q nem EJB3 com Anotacoes...
É disso que eu estava falando. Na minha opinião, os WebServices suprem as necessidades dos sistemas 'modernos', mas o bagulho é arcaico! O negocio vai lá e manda um monte de XML pro outro lado, que faz parsing nesse XML e chama um método. Nada contra o XML, mas isso bem que podia se tornar transparente pra quem desenvolve. _________________Daniel F. Martins
O problema dos WS's é que eles ainda não são tão compatíveis quanto se diz.
Ja trabalhei com webservices usando Axis, o BEA Workshop etc, e as vezes, os WSDL's gerados por uma ferramenta não são compreendidos por outra..
Agora.. dentro de um ambiente 100% BEA por exemplo, onde todos usam o BEA Workshop (a ide da bea), WebServices funcionam perfeitamente.. e é relativamente simples montar soluções de integração no "estilo" SOA..
E a causa desse problema é justamente o fato de que WebServices são encarados como 'chamadas de métodos remotos via XML'. Você cria primeiro uma interface Java, pra depois deixar a ferramenta gerar o WSDL pra você. O problema é que, se o que você quer é interoperabilidade, o WSDL deve ser encarado como um contrato, que deve ser elaborado de tal forma a ser interoperável, entre contextos, entre linguagens.
Concordo.. o problema é que a "facilidade" que as ferramentas oferecem para geração de wsdl a partir de classes java por exemplo, da essa falsa impressão de que um wsdl é algo pouco importante, afinal ele foi gerado automaticamente..
na minha ex-empresa o wsdl era o ponto de partida pra criação de um serviço, e nao uma classe java.. não sei se todos compreendem dessa forma hehe até pq é relativamente chato escrever um wsdl e muita gente é preguiçosa e prefere fazer java -> wsdl e nao ao contrario..
na minha ex-empresa o wsdl era o ponto de partida pra criação de um serviço, e nao uma classe java.. não sei se todos compreendem dessa forma hehe até pq é relativamente chato escrever um wsdl e muita gente é preguiçosa e prefere fazer java -> wsdl e nao ao contrario..
É difícil criar o WSDL porque as ferramentas que existem hoje focam em RPC. Na medida em que a outra abordagem se tornar mais popular, as ferramentas vão evoluir nesse sentido. Bem, isso se essa abordagem pegar mesmo, já que é mais fácil viver em negação e fazer de conta que o problema não existe _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
na minha ex-empresa o wsdl era o ponto de partida pra criação de um serviço, e nao uma classe java.. não sei se todos compreendem dessa forma hehe até pq é relativamente chato escrever um wsdl e muita gente é preguiçosa e prefere fazer java -> wsdl e nao ao contrario..
É difícil criar o WSDL porque as ferramentas que existem hoje focam em RPC. Na medida em que a outra abordagem se tornar mais popular, as ferramentas vão evoluir nesse sentido. Bem, isso se essa abordagem pegar mesmo, já que é mais fácil viver em negação e fazer de conta que o problema não existe
po.. eu ja usei o XML spy.. mas pra fazer um wsdl o notepad ja é suficiente hehe basta saber como escrever (ai entra a galera q nao sabe nada e quer gerar ele a partir de codigo) hehehe
po.. eu ja usei o XML spy.. mas pra fazer um wsdl o notepad ja é suficiente hehe basta saber como escrever (ai entra a galera q nao sabe nada e quer gerar ele a partir de codigo) hehehe
po.. nada contra quem nao sabe.. eu tb nao sei muita coisa!! ahuehua
mas essa geraçao toda a partir de diversas ferramentas, axis, visual studio .net que gera a maioria dos problemas..
Hehe tava brincando ! Mas, o lance de se gerar o WSDL na mão e depois construir os programas em cima, deve realmente ser mais vantajoso por ter maior garantia de compatibilidade com WS's escritos em outras linguagens e tal... _________________Daniel F. Martins
Não seria exatamente 'na mão', mas auxiliado por algum tipo de ferramenta.
carneiro
Acho que os programadores de hoje deviam gastar mais tempo com coisas inteligentes, ao invés de perder tempo fazendo xmls...
Mas isso não seria exatamente função de um programador, mas do analista que projeta o serviço, e/ou provavelmente de acordo com acertos feitos entre as empresas parceiras que vão utilizar o serviço.
Se esse passo não existe (especificação da interface e/ou acordo entre parceiros), então você deveria reavaliar se é realmente o caso de usar um Web Service, e se a implementação que é usada hoje é realmente um Web Service ou é apenas uma chamada de método remoto via SOAP (isto é, poderia ser trocado sem problemas por REST, RMI, Hessian, Burlap, etc.), porque isso quer dizer que a facilidade do programador é posta em primeiro plano, em detrimento da interoperabilidade, que teoricamente é o requisito que Web Services se propõe a resolver. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Francamente falando considero a evolução de interoperabilidade via web services tão consistente que em breve veremos plataformas IBM zSeries realizando o que é chamado de processamento não produtivo em XML parsing, ou seja uma arquitetura de processamento dedicada para este tipo de demanda computacional. Hoje já existe infraestrutra semelhante para SSL (criptografar/descr...). Este comentario diz respeito as problemas de perfomance que envolvem a utilização de WS. Embora muitas pessoas aqui critiquem a complexidade, minha experiencia em desenvolvimento de sistema para Bancos e Financeiras mostram que o maior impedidor é perfomace (1.000 transações por segundo.).
Também acredito que a tendência é a utilização de Documentos para troca de mensagens, além disso é importante lembrar que integração com sistema legado muitas vezes é realizado assincronamente, embora WS reduza o acoplamento entre plataformas a utilização de RPC estabelece um acoplamento entre os processos, ou seja, existe um dependência entre os processos no sentido que ambos precisam estar ativos e a performance de um influência a performance do outro, soluções orientadas a Documento e assincronas resolvem este problema (quando é adequada para o cenário, claro).
No que diz respeito a problemas com interoperabilidade creio que a utilização das recomendações do Basic Profile da WS-I dão excelente suporte, e concordo com os comentarios acima, a chamda definição das interfaces na perpectiva top-botton (começando pelo WSDL) é a forma mais adequada de evitar influencia de alguma plataforma.
Deivson Rayner T. Costa
Fóton Informática S.A.
_________________Deivson Rayner
Brasilia - DF
Borland JBuilder Product Certified
Sun Certified Java Programmer
Sun Certified Business Component Developer
Sun Certified Developer for Java Web Services
Sun Certified Enterprise Architect part I
Sun Certified Mobile Application Developer
Embora muitas pessoas aqui critiquem a complexidade, minha experiencia em desenvolvimento de sistema para Bancos e Financeiras mostram que o maior impedidor é perfomace (1.000 transações por segundo.).
Bem, estão tentando diminuir esse problema com o FastInfoset, que é um formato binário equivalente ao XML, porém mais fácil de se fazer parsing e serialização de dados, e que resulta normalmente em mensagens menores. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Embora muitas pessoas aqui critiquem a complexidade, minha experiencia em desenvolvimento de sistema para Bancos e Financeiras mostram que o maior impedidor é perfomace (1.000 transações por segundo.).
Bem, estão tentando diminuir esse problema com o FastInfoset, que é um formato binário equivalente ao XML, porém mais fácil de se fazer parsing e serialização de dados, e que resulta normalmente em mensagens menores.
Web-services são uma "pain in the ass" tão grande, que parecem até uma paródia de mau-gosto daquela famosa frase de Einstein. Ficaria mais ou menos assim:
Web-services: Faça coisas simples, mas não da maneira mais simples
Web-services são uma "pain in the ass" tão grande, que parecem até uma paródia de mau-gosto daquela famosa frase de Einstein. Ficaria mais ou menos assim:
Web-services: Faça coisas simples, mas não da maneira mais simples
(não estou dizendo que WebServices é a melhor, ok!) _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
(não estou dizendo que WebServices é a melhor, ok!)
Ahh, quase sempre, vai!
Não, aliás, quase nunca (pelo menos esse 'mais simples' absoluto, sem contextualização).
Qual a maneira mais simples de se fazer uma página que mostre uma tabela com informações gravadas num banco de dados, usando Java?
- JSP+JDBC? Usa apenas APIs padrão da JRE, requer apenas um JAR, que só precisa estar no classpath, e você não precisa nem compilar nada, basta jogar no servidor e pronto!
- JSP+JSTL? Bem, continua precisando apenas do JAR do driver, não precisa compilar nada, a sintaxe fica mais resumida, mas você precisa aprender como usar JSTL.
Estas são as soluções mais simples nas quais eu pude pensar, e inclusive são usadas em muitos casos, mas são as melhores soluções? Depende.
Se você for fazer um teste, ou um relatório isolado, ou algo do tipo, perfeito. Mas agora imagine que esse sistema vai ter 200 telas, 20 tabelas, regras de negócio complexas, 5 programadores trabalhando em paralelo e requisitos consideráveis de segurança e performance. 'Inferno' é a palavra que vem à mente.
Uma arquitetura do tipo 'Framework+Spring+Hibernate' está longe de ser simples, mas com certeza é bem melhor que as alternativas anteriores.
"- Ah, mas a idéia era 'o mais simples possível', considerando os requisitos e a complexidade geral, não pontual!"
Exato! E isso nos leva de volta ao assunto do tópico:
Web Services não é simples, com isso eu concordo plenamente. Mas que tecnologias cumprem os requisitos, digamos, interoperabilidade entre plataformas e linguagens, tecnologia madura, padrões abertos, suporte por ferramentas, uso da indústria? É complicado isso, Web Services não é a coisa mais simples ou mais fácil do mundo, mas o que vamos usar no lugar?
Claro, se os seus requisitos não são esses o argumento não vale, mas daí você deve se perguntar se realmente deveria estar usando Web Services... _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Não, aliás, quase nunca (pelo menos esse 'mais simples' absoluto, sem contextualização).
Claro! Desde que o 'simples' resolva o problema.
ronaldtm
Qual a maneira mais simples de se fazer uma página que mostre uma tabela com informações gravadas num banco de dados, usando Java?
Cara, se você não tivesse colocado o ",usando Java" no final, eu já tinha a resposta na ponta da língua!
ronaldtm
- JSP+JDBC? Usa apenas APIs padrão da JRE, requer apenas um JAR, que só precisa estar no classpath, e você não precisa nem compilar nada, basta jogar no servidor e pronto!
- JSP+JSTL? Bem, continua precisando apenas do JAR do driver, não precisa compilar nada, a sintaxe fica mais resumida, mas você precisa aprender como usar JSTL.
Estas são as soluções mais simples nas quais eu pude pensar, e inclusive são usadas em muitos casos, mas são as melhores soluções? Depende.
Se sua equipe manja legal de JSTL, porquê não utilizá-la? O 'simples' é sim, como você disse, relativo demais. O importante é saber o 'threshold'.
ronaldtm
Se você for fazer um teste, ou um relatório isolado, ou algo do tipo, perfeito. Mas agora imagine que esse sistema vai ter 200 telas, 20 tabelas, regras de negócio complexas, 5 programadores trabalhando em paralelo e requisitos consideráveis de segurança e performance. 'Inferno' é a palavra que vem à mente.
Isso sim é algo indiscutível!
ronaldtm
Uma arquitetura do tipo 'Framework+Spring+Hibernate' está longe de ser simples, mas com certeza é bem melhor que as alternativas anteriores.
Melhor isso do que lidar com EJB! Mas aí também depende. Se uma equipe consegue ser produtivo mesmo usando EJB (existe uma?), não há necessidade de utilizar a arquitetura que você descreveu. Claro, isso se o seu cliente tiver umas verdinhas pra gastar num Application Server decente.
ronaldtm
Web Services não é simples, com isso eu concordo plenamente. Mas que tecnologias cumprem os requisitos, digamos, interoperabilidade entre plataformas e linguagens, tecnologia madura, padrões abertos, suporte por ferramentas, uso da indústria? É complicado isso, Web Services não é a coisa mais simples ou mais fácil do mundo, mas o que vamos usar no lugar?
Por enquanto, vamos usar os Webservices mesmo! Fazer o quê?! _________________Daniel F. Martins
Melhor isso do que lidar com EJB! Mas aí também depende. Se uma equipe consegue ser produtivo mesmo usando EJB (existe uma?), não há necessidade de utilizar a arquitetura que você descreveu. Claro, isso se o seu cliente tiver umas verdinhas pra gastar num Application Server decente.
Eu também não disse que essa era a melhor arquitetura, mas pelo menos no caso descrito ela é melhor do que as anteriores.
EJB é um caso sério... eu era extremamente cético, devido a ter sido 'escaldado' em um projeto usando EJB 1.1, e visto que o 2.1 não melhorou muita coisa. Mas o EJB3 está realmente mais simples, e se tornou uma alternativa viável, pelo menos para consideração. Bem, só o tempo dirá... _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Mas que tecnologias cumprem os requisitos, digamos, interoperabilidade entre plataformas e linguagens, tecnologia madura, padrões abertos, suporte por ferramentas, uso da indústria? É complicado isso
Mas que tecnologias cumprem os requisitos, digamos, interoperabilidade entre plataformas e linguagens, tecnologia madura, padrões abertos, suporte por ferramentas, uso da indústria? É complicado isso
Texto
Texto, claro, por que eu não pensei nisso antes? Ah sim, pensei! Mas daí me veio em mente os problemas de definição de dados, desde o formatos dos registros (Campos de tamanho fixo? separados por vírgulas? tabs?), formato de tipos complexos (hierárquicos, compostos, colecoes), até a codificação dos caracteres (UTF-8? UTF-16? ISO-8859-1? Qualquer coisa, e quem for ler que se vire?).
Quando não encontrar uma solução boa, simplesmente diga 'f0da-se' e pronto? _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
- Interoperabilidade entre plataformas (Windows/Linux/Mac).
- linguagens (printf e scanf),
- tecnologia madura (muuuuuuito)
- padrões abertos (claro.. texto ASCII)
- suporte por ferramentas (Sim, qualquer uma lê e grava sem problemas e algumas até fazem muito mais)
- uso da indústria? (simplesmente era o padrão antes da porcaria dos WebServices. )
Quando não encontrar uma solução boa, simplesmente diga 'f0da-se' e pronto?
Foda-se? Foda-se é usar WebServices.
Gerar WSDL é o mesmo que especificar um doc TXT. A diferença do TXT é que qualquer ferramenta pode facilmente especificar um, inclusive o Notepad, coisa que o WSDL se torna um inferno.
No final, da no mesmo. O problema é que uma delas já é padrão, a outra está só engatinhando (e bem mal, por sinal)
Aliás... eu não diria que Webservices é maduro, se fosse assim, EJB2.0 também seria maduro. E, no entando, dado o auê que foi montado em torno dele, pode ser considerado o maior erro dos últimos anos _________________Vitor Pamplona
http://vitorpamplona.com @vitorpamplona
1. ASCII não é interoperável (caracteres acima da faixa 0~127 não são padronizados, o que dificulta (pra não dizer impossibilita) a interpretação correta das mensagens
2. qualquer ferramenta lê e escreve texto, mas nenhuma te ajuda a escrever ou ler dados estruturados (você vai escrever um parser pra cada serviço?)
3. com certeza algumas empresas usam trocas de arquivos texto como forma de integração (já vi um caso que ainda usava ftp pra transportar as mensagens para o servidor), mas não acho que esse seja o padrão, e mesmo que fosse, duvido que alguém em sã consiência recomendasse isso se houvessem outras alternativas mais apropriadas (praticamente qualquer outra).
4. gerar WSDL não é o mesmo que especificar um documento txt. WSDL é uma linguagem completa para esse tipo de definição, com estrutura, tipagem. Fora que é um padrão aberto, o que possibilita que alguém construa ferramentas para ajudar na tarefa de criá-lo (ou, como existe hoje, criá-lo a partir de interfaces de programação).
No final, os detalhes que você preferiu ignorar fazem toda a diferença. O problema é que uma delas tenta resolver os problemas de interoperabilidade encontrados ao longo dos anos mesmo à custa da simplicidade, e a outra na verdade trabalha num nível bem mais baixo, e sequer sabe que os problemas existem.
Mas que bost4! O Vitor, com seus argumentos sem nexo, tem o poder de me fazer defender coisas das quais eu não gosto! _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Aliás... eu não diria que Webservices é maduro, se fosse assim, EJB2.0 também seria maduro. E, no entando, dado o auê que foi montado em torno dele, pode ser considerado o maior erro dos últimos anos
Eu diria que o erro é como Web Services são usados. São usados em situações onde não são apropriados e nas situações em que são apropriados são usados incorretamente. Pra vender mais, os fornecedores o vendem como a 'bala de prata' do mundo corporativo, e todo mundo fica achando que tudo é uma droga que não serve pra nada, depois de ver que ele não serve para aquilo que se acreditava (expectativas exageradas criadas pelo vendedor).
A sua visão é perfeitamente justificável, Vitor, mas é míope, vinda provavelmente da observação de maus usos da tecnologia (mesmo porque é realmente difícil encontrar um caso de bom uso por aí...) _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
1. ASCII não é interoperável (caracteres acima da faixa 0~127 não são padronizados, o que dificulta (pra não dizer impossibilita) a interpretação correta das mensagens
ueh.. então faça UTF-8, UTF-16, ISO-8859-1 ou o que for. Os padrões estão aih, é só usar. E pode ter certeza que estão muito mais maduros do que qualquer padrãozinho de Webservice. Só que eu acho que sistemas mais antigos (DOS) só importarão ASCII.
ronaldtm
2. qualquer ferramenta lê e escreve texto, mas nenhuma te ajuda a escrever ou ler dados estruturados (você vai escrever um parser pra cada serviço?)
Dados estruturados até Pascal gerava. Record roox! . Já que vc trabalha com bancos, faça o teu Webservice se comunicar com um Mainframe COBOL
ronaldtm
3. com certeza algumas empresas usam trocas de arquivos texto como forma de integração (já vi um caso que ainda usava ftp pra transportar as mensagens para o servidor), mas não acho que esse seja o padrão, e mesmo que fosse, duvido que alguém em sã consiência recomendasse isso se houvessem outras alternativas mais apropriadas (praticamente qualquer outra).
Não é padrão somente por questões de marketing. Se todo mundo diz que Webservices é padrão, então é padrão, fazer o q... Mas a 5 anos atrás, arquivos textos governavam. O problema é que nem todos desse "todo mundo" usaram Webservices.
ronaldtm
4. gerar WSDL não é o mesmo que especificar um documento txt. WSDL é uma linguagem completa para esse tipo de definição, com estrutura, tipagem. Fora que é um padrão aberto, o que possibilita que alguém construa ferramentas para ajudar na tarefa de criá-lo (ou, como existe hoje, criá-lo a partir de interfaces de programação).
Sim, uma linguagem tão chata que vc se enoja só de ver o arquivo. O que é mais fácil de entender, uma planília com as colunas e posições iniciais ou um arquivo desses? Tenta fazer um WSDL bem estruturado para vc ver como fica a leitura dele. Se o cara não tiver uma ferramenta apropriada é impossível de entender.
ronaldtm
No final, os detalhes que você preferiu ignorar fazem toda a diferença. O problema é que uma delas tenta resolver os problemas de interoperabilidade encontrados ao longo dos anos mesmo à custa da simplicidade, e a outra na verdade trabalha num nível bem mais baixo, e sequer sabe que os problemas existem.
Não fazem tanta diferença assim. Acredite eu já fiz isso e já participei de outros projetos que também se utilizavam de arquivos texto para intercomunicação entre empresas.
ronaldtm
Mas que bost4! O Vitor, com seus argumentos sem nexo, tem o poder de me fazer defender coisas das quais eu não gosto!
É o prazer da batalha!
Vai por mim, já usei os dois. É a mesma bosta. A diferença é que ou você usa algo como o Axis e gera os WSDL via código Java e o teu parceiro que se foda, ou use os arquivos textos que serão mais simples de usar e mais fáceis de repassar as regras para o teu parceiro.
O que é mais fácil?
Isso:
ou isso?
E não venha me dizer que esse é um caso irreal, pq o WSDL trafegando objetos java é muito mais complexo de entender do que programar em Brainfuck. Eu diria que é impossível sem ter uma boa (e cara) ferramenta.
miojoPosts:1358
Fonte: TheServerSide.com