The Kitchen in the Zoo - architecture tag

Playing with Cache Performance

Thu, 30 Dec 2010 21:43:00 GMT

My current client has a service which connects to an old IBM z/OS application (legacy system). The data centre charges for each message sent to this legacy system, rather than using a processor or hardware based pricing model. The output from this legacy system is always the same, since the calculations are idempotent. The application calculates prices for travelling along a given route of the train network. Prices are changed only twice a year through an administration tool. So in order to save money (a hundered thousand dollars a year), the service which connects to this legacy system had an in-memory least-recently-used (LRU) cache built into it, which removes the least recently used entries when it gets full in order to make space for new entries. The cache is quite large, thus avoiding making costly calls to the legacy system. To avoid losing the cache content upon server restarts, a background task was later built to periodically persist the latest data inside this cache. Upon starting a server, the cache content is re-read. Entries within the cache have a TTL (time to live) so that stale entries are discarded and re-fetched from the legacy system.

This cache was great in the beginning because it saved the customer a lot of money, but in the mean time several similar caches have been added, as well as more general caches for avoiding repeated database reads, causing our nodes to need over 1.5 GB of RAM. Analysis has showed that the caches are consuming over 500 MB alone. The platform is WebSphere and IBM only recommends running with 512 MB per node... So as you can see, we are on the road to having some memory issues. In order to avoid these issues, and potentially also save money by requireing less hardware for our applications, I have taken time to think about possible architectures which could solve the problems.

One of the problems is that the cache is an internal part of the service, i.e. it is a glorified Map referenced as a singleton. That means, each node has its own cache instance. Worse actually, because of the class loaders in application servers, each application has its own instance of the service and hence its own instance of the cache, and because the service is deployed per application, each cache exists multiple times per node in the cluster. The result is an architecture as follows, where there are for example 8 instances of the same cache:

While these in memory caches are quick, that is not the main reason for having created them. The main reasons were to avoid hammering either the database or the legacy systems with repeated queries which result in the same outcome. While the caches theoretically speed up the the applications, the associated increase in garbage collection might actually result in lower overall speed because the garbage collector needs to run more frequently because there is less memory available for use by the application itself, because the caches consume so much.

This got me thinking about creating a centralized cache, of which there is one single instance for use by all applications. The architecture would then look like this:

The requirements for the cache are:

Persistent, so that server restarts do not cause all content to be lost,
Single, so that the entire landscape contains just one cache rather than the same data being cached lots of times as it is today,
Relatively fast,
No impact on existing infrastructure, i.e. if we stick our cache into our database, that influences the reading/writing of other data by making the database perform less well.

So, what are the options for creating such a cache?

In Memory, but remote, backed by persistence, similar to what we have today, only with the service deployed as a remote EJB, rather than being called locally,
A bigtable style, NoSQL cache, because they are based on key/value pairs and can handle lots of data,
LDAP, because LDAP is persistent as well as optimised for read access.

A fourth option might be to use a database cache, i.e. a table devoted to key/value pairs cached in the database, which gets read every time you need data, but this would affect overall database performance, so isn't really an option. I have however included such a solution in the solutions that I tried below, simply to compare performance.

While the concept of a bigtable style database is aimed at large amounts of data (billions of rows and millions of columns), what is of interest in this case is that it is based on key/value pairs, which is exactly what we need for our cache. The caches used today are LRU caches, because to store all possible data would require too much memory (there are millions of routes on the train network), which is also the reason why we wouldn't want to store all possible routes in the database. However, because a bigtable style database supports large data sets while maintaining performance, we can potentially just let it contain all possible routes. The strategy for filling such a cache would be to check the cache for the required entry, if it doesn't exist, to then query the legacy system, and its answer be cached for future use, until it becomes stale.

So first things first, I started up Glassfish for Eclipse and MySQL to do some tests. I created a set of tables to contain 100,000 train stations, generated randomly. Then I added 100,000 random routes, each containing between 3 and twenty stations. It is these routes which the legacy system calculates prices for. The first solution I implemented was a pure database cache, where a query to the service which encapsulates the legacy system first checked if the database contained a cache entry for the key, made up of the "from" station and the "to" station codes. If there was no hit on the cache, the legacy system was queried and its result was cached. I filled the cache with all 100,000 routes and began making measurements. My first results were rather poor, with requiring several hundred milliseconds to read from the cache, even though the cache key was the primary key, that is indexed! OK, the test system was my aging IBM T60 Intel Core Duo (2 core CPU) laptop with only 2 GB RAM, running Windows XP, Glassfish, MySQL, and a handful of other (memory intensive) applications and services.

I started reading up about Cassandra, the Apache application based on bigtable, and in the performance tuning section it mentioned about using two disks for seperate files which it writes. That made me think about what was going on on my laptop and I realised that one reason why my first solution was so slow was that I was running applications using over 2 GB of RAM, so I was well into the region where the OS was using virtual memory and swapping from RAM to disk continuously. Sure enough, during tests, my hard disk light was going crazy. I have been wanting to upgrade this laptop for a while, but it belongs to the client, so I cannot really upgrade it. But I did a little more reading and decided to try out a USB 3.0 external hard disk (500 GB "My Passport" from Western Digital), together with an Expressbus USB 3.0 adapter. This gave me a very fast external hard drive. Random read/write tests showed that this external hard drive was actually up to three times faster than the internal one!

So, I got back to testing, and installed my apps (Glassfish and MySQL, etc) on the external hard drive, leaving the internal harddrive for the OS and disk swapping. In the ideal world, one would do this the other way around and install an SSD for the OS and its swap file, leaving a slower more conventional spinning hard disk for applications and data. Anyway, instead of a single drive having to try to do swapping and reading of say the database simultaneously, this configuration let the internal drive handle swapping, while the external drive handled reading for the database, basically allowing parallel tasks.

Sure enough, I was able to get random cache read times for this database cache, down to 15 milliseconds. It still wasn't that fast, but interestingly, this database was doing nothing else at all, simply servicing cache reads (i.e. reads out of a single table with a cache key as the primary key, and a varchar for the value (a serialised Java object). Since this solution influences the existing infrastructure, i.e. the database, it would not fulfil the requirements I created earlier in this post.

I next downloaded Cassandra from Apache, and read a few introductions like the ones here and here.

What I wanted to do was not complex at all, so I created a structure with a single ColumnFamily (like a table). I filled it with all 100,000 routes, and started performance testing, and got average read times similar to MySQL. I read up a little more about performance tuning and I discovered that I could control the number of entries cached in memory inside Cassandra. I set this to be 99% and sure enough, my results improved to the point that after a few hundred thousand reads (which would happen fast in production), I was getting read times of around 2 milliseconds. Cassandra was running as a single process on the same laptop on which GlassFish was running, which contained a service which wrapped calls to Cassandra. The data structures were simple with each cache entry stored within a single key in Cassandra, basically having a single column for the ColumnFamily, containing the serialised route object.

Further reading introduced the idea that Cassandra is optimised for reading many columns within a single "row" (key). I tried restructuring the data so that the key for each "row" was the "from" station code, and for each destination from that station, a column was added within the row. So I had many less keys in Cassandra, but many more columns per row. And because these bigtable solutions do not require each key to have identical columns, allowing sparsely filled tables, it was perfect for this restructuring.

I refilled the cache using this new structure, and sure enough, once Cassandra had loaded a few hundred thousand keys and they were all cached in its memory (set at 256 MB for the process), average random read times sank to just 1 millisecond. Compared to MySQL things were looking good.

Time for the next proposed solution, which was to make calls to a remote EJB running in its own node (or rather cluster). I implemented this by creating a simple stateless session EJB which contained a static reference to a Hashtable (so that it was thread safe). I didn't bother implementing the persistent part in the first instance, because I was interested in how long it would take to simply call the remote EJB and do the lookup in the Map. I deployed the EJB to Apache OpenEJB running as a simple process on the same laptop and after filling the cache completely, the average time for random reads was around 2 milliseconds, i.e. similar to Cassandra, albeit a tiny bit slower.

The final option was to try out LDAP. I only considered this because LDAP is optimised for reading, which is what this service is doing. I used ApacheDS that also as a process on my laptop. I filled LDAP with my 100,000 routes by basically filling my organisation unit with new sub-organisational units per key, with the Base64 encoded serialised object attached to the sub-OU as an attribute, such that the cache entry had a URL like ldap://localhost:10389/ou=8500101_8500103,ou=verbindungen,ou=system. Sadly I am no expert on LDAP and was not too sure how to optimise it, beyond increasing the cache size attribute of the system partition in server.xml inside ApacheDS. The results were far from promising with average random read times around 50 milliseconds.

In all cases, I optimised my code so that connections to the remote processes were created post EJB construction, and just once, until the EJB instance was destroyed (using the @PostConstruct EJB 3 annotation). In all cases, the average read times were measured per cache entry, based on 1000 random serial cache reads, after reading over 100,000 entries to ensure that the external process had had time to optimised its own in memory key cache.

The results are summarised as follows:

Solution	Average Read Time
MySQL Cache table	15 ms
Cassandra	1 ms
Remote EJB	2 ms
ApacheDS LDAP	50 ms

The nice part about using Cassandra would be that we don't have to write the code for this cache, nor maintain it. Additionally, there are other areas within our landscape that could make good use of a bigtable style solution because the amounts of data are getting very slow to handle, so it would be useful to start getting to know the new world.

The not so nice part about Cassandra, is that it is not standard software at this client. We would need to create a request for architecture and invest time convincing some enterprise architects that we need Cassandra and that our platform people and data centre should invest in order to support it. This could end up involving software evalutations and eventual licence costs if they chose a commercial solution. All this effort could easily cost more than we could possibly save by implementing a single cache in order to reduce the amount of hardware required today. Politics are great, eh :-| I shall be putting the proposals forward in the new year, let's see what they bring.

One quick final note: the times measured here are not realistic of the target environment - a laptop doesn't compare to a cluster! But they can be used as relative indicators to suggest which solutions might be worth further investigation. Only final deployment to production can give the real answer, as shown by this example, although just because Digg had problems, doesn't mean Cassandra is bad. It does show that you need to think long and hard about your architecture though.

Copyright © 2010 Ant Kutschera

Social Bookmarks :

DCI and Services (EJB)

Sat, 20 Nov 2010 21:29:00 GMT

Data, Context and Interaction (DCI) is a way to improve the readability of object oriented code. But it has nothing specific to say about things like transactions, security, resources, concurrency, scalability, reliability, or other such concerns.

Services, in terms of stateless EJBs or Spring Services, have a lot to say about such concerns, and indeed allow the cross-cutting concerns like transactions and security to be configured outside of the code using annotations or deployment descriptors (XML configuration), letting programmers concentrate on business code. The code they write contains very little code related to transactions or security. The other concerns are handled by the container in which the services live.

Services however, constrain developers to think in terms of higher order objects which deliver functionality. Object orientation (OO) and DCI let programmers program in terms of objects; DCI more so than OO. In those cases where the programmer wants to have objects with behaviour, rather than passing the object to a service, they can use DCI.

If objects are to provide rich behaviour (ie. behaviour which relies on security, transactions or resources), then they need to somehow be combined with services, which naturally do this and do it with the help of a container, so that the programmer does not need to write low level boiler plate code, for example to start and commit transactions.

The idea here, is to explore combining a service solution with a DCI solution. Comparing SOA to DCI, like I did in my white paper, shows that the DCI context is analagous to the code which calls a service in a SOA solution, and that a context does not really explicitly exist in a SOA solution. However, thinking a little more abstractly, in DCI an encapsulation of behaviour would be the context together with its roles. In SOA, this encapsulation is the service itself. So it is possible to realign the ideas in that white paper, to think of a context as being a service. If the goal is to create a hybrid between services and DCI, so that all of the concerns listed at the start of this article get handled by a hybrid solution, then the roles still exist as they do in DCI, but the context becomes a "service" in the technical sense.

Time for an example. Imagine a train company which owns electrified tracks along which trains run. They have a business partner who provides the electrical energy, who is offering cheaper energy to consumers who can forecast their energy consumption so that the partner can make their production more efficient. To deliver these forecasts, the train company checks the timetable for regular passenger transport, as well as all its cargo contracts for bespoke cargo trips. This allows them to simulate all train trips for a given time period and calcuate the energy requirement. Now, the company is a national one, and has thousands of kilometers of track and hundreds of trains running. They have created detailed maps of the terrain over which their tracks run, so they know the uphill and downhill segments and their power consumption changes. They want to build some simulation software to handle the forecasting. At the same time, there is a non-functional requirement to complete calculations extremely quickly, so rather than making them sequential, a parallel solution is required. Here is the proposed object model:

Trip: Consists of a Train and a list of TripSegments.
Train: consists of a list of Locomotives, and a list of Wagons. The assembly of a train comes from the Timetable.
Locomotive: Has an efficiency, a weight and rolling friction factor.
Wagon: has a weight and rolling friction factor.
TripSegment: has a Segment, and the average speed along which the Train will travel on that segment, during its trip.
Segment: a stretch of track, which has a length, positive hill climbs and negative hill decents. Has a starting station and an end station, which are not relevant to the energy calculations - it is the distance which counts.
Timetable: a service which provides all Trips for a given time period.

In order to make each trip be calculated in parallel, I have chosen to use a feature of EJB whereby the container creates a new thread and does the calculation on that thread. It means with a simple annotation on a method, I have almost no boiler plate code to write! In order to use that annotation, my context needs to be an EJB, but seeing as the application is running in an enterprise Java application server anyway (so that I can for example have a nice website as a front end), this is no big deal.

So, the architecture of this solutions is: a web request to run the calculation is received which makes a call to my process layer (aka application layer). The process layer calls the timetable to get all trips for the requested period, and for each trip it calls the context to do a calculation in parallel. The process layer waits for all calculations to complete and returns the result to the web layer to present the results to the user. Here is the context:

@Stateless
@Context
public class ForecastingContext implements ForecastingContextLocal {

	/**
	 * an asynchrounous method for determining the energy requirements of the given trip.
	 */
	@Asynchronous
    public Future forecastEnergyRequired(Trip trip) {

		BehaviourInjector bi = new BehaviourInjector(this);
		
		//the context simply casts objects into roles, and starts the interaction
		EnergyConciousTrip t = bi.assignRole(trip, EnergyConciousTrip.class);
		double energy = t.forecastEnergyRequirements();
		
		return new AsyncResult(energy);
    }
}

The context does nothing special, apart from contain the @Asynchronous annotation which tells the container that calls to this method need to occur on a new thread. Unlike perhaps more standard DCI, this context has no constructor which takes objects which will play roles, rather the interaction method "forecastEnergyRequired" is passed the object which gets cast into a role. The reason is that I have no control over the instantiation of the context, because it is an EJB, meaning that the container does the instantiation for me!. I have not sub-classed BehaviourInjector (which is an option in my framework), because stateless EJBs can be called by multiple threads at the same time, and BehaviourInjector is not thread safe.

Here are the two roles:

/**
 * this role is played by a trip so that it is able to 
 * give a prediction about how much energy will be 
 * needed to undertake the trip.
 */
@Role(contextClass=ForecastingContext.class, 
		implementationClass=EnergyConciousTrip.EnergyConciousTripImpl.class)
public interface EnergyConciousTrip {

	double forecastEnergyRequirements(); //role
	List getTripSegments(); //data
	Train getTrain(); //data
	
	static class EnergyConciousTripImpl{ //role implementation
		
		@CurrentContext
		private IContext ctx;
		
		@Self
		private EnergyConciousTrip self;

		/**
		 * energy consists of a longitudinal component (ie along the track due to 
		 * aerodynamic forces and rolling resistance) as well as altidudal component
		 * (ie due to climbing or descending).
		 * 
		 * E = mgh //ie potential energy for climbing / descending
		 * E = Fd  //ie energy required to overcome resistive forces
		 */
		public double forecastEnergyRequirements(){
			
			//give the train some scientific behaviour and determine
			//its total weight and average efficiency
			ScientificTrain train = ctx.assignRole(self.getTrain(), ScientificTrain.class);
			double totalWeight = train.getTotalWeightKg();
			double avgEff = train.getAverageEfficiency();
			
			//add up all energy per segment
			double energy = 0.0;
			for(TripSegment seg : self.getTripSegments()){
				
				double segmentEnergy = train.getResistanceForce(seg.getSpeed()) * seg.getSegment().getLengthMeters();
				
				segmentEnergy += totalWeight * seg.getSegment().getAltitudeChange();
				
				//each locomotive can pull, but has an efficiency which needs to be factored in!
				//it needs more energy than just pulling wagons, because its inefficient
				segmentEnergy /= avgEff;
				
				energy += segmentEnergy;
			}
			
			return energy;
		}
	}
}


/**
 * played by a train, when it needs to provide scientific details about itself.
 */
@Role(contextClass=ForecastingContext.class,
		implementationClass=ScientificTrain.ScientificTrainImpl.class)
public interface ScientificTrain {

	double getResistanceForce(double speed); //role
	int getTotalWeightKg(); //role
	double getAverageEfficiency(); //role
	List getWagons(); //data 
	List getLocomotives(); //data
	double getDragCoefficient(); //data
	
	static class ScientificTrainImpl { //role impl

		@Self
		private ScientificTrain self;

		/** 
		 * resistance force is the rolling friction as a 
		 * result of weight, as well as aerodyamic drag.
		 */
		public double getResistanceForce(double speed){
			double resistanceForce = 0.0;
			for(Wagon w : self.getWagons()){
				resistanceForce += w.getWeightKg() * w.getRollingFriction();
			}
			for(Locomotive l : self.getLocomotives()){
				resistanceForce += l.getWeightKg() * l.getRollingFriction();
			}
			
			resistanceForce += speed * speed * self.getDragCoefficient();
			
			return resistanceForce;
		}

		/** total weight of wagons and locs. */
		public int getTotalWeightKg(){
			int weight = 0;
			for(Wagon w : self.getWagons()){
				weight += w.getWeightKg();
			}
			for(Locomotive l : self.getLocomotives()){
				weight += l.getWeightKg();
			}
			return weight;
		}

		/** average of all locs in the train */
		public double getAverageEfficiency(){
			double avg = 0.0;
			for(Locomotive l : self.getLocomotives()){
				avg += l.getEfficiency();
			}
			return avg / self.getLocomotives().size();
		}
	}	
}

There is nothing fancy in these roles - simply the engineering calculations to work out the energy requirements. I have chosen to implement the role implementations inside the role interface, but there is no reason the role implementations could not exist in their own classes.

Finally, here is the process layer:

@Stateless
public class EnergyForecastingService implements EnergyForecastingServiceLocal {

	@EJB
	private TimetableLocal timetable;

	@EJB
	private ForecastingContextLocal forecastingContext;
	
	@Override
	public EnergyRequirementResult forecast() throws InterruptedException, ExecutionException {
		
		long start = System.nanoTime();
		List> results = new ArrayList>();
		EnergyRequirementResult result = new EnergyRequirementResult();
		result.setTrips(timetable.getTripsForPeriod(null, null));
		for(Trip trip : result.getTrips()){
			//start it in a parallel thread
			//it will be simulated using a DCI context...
			Future e = forecastingContext.forecastEnergyRequired(trip);
			results.add(e);
		}
		
		//ok, all started, lets wait until all are done...
		result.setEnergyRequirement(waitForResults(results));
		result.setCalculationTimeNs(System.nanoTime() - start);
		
		return result;
	}

	private double waitForResults(List> results) throws InterruptedException, ExecutionException {
		double energyRequired = 0.0;
		while(!results.isEmpty()){
			List> assimilated = new ArrayList>();
			for(Future result : results){
				if(result.isDone()){
					assimilated.add(result);
					energyRequired += result.get().doubleValue();
				}
			}
			results.removeAll(assimilated);
			
			//lets give CPU time to other threads while we wait...
			Thread.sleep(5L);
		}
		
		return energyRequired;
	}
}

The process layer uses these funny "Future" objects which allow it to not only get the result from a calculation which has run on another thread, but also to query whether that thread has completed or is still running. The only boiler plate code needed to handle this multi-threaded code is analysis of results while waiting for them all to complete.

The context and its roles look like this:

One interesting side point, is that the EnergyRequirementResult is a class in the context's package (namespace), because it only makes sense to create it from the context. It can be used outside of the context as a read only object to read the results, but it is strongly coupled to the context. It doesn't really make sense for it to exist without the context, and thinking in terms of components, or code re-use, it makes sense to place it in the same namespace as the context. The context and its roles, are afterall a component which can calculate energy requirements - they encapsulate the behaviour to do this.

It might look strange that the behaviour is not simply added to the train and trip objects. But it's hard to see the benefits when looking at such a small project. Imagine a huge project where the object model is much more complex, and there are many many more use cases. If you look at the object model in this example, the train and timetable can be used in many more applications than just one which does energy predictions. Typically within an enterprise, we keep rebuilding similar object models with relevant parts of data, and differing behaviours for each OO solution. DCI lets you build a large single object model, with behaviours constrained to the contexts in which they are relevant. This allows the data model to become sufficiently complex to make it usable within the entire enterprise, but not so overly complex that making changes to it breaks it. Of course it is also arguable, that things like drag coefficients and rolling friction coefficients have no place in an object model of an application related to passenger load planning or whatever else the enterprise needs to do. In terms of making applications flexible to change, it can help if each application has its own object model, even if it results in code duplication within the enterprise.

In this example I have turned my context into an EJB, because I want to take advantage of boilerplate code which the container can handle for me - in this case concurrent computing. Similarly, if my context needs resources, transactions, security, etc, I would use an EJB for my context, and pass the resources which the container injects into it, into the roles using my BehaviourInjector framework (see its documentation for details). I have solved the banking example used in many DCI articles, by making the contexts EJBs, letting the container handle transactions, and getting hold of the EntityManager (for interacting with the database) by letting the container inject it into the context, which the BehaviourInjector can in turn inject into roles.

If contexts are to be "services" in the technical sense, it also makes sense for an enterprise to build a context repository to sit along side their service repository. These are places for software people to look, when needing to see if problems they face have already been solved. Just as we have tools for searching service repositories and we create documents to list all our services, we will need to do the same for contexts, if DCI is to really be adopted by the enterprise world.

It's important to remember that you could build this solution with pure services, or pure OO. DCI is simply another, and valid way of solving the problem, which concentrates on separating the behaviour from the data in order to make the code more reviewable, while at the same time remaining object oriented, so that the model which the users and customers have, stays similar to that which the programmer uses. Is creating roles and injecting behaviour into the Train and Trip objects better than putting those methods into a service which does the same thing? I don't know... It is certainly less OO, but is that a bad thing? Perhaps its just down to designers choice and feeling comfortable with the resulting code. So long as reading the solution compares to the users and customers stories, that is the important thing. Mappings between the users/customers world, and the programmers world are unnecessary and cause bugs as well as unsatisfactory users, because the programmer concentrates on solving his problems, rather than the business' problems.

You can download all the source code for this train app from here.

PS. I have no idea if train companies need to forecast energy requirements, or even if they work with energy partners. The creativity of this blog article should not hamper the readers understanding of how to create a service/DCI hybrid, in order to benefit from the way a container handles the concerns listed at the start of this article!

© 2010 Ant Kutschera

Social Bookmarks :

DCI Plugin for Eclipse

Tue, 16 Nov 2010 20:58:00 GMT

The Data, Context, and Interaction (DCI) architecture paradigm introduces the idea of thinking in terms of roles and contexts. See some of my white papers for a more detailed introduction into DCI, but for this blog article, consider the following example: a human could be modelled in object oriented programming by creating a super huge massive class which encapsulates all a humans attributes, their behaviours, etc. You would probably end up with something much too complex to be really maintainable. Think about when a human becomes a clown for a kids party; most of that behaviour has little to do with being a programmer, which is a different role which the human could play.

So, DCI looks at the problem differently than OOP and solves it by letting the data class be good at being a data class, and putting the behaviours specific to certain roles into "roles", which in my DCI Tools for Java library are classes.

Certain roles interact with each other within a given context, such as a clown entertaining kids at a birthday party. The roles which belong to an interaction are part of the context, and in DCI the context is a class which puts data objects into specific roles, and makes them interact. The context and its roles form the encapsulation of the behaviour.

I have updated my library, so that there are two new Annotations, namely the @Context and @Role annotations. The @Context annotation is simply a marker to show that a class is a context. The @Role annotation is more important. It is placed onto the role interface class and tells the context where to find the role implementation, and additionally requires that the programmer specifically state to which context the role belongs.

The code ends up looking looking as follows. First a unit test which creates and calls the context:

    @Test
    public void testExecute() {
    	
    	//create an adult (the clown) and some children, 
    	//and let the party start...
        
    	Human adult = new Human();
        List children = new ArrayList();
        Human child = new Human();
        child.setName("Johnny");
        children.add(child);
        child = new Human();
        child.setName("Jane");
        children.add(child);

        ClownContext cc = new ClownContext(adult, children.toArray());
        cc.startParty();

        //check the party went well...
        assertEquals(0, adult.getHappiness());
        for (Human c : children) {
            assertEquals(1, c.getHappiness());
        }
    }
}

There is nothing special about the code above. It simply creates some data objects and passes them to the context, and then starts the party (the interaction, or use case). Next, the context class is shown:

/** the context in which a clown entertains some kids. */
@Context
public class ClownContext extends BehaviourInjector {

    /** the object who will play the clown role */
    private Object adult;
    
    /** the objects who will play the kid role */
    private List children;

    /**
     * Creates a new Context object. takes "objects" rather than specific types to allow it to be reusable.
     */
    public ClownContext(Object adult, Object[] children) {
        this.adult = adult;

        this.children = new ArrayList();

        for (Object child : children) {
            this.children.add(child);
        }
    }

    /** start the interaction */
    public void startParty() {
        Clown clown = assignRole(adult, Clown.class);
        
        clown.applyMakeup();

        IIterable kids = getIterable(children.iterator(), Kid.class);

        clown.makeKidsLaugh(kids);
    }

}

The context has a few noteworthy points. First of all, it extends the BehaviourInjector. By doing this, it has access to the assignRole(Object, Class) and getIterable(Iterator, Class) methods. Note the @Context annotation at the top - it's important for not only helping the programmer spot that it's a context, but also for the Eclipse plugin which I created and which I introduce below.

You might have spotted that the context above is not tightly coupled with the Human class. The reason is simply to make the context and its roles usable in the future, with data classes which I currently know nothing about. It is feasible that a robot might one day do parties by dressing up as a clown!

Assigning the role is where the behaviour is "injected" into the data object. The iterable which is created is a special role, which can automatically cast the human children into the role of a kid attending a party.

Next, take a look at the role interface. This class defines the methods which data object must have to play the role, as well as the behaviour which will be added to the object.

@Role(contextClass = ClownContext.class, 
	  implementationClass = ClownImpl.class)
public interface Clown {

	/** put some makeup on (initialise) */
	public void applyMakeup(); // role

	/** makes kids laugh */
	public void makeKidsLaugh(IIterable kids); // role
	
	public void setHairColour(Color c); // data
	
}

The role interface has the @Role annotation which tells the behaviour injector firstly to which context the role belongs, and secondly where the actual implementation (behaviour) can be found. In the clown role specified above, two behaviours are added (applying make up and making kids laugh). The application of make up additionally requires that the clown be able to set his hair colour, so that method which the human class must have is also specified here.

Finally, the role implementation class:

public class ClownImpl {

	@Self
	private Clown self;
	
	/** @see Clown#applyMakeup() */
	public void applyMakeup(){
		self.setHairColour(Color.GREEN);
	}

	/** @see Clown#makeKidsLaugh(IIterable) */
	public void makeKidsLaugh(IIterable kids) {
		for (Kid kid : kids) {
			kid.laugh();
			System.out.println();
		}
	}
}

The role implementation does not need to implement the role interface! It is simply a class which the behaviour injector relies upon to find behaviour which it cannot find in the data object. The @Self annotation on the clown field called self is a reference to the object playing the clown role, and is similar to "this", just that "this" would be a reference to the instance of the role implementation, rather than the object playing the role. It allows you to access the data methods of the data object.

Now, as well as helping the programmer to mentally associate contexts with roles, these two annotations allow static analysis of the code to be performed. Using the Eclipse JDT framework, it is possible to obtain individual tokens of source code, even when the class files don't compile, in order to build up a model of contexts and roles within a Java project. I created a little DCI Outline view for Eclipse, similar to the class outline, except rather than showing classes, it shows the contexts and their associated roles. Here's a screen shot:

The view shows all contexts which it finds in the selected Java project. For each context, it shows the package, followed by a list of its methods, and then all the roles that belong to it.

For each role interface, the package is listed, followed by a list of methods which the role interface contains. At the bottom of a role branch, is the role implementation class.

The idea of this plugin is to give the programmer a view of what contexts are available and what roles they contain. It puts contexts, roles and their methods into the mind of the programmer letting them think in terms of DCI, exactly the same way which a standard class browser lets the programmer think in terms of classes.

Double clicking on a role interface, role implementation or context will open it in the editor.

The plugin has limited validation capabilities and can determine for example, if a context specified in a role annotation cannot be found within the project, and highlights this so that the programmer can see there is a problem. In such cases, the view looks like this:

The code from this example can be downloaded here.

A full instruction manual, together with the the DCI Tools for Java library, and the Eclipse Update site can be found at here.

Attention: No clowns were harmed during the writing of this blog.

© 2010 Ant Kutschera

Social Bookmarks :

User Mental Models

Mon, 01 Nov 2010 22:04:00 GMT

I've spent the last 6 weeks looking into an interesting paradigm called Data, Context & Interaction (DCI).

I've written a few introductory papers, and some tools too.

DCI has the following goals:

To improve the readability of object-oriented code by giving system behavior first-class status;
To cleanly separate code for rapidly changing system behavior (what the system does) from that for slowly changing domain knowledge (what the system is), instead of combining both in one class interface;
To help programmers reason about system-level state and behavior instead of only object state and behavior;
To support an object style of thinking that is close to peoples' mental models, rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages.

The problem recognised by this paradigm is that system behaviour gets fragmented in traditional OOP, over a large number of classes and sub-classes. The code directly related to a use-case gets fragmented and "lost". The boundaries for the behaviour end up being class boundaries and pieces of behaviour are stuck with the data on which they operate, so that the code has high cohesion. If you want to read the code related to a use-case, you will struggle to extract it and understand it. I agree with these problems, but have not really encountered them personally for a long time, because I do most of my work predominantly in the SOA paradigm.

When I first read these goals and all the articles I could find about DCI, I interpreted them as roughly:

Separating system behaviour from data, to give behaviour first class status;
Allowing the programmer's mental model to become the same as the user's mental model and hence reduce the number of mappings between programmer's and user's mental models;
Making code use-case centric, rather than class- or data-centric;
Making code reviewable and having less reliance on testing, by keeping fragments of use-case code physically close so it's not fragmented.

I thought about these interpreted goals hard, because I was convinced that in the applications I help to write, we were achieving them. I questioned the DCI forums at length about why a SOA architecture couldn't achieve these goals. When I say SOA, I don't mean the modern version involving metadata to describe remote interoperable services like Web Services. I mean services, like what people used to write in the early 2000's when EJB stateless session beans first came out. Java classes which were stateless and contained just behaviour. Let's call such service "local services" to distinguish them.

Today around 12pm, I finally understood what the people at the DCI boards meant, when they said that my ideas were not DCI and could not fulfil the DCI goals... The very first DCI goal shown above relates to object oriented code. It does not mean make it more readable by splitting the behaviour out and having dumb data objects used by behaviour which is implemented elsewhere, such as happens with SOA. It really means, letting the code stay object oriented. I found that really stange, that in 2010, people still want to really program in traditional object oriented styles. Let me explain. In a Zoo, you have animals, and they can all "talk" to some extent. So you create a model which uses a super-class "Animal" which has a talk method which each animal class can override. Then maybe you introduce some movement and provide a "walk" method (hmm... snails... guess we need a new level in our inheritance tree to differentiate between walkers and sliders... oh dear our inheritance tree is exploding...).

Fair enough for a zoo. But in software, especially business software, how often do we really model behaviour inside the entity classes? Consider a bank account, and transferring money between two of them. Does the account transfer money from itself to another one, or does "something else" do it? Or think about a complex set of tickets which are related, for example a train ticket, a hotel booking and a ticket to a concert. You could buy these as a discounted package. The package might be just clever enough to give you the price based on adding up the price of its parts, but would you expect the package object to work out the package discount, or would it be the system which works out the discount, and sets it as an attribute on the package object?

In cases where it is something else providing functionality, rather than an entity, we use services. Services meld really well with object oriented data models. The services contain no data, just functionality, and the data model contains data, but no real functionality.

I am sure there are users, business analysts and requirements engineers out there, who think of these behaviours as belonging to objects, rather than the system, but for me, this thinking is wrong. DCI aims to make the programmer's mental model the same as the user's, so now we have a problem, because these user's are not thinking "right". But if you think about it, we don't write software for a single user. We write software for lots and lots of users (I once wrote an app costing nearly a million CHF for 3 users, but that was an exception). How can we ensure that their mental models are the same? And there is usually more than one programmer doing the writing, so how can we ensure their models are also the same? In agile programming, the users, customers, programmers, analysts, architects, business people and all other stake holders get together and talk. During that discussion, it is fine to encourage user's with a "strange" way of looking at the world to think a little differently (it might involve beer, donuts, or threats, but it is possible). To take a users mental model without encouraging them to refine it is dangerous. Typically, software is created to improve the user's life. If you ask a standard computer user with no IT training, to tell you what they want, in my experience it is not usable. We once asked our user's to define the colours of new system which would replace a 20 year old green-screen system. Their input: light green, a bit of dark green. Black text. They had no concept of modern software and what it could do for them or how it might make their lives easier. You are definitely allowed to encourage users to expand on and improve their original mental models.

So what about software which manipulates things on screen, i.e. the UI part? Imagine a word processor. You are typing away and have the feeling that you are on a type writer. You then want to add a picture. To add a picture, the program needs to respond to your click, open a file dialog and show you the files in a directory. You choose a file, click OK, and the picture is read and displayed where the cursor was. You click the "center" button to centre justify the picture. What goes on, in the user's head? What handles each of these inputs? Is it a document which responds to his wanting to insert a picture, or the system? Is it the document which puts the image in the document, or the system? Is it the document which formats the picture to become centred or is it the system? In my world, it is the system which does this, and as such, I can program these things to be part of my MVC controller which handles complex state updates. In my world, the controller would not tell the document to centre the image, but would do so itself. The document object contains the system state and knows where the image is in the document, and that the paragraph has the centred style. But the document does not have the ability to do anything useful itself.

In Eclipse RCP UI programming, clicking a button to load a file is handled as an action; you don't even have the choice of letting your "document" react to the event, unless you are backward thinking and have code in the action which fetches the document from the data model and calls the "insert image" method on it.

I just spent ten minutes getting my wife to open the word processor and describe to me what happens when she inserts an image and left justifies it. My wife is a standard user, who is word processor and browser proficient. When talking about actions and reactions (e.g. clicking the ok button in the file dialog which inserts the picture into the document), she always referred to either her or the system doing the work. If I asked her not to refer to herself, rather an element of the word processor, it was always the system which did the work. If I were programming the word processor, I therefore wouldn't be allowed to attach the behaviour to the button or document, rather the button causes the system to load the file. I could create a class called the system, but for me, a controller which relies on using services to do the work is acceptably close to the user's mental model.

Maybe I am just at an advantage, because I have lived in the service world for so long. Either way, the thing to take away is that local services empower the programmer to have a mental model close to the user's mental model, so that code becomes simpler to maintain. They also let the system behaviour be first class just as data is, and make code more reviewable by allowing it to be use-case-centric, which reduces reliance on testing.

©2010 Ant Kutschera

Social Bookmarks :

How Brontosaurs kill Raptors

Wed, 01 Sep 2010 19:59:00 GMT

The board of a large organisation appoints a CIO who delegates technical decisions to his employees. In the Enterprise Architecture (EA) department, an expert on Business Intelligence (BI) decides that the strategy for this company is to have a single Enterprise Data Warehouse (EDW). This makes sense, because experience has shown that in the long run, it is cheaper and more efficient to build one Data Warehouse, rather than start by building "islands" and then later try to merge them together.

In the mean time, some business people working for the company have rallied the budget holders, and started a project to build a new online sales application. They need to generate some reports based on the sales from this application, in order to set themselves targets and measure their performance. But, they are not experts when it comes to reporting. The business sector at which their application is aimed is cutting edge and brand new, so they don't know what to expect, they don't really know what kind of reports they will need, and they will certainly need to adapt to the market very quickly.

A project team in the IT department then get the assignment to build the application, including the report generation. Also knowing little about reporting, they start talking to EA, who set up a meeting, between themselves, the development team, some people from the Quality Assurance (QA) department and some experts from the BI team. Hours of discussion later, they have made the following conclusions:

Company IT Strategy states all reporting must be implemented in the BI solution, to ensure there is only one EDW,
The BI team are the only experts of the BI system,
The BI team cost a lot, because they are using SAP and consultants (how many SAP guys aren't freelance?),
The BI team dictate a six monthly release cycle, no exceptions,
The BI system is a black box, its inner workings stay secret within the BI team.

So, a simple question arises... "Our customer doesn't know exactly what they want, and because of their business requirements, they need us to be agile. What do we do and can the BI team help?", the development team ask. The first answer skirts around the issue and doesn't actually deserve being called an answer, because it doesn't answer the question. The development team make the point that the question hasn't been addressed, to which another attempt to avoid the question is made. Clearly, either these people don't understand their businesses needs, or they know they can't help but won't admit it. Either way, the debate moves on.

Days later, the business guys are telling some colleagues about their cool new project over an espresso and a latte. "Hee hee hee, hoo hoo hoo...", laugh their colleagues. "We thought our reports would let us track our progress too, but the IT department screwed us over. They charged us double and delivered nothing useful. We tried to submit some change requests to get it working and all the IT department wanted was more money and they couldn't deliver the changes quick enough anyway!"

The cool business dudes ran over to the IT office, informed their development team about the new information and said, "Guys, we don't want you to use BI. Well not for the first release anyway. Maybe in a year or two. Sure, it's policy and all, but we don't know what we want, and need to gain some experience, so just hack those reports out within budget please!".

So the development team arrange another meeting with the ~~astronauts~~ EAs and QAs to get that unanswered question answered, and they talk about the customers concerns. Even if it's an over reaction, the point is, that another department needs to be involved meaning more communication, less visibility and hence greater costs and risks. "Sure, no problem if the requirements are stable and known, but this project needs agility", is the point the dev team makes. "Well, no, not a chance!", comes the response.

"In fact," they continue, "you simply need to go back to the business and tell them that their idea is an architecture infringement - it goes against company policies. You won't pass QA, you won't get the go ahead to go into production, and that's the end of it", comes the reply.

A solution oriented response indeed... "Furthermore," continues an EA, " the business doesn't have the right to come into our shop and tell us where to implement things and where not to. We are the experts in the technology domain. We make these choices."

Well, his argument is that the business hired the CIO, who delegated responsibility to a BI expert, who created a non-agile policy. So the business have to swallow the argument and accept that the IT department is shit and won't give them solutions which they need, to compete in new markets... I'm not sure he realises that this is his argument, but it is, if you look at it pragmatically.

I'm not sure the cool business dudes see it that way either. I know I don't see it that way. And I know of no solution oriented architect or developer who sees it that way.

Of course I understand the reasons we have EA, QA, Processes and Policies. For large organisations they are the only way to avoid utter chaos, amongst many other reasons. Most of my working life has been spent with large organisations, even though in many cases I was allowed to implement agile solutions. But, after a long day in the office, with some frustrating decisions, I need to rant, so here is my cynical view of EA, QA, Processes and Policies, albeit somewhat harsh: these are all things which get bigger, the larger a company is, and all things which let people hide behind their responsibility of providing the business with the solutions they need. They all cause large corporations to be compared to large dinosaurs. These departments seem to have forgotten one golden rule: if the business fails, those departments won't exist. In competitive markets like we have today, businesses, no matter how large, need to stay competitive, and they can do so by using IT departments which are able to deliver agile solutions. These departments also often remind me of self-perpetuating witch doctors (The Witch Doctors, ISBN 074932645X). They justify themselves by stating that the business learned the hard way and now that they have been built up they cannot possibly be removed or have power taken away, like we some how never managed to go live before they existed, or that small companies can't exist because they don't have them.

Copyright © Ant Kutschera

Social Bookmarks :