[quote=fabiofalci]Sim, java-to-java.
Mas tem a opção de Hessian and/or Burlap
Mas esses nunca usei[/quote]
No caso do Hessian/Burlap eles utilizam-se do protocolo HTTP e o Webservice do SOAP mas ambos não deixam de ser XML’s transitando com informações.
Como webservice está bem mais difundido, recomendo neste caso utilizar ele. O Burlap é utilizado mais em aplicações móveis (J2ME).
[quote=Quinger][quote=sergiotaborda]
O que vc quer é uma aplicação desktop sometimes-connected. Esta aplicação não é em tempo real como uma aplicação cliente-servidor (always-connected) (…)
[/quote]
Concordaria com vc se fosse desenvolver o sistema a partir do zero!
Mas o fato é que já existem as aplicações em diferentes plataformas, que devem ser integradas…[/quote]
Desenvolver acho que significa “do zero”. Pelo menos a parte desktop já que o actual está em VB.
Mesmo que reutilize a parte web , para o objetivo do mlecar é otimizar a homologação , ela tem que ser , no minimo, reformatada. Mesmo que utilize JEE concerteza o atual não tem mecanismo de sincronismo.
Mesmo que use wbeservices e a aplicação seja online, tem que haver altrações por causa do objetivo da homologação.
Não conheço a dimensão do projeto. Em casos de partir do zero, ou seja, refazer, as vezes pode ser um processo que dure 1 ou 2 anos.
Aqui na empresa em que trabalho tem vários sistemas legados em Natural com ADABAS, onde apenas foram mapeados através de um middleware e mudaram a cara(interface) do sistema. Se optassemos por refazer o negócio, estariamos até hj implementando…
Mas caso seja uma aplicação simples, já toca o barco tudo pra Java e elimina VB. hehehe
Google Gears + Tibco GI no front-end. O Backend pode ser um conjunto de WebServices no estilo SOAP ou algo mais “leve” (XML-RPC, pex).
Será uma única aplicação e, idealmente, transparente para o usuário. Até mesmo a atualização da aplicação fica transparente usando o Gears.
Como já comentaram, a melhor opção no seu caso é criar serviços com a logica de negocio e disponibilizar para a aplicação desktop(VB). Com isso você retira toda a lógica do client e altera apenas no serviço quando necessário.
Resultado: Sua aplicação VB será apenas um frontend e poderá sincronizar os dados com o servidor quando conectado.
De qualquer maneira, você no fim vai transformar um problema(homologação de 2 apps) em um projeto complexo e sem ganho real para o negócio(pois até onde sei, aplicações vb conseguem se atualizar pela internet com um minimo de esforço).
A um tempo atrás pesquisei aqui no GUJ mesmo sobre isso e em um post do Luca fiquei sabendo que os Correios/Banco Postal utilizam um esquema via URLConnection para isso.
Você pode trabalhar on-line eqto estiver conectado e se perder conexão utiliza algo local como o JavaDB esperando por conexão para sincronizar os dados locais com o servidor.
E se ao invés de fazer uma aplicação desktop sometimes-connected, fizesse uma aplicação web normal, só que na máquina cliente, eu subiria um servidor de aplicação como o JBOSS e trabalharia offline mesmo, com um banco como o JavaDB, ou outro qualquer, e criasse um meio para que o cliente fizesse a sincronização da base de dados a qualquer hora?
Pensando dessa forma, eu evitaria criar uma camada de apresentação diferente, e a aplicação passa a ter diferença somente na camada de dados. Teríamos a mesma camada de apresentação e domínio tanto no cliente quanto na web.
Seria possível implementar algo assim sem problemas?
Olha, veja se iso é possivel para vc:
Faça uma aplicação toda web e de a possibilidade do usuario escolher: intranet ou internet; caso ele escolha intranet faça um robo para roda de tempos em tempos (via webserveces, lembrando que ele precisará se conectar), assim acredito eu que vc só precisará fazer um modulo de escolha para o usuario, trabalhei em uma empresa que fazia algo assim, todas as aplicações eram web porem com varios legados diferentes e uma delas nao era on-line sendo assim tinhamos um robo que fazia toda a varedura anoite para atualizar as bases do legado…
at.
Alguns problemas com esta abordagem(acreditem, eu já passei por isso):
utilização de recursos mesmo sendo embutidos(db, webserver) e uso de memória.
conflitos de portas com outras aplicações rodando e firewall.
segurança, pois você está abrindo um server na máquina do cliente(ele sabe disso?)
Se várias aplicações forem executadas com este conceito e não pensarem nos itens acima garanto uma confusão igual a época do visual basic, onde os conflitos de dll reinavam pois os desenvolvedores só pensavam neles mesmos.
[]'s