Using parent/child applications contexts in the Spring framework

The problem :
We would like to have an application that has two layers :
(1) a non-dynamic layer
(2) dynamic layer

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.

Practical Styles of Pair Programming

Real world experiences of a pair programmer. Gives practical tips for getting in the zone and good practices for navigators and drivers with concrete examples.

via Practical Styles of Pair Programming.

The third no-Sql meetup

This meet-up had some catch-up to do, because we couldn’t finish the “Apostate..” paper from the last meeting. In this meet-up we had a rather theoretical paper on “Byzantine generals problem” and the “Dynamo” paper (with much more implementation related information).

We didn’t had enough time to finish up the “Dynamo” so we had to postpone almost 2/3 of it for the next meet-up (next month).

This meeting had a little less attendance compared with the second one. Besides this it was full of energy (as usual) and people that truly wanted to understand. I had a great time.

James McLurkin – Swarm robotics

[Taken from : http://people.csail.mit.edu/jamesm/currentResearch.php]

Swarm Research

Robotics : The Next Generation
Much of the current robotics research aims to create practical robots that can function in today’s society. Through the advent of robots designed to perform certain human tasks, robots can be deployed for difficult and dangerous missions that may otherwise jeopardize human lives.

Swarm Reporting for Duty
To create robots that can explore caves, landmines or even Mars, the robots must be plentiful and autonomous. The Swarm, a fleet of 100 robots, runs on the Swarm Operating System (SwarmOS), which is based on distributed algorithms that allow the input or commands to be divided among multiple recipients. This software is also scalable, so that the number of robots in the swarm can increase or decrease without affecting the work accomplishments of the group. While a centralized system is easier to program and control, it is not readily scalable and thus does not react well if one member of the group fails to perform during the task. Distributed algorithms also set the platform for local communications among the robots so each can work independently toward achieving one common goal.

Mother Nature’s Secrets
As lead scientist at iRobot, McLurkin began the Swarm project in 1999 with colleagues Jim Frankel and Jennifer Smith. The aptly named Swarm was inspired by the biology of bees and ants, both swarm insects that are reproductive labors and work autonomously but toward a common goal such as collecting nectar. The Swarm was a progression of McLurkin’s robotic ants, which he built as a freshman at MIT. Software research for the Swarm was sponsored by the Defense Advanced Research Projects Association (DARPA) from 2002-2004.

Off To Work They Go
The Swarm project is a hardware simulation, in which the software is written and tested on a real swarm robot prototype. The five-cubic inch robots are equipped with light sensors, drive motors, a bump skirt and more. In deploying the Swarm, hands-free maintenance is crucial and implemented with Robot Ecology, a physical extra-structure composed of a beacon navigation, camera, testing station, and chargers to enable the Swarm to work at its optimal performance, sans direct human contact. The beacon navigation is a long-range navigation center that acts like a compass to inform the swarm where they are going” particularly used to direct the robots to the docking stations to charge. The beacon is turned to guide the robots in the correct path of the dock. The chargers along the docking station resemble the robots, so that the Swarm will be attracted to them when they need to refuel. It is critical that the chargers are hands-free, because it would be an overwhelming task to charge 100+ robots by hand” impeding work by the Swarm.

The Art of Communicating
LEDs, radio and audio serve as output to keep humans informed of what the Swarm is doing while at work. Illustrating feedback through these methods allows humans to watch the robots directly rather than study a computer screen to observe their actions or see if anything has gone awry. Human connection is made through the HIVE interface, a centralized system that collects data, debugs, turns them on and off, and controls their functions. During the tasks, certain robots can be designated as Swarm leaders to take on a higher post and delegate specific orders among the fleet.

The Swarm robots communicate with each other via lateral inhibition (a gradient communications system). Each robot has a unique serial number I.D. When the robots are working in a small group, the robot with the lowest number is usually appointed the leader and the other robots obey or disregard its message based on their own I.D. being higher or lower with respect to the number of the leader. The robots have a communications range of approximately three feet. Hence, they use other robots as landmarks to transmit information. The message will hop from the source to the targeted receiver, using the shortest range possible. The message is disregarded by the robots that pass the message along based on the number of each one’s I.D. with respect to the source.

LEDs signify the behaviors of the robots. The tasks/commands can be implemented as a primitive (single) being, duo or other numbers of groups. The robots clump to form distinct groups to execute specified tasks. Some examples of other typical commands are:

Orient to robot Follow the leader Cluster (robots group into same spot) Orbit robot Disperse uniformly Avoid robot In working with a fleet of robots, a multiple of navigational functions are necessary, because generally all the robots would not be sent to the same spot to do the same function. Instead different groups within the Swarm will be assigned to specific tasks to get the job done.Swarm Status Research on the Swarm is ongoing. Certain improvements that may be worked on are increased accuracy with the commands and the ability of the robots to travel in a straight line (when necessary). The Swarm represents the future of robotics and will help humans to accomplish otherwise daunting tasks.

Swarm Videos

Space Ship One

The incredible Space Ship One

See Burt Rutan TED Talk : Entrepreneurs are the future of space flight