

%\documentstyle[times,art10,twocolumn,latex8]{article}
%\documentstyle[times,twocolumn,latex8]{article}

\documentclass[times,10pt,twocolumn]{article}
\usepackage{latex8}
\usepackage{times}
\usepackage{graphicx}


%------------------------------------------------------------------------- 
% take the % away on next line to produce the final camera-ready version 
\pagestyle{empty}

\begin{document}

\title{UPnP Services and Jini Clients}

\author{Jan Newmarch\\
School of Network Computing\\
Monash University\\
jan.newmarch@infotech.monash.edu.au
}

\maketitle
\thispagestyle{empty}

\begin{abstract}
UPnP is middleware designed for network ``plug and play''.
It is designed to manage {\em devices}, unlike more
general middleware such as Jini which is designed to manage
{\em services}. Since UPnP uses more simplistic technologies
than Jini, it has appeared to be easier to build and deploy
UPnP devices than Jini devices. This paper shows how UPnP
devces can also expose themselves as Jini devices in a fairly
easy manner, and discusses the advantages of having UPnP devices
available within a more general purpose service middleware.
\\
\\
Keywords: Middleware, UPnP, Jini, Service oriented architecture, Embedded systems

\end{abstract}

%------------------------------------------------------------------------- 
\Section{Introduction}

I am a professor at an Australian university. My responsibilities are to do research and
teaching, to communicate my research findings to the wider community and to teach to my
students. Right up front, I find a contradiction: why is my research supposed to be communicated 
widely, but my teaching only locally?

I am paid by the Australian government, and like most academics I can do contract work under 
limited conditions. Otherwise I am expected to devote most of my time, ideas and work under
the auspices of my government employment, which I take to mean ``for the public good''. This is
not a universal attitude, and is not even universally accepted in the Open Source movement:
I have many times been criticised for saying ``I am making this open because I am a public servant''.

In 1995 I came across the Web, and adopted it as my coursework delivery mechanism because the Mosaic
browser offered the first feasible mechanism whereby I could prepare lecture materials under Unix
and my students could access it using the Microsoft O/S (even if they had to jump through hoops
at that time to get internet access). Since then I have made all of my courseware, my publications
and even a textbook available on the Web, as public access materials.

In this paper, I want to discuss a range of issues related to open content documents.















UPnP (Universal Plug and Play)  is an industry standard to 
allow devices to be added seamlessly into
a small network such as a home network [1]. The technologies underlying UPnP
have been developed steadily since 1998, and UPnP is now based on the following:
TCP, UDP and multicast network protocols in addition to search protocols
such as HTTPU and HTTPMU and method invocation by SOAP. The UPnP consortium
has standardised a number of devices such as light switches through to A/V players.
However, the UPnP middleware is ``device-centric'' and does not contain mechanisms
to share in general service-based middleware systems.

There are an increasing number of service-based middleware systems, including Jini [2]
and Web Services [3]. While Web Services are currently targetted at business systems
with corporate-scale discovery and registration mechanisms, Jini was designed
to support both the kind of adhoc discovery mechanisms that are needed for
zero configuration home systems as well as the larger scale business service
systems.

Nevertheless, Jini has not made inroads into the smaller device markets, in
contrast to UPnP. This paper discusses the technical reasons for this apparent
failure, and shows how a UPnP device can both advertise itself not only as a UPnP
service but also as a Jini service
and hence can be invoked by a Jini client, with minimal overheads on the device. 
The advantages of this ``dual personality'' are discussed.

The structure of this paper is as follows: in the next section we review UPnP and in the
following section do the same for Jini. The next section summarises the differences.
This is followed by a more detailed discussion of mobile objects in Jini. The main results
are given in Section 6, where we restrict Jini to UPnP services. We show that it is
possible to embed a Jini lookup service within a UPnP service with the resultant Jini
service proxy able to talk directly to the UPnP service.
 The following section
discusses our implementation and other possibilities. We then conclude with a discussion
of the value to both Jini and UPnP of this work, and a look at future work.
Our contribution is that we show that it is easy for a UPnP service to be a Jini service as
well, and this increases the scope of use of UPnP devices within a more general service
framework.


In related work,
Allard et al [9] discuss a Jini/UPnP bridge. In this system, specialised software acts as
bridge between the two middleware systems. For each UPnP service instance the bridge
generates a Jini service which it registers with a Jini lookup service. Calls on this
Jini service are transformed into calls on the UPnP device, and returns from this device
are similarly translated back into returns from the Jini service. The advantage of this
method is that it does not require any invasive code in the UPnP device.
The disadvantage is that it requires specific code to be written for each UPnP device
type, and a bridge object to translate between method calls of the two middleware
systems. We do not require additional code to be written, have no bridge object
and the Jini client makes calls directly on the UPnP service without any intermediate
third party.

Pota et al [10] discuss the relationship between Jini and Grid Systems. They also talk about
a bridge object, but consider the possibility of the Jini service proxy talking directly
to the grid service using the grid service's protocol. However, they do not discuss
any implementation features of their work.

JMatos [11] is an existing Jini system that builds a special purpose Jini lookup service.
The proxy for this lookup service can be completely downloaded to the client, so that
as in our system there is no need to have Java to run the lookup service. Their system
is designed for general purpose low-resource systems, while ours is able to take
specific advantage of the tighter environment of UPnP services.

\Section{UPnP and Jini}

UPnP is designed as language agnostic middleware particularly suited
for small network-aware devices in a zero configuration environment. A typical
example of such an environment is the future home, where many mundane devices
such as light switches, air conditioners, etc, through to more sophicated devices
such as A/V storage devices will exist, all with IP networking capability. 
Other possibilities include automobile systems
or sensor networks which require minimal configuration.

UPnP devices advertise themselves by  multicast [3]. Muticast scope typically limits
advertisements to the local network. UPnP devices have no protocol for unicast
advertisements beyond this scope. Clients searching for UPnP devices also make 
requests by multicast, and again there is no unicast mechanism.

Advertisements and searches are performed by using a protocol derived from the 
principles of HTTP requests, but adapted to multicast: text based
messages using a small number of verbs. Advertisements provide information about services
by giving basic device and service information while providing URLs for further
information such as how to control the device. These protocols, known as HTTPMU and
HTTPU have been prescribed by the UPnP consortium.

Services on a device have functions that can be called directly and events which
can be delivered to listeners. Service functions are invoked by SOAP calls,
a protocol borrowed from Web Services. In addition, UPnP devices maintain
state, and changes of state are signalled by changes in state variables.
These changes are notified by unicast to a list of listeners who have
explicitly subscribed to state changes.

Jini is Java-specific middleware. It relies on clients able to interpret Java
bytecodes. It is designed for a general purpose environment, able to take 
advantage of multicast and zero configuration environments and yet also
has unicast mechanisms for general internet services.

Jini makes use of a service registry called a ``lookup service''. Services and clients find
a lookup service by local multicast or by unicast to known locations. Services register
themselves with a lookup service and clients ask it for suitable services.
Services are stored and moved around the network as Java marshalled objects, and are
downloaded to clients where they run in the client's Java virtual machine.

Typically, a client will download a proxy for the service which will communicate using
a protocol such as RMI back to the service. However, Jini does not mandate any particular
proxy/service structure or communication protocol between them. While it happens to be
most common and convenient to use RMI proxies communicating using an RMI protocol,
other possibilities can exist. 

Some services can also generate events, and clients
add themselves as event listeners by sending a client proxy to the service. Again,
while there is much flexibility possible, RMI proxies are usually sent.

\Section{Comparing UPnP and Jini}

While there are some common features between UPnP and Jini, there are also many differences.
These are summarised in Table 1. UPnP uses fixed protocols for all operations:
advertisement, discovery and invocation. On the other hand, Jini only has a fixed
protocol for searching for lookup services and this protocol does {\em not} require
Java. 

UPnP has a very limited set of data types that can be used in method invocation [3]. 
They are the primitive types such as integers, boolean values and strings.
Jini can use any serialisable Java object. This includes structured types such as arrays
in addition to the full set of Java objects as well as the primitive types. 
In adddition, proxies can also define their own protocols and move objects appropriate
to that protocol (e.g. CORBA IIOP references).

There is a cost to this flexibility, in that it requires the movement of Java objects
across the network, usually from one JVM to another.

\begin{table*}
\begin{tabular}{|c||c|c|}
\hline
{\em Property} & {\em Jini} & {\em UPnP} \\
\hline
\hline
 
Service adverts &
via a Lookup Service (LUS) &
Direct multicast \\
\hline

Service discovery &
via an LUS &
Direct multicast \\
\hline

Discovery protocol & 
fixed &
fixed \\
\hline

Service invocation protocol & 
Unspecified (JRMP, Jeri, IIOP, etc) & 
SOAP \\
\hline

Object references & 
Java proxy objects &
URLs or XML documents \\ 
\hline

&
LUS proxy (to client and service) &
\\ \cline{2-2}

&
Service proxy (to client) &
\\ \cline{2-2}

Mobility &
Method call arguments (to service) &
None \\ \cline{2-2}

&
Method call result (to client) &
\\ \cline{2-2}

&
Listener registration (to service and LUS) &
\\ \cline{2-2}

&
Unknown class definitions downloaded from an HTTP server &
\\ \hline


Language &
Java only &
Agnostic \\
\hline

Data types &
Any, including Java objects &
Small set, mainly primitive \\
\hline

\end{tabular}

\caption{Differences between UPnP and Jini}
\end{table*}

Since UPnP is language agnostic and only supports simple data types it does not need
to support any form of object mobility. Jini does, because it needs to get lookup
service proxies to clients and services, and service proxies to clients. Once there,
a Java runtime must be present to handle the proxies. In addition. method calls
that have objects as arguments or return values also require mobility - either to transport
serialisable objects or to transport proxies for remote objects.

The mobile objects in a typical Jini djinn are shown in Figure 1.
\begin{figure*}
\centering
\includegraphics{mobility1}
%\epsfig{file=barbie.eps}
\caption[width=1in]{Mobile objects in Jini}
\end{figure*}

\Section{Restricting Jini to UPnP-like Services}

\SubSection{Restricted datatypes}

If a Jini service only uses the datatypes supported by UPnP, then there is no object mobility
required for method arguments or return values. The primitive types such as integers
and the content of strings can be sent across the network without requiring any
Java object mobility. The parameters and return values do not require Java in either
client or server for UPnP data types.

\SubSection{Invocation protocol}

Jini does not specify the method invocation protocol. In fact, Jini 2.0 [4] has made this
completely configurable so that a service proxy can use any desired invocation mechanism.
In particular, a proxy can be set up to use SOAP, the UPnP invocation protocol [5].
In Jini 2.0 this configurability is used on both sides of the client/service connection:
the proxy in the client may use Jeri to talk to a service also talking Jeri, or the proxy may 
talk JRMP to the service, and so on.

However, there is no need for the service to be implemented as a Jini service. The service
endpoint just needs to understand the protocol used by the proxy.
Thus a Jini service proxy using SOAP can directly invoke a UPnP service without needing a Jini version
of the service at all. While this still requires Java on the client side to run the
proxy, it does not require Java on the service side.

\SubSection{Embedded lookup service}

The standard configuration of a Jini ``djinn'' is have separate clients, services and
lookup services. In this mode, any service must be able to handle a proxy from a
lookup service, requiring a Java runtime. However, it is possible for a service
to run its {\em own} lookup service: the service could have a component that talks the
Jini discovery protocol and on demand (from a client) downloads a lookup service
proxy to the client. The service in this case would only need to listen and respond
to the Jini multicast discovery protocols and these do not involve Java at all.

On request from a client, the service would need to download a lookup service proxy. 
From the service viewpoint, this is just a series of bytes obtained from serialising
the lookup service proxy. While this is generally produced by a Java runtime serialising
a Java object on the fly, it could also be done by a Java process serialising the
object at some prior time and saving it in a file, while the service just delivers the
byte stream from the file. So although a Java runtime would be required at some preparation
staqe, the service would not need to be running Java in order to respond to client requests
and download a lookup service proxy.

\SubSection{Service proxy}

Such a specialised lookup service could be primed to ``only'' know about its own service.
That is, in response to a request from a client for a service, it could answer
affirmatively only if there is a match to the single service it represents. It could 
then return a proxy for the service. How it gets this proxy is not fixed: it could get
it from the Jini service, or generate it directly itself. In the second case, this could
avoid unneccessary conversation with the service.

In Java 1.4 a new class was introduced, the {\tt Proxy} class. This class can be
instantiated with a list of interfaces and will return an object implementing
all of those interfaces. When a method is called on such an object it passes
the call to an invocation object and, as we have already mentioned, this invocation
object could make SOAP calls directly to the UPnP service.

The result of these changes is to reduce object mobility to that of Figure 2.
\begin{figure*}
\centering
\includegraphics{mobility2}
%\epsfig{file=barbie.eps}
\caption[width=1in]{Reduced mobility for UPnP Services}
\end{figure*}

\SubSection{UPnP interfaces}

A UPnP device and its services is defined by an XML document, similar in intent
to WSDL for Web Services [6] but much more straightforward and better designed.
When a UPnP device advertises itself it includes the URL of its device. 
UPnP devices use this to work out how to communicate with 
services. The URL for the device contains URLs for the descriptions of the 
services it offers and also URL endpoints for SOAP invocation of each service.

The service URLs can be used to generate suitable interfaces for Jini services,
and since the service descriptions are often standardised by the UPnP Consortium
they could become ``well known'' Jini service descriptions.

The device URL could be included as part of the specialised Jini lookup service proxy
so that when it is asked for a service by a client it can examine the UPnP XML
device and service description. From the service descriptions it can tell what Jini
service interfaces it offers, and from the SOAP endpoints it can return a service
proxy that can communicate with the UPnP services.

\SubSection{Class files}

The final component that distinguishes the Jini and UPnP protocols is the Jini
requirement to download class files that a client does not already have. With
Jini 2.0 this requirement has been greatly reduced from earlier versions since 
the {\tt Proxy} class can be used to generate a proxy on the fly, and as this is
part of Java 1.4 the client will already have its classes and will not require a
download. However, the client will need to find the classes for the SOAP invocation
layer. If this becomes a common invocation class then clients may have this class
in their class files in future versions of Jini. If not, then since the device has
to run an HTTP server anyway, the classes can simply be placed on its HTTP server
for downloading to clients.

\Section{Implementation}

Based on the above considerations we have implemented a set of Java classes that
will perform the lookup service role of Jini discovery and will return a proxy that can
run entirely within a Jini client. This lookup service proxy is seeded with the URL
for the device XML description. Upon request from the Jini client, it can return a
Jini service proxy that implements all of the Java interfaces derived from the UPnP
services. This service proxy uses SOAP to communicate directly with the UPnP services.

We have designed the service-side classes to run in the Cybergarage Java UPnP
implementation [7]. Cybergaraqe allows services and devices to be written in the Java
SDK and deployed within an IP network. it implements all of the UPnP protocols,
so that its services can be found and invoked by UPnP clients. With the addition
of our classes, the services can also be found and invoked by Jini clients.

Note that this is an invasive mechanism: the UPnP service needs to have code added
to also make it into a Jini service. However, the overheads of this are small,
less than 15k of class files. This is because UPnP already has to support TCP,
UDP and multicast protocols and we are just adding support for another protocol
and creating a lookup service proxy just in order to serialise it.

Although our implementation runs within the Java Cybergarage, this is done for
convenience in serialising a lookup service proxy on the fly. It would be a
straightforward matter to add this to, say, the C++ version of Cybergarage or
to use a different UPnP service platform such as that provided by Intel [8].
This could reduce overheads to a few thousand bytes.
However, configuration and deployment would be a more complex matter.

\Section{Value of work}

Jini has suffered by a lack of standards work for Jini devices and device services,
with a corresponding lack of actual devices. This work allows Jini to
``piggyback'' on the work done now and in the future by the UPnP Consortium
and to bring a range of standardised devices into the Jini environment.
Jini clients will be able to invoke UPnP services in addition to services
specifically designed for Jini.

UPnP is a device-centric service architecture. As mentioned earlier, there are now
many service architectures, including Jini, Web Services and Grid Services. These all
offer environments which include both software and hardware services. However, for a client
to use both a UPnP and a Jini service has previously required the client to talk both sets
of protocols. Our work allows both types of service to be handled within a single
framework, that of Jini. 

For example, a calendar service may be purely implemented in software,
but can be used to set the alarm on hardware-based clocks. If the two types of
service use different middleware systems then it increases the difficulty of
writing clients. Bringing UPnP into the Jini environment makes it easier to
write clients which can access all the services from within Jini.

Note that it is not possible to bring general Jini services
into the UPnP environment due to the probable Java dependencies of most Jini
services.



\Section{Future Work}

Our implementation uses Cybergarage for Java for the services and Jini for
the clients. These both require the standard Java JDK. Neither of them will
currently run on a ``lightweight'' Java J2ME microedition machine such as the
KVM. Work is currently underway to adapt Cybergarage to this VM. This means
defining a new profile at least, since there is no J2ME profile that supports
multicast and the web services profile is not rich enough for UPnP.

Getting Jini to work as a client on the KVM is more difficult since the KVM 
does not support dynamically changing the class loader and the default loader
does not support dynamic remote class loading [12]. However, the KVM specification
states that an alternative default class loader may be used, presumably to allow 
for small machines with different file systems. It may be possible to use
a Jini-aware class loader instead, but this will only work for specialised
versions of the KVM, not for those currently existing. Security issues for the KVM will
also become more important with such a classloader.

We have adopted an approach in which the lookup service is embedded within the UPnP
device. Other authors have looked at bridges between middleware systems. A third
alternative would be a specialised Jini lookup service that listens for UPnP device
announcements and makes Jini service proxies of the nature that we have discussed available
to Jini clients. This would eliminate the invasive nature of our current system, would
not require custom coding,  and would allow Jini clients to talk directly to UPnP
devices without a third party in the middle. However, it would still need a separate
lookup service to be running.

\Section{Conclusion}

We have discussed ways in which UPnP services can also be made available as Jini services,
with low overheads. This can be done both for UPnP devices that understand Java
and for those that don't. We have an implementation for Java-aware devices.
This has been shown to be of advantage both to Jini and to UPnP.

\bibliographystyle{latex8}
% \bibliography{latex8}
\noindent
\begin{thebibliography}{99}
\bibitem{}
UPnP Forum, UPnP Home Page, http://www.upnp.org.
\bibitem{}
K. Arnold, et al, The Jini Specification, 2 nd ed., Reading, Mass.: Addison-Wesley, 2001.
\bibitem
 WWW Consortium, Web Services Home Page, http://www.w3.org/2002/ws/ 
\bibitem{} UPnP, ``UPnP Device Architecture'', 
    http://www.upnp.org/resources/documents/.
\bibitem{}
    J. Newmarch,  ``A Jini Tutorial'',
    http://jan.netcomp.monash.edu.au/java/jini/tutorial.
\bibitem{} 
WWW Consortium, ``SOAP 1.2 Protocol,''
   http://www.w3.org/TR/soap12. 
\bibitem{}
 WSDL 1.0 Specification, http://http://www.ibm.com/developerworks/web/library/w-wsdl.html
\bibitem{} S. Konno, ``Cyberlink for java'' 
http://www.cybergarage.org/net/upnp/java/index.html.
\bibitem{}
Intel, ``Intel Software for UPnP Technology'', 
http://www.intel.com/technology/upnp/
\bibitem{}
  J. Allard, V. Chinta, S. Gundala, G. G. Richard III, "Jini Meets UPnP:
  An Architecture for Jini/UPnP Interoperability,"  Proceedings of the
  2003 International Symposium on Applications  and the Internet (SAINT
  2003)
\bibitem{}
  Sz Pota, K. Kuntner and Z. Juhasz, ``Jini Network Technology and Grid Systems''
  Proc. MIPRO 2003, Hypermedia and Grid Systems, Opatija, Croatia, 19-23. May 2003.
\bibitem{}
  Psinaptic ``JMatos, Jini Network Technology for Embedded Processors''
  http://www.psinaptic.com/j\_matos.jsp
\bibitem{}

  Sun MicroSystems, ``J2ME Connected Limited Device Configuration'',  
  http://java.sun.com/products/cldc/index.jsp
\end{thebibliography}
\end{document}
