La verdad.... no, no te explicaste.....

Quieres hacer una App Ciente Servidor, donde los datos esten almacenados en una ubicacion remota a tu App

Bueno, me parece que quieres un consejo para ver si lo harias en JSE o en JEE.... pues depende el conocimiento que tengas, a reserva de los comentarios de alguien mas experimentado en Swing (por ejemplo) puedo decirte que para JEE necesitas un background mas amplio que en JSE aunque puedes hacer cosas basicas (bueo como e todo) pero ahi te tienes que preocupar mas por cuestiones de conexion, por el estado de tu Servidor de aplicaciones y tienes que pensar en como hacer tu app multiusuario.. e cambio, veo que en app para esritorio no necesariamente tienes que poner soporte para varios usuarios porque no van a usar mas de 1 usuario tu app (creo) por lo que lo hace "mas sencillo"

Una ventaja (indudable) de las apps de escritorio es que suelen ser mas rapidas que las web apps, pues porque no tienes intermediaria una conexion (mas que la de DB... claro que puedes hacer de las dos, haces tus WS, REST ... (15 min desues por interrupcion del temblor ¿en que estaba?)... ah si pues puedes utilizar ambas plataformas pero eso depende de tu alcance... si es algo basico pues esta muy sobrado usar tanta cosa, es cosa de criterio

¿Tienes experiencia en Java?
De tener experiencia, en qué ¿escritorio o web?

De tener experiencia en el escritorio mi recomendación sería que hicieras una aplicación en el escritorio, sin embargo tienes que considerar la plataforma y por ejemplo Swing (una librería importante para el desarrollo de aplicaciones de escritorio en Java) no se integra bien con Mac, por lo que pudiese ser un problema. En el escritorio no hay mayor complicación y pues no te recomendaría Hibernate en el escritorio, de hecho lo único que harías es volver pesada la aplicación (eso es lo que me dijeron mis usuarios de una aplicación cuando utilicé hibernate). Para mí sería mejor irme a la sencilla, JDBC, implementar un ORM y una conexión usando singleton.

De tener experiencia en la web mi recomendación sería una aplicación web con algo alterno a "el marco oficial", es decir, en lugar de usar el Stack propuesto por Oracle busca alternativas. La mía sería Play! Framework o Spring Roo, pero puedes intentar con Wicket, Tapestry y ahora si te recomendaría JPA por medio de Hibernate. Algunos usan Spring, en mi caso el uso de tanto framework me marea, pero también tiene sus ventajas una vez entendiendo.

Otra cosa es si quieres aprender algo nuevo, por ejemplo si has hecho aplicaciones de escritorio y quisieras hacer una web, en este caso yo creo que a considerar más que nada sería el tiempo.

Espero y te haya ayudado.

Las ediciones de Java están muy bien definidas. Usar JEE implica usar JSE, pero no al revés.
Creo que lo primero que debes hacer es saber qué necesitas hacer y entonces echarle un vistazo a lo que cada edición de ofrece.
Una aplicación cliente servidor puede hacerse totalmente con lo que ofrece JSE.

JSE es la plataforma "genérica" para desarrollar en JAVA, sea lo que sea. J2EE es un framework para aplicaciones distribuidas, y hoy en día, un chorro de otras cosas. Mas que JSE vs J2EE, tal vez la pregunta pudiera ser J2EE vs Spring, por ejemplo; o JSP vs SWING...

Así que para "Deseo desarrollar un sistema cliente/servidor para x organización: (sistema contable), en el cual al momento de hacer alguna actualización sólo se haga en el Server," .. J2EE pudiera servir. Está muy evolucionado y documentado. Lástima que no puedo decir mucho mas que eso vs otros frameworks, pero eso es otra historia.

Creo que queda claro que se necesita mucho mas detalles de lo que necesitas hacer y lo que no puedes hacer para poder proponer alguna solución.

Para finalizar el comentario, solo sería comentar que el problema de negocio y tu experiencia deben dictar la herramienta, no al revés. No se trata de que si Hibernate o ODBC pelón y luego veo como lo meto en el diseño. Vas a usar un diseño basado en objetos de negocio bien definidos y con disciplina?: usa Hibernate. Vas a trabajar sobre un esquema de base de datos ya existente hecho un batidillo de llaves complejas y vicios de ultra normalización, olvídate, usa SQL directo y DAOS a pata.

Bueno, mis 5 centavos de comentario son de que: Primero define bien tus requerimientos de negocio y luego vemos que tecnología te lo va a facilitar. Recuerda que el mal análisis renegocio es lo que destruye proyectos en primer lugar, no las herramientas. Y, al revés, una herramienta no te salvará de errores en el diseño de negocio.

Ya tiene un rato que no se llama J2EE. J2EE era Java 2 Enterprise Edition. Había J2EE 1.2, J2EE 1.3, J2EE 1.4... como que el 2 no venía mucho al caso (sólo porque era para indicar que era Java 2, o sea a partir de Java 1.2). Cuando salió Java 1.5 o Java 5, decidieron quitarle el 2 al J2EE porque ya de plano no venía al caso. Ahora es JEE 5 y ya está JEE 6.

J2EE sólo se usa en contextos históricos, para hacer referencia a esas versiones viejas. Desarrollar hoy algo nuevo en J2EE no tendría ningún sentido, sólo se menciona para sistemas existentes a los que hay que darles mantenimiento y que no se pueden migrar a una versión más actual de JEE.

JEE no es un framework; es una tecnología como JSE o como JME.
Como parte de la tecnología JEE existen algunas cosas que se clasifican como frameworks. También sucede con JSE. Por ejemplo nos referimos a Swing como "Swing Framework". En varios textos inclusive nos referimos al API de colecciones de Java como "Java Collections Framework"
Existen varias clasificaciones de frameworks en software y el término es más usado fuera del mundo de la computación que en él.
Es un término "sobrecargado". Tenemos entonces que distinguir cuando decimos que Swing es un framework y Spring también lo es. Una de las cosas que los distingue es la inversión del control (no confundirlo con inyección de dependencias).

JEE 5 o 6, son la evolución de J2EE.. sorry pero no se que versión estará usando el compañero. Seguro que me entendió.

Si entonces somos tan perfectos, tampoco es un "tecnología".

Para los que sacian su complejo de inferioridad criticando sin aporta nada al problema, del java EE 5 tutorial:

"The Java Programming Language Platforms
There are four platforms of the Java programming language:
Java Platform, Standard Edition (Java SE)
Java Platform, Enterprise Edition (Java EE)
Java Platform, Micro Edition (Java ME)
Java FX"

Entonces es una "plataforma".

Efectivamente es una plataforma. Usé la palabra tecnología en ese contexto, sobre todo para comentar sobre los frameworks.
Dios sabrá que quiere decir eso de "Para los que sacian su complejo de inferioridad crit........" pero por si acaso no es mi intención ni de ninguno de los que conozco que aportan cosas a este foro.
Decir algo contrario a lo que yo digo no lo tomo como ataque ni crítica. Lo tomo como otra opinión tan valiosa como la mía. Así deberías hacer.
Y para aclarar más : Java es una tecnología compuesta por dos cosas: el lenguaje y su run-time. Y esa tecnología se brinda en varias plataformas.

JEE no es un framework; es una tecnología como JSE o como JME.

Que es una tecnología, de acuerdo...

Si entonces somos tan perfectos, tampoco es un "tecnología".

[...]

Entonces es una "plataforma"

pero... que no es un framework... bueno.... pues netamente, de acuerdo con esta definicion, efectivamente, no lo es ( y es efectivamente una plataforma). aunque partes de JEE si pudieran considerarse frameworks.

Para los que sacian su complejo de inferioridad criticando sin aporta nada al problema...

@avazqueznj: Siento tu comentario es a la defensiva mostrando que si alguien se siente inseguro, en todo caso eres tu. Los comentarios de bferro (como en este caso) que he leído han sido siempre con el objetivo de ayudar a entender y no con el afán de ofender a nadie (y mira que a menudo no estoy de acuerdo con su punto de vista... pero que aburrido seria este foro si siempre estuviéramos todos de acuerdo).

@gush ... pues ya tienes varias opciones, espero que en algún momento veas éste hilo, y de ahí un punto de partida para un análisis de tu problema, y definir que tecnologías/frameworks/plataformas puedes utilizar en tu desarrollo...

@bferro, no entendí tu comentario, de que la inversión del control (no confundirlo con inyección de dependencias) entonces, toda mi vida he vivido engañado? yo siempre he pensado ( y leído ) que es el mismo concepto......

Cuando alguien te critica con fundamentos uno debe ser lo suficientemente maduro para aceptarlo e incluso dar las gracias, el sentirse ofendido por una crítica es una falta de criterio madures no hay ninguna motivo racional por la cual alguien no pueda ser sujeto de críticas como si el tuviera algún tipo de autoridad sobrenatural y perfección
Parece que no han prestado atención a que el dijo un punto muy importante (yo diría el más importante incluso la decisión mas importante de diseño) a lo que se refiere a que él quiere solo actualizar en el servidor y no en todo los clientes
te cuento unas cosas las aplicaciones de la plataformas jee (definiendo como aplicaciones que usen las librerías exclusivas jee como servlet) automáticamente no presentan el problema debido a que te mandan todo la información incluida la vista por medio del navegador pero presentan el problema bajo mi punto de vista de que presentan una complejidad increíble especialmente en la configuración y nosotros lo ponemos peor poniendo una cantidad exagerada de frameworks para disminuir el problema (logrando una mejor minúscula) para luego lidiar con toda la configuración del batidillo de frameworks usados es por eso que yo te recomiendo esta es una opinión por la que me ganare muchas críticas no uses por ningun motivo el stack de frameworks tradicional yo tomaría con especial cuidado usar frameworks que tengan como lema "yo soy pragmático y fácil de usar" en mi opinión jpa hibernate(autogenerando base de datos a partir del modelo) vaadin o tapersty o play y para la inyección de dependencias Guice otro punto es usar xml cuando se la ultima opción y no con el pensamiento actual (usar xml para todo a menos que sea imposible)
Si vas por la opción de de crear una aplicación de escritorio estas obligado a usar algún mecanismo de comunicación con el servidor (el cual tiene que hacer prácticamente toda la parte difícil) uno de ellos el ejb o rmi o rpc

por ningún motivo uses las versiones antiguas de ejb

otro punto mas importante es que no deves escribir ninguna linea de codigo a menos que tengas conosimientos solidos hacerca de que es mvc ,mvp, 3 capas ,solid, y de como se hacen pojos

Parece que no han prestado atención a que el dijo un punto muy importante (yo diría el más importante incluso la decisión mas importante de diseño) a lo que se refiere a que él quiere solo actualizar en el servidor y no en todo los clientes
te cuento unas cosas las aplicaciones de la plataformas jee (definiendo como aplicaciones que usen las librerías exclusivas jee como servlet) automáticamente no presentan el problema debido a que te mandan todo la información incluida la vista por medio del navegador pero presentan el problema bajo mi punto de vista de que presentan una complejidad increíble especialmente en la configuración y nosotros lo ponemos peor poniendo una cantidad exagerada de frameworks para disminuir el problema (logrando una mejor minúscula)

Eeeemmm... se supone que pidió sugerencias, en ningún momento se dijo que tiene que meter toooodos los frameworks que se han mencionado, además, complejidad increíble configurar un proyecto?? sólo si no te haz leído la documentación del marco de trabajo elegido, porque si le echas una lectura a los docs, la gran mayoría de frameworks te dicen paso a paso cómo configurar un proyecto de forma bastante sencilla...

para luego lidiar con toda la configuración del batidillo de frameworks usados es por eso que yo te recomiendo esta es una opinión por la que me ganare muchas críticas no uses por ningun motivo el stack de frameworks tradicional

Como dije anteriormente, la configuración de los frameworks va en base a la lectura de su documentación, y previo análisis, digo, primero tienes que checar si el framework llena o se acerca a llenar tu ideal de solución de un problema determinado, después checas su documentación y haces la configuración, no veo mayor problema....
Yo aquí tengo la pregunta, cuál es el stack de frameworks tradicional??

yo tomaría con especial cuidado usar frameworks que tengan como lema "yo soy pragmático y fácil de usar" en mi opinión jpa hibernate(autogenerando base de datos a partir del modelo) vaadin o tapersty o play y para la inyección de dependencias Guice otro punto es usar xml cuando se la ultima opción y no con el pensamiento actual (usar xml para todo a menos que sea imposible)

Todos los frameworks dicen que son "fáciles de usar", y como opinión personal, generar la base de datos a partir de tu modelo de objetos, no se me hace buena opción, seria mejor al revés, puesto que es más fácil de rastrear la falta de algúna restricción en un script de base de datos, o herramienta gráfica de base de datos, que en código Java....
Y eso de usar XML, pues es relativo, digo en realidad tampoco hay que desecharlo del todo, igual te puede hacer algún paro en algún momento... o no??

por ningún motivo uses las versiones antiguas de ejb

Pues si tiene que consumir servicios solamente, no importa mucho la versión de ejb, creo que importa más si él va a construir un servicio, ahí si estaría de acuerdo..

otro punto mas importante es que no deves escribir ninguna linea de codigo a menos que tengas conosimientos solidos hacerca de que es mvc ,mvp, 3 capas ,solid, y de como se hacen pojos

Y entonces, cómo va a aprender a hacer pojos si no debe escribir una línea de código hasta que sepa cómo hacerlos??? digo, está bien que debe leer antes de empezar, pero parte del aprendizaje está en echar andar código sencillo, e irle subiendo de complejidad...

Oh, bueno, es sólo una opinión...

UPDATE : aquí hay un claro ejemplo de que un rato de lectura, y rinde frutos...thanks @Benek por tu post!

[...]vaadin o tapersty o play y para la inyección de dependencias[...]

Creo que alguien tiene que tomar en cuenta lo más importante: ¡LEER ANTES DE OPINAR!...De entrada Vaadin y Tapestry se puede decir que entran dentro de la misma categoría y esta LEJOS o más bien MUY LEJOS de ser frameworks de DI. Y de Play! pues podemos decir que es un framework que tiene la capacidad de inyectar dependencias, PERO, Play! es un framework Full-stack que va del modelo a la vista y a la configuración. Incluso que mayor problema hay con Play! para empaquetar un proyecto basta con:
 
Y listo, de igual manera con un proyecto usando maven no es más problema que teclear:
 

De verdad que no es bueno "satanizar" herramientas porqué si y aún menos sin haberlas utilizado. Recordemos que los frameworks son experiencia de otras personas que alguna vez tuvieron algún problema parecidos a los nuestros, por ejemplo ¿cuántos no hemos tratado de usar un registro de bases de datos cómo un objeto? y hay muchas cosas más. No digo que no sea chido aprender a fondo cómo se hacen las cosas, pero ya en la vida real es necesario el uso de herramientas a no ser que tengas restricciones.