Comunicar 2 aplicaciones java que estan en un mismo sevidor (JBoss)
Buen dia,
Si fueran tan amables en colaborarme, tengo la siguiente situación:
Existe una aplicacion JavaEE totalmente funcional, y se presenta el siguiente requerimiento, se realizó otra aplicación independiente pero que va a correr sobre el mismo servidor de aplicaciones, y se necesita que la aplicacion principal pueda llamar procedimientos que estan implementados en javaBeans en la aplicación secundaria y recibir su respuesta, cual sería la forma mas eficiente de realizar esta tarea?
- Inicie sesión o regístrese para enviar comentarios
Pienso que es un buen
Pienso que es un buen requerimiento para usar web services.
Ejb 3 pudiera ser otra opción
Ejb 3 pudiera ser otra opción
varias
Hay varias opciones, dependiendo de lo que necesites. Si anticipas que habrá pocas llamadas entre las aplicaciones, puedes usar cualquier opción, irte por la más fácil de implementar, etc. Si crees que habrá miles y miles y miles de llamadas entre las aplicaciones, es importante elegir algo que te dé un buen desempeño. También considerar si la manera de comunicarse va a estar cambiando o si ya es algo fijo; es decir, si los mensajes a intercambiar ya están bien definidos o no, además de qué tan probable sea que se agreguen mensajes nuevos posteriormente o que haya que modificar uno existente.
No sé por qué pero hay una correlación entre la facilidad de desarrollo/implementación y el performance de las opciones. Entre más fáciles son de implementar, peor performance te ofrecen. SOAP (o sea los mentados web services) son de lo más fácil (disque) de implementar, pero dan el peor performance y mayor overhead. EJB 3 es una mejor opción pero tampoco tiene un performance así muy bueno que digamos. RMI es un poco más complejo de implementar que EJB 3 (aunque usando Spring o alguna otra biblioteca se puede facilitar bastante) y da un poco mejor performance que EJB 3. Y luego de eso tienes opciones como Thrift y Protocol Buffers que dan excelente performance pero son un poco más complejos de implementar. Y finalmente tienes sockets, donde puedes llegar a tener el mejor performance (o el peor, si no diseñas e implementas bien tu mensajería) pero tienes que hacer absolutamente todo el trabajo de codificar, decodificar, transmitir, recibir, manejar concurrencia, etc etc etc.
O sea
Entre más bajo nivel, es más talacha y mejor performance; no es una regla general, pero generalmente suele ser así ( por lo que entendí del comentario de @ezamudio ).
RMI? me da la impresion que
RMI? me da la impresion que esta dificil, y no quiero pensar Protocol Buffers, pero como dicen, todo depende de los requerimientos.