Arquitetura ideal para migração de sistema Desktop

Olá

Troca o servidor RMI por um servlet engine que geralmente tem melhor performance. Crie um servlet para receber as comunicações entre o cliente e o servidor usando URLConnection (com ajuda de HttpClient). Normalmente o servlet engine não precisa parar quando você instala um novo jar desde que você o empacote como war.

O FTP você deve fazer para um outro diretório diferente. Ao fim dele, você simplesmente executa um script que move o novo arquivo .war recem transferido para o diretório da aplicação (webapps se o servlet engine for o tomcat). Cada novo arquivo .war deve ter nome diferente do anterior mas o jar precisa ser com o mesmo nome.

Como são apenas 10 clientes, acho que pode continuar usando Java Web Start que tem o grave inconveniente de atualizar todos os clientes juntos se eles abrem na mesma hora.

Sugestão: mantenha sempre no servidor as versões antigas porque se der caca em uma atualização você tem condições de voltar a anterior rapidamente.

[]s
Luca

Pois é, a gente faz esse tipo de coisa tudo via Ant, é automatizado, o inconveniente é essa parada mesmo. O Jar tem algo em torno de 3 megas, e a atualização é demorada pacas pros usuários que não estão na filial onde está o servidor.

Seria legal usar um JBoss nesse caso? Nunca trabalhei com EE que não seja Web, é interessante ou pro tamanho da coisa é matar uma mosca com bala de canhão?

Pensamos também em Webservice no lugar dos RMI’s…

O fato é que estas “funcionalidades” na verdade são a migração de um sistema atual para Java, e como são coisas similares, vamos juntar os dois, que já era um projeto antigo.

Porém, gostaríamos de atualizar em separado estes dois sistemas (que agora serão um) para que não afete o negócio de nenhuma das partes, ou, fazer uma atualização que não pare nada!

Olá

Para porque é RMI, se fosse servlet não precisaria.

Neste caso o assunto é outro. Já não está mais falando do servidor RMI. Aqui a solução é criar uma sistema seletivo de dowload só das classes alteradas e fazer um ClassLoader customizado no cliente para reconhecê-las e carregá-las na memória. É factível, já participei de um projeto de um sistema assim.

Para que? Só para servir servlets? É claro que não. O JBoss usa o tomcat ou o Jetty para servir servlets.

Você poderia pensar em usar o Apache XML-RPC para enviar as mensagens para o servlet. Mas aí você teria que alterar todas as atuais mensagens do sistema. Melhor deixar web services de lado. Quando muito, se for mudar as mensagens e quiser enviar classes serializadas para o servlet engine, use o XStream.

[]s
Luca

Luca, eu noto que você sempre recomenda Servlets + HttpClient em vez de RMI, Session Beans e etc.

Será que com o EJB 3 não ficaria mais simples usar Session Beans do que usar Servlets + HttpClient e criar um protocolo? Qual a sua opinião?
Servlets + HttpClient não vai te obrigar a criar um protocolo, acrescentando uma complexidade a mais?

Olá

Acho que ainda vai demorar para que eu recomende alguma coisa no cliente que não seja baseado em HTTP passando pela porta 80.

Pelo que conheço de redes e de administradores de redes, não vejo outra alternativa. E já vi gente reclamando de HTTP mas nunca me inclui entre eles porque, bem ou mal, foi o HTTP que propiciou todo este mundo conectado que temos hoje.

Mesmo que você passe o RMI por um tunel HTTP eu não gosto de usar EJBs no cliente. A minha visão de cliente é que ele precisa ser o mais desacoplado possível do servidor e eu vejo o uso de EJBs no cliente como a criação de um vínculo.

Mas sei de gente que usa EJBs no cliente com muito sucesso. Só não sei se eles continuarão felizes se um dia sua arquitetura mudar para SOA e outros clientes precisarem acessar seus serviços.

Quanto a criação de protocolo, se você quiser algo padronizado e mais simples do que SOAP, use o Apache XML-PRC (com servlet). Ou então o próprio SOAP que também não é assim tão difícil.

[]s
Luca

O Java WebStart - na verdade o JNLP, especificado pela JSR-51 - jah possui um esquema de versionamento que permite a distribuicao automatica apenas da “diferenca” das versoes, com um protocolo conhecido como jardiff. Jah pus em producao e funciona muito bem, exceto em algumas versoes mais antigas do JDK 1.4.2, em que existe um bug na escrita do jar que forca o usuario a, ocasionalmente, ter que tentar acessar a aplicacao mais de uma vez ateh ser bem sucedido (num caso pessimista, no maximo n + 1 vezes, sendo n o numero total de jars da aplicacao; no caso em questao, o pior que vi foi n / 5).

RaulCarlin:

Seria legal usar um JBoss nesse caso? Nunca trabalhei com EE que não seja Web, é interessante ou pro tamanho da coisa é matar uma mosca com bala de canhão?

Pensamos também em Webservice no lugar dos RMI’s…

Pra resolver o problema da comunicacao remota, recomendo que voce continue utilizando um protocolo binario e compacto, ateh porque voce disse que hah problemas de download. RMI “cru” eh um tanto pesado no servidor a menos que voce faca um esforco grande de programacao para compensar isso.

O ideal eh ter uma tecnologia no servidor que permita implementar servicos e gerencia-los. Utilizar EJB eh uma opcao, mas nao a unica saida. Em casos como esse, desacople a tecnologia utilizada para interligar cliente e servidor, colocando-a numa camada invisivel da aplicacao, utilizando dynamic proxies em cima de interfaces ou AOP em cima de POJOs.

Uma implementacao desse conceito eh a remotabilidade transparente do genesis, que permite que a integracao seja feita conforme necessario.

Acho que vão. O uso de uma Arquitetura Orientada a Serviços (SOA) pressupõe a coexistência entre quaisquer protocolos/plataformas/linguagens no parque de software de uma organização.

Olá

Bem lembrado, eu tive problemas com jardiff usando Java 1.4.1.

Mas mesmo que o jardiff funcionasse 100%, ele não evitaria todos os downloads ao mesmo tempo que era meu principal problema no servidor já que todas as lojas abriam na mesma hora. Daí a necessidade de um esquema especial. Aliás, no livro do Mauro Marinilli sobre JNLP de 2002, ele já reclamava da falta da possibilidade de download seletivo no JNLP.

mister__m:

Em casos como esse, desacople a tecnologia utilizada para interligar cliente e servidor, colocando-a numa camada invisivel da aplicacao, utilizando dynamic proxies em cima de interfaces ou AOP em cima de POJOs.

Uma implementacao desse conceito eh a remotabilidade transparente do genesis, que permite que a integracao seja feita conforme necessario.

Não acho que a solução do genesis web signifique o desacoplamento ideal PORÉM acho que significa um enorme avanço sobre o uso de RMI. Realmente uma mão na roda para projetos deste tipo. E com a vantagem de deixar o trabalho de baixo nível de rede para o JBoss.

Acho que eu preciso um dia brincar com a trinca JMeter + GlassBox + Wireshark em cima de uma aplicação com o genesis para ganhar confiança mas ele me impressiona muito bem.

[]s
Luca

Olá

Não entendi bem onde você discordou de mim e por isto tentarei me explicar melhor.

Em princípio não gosto de EJBs no cliente por 2 motivos:

1. Complica o desenvolvimento e necessita de codificador mais experiente
2. Necessita de servidor que entenda um protocolo de EJBs que são estranhos para outras aplicações não baseadas em EJBs

Para resolver o problema 1. se pode adotar soluções como o genesis web que se encaixa com perfeição e deve dar um ganho enorme de produtividade ao desenvolvimento.

Fazendo um parêntesis, SOA significa arquitetura baseada em serviços, não exatamente baseada em web services e nem propriamente aberto na Internet.

Em termos de arquitetura, sempre objetivo o menor acoplamento possível. Sabendo que há possibilidades de se adotar soluções menos acopladas do que com EJBs, em igualdade de condições, eu priorizo uma solução sem EJBs que possa ser acessada por outros clientes (clientes não humanos).

[]s
Luca

Luca, eu nao entendi exatamente como isso era um problema pra voce. O servidor ficava em pico de processamento? A rede “entupia”? As lojas mais importantes nao conseguiam fazer download?

Apenas para deixar mais claro, o que considero ideal eh esconder completamente como a comunicacao com o servidor eh feita; isso deve ir pra “debaixo dos panos”. Desenvolvedores de codigo de negocio nao devem ser expostos aos detalhes de implementacao de EJB, RMI, SOAP, Webservices para desenvolver suas aplicacoes.

Olá

A aplicação travava nas agências e lojas porque o servidor não tinha largura de banda para o download de todos ao mesmo tempo. Porém o pior problema era que o usuário perdia a paciência com a longa espera e rebootava a máquina achando que resolveria. O servidor na verdade fazia muito mais downloads do que o necessário. Isto acontecia no Banco Postal na época em que o servidor tinha 8Gb de banda que era insuficiente para dar conta de bem mais de 10 mil agências. Na época a gente ainda não usava o jardiff que só fui usar em uma outra aplicação de captura de cartão de crédito também com muitos clientes Java Web Start.

Mas se o cliente tivesse aprovado o projeto, poderia ter sido criado um banquinho de dados no servidor para liberar os downloads de acordo com um escalonamento desde que o motivo da atualização não seja um erro gravíssimo.

Perfeito, só por isto o genesis já tem seu valor. E o bom dele é que faz mais coisas.

[]s
Luca

mister__m

Você já utilizou genesis? O que ele quer dizer com a restrição “Não pode ser estático nem manipular membros estáticos”? O fato de não permitir um método estático tranquilo, mas o que ele considera uma manipulação? Acesso ou alteração?

Se não puder acessar membros estáticos dentro do @Remotable então está fora de cogitação, mesmo tendo me interessado logo de cara pela sua facilidade… o meu projeto tá completamente OO, cheio de interfaces e uma porrada de variáveis estáticas que servem pra um zilhão de coisas, se não puder utilizá-las no servidor vai ser em vão, não vou entupir o meu cliente de processamento sendo que temos um servidor muito parrudo pra isso…

Por enquanto estou trabalhando na idéia do Luca, utilizando HTTP com um Servlet brincando de RMI e fazendo persistência com Hibernate (outra novidade que entrou no projeto)…

Valeu pela atenção!

Olá

Ele é o criador do genesis

Se tem muitas variáveis estáticas então dificilmente será considerado como completamente OO.

O genesis justamente resolve parte dos problemas de quem usa RMI. A menos que você abandone o uso de RMI, no seu caso valeria a pena dar uma olhada no genesis.

A minha sugestão seria totalmente sem RMI.

[]s
Luca

RaulCarlin:

mister__m

Você já utilizou genesis?

Criei

Veja esse snippet da documentacao:

Basicamente, o problema eh que os valores estaticos nao serao sincronizados com o servidor, gerando uma serie de efeitos indesejados. No seu caso, nao haverah problema algum, pois sua arquitetura jah implica que nao hah sincronia entre os membros estaticos de qualquer forma. Porem, uma observacao…

Se seu codigo tem uma “porrada” de variaveis estaticas, seu projeto nao estah completamente OO. Um design OO limpo gera poucos - as vezes, nenhum -membros estaticos. Revise o modelo das suas classes nesse respeito, independente da solucao final que adotar.

Luca,

Estendendo a estrutura ortogonal baseada em AOP existente no genesis, eh possivel usar qualquer outro metodo de invocacao do servidor. O genesis possui, out-of-the-box, tres modelos de execucao dos componentes de negocio: local, remoto com EJB e local com EJB. Basta estender um aspecto base, configura-lo no aop.xml e mudar o funcionamento do aplicativo. A documentacao dos aspectos fala mais sobre isso.

Olá

Sou conhecido aqui no GUJ como o homem que não acredita em sistemas confinados na rede local. Só a opção remoto com EJB me despertou o interesse. Mesmo assim com a restrição de que EJBs criam vínculos entre cliente, servidor e EJB engine (que depende do vendor).

Se um dia aparecer um louco na equipe do genesis que crie mais opções remotas usando XML-RPC, SOAP e REST, me interessarei mais ainda.

[]s
Luca

Luca:

Se um dia aparecer um louco na equipe do genesis que crie mais opções remotas usando XML-RPC, SOAP e REST, me interessarei mais ainda.

Esta nos planos para a versao 4. Assim que terminarmos a versao 3.0, pretendo atualizar o roadmap.

Explicando a “porrada”:

Temos um determinado documento (não vou entrar em detalhes). Este documento pode ser de 3 tipos distintos e, além disto, possui dois estados. Para melhorar a codificação, existe (exemplo) uma variável Document.OK, Document.NOT_OK, que auxilia à puxar estes dados do BD.

Dentro deste documento existem, no mínimo, 100 objetos que (exemplo novamente) possuem uma série de características e são os principais do sistema. Cada um destes objetos possuí outros objetos (existe até um objeto que só armazena uma String, mas que a sua validação é essencial) e por aí vaí. Para identificar os tipos de toda essa bagunça usamos essa “porrada” de variáveis. Existem pouqíssimas classes abstratas no projeto, e as que existem nem são persistidas. Eu, pelo menos, acho muito mais simples chegar à alguma conclusão tendo um Document.OK, DocumentLine.EMPTY e por aí vai… acho mais claro… mas por favor me contestem…

Tá meio bagunçado e difícil de voltar atrás, nem sou o pai exatamente da coisa, mas se vocês pudessem ver até achariam que não foi uma má idéia tendo em vista a complexidade da coisa.

Desculpe não ter nem pensado em ver o Project Team… :oops:

Mister_m, quais empecílios teria em utilizar o Genesis nesta minha situação? Pelo que você disse, nenhum, certo?

Só complementando, são todas variáveis final, NUNCA irei alterar…

Acho que isso que vocês deviam estar pensando né… NUNCA ocorrerá de meu servidor e meu objeto serializado no cliente tratarem valores diferentes, serão sempre os mesmo…

Voce estah falando de constantes ou enums? Em qualquer um dos casos, nao hah restricoes por parte do genesis. Agora, se estiver trabalhando com variaveis estaticas quando deveria usar enums, seria melhor usar enums mesmo, que sao fortemente tipadas.

RaulCarlin:

Só complementando, são todas variáveis final, NUNCA irei alterar…

Acho que isso que vocês deviam estar pensando né… NUNCA ocorrerá de meu servidor e meu objeto serializado no cliente tratarem valores diferentes, serão sempre os mesmo…

Hmm, sao constantes entao. A pergunta eh: deveriam ser enums?

Poderiam…

Luca:

Olá

Não entendi bem onde você discordou de mim e por isto tentarei me explicar melhor.

Releia os posts e entenderá. Vc criticou alguma coisa usando alguma argumentação. Eu invalidei sua argumentação.

Propaganda?!? Pensei que vc estava falando de uma solução com HTTP/servlets.

Sim, isso eu sei. O que tem a ver com a discussão!?

O que te faz acreditar que uma solução com HTTP\servlets é menos acoplada!? A que tipos de acoplamento vc se refere!? Pense bem para responder.

[]s

Olá

Taz, continuo sem entender sua contestação e seus posts não a explicam. Por exemplo: como uma aplicação .NET acessa um EJB engine?

Soluções usando servlets são MUITO mais desacopladas do que soluções usando EJBs, principalmente porque se pode trocar com facilidade o servidor de aplicação. Exemplo: o Banco Postal foi desenvolvido sobre o Tomcat e na produção foi para o WAS com facilidade sem alterar uma única linha no jar. Em demos fizemos ele rodar igualmente fácil no JBoss e no jetty também sem alterar uma linha. As chances de isso acontecer quando se usa EJBs no cliente são mínimas.

A lembrança de SOA x Web Services foi por questões de completitude do meu post e para evitar que outro alguém o fizesse.

E sobre propaganda, é mais uma observação que não entendi. Apenas citei um framework Open Source que pode ser adequado neste caso.

<editado>
[color=darkred] Sobre este seu pense bem para responder, solicito que me trate com o mesmo respeito que eu lhe trato.
Obrigado[/color]
</editado>

[]s
Luca

Olá…

Reiniciando a discussão inicial: vi vários (vários mesmo) posts ordenando repetidamente e expressamente: “mantenham o banco fora da rede”, “faça um servlet”, “faça um webservice”. Mas nunca o porquê.

É realmente tão perigoso assim manter um banco de dados online?

Mesmo configurando senhas e permissões corretamente, lidando com um número limitado e baixo de clientes e estabelecendo uma conexão remota sobre SSL com o BD, enviar a camada de acesso a dados (eg: hibernate/DAOs) via java web start junto com a camada de visualização/controle continua sendo uma solução tão porca assim?

Olá

O banco pode estar em qualquer lugar. No desenvolvimento ou nas demos ele pode ficar na mesma máquina. Em produção pode ficar na rede local ou em um data center externo.

É bem fácil mudar o banco de lugar caso a aplicação seja escrita com esta separação. Com servlets se consegue isto.

Já quem escreve código no lado da camada de apresentação que acessa ao banco de dados fica eternamnte confinado na rede local. Se amanhã aparecer um outro cliente para a aplicação que tenha filiais, ele presisará ser reescrita. Melhor fazer da primeira vez já separando as responsabilidades.

[]s
Luca

Certo, mas por que precisará ser reescrita para funcionar via internet? É isso que não entendo… ao meu ver, seja via internet ou via rede local, fazendo uma conexão remota sobre SSL ao DB… qual o problema?

(sim, eu sei da limitação no número de acessos simultâneos… mas tem algo além disso?)

Olá

Experimente. Verifique a performance. Compare os protocolos de rede. Para sentir melhor o drama, adquira um Oracle com 5 licenças.

E procure ler sobre as vantagens de se ter o acoplamento mais fraco possível.

[]s
Luca

Olá…

Bom, primeiramente, obrigado pela paciência em responder.

Eu entendo as vantagens de um baixo acoplamento… mas veja, se a aplicação usa hibernate, já esta independente de BD. Só não estou conseguindo é ver um motivo forte o bastante para justificar a adição de mais uma camada na aplicação (os servlets no servidor, URLConnection no cliente), se o driver do banco de dados resolveria isto [buscar os dados através da internet ou rede local].

Desculpe, mas estou meio sem tempo pra poder testar… é possível me dar alguma idéia de como seria a diferença de performance ao usar conexão remota ao BD, sobres SSL, ou usar servlets conectados localmente? De fato, não faço a menor idéia… nem conheço o protocolo que o driver usaria.

Denovo, obrigado pela paciência hehe.
(obs: não entendi o comentário sobre as licenças Oracle)

Olá

bzanchet, repare que eu não falei em independência de BD.

Leia o livro de patterns para integração de sistemas do Gregor Hohpe. No próprio site dele há bastante material. E ele já escreve sobre isto há bastante tempo.

[]s
Luca

Luca:

Em princípio não gosto de EJBs no cliente por 2 motivos:

1. Complica o desenvolvimento e necessita de codificador mais experiente
2. Necessita de servidor que entenda um protocolo de EJBs que são estranhos para outras aplicações não baseadas em EJBs

[]s
Luca

Se não me engano, o JBoss tem um invoker para SOAP ou Corba… mas… alguém ja utilizou?

Olá

E para que serviria um invoker do JBoss para SOAP ou CORBA?

Não sei bem o que eu poderia fazer com um invoker do JBoss, mas acho que SOAP e CORBA são muito diferentes para que o JBoss tenha algo SOAP ou CORBA.

[]s
Luca

Eu tou pra ver uma aplicação feita em Hibernate que não precise em algum momento de algum comando SQL nativo do banco, mandando a independência do BD pro lixo.

Hoje em dia, eu não uso nem mais esse argumento pra falar sobre Hibernate (independência de BD), falo somente das vantagens de trabalhar com objetos etc. Independência de banco de dados seria lindo, mas não se consegue - principalmente quando o banco já ti fornece modos bem mais fáceis de fazer algumas coisas.

Preste atenção, sua pergunta já foi respondida. Eu disse “O uso de uma Arquitetura Orientada a Serviços (SOA) pressupõe a coexistência entre quaisquer protocolos/plataformas/linguagens no parque de software de uma organização.” Além disso, sua pergunta foge do assunto. Não foi esse o problema apresentado. Não invente requisitos.

Se vc usa servlets, continua acoplado a um servidor Web. Qual a diferença!?

Onde há desrespeito!? Não fique bravo. Apenas propus uma reflexão.

Olá

Pois foi foi exatamente o que eu escrevi. Está la: " Mas sei de gente que usa EJBs no cliente com muito sucesso. Só não sei se eles continuarão felizes se um dia sua arquitetura mudar para SOA e outros clientes precisarem acessar seus serviços. "

E se você respondeu que vão deve saber como um cliente .NET pode acessar um EJB engine.

De novo foi grosseiro. Não me considero capaz de responder no mesmo nível.

[]s
Luca

E essa!? Não responde também!?

Olá

Taz:

E essa!? Não responde também!?

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

Luca:

E para que serviria um invoker do JBoss para SOAP ou CORBA?

Não sei bem o que eu poderia fazer com um invoker do JBoss, mas acho que SOAP e CORBA são muito diferentes para que o JBoss tenha algo SOAP ou CORBA

O JBoss vem com invokers CORBA (baseado no mapeamento padronizado Java-IDL), JRMP e Http. Este último simplesmente serizaliza o objeto Invocation (que carrega as informações do método a ser chamado) dentro de um POST.

Também tem o projeto JBoss remoting, que eu não conheço.

Olá

Obrigado Rafael, eu não tinha idéia sobre o que era isto. Já tinha ouvido falar nos invokers do Spring (acho que em uma palestra do Urubatan) mas também nunca usei.

Como estou envolvido com web services e integração de aplicações, acho que teria obrigação de saber um pouco sobre isto. Vai para a lista. :oops:

[]s
Luca

Luca:

Olá

Taz:

E essa!? Não responde também!?

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

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!?

Olás!

AllMighty wrote:

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.

Abraços,

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.

microfilo:

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!?

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.

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.

Oi Giuliano

Giuliano Mega:

Olás!
Serializa o Invocation? Esse invoker HTTP é só para Java-Java? :-P

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. :-)

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…

Olá

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.

[]s
Luca

Oi Rafael,

AllMighty:

Oi Giuliano

Giuliano Mega:

Olás!
Serializa o Invocation? Esse invoker HTTP é só para Java-Java? :-P

Yeap.

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).

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…

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?

Abraços,

Giuliano

(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.

Olá

<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>

[]s
Luca

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.

E eu acho que o invoker HTTP do JBoss só serve para furar firewall mesmo.

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.

Abraços,

Dá para chamar um Session EJB3 via http.
Dá uma olhada neste link.

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71331&view=next

Oi,

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.

Enfim, tô falando meio nas coxas. Interessados podem olhar em http://www.jaronlanier.com/topicsindevelopment.html (há muito mais coisas interessantíssimas lá). Estou sempre disponível para discutí-las.

Abraços,

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).