The stuff on the servers (the “back end” of the system, where your laptop’s browser is the “front end”) actually has a bunch of things to do, and in well-designed systems the chunks of functionality are called “tiers” and a system with “n” things to do is called “n-tier architecture”. Let’s talk about some of those tasks:
First, the system has to have some way to respond to requests from your web browser, so the top tier needs to be a “Web Server” (software that knows how to play well regardless of the flavor of web browser you are using, and regardless of whether you are sitting in front of a PC or a Mac).
Secondly, the Web Server has to figure out who you are: is the person looking to get access to the digital assets, of this project, actually allowed to see it? This is the login role, and as part of that the system, also might have to tell the difference between a junior photographer (who may only be allowed to see the photos they have taken) and a photo editor (who can see anything they desire!). It can be far more granular: some people may be allowed to see anything, but not allowed to tag anything. Some people may have permission to initiate a production. These rules that govern who can do what are called “business rules” and they live in the top tier.
Thirdly, this tier of the system has to know how to transform your request to the language the database understands, and when it gets records back from the database, it needs to know how to construct a page to send down the wire to your laptop, so you can see just the documents you asked for.
The “Web Server” tier plays the three roles we mentioned (see the above diagram). Note that nothing in the “Web Server” tier contains sensitive information, just the mechanics to figure out who you are, what you are entitled to do, how to listen to you, and how to send you the answers to your questions.
The next tier, in the center of the diagram, is the Database Server, and as the name implies this is where your database lives. As new assets come into the system a record is inserted into the database to represent them. And as your team tags assets, it is here where the metadata information is stored.
The last tier in the diagram is the File Server tier, and this is where your actual digital assets are stored (be they native or TIFF or PDF, or whatever). Each record in the database “points” to the location of the original asset in the File Server, so if you need it, a copy of the original is just a click away (you can never edit the originals!).
There are other roles the system plays, but these are the main ones, and this is a “three tier” system.
So when you ask to see all the photos from a specific photographer, your web browser sends a request to the Web Server. The Web Server (Tier 1) decides if you are allowed to ask for these photos, and if so, it translates your request into a SQL (Structured Query Language) query and sends it to the database (Tier 2). The database returns back to the Web Server a record for each photo that matches your query, and each record contains a location of the original document. The Web Server looks at a template of how you like to see things, and starts building a web page to send back to you, using information from the database and asking the File Server (Tier 3) for any documents or thumbnail representations of the documents. Once the page it is building is complete, the Web Server tier sends it over the wire back to your laptop. And all this takes less than a second!
Next time we’ll discuss how this n-tier architecture can increase your ability to secure all of your digital assets.
Posted by David Tenenbaum
Flickr photo by torkildr