Let’s create a “smart grid,” meaning an app that can adapt to different real-life events. This is based off of a set of real projects written by Red Hat for customers, largely logistics in nature (trucking, aerospace, and rail transport are all logistics, for example.)
The end goal is to have a project that has characteristics that these real applications have, while having nothing to do with an actual problem space, yet showing how these applications can be written.
It will be an iterative process. Our first few rounds will not be our end goal, but we’re going to get closer and closer as we go along – and we’re going to put everything on github so everyone can see what we’re doing right as well as what we’re doing wrong, and hopefully everyone can learn and grow through the process.
Here’s our application description, in a nutshell:
Create an application that tracks current light levels for participating devices in near-real-time.
The basis for this is a toy I wanted my oldest son to create for me when he was nine years old: a lamp that would adjust its brightness based on the current room light levels. If it was bright, I wanted the lamp off, of course. If it was dark, however, I wanted the lamp to be bright; if the light was dim, I wanted the lamp on, but not at full power.
The idea was to give me light when I needed it, at the level I needed it.
This application will give me that capability (and I plan on actually designing a device that provides this, based on this application’s data).
The initial design of the application doesn’t quite go that far, though.
What it will do:
- Use an Android as an initial light sensor (since the Android has a readily available light level sensor, and Android phones are pretty common) to send the current light level and GPS location for that device, along with an identifier for the device, to a central server.
- An initial client will be a web browser, displaying the identifiers’ locations and their current light levels on a map.
This is not the final iteration of design, of course: keep that in mind! As we’re working through the application, I’ll continue to make notes and references towards improvements (and there will be quite a few of them.)
A Few Thoughts
Platforms… which platforms. our choices of platforms depend on a lot of aspects. We’ve already specified Android, and we know that a web browser will be involved at some point… but why?
Android is being chosen for a few reasons.
The first reason is the most simple: I have one! (A Samsung Galaxy S III.) There are actual technical reasons as well: the available sensors on the Android include the light level sensors. I found a reference to the light level sensor on the iPhone, so it’s possible (early references said to use the camera!) but that’d mean going out and buying an iPhone and the entire development kit.
Android wins through ease of access.
So that gives us our provider (the thing generating data). Where does it send the data?
Well… that’d be a broker of some kind. It just so happens that I have some experience in middleware, so why don’t I use my experience? It just so happens that it’s a good fit, technology-wise.
There’re some aspects to the middleware that we’ll swap out for various reasons (which will be made more clear as we go through the process) but we’ll start with JBoss AS7 – which means the basic Java EE stack, plus a convenient data grid (Infinispan.)
The integration of Infinispan into JBoss AS7 is really convenient – it means our data access is really, really simple, and Infinispan is already a clustered data grid, so we can distribute our data across multiple servers without having to jump through any RDMS-related hoops. Thus we eliminate any explanations of the Java Persistence Architecture, although we probably still want to keep transactions in mind at some point.
The producer and the middleware use Java (more or less) as their lingua franca; we’re not going to limit ourselves to Java-only from the specification’s standpoint, but we may not need to use anything else. If we need to, however, we will.
The last bit we have to think about is the end consumer… well, maybe not that far, but at least we have to think about the program the end consumer will use.
We’re targeting a web browser for the first design, so let’s try to keep in mind that users aren’t going to stick to Chrome like they ought – they’re going to use Safari, or Firefox, or Opera, or – God forbid – maybe even Internet Exploder.
That should be easy enough – I’ll stick to my skill level for the client side (which is somewhere between “comically ignorant” and “novice”) and rely on libraries to provide cross-browser compatibility.
Eventually, I plan on having a non-browser consumer, that can adjust its output based on current local ambient light levels… provided through the phones being used as producers.
It’s a silly project, in the end, of course, but as a proof of concept there’s a lot of usefulness to be mined.
Next we’ll look at the Android application, the data producer.