OSGi Bundle Management Code [Part 4, ROM]

In the part 4 of my series I am going to describe the OSGi/Java code on the Plug Computer that implements the bundle manager in the ROM (Remote OSGi Manager) project.... and one of the best parts of doing this particular portion was that I started getting a much better understanding of the XML fundamentals. Notionally I always understood XML, but this was my first time programming with it.

At the simplest level - there is an OSGi bundle that receives network command over a Sockets Interface from the IOS app or a Java Test app, and then performs the appropriate action. These commands are all listed in the overview post. And I did get some good help from my Java programming friends to implement the entire interface along with the Java test application that I used to test the interface and responses.

First step to start a TCP server, here is the code snippet to accept a incoming connection and spin it on a new threadt:

try {
ServerSocket ss = new ServerSocket(port);
ss.setSoTimeout(soTimeout);
System.out.println("\nSocket Server listening on port "+port);
while (stopFlag == false) {
try {
Socket s = ss.accept();
clients.addElement(new Worker(s,bc));
System.out.println("Worker Thread Created");
} catch (Exception ignore) {
System.out.println(ignore.getMessage());
}
}

One challenge, that I faced later, was the decision to use UTF8 functions in Java to avoid network ordering issues. This did create problems during the IOS app but it was a good learning experience that was overcome using Google Search and Stack Overflow. 
The spawned worker thread handles the commands using Switch/Case flow:

public void run() {
String message = null;
String content = null;
int option = -1;
int BId = -1;
String file = "";

try {
message = dis.readUTF(); 
  System.out.println(message);
if (message != null)
option = Integer.parseInt((message.split(","))[0]);
BId = Integer.parseInt((message.split(","))[1]);
file = message.split(",",3)[2];
System.out.println("Recd packet from client Option:"+option+" BID:"+BId + " file:"+file);
} catch (IOException e1) {
System.out.println(e1.getMessage());
}
//System.out.print("message: "+message+"\n");
DoOps getb = new DoOps();

switch (option){
case LIST_BUNDLES:
  content = getb.getBundleList(bc);
  break;
case GET_BUNDLE_INFO:
content = getb.getBundleInfo(BId, bc);
break;
case STOP_BUNDLE:
content = getb.stopBundle(BId, bc);
break;
case START_BUNDLE:
content = getb.startBundle(BId, bc);
break;
case UPDATE_BUNDLE:
content = getb.updateBundle(BId, bc,file);
break;
case SYS_INFO:
content = getb.getControllerInfo(bc);
break;
case INSTALL_BUNDLE:
content = getb.installBundle(bc, file);
break;
}

    try {
    dos.writeUTF(content);
    dos.flush();
    dos.writeBoolean(true);
    this.stopWorker();
    s.close();
    return;
} catch (IOException e) {
System.out.println(e.getMessage());
}
}

All the commands are implemented in the Class DoOps, which perform the command and return the result. The first two commands above in the Switch/Case statements are returning XML schemas. The List of All Bundles returns all the bundles as XML content and the Get Bundle Info returns details of the requested bundle using an XML schema as well. Here is the XML schema/format for the List of Bundles:

<?xml version="1.0" encoding="UTF-8"?>
<bundles>

<bundle id="0">
<name>name of bundle</name>
<status>ACTIVE</status>
</bundle>

</bundles>

SSDP Service using Java/OSGi [Part 3, ROM]

In the last part I talked about how I implemented the SSDP code on the IOS app, to make my device discoverable - it has to be running the "SSDP Advertiser" - or a server that is listening to discovery messages.

The SSDP service runs as a thread when the OSGi bundle is installed and started - "AdvertiseServiceSSDP()". [The call before that - SocksServer is the class that implements the network interface between the IOS app & the Plug Computer as explained in the project overview.

public void start(BundleContext bc) throws Exception {
    this.bc = bc;

 

    nServer = new SocksServer(bc);
    advtROMService = new AdvertiseServiceSSDP(bc);

  }

Here is the SSDP code:

public void run() {

String msg = "LISTEN-FOR=THIS MESSAGE";

String chkResponse = "RESPOND-WITH-THIS-MESSAGE";

try {

int port = 1900;

InetAddress listenSSDP = InetAddress.getByName("239.255.255.250");

MulticastSocket ms = new MulticastSocket(port);  // Create socket
ms.joinGroup(listenSSDP);
System.out.println("\n Rcvr started, Ready to Receive... \n");
boolean match = false;
do {
byte[] response = new byte[256];
DatagramPacket rspPkt = new DatagramPacket(response, response.length);
ms.receive(rspPkt);
//System.out.println("\n Done Receiving!\n");
String getResponse;
getResponse = new String(rspPkt.getData());
match = getResponse.regionMatches(0, msg, 0, msg.length());
if (match)
{
System.out.println("Controller found\n");
// Send Response
InetAddress IPAddress = rspPkt.getAddress();
byte[] sendData = new byte[1024];
String sendResponse = chkResponse;

sendResponse += IPAddress.getHostName();

sendResponse += "/:portAddr";
System.out.println(sendResponse);
sendData = sendResponse.getBytes();
DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 1900);
ms.send(sendPacket);
System.out.println("Response Sent");
match = false;
}
} while(match==false);

} catch(Exception ignore) {

System.out.println(ignore.getMessage());
}

}

The above code when running on the Plug Computer(s) allows the IOS app to discover them. Of course the beauty is that this will work for all devices that support OSGi/JVM and have multicast networking support.

SSDP Service/Device Discovery [Part 2, ROM]

To begin my project - a Remote OSGi Manager (ROM) as described in my first part here, the first task I picked up was to try developing  a very rudimentary app that would discover the RTCOA Thermostat using the SSDP protocol. As you can see from the screenshot - it is really rudimentary user interface but my focus was to get my MVC right, and more importantly get the network interface going for the project. [BTW if you observe carefully - you can see the "Marvell" code that has been used in the RTCOA Thermostat].

Screen_shot_2012-04-10_at_6

After much searching and reviewing samples, I decided to go with the Cocoa Async Sockets, and I have ended up using them for all of the network interface in my iOS/iPad app. I got started with the AsyncUdpSocket to leverage it for running SSDP based discovery of the RTCOA Thermostat. The screenshot above was the start. I took the SSDP objects (serviceSSDP.m, serviceSSDP.h) and moved them to the bigger project. Also as a first step - the SSDP discovery code stopped after discovering the first controller. Given that in my project I was going to support multiple controllers, I ended up modifying the code to take into account that I should be able to discover multiple controllers (or devices) and then add them to a NSMutableArray.

//
//  serviceSSDP.h
//  SimpleSSDPDiscovery
//
//  Created by Ashu Joshi on 3/1/12.
//  Copyright (c) 2012 Movinture, LLC. All rights reserved.
//

#import <Foundation/Foundation.h>
#import "AsyncUdpSocket.h"
#import "connectedLifeController.h"

@interface serviceSSDP : NSObject

// This is the string that is Multicast to Discover the Controller
@property (strong, nonatomic) NSString *discoverControllerString;
// The Controller would respond with the string below upon discovery being received
@property (strong, nonatomic) NSString *responseStringFromController;
// The list of discovered controllers
@property (strong, nonatomic) NSMutableArray *controllerList;

@property (strong, nonatomic) connectedLifeController *currentController;

@property (strong, nonatomic) AsyncUdpSocket *ssdpSocket;

- (BOOL)startControllerDiscoveryProcess;

- (BOOL)startControllerDiscoveryProcess:(NSMutableArray *)listOfControllers;
@end

Once I got the Thermostat to discover using SSDP discovery code using iOS/iPad, I turned my attention to the Plug Computer. I created the framework for my bundle (OSGi terminology for an application). And the first thing I did was to implement code built out code in Java to run a SSDP "advertise" service on the Plug Computer. Before even migrating or trying the code on the Plug Computer I tried the code on my PC/Mac using Eclipse, once it was working I migrated it as a bundle/service in the OSGi framework on the Plug Computer. This code uses threading so that it is always running on the Plug Computer.

In the next part I will give an overview of the Java/OSGi code and the network interface implemented….

The Future of Fitbit Ultra

In the past few months I have been using Fitbit as an example for eHealth & Fitness services and also as an example of how connectivity, and consumer web services are changing the landscape. I finally ended up buying my own last week. I am definitely tracking my “steps” with the Fitbit Ultra and the other thing that I am doing is to monitor if I am sleeping well. But my motivation was to understand the intersection of technology with eHealth & Fitness. And I am big believer in the notion/concept of “Connected Life” and Internet of Things, and the Fitbit Ultra is an exemplary device.

So far the Ultra does what it claims and it’s amazing that the device uses an accelerometer to detect movement BUT it is the magic of software (in this case I believe it is good old C-based firmware) that turns data into knowledge. Take a look at the clip of job ad from Fitbit website:

Image002

And as a startup they have made a wise choice – of using an low power SOC like the MSP430 from TI - start with a technology that gives incredibly long battery life. I have gone a few days without having to charge my Ultra and it holds up very well. This can only be accomplished by ultra-low power processor coupled with the accelerometer to keep it powered! I also suspect, very strongly, that the MSP430 SKU being used actually is one with an RF Link built into it. The Fitbit Ultra needs the wireless link to sync with the PC and upload the data to the Fitbit site.

The challenge, I believe, is that the wireless technology from TI won’t be built into Tablets or PCs or Smartphones – and hence for bypassing the need for a PC or Mac sync with a dongle is important and it needs to be there future. And the same ad above makes it clear – Fitbit is looking into Bluetooth (and I would guess it would the LE Low Energy version to sustain battery life) and/or Zigbee (which also consumes very little power). The sooner they liberate themselves from the PC, the more innovative the Ultra will get… I would suspect & argue that with the sophisticated processing being done on the accelerometer data from the Ultra – there would be no shortage of beneficial use cases of such an incredible device.

Getting Started: IOS-based OSGi Application Manager

I am going to provide more details on the project that I have in of the earlier posts. The objective of the project is to build a network interface between an iOS application & a device running OSGi (it could be any device running OSGi since that lends to portability but I am going to start with a Plug Computer). And using that network interface/protocol  the IOS/iPad application would function as a “Remote Manager” to the Plug Computer. Obviously all code on the Plug that interacts with the iOS/iPad app would be developed in OSGi/JVM.

I had started doing some preliminary design work and thinking through in late January, and to prepare spent last two weeks of December (2011) getting my coding skills comfortable with both Java & iOS/Objective-C. The approach was to build the project incrementally, baby steps at a time. The key was to define the network protocol/interface between the iOS App & Plug. The interface by itself was very simple but I had to decide what it would do and more importantly in the first iteration what it won’t do.

Here is a simple diagram illustrating the protocol/interface, and I had decided to use a Sockets Interface between the iOS and Plug. The Plug and the iPad are both on the same network/subnet.

Image001

Using sockets was my first decision - in my next iteration I would move to a REST API between the two. I can comfortably say 3 months into it that the design & implementation is flexible enough where my “network interface” code on both sides is separate from the actual command processing. The next couple of decisions were also what not to take on in the first round of implementation – no TLS/SSL sockets and no authentication. I would take that on once I have the entire interface working. In addition there is no authentication or provisioning for the iPad/iOS app – that is – I have not built in any authorization check before the iOS/iPad app would be allowed to access the OSGi information on the Plug computers.

iOS Programming: Getting Started, & Sticking To It

Search the web and you will turn up gazillions of resources on getting started with IOS Programming, and I have done the same. In fact for the last three years I have been spending $99 every year paying for the IOS Developer Subscription and buying books. Apple keeps on revving (albeit not at the same rate as Android) the IOS SDK, APIs and the books that I had bought kept getting obsolete! I tried attending local Meetups and trying sample code. All I was able to do was to or rather hack together a few apps that could control or manage a Set Top Box (STB) using iTouch or iPhone. And the user interface on them was horrible…

Finally last December as I became more engaged and serious I latched on to three critical resources, here they are and the challenges with them:
As a prerequisite to all of the above - you need an Intel-based Mac, I had access to my personal iMac and you need to have the IOS SDK. While the SDK is free, having the $99 membership is required to test with an IOS device [you can get started testing with the IOS Simulator which is part of the free SDK and it is very, very good]. Testing on IOS device, IMHO, is very important. But not having one should not prevent you from getting started, it is however a challenge to keep going and be good at it.

Now, based not the version of the OS (Leopard, Snow Leopard, Lion) on the Mac machine you have and the version of SDK you will have to work around and adapt to a few new concepts and technologies introduced by Apple chief among them being "ARC" (Automatic Reference Count) - which reduces the burden not the programmer by making memory management a linker feature. And on that note - you may want to get the 3rd Edition of the IOS Programming mentioned above because the 2nd Edition is pre-IOS 4.3 SDK and that does not support the ARC. This, for a beginner, will add to the confusion of getting started.

You can use the resources above or something else, but the key to success is finding a project of your own that will help you apply the lessons. And as you build your own application or work on your own project Google Search is indispensable, and I would highly recommend Stack Overflow as well.

The Power of Three

There was a time when building a technology product and its functionality was largely contained into itself - ing was an island was perfectly fine. This was true of both enterprise and consumer products. A Set Top Box (STB) had no need for interactive functionality least of all a "companion application", or a Thermostat in the house was manually operated. The rise of smartphones, increasing connectedness have changed that. The paradigm has changed. When products are designed and developed - it is no longer just about the hardware & software of the product you are building - it is equally important to design interactivity with a smartphone or tablet application and tying the functionality of the product with cloud services. And as I outlined in one of my previous posts - my re-engagement with programming & development would be at the "intersection" of the three elements:

1. Technology Product

2. Smartphone | Tablet Application

3. Cloud Services

This is what I mean by the title - to deliver the best product experience - the product strategy and planning has to be done keeping the three elements in mind - to bring together the  Power of Three. The challenge I had was where to get started because each of these areas offers attractive options. I had to filter them - and the primary one was that I wanted to make sure that it did not impede or conflict with my day job. So when I started about three months ago I had to stick to products, technologies that are available to mostly anybody and available openly without requiring any NDA. And here are the choices I made:

1. To use a proxy for the 'technology product' - instead of choosing a STB or a Gateway (and I have tons of product management experience in both) - I chose an embedded Linux-based device or server - a Plug Computer. It supports an ARM version of Debian or Ubuntu. And for creating applications on the Plug - I chose to go with OSGi running on open source JVM.

2. The choice for Smartphone or Tablet applications was fairly easy - I chose IOS. And I specifically wanted to focus on programming with the large real estate screen of the iPad. Down the line I may expand this to support two more options - Android Smartphones and GoogleTV...

For Cloud Services - I have two choices Google App Engine or Amazon Web Services - but that the choice is still open… 

Let me quickly talk about the application I have in mind though or rather what functionality I want to implement. I am going to write basic code on the Plug Computer that would support a network interface to collect data, diagnostics from the Plug by the IOS App. The code not the Plug would be (or is begin developed) using OSGi/JVM. I intend to incorporate addition to diagnostics, use the Plug to connect to some basic sensors such as Accelerometers or Zigbee Switches and using the network API to communicate the data/events gathered to both the IOS app and the Cloud. As I write this I have made good progress on the initial stuff so far and my subsequent posts would talk about them. But I do have a long way to go, and I am looking forward to it….

Note: Attached a couple of sketches to illustrate my concepts using the great new Paper App for iPad.

(download)

Cancer Sniffing Sensors (& Dogs?)

Chemistry, Big Data (collecting and matching sample) and Sensors are enabling commercial machines to detect cancers - and detect them accurately. It sounds almost science fiction but is true. Business Week's Ashlee Vance has written an article on a startup, Metabolomx, and its cancer sniffing machines. 

The Metabolomx machine looks like a desktop PC with a hose attached. It sits on a cart that can be wheeled up to a patient, who is instructed to breathe in and out for about four minutes. The machine analyzes the breath and its volatile organic compounds, or VOCs—aerosolized molecules that, among other things, determine how something smells. Tumors produce their own VOCs, which pass into the bloodstream. The lungs create a bridge between the bloodstream and airways, so the breath exhaled by a patient will carry the VOC signatures of a tumor if one is present. “It may seem surprising, but it’s actually very straightforward,” says Paul Rhodes, the co-founder and chief executive officer at Metabolomx.

I can bet that from a desktop to a much smaller device that then interfaces with a smartphone or better still a Tablet such as the new iPad over Bluetooth LE is not far away. Interesting enough the inspiration originates from the fact that dogs can sniff cancer:

A few years ago researchers in California received widespread attention for showing that dogs can smell cancer on a human’s breath. With 99 percent accuracy the canines could detect if a person had lung or breast cancer, beating the best figures from standard laboratory tests. Subsequent studies confirmed the results and provided further evidence that dogs really are man’s best friend.

Back To The Future

I am getting back to programming actively. While I have been on the dark side (from an engineering perspective) - doing Business Development and Product Management - for almost 8 years now - lately I have found myself to gravitate towards getting deeper into technology. First signs - from hacking code to do simple demos - I have started (re)learning to code again, with gusto, patience, and diligence. My expertise has been in Embedded Technology - the kind of stuff that makes the guts of computing technology. It reminds of the tagline that BASF uses: 

"At BASF, we don't make a lot of the products you buy. We make a lot of the products you buy better."

The journey back to the dark side had started with the simple idea of being a better (technology) product manager.  Technology continues to evolve rapidly, not just that, the rate at which change is happening is also accelerating. Technology products are no longer islands of their own. They are increasingly connected to each other. Understanding this convergence, interaction is absolutely essential. So I am going "Back to the Future" - going "back" to rejuvenate my technical skills and converge them with my business experience. 

A Cluster Of Links: Telcos & Innovation

Last months Mobile World Congress prompted a cluster of posts and book reviews around the subject of Innovation & Telcos, especially around the roll of Bell Labs. Here are the top ones to read:

The Carriers Are Stuck In The Innovator’s Dilemma. Just Don’t Tell Them That.
Jeff Lawson, Pando Daily, February 20th 2012 (the author is founder of Twilio, an example given in the post for innovation using Telco networks)

"To survive the innovator’s dilemma, carriers need to increase the intelligence of their networks and open them up for innovation."

"There is, in fact, a party of innovation among developers of voice, VoIP and SMS apps that is similar in spirit to the early days of DIY telephone networks. It’s time for the carriers to join in."

"Instead of being fearful, operators should embrace the opportunity to innovate. But they do require a different organizational structure that allows them to fail fast and learn so that every once in while they have a winner."

A new book is out  The Idea Factory: Bell Labs and the Great Age of American Innovation” and the author Jon Gertner wrote an opinion piece in NYTimes that has prompted me to add the book to my reading list. Here is what he has to say:

Indeed, in the search for innovative models to address seemingly intractable problems like climate change, we would do well to consider Bell Labs’ example — an effort that rivals the Apollo program and the Manhattan Project in size, scope and expense. Its mission, and its great triumph, was to connect all of us, and all of our new machines, together.

In his recent letter to potential shareholders of Facebook, Mark Zuckerberg noted that one of his firm’s mottoes was “move fast and break things.” Bell Labs’ might just as well have been “move deliberately and build things.” This sounds like the quaint pursuit of men who carried around slide rules and went to bed by 10 o’clock. But it was not.

But to consider the legacy of Bell Labs is to see that we should not mistake small technological steps for huge technological leaps. It also shows us that to always “move fast and break things,” as Facebook is apparently doing, or to constantly pursue “a gospel of speed” (as Google has described its philosophy) is not the only way to get where we are going. Perhaps it is not even the best way. Revolutions happen fast but dawn slowly. To a large extent, we’re still benefiting from risks that were taken, and research that was financed, more than a half century ago.


You can read more reviews of the book @ Huffington Post and NYTimes.