Java: tomas de corriente o RMI?

Necesito separar nuestra aplicación en una aplicación de interfaz gráfica de usuario ligera y una aplicación de lógica de negocios. Esta no será una configuración cliente/servidor como tal, ya que el componente 'servidor' solo tendrá un cliente.Java: tomas de corriente o RMI?

La otra limitación en la aplicación es que solo tiene un punto de entrada/salida. Por lo tanto, si usáramos RMI, solo estaría en una función. Todos los datos del formulario ya están envueltos en una cadena y se pasan a través de un área de transporte.

¿Debo simplemente usar Java Sockets para mejorar esta aplicación o ir con RMI? ¿O alguna otra tecnología Java?

Hice una publicación anterior que describe los requisitos de nuestra aplicación, sin embargo, no fue respondida. https://stackoverflow.com/questions/2604528/terminal-panel-pc-single-server-solution-client-server-or-rdp

Cheers.

Fuente

2010-04-12 StillLearning

posible duplicado de http://stackoverflow.com/questions/2604528/terminal-panel-pc-single-server-solution-client-server-or-rdp – paxdiablo

Creo que ha respondido la pregunta usted mismo. Si es liviano y un usuario único y se siente cómodo con RMI, entonces debe ir con él. –

@paxdiablo * posible * duplicado? :) – oedo

personalmente, RMI parece un poco exagerado si solo tiene un método para llamar, y todos sus datos ya están envueltos en una cadena. Me imagino que un simple servidor de socket sería suficiente para sus necesidades. sin embargo, RMI te da un montón de cosas gratis, como multithreading, recolección de basura distribuida, clasificación de objetos, etc. etc. Sin embargo, si solo tienes 1 cliente, entonces el multithreading podría no ser útil y dado que estás haciendo tu propia organización de objetos, entonces estos beneficios pueden no ganar nada.

hay una buena página de las capacidades del RMI aquí: http://java.sun.com/javase/technologies/core/basic/rmi/whitepaper/index.jsp

Fuente

2010-04-12 08:33:27 oedo

Esto era lo que estaba pensando. Mantenlo simple o usa RMI y luego aprovecha sus otras características. Todavía no estoy seguro, pero solo quería asegurarme de que no existían otros marcos/API que no conocía. Aclamaciones. – StillLearning

ya que su protocolo ya es muy simple (acaba de pasar una cadena) Sugiero que vaya con sockets. la ventaja sería que no estará vinculado a Java en ambos extremos, por ejemplo, será posible cambiar la interfaz de usuario a otro idioma fácilmente.

Fuente

2010-04-12 08:33:07

Usted puede considerar envolver su punto de entrada del servidor como un servlet y hacer un post de un cliente.

Fuente

2010-04-12 09:40:16

sí, se encarga de organizar y desasociar. El único inconveniente es que necesitamos un servidor web. –

Después de haber hecho aplicaciones que usaban sockets sin procesar para comunicarse, que usaban RMI, y que usaban SOAP, es más fácil (por un pelo delgado) usar RMI pero entonces está obligado a usar Java para todo. La clave de por qué RMI es más fácil es que garantiza que se envíen mensajes completos y incluye un marco de descubrimiento básico, y sin embargo no tiene la complejidad de SOAP (que es mucho más complicado que todo lo mencionado anteriormente).

Fuente

2010-04-12 09:53:07

Respuesta

Cuestiones relacionadas