Principles

• Devices will range from low-capacity upwards, but will have some form of wireless communication
• Lightweight hardware requires lightweight middleware
• The middleware world will be non-homogenous
• The communications world will be non-homogenous

Specific projects

• Lightweight UPnP
• Jini and UPnP bridging
• Lightweight grid
• Jini and UPnP for small devices
• Structure-based discovery
• Web service discovery
• Identity-based PKI
• Network discovery of classes
• Ownership
• Network audio
• SISAL
• Toys API

Critique of web services

• Web services are built using SOAP, WSDL and UDDI
• All of these have fundamental flaws and are unsuitable for middleware in general and small devices in particular
• See paper on my web site http://jan.newmarch.name

SOAP

• XML-based remote procedure call protocol, usually layered over HTTP
• Requires XML parsers, often too heavy for small devices
• Only supports call-by-value, not call-by-reference, so...
  cannot return references to new objects
• Services are not addressable
• Breaks HTTP caching mechanisms
• Exploits security holes

WSDL

• Ridiculously complicated as a specification language
• Mixes protocol layers
• No location independent description of service
• Promotes poor s/w engineering practise: write the implementation, reverse engineer the specification

UDDI

• Designed as the "directory for everything"
• Not suitable to describe web services
• No way of searching for a web service
• Usage documents attempt to work around problems
• Should have a registry designed from scratch for web services

REST and UPnP (completed)

• REST is a design philosophy for applications that run over HTTP
• In REST, return a mixture of content (eg HTML) and references (URLs)
• Does not require XML parsers (eg url-form-encoding often good enough)
• UPnP (Universal Plug and Play) uses SOAP for RPC
• Replacing SOAP with REST-compliant protocol
  • Reduces network traffic significantly
  • Reduces processing time significantly
  • Reduces memory requirements significantly

Lightweight grid (ongoing)

• The grid is good for compute-intensive and/or data-intensive applications
• Motivation: in the home, cable TV produces huge amounts of real-time data
• Prediction: sensor networks will produce huge amounts of data
• Home devices (fridge, washing machine, ...) will all have CPU power idle most of the time
• Project: design middleware conforming to grid principles but without the overheads of current grid middleware such as Globus
• Status: design of lightweight grid completed, ready to move to implementation

Jini and UPnP for small devices (ongoing)

• Java standard for small devices is J2ME, running on the KVM (kernel VM)
• J2ME does not support either Jini or UPnP
• Adding a profile and implementation for multicast
• Adding a profile and implementation for XML parsing suitable for SOAP (current XML profile is only suitable for web service clients, not devices)
• Jini requires a special class loader, and the KVM does not allow user-defined class loaders, but...
• ...the bootstrap class loader in the KVM is not specified
• Project is to write a bootstrap class loader suitable for Jini, and define a profile for it

Jini and UPnP bridging

• There are many middleware systems: Jini, UPnP, HAVi, Web services, CORBA, ...
• No single system will become universal - politics, different applications domains, etc
• Bridging between protocols will always be needed
• There are many issues
  • Data types
  • Programming styles (eg mobile objects vs fixed references)
  • Synchronous/asynchronous/events/...
  • Discovery systems

Bridges

• Standard bridge looks like
  
• We have built two different types of bridge
  • Embedded lookup service
    
  • Service cache manager bridge
    

Ontologies

• An ontology is a description of all the "nouns" and "verbs" in a system and how they relate to one another
• They have been described in the past by data dictionaries, entity-relationship diagrams, UML class diagrams, etc
• Ontologies form the basis of the "semantic web" using ontology languages such as RDF and OWL
• OWL allows typical O/O constructs such as inheritance and aggregation. It also has reasoning systems, in three forms
• The assumption is that everyone will agree on the same ontologies for similar domains
• Reality is that there will be many ontologies, just like there are many database schema for similar domains
• Mapping between different ontologies will be a requirement of future semantic systems - and hard

Ontologies and services

• Services in a domain will be built above an ontology
• A service will usually only use a subset or slice of an ontology
• Matching services may be easier than matching a complete ontology

Web service cache manager (ongoing)

• UDDI is not appropriate as a lookup service/service cache manager for web services
• We have built a service cache manager that stores WSDL documents and can be searched for services matching XML tags
• We use a factory object for the search engine, so we can plug in different types of search engine
• Currently we have exact match and and inexact match search engines
• This will be used for a cache manager to work across ontology slices

Structure-based discovery (ongoing)

• Jini uses exact matching within an inheritance hierarchy
• This requires total knowledge and agreement of the service ontology
• Jini uses the Java name-based inheritance
  class A extends B
• A weaker inheritance system is structure-based inheritance which just requires matching of method signatures
• We are building a service-cache manager using structural inheritance as a first step towards a cache manager to work across ontology slices

Network discovery of application classes (completed, but extensions possible)

• Jini/RMI/CORBA/etc allow discovery of services/objects
• This must be explicitly coded, and gives some sort of reference/proxy to a live object
• This project discovers class files needed by an application
• Custom class loaders form a federation of loaders connected by Jini
• When an application needs a class, it asks all the loaders for suitable classes - invisible to application
• Many uses
  • Classes placed on a home gateway can be picked up by devices (different to OSGi)
  • An application can pick up local classes (eg tourist program)
• We can also replace code in place, without stopping the application

Follow-me audio (ongoing)

• Builds on a distributed audio system
• Assumes mobile trackable user, and a number of audio outlets
• Audio is directed to nearest audio system
• Need to handle context ("best" audio system)
• Need to handle conflict (two people wanting to listen to different things)

Networked loudspeaker

Ownership (ongoing)

• To prove ownership of an object, you need a receipt/bill of lading/etc
• Having a separate receipt and object is poor O/O
• Long-term assumption: anything (eg bottle of soya sauce) can have an RFID tag with non-trivial processing power
• Tag can store ownership information
• Protocol developed for "change of ownership"
• Many issues
  • Legal status
  • Lightweight PKI
  • Different types of ownership - own, rent, hire purchase
  • Group ownership
  • Forced change of ownership (eg death)

Identity-based PKI (ongoing)

• Typically, public and private keys are opaque data
• Identity-based PKI allows "well-known" strings such as email addresses to be used as public key
• Private key is generated by special server
• Building a practical system based on this, to be adapted to a zero-configuration environment if possible

SISAL (beginning)

• Sensor Information Systems for Assisted Living (typically helping old people)
• Peninsula campus of Monash has a Health focus
• Cooperation beginning on research projects across campus
• Peninsula School of IT will be involved in SISAL projects

Toys API (beginning)

• The toy industry is a multi-billion dollar industry
• More toys will contain microprocessors
• Current systems are mainly control systems eg model planes, model trains
• Some toys such as Lego Mindstorms have substantial processors (16 bits, 32K RAM, programs downloadable over infrared)
• Would like to start a project to develop systems and APIs for interactive toys - not just electronic games!

Lego Mindstorms

Slotcars

Conclusion

• Many different projects
• Loosely coupled as middleware systems for small devices
• Comments? Questions?