The µ controller runs simple REST client that makes HTTP requests to the server to allow entry to some supposedly secure location. (Of course, this is just a trivial application; the ultimate project is to have an automatic hoover that cleans my house automatically, but allows me to control where it goes and to tell it to focus on a particular area.) Before we start looking at the code, here’s a video that shows the project in its full hardware glory!

The client

The client in this case is not a browser, but it is a microcontroller running a simple tourniquete-like application.

The hardware

The hardware is the mbed microcontroller talking to a HD 44780 two-line character LCD module, a photodiode and a few other bits and pieces. If you fancy building it yourself, Figure 1 shows the schematics.

Figure 1. Schematics

The client software

The client software is a C++ program that runs on the microcontroller. The code initialises the display module; initialises the network interface and then makes plain HTTP requests to the server-side code. The interface is

class Main {
private:
    int count;
    DigitalOut *busyLed;
    AnalogIn *light;
    TextLCD *lcd;
    DigitalOut *goLed;
    DigitalOut *stopLed;
    char* status;
    EthernetNetIf *eth;
    HTTPClient *http;
    float ambient;
    bool noEthernet;

    void go();
    void stop();
    bool isHit();
public:
    Main();
    void run();
};

…

int main() {
    Main main;
    main.run();
}

The constructor, Main::Main() performs the necessary initialisation; and the code that runs the main loop is in the run method. The code in the run makes the HTTP requests (when I pass my hand over the photodiode), displays the results and execute the appropriate methods stop and go. The methods simply turn on the LEDs, but one could imagine that the methods open barriers or something similar. (Think the Tube tourniquets). To complete the picture, here is the skeleton of the run method:

void Main::run() {
    while (1) {
        lcd->locate(0, 0);
        lcd->printf("--- %.4f", ambient);

        wait(0.1);

        if (!isHit()) continue;

        (*busyLed) = 1;
        HTTPText txt;
        lcd->locate(0, 0);
        lcd->printf("*** %.4f", ambient);
        stop();

        if (noEthernet) {
            lcd->locate(0, 1);
            lcd->printf("Could not verify");
        } else {
            char request[200];
            bool isGo;
            count++;
            char message[16];
            sprintf(request, "http://192.168.1.69:8080/%d.toString", count);
            HTTPResult r = http->get(request, &txt);
            if (r == HTTP_OK) {
                const char* s = txt.gets();
                isGo = s[0] == 'G';
                strcpy(message, s);
            } else {
                lcd->locate(0, 1);
                isGo = false;
                strcpy(message, "STOP (no server)");
            }
            if (isGo) go(); else stop();
            lcd->locate(0, 1);
            lcd->printf(message);
        }
        wait(5);
        ambient = (*light);
        lcd->locate(0, 1);
        lcd->printf("                ");
        (*busyLed) = 0;
        stop();
    }
}

Now that we have the client, let’s move on to the server code.

The server

I have implemented the server-side code using Akka; I am deploying it in Tomcat 7. Figure 2 shows the overview of all the files that make up the application.

Figure 2. The key files

The key files include

• akka.conf file in src/main/resources containing the Akka configuration
• web.xml in src/main/webapp/WEB-INF with the servlet configuration for Tomcat 7
• Initializer that implements the ServletContextListener that boots up Akka
• Boot that configures Akka on startup
• Finally, GatekeeperActor that handles the client requests

Akka in Tomcat

We now need to bootstrap Akka when we deploy it in our Tomcat 7 container; we also need to map the HTTP requests to our actor. The web.xml file defines the listener that initializes the Akka environment and the servlet that processes the HTTP requests.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
  version="3.0">

  <listener>
    <listener-class>scalad.example.akka.Initializer</listener-class>
  </listener>

  <servlet>
    <servlet-name>AkkaServlet</servlet-name>
    <servlet-class>akka.http.AkkaMistServlet</servlet-class>
    <async-supported>true</async-supported>
  </servlet>

  <servlet-mapping>
    <servlet-name>AkkaServlet</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>

</web-app>

Notice, in particular that this is Servlet 3.0 web.xml (you will have no luck running the application without it)! Onwards to the Initializer that prepares the environment for Akka.

class Initializer extends ServletContextListener {

  lazy val loader = new AkkaLoader

  def contextDestroyed(e: ServletContextEvent) {
    loader.shutdown()
  }

  def contextInitialized(e: ServletContextEvent) {
    loader.boot(false,
      new BootableActorLoaderService with BootableRemoteActorService )
  }

}

Next, in akka.conf we have boot = ["scalad.example.akka.Boot"], which means that Akka will turn to the Boot class, which will bootstrap the Akka environment.

class Boot {

  val factory = SupervisorFactory(
    SupervisorConfig(
      OneForOneStrategy(List(classOf[Exception]), 3, 100),
      Supervise(Actor.actorOf[RootEndpoint], Permanent) ::
      Supervise(Actor.actorOf[GatekeeperService], Permanent) ::
      Nil))

  factory.newInstance.start

}

We setup the SupervisorFactory with two actors: the RootEndpoint, which acts like a central registry for the HTTP requests and our GatekeeperService, which registers the GatekeeperActor. The actor is the key element in our application. It receives the HTTP requests and produces the responses:

class GatekeeperActor extends Actor {
  private val random = new Random

  def receive = {
    case get: Get =>
      get OK (if (random.nextInt() % 2 == 0) "G" else "S")
    case other: RequestMethod =>
      other OK "S"
  }
}

And yes, the actor is trivial. When it receives a HTTP GET request, it produces a text response as either "G" or "S", at random. The client interprets these responses and performs the appropriate actions.

The code

This application’s source code is available as part of Scalad, but the Scalad version includes some data access code and it is at github.com/janm399/scalad.

Why is COBOL still out there?

So, how come COBOL has survived for so long? It is an old, cumbersome language; yet, it has modern compilers and runtime environments. You can compile your COBOL program on 32bit Windows, on 32 and 64bit Linux, HP-UX, Solaris, AIX, and many others.
Seven years ago, I worked in Ortex and they (not me, I was the cool new dude) were churning out thousands of lines of COBOL code every day.
I helped replace the aging Windows 3.1-style user interface with something that looked a bit more modern, but underneath the pretty UI, we were still talking to green-screen UNIX COBOL monster. And there lies the key to COBOL’s continued success.

What did COBOL give us?

It did not use complex binary protocols, it relied on the XML of the seventies — fixed width text messages. This simple data exchange format lends itself to easy integration with other systems. As long as your system can read and write fixed-width text, you can talk to COBOL-based systems — OK, I know I’m leaving out details, but bare with me.
Fast forward to 2006 and watch the WS-* approach. Why, did the WS-* people ask, are our systems talking to each other in closed binary formats; why can’t we use an easy to read and write format? Why aren’t we using XML? It turns out that WS-* approach is still cumbersome. For example, you cannot determine what a WS-* call will do just by looking at the endpoint, you need to examine the payload. Hmmf!
Enter REST. Again, we are sending structured plain text, but this time around, we’re making the most of the HTTP protocol. We use the HTTP methods properly and we give meanings to the URIs.