(5) Establishing Connectivity: From Networks to the Internet

• The earliest computers were disconnected computing machinery
• The first computer networks were designed and established in the 1960s [http://en.wikipedia.org/wiki/Computer_network#History]
• Proprietary/specific networks (such as DECnet [http://en.wikipedia.org/wiki/DECnet]) were popular until the 1980s
• The Internet was invented specifically for interconnecting networks
  • Started with the ARPANET [http://en.wikipedia.org/wiki/ARPANET] in the late 1960s
  • The Internet [http://en.wikipedia.org/wiki/Internet] then focused on protocols and not on networks
  • Other protocols faded away in favor of TCP/IP's packet switching approach
• Internet vs. OSI was a big debate/fight in the late 1980s
  • The main differences were purity, complexity, and culture
  • Apart from a few select parts, OSI lost and the Internet won
• The Internet's biggest push was the advent of the web in the early 1990s

(6) Historical Internet Traffic (1993-2004)

(7) Current Internet Traffic (1H 2014)

(8) Providing a Platform: From Walled Gardens to the Web

• The web was the first usable global information system
  • Built on protocols rather than on products
  • Available at a time when computers started to become mainstream
• Web Architecture focuses on three central pillars
  1. Globally Unique Identifiers that allow everybody to refer to available resources (URI)
  2. Uniform Interfaces that can be used to access those resources (HTTP)
  3. Self-Describing Representations that allow clients to understand resources (HTML/XML/JSON/RDF)

(9) Client/Server Lost

• Remote application access went through (roughly) three stages
  • Traditional fat clients [http://en.wikipedia.org/wiki/Fat_client] that require specific client-side application code
  • Thin clients [http://en.wikipedia.org/wiki/Thin_client] that do not require application-specific client-side code
    • Typical architectures are remote application access through X11 [http://en.wikipedia.org/wiki/X_Window_System] or Citrix [http://en.wikipedia.org/wiki/Citrix_XenApp]
    • Scalability is a problem because clients use centralized computing resources
  • Web Browsers function fundamentally different
    • Client-side code is possible but not required (good web apps minimize client code)
    • Instead of displaying applications, what matters are representations
    • With HTML5 [https://github.com/dret/HTML5-overview] progressing, browsers become sophisticated code-on-demand thin clients
  • In some scenarios, fat and thin clients still make sense

(11) 2007: The Smartphone Era

• Sensors have become very affordable
• Connectivity has improved dramatically
• Many information sources (services/sensors) become available every day
• It's a little bit like the golden era of blogs and RSS/Atom
  • RSS/Atom feeds were an open way of making information streams machine-readable [http://dret.typepad.com/dretblog/2009/05/atoms-future-as-a-generalpurpose-format.html]
  • Social Platforms took over and quickly crippled/disabled open access
  • People today are very accustomed to live in pretty walled gardens
• The Big Question: Will there be a Facebook of IoT/WoT?
• For now the ecosystem is still young and developing

(12) Shared Identification Model

• http://google.com/ [http://google.com/] means the same everywhere
  • There is no (relevant) difference in terms of what the URI identifies
  • Any ambiguity is created (and hopefully managed) by Google
• Possible scenarios where this principle is violated:
  • A parallel Internet where google.com identifies a different entity
  • Intranet applications identified with broken URIs such as http://magicservice/
• Useful identification schemes are global in scope and uniqueness
  • Not every scheme needs a computer: Call me! [tel:+15102061079]
  • ...or electricity: Meet me here! [geo:37.859544,-122.327007]
  • ...or even identifies a physical resource Great book! [urn:isbn:3540642854]

(13) Shared Interaction Model

• HTTP always works the same (a shared uniform interface)
  • Interacting with the resource is possible without knowing it beforehand
  • The interaction language only is about making interaction possible and scalable
  • The representations being exchanged depend on a Shared Representation Model [Shared Representation Model (1)]
• Every browser on the planet can access every resource on the planet!
• Other schemes have other (or no) interaction models
  • ftp: works similar to HTTP (TCP/IP-based access)
  • tel: is based on a much older global network than the Internet
  • geo: interaction might just mean take me there
  • isbn: has no way to interact with the identified resource

(14) Shared Representation Model

• HTML works for the human web because of two factors:
  • Browsers know how to render a web page so that a human can read it
  • There is a hidden shared model of the human language that is published/read
• There are disconnected webs separated by language barriers
• Shared Identification Model [Shared Identification Model (1)] and Shared Interaction Model [Shared Interaction Model (1)] are necessary
  • But they are not sufficient: without them the web is not possible
  • But without a shared representation model there is no shared understanding
• How to establish shared understanding is a very deep problem

(16) How To Connect Things

• Constrained devices and networks may require different approaches
  • IoT's edges can look very different from IoC
  • Low bandwidth and intermittent connectivity are specific IoT issues
  • What happens past those edges may not be all that different
• Writing IoT applications requires some understanding of those constraints
  • It's similar to the (badly designed) mobile apps that don't work offline
  • In mobile it's the apps that go offline, in IoT it's the resources
• Core IoT can be a highly specialized development environment
• Applied IoT may be able to abstract away most of these problems

(17) How To Interconnect Things

• Using web architecture to build applications
  • The web has become the most successful application layer on the Internet
  • Not every application using the Internet follows the web's architectural model
• IoT scenarios in many cases involve broad and deep scenarios
  • Broad in the sense that resources come from a variety of sources
  • Deep in the sense than sensemaking involves a variety of steps
• Ideal IoT application should be open, extensible, and scalable

(18) What is the Browser of the IoT/WoT?

• Why would it be any different from a regular browser?
• One reasoning is that ii is not controlled by a human
  • Imagine programming a browser so that it does what you would do
  • In many cases programming such a browser would be hard/impossible
• Richer data/information models help building such a browser
  • How to define those is one of the main challenges