Jini for Home Middleware

Home middleware

• One of the next battlefields for systems will be the home
• Possible middleware candidates include
  • UPnP
  • Jini
  • HAVi
  • many others
• Home networks will require
  • Zero configuration
  • Lightweight middleware

Jini

• Relatively heavyweight: the Jini libraries are over 1M in code size
• A pain in the b*tt to set up
• Won't work easily in a badly setup or "incomplete" environment
• Poor industry support
• No Jini devices exist

UPnP

• Fairly lightweight, uses existing protocols: SOAP, HTTP, TCP, UDP, Multicast
• Easy to set up
• Will work in minimally configured environments
• Strongly supported by a Microsoft backed industry group
• Several UPnP devices exist

Technical comparison

Object mobility

• Requires object introspection (for marshalling)
• Requires specialised class loader (e.g RMIClassLoader)
• Requires security management (e.g. RMISecurityManager)
• Requires HTTP server
• Not available in e.g. KVM

Method level object mobility

• UPnP avoids object mobility by using primitive data types: int, boolean, string, etc
• Jini can equally use these types
• If Jini services only use primitive data types, then there is no method-level object mobility - just like UPnP
• This requires no change to any of Jini - just how the interfaces are specified
• Paranthetic note: UPnP should be in trouble over A/V structures - it avoids them by hiding XML documents in primitive strings

LUS proxy mobility

• A home service is likely to be on a small footprint device: temperature sensor, infrared sensor, washing machine, fridge, etc
• A home service may not be able to support object mobility to the service
• Embed an LUS within the service, so mobility of an LUS proxy to the service is avoided

Listeners

• Event listeners could be registered with the LUS proxy...
• Listeners could be registered with the service...
• ...just don't move them to the service/LUS

Object mobility changes

The change is shown as

Removing the HTTP server

• To load an unknown class, the JVM must be able to find the class definition
• For new mobile objects, the class definitions are usually stored on an HTTP server
• The Java Proxy class reduces this: a proxy supporting an interface can be generated on the fly
• The generated proxy uses an InvocationHandler to deal with method calls
• Jini and RMI have standard invocation handlers known to the client so no mobile code is needed for protocols such as JRMP, Jeri, IIOP, etc
• Additional classes unknown to the client may need to be downloaded - not a problem for UPnP data types

Situation so far: ZeroConf

• Jini can function at the level of UPnP data types trivially
• Combining the LUS with the service can remove all mobile code to the service
• Use of Proxy and a standard invocation handler avoids use of an HTTP server
• Result: Zero Configuration of the service!

Lessons from JMatos

• JMatos is a Jini LUS, not Open Source
• The Sun LUS proxy communicates back to the LUS itself for any queries
• The JMatos LUS is self-contained and does not need to talk to its original server - a "complete" proxy
• This reduces network traffic, speeds up responses, etc

Lessons for Jini/UPnP

• It can be more convenient to send a "complete" LUS proxy
• Network traffic can be reduced
• There is no need to define a "proxy to source" protocol
• But it isn't necessary...
• What follows can be done more easily using a complete proxy, but can be done anyway

Piggybacking service definitions off UPnP

• The UPnP consortium has defined a number of standard home services
• Services are defined in an XML file
• This can be parsed to define a Jini interface to talk to the service
• This is similar to mapping CORBA IDL to Java and mapping Web Service WSDL descriptions to Java
• It is simple for UPnP since the data types are primitive, and you only need to look at in or out parameters
• Define "holder" classes for out parameters such as IntHolder

Example: UPnP service definition

A typical XML service document (for a timer service) is

<?xml version="1.0"?>
<scpd xmlns="urn:schemas-upnp-org:service-1-0" >
    <specVersion>
	<major>1</major>
	<minor>0</minor>
    </specVersion>
    <actionList>
	<action>
	    <name>SetTime</name>
	    <argumentList>
		<argument>
		    <name>NewTime</name>
  		    <relatedStateVariable>Time</relatedStateVariable>
		    <direction>in</direction>
		</argument>
	    </argumentList>
	</action>
	<action>
	    <name>GetTime</name>
	    <argumentList>
		<argument>
		    <name>CurrentTime</name>
		    <relatedStateVariable>Time</relatedStateVariable>
		    <direction>out</direction>
		</argument>
	    </argumentList>
	</action>
        <action>
            <name>TimeValid</name>
            <argumentList>
		<argument>
		    <name>Valid</name>
		    <relatedStateVariable>TimeValid</relatedStateVariable>
		    <direction>out</direction>
		</argument>
	    </argumentList>
	</action>
    </actionList>
    <serviceStateTable>
	<stateVariable sendEvents="no">
	    <name>Time</name>
	    <dataType>time</dataType>
	    <!-- <dataType>string</dataType> -->
	</stateVariable>
	<stateVariable sendEvents="yes">
	    <name>TimeValid</name>
	    <dataType>boolean</dataType>
	</stateVariable>
    </serviceStateTable>
</scpd>

Example: UPnP service definition in Java

The generated Java interface is

public interface urn_schemas_upnp_org_service_timer_1 extends Remote {
     void SetTime(time NewTime) throws RemoteException;
     void GetTime(timeHolder CurrentTime) throws RemoteException;
     void TimeValid(booleanHolder Valid) throws RemoteException;
 }

The lack of conformance to Java naming conventions is typical for non-Java middleware systems :-)

Making UPnP services available as Jini services

• A Java-based UPnP service can advertise itself as a Jini service too!
• By combining a Jini LUS into a UPnP service it can advertise using both protocols
• The Jini dynamic proxy can use a SOAP invocation handler to talk directly from a Jini client to a SOAP service

Extensions to Web Services

• The techniques are service agnostic - as long as the service data types are simple enough
• It should be possible to extend this to Web Services

What's in it for Jini?

• The strength of Jini is that it allows a huge amount of flexibility to the Jini service
• Jini services can be implemented in many ways - smart or dumb proxies, security or no security, etc
• Combining the LUS with the service still leaves that flexibility
• Restricting the services to UPnP services removes that flexibility
• But it brings a lower-capability middleware into an almost-equal partnership
• It - importantly - allows Jini to piggyback on the UPnP consortium efforts

Hierarchical services?

A possible use is a sensor network of dumb Jini devices coordinated by a smart Jini client which in turn is a Jini service to other clients

Jini without Java

• An LUS must deliver a MarshalledObject to a request
• The receiver must understand what to do with a Java object
• The producer doesn't: it could just read this object out of a file and squirt it to the receiver
• Even a very stupid service could send a marshalled LUS containing a service proxy to an enquirer
• A smart preparer could write a marshalled object into a file for a dumb service
• Jini on a Nutshell :-)

Current status

• Proof of concept LUS written
• Hand-built service proxies written for proof of concept
• Example joint Jini/UPnP service hand-built
• Generation of Jini interfaces from UPnP XML description done
• Writing SOAP invocation handler underway