O dilema da escolha

Coisas a se considerar:

• é realmente necessário fazer a interface web? Não compensa o tempo de estudo para fazer a interface em Swing ou semelhantes? Mais robusto, confiável e bonito.
• quando começar a pensar em EJBs, tenha certeza que você precisa deles. Sua aplicação contém muita lógica de negócios? Ou é só um “front end para a database”? Os servidores são distribuídos? Ou fica tudo numa máquina só?

Minhas sugestões caso resolva seguir o caminho que indicou:

• Se tiver tempo para estudar, use WebWork.
• Use Jetty ao invés do Tomcat. Simplesmente melhor e mais rápido.
• Sobre Velocity eu uso, gosto e recomendo. Mas pelo que olhei por aí o FreeMaker parece uma opção mais cheirosa, mas não posso dizer muito, pois não usei ainda.
• Hibernate :thumbup:

Viche… o Filipe falou tudo!!!

Mas opinião pessoal:
Pela telinha que você mostrou, parece que swing é mais interessante!!! Daí vc pode usar o Java Web Start para iniciar a aplicação mesmo à partir de um brownser!!!

Se tiver se ser web, então meu conselho é vc usar Hibernate dependendo do tamanho da aplicação. Webwork e Struts caem bém (O pessoal aqui curte bastante webwork… e muitos não suportam e odeiam Struts… pense nas probres foquinhas…).

Se sua aplicação for distribuiída, pense um milhão de vezes antes de usar EJB! Provavelmente um container leve como Spring ou PicoContainer poderá ser mais que suficiente para resolver seus problemas!!!

Um Abraço!

Vocês tem mania de desvalorizar a interface web.
Dá para fazer interfaces web completamente confiáveis, bonitas, leves
e simples.

No caso de interface não é a escolha do framework que irá determinar
como ela ficará, mas o seu conhecimento em tecnologias client-side como
html, javascript,css,etc.

É lógico que os frameworks ajudam se possuem components server-side de view.
dê uma olhada no struts-layout, uma extensão pouco divulgada do struts que fornece components server-side para criar treeviews, listviews, grids e ainda ajuda na criação do layout, dispensando você do conhecimento das tecnologias cliente-side.
http://struts.application-servers.com/

Já interfaces web ficarem iguais a interfaces desktop e compátives a maioria dos browsers.

jprogrammer, não sei quanto a você, mas todos os projetos que me envolvi até o anterior ao atual optamos por interfaces web, com HTML ou XUL.
E neste último estamos desenvolvendo com Swing. Não tem como comparar. Nada de refreshs e redirects. Componentes que são objetos de verdade, e não tags <inputs>. E o melhor: sem protocolo http. Só por isso já é infinitamente superior na minha opinião.

Ninguém desvalorizou a interface web aqui!!!

Na verdade acontece o contrário… Todo mundo só que saber de fazer na WEB e esquece de recursos swing, que dependendo do caso, seria o ideal para satisfazer a necessidade de nosso amigo!

Um Abraço!

O que quero ressaltar que com a tecnologia client-side que temos hoje, não precisamos mais ficar dando refresh, redirects.
É lógico que vocês vão falar: mas é usando gambiarra.
Mas o que importa é para o usuário. O que ele vê.

Gosto do swing, mas temos que pensar que podemos ter máqunas com pouco poder de processamento como client.

O qual o problema do LIPE com o http ?

XMLHttpRequest não é gambiarra (pelo menos já é uma gambiarra oficial e documentada).

HTTP não foi feito para criar aplicativos, foi feito para compartilhar documentos em hypertext. Esse é o problema. Você notou que existem vários métodos não usados no HTTP? É por isso.

Aliás, um protocolo web novo e desenhado apra isso faria um bem grande.

Máquinas menos possantes para rodar a aplicação client???

Não… esse não é o principal problema…

O Swing não é o principal problema pelo mau desempenho das aplicações. É claro que swing não vai rodar em um 486… mas as maioras das máquinas que temos por ai roda swing …

Que adianta vc ter uma máquina rodando um cliente super rapidamente e a parte server ser super lerda??? Nem interface no modo texto deixia a aplicação mais rápida.

O que vai definir o sucesso do projeto não é apenas o que o cliente vê, e sim quanto ele terá que esperar para receber a resposta do sistema!!!

Mas a tecnologia server do java (JSP/Servlets) bem aplicada contribui para o bom desempenho da aplicação.

Não é por ser web que ficará lenta, mesmo tendo um processamento
centralizado.

Outra vantagem da interface web é portabilidade para máquinas
que não possuem JVM.
Já tive problemas no windows XP. Não era permitido instalar mais nada.
Cada cliente tem seu gosto.

jprogrammer:

Mas a tecnologia server do java (JSP/Servlets) bem aplicada contribui para o bom desempenho da aplicação.

Adendos:

• Nada impede o uso de HTTP/ Servlets e até JSP numa interface Swing ou outra qualquer do tipo

• Java possui uma vaaaaaaaaaaasta gama de tecnologias para servidores

[]s

Discordo completamente desta afirmação. Manter toneladas de código em JavaScript é uma desgraça, por mais cuidado que a equipe tenha ao desenvolver. Isso é amenizado com o Firefox e seu JavaScript debugger, mas ainda assim é muito dolorido. Claro que é muito importante o resultado final, mas não é tudo.

Já tentou rodar o Firefox ou a última versão do IE num computador com 16 de ram? Concordo que dependendo do tipo de aplicação uma interface HTML é mais leve, mas nem sempre.

Além do que o shoes falou, eu fico muito irritado todos os dias quando me vejo lidando com um monte de texto ao invés de Objetos. Frameworks jogam perfume na merda, mas como diz o cv, continua sendo merda. Existem protocolos de comunicação muito melhores que http para desenvolver aplicações. Como disse o shoes, ele é bom para fazer o que se presta: enviar documentos. Se posso usar estes outros protocolos, por que não?

No mais concordo com as suas observações, contudo os prós de desenvolver aplicações utilizando Objetos e não texto e tags html superam dificuldades decorrentes da instalação a JVM nos clientes.

E, por fim, a regra de ouro: cada caso é um caso

RMI? Quais outras? To perguntando pq desenvolvi um trabalho onde minha idéia era reunir applet + celular + bd e pra isso eu usei http.

Sockets seriam uma outra implementação desse trabalho, por exemplo?

RMI, JMS, RPC, EJB, SKTS ( :XD: ).