The non-dynamic layer could include things like :
* database sessions
* mail services
* templating engines
* basic beans/components
etc.

As to keep things simple, a bean/component belongs to the non-dynamic layer if you are ok
with changing only through redeploys. The examples mentioned (ie. database sessions, etc.)
clearly belong to this category as we almost never want to change the database session settings
while the application runs.

The dynamic layer could include things like :
* configurable modules
* rule processing chains
* logging

The rule of thumb would be : anything that you might want to change while the application runs
(without any redeploy) would belong to the dynamic layer.

The Spring JAVA framework can help a lot with this. There are mainly 3 ways to do it :
(1) multiple hierarchical application contexts
(2) dynamic language support
(3) OSGI

The easiest (and best performing) solution is to use multiple hierarchical application contexts.

1. Creating hierarhical application contexts
The principle behind this is the fact that the Spring application context is similar to a
tree, builded from bottom up. As such every application context that we load (an XML file content
or just plain String) can have another application context as parent.

AbstractApplicationContext parentContext = new ClassPathXmlApplicationContext(new String[]{“classpath:META-INF/spring/applicationContext-job-sample1.xml”});
AbstractApplicationContext childContext = new ClassPathXmlApplicationContext(new String[]{“classpath:META-INF/spring/applicationContext-job-sample1.xml”},parentContext);

The fact that the tree is builded bottom up is a usefull metaphor to remember as it constrains the visibility of the application contexts (and the beans defined inside of them):
the child can see the parent, the parent cannot see the child. This makes sense as when the parent context was loaded, there was no child context available.
As such the visibility/scope is going only one way. You cannot use the parent context to get a bean from the child context. Only the other way around : use the child context to
get a bean from the parent context.

2. Managing multiple contexts – the simplest way to go
The easiest/cleanest way to work with this situation is to think of the child application context as a “second class citizen”. As such it can contain beans that
refer to the parent/stable context. Also you avoid cross-refering/cross-using beans from one child context to another (this is not possible through the Spring
context application loader, but it could be done trough different hacks in your code).
A good example of the child application context would be that of a job that gets configured as a chain of multiple resources/beans available in the parent :

[Parent context]
<bean id=”parentTask1 />
<bean id=”parentTask2 />
<bean id=”databaseSession” />

[Child context 1]
<bean id=”job1″ class=”com.example.Job” >
<util:list name=”tasks” >
<value ref=”parentTask1″ />
<value ref=”parentTask2″ />
</util:list>
<property name=”databaseSession” ref=”parentDatabaseSession” />
</bean>

[Child context 2]
<bean id=”job2″ class=”com.example.Job” >
<util:list name=”tasks” >
<value ref=”parentTask1″ />
<value ref=”parentTask2″ />
</util:list>
<property name=”databaseSession” ref=”parentDatabaseSession” />
</bean>

As you can see the child context just define “job plans”, which can be fancifull assemblies of existing parent beans.
Whenever you want to call a job (ie. by id) you just need to know in which child context was the job defined and then
use that particular context to instantiate the bean. The straightforward way to do this is to keep a Map<String,AbstractApplicationContext>
somewhere accesible in the parent context and whenever you add a new child context, update the map with all the beans from the child context
that you know you will need to call directly (ie. in the above example it would make sense to get all the beans that are an instance of the
com.example.Job class as I’m sure that I will call just job beans directly)

2.1 Load, Refresh & Close
The main reson why we want to have child application contexts is because we want our jobs to be flexible. As such we need to be able to create, update
& delete jobs without any redeploy.This is done straightforward in our situation :

Create a child application context :
AbstractApplicationContext childContext = new ClassPathXmlApplicationContext(new String[]{“classpath:META-INF/spring/applicationContext-job-sample1.xml”},parentContext);

Use the child application context :
Job job = (Job) chilContext.getBean(“job1″)

Refresh the child application context :
childContext.refresh();

Close the child application context :
childContext.close();
If you have some mechanism to update the child application context XML files, all you need to do is to refresh the child application (or close and
load them), and you get a new “version” of the jobs.

3. Pitfalls
First : Don’t cross reference beans from two different child contexts. What happens when you end up closing one of the contexts and the other one needs it?
Second : Don’t use beans from the child context in the parent context. You cannot do this through Spring directly, but you can still assign it through you code. When the child application gets closed or refreshed you will
still keep references from the old version.

The fact that this is possible (legally at least) opens up interesting opportunities towards creating an “exclusive” (but wholly legal) market for human body parts (as raw materials for exquisite recipes). I believe the steps would be the followings :

1. the body part – from the person to property : it is a matter of routine that a certain percentage of accidents and illnesses require certain body parts to be amputated (ie. legs, arms, etc.) or internal organs to be removed (ie. lungs, parts of the liver, kidney, etc.); once the body part is separated from the body, it is no longer part of the “holy legal sanctity of the person” and becomes just property (more precisely : the property of the former person). As such it seems pretty reasonable (at least legally) that people can hold those ex-body/person parts at home, as many of us hold artifacts/souvenirs of past people and places.
2. the property –  from body part to object : as the body part is no longer (legally at least) part of the person, it loses any kind of protection that “people” have and it’s now protected by the laws regarding “ownership”; as such, it can become insured (as an object and not as part of the former “person life insurance”) against theft or damage and also the owner can dispose of it in the way of the object : it can eat it alone, it can share it with friends or it could even exchange it for other human body parts or money

As a developer I read & worked it out in the following way :

1. Installing the server and testing the Mongo basics – Ch. 1,2,3,4 – (it’s good practice to write small pieces of code to check how the things you read work out)

• installed MongoDB with my Linux package manager (I have Ubuntu, but the MongoDB server is available in most major Linux distributions as a package) – check Appendix A for a detailed way to install Mongo and Ch. 8 – part 1 for starting/stopping it
• read chapters 1-4 (Introduction, Getting started, CRUD, Querying)

In the first 4 chapters the book focuses both on practical things like CRUD & querying (with sample code in the console) & on the data design part. I found that the data design part to be of considerable importance for the developer that works with a “document based” database for the first time in his life. As you will see (if you give Mongo a try), MongoDB pushes the the “document based” model to the limits, allowing the developer to use a powerfull and sometimes SQL-like query language. In terms of time I believe that understanding the first four chapters (and their examples) should not take more than 12 hours. After you finish this you should be able to build a small blog-like app on your own.

2. Getting into aggregation & indexing  – Ch. 5,6 : gives a good insight in how to optimize your Mongo for speed (with the right indexing) and some more information on ways to use aggregated/summarizing queries. This is also a good read but make sure you have some data in your test database so you can test counting, summing & the rest. If you have some experience with SQL indexing and aggregation you can skip most parts of those two chapters and just focus on the syntax.

3. The advanced topics : This is covered in Ch. 7 and shows off some “cool” and rather unique capabilities of Mongo : capped collections (great for logging), distributed filesystem, server-side scripting (in Javascript!). This is also worth your reading so that maybe you can implement the features you need with them, instead building something from scratch.

In total, it would take you around 20 hours to read the first 7 chapters.

As a server administrator (some developers for large scale system will also need to wear this hat from time to time) The last 3 chapters deal with administration (clustering, replication, backup, monitoring, etc.). Read it just to get some insight. But it’s just an intro. If you want to use Mongo in a production environment, go search more on the net on this one.

As a whole the book is a very good introduction and I would strongly recommend it to anyone who wants to seriously start doing something with Mongo.

• Ch4. “The CDN Model” : an accessible presentation of the architecture and role of a CDN and why you can’t beat the CDN model with your local server rack
• Ch5. “Caching and load balancing” : the most valuable thing here is the detailed presentation of the META tags used in requests & responses so that you can control how caching is done both upstream/request and downstream/response

The last 2 chapters are a little bit less technical and cover stuff that’s more related to the business model and gathering statistics from your CDN usage (ie. logs & monitoring). So I would recommend that you focus on Ch4. & Ch5. and if you got some slack, give Ch6. and Ch7. a try.

Such services are readily available on the  web today, free of charge, but with a limited number of calls/time unit. So, if your application needs this at a larger scale (ie. 100k calls/day), then you might need to do it on your own. In this post I will discuss some ways to build such a system.

Basic functional characteristics :

1. it involves mostly reads (99.9999% reads & 0.0001% writes)
   - usually the IP 2 Geo database gets updated once per month
   - having stale data is no problem (on short periods of time)
2.  it has to scale really big & perform really well
   - every potential web visitor will hit this service at least once => this service is one of your first possible bottlenecks
   - this hit will probably happen at the first page load => it has to be fast (so that it doesn’t affect the page load time)
3. it should store more than just a latitude/longitude pair
   - it would be nice to have more information stored for every IP : city, region, country, weather code, connection speed, etc.
   - this should be stored in a document structure that is easy to read and maintain (ie. JSON, etc.)

This would clearly be the most simple and straightforward solution. The IP number can be converted in a directory structure just

by replacing the DOTs with a SLASH, like : the IP 110.111.112.113 would be transformed in the filesystem path /110/111/112/113.txt.

Storing things in this way would us to use the basic filesystem tools  to add/change/remove entries and also we could use the classic

FTP, rsync, etc. tools to replicate changes across multiple servers. As such there is almost no “fancy” technology & administrative

skills needed to build & maintain such a system. Also there would be little “application level overhead” because we would work directly

with OS level system calls (ie. the POSIX filesystem calls).

The problem :

There are 2^32 IP addresses out there (assuming you want to resolve good old IPv4 addresses) and that means you would need

to have 4 billion files on your filesystem. And this just doesn’t work!!! Most advanced filesystems (ie. ext3, xfs) just perform terribly for anything that

goes above 100 million files. And we are almost 2 orders of magnitude above that (we need > 40x that number). Also, if you encounter filesystem corruption (ie. servers loose power, etc.) the filesystem recovery process will just take hours and hours to finish.

Storing the IP entries on a CDN
This would be a quite elegant solution, especially for high volume traffic. Every IP entry would be stored as a 500bytes file and the name of the file would be

the IP address itself. As such, an IP adress like 110.111.112.113 would be translated into a CDN file request like : http://mycdn.mydomain.com/ip/110-111-112-113. At the origin we would have a container that stores those entries with a TTL of 1 month. Every month we could run a script that refreshes some of those entries at the origin level and that’s it. The price would also be extremely low on a CDN with a bandwidth based pricing model. If every geo request takes around 1KB of bandwidth (including the headers and everything) then you would consume 1 GB of traffic in 1 million requests.

The problem :
No CDN will actually allow you to store more than 10 million of files (for example Rackspace Cloudfiles limit you at 5 million files). And we are almost 3 orders of magnitude above that.