2 Comments

Summary:

Oracle and Freescale have teamed up to make a universal translator appliance for the many protocols used by the internet of things. The first appliance will be aimed at the smart home.

SmartHome

When it comes to connected devices, there’s still plenty of debate over the right operating system, the correct protocols for sending data and even the basics of where processing will take place — on premise or in the cloud.

This might seem esoteric, but if you’re waiting for your phone to unlock your front door, that round trip to the cloud or a fat OS isn’t going to win accolades if you’re waiting in the rain. With all of this in mind, Oracle and Freescale have teamed up to offer an appliance and a Java-based software stack for the internet of things.

The idea is that sensors running lightweight versions of Java — Freescale’s Kaivan Karimi, assures me they exist — will talk to a box that can “speak” all of the variety of protocols currently being used in connecting devices. The box runs Oracle Java SE Embedded and is powered by a Freescale i.MX 6 series applications processor built on the ARM Cortex-A9 core.

Karimi said in an interview that the system would be open throughout since it’s based on Java and doesn’t require hoops for programmers or device makers to jump through. Basically, the idea is that everything in a connected manufacturing plant or home or utility point their devices to this “one box” appliance and the box does the work of translating protocols so everything can work together.

The box also has enough processing power to handle some of the real-time data processing that connected devices will require, and can then send the remaining data up to the cloud if needed. There, Oracle’s big data gear will be happy to crunch those bytes, although the client could use whatever gear they’d like. This local data processing cuts down on cost and latency.

The first box will work in the connected home, and cover common protocols in that realm. Oracle and Freescale will develop later boxes for other industries ranging from smart grid to manufacturing. Given how many connected devices with their own embedded radios are already on the market and out in the field, finding a solution that embraces and helps compensate for this existing diversity makes a lot of sense, even if it might be more efficient to try to build a brand-new system.

However, this effort is one of many efforts in this space, and many doubt if Java is the right way to go for sensors — given how much memory and processing power it can require. But I like the approach and appreciate any effort that’s trying to tackle the ecosystem as opposed to just adding new parts. We can export more Karimi at our Mobilize event in San Francisco on October 16 and 17th.

You’re subscribed! If you like, you can update your settings

  1. Java is the leading example of the morass of barnyard excrement turning the path of software development into a minefield that I anyone expected to result from the religion of Open Source.

    Any IT department can relate tales of getting an update to critical software and realizing one more version of Java is needed to sit on the system just to make things run. Then begins the next inevitable round of incompatibilities.

  2. For the most part, the smartphone world has successfully avoided Java, and it is better for it. Android allows a particular, sandboxed version of precompiled Java, so there’s no JVM or portability of this code. iOS avoids it completely. This has not deterred many people from developing for these platforms.

    The core argument from the Java lobby, that it allows faster application development, is specious at best. Java seems to be used by desktop enterprise-ware and for some backend stuff, where I suspect it is gradually being supplanted. It was an interesting experiment that became irrelevant once compilers got really fast and articulate (see LLVM on a modern computer), and once the CPU world more-or-less converged onto two platforms, ARM and x86, both of which are supported by FOSS compilers. The dependence on a particular JVM/JDK version has become a bigger problem than dependence on underlying hardware.

Comments have been disabled for this post