Opinions/headers for splitting an application into front-end/back-end (not user/admin, but ui/logic)

I am building a new web application and playing around with the architecture and would like some opinions about splitting UI and business logic and running them on separate servers.

This means that if someone requests a page, the front end will itself request the data from a back-end server and then not actually perform any calculations/logic but just use the data to populate a template and then respond with that.

• Back-End: Java + JAX-WS
• Front-End: Kohana 3.1 (PHP)
• Data Interchange Format: JSON

Advantages:

• clear separation of logic and UI
• ability to choose language/framework best suited for either end
• possibility to add logic/UI servers depending on which one is the bottleneck in case of performance issues
• possibility to make the API publicly available without any extra work (pseudo-internal requests will go to the same API as requests from third-part applications)
• ability to change (if need be) the framework/language of either side without having to edit the other
• ability to specify different server hardware according to the needs of the logic/UI application
• better security (if API private) (??)

Disadvantages:

• latency (??)
• more servers

So what do you think? Is this a good idea? I haven't been able to find much information so far but my guess is that many big sites do it this way, right? How will performance be affected (I am thinking of running it on EC2)? What are开发者_开发技巧 further advantages/disadvantages? Any thoughts on the languages/frameworks choices?

A similar architectural pattern is often employed, though generally the UI part is often moved to the client. So you have a backend that responds with JSON, a quick http server with full-blown caching (and that can use html5 app caching as well) and a rich javascript client which requests the JSON from the backend and builds the UI.

More on this pattern: http://www.metaskills.net/2008/05/24/the-ajax-head-design-pattern/

The main negative of the approach is that is generally more work in the beginning - if you don't need an external API then using a simpler architecture will be easier to program.

You also might want to employ the idea of keeping your servers stateless and let the client side handle any state. This simplifies the whole load-balancing and fail-over stuff and makes you think about a more resource-oriented architecture.

And if you are set on JSON already, you might want to explore the idea of NOT mapping POJOS to your data and use a document store like MongoDB or CouchDB to access JSON data directly.