Sistema Open-Source para Gerenciamento de Escolas

Legal usa iniciativa. Espero que dê certo. [=

Se quiser aproveitar conceitualmente algo para referência, acho que ainda tem o projeto SAGU, é um projeto bem antigo de gerenciamento de escolas/universidades, de uma pesquisada sobre ele.
[]s

Pessoal, thanks pelas respostas e pela dica do SAGU! Sim, vou dar uma olhada nele, de repente até aproveito algumas coisas, mesmo q seja conceitualmente.

Mas queria uma opinião do pessoal sobre a tecnologia que estou considerando, é uma boa ou há algo melhor? Por exemplo, usar o container do Spring e o Spring Remote para substituir os EJBs… Será meu primeiro projeto Java nessa linha, então não sei dizer qual é mais indicado.

Também haverá alguns módulos a serem disponibilizados online (via web), para esses considerei VRaptor ou Spring MVC. Qual vcs acham que é uma boa?

Obrigado!

Muito bom usar essa versão do EJB, é muito produtivo… mais porque você não faz uma interface “WEB” ?acredito que seria interessante para esse tipo de sistema.

Principalmente se usar JSF (PrimeFaces), aonde existe componentes “prontos” bem próximo de uma interface Desktop

Fala-se muito mesmo que interfaces desktop estão sendo deixadas de lado em favor de interfaces web. E sim, a interface do meu sistema não será 100% desktop, mas onde se aplicar eu prefiro esta por n razões:

• facilidade de construção se eu usar ferramentas como o WindowBuilder do Eclipse
• já faz parte do Java SE, ou seja, nada de bibliotecas ou peso extra na aplicação (eu ainda acho engraçado como se usam trocentas bibliotecas para se fazer uma app java funcional e com boa arquitetura)
• não preciso me preocupar com questões de design visual (pelo menos não tanto quanto se a interface for em web). O visual é o do look and feel (e se tem uma função que já está implementada, é a troca de L&F’s no menu principal, a partir de uma lista com os L&F’s instalados ;))

Como complemento à questão do design, a interface web vira uma salada de linguagens: HTML, CSS, JavaScript… o objetivo é usar Java, compilado em .class! Acho que isso tudo tem lugar quando o objetivo é fazer um site mesmo, divulgação para o público. Já tenho site, passei o link. É básico, mas está lá e funciona. Feito em PHP mas com uma boa arquitetura (podem me bater, mas eu gosto mais de PHP do que de Java para fazer aplicaçòes web! E está na minha agenda aprender o Ruby on Rails, ô linguagenzinha boa dimái da conta o Ruby!)

O meu foco é resolver o problema da escola, e uma aplicação tradicional janelinha-menu-botão me permite ir + direto ao ponto.

MarkKnopfler:

Fala-se muito mesmo que interfaces desktop estão sendo deixadas de lado em favor de interfaces web. E sim, a interface do meu sistema não será 100% desktop, mas onde se aplicar eu prefiro esta por n razões:

• facilidade de construção se eu usar ferramentas como o WindowBuilder do Eclipse
• não preciso me preocupar com questões de “design” (pelo menos não tanto quanto se a interface for em web). O visual é o do look and feel (e se tem uma função que já está implementada, é a troca de L&F’s no menu principal, a partir de uma lista com os L&F’s instalados ;))

Como complemento à questão do design, a interface web vira uma salada de linguagens: HTML, CSS, JavaScript… o objetivo é usar Java, compliado em .class! Acho que isso tudo tem lugar quando o objetivo é fazer um site mesmo, divulgação para o público. Já tenho site, passei o link. É básico, mas está lá e funciona. Feito em PHP mas com uma boa arquitetura (podem me bater, mas eu gosto mais de PHP do que de Java para fazer aplicaçòes web! E está na minha agenda aprender o Ruby on Rails, ô linguagenzinha boa dimái da conta o Ruby!)

O meu foco é resolver o problema da escola, e uma aplicação tradicional janelinha-menu-botão me permite ir + direto ao ponto.

Particularmente eu sou bem mais produtivo com JSF do que com o WindowBuilder do Eclipse para Swing, não acredito que seria uma vantagem isso.

Concordo que é uma Jar a mais e tals, porem é um “jar” a mais, tabom se for usar o primefaces é dois, mesmo assim não é tanto assim…
Acho que hoje em dia, com esse servidores que existem ai… essa questão de uma aplicação “pesada” teria mais “peso” alguns anos atras, claro não é para Generalizar…

Realmente para quem quer focar em java, mecher com HTML, CSS, JS é um saco, mais eu já fiz uma aplicação considerada grande apenas com JSF e PrimeFaces “puro”
ou seja, não fiz nada na unha, deixei por conta dos componentes do prime…

ErickMacedo:

já faz parte do Java SE, ou seja, nada de bibliotecas ou peso extra na aplicação (eu ainda acho engraçado como se usam trocentas bibliotecas para se fazer uma app java funcional e com boa arquitetura)

Concordo que é uma Jar a mais e tals, porem é um “jar” a mais, tabom se for usar o primefaces é dois, mesmo assim não é tanto assim…
Acho que hoje em dia, com esse servidores que existem ai… essa questão de uma aplicação “pesada” teria mais “peso” alguns anos atras, claro não é para Generalizar…

Tem gente que acha que JSF é simples e fácil de utilizar como um Servlet da vida, aí faz um cocô de código e põe a culpa no JSF. tsc

Acho que esse é o problema mais comum do programadores que usam JSF , saiu colocando componente em cima de componente e só pq funcionou acha que está bom…sem ao menos intender o ciclo de vida do faces .

Eu nunca tive problema com JSF, e sempre ficou bem rápido os sistemas…alem de ser ótimos para sistemas que querem ter as mesmas “caracteristicas” de um Desktop que é o caso do nosso amigo

Porque possivelmente terá alguma coisa acessível pela web (ex.: serviços aos alunos).

Com relação ao peso da aplicação, se eu fizer com EJB (que já falaram que é uma boa escolha), vou ter o servidor de aplicação (Glassfish, JBoss, sei lá). Se eu fizer com o Spring (container, Remote, integração com Hibernate, etc.), aí dá-lhe JAR! É uma opinião nesse sentido que eu quero. Permitam-me detalhar melhor:

• Priorizarei interface Desktop, a interface já está compilada, o servidor nem terá o trabalho de gerar HTML. Se eu resolver disponibilizar algo para os alunos em web, acho que posso fazer na forma de webservices (ex.: REST) e meu PHPzão acessa os serviços
• Leveza: o que é mais leve, os jars do Spring ou o servidor Java EE com EJB?
• Curva de aprendizado: comprei o livro de Spring do Kico, gostei d+++, mas queria algo sobre o Remote. Baixei a apostila de EJB da K-19 e vou estudá-la. Lembrem-se que estou fazendo isso para aprender como se faz na ralação mesmo!

Porque possivelmente terá alguma coisa acessível pela web (ex.: serviços aos alunos).Então por que você descartou o JSF de bate pronto falando que queria o Swing? O.o

Não to entendendo… :shock:

Não descartei não, se eu resolver colocar algo na web posso usar sem problemas.
Mas uma coisa de cada vez, primeiro os módulos gerenciais.

Tô feliz d++++++++++++++++++++++++++
Já desenvolvo em java “normalzinho”, hj fiz meu primeiro EJB funcionar (bichim lento da p********)

MarkKnopfler:

Não descartei não, se eu resolver colocar algo na web posso usar sem problemas.
Mas uma coisa de cada vez, primeiro os módulos gerenciais.

Tô feliz d++++++++++++++++++++++++++
Já desenvolvo em java “normalzinho”, hj fiz meu primeiro EJB funcionar (bichim lento da p********)

Cara, você não deve ter feito alguma “caca” ai rsrs

não é lentoo…

Vamos lá, alguns comentários que podem te ajudar.

Minha esposa tem uma escola, mas o negócio dela é um pouco diferente… é uma escola de reforço, sendo assim nenhum dos projetos como o SAGU atendiam… na verdade… até atendem, mas o objetivo de fazer um sistema foi otimizar os processos dela, igual o negócio dela, então desenvolvi um sistema novo que hoje ajuda, pois se eu usasse algo de escola padrão, talvez estivesse atrapalhando!
Fiz em web pois ela precisa acessar de diversos lugares diferentes… também o operacional do sistema é baixo, não é algo que a pessoa fique o dia todo usando.
Fiz o mais simples possivel, usei JSP/Servlet, usei HTML/CSS para as telas… usei DWR para ajax e programei em javascript/jquery… o resultado final era querer ter uma interface leve e rapida que rodasse até mesmo do celular com conexões lentas! Deu um pouco de trabalho mas não me arrependi…
Embora tenha feito MVC, não fiz distribuido pois essa necessidade não existe hoje e se vier a existir vejo que será o caso de rever o sistema como um todo e talvez até mesmo refazer do zero. No momento busquei algo simples que pudesse manter de forma barata, com hospedagem barata, etc.
Usei Eclipse e Mysql, mais nada… desenvolvi tudo em linux!

Para projetos Desktop já usei WindowBuilder e é muito bom. Entretanto telas complexas e dinâmicas sempre precisam ser feitas na unha, independente da tecnologia. Usamos SWT aqui na empresa e recomendo… é muito mais leve que swing… fiz testes de aplicativos pequenos (POC) em .NET com C# e WindowsForms… em java com SWT, Java com Swing, VB, C++ e consegui resultados excelentes em SWT comparados até mesmo com C++ (são sistemas de acesso a banco de dados, ok… dependendo da necessidade teria de ser de qualquer jeito em C++), e ainda com a vantagem de ser multiplataforma, embora não seja algo nativo do Java como Swing, é algo de peso quando dizer que é o que o Eclipse usa. A unica coisa que ficou maior no Java foi o consumo de memória, incomparável com o C++ e até mesmo com a versão .NET, entretanto, o tempo de resposta foi o mesmo. Como era um sistema corporativo e multiplataforma era um diferencial, optamos pelo SWT e não nos arrependemos.

Ah por ser simples, muitos falaram, por que não fez em PHP… confesso que tentei… e no começo o objetivo era mesmo fazer em PHP, porém por mais simples que fosse o sistema e pequeno, as regras de negócio são complexas e logo no começo o PHP começou a ficar confuso… dificil de dar manutenção… até mesmo de concluir a implementação das regras… na minha opnião, tipagem dinâmica se torna uma dor de cabeça tremenda, dependendo das regras que tem de implementar. Mudei para o Java e não me arrependi… fiz em 2 dias o que tinha demorado 1 semana para fazer em PHP e logo o sistema estava pronto, funcionando em Java.

ErickMacedo:

Cara, você não deve ter feito alguma “caca” ai rsrs

não é lentoo…

O que ficou lento foi só a classinha de HelloWorld, com sua interface remota e sua classe cliente usando InitialContext. Não fiz praticamente “nada”.

Deve-se considerar que meu notebook é um Celeron 1.3 comprado em 2004 ou 2005 (nem era meu), cuja memória inicial era 256MB (hj está com 1GB). GlassFish + Eclipse + Aplicação distribuída não tem o direito de ficar lenta nessa configuração? Feito em Delphi 7 com DataSnap fica levíssimo, mas eu quero uma arquitetura orientada a objetos, não a dados.

Estranho… aqui com EJB 3.1 fica muito rapidoo… nem percebo que estou usando EJB…

deve ser o seu PC rsrsr

a diferença entre ejb ou spring quanto a desempenho ao que eu percebo é pouca…

claro que a primeira vez que você acessa o ejb vai ser lento, mas nas próximas vai de boa…

maior_abandonado:

a diferença entre ejb ou spring quanto a desempenho ao que eu percebo é pouca…

claro que a primeira vez que você acessa o ejb vai ser lento, mas nas próximas vai de boa…

Seu argumento faz sentido, deve ser porque eu ralei um pra achar o nome JNDI (nunca tinha mexido com isso, dá-lhe coisa nova ) e toda hora o Eclipse ficava fazendo o redeploy do danado rsrsrsrsrsr.

Bacana a iniciativa,parabéns!!!

Mas,qual a necessidade de EJB?

MarkKnopfler:

Porque possivelmente terá alguma coisa acessível pela web (ex.: serviços aos alunos).

Com relação ao peso da aplicação, se eu fizer com EJB (que já falaram que é uma boa escolha), vou ter o servidor de aplicação (Glassfish, JBoss, sei lá). Se eu fizer com o Spring (container, Remote, integração com Hibernate, etc.), aí dá-lhe JAR! É uma opinião nesse sentido que eu quero. Permitam-me detalhar melhor:

• Priorizarei interface Desktop, a interface já está compilada, o servidor nem terá o trabalho de gerar HTML. Se eu resolver disponibilizar algo para os alunos em web, acho que posso fazer na forma de webservices (ex.: REST) e meu PHPzão acessa os serviços
• Leveza: o que é mais leve, os jars do Spring ou o servidor Java EE com EJB?
• Curva de aprendizado: comprei o livro de Spring do Kico, gostei d+++, mas queria algo sobre o Remote. Baixei a apostila de EJB da K-19 e vou estudá-la. Lembrem-se que estou fazendo isso para aprender como se faz na ralação mesmo!

EJB + Spring + Swing + REST + PHPzão… percebe o tamanho da gambiarra que vc esta se enfiando? A quantidade de coisas que vc vai ter que manter, evoluir e integrar?

Se tu faz web, é uma vez só pra tudo, atualizou uma vez todo mundo já tem acesso, pode acessar local, remoto, na lua, em marte, com ipad, sem instalar nada, sem peso nenhum pro cliente. Em swing vc ainda obrigado o cara instalar o Java na máquina, que é cheio de bugs de segurança e é um pé no saco pra end user ficar atualizando, tem que pensar tbm nas atualizações desse cliente swing, como vai garantir que TODOS estão usando a última versão?

Se não conhece nada de JSF, não faça em JSF, vai ficar lento do mesmo jeito, e como já falaram, a culpa será do JSF, não é só arrastar um componente bonitinho e ta tudo pronto e maravilhoso, tem que conhecer a arquitetura, como ela funciona, os componentes, claro que isso vc estudando um pouco já consegue se virar sozinho, nada impede.

Essa é apenas MINHA opinião e visão do seu projeto, boa sorte, seja como definir fazer, e coloque suas dúvidas conforme surgirem.

[]s

É só vc configurar para ele não fazer redeploy toda vez que vc salvar algum arquivo da sua aplicação…

+1

Luiz Aguiar:

MarkKnopfler:

Porque possivelmente terá alguma coisa acessível pela web (ex.: serviços aos alunos).

Com relação ao peso da aplicação, se eu fizer com EJB (que já falaram que é uma boa escolha), vou ter o servidor de aplicação (Glassfish, JBoss, sei lá). Se eu fizer com o Spring (container, Remote, integração com Hibernate, etc.), aí dá-lhe JAR! É uma opinião nesse sentido que eu quero. Permitam-me detalhar melhor:

• Priorizarei interface Desktop, a interface já está compilada, o servidor nem terá o trabalho de gerar HTML. Se eu resolver disponibilizar algo para os alunos em web, acho que posso fazer na forma de webservices (ex.: REST) e meu PHPzão acessa os serviços
• Leveza: o que é mais leve, os jars do Spring ou o servidor Java EE com EJB?
• Curva de aprendizado: comprei o livro de Spring do Kico, gostei d+++, mas queria algo sobre o Remote. Baixei a apostila de EJB da K-19 e vou estudá-la. Lembrem-se que estou fazendo isso para aprender como se faz na ralação mesmo!

Desculpe acho que vc esta fazendo algumas confusões, adicionar meia dúzia de jars a mais ou a menos não vai ser o determinante pra uma aplicação ser rápida ou lenta, vc esta falando em escolher uma arquitetura baseado em ter que colocar um jar a mais, estamos em 2013, 1GB de ram vem de troco no mercado. Não existe isso de Java puro ou não, uma plataforma se integra com diversas tecnologias, e conhecer pelo menos a mais usadas no mercado é nosso dever, um pouquinho de html e css não vai fazer vc não ser programador Java.

EJB + Spring + Swing + REST + PHPzão… percebe o tamanho da gambiarra que vc esta se enfiando? A quantidade de coisas que vc vai ter que manter, evoluir e integrar?

Se tu faz web, é uma vez só pra tudo, atualizou uma vez todo mundo já tem acesso, pode acessar local, remoto, na lua, em marte, com ipad, sem instalar nada, sem peso nenhum pro cliente. Em swing vc ainda obrigado o cara instalar o Java na máquina, que é cheio de bugs de segurança e é um pé no saco pra end user ficar atualizando, tem que pensar tbm nas atualizações desse cliente swing, como vai garantir que TODOS estão usando a última versão?

Se não conhece nada de JSF, não faça em JSF, vai ficar lento do mesmo jeito, e como já falaram, a culpa será do JSF, não é só arrastar um componente bonitinho e ta tudo pronto e maravilhoso, tem que conhecer a arquitetura, como ela funciona, os componentes, claro que isso vc estudando um pouco já consegue se virar sozinho, nada impede.

Essa é apenas MINHA opinião e visão do seu projeto, boa sorte, seja como definir fazer, e coloque suas dúvidas conforme surgirem.

[]s

eu acho que foi por isso que ele descartou o JSF de bate pronto. [=

Pessoal, eu ainda estou só escolhendo o que vai ser usado!

Pra começar, uma das minhas primeiras escolhas é entre EJB x Spring. Ou seja, não pretendo usar os 2 juntos. Estava lendo um material sobre EJB, mas acho que Spring vai se encaixar melhor. Comparando os JARs deles e outros + que eu vier a usar (Hibernate, por exemplo), vai ser realmente bem + leve do que o servidor!

Para a parte que será em web, Rest foi uma opção para eu poder integrar com o legado, que é feito em PHP. Mas pelas considerações colocadas pelos colegas, eu posso optar sim por um JSF sem problemas.

Sim, estou considerando todas as tecnologias citadas. Talvez eu falando “escolhi Swing por isso, isso, e aquilo”, o pessoal entende “não, eu quero fazer com Swing e pronto”. Bem, estou sim (ainda) com muita vontade de fazer em desktop pelas razões que eu citei, mas a parte que vai ser na web eu ainda não bati o martelo. O JSF está na minha lista de estudos aqui, só tenham calma que é muita coisa rsrsrsrs

O objetivo maior é meu aprendizado, não mais que isso. Ainda estou aprendendo, não sei o que é melhor para esse projeto e por isso estou pedindo a opnião de vcs. Atender pura e simplesmente a necessidade da escola, eu atenderia com Delphi, PHP, Java desktop com Swing, Java web com VRaptor, Turbo Pascal ou QuickBasic. Não importa se a tecnologia é antiga ou nova, o cara tem que conhecer profundamente, e esse é meu objetivo, ganhar vivência com alguma tecnologia que ainda desconheço. Não pretendo desenvolver com o Delphi até o dia q eu morrer.

MarkKnopfler:

Fala-se muito mesmo que interfaces desktop estão sendo deixadas de lado em favor de interfaces web. E sim, a interface do meu sistema não será 100% desktop, mas onde se aplicar eu prefiro esta por n razões:

As suas razões, são as razões erradas

Então vejamos. Java FX , é padrão SE no java 7 (se não está usando o java 7 o que vc está fazendo ?) Tem suporte no netbeans. O lookand feeel é CSS.

Como complemento à questão do design, a interface web vira uma salada de linguagens: HTML, CSS, JavaScript… o objetivo é usar Java, compilado em .class! Acho que isso tudo tem lugar quando o objetivo é fazer um site mesmo, divulgação para o público. Já tenho site, passei o link. É básico, mas está lá e funciona. Feito em PHP mas com uma boa arquitetura (podem me bater, mas eu gosto mais de PHP do que de Java para fazer aplicaçòes web! E está na minha agenda aprender o Ruby on Rails, ô linguagenzinha boa dimái da conta o Ruby!)

O meu foco é resolver o problema da escola, e uma aplicação tradicional janelinha-menu-botão me permite ir + direto ao ponto.

Veja bem, implementar swing remoto não é trivial. Nada trivial. Hoje em dia nem sequer é aconselhado. hoje em dia se quer desktop use JavaFX com JWS. JWS é que é o segredo. Ainda para mais se o seu sistema vai ter uma parte web, vai ser ainda mais fácil integrar o JWS. Mas não é trivial.

Se o seu sistema tem uma parte web porque não tudo web ? É um desperdício usar duas tecnologias. Não é DRY. E vc não apresentou uma razão real para usar desktop. Pense melhor.

Hoje em dia tem tecnologias web que são tão faceis de programar quanto desktop e têm look and feel e tudo isso. Dê uma olhada no Vaadin e no ZK. É muito mais melhor bom que swing. Eu adoro swing, veja bem, mas hoje, é muito trabalho. Uma opção (se insiste no swing) é usar o projeto Griffon. É em groovy feito pelo pessoal do spring source e é equivalente ao rails/grails para desktop.

Eu usaria Vaadin rodando em tomcat e spring. É mais do que suficiente. Dá um look bem Desktop sem ser. A Web já torna o sistema distribuido por natureza.
Mas detalhes, o Vaadin é para o backoffice. Para o front-office vc pode usar o Spring MVC. e achar complicado use o Vaadin apenas onde for fortemente orientado a cadastros.

Cara vc esta comprando jars? Qual projeto tem mais ou menos? Desculpe mas está tudo errado isso, precisa rever seus conceitos sobre desenvolvimento Java pra poder sim aprender o máximo possível com esse projeto e pode usar esse aprendizado profissionalmente depois, nunca vi nenhum material didático sobre Java usar alguma abordagem como essa.
Veja que a maioria dos amigos aqui já experiente esta lhe dizendo que o caminho que vc esta indo não é a opção “correta”, mas óbvio que fica a seu critério decidir o que fazer, mas avalie a ajuda que estão lhe oferecendo.

[]s

Entendi, o que eu estava querendo no início é isso mesmo. Sugestões de tecnologias. O Herbert deu a dica do JSF e o Sérgio, do JavaFX/JWS/Vaadin/Griffon (q tanto!). Eu já sei da existência do JavaFX, mas não sabia que ele é padrão no Java SE 7. Sim, estou usando o Java 7. Eu não sabia que Swing é ruim assim para acesso remoto, mas eu consegui acessar sem grande dificuldade (claro, apanhei um pouco para pegar as manhas, mas uma vez aprendido foi blz). Com relação a não ser trivial, não se preocupe, eu estou querendo é apanhar um pouco mais com tecnologias novas, acho que depois de umas boas leituras vc tem que ralar pondo a mão na massa.

A questão é que, debate-vai-debate-vem, o que era para virar um filtro de opções acaba abrindo mais opções ainda. Juro que queria ter tempo para ler sobre tantas coisas, mas eu preciso fazer alguma coisa aqui.

Bem… agradeço de coração a todos pelos toques, vou dar mais umas estudadas e pesar prós e contras. Daqui pra frente é por minha conta, logo estarei postando uns protótipos no GitHub. Abraços

[editando]Eu quis dizer comparando o “peso” desse conjunto de jars e o peso de um servidor Java EE. Os jars me parecem mais leves.[/editando]

MarkKnopfler:

Entendi, o que eu estava querendo no início é isso mesmo. Sugestões de tecnologias. O Herbert deu a dica do JSF e o Sérgio, do JavaFX/JWS/Vaadin/Griffon (q tanto!). Eu já sei da existência do JavaFX, mas não sabia que ele é padrão no Java SE 7. Sim, estou usando o Java 7. Eu não sabia que Swing é ruim assim para acesso remoto, mas eu consegui acessar sem grande dificuldade (claro, apanhei um pouco para pegar as manhas, mas uma vez aprendido foi blz). Com relação a não ser trivial, não se preocupe, eu estou querendo é apanhar um pouco mais com tecnologias novas, acho que depois de umas boas leituras vc tem que ralar pondo a mão na massa.

Vc fala que não é problema apanhar. Ok. então faça em C++ :twisted:
Vc quer aprender. Tudo bem. Mas suponho que tb queira um negocio funcionando. Senão, what’s the point ?

Veja que as tecnologias mencionndas se excluem mutuamente. Não é JavaFX e JWS e Vaadin e Griffon . É JavaFX + JWS ou Vaadin ou Griffon.

Swing não é ruim. É que não é o futuro. O futuro é JavaFX. Griffon é uma casca que permite vc programar sem saber se é swing ou swt. Vc escreve um codigo mais agnóstico. Mas ainda vai gerar um desktop no final. É uma forma de acelerar o processo, é uma ferramenta. Se vc quer aprender do zero, não vale a pena aprender swing porque está obsuleto. Eu sei swing, então para mim é mais dificil usar javafx que tenho que aprender do que usar algo que conheço. Mas para vc , deveria escolher o que é novo.

O swing não é ruim para acesso remoto. Ele não faz acesso remoto. É vc que tem que criar esse design . O swing é só a UI. Mas num sistema cliente=servidor, o cliente é mais que a UI. Ele contém logicas para comunicar com o servidor. Seja qualquer o protocolo.

Existem padrões antigos e existem padrões modernos. Porque vc vai perder tempo aprendendo o antigo ? Não é mais eficaz aprender o que é moderno ? Por exemplo, pq usar RMI se pode usar REST ? Ninguem programa sockets mais, se usam tecnologias de mais alto nível. Quanto mais alto mais simples.

Por ordem de simplicidade e parta do principio que as opções são excludentes

Só Web
MVC modelo 2 : Spring MVC ou algum outro framework web + Spring IoC + Web container (tomcat) + JSP. Simples. O problema é que tem que ser mais ou menos bom de html e css.
MVC modelo 3 : JSF + CDI + Web container (tomcat). Simples. O problema é que tem que ser mais ou menos bom de html e css e JSf é mais complexo que JSP e MVC, mas também não é nada do outro mundo.
Tendencia : Vaadin + Spring IoC + web container. Não precisa programa html nem css nem javascript. É tudo java. Só java. Os padrões são os mesmos usados no swing , swt e outros frameworks dektop. Então isso lha dá um conhecimento de como seria a UI do desktop, mas sem o problema de criar todo o protocolo de comunicação. O ZK é uma opção ao Vaadin. Ai é questão de gosto, talvez…

Desktop sem web
Cliente : JavaFX para a UI + Spring IoC para organização + JWS para distribuição. Servidor : JEE . Uso de EJB remote para a comunicação.

Desktop com web
Cliente : JavaFX para a UI + Spring IoC para organização + JWS para distribuição. Servidor : Web container. Uso de REST para a comunicação.

Desktop com web + Modulo de acesso pelo Browser
Cliente Desktop : JavaFX para a UI + Spring IoC para organização + JWS para distribuição. Servidor : Web container. Uso de REST para a comunicação.
Cliente Browser :um de “Só Web”

Existem realmente muitas opções. Vc poderia aprender todas e decidir depois. Mas pragmaticamente isso é impossível. Aliás, por isso que vc veio perguntar aqui. A principio eu lhe diria para usar o que já conhece,mas como não conhece nada, então esse conselho não serve. Então o próximo passo é : exclua o que é velho. O que é mais novo é mais dificil. Vc vai encontrar menos ajuda na net. Mas sendo que vc quer ralar, isso é o ideal para vc.
Independentemente da tecnologia pense na aquitetura e no design primeiro. Depois escolha a tecnologia que mais o ajudar a montar seu design. Tenha em mente que numa aplicação distribuída cada nodo tem as mesmas camadas que o outro, mas não necessariamente implementadas da mesma forma. as camadas padrão são

Cliente UI (a parte que realmente integra com o usuario e ele vê. Por ser o swing, o swt, o jvafx, o html , etc…) Vc tem que usar uma tecnologia para pegar os gestos e itenções do usuário e devolver a informação.
Apresentação. Esta parte é independente do Cliente. Então, qualquer cliente deve encaixar nesta camada. Esta camada contém as regras de apresentação. Navegação, desabilitação, foco, mensagens popup, etc… e delegação à camada de baixo
Dominio. Aqui estão as regras verdadeiras que podem ser chamadas de diferentes apresentações em diferentes clientes e nodos. É o core. É o sistema realmente dito.
Integração. Chamadas as outros nodos. Ao sistema de arquivos. Ao OS. Ao banco de dados. No servidor isto é normalmente a ligação ao banco. No cliente isto é a ligação ao servidor.
Recursos. Isto são os dados em si. Arquivos de configuração. Arquvios de imagem. Bancos de dados. Indexes do lucene. etc… Algums dados têm que viajar de nodo para nodo, outros não.

Não é apenas uma questão tecnológica. É uma questão de design. Por isso que eu falei que as suas razões eram erradas. Vc quer abraçar o mundo. Não precisa.
Comece por baixo. Veja funcionando. Depois vc expande. Por exemplo, o desktop é muito legal e pode paracer que vai dar uma melhor user experience , mas qual é a razão real para usar desktop ? Hoje em dia web faz tudo que o desktop faz e é muito mais rápido de criar. Tem que haver uma razão para ir para o desktop. Sem ela é tudo um exercício fútil. uma razão que eu sempre penso é integração com periféricos. Impressora, scanner, essas coisas. Se isso é necessário então o desktop é mais recomendado, de fato. Mas a pergunta tem que ser : preciso mesmo disso ?

Apanhar pra aprender, não pra fazer rsrsrsrs! Lógico que eu quero um negócio que, uma vez aprendido, me permita trabalhar com mais fluidez.

E tb só listei os exemplos de tecnologias q vc mencionou, não quer dizer que vou usar tudo junto!

Mas eu gostei das suas sugestões, era exatamente o que eu gostaria de saber. Só falar “o seu está errado, usa X que é melhor” não me convence, vc foi o primeiro a categorizar e embasar as opções de uma maneira bem didática. Pelas suas colocações, interessei-me pelo JavaFX. Ele me permitiria então criar interfaces tanto desktop sem quanto com web, segundo sua lista.

Só que eu já conheço alguma coisa sim, embora pouco. Com meus conhecimentos atuais, eu sou capaz de desenvolver em MVC Web Modelo 2 e em DSCG (Desktop Swing Cliente Gordo), que eu quero evitar.

Às vezes eu acho difícil conversar com o pessoal aqui, pq eu falo X e interpretam Math.pow(X * melancia, 1/2). Vou tentar falar numa linguagem q vcs entendem:

Forum forum = GUJ.getForum();
Tecnologia[] interfaces = forum.perguntaPraGalera(TecnologiaInterface.class);
Tecnologia[] iocs = forum.perguntaPraGalera(TecnologiaInversaoDeControle.class);
Tecnologia[] persistencia = forum.perguntaPraGalera(TecnologiaPersistencia.class);
Tecnologia[] distribuicao = forum.perguntaPraGalera(TecnologiaDistribuicao.class);

// Aqui algoritmo para decidir-se entre as tecnologias de distribuição
TecnologiaDistribuicao escolhiDistribuicao = ... ;

TecnologiaInterface escolhi = null;  // Ainda não me decidi ;)

for (TecnologiaInterface i: interfaces) {
   if ( i.pareceDesktop() && i.facilDeIntegrarComDistribuido(escolhiDistribuicao)) {
      escolhi = i;  // É esta ;)
      break;
   }
}

Acho que vcs interpretaram q eu quero aprender Swing tb. Swing eu já sei, quero aprender a fazer aplicações distribuídas e com uma arquitetura pelo menos com IoC.

MarkKnopfler:

Acho que vcs interpretaram q eu quero aprender Swing tb. Swing eu já sei, quero aprender a fazer aplicações distribuídas e com uma arquitetura pelo menos com IoC.

Tecnologias para distribuição também ha várias. tudo depende do tipo de interação que o servidor vai ter com o cliente. Hoje com websockets e tal é bem mais fácil que antigamente.
Eu fi uma vez uma aplicação swing com jws com servidor jboss ejb 2.1 que usava serialização via http( e não rmi para poder passar por firewalls) e JMS. O JMS era para o servidor poder enviar eventos para o cliente.
Se vc precisa de enviar eventos para o cliente é um tipo de distribuição , se não, é outro. Existem tecnologias como JXTA para distemas distribuidos em clusters ou do tipo emule/kazaa.

Um problema que eu tinha era com os dados e a latência da rede. Tive que incluir um mecanismo de cache do lado do cliente.

Hoje não sei se faria isso. É muito complexo. Demasiado complexo. O Browser é cada vez mais o cliente por default e hoje em dai com mobile é mais simples. Claro que uma aplicação nativa é mais bonita e tal, mas acho que web pode ser bem bonito também. Não é só porque o desktop não tem CSS e vem com o llok and feel que todos os problemas de grafismo estão resolvidos. Um designer é sempre bom. Em qualquer plataforma. E se manjar de UX ainda melhor.É isso que realmente faz a diferença. Colocar o componentna tela é fácil. Colocá-lo no lugar certo que é dificil