Já foi respondida com o exemplo que dei do Banco Postal que rodava em vários servidores diferentes sem alterar uma linha sequer no código. Na producão usa WAS, mas foi desenvolvido com Tomcat ou JBoss e eu executei várias vezes com o Jetty.
[]s
Luca[/quote]
Acho que não. Da sua maneira, vc continua acoplado a um servidor WEB. VOU REPETIR: Qual a diferença para uma solução com EJBs, onde vc fica acoplado a um Application Server e tem várias opções disponíveis no mercado!?
Serializa o Invocation? Esse invoker HTTP é só para Java-Java?
Luca wrote:
Esse problema de interoperabilidade entre protocolos de nível de aplicação é mesmo um saco. Eu não acho que um invoker do JBoss possa resolver isso de forma satisfatória, nem usando CORBA do lado .NET (aliás, nem sei se existe um ORB para .NET).
Com relação ao HTTP prover desacoplamento, eu concordo na questão do protocolo, mas daí começam a surgir as questões relacionadas a quanto do middleware subjacente você expõe no seu serviço. Dependendo do que você faz, o acoplamento só muda de nível.
Já foi respondido: com a solução Http qualquer plataforma pode fácilmente acessar a aplicação e é muito mais fácil pegar um .war e fazer rodar perfeitamente em qualquer Servlet Container do que pegar um .ear e fazer ele rodar perfeitamente em qualquer AS.
[quote=microfilo][quote=Taz]
Acho que não. Da sua maneira, vc continua acoplado a um servidor WEB. VOU REPETIR: Qual a diferença para uma solução com EJBs, onde vc fica acoplado a um Application Server e tem várias opções disponíveis no mercado!?
[/quote]
Já foi respondido: com a solução Http qualquer plataforma pode fácilmente acessar a aplicação e é muito mais fácil pegar um .war e fazer rodar perfeitamente em qualquer Servlet Container do que pegar um .ear e fazer ele rodar perfeitamente em qualquer AS.[/quote]
A pergunta foi em relação a acoplamento. Não há diferença. De uma maneira vc fica acoplado ao AS (mas tem disponível os serviços dele), de outra vc fica acopladoao web server. Das duas maneiras vc fica acoplado. Se não quiser acoplamento, reinvente as roda e construa tudo do início.
[quote=Giuliano Mega]Olás!
Serializa o Invocation? Esse invoker HTTP é só para Java-Java? :-P[/quote]
Yeap.
[quote] Luca wrote:
Esse problema de interoperabilidade entre protocolos de nível de aplicação é mesmo um saco. Eu não acho que um invoker do JBoss possa resolver isso de forma satisfatória, nem usando CORBA do lado .NET (aliás, nem sei se existe um ORB para .NET).
Com relação ao HTTP prover desacoplamento, eu concordo na questão do protocolo, mas daí começam a surgir as questões relacionadas a quanto do middleware subjacente você expõe no seu serviço. Dependendo do que você faz, o acoplamento só muda de nível. :-)[/quote]
Fazendo um web service contract-first, escrevendo o schema e a wsdl com cuidado antes mapear para uma linguagem de programação, dá para conseguir um desacoplamento bastante bom. É claro que se, em cima disso, você jogar uma meia dúzia de padrões WS-DeathStar que só tem duas implementações no mercado fica difícil mudar de plataforma…
Certo, seria uma alternativa. Mas se as mensagens que chegam ao servlet engine no servidor fossem somente HTTP sem RPC ou EJB/RMI, bastaria a aplicação .NET enviar um GET ou POST para receber uma mensagem resposta. Este foi o contexto da minha afirmação em termos de menor acoplamento entre o lado cliente e o lado servidor quando não se usa EJBs no cliente.
Tenho estudado bastante esta questão de tentar o menor acoplamento possível. Sinto que não é coisa fácil de obter neste mundo onde muita gente só pensa em RPC. Com o agravante de que aqueles que pretendem usar doc/literal esbarram no modo exclusivo como cada framework ou partner usa ou extende o schema “padrão” do W3C.
O sonho de integração das aplicações ainda tem muitas barreiras fora do nosso controle. Minha opinião neste momento atual, é que a gente deve fazer a nossa parte criando aplicações com o menor acoplamento possível e este modo de pensar praticamente bane o uso de RMI e consequentemente EJBs, no lado cliente.
[quote=Giuliano Mega]Olás!
Serializa o Invocation? Esse invoker HTTP é só para Java-Java? :-P[/quote]
Yeap.
[/quote]
Hum… então de fato ele não acrescenta muito no quesito “.NET falando com EJB” (he he he, exemplo de como usar HTTP e continuar completamente acoplado).
[quote=AllMighty]
Fazendo um web service contract-first, escrevendo o schema e a wsdl com cuidado antes mapear para uma linguagem de programação, dá para conseguir um desacoplamento bastante bom. É claro que se, em cima disso, você jogar uma meia dúzia de padrões WS-DeathStar que só tem duas implementações no mercado fica difícil mudar de plataforma…[/quote]
Bem, minha experiência com Web Services é limitadíssima, mas eu acredito em você. Meu comentário, meio genérico (e compatível com a minha experiência), é que o protocolo é uma parte importante mas, de longe, não é a única parte.
Gostei do WS-DeathStar.
Deixando o medo de falar abobrinha de lado por um instante…
Concordo, mas tem que tomar cuidado com o que vai nesse GET/POST. Usar GET/POST com REST é uma coisa, usar GET/POST para passar um byte blob com um Invocation serializado (disfarçando uma RPC) é outra coisa. Aliás… isso me traz uma pergunta à cabeça. Até a década de 70, não existia TCP/IP - as máquinas conversavam via protocolos proprietários e não era possível ligar dois fabricantes numa rede só. Depois da adoção do protocolo na ARPANET, em 83, as coisas mudaram - de repente todo mundo conseguia conversar - a tão sonhada interoperabilidade. Hoje em dia, tudo mundo fala TCP/IP, mas nós dizemos que as aplicações não interoperam (o problema foi empurrado para o nível de cima).
Eu tenho a impressão que o HTTP, considerado em isolado, é bem dizer o mesmo caso - você tem que considerá-lo no contexto do estilo REST, por exemplo, para tentar obter algum benefício real. O que vocês acham?
(eu também não tenho lá muita experiência prática com Web Services…)
Eu acho que interoperabilidade entre aplicações é um problema essencial, usando a terminologia do Brooks. Aceitando essa premissa, uma consequência é que o impacto de novas tecnologias nunca será grande o suficiente para eliminar o problema (nem sequer diminuir sua complexidade em ordens de magnitude). O máximo que as tecnologias podem fazer é alterar o espectro das dificuldades acidentais (ainda seguindo Brooks). Por exemplo, os padrões para RPC ou objetos distribuídos eliminam a dificuldade acidental de projetar o wire protocol, mas a interface que a sua aplicação expõe ainda precisa ser especificada (e os sistemas de objetos distribuídos que eu conheço ainda introduzem uma porção de dificuldades acidentais a mais).
Um aspecto interessante do REST é que ele divide o problema da interoperabilidade em três partes: Substantivos, Verbos e Content-types. A partir daí cada parte pode ser “solucionada” em separado. Na arquitetura da web, os Substantivos são as URLs - que tem propriedades interessantes - e os verbos são limitados aos que o HTTP oferece (GET, PUT, POST, DELETE, HEAD). Já o content-type é específico por aplicação, mas com espaço para adoção de grandes padrões internacionais (como HTML e Atom). Essa separation of concerns é o que permite, por exemplo, os caching proxies (responsáveis pela escalabilidade da web - imagine se a AOL não fizesse caching) e os crawlers genéricos dos mecanismos de busca.
O Roy Fielding fala do REST como o padrão arquitetural que descreve o funcionamento da web, então pode-se argumentar que não devemos considerar o HTTP isolado do REST.
E eu acho que o invoker HTTP do JBoss só serve para furar firewall mesmo.
<setMode Desabafo On>
As aplicações interoperam por TCP/IP. Se pode usar sockets ou alguma API que use sockets por debaixo dos panos mas que agregue outras coisas mais como ó o caso dos servlets, de RMI/EJBs e dos web services.
O tempo da moleza no desenvolvimento de sistemas já acabou no século passado. Antigamente a gente desenvolvia só para redes locais e a única preocupação era na carga do sistema, verificar se ficou alguma transação pendente para fazer rollback porque a máquina podia ter travado. O protocolo 2PC era usado apenas dentro de aplicações da mesma empresa.
Eu vivo insistindo aqui que este tempo já acabou. Os desafios agora são outros. O mundo é desconectado e deve ficar assim. O desenvolvedor precisa usar a infra-estrutura de rede Internet e não de LAN. Os conceitos de transações precisam dar suporte a uma arquiterura baseada em serviços distribuidas sei lá por onde e rodando em máquinas multi processadas.
Java nos permite deixar fluir nossa imaginação e fazer com ENORME facilidade aplicações completamente diferente do que faziam os Clipeiros ou VBzeiros no milênio passado. Usar Java apenas para substituir Clipper ou VB é perder todo um mundo de oportunidades sem ganhar quase nada.
<setMode Desabafo OFF>
Putz, valeu pela referência, Rafael. Eu não conhecia esse artigo (eu sei, é vergonhoso, pelo que eu entendi ele é uma espécie de clássico), mas achei muito legal. Com certeza ele vai para a bibliografia da minha tese.
É exatamente a isso que eu estava me referindo. O problema é que vejo muitas pessoas (não estou falando de você, Luca) falando sobre o uso do HTTP como um “protocolo de transporte em nível de aplicação” (pura e simplesmente), como se isso fosse resolver alguma coisa.
[quote]
E eu acho que o invoker HTTP do JBoss só serve para furar firewall mesmo.[/quote]
Isso é muito, muito engraçado prá mim. Digo, prá que que existem firewalls então? Prá você ficar furando? Daqui a pouco vão inventar um firewall para tráfego que passa pela porta 80 - porque tudo vai ser multiplexado pela porta 80 - daí depois vai vir um fulano dizendo “firewalls de porta 80 são um problema, nós inventamos esta tecnologia convoluta e complexa que resolve esse problema”. Quando, na verdade, a questão é mais fundamental e mais ampla - diz respeito a como definir políticas de segurança eficazes, diz respeito a como equilibrar o tradeoff entre segurança e inconveniência, entre outras coisas. É o negócio das dificuldades fundamentais e acidentais, como muito bem falou o Brooks.
Isso sem contar todos os outros novos problemas acidentais (alguns óbvios, outros nem tanto) que podem ser criados pelo uso indiscriminado do HTTP. Daí toca ler artigos e white papers que resolvem esses novos problemas.
Enquanto isso, nós ficamos patinando no mesmo lugar.
Se não falha a memória, você pode chamar qualquer MBean no JBoss via HTTP, não só o container EJB.
Mas isso não resolve o que nós estamos discutindo. Aliás, de acordo com Brooks (e eu concordo), esse problema não tem solução, ao menos não com os paradigmas atuais.
Divagando mais um pouco, isso me lembrou das interfaces baseadas em reconhecimento de padrões que o Jaron Lanier comentou num key note da OOPSLA’04. Segundo o que ele diz, nós não vamos conseguir domar softwares complexos enquanto continuarmos especificando protocolos num nível de granulosidade tão fino.
Ele fazia uma comparação entre o poder expressivo de uma imagem e o de um texto (o popular “uma imagem vale por mil palavras”), dizendo que a comunicação por protocolos é mais semelhante à leitura de um texto ou uma conversa entre duas pessoas (é ineficiente). Foi engraçado porque ele disse que nós usamos boquinhas virtuais para comunicação entre sistemas de software (mensagens, seriais, uma atrás da outra). Faz muito sentido, mas é bizarro pensar em especificar padrões como interfaces entre componentes - até porque a natureza do reconhecimento de padrões é intuitivamente mais imprecisa. Bem, talvez seja essa a mágica da coisa.
Ainda não lí os textos do Jaron Lanier, mas vou comentar sem embasamento algum a minha opinião sobre essa área :). Faz tempo que eu ouço falar em sistemas de software com inspiração biológica, orgânicos, adaptativos, autônomos, etc. Acho que deu para perceber que sou meio cético…
Um motivo para meu ceticismo é que, embora os organismos vivos pareçam capaz de coisas fantásticas (tipo ficar escrevendo bobagem no GUJ), a evolução não é direcionada. É só um punhado de genes se replicando e propagando mutações que contribuem localmente para a replicação. Já um sistema de software em geral tem um objetivo muito mais claro (nem que seja “fazer empresa grande ganhar mais dinheiro”).
Uma viagem que me ocorreu agora é que o papel dos programadores (humanos) pode ser encarado como se fôssemos análogos às enzimas ou proteinas. Huh? Tipo, numa célula de organismo existe um maquinário molecular “determinístico” (que faz a duplicação do DNA, a cópia para RNA, etc.) e a complexidade e autonomia do organismo surge a partir desse maquinário básico. Se em vez de pensarmos em uma aplicação como análoga ao organismo e o código fonte como análogo a esse mecanismo molecular, nós pensarmos nos programadores/operadores fazendo o papel dessa estrutura básica e nos grandes sistemas de-facto como um organismo talvez a analogia seja adequada. Um administrador de sistemas hackeando um script perl para fazer uma importação de dados ou um usuário de planilha eletrônica copiando o resultado de uns cálculos para o ERP “oficial” seriam exemplos de humanos agindo como enzimas dentro de algo como um organismo…
Será que deu para entender alguma coisa? (Ainda bem que eu não uso drogas :D).
