Running the same framework on client and server can definitely be a good if developers are called upon to work both sides of the fence. And for the system architect to design.
With a long-running server process (not a CGI request where the program gets run each time a request is made):
* Model classes (Proxies) communicate with databases, other processes, remote servers, etc.
* View classes (Mediators) maintain individual client sessions
* Control classes (Commands) perform logic such as transforming an HTML template with data, or format a JSON or XML response
* Facade handles startup of the server app, as well as creating Mediators for new client sessions. In some languages this interprocess communication would be handled with forking and pipes, in Java it would be via threads and synchronized objects.
has an PUREMVC JS based port on web server (maybe apache reverse proxy)
-- hosts the Client Side delivering only the static images and static HTML
-- (DIVS for content layout and empty HTML5 TEMPLATE for content)
-- reverse proxy passes client commands back to application server VIA AJAX formatted as JSON
has an PUREMVC JAVA based port hosted on J2EE App server (maybe Glassfish)
-- hosts the Server application
-- No JSP's or content handlers to output html
-- App Server only accepts data requests from client via AJAX and returns formatted JSON
Sounds like a reasonable setup (although I believe AJAX that returns JSON is now commonly referred to as AJAJ).
Trying to avoid
So, your request parameters would go as HTTP headers? If you're not passing the request info via URL params or the path, then headers is all that's left.
REST as it's to tightly coupled to HTTP
This seems directly at odds with your spec above. AJAX/AJAJ implementations typically build upon XMLHTTPRequest, which is intimately coupled to HTTP. REST is just a way of letting you think about your request space in a tree form. It's a simple way to pass information to your service about what you want. As are URL params. Again, you have to pass that info some way, and the only way you've left is HTTP headers, which is as tightly coupled to HTTP as you can get.
WEB Services (wsdl or soap) as its XML is too verbose[/quote]
I agree, although most browsers and servers are capable of gzipping requests and responses now, so it's less of an issue than it once was.
I look forward to hearing about your progress.