Header Ads

  • Breaking News

    Web thinking for connected devices


    WEB THINKING FOR CONNECTED
    DEVICES



    When you are thinking of the networked aspect of Internet of Things
    objects, it might help to draw on experiences and design guidelines from
    existing network deployments. The obvious choice would be to look at
    design guides to the World Wide Web and the Internet itself; after all, the
    term Internet of Things will look quaint in the future when we accept that it
    is completely natural for the Internet to be full of Things as well as comput-
    ers and phones. You should aim to get into the mindset of the web and create
    devices which are of the web rather than those which just exist on the web.
    In an early version of the specification for TCP (RFC761, http://tools.
    ietf.org/html/rfc761 - section-2.10), Jon Postel wrote: “Be
    conservative in what you do, be liberal in what you accept from others”.
    Since then, that robustness principle has become so well known that it is
    commonly referred to as Postel’s Law. It is good to bear this in mind when
    designing or building anything which must interact with other services—
    particularly when you aren’t the one building the other components with
    which your system interacts.

    SMALL PIECES, LOOSELY JOINED:

    Even if you are building all the components of your service, it makes sense not
    to couple them too tightly together. The Internet flourished not because it is
    neatly controlled from a central location, but because it isn’t; it is a collection
    of services and machines following the maxim of small pieces, loosely joined.
    What this means for the architects of a service is that each piece should be
    designed to do one thing well and not rely too much on tight integration with
    the separate components it uses. Strive also to make the components more
    generalised and able to serve other systems which require a similar function.
    That will help you, and others, to reuse and repurpose the components to
    build new capabilities unimagined when the initial system was commissioned.

    Where possible, use existing standards and protocols rather than inventing
    your own. Any loss of elegance or efficiency of code size or electronics will
    be outweighed by the availability of standard libraries and skills for people
    to interact with, and build on, your system. For example, when the designers
    at Twitter implemented the search feature, they chose to include a more
    machine-readable option in the form of a feed of results in the standard Atom
    syndication format (http://tools.ietf.org/html/rfc4287). I’m
    fairly certain that they didn’t expect it to be consumed by an Arduino, which
    would then use it to activate a bubble machine to blow bubbles for each new
    tweet.

    Similarly, because Bubblino was made to understand and consume Atom
    feeds to look for new tweets, it can now be repurposed to monitor anything
    with such an interface. So new entries in a blog are trivial to monitor, and
    most web languages have libraries to generate suitable Atom feeds for any
    other notifications that you would like to visualise as bubbles.

    This meant it was trivial for one customer to get their Bubblino to trigger
    whenever one of their developers submitted some code which failed their
    automated tests. They just wrote a small web service that took the test
    results and presented them as an Atom XML feed. Once their Bubblino was
    configured to use that new service, it would then blow bubbles whenever the
    tests failed.

    FIRST-CLASS CITIZENS ON THE INTERNET:

    An extension of the concept of loose coupling is to strive to make your devices
    first-class citizens on the Internet. What do we mean by that? Where possible,
    you should use the same protocols and conventions that the rest of the
    Internet uses.

    In the early days of any new development, it is tempting to compromise and
    choose protocols which are easier to implement. Indeed, many middleware
    providers encourage that practice, claiming that such low-powered end-points
    are not capable enough (in processing power or RAM or in t

    See also:

    internet-of-things-magic-as-metaphor

    privacy-of-internet-of-things

    calm-and-ambient-technologytech-wise

    who-is-making-internet-of-things

    No comments

    Post Top Ad

    Post Bottom Ad