Wednesday, October 14, 2009

Logic, Database, Your customer:

That's the basic breakdown when it comes to providing central application services. You centralize the applications so you don't have to network share every single application you want your clients to use (it just doesn't look professional).

When you centralize your applications in your company, you add many different complex challenges to providing those applications and keeping things manageable and agile.
  • How do we secure our applications?
  • How do we make them available to the clients?
  • How can we remove redundant functionality?
  • How can we simplify the deployment process?
  • Database, logic, and client...Oh my!
If you come from a LAMP or RoR background this may all be very new to you. Basically the setup works as such:
  1. The client (web, thick, thin, or services) calls up an action like: *Create new shopping cart, *Add product #23, #46, #107, and #428-A to the cart
  2. Check out using the following information: (name, address, CC# etc...)
  3. Send back the result of the transaction.
In LAMP and Rails one would have web pages that implement the logic of connecting to the database, validating the information, managing the session, and so forth. Basically all the logic is in the web page.

In a multi-tier environment, you have separate processes that manage all of that. You have a web server that sends out the web page, you have an application server that handles the logic of your session and validating values, and you have a presistance layer that handles the logic of connecting to your database. Each layer can service any other application as well. You build the logic and use it in every application where it is needed.

This simplifies management because now you can take a project and break it into many smaller parts, instead of passing around one large PHP file with about a dozen includes.

It makes sense to break your large projects into smaller more manageable chunks. It's nice to know that you can write and execute common code once, instead of writing 30 or so include file and having who knows how many threads of execution going over the same include file. With a multi-tier platform one can manage the ever increasing demand of constantly growing flat file systems, add new features without major code surgery, and reduce the amount of covering the same ground (not only in code, but in CPU cycles as well).

Giving credit where credit is due, RoR is really starting to mature in the MVC realm of web frameworks, but it still has many short comings like reducing number of threads doing the exact same thing, or rich messaging between processes (however they do have a nice RESTful services API, but so does Java and dotNet).

In the end, modern web application frameworks provide robust one shot solutions to many problems, but as your demands grow managing those applications becomes harder and harder. Multi-tier applications make it easy to scale to large deployments with a little investment up front. Modern multi-tier has come a long way since the days of spending months on each single layer, frameworks have become more compact and interchangeable, providing quick application development, testing, and deployment.
Post a Comment