I have an existing enterprise Java application with several layers including a web services facade over a Java services layer over a domain layer over a data access layer. The system currently has not GUI. The clients of this system currently are (simply) other composite web services based applications.
I am somewhat new to the whole web presentation stuff, but I am currently investigating approaches to providing customers with our own GUI thin client. I am currently looking into JSP, Ajax (or both). My question is how should this presentation layer talk with the services layer? What gives the best performance and customer flexibility for deployment?
Here are some of my thoughts:
1) Use the existing web services: Because I have existing web services I could have my web presentation invoke the existing web services. I like this idea because it would allow my customers the option of clustering just the web presentation tier in the event they need to scale up the number of users. It also reuse the existing web application tier. My concern here is that it will have high latency, slower response times and make the users crazy...perhaps Ajax will help?
2) Use remoting: I could have the web application java objects use some kind of remoting technology such as RMI to talk directly to the services layer on the app server and by pass the web services facade. This gives customers flexibility, and could perhaps run faster than the web services communication, but I am not sure how much faster.
3) Put it all in one JVM: I could put the services/domain/data access JARs right into my web server and run it all on one tier -- this seems to me to be the fastest possible performance as it eliminates an entire layer of network communication. Customers could still cluster the web presentation servers, but they may or may not like the idea that they completely bypass the existing application servers.
Are there other, better options? Are these approaches sensible?