Javalobby - Comments for "Enterprise Web Application Architecture 2.0 and Kittens" Comments for "Enterprise Web Application Architecture 2.0 and Kittens" en I really like what you're <!--paging_filter-->I really like what you're trying to do here. But I think the "enterprise" places some constraints on you that you aren't acknowledging. I'd like to hear your thoughts on a few of them. Perhaps another stab at this, but considering some of these issues, would be a good follow-up article. - Enterprises like their relational databases. Convincing folks to abandon sql and go with json and http is like asking them to dump, oh i dunno... excel spreadsheets and go with full fledged databases when they need them. It's not a question of wrong or right, so much as it is an issue of institutional familiarity. - You have to have, minimum, three layers. Nowadays enterprises do not put their databases in public-facing networks, they put them in DMZs, and they only allow specific other computers to access them. These other computers are the application servers, and they are public facing, but have the access to the DBs to get the data. Generally these are web servers. I have also seen it taken to another whole degree by placing a fourth (mandatory) layer in there, that of the services. In this case public facing application (usually web) servers reach out to services (usually soap) servers, and the services are allowed to hit the databases. Anyway I am taking a long time to explain that you have glossed over an entire aspect of modern enterprise network security architecture. This leaves me asking is "what does it mean 'enterprise'?" Sun, 07 Feb 2010 11:48:24 -0500 johndehope3 comment 25341 at Clue: in most "enterprise" <!--paging_filter--><p>Clue: in most &quot;enterprise&quot; situations, you aren't the only one using the data.  You try telling the guys in Billing or Purchasing that they'll have to parse JSON strings or DOMscrape your web app (because you moved some business logic into the UI) and you'll find yourself embarrassed in a meeting when you find out that nobody's using your app because it's more effort than it's worth to integrate with it.  Your data access layer's there because in an enterprise, you'll likely need data from more than one source.  Your application layer's there because you'll probably need extended validation (like: will we have to split this customer's order to bill it across two or more purchasing contracts?) or to coordinate with other systems (is there enough product in stock to satisfy this order?  If not, will a shipment come in before this order has to ship?).  Your presentation layer is there to do the grunt work so you can show a customer a summary total without having to ship a couple hundred lines of data to the browser and computing the total client-side.  Like jsmildanach pointed out, the whole lets-put-all-the-business-logic-in-the-database movement died out years ago, and for good reason.</p><p> At least you got the kittens right... </p> Fri, 05 Feb 2010 12:34:32 -0500 tnelson comment 25285 at annnnd we're back to <!--paging_filter-->annnnd we're back to client-server architecture then? Fri, 05 Feb 2010 08:38:27 -0500 jsamildanach comment 25269 at What about if you have some <!--paging_filter-->What about if you have some business logic that is not 'validation', but you cannot take the risk of someone modifying your javascript code (which is pretty easy these days) and changing it? Fri, 05 Feb 2010 05:54:02 -0500 ronaldtm comment 25257 at