JSP back-end interface to Remote server. Please help the newbie

Question

Could someone comment on pros and cons of the JSP back-end interfaces to the remote server/programs using..
(1) Socket Interface between JSP and Remote Server. One socket for one JSP session. JSP to create and delete the socket when done.
(2) RMI between JSP and Remote program.
(3) Message Exchange using JMS between JSP and the Remote Server.
(4) Peer-to-peer JAXM message exchange. JSP/JAXM Client to Remote JAXM Server
(5) Anything else?
Thanks in advance..

Answer 1

(1) Socket Interface between JSP and Remote Server.
One socket for one JSP session. JSP to create and
delete the socket when done.JSPs are compiled to servlets, which use the HTTP protocol. The remote server should be the servlet/JSP engine.
(2) RMI between JSP and Remote program.As soon as you say "JSP", you're assuming HTTP request/response. If you want to talk to RMI objects, I think that's best done elsewhere than a JSP. They really should be for interface only. Have your JSP talk to a central, front controller servlet and have it invoke methods that deal with RMI objects or EJBs or POJOs on the back end. That stuff doesn't belong in JSPs, IMO.
(3) Message Exchange using JMS between JSP and the Remote Server.No.
(4) Peer-to-peer JAXM message exchange. JSP/JAXM
Client to Remote JAXM ServerNo. This is crazy. JSP = HTTP, which is client/server by definition.
(5) Anything else?All these might be fine options, but they don't belong in JSPs. Those should be for Web interface, a thin client. The details of how you process (e.g., RMI vs. EJB, synchronous vs. asynchronous, etc.) are best encapsulated somewhere else besides a JSP.
HTTP is a client/server, synchronous, request/response protocol, of course. As soon as you say JSP, these assumptions are built into your system. You can do asynchronous processing, but you still have to send back a response synchronously (e.g., "Your order is being processed. Please come back.")