Criação de uma aplicação web que também rode no desktop

Vc pode criar toda uma aplicação baseada em web-services (REST por exemplo) com o core da aplicação, criar uma aplicação web para acessar esses web-services e um cliente Swing que faça o mesmo. No lugar de web-services pode ser qq coisa que dê pra invocar remotamente.

Vc pode ser mais radical e criar uma aplicação java hermafrodita que seja desktop mas, com um parametro especial vc inicie um servidor web embutido escrito em java também, que forneça uma interface web criada na unha. Ai vc tem uma aplicação só, mas acho q isso é um tanto complexo demais do que a primeira sugestão.

É verdade, a primeira opção seria mais viável, porém a segunda seria o ideal!

E quanto ao usar o Swing, não seria melhor usar o SWT? O Swing é meio complexo…

Obrigado!

Fazer tudo num único aplicativo seria tão complexo que o Swing é o menor dos seus problemas…

É verdade!

Vou pensar em fazer o webservice!

Valeu pelas idéias!

Obrigado!

Pq vc não usa só Web?

[Editado]Não vi a parte do OffLine[/Editado]

Só não vejo muito o funcionamento de uma aplicação que tenha uma base de dados funcionar off-line.
Vc vai jogar o banco de dados dentro da máquina cliente?

É pq alguns clientes não ficam conectados na internet direto e precisam acessar essas aplicações para depois nos mandar as informações.
Agora eu só fiquei na dúvida se caso eu fosse usar webservices, eu entendi que teria q colocar esse webservice na máquina cliente tb.

Alguém tem uma dica?

Acho que a melhor situação mesmo é vc disponibilizar serviços “webservices” da aplicação web, para utilizar na desktop.

E referente a deixar off-line para depois sincronizar.

Vc vai ter que salvar local e criar uma forma de sincronização que através de um controle do tipo “data ultima alteração” vc realiza a operação.

Entendi Quinger. Mas dá para disponibilizar o webservice no desktop na boa?

O google criou um framework chamado Google Gears. Alguém já usou?

mlecar:

É pq alguns clientes não ficam conectados na internet direto e precisam acessar essas aplicações para depois nos mandar as informações.
Agora eu só fiquei na dúvida se caso eu fosse usar webservices, eu entendi que teria q colocar esse webservice na máquina cliente tb.

Alguém tem uma dica?

Se vc for utilizar WebServices teria que estar on-line com o servidor.
Entre utilizar WebServices e a sua aplicação que já funciona via Web, fique com sua aplicação.
WebServices em aplicações Desktops com o intuito de fazer a “camada intermediária” se justifica quando vc não tem uma aplicação Web ou quer utilizar uma aplicação com uma interface mais rica. Mas é conectado do mesmo jeito.

Entendi Quinger. Mas dá para usar o webservice no desktop na boa?

Quinger:

Acho que a melhor situação mesmo é vc disponibilizar serviços “webservices” da aplicação web, para utilizar na desktop.

E referente a deixar off-line para depois sincronizar.

Vc vai ter que salvar local e criar uma forma de sincronização que através de um controle do tipo “data ultima alteração” vc realiza a operação.

IMHO, com a Internet cada vez mais acessível em qualquer lugar eu não ficaria perdendo tempo com aplicações off-line. Operadoras de celular já têm aqueles modens USB com velocidade “razoável” para o Brasil. Isto requer uma programação mais detalhista, o usuário não tem acesso à informação real, dá trabalho pra integrar e manter. Cada caso é um caso, mas talvez seja a hora de rever esta situação.

Entendi… mas de qq jeito infelizmente eu vou acabar precisando das duas aplicações. O que eu queria era usar o máximo da reutilização do código.

mlecar:

Pessoal, estou em uma equipe onde tenho que procurar desenvolver uma aplicação que rode tanto na web como no desktop.
(…) As duas aplicações fazem a mesma coisa, porém são códigos diferentes. A aplicação web é feita usando J2EE e a desktop é feita em VB.

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)
Se a sua aplicação desktop tem que funcionar offline esqueça webservices porque eles precisam de conectividade para funcionar. O que vc deve fazer é uma aplicação em camadas de forma que a unica coisa diferente seja a apresentação e a persistencia. Em web vc cria uma apresentação html, em desktop swing. Sim, swing. Não se meta com SWT que vai se dar mal. Swing não é complexo, é poderoso.
A camada de persistencia tb deve ser diferente. No desktop tlv precise usar uma banco embutido como o JavaDB.
A logica de negocio/dominio deve ser independente e funcionar nos dois contexto. Dessa forma a homologação será simples pois a logica é exactamente a mesma ( são as mesmas classes).
Depois, no desktop, precisa ter um modulo de sincronismo que detecta a ligação ao servidor e se sincroniza conforme. O servidor deve ter uma logica compativel com isto. Não faça sincronismo de banco, faça uma logica de sincronismo via java. Vc pode usar XML e HTTP para transferir os dados, mas isso não tornas as coisas webservices.

Eu uso aplicações desktop acessando aplicações web usando isso
http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html

Mais precisamente esse http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-httpinvoker

marciosantri:

IMHO, com a Internet cada vez mais acessível em qualquer lugar eu não ficaria perdendo tempo com aplicações off-line. Operadoras de celular já têm aqueles modens USB com velocidade “razoável” para o Brasil. Isto requer uma programação mais detalhista, o usuário não tem acesso à informação real, dá trabalho pra integrar e manter. Cada caso é um caso, mas talvez seja a hora de rever esta situação.

Concordo! mas teve casos aqui no lugar que trabalho, onde o operários iam fazer uma revizões periódicas em equipamentos que ficam metros abaixo, de toneladas de concretos, onde não tinha conexão! e a aplicação foi desenvolvida salvando dados locais em um coletor de dados, para mais tarde efetuar a sincronia com a base de dados original.

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)
Se a sua aplicação desktop tem que funcionar offline esqueça webservices porque eles precisam de conectividade para funcionar. O que vc deve fazer é uma aplicação em camadas de forma que a unica coisa diferente seja a apresentação e a persistencia. Em web vc cria uma apresentação html, em desktop swing. Sim, swing. Não se meta com SWT que vai se dar mal. Swing não é complexo, é poderoso.
A camada de persistencia tb deve ser diferente. No desktop tlv precise usar uma banco embutido como o JavaDB.
A logica de negocio/dominio deve ser independente e funcionar nos dois contexto. Dessa forma a homologação será simples pois a logica é exactamente a mesma ( são as mesmas classes).
Depois, no desktop, precisa ter um modulo de sincronismo que detecta a ligação ao servidor e se sincroniza conforme. O servidor deve ter uma logica compativel com isto. Não faça sincronismo de banco, faça uma logica de sincronismo via java. Vc pode usar XML e HTTP para transferir os dados, mas isso não tornas as coisas webservices.

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…

Então, depende da infraestrutura da empresa.

O servidor cuja aplicação web (j2ee) está rodando, está localizado dentro da empresa?

fabiofalci:

Eu uso aplicações desktop acessando aplicações web usando isso
http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html

Mais precisamente esse http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-httpinvoker

Ótimo! mas isso é uma solução de Java para Java certo?

Sim, java-to-java.
Mas tem a opção de Hessian and/or Burlap

Mas esses nunca usei

fabiofalci:

Sim, java-to-java.
Mas tem a opção de Hessian and/or Burlap

Mas esses nunca usei

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

Quinger:

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) (…)

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…

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