Devices as Software Objects

Software devices

• To make a device into an "internet device" means there must be ways of communicating with the device by software
• For each device there will be one or more software "objects" e.g. a TV may have a display object, a tuner object and an amplifier object
• These objects may be in an O/O language, but not necessarily
• There are many issues involved in representing devices as objects

Device classification

• No awareness of any object system (legacy current devices)
• Awareness of a software object system, but not enough computing power to fully partake
• Enough computing power to be a "first class device"

Legacy devices

• Most devices are "legacy devices" without any knowledge of other devices, and with linmited capability of communication with them
• These may need proxy objects or surrogate objects to control them, which may be other devices
• e.g. an X10 light switch may be represented by a switch object running on a computer in the home

Partial knowledge

• A device may not have enough computing capability to be an object in a network
• It may have enough capability to store a program capable of controlling it, and upload that to another device which can run it
• The lowest level of this is an RFID tag which can upload its value to a device which knows information associated with the tag
• A higher level is a device which stores proxy code and can upload that to a proxy device, so the proxy device does not have to be so knowledgeable about the device
• Uploading code means that the receiver must be able to run the code
• This requires portable code, such as Java bytecodes or programs in an interpreted language such as Python

Full capability

• The device has enough processing power to run programs
• It has a network connection of some sort
• J2ME devices are in this category

Transport independence

• Many different transport mechanisms and protocols exist
• Your TV must be able to talk to your VCR even if they use different protocols
• Two approaches:
  • Higher protocol level
  • Bridging
• TCP and UDP run on top of IP which is implemented on top of lots of different protocols
  • ethernet
  • PPP (point-to-point e.g. for telephones)
  • Bluetooth
  Given a set of protocols, find a higher level that will talk to both
• If there is no higher level, build a bridge between them e.g. a CORBA to COM+ bridge

Zero configuration

• When you switch on a new device, it should configure itself to its new environment
• There should be no need to set any parameters e.g. a new TV picks up the local channels without doing anything, but a new FM receiver has to be tuned to the local channels
• Settings can be done at the factory level e.g. standard TV frequencies
• Settings can be picked up from the local environment
  • DHCP to get the network address parameters
  • A timeserver to set the clock
• Zero configuration may conflict with security e.g. the Palm Pilot of someone else learns the pin code to your home security system

Advertisement

• Devices offer services
• These must be publicised in some way
• An "advert" for a service may be
  • broadcast to every other service
  • placed in a repository
  • kept on the device, for retrieval on a search request
• An advert must contain
  • Service type
  • Specific information about that service
  • Information about extensions to the service

Advert contents

• Service type.
  This must be standardised so that everyone knows what to look for
• Specific information about that service.
  e.g. a printer can be a colour or black-and-white printer
• Information about extensions to the service.
  e.g. the printer may also send faxes

Discovery

• Before invoking a service, a client must be able to find it
• This depends on how adverts are stored
  • Listen for adverts
  • Go to an advert repository
  • Broadcast for the service
• Listening
  • relies on services broadcasting - may cause delays
  • the listener must act as a server or event sink
• Advert repository
  • requires knowledge of where the repository is
  • this may be hard-coded or the result of a broadcast search for repository services
• Broadcast
  • Send a message to everyone asking for responses
  • Everyone else has to be listening

Service invocation

• When a service is located, it will give you some sort of "handle" to invoke the service
• The handle may be a URL: getting the URL will run a CGI script or similar on the service side (e.g. Web services)
• The handle may be an IP address and port number: connection to that address/port will allow exchange of messages between service and client (e.g. telnet)
• The handle may be an RPC (remote procedure call) stub: this can be used as a proxy to make remote calls on the service (e.gm Network File Service, NFS)
• The handle may be a mobile object which represents the service in some way (e.g. Java RMI gives you a proxy object)

Synchronous/Asynchronous

• Messages/RPC/URL requests are all synchronous:
  • they block until a reply is received
  • they require the service to be online
  • a connection to the service must be available
• Asynchronous invocation sends a message and returns
  • the sender can immediately carry on with other work
  • the receiver need not be available at the time, but must eventually be so
  • this requires an infrastructure to receive, buffer and forward messages
  • the sender must have an event listening mechanism to get replies

Failure

• Networks fail
  • Clients dies
  • Service dies
  • Router dies
  • Name server dies
  • Cable/switch fails
  • Delays timeout
• Internet services need to handle a wider range of failure than ordinary programs

User interface

• User interfaces come in many forms
  • Windows applications
  • Browsers
  • Mobile phones
  • Microwaves
  • VCRs
  • doors (see "The Design of Everday Things")
• To control a device from different control devices requires changeable user interfaces
  • Multiple interfaces, one for each UI type
  • A customisable UI
  Both are hard