Lo que describes es comunicación síncrona y no siempre es el caso. El ejemplo con HTTP está bien porque HTTP es un protocolo de comunicación síncrono, pero hay protocolos asíncronos en los que puedes estar enviando datos y recibiendo datos al mismo tiempo, por la misma conexión. En ese caso necesitas tener un proceso enviando datos y un proceso separado leyendo los datos que llegan por el socket, y generalmente la conexión se mantiene abierta.

Del lado del servidor, en Java puedes implementar algunos modelos para las conexiones que aceptas, puedes manejar un hilo por cada conexión que aceptas, o manejar todas en un solo hilo (con java.nio) o un híbrido usando thread pools.

Más info aquí:

Bueno, como mencione no soy experto en Java (espero serlo algún día) , gracias por la asesoria. Espero estudiar más sobre este tema.

No necesitas ser un experto en Java. Los modelos que describo para servidor son válidos en otras plataformas, incluso hay otros modelos como un proceso separado para cada conexión, en vez de un hilo por conexión, con un pool de procesos (similar a lo que hace Apache httpd). La info del final sí es específica de Java y espero te sirva.

Les mando felicitaciones por el tema, bastante info buena

buen tema, lo estaré observando o.O

Ya veo, si, es un sistema CRUD, definitivamente si te conviene utilizar el API de Java RMI que jugar directametne con los sockets... a menos que te gusten los deportes super super extremos, estilo surfear en lava ardiente ;-)

Siempre que claro, necesites 3 capas, por que si no, pues podras conectarte directo desde Swing a la base de datos usando JPA... o JDBC, si te sientes medio-suicida ;-)

el chiste creo yo es aprender, por que va a ser una tesis no? no se trata simplemente de hacer la aplicación, si no entender de cabo a rabo como funciona. Por ejemplo yo siempre he usado rmi y tengo una vaga idea decomo funciona, pero no se como lo implementan ni nada.

PD. para el autor de este post, checa mi blog, hace mucho tiempo coloque un proyecto que hize de un juego multiusuario que utiliza sockets, esta bastantita mala el modelo servidor, por que crea un thread por conexión, pero bueno era para aprender =)

saludos

Bueno al final de cuentas, aprender Java RMI tambien es aprender no? , supongo que siendo tesis se le puede orientar a algo no llega a nivel de ser verdaderamente util, si no quese queda simplemente en el nivel de ejercicio academico. Espero que no me mal entiendan, los sockets son muy utiles en el mundo real, pero por lo que se describe de esta aplicación, RMI parece un mejor candidato para construirla, y si es una tesis: no deberia ser parte de su metodologia de investigacion seleccionar la mejor tecnología para resolver el trabajo? Si fuera sinodal de esa tesis, le pediría que defendiera sus razones para no usar RMI (y para no usar EclipseLink Remote Sessions)... y a respuesta de "por que solo es un tesis" no resultaría en mi aprobación....

Por otro lado, la mayoria de las tesis que he visto se quedan precisamente en ese nivel (el de jugar con una tecnologia solo por aprender, independientemente de si es la mejor para el caso o no)... por que no mejor hacer una tesis que tenga como resultado un framework para facilitar la programacion con RMI (por ejemplo, integrandolo con JSR-299 Weld o con JPA, para darle a Java business objects distribuidos).... o de como propagar y controlar mensajes de error de logica de negocios desde el middle tier a el cliente... no se... algo que construya sobre o que ya esta construido en ves de reinventar la rueda...

Los iniciadores del desarrollo de GIMP en 1995 fueron los estudiantes Spencer Kimball y Peter Mattis como un ejercicio semestral en la Universidad de Berkeley, en el club informático de estudiantes.

GIMP ni siquiera era un proyecto de tesis, y de el, derivo GTK+, y de ahi GNOME..., y era solo un proyecto semestral... definitivamente no creo que decir "es solo una tesis" sea justificación para no utilizar el mejor enfoque posible para resolver el problema que se este atacando.

A veces una tesis puede ser una oportunidad para hacer algo sin tener las malditas restricciones de mundo real que salen en la chamba, como no usar tal o cual framework simplemente porque es política de la empresa, sin mayor razón técnica. O al revés, tener que usar forzosamente X o Z framework porque eso dijo el director de sistemas y no puedes contradecirlo.

En una tesis puedes proponer una nueva arquitectura para algun tipo de aplicaciones, un nuevo patrón de diseño, o presentar una nueva aplicación para cierta tecnología... puedes hacer algo muy interesante.

En si no es tanto la aplicación lo que cuenta, si no también la metodología de desarrollo. El punto fuerte del proyecto no es la aplicación ni la herramienta que estoy ocupando, es la forma en que lo voy a desarrollar

Alguna metodología en particular, o tu tesis consiste en proponer una metodología nueva?

Es la combinación de las metodologías MDAE y DSDM para crear una nueva.

Si, se trata de un sistema de información que permita Insertar, Actualizar, Consultar y Eliminar registros de la base de datos de una empresa de transporte público mediante un programa Servidor que contine la BD y los módulos Cliente que solicitarán acceso a ella y registrar datos de los clientes

Si, se trata de un sistema de información que permita Insertar, Actualizar, Consultar y Eliminar registros de la base de datos de una empresa de transporte público

Esa primera parte, suena como a que JPA seria la solucion ideal para el problema (o quiza JdbcTemplate si no te gustan los ORMs).

mediante un programa Servidor que contine la BD

Esta parte ahora me hace pensar que masbien le estas apuntando a una arquitectura de 2 capas,por esto que dices de "un programa Servidor que contiene la BD"... estas pensando en manejar una base de datos java embebida en el servidor RMI? (Como H2?) o piensas usar una base de datos separada? (MySQL,Postgresql, Oracle, etc)

y los módulos Cliente que solicitarán acceso a ella y registrar datos de los clientes

A ella quien? Los modulos clientes tendrian acceso directo a la base de datos? (2 Capas) o hablarian con una capa intermedia en Java (3 Capas). Si estamos hablando de 3 Capas definitivamente suena exactamente como el tipo de problema para el que Java RMI y EclipseLink Remote Sessions. Si no, pues desde Swing te puedes comunicar directo a la base de datos usando JPA para la persistencia y JSR 296 para el databinding. Con el wizard que trae netbeans es facilisimo: Tutorial paso a paso con Netbeans para aplicacion de 2 Capas

En si no es tanto la aplicación lo que cuenta, si no también la metodología de desarrollo. El punto fuerte del proyecto no es la aplicación ni la herramienta que estoy ocupando, es la forma en que lo voy a desarrollar

Bueno, si en si no es tanto la aplicación lo que cuenta, si no la metodología de desarrollo, tal ves no deberias ir por el camino de supercomplicarte la vida reinventando Java RMI con el API de super bajo nivel de sockets... o preocuparte de como construir una aplicacion de 3 capas con persistencia a la base de datos utilizando las APIs mas convenientes (EclipseLink Remote Sessions), si no mas bien buscar el modo mas facil de resolver el problema: Aplicacion a 2 capas con Swing, JSR 296, JPA y Netbeans.

Por otro lado, si lo importante es la forma en que lo vas a desarrollar, yo diria que un paso importante al decidir el modo es observar la situacion en la que se va a ejecutar tu sistema... por ejemplo... sera a traves de internet? o en una intranet? Si es a traves de internet (y no cuentas con una VPN), entonces Java RMI y las Eclipse Link Remote Session hacen sentido para proteger el acceso a tu base de datos utilizando a la capa intermedia que introducirías como barrera... si por otro lado, todo va a ejecutarse en una intranet, es posible que sea suficiente asumir a la red como un mecanismo de comunicación seguro, y utilizar solo 2 capas y simplificarte mucho la vida en terminos de complejidad de codigo y de velocidad de desarrollo... ademas de que probablemente tendrías menos conceptos nuevos que aprender (y por otro lado, hay bases de datos que soportan comunicacion encriptada, y eso igual podria ahorrarte tener que crear 3 capas).

Es importante definir el objetivo, y conocer sus implicaciones en el trabajo real a nivel de desarrollador, por que si no, terminaras proponiendo el tipo de solucion que un arquitecto astronauta propondría: completamente desconectada de la realidad del desarrollo. Tienes que enfocarte bien en que problema estas queriendo resolverle a tu cliente, y luego, basado en el ambiente y en los requerimientos de tu cliente, elegir la tecnología (y metodología) mas adecuada (y no empezar por "voy a hacerlo a X capas, o voy a hacerlo con sockets o..." si haber analizado primero si la situación amerita tal o cual enfoque.

Recuerda, primero analiza la situacion, y luego propon una solucion... hacerlo al reves conduce casi siempre a la perdicion (a menos claro, que tu tesis tenga el objetivo de demostrar lo malo que es crear soluciones y luego buscar problemas ;-) )

Bueno, MDAE no se que sera (suena como MDA, pero no puedo estar seguro), DSDM supongo que es Dynamic Systems Development Method. Uno de los objetivos principales de de DSDM es el desarrollo rapido (RAD), asi que si quieres seguir DSDM, definitivamente la reinvencion de JavaRMI mediante uso directo del API de sockets seria una violacion a los principios de DSDM. En todo caso deberias estar buscando tecnlogias estilo NakedObjects... si los requerimientos indican que lo mas adecuado es una aplicacion de Escritorio, entonces probablemente una Aplicacion a 2 capas con Swing, JSR 296, JPA y Netbeans sea tu una buena opcion, si en cambio los requerimientos apuntan hacia Web, entonces probablemente lo mas adecuado seria algo como como AribaWeb o AppFuse

P.D. Si MDAE es MDA, entonces que uses el API bajo nivel de sockets estaria doblemente en contra de tu metodologia, el chiste de MDA es construir aplciaciones definiendo un modelo, y dejandole a tu infraestructura el "detalle" de derivar el codigo fuente a partir de ese modelo. Mas bien deberias estar buscando utilizar proyectos como OpenMDX (o si preferieres, crear tu propio generador de codigo basado en MDA, lo que si es seguro es que tampoco seria conveniente que te metieras con el API de sockets de bajo nivel)

Entonces no son metodologías flexibles? Hay metodologías que puedes aplicar a un desarrollo sin importar si lo haces directo con cliente-servidor o con más capas que todos los superamigos juntos, o con bloques de Lego (virtuales, para que siga siendo software).

Bueno, claro que son flexibles, si quieres, podrias crear un producto lllamado MDA2ASM que reciba un PIM y genere a partir de el codigo en ensamblador... Igualmente, supongo que nada te impide hacer un generador MDA que genere una aplicacion con codigo de sockets bajo nivel a partir de tu PIM... (seria un absurdamente mas dificl que que generar codigo JPA, pero si problemas es lo que estas buscando...).

Por otro lado, DSDM: "DSDM was developed in the United Kingdom in the 1990s by the DSDM Consortium, an association of vendors and experts in the field of software engineering created with the objective of "jointly developing and promoting an independent RAD framework" by combining their best practice experiences." Todo el objetivo de DSDM es desarrollar rapido aplicaciones. Se supone que maneja una etapa de inicial de "Estudio" durante la cual se debe hacer un estudio de factibilidad para determinar si DSDM es adecuado para el tipo de proyecto que se quiere construir, y un estudio del negocio en donde "las características escenciales del negocio y la tecnlogia deben ser analisadas"... y me sorprenderia sobremanera que el resultado de efectuar dicho estudio de forma correcta atacando el problema de construir un sistema "para empresa de transporte público (radio taxis) con el proposito de atender clientes, asignar taxis y llevar el control de pagos, facturas a clientes, y guardar las operaciones en MySQL " fuera que lo mejor que se puede hacer en este caso es trabajar con API de sockets de bajo nivel.... en todo caso, si DSDM es incapaz de evitar un error de esa magnitud habria que cuestionar su valor como metodologia... es ese el objetivo de la tesis? demostrar que no importa lo que diga la metodología, se puede fallar catastroficamente?

Por otro lado, DSDM prohibe explicitamente "Projects that aim to produce re-usable components - the demands on perfection are often too high and conflict with the 80%/20% principle described earlier." Creo que crear una arquitectura para generacion a partir de PIM ciertamente cae en el area de crear componentes reutilizables... ademas de que tendriamos que como dije antes, revisar los objetivos de la tesis... que queremos al final? tener un sistema para administrar taxis? o tener un generador de codigo basado en sockets basado en MDA? cuales son nuestros argumentos para no utilizar alguno de los generadores MDA opensource que ya existen? O quiza tener un monton de documentacion (pero nada de codigo funcional). Esto ultimo igual iria en contra de DSDM (que se supone que busca ofrecer una solucion iterativa, que produsca pronto un prototipo de la aplicacion, y no un cerro de documentacion)

Gracias por las aclaraciones, voy a tomar en cuenta lo que dices

No , solo se plantea la combinación de ambas metodologias "NO VOY A INVENTAR EL HILO NEGRO", respecto al uso de sockets si es un poco dificil lo que plantee anteriomente, pero no es imposible

Entonces te refieres al Analisis Estructurado? Bueno, en ese caso, por ese lado, no tienes las restricciones que tiene MDA (en cuanto a tener que describir tu sistema en PIM, y combinarlo con un PDM para producir un PSM ejecutable. Basicamente el AE te permite analizar cualquier conjunto de requerimientos, documentarlo, y convertirlo en una aplicación.... por ese lado, tienes flexibilidad total (tanto potencial para tener exito, como para fallar). Por otro lado, es una metodología antigua... de 1970 y 1980... si yo fuera a evaluar tu tesis, te preguntaría por que no estas aplicando ninguna de las metodologías mas modernas...
Pero las restricciones DSDM que mencione siguen aplicando: Todo el objetivo de DSDM es desarrollar rapido aplicaciones. Tus estudios de factibilidad y de negocios deberian de llevarte lejos de la aplicar el API de bajo nivel de sockets... como dije antes si DSDM no puede evitar una perdida de tiempo como la que significaría desarrollar tu aplicación de esa forma, y su objetivo es el desarrollo rapido, habria que cuestionar su valor como metodología.

No , solo se plantea la combinación de ambas metodologias "NO VOY A INVENTAR EL HILO NEGRO", respecto al uso de sockets si es un poco dificil lo que plantee anteriomente, pero no es imposible

No entendí... que cosa no es "un poco dificil lo que plantee anteriomente, pero no es imposible"? Reinventar Java RMI? Definitivamente no creo que sea imposible, quiza ni siquiera muy dificil, pero los recursos disponibles para construir una aplicación (sobretodo el tiempo) son finitos. ¿Por que perder el tiempo reinventando Java RMI (o la persistencia distribuida de EclipseLink) si ya estan ahi, son gratuitos y estan probados por cientos de empresas en la industria? Como justificas algo asi en tu plan de trabajo?

Te aprovechas quizá de la ignorancia del cliente, haciéndole creer que lo que estas construyendo usa las tecnologías disponibles mas adecuadas para el problema, cuando lo que vas a hacer es reinventar el hilo negro? ;-)

Si estas pensando en crear una nuevo metodología de desarrollo basada en una combinación de SA y DSDM, y no encuentras en ellas nada que evite un error asi de grande (segun yo DSDM debería evitarlo, pero tampoco soy experto en DSDM), tal ves deberías pensar en contribuir con una "clausula extra" que evite este tipo problemas como parte de tu tesis... Creo que es importante que te lo plantees de una ves, por que cuando salgas al mundo real, aunque te parezca sorprendente, encontraras personas que querran reinventar el hilo negro en todas partes (con la consecuente perdida inutil y absurda de tiempo)...

El uso de Sockets en mi proyecto solo es para establecer una comunicación entre el módulo principal (SERVIDOR) y los demas módulos (CLIENTES), como un "pequeño chat " solo es para consulta del usuario (mi asesor de tesis me sugirio que asi deberia ocuparlo).

p.s "NO ME ESTOY APROVECHANDO DE LA IGNORANCIA DEL CLIENTE " :) apenas si soy un inexperto en este lenguaje

El uso de Sockets en mi proyecto solo es para establecer una comunicación entre el módulo principal (SERVIDOR) y los demas módulos (CLIENTES),

Al final, en Java, sobre TCP/IP toda comunicacion entre el Servidor y los Clientes usara internamente el API de Sockets, la cuestion es si es conveniente o no que tu los uses directamente... la respuesta depende de tus requerimientos... y por lo que has planteado: "un sistema para empresa de transporte público (radio taxis) con el proposito de atender clientes, asignar taxis y llevar el control de pagos, facturas a clientes, y guardar las operaciones en MySQL " no se justifica el uso directo del API de sockets

como un "pequeño chat " solo es para consulta del usuario (mi asesor de tesis me sugirio que asi deberia ocuparlo).

Para un modulo de Chat casi haria sentido... si no fuera, por que seria mas conveniente que aprovecharas un proyecto opensource con soporte para XMPP como OpenFire (y su cliente, tambien opensource Spark)

Imaginate que estas compitiendo en una especie de proceso de licitacion para ver si te ganas el proyecto... crees que tu sistema de chat superara al de otro competidor que ofrezca simplemente instalarles OpenFire/Spark? (Tal ves si a a la larga, pero OpenFire puede estar listo en 30 minutos, y tu tardaras meses en llegar a tener un el mismo numero de caracteristicas, y quiza mas de 1 año en tener algo claramente superior... tiempo que podrias haber aprovechado en aprender el API de Spark y construirle extensiones... en vez de reinventar el hilo negro...)

Hola a todos.. les cuento que yo tambien estaba en el proceso de decidirme por un buen tema de tesis para graduarme... y mi idea inicial era una aplicacion similar a la de CARRARO pero enfocada a imprentas y mecanicas que trabajan con ordenes de produccion y de trabajo. El punto es que siempre me ha gustado programar en Java pero no sabia por donde empezar el desarrollo de la aplicacion cliente-servidor, pero gracias a uds ..tengo muchas esperanzas. Voy a empezar a solicitar ayuda y voy a seguir de cerca a CARRARO en su trabajo.......

hola q tal.. la verdad es que despues de dos años retomo la carrera si me podrian recomendar libros o foros paginas donde pueda encontrar informacion sobre programacion web ... ahora estan en el tema de los socket comunicacion cliente-servidor el profe nos dejo para hacer como un mini chat entre dos computadoras ... si me pudieran ayudar se los agradeceria mucho