Funcion que devuelve el resulstado de un evento

[ping_86]

NOTA En el título puse evento porque estaba pensando en algúna solución basada en eventos que no os lleve a engaño.

Hola, es algo dificil de explicar para mi pero espero ser lo más preciso posible.

Tenemos una funcion, que envía un mensaje a un canal, luego existe otra fucnión que escucha las respuestas de ese canal.

public void numLs() {
canal.enviarPeticion("numLS");
}

public void servidorResponse(int codigo, String respuesta) {
..............................
if (codigo == Codigos.numLS) {
aquí tenemos el resultado de numLS en la variable respuesta
}
..........................
}


Ahora bien no sabemos cuando va a llegar la respuesta, ni tenemos ningún control sobre el canal puesto que es un servicio externo.

Pues lo que se pretende hacer es una función que llamada en el código haga los siguiente



public inc numeroLS() {
...................
return numLS;
}

System.out.println("Número ls "+ objeto.numeroLS());

la función envía la peticion al canal, y devuelve la respuesta, en caso de un error o un timeout devolver una excepción.


Alguna buena práctica o forma de realizar esto?

Saludos y gracias.

[HackmanC]

Hola,

Iniciado por ping_86

... Tenemos una funcion, que envía un mensaje a un canal, luego existe otra fucnión que escucha las respuestas de ese canal.

Ahora bien no sabemos cuando va a llegar la respuesta, ni tenemos ningún control sobre el canal puesto que es un servicio externo.

la función envía la peticion al canal, y devuelve la respuesta, en caso de un error o un timeout devolver una excepción.

Alguna buena práctica o forma de realizar esto?

Buena práctica no estoy seguro, pero normalmente en las comunicaciones asíncronas se utilizan hilos diferentes sincronizados. Acá entran dos conceptos a tomar en cuenta,

¿Tu aplicación no hace otra cosa mas que esperar la respuesta o realiza otra actividad así como tiene una interfaz gráfica con un botón cancelar o algo por el estilo?

Si tu aplicación tiene una interfaz gráfica con un botón cancelar o realiza otra actividad mientras espera la respuesta entonces necesitas esperar la respuesta en un hilo independiente, una vez que este hilo obtuvo la respuesta ejecuta una acción o le avisa internamente al hilo principal con métodos sincronizados, mensajes u otros.

Sino es necesario realizar otra actividad en el intervalo de tiempo de espera entonces simplemente esperas la respuesta en el mismo hilo y se hace mucho mas fácil, aunque el programa se queda 'detenido' mientras espera.

Un método no aconsejado, en otros lenguajes se acostumbra hacer un 'barrido' temporizado, (como en el caso de C), cada X segundos o minutos el programa principal revisa si hay alguna respuesta, haya o no una respuesta continua con el programa principal, este método es muy antiguo y no es muy usado en Java.

¿Tu aplicación recibe la respuesta de un socket?

En las aplicaciones que usan sockets en Java se acostumbra usar un hilo que espera la respuesta, actualmente con NIO es preferible usar sockets que no bloquean. Es decir, el socket no espera una respuesta al leer sino que avisa llamando a un método cuando hay datos disponibles. En otras palabras tu aplicación recibe una notificación cuando ya hay datos.

Saludos,

[ping_86]

La aplicación funciona de la siguiente forma.

Existe un programa continuamente escuchando el canal de entrada (socket).

Cuando se le hace una petición se crea un hilo que envía a ese canal de un comando. Despues ese socket tiene que esperar a que se realice la respuesta, que no sabe cuando será y por último devolver el resultado.

He estado buscando y en encontrado como realizarlo con el Productor/Consumidor Java

http://casidiablo.net/java-sincronizacion-subprocesos/

Creo que es la solución adecuada. pero solo creo. Si se os ocurre una forma mejor estoy abierto a cualquier opción

Saludos y gracias,

[HackmanC]

Hola,

Realmente no entendí lo que quisiste dar a entender, y todavía sigo sin saber si 'bloquea o no'. Pero si te es de alguna ayuda revisa BlockingDeque y BlockingQueue en la API de Java (para implementar producer/consumer). Si son sockets lo mejor es usar NIO, donde solamente usas un hilo para enviar y recibir y 'no bloquea' (no espera sino que recibe una notificación).

Saludos,

[ping_86]

HackmanC voy a intentar explicarme mejor, pero perdona pero la ignorancia es muy mala y no domino todo lo que quisiera el tema.



Envía y recibe datos de un socket, tiene que estar conectado continuamente, es mas costoso realizar la conexión que mantenerlo conectado.

Escribes en un canal un comando por ejemplo numLs con una función enviarComando y recibes el resultado por otra furnción recibirRespuesta(int codigo, String respuesta).

El programa esta recibiendo continuamente respuestas con cogio 1, 2, 3, 4 ..... N. Tu envías el comando numLs que es el comando 4 y en un determinado momento te enviará por la funcón recibirRespuesta, el código 4 con el string de la respuesta.



Por otro lado se pretende integrar este programilla en una formato web, por lo que las peticiones se hacer a un Servidor.java, que crea un thread por cada petición, coje el prgrama anterior y envia el comandoLS y espera por la respuesta y a continuación la muestra.

Por lo que dices veo que es mejor NIO puesto que como tenia pensado (productor/consumidor) bloquearía el programa mientras espera por la respuesta, mientras con el otro no (corrígeme si me equivoco)

Saludos y muchas gracias.

[HackmanC]

Hola,

Iniciado por ping_86

Escribes en un canal un comando por ejemplo numLs con una función enviarComando y recibes el resultado por otra furnción recibirRespuesta(int codigo, String respuesta).

Esa parte si la había entendido, es decir, enviar y recibir por un socket de forma asíncrona, a lo que yo me refería era si el programa hacía algo más, si el programa envía y espera la respuesta entonces es un solo hilo que se manda y después se detiene a esperar; si envía en cualquier comento y recibe en cualquier momento entonces son dos hilos uno dedicado a enviar y otro a recibir.

Si necesitas que se comunique un hilo con el otro busca información sobre las clases que mencioné anteriormente puesto que resultan muy útiles para eso.

Iniciado por ping_86

Por otro lado se pretende integrar este programilla en una formato web, por lo que las peticiones se hacer a un Servidor.java, que crea un thread por cada petición, coje el prgrama anterior y envia el comandoLS y espera por la respuesta y a continuación la muestra. ...

De nuevo, si manda un comando y después se detiene a esperar y no hace nada mas pues solo necesitas un hilo para realizar ese procedimiento, uno por cada socket. Si necesitas un montón de hilos enviando y esperando la respuesta, solo tendrías que pensar en la cantidad de hilos que vas a manejar.

Iniciado por ping_86

Por lo que dices veo que es mejor NIO puesto que como tenia pensado (productor/consumidor) bloquearía el programa mientras espera por la respuesta, mientras con el otro no (corrígeme si me equivoco)

Con los dos métodos puedes lograr sockets que no bloqueen, es decir, con producer/consumer puedes crear un hilo aparte para leer y ese hilo es el único que se va a quedar bloqueado mientras espera la respuesta. Con NIO tienes que registrarte para recibir eventos del socket cuando lea, pero no bloquea.

Pero todo depende del objetivo de tu aplicación, si no es necesario que el programa haga algo mientras espera pues solamente necesitas un hilo con un socket normal. Ahora si quieres que el programa envíe X comandos eventualmente en un intervalo de tiempo indefinido y reciba N respuestas de igual forma eventualmente sin un tiempo definido y posiblemente intercalando envíos y respuestas, entonces necesitas dos hilos, uno que envía y otro que recibe o usar NIO en un solo hilo.

La ventaja de NIO es que no necesitas mas que un hilo para recibir y enviar, y por consiguiente no necesitas sincronizar los hilos, la desventaja es que es un poco complicado aprenderlo a usar.

Saludos,