Daniel is a handsome Java Developer in Brisbane, Australia. Twitter: @danielalexiuc Daniel has posted 3 posts at DZone. View Full User Profile

Enterprise Web Application Architecture 2.0 and Kittens

02.05.2010
| 7355 views |
  • submit to reddit

According to its homepage, CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. That is a boring bunch of words. Here is why it is interesting.

Typical enterprise web-application architectures that I've worked on in the past look something like this:



 

The grey boxes represent the data format used between each layer. As you can see, the data gets transformed many times in a typical web request from Database to Browser.

Ok now let's have some fun. Imagine that our database was clever enough to do all of our form validation and authentication for us. Our diagram would change to look like this:

 

 


 

And what about if we split up the application layer - we can put all of our business validation logic in database, and push any other leftover application logic into the presentation layer.

 



 

As shown in the diagram, there are typically two methods used to produce HTML, and they are often used together:

1. Server side view templating - where HTML code is produced on the server and sent directly to the browser (e.g. server side MVC, JSP, Velocity, Freemarker)

2. AJAX - where only data is sent from the server via an XMLHttpRequest, and Javascript manipulates the DOM directly

Let's abandon server-side templating, and do all our templating on the client side in Javascript. In fact, let's use Javascript for all our presentation needs:

 



 

Then how about we give our Database an HTTP interface, make it speak JSON and store data in JSON format. This will allow us to remove the data access layer and that awful ORM to which we've been shackled for so long.

 



 

What kind of amazing magical database can do all this? Well it turns out that a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API can.

I'm not claiming any silver bullet here, in fact CouchDB is still relatively immature. But as a potential architecture for a typical Enterprise Web App - it makes you think about whether we really need all of those grey and blue boxes. If you'd like to learn more - download CouchDB, try CouchApp, and try this demo.


Oh and as promised - here are some kittens:


Published at DZone with permission of its author, Daniel Alexiuc.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ronald Miura replied on Fri, 2010/02/05 - 5:54am

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?

Joel Samildanach replied on Fri, 2010/02/05 - 8:38am

annnnd we're back to client-server architecture then?

Tracy Nelson replied on Fri, 2010/02/05 - 12:34pm

Clue: in most "enterprise" 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.

At least you got the kittens right...

John DeHope replied on Sun, 2010/02/07 - 11:48am

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'?"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.