Summary
After reading many texts, both in print and online and many discussions on the Internet a realisation slowly crept over me

I remember once my teacher said in one of my CS lessons -"if people built houses like some people built computer programs, we'd all be sleeping under the stars"

But getting back to things proper.....
That realisation was that most of the time, a lot of people talk about things in terms of this theoretical architecture, but they apply (and intend you to apply) them to the real world as they are.

One presentation server, one application server, one database server....(and one server to rule them all! No just kidding!)

But it's this constantly projected idea that really annoys me - that one conceptual tier should equal one physical tier. Where does this come from? Well, apart from Dan's discussion on TheServerSide, about the nature of distribution and the lack of understanding of that nature, my frustration at this, lies in the fact that (Note: I don't work for a large multi-national company) we have a number of databases as well as a CICS Mainframe. So we don't have one data store. More importantly we have very little data in one system that is replicated from the same 'viewpoint' as in another system, if the data is replicated at all between systems.

We have a number of programming environments running on many systems, so we don't have one all powerful application server, and we also don't have just one single way of presenting data and getting user input (as a matter of scope this ranges from CICS 3270 screens to Client-Server DB apps, from Microsoft Office to JSP's)

So my issue is that I realised a long time ago that the Theoretical Architecture was just that, and when I go from one system to another tier I have to think a whole lot more than in the GTA - I might not just be going from app-server to database, I might also be going all the way to the mainframe, to a database, to another application server and service, and on it goes.

And to go back to my point at the beginning about my teacher - one of the things he taught me about computers in my very first lesson - "Computers consist of input,output and process - that's it" and when you apply it to the GTA, "Any tier can present, process and persist". That's why I like Service Oriented Architectures - "this is my service it does X, and when you tell it to do X with this data, it does something and gives you this back". Simple.

Many of you may think I'm talking stupid - 'conceptual architecture equivalent to phycical architecture'. But how many texts actually make this rather sweeping assumption? Well, let's think about this example - in all the books you may have read and all the articles you have seen - Should I change a stored procedure that returns HTML straight out to a client, and when run process and formats data from the database?

Some of you will say yes - MVC.
But some of you may say no - for reasons of performance or similar.

Already you have a choice, and this is only a simple example. Let's make the example a little more complex - what happens if for some data matching a certain condition, you also add in some data from a mainframe, and for some data matching another condition you update a workflow system or automatically create documentation?

Talk Back!

Have an opinion? Readers have already posted 7 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Calum Shaw-Mackay adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Calum Shaw-Mackay is an architect on Java and Jini systems, working in the UK. His interests lie in distributed computing, adaptability, and abstraction. Calum has been using Jini for longer than he would care to mention. His main area for taking the blame (some people would call it 'expertise') is systems integration and distributed frameworks, and is an advocate of using Jini's unique strengths to build adaptable enterprise systems. His opinions are his own. He's tried to get other people to take his opinions off him, but they just won't.