%narms.tex, an example driver file for Balkema documents.

%use the following for US Letter paper:
%\documentclass[12pt,twocolumn]{narms}
%use the following for A4 paper:
\documentclass[12pt,a4paper,twocolumn]{narms}

% Preamble

\usepackage{subfigure} % was: subfignarms.sty
\usepackage{psfig}
\usepackage{timesmt}   % use times typeface
\usepackage{chicnarm}


%  Reformat the section header styles for Balkema
% specs.
% Major section must be typed in all caps in the
% document; the following turns of the bold and
% larger font.
\makeatletter
\renewcommand{\section}{\@startsection%
{section}%
{1}%
{0mm}%
{- \baselineskip}%
{0.15\baselineskip}%
{\normalfont\normalsize}}%

%Minor sections must be manually set
% i.e. \subsection{\em ...}; the following
% disables the bold and font change.
\renewcommand{\subsection}{\@startsection
{subsection}%
{2}%
{0mm}%
{-\baselineskip}%
{0.15\baselineskip}%
{\normalfont\normalsize}}%
\makeatother

%  Odd macros of my own making for engineering mathematics.
%\input{engr}

%set up the margins for Balkema specs.  This should
% eventually be rewritten as an option in the
%.cls file.  Note that letter paper just won't take the spec
% and has to be shortened to 260mm.  Use the A4 option
% in the class file if your printer is A4 capable.

\setlength{\topmargin}{-2.2cm}
\setlength{\oddsidemargin}{-15mm}
\setlength{\leftmargin}{-1in}
\setlength{\textheight}{260mm}
\setlength{\textwidth}{187mm}
\setlength{\columnsep}{7mm}
\setlength{\textfloatsep}{13pt}
\setlength{\abovedisplayskip}{8pt}
\setlength{\belowdisplayskip}{8pt}

% Tweak the graphics placement.
\renewcommand{\textfraction}{.1}
\renewcommand{\bottomfraction}{.6}


%Give a little extra space in the equation arrays because
%of all the sums and fractions.
\setlength{\jot}{.2in}

\linespread{0.9} % reduce linespacing.
                 % added by <W.Hennings@fz-juelich.de>

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%  All this stuff is from modifying the article.cls for Balkema
%%%  specifications.
%\title{..title.}
%\author{..autor.}
%\abstract{..abstract.}
\begin{document}
%\maketitle

\title{Zero Configuration for Jini}
\author{\large {Jan Newmarch}\\
{\em School of Nework Computing}\\
{\em  Monash University, Australia}\\
}
\date{}% No date.

\abstract{This is the abstract.}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%  To kick in the changes.
% Make title here for two column format.
\maketitle
\frenchspacing   % no double spaces after colon
                 % added by <W.Hennings@fz-juelich.de>

% Write some ascii text files called intro.tex, concept.tex, etc.
% TeX and LaTeX will look for the .tex subscript by default.

\section{INTRODUCTION}
For networks of ubiquitous devices to become reality, they must run with a minimum -
and preferably <em>zero</em> configuration. That is, it should be possible to add
devices to a network by doing nothing more than plugging them into
a power supply (if needed) and just switching them on. Similarly, removal should
be done by just switching them off. The current mechanisms for configuring devices
in a network are (a) by hand; (b) placing the burden on a netork service such as
a DHCP server (which also needs configuration); or (c) using techniques of
{\em zero configuration}.

While zero configuration plays an important role, it only manages how the device
is known to the network and how it can communicate with other devices in the
network. However, devices are used for a purpose, and that is generally to provide
some sort of <em>service</em>. In order to be effective, zero configuration needs
to be applicable at the service level, so that devices/clients/services can find
other devices/clients/services and make use of them.

There are many service advertisement and discovery systems and these are discussed
in the next section. However, in this paper we concentrate on the Jini middleware,
which was designed for the management of adhoc services. On the face of it, Jini
should be very suitable for a zero configuration environment. However, we show
in this paper that Jini needs some changes: in specifications, in reference
implementations and in the discovery structure of the middleware.

We show in this paper that Jini is <em>almost</em> suitable, both to run
in zero configuration networks and to require zero configuration itself..
However, it needs changes to specifications, implementations and needs more
flexibility in the advertisement architecture. 


\section{ZERO CONFIGURATION}


The IETF Zeroconf working group has established four attributes of zero configuration
networks:
<ul>
  <li>
      IP host addresses
  </li>
  <li>
      Name to address translation
  </li>
  <li>
      IP multicast addresses
  </li>
  <li>
      Service discovery
  </li>
</ul>



Each host on an IP network must have an IP address, which can be hard-coded, found from
a DHCP server, or be self-assigned as a link-local address. By this means, a host in any
IP network can get an IP address. Similarly, names may be hard-coded, found from a DNS
server or be self-assigned. Service discovery is addressed by SLP (Service Location
Protocol) which is considered later.

\section{DISCOVERY SYSTEMS}

There are a large number of service systems, with a variety of ways of advertising
and discovering services. Such ways include "naming service" advertisements where services
register with a separate "well known" naming service. Such systems include RMI, CORBA
and in the future, Web services with UDDI registries. Such systems require configuration
of the naming service, and so are not entirely suitable for zeroconf networks.

UPnP (Universal plug and play) avoids this issue by each device/service advertising itself
directly by multicast to all potential clients. Part of each advert is a URL where
further information about the service can be found, and it is expected that each device/service
will run an HTTP server.

SLP also advertises directly by multicast, but is most cases the advert contains enough
information to invoke the service without requiring further information. Both UPnP services
and SLP services are adapted to zeroconf networks. 

Jini on the other hand is not. A lookup service is required, playing an object-oriented
equivalent to a naming service. In addition, Jini downloads objects from service to client
and this not only requires instance data but also class files. These class files are typically
located on an HTTP server. Running a Jini service typically requires an environment already
containing lookup services and HTTP servers.


\section{JINI IN A ZEROCONF NETWORK}


The Jini specification only requires that all hosts have IP addresses in an IP network.
It does not require host names. The Jini 1.2 implementation however is heavily dependant
on names as it does a name to address resolution in order to find the local host IP
address. In Jini 2 this dependency has been largely removed, and it is possible to configure
a Jini service so that it takes its address from the local host without a name to address
lookup (modulo a minor bug in the <code>LookupDiscovery</code> class).

It is thus possible to run Jini in a zeroconf eonvironment, using hard-coded, DHCP or
self-assigned link-local addresses.

\section{HTTP SERVER}


A UPnP device is expected to run an HTTP server along with all its own device services.
A Jini service may be running on a host that is not running an HTTP server, and indeed,
there may be no HTTP servers running that are accessible. In addition, even if there was
an HTTP server running, a deployment step would require that class files be copied to the
server.

This can be avoided by each Jini service running an HTTP server of its own. That is,
as part of Jini service startup, it sets an HTTP server running where the server root
contains the service's remote class files. The service can then set its own
<code>java.rmi.server.codebase</code> property based on its host name (if available)
or IP address and the chosen HTTP port.


\section{LOOKUP SERVICE}


In a standard Jini environment, both services and client send multicast requests
for a lookup service. Any lookup service getting this request will reply. After this
a unicast conversation follows, in which services upload a service description to the
lookup service and clients download this description. If there is no lookup service
present, then clients and services cannot find each other.

The standard Jini lookup service from Sun is called "reggie".
We have implemented a "half reggie" which runs from within a service.
A Jini service tries to find a lookup service (or "full reggie") in the usual way.
If it fails after some suitable timeout, it starts up its own half-reggie.
The service registers itself directly with this half-reggie. The half-reggie will
respond to requests from clients and services by engaging in a unicast conversation
and sending a registrar proxy as usual. If a client requests the service registered
with the half-reggie then this is also sent to the client in the normal way.
A client just sees the half-reggie as a normal Jini lookup service.

A separate service may also locate a half-reggie lookup service and attempt to
register with it. An implementation choice could allow this to succeed, or it could deny
it. Either way if okay. If the half-reggie accepted external requests then it would
be acting like an ordinary lookup service with a short-cut for registration of the
local service. On the other hand it could deny such an attempt, to keep memory usage
to a minimum. Our current implementation takes the second course, and the implications
of this are discussed later.


\section{PERFORMANCE}


\section{CONCEPTUAL MODEL}
This is the concept.

%hint: for citations according to Balkema style, use "\shortcite{key}"
%      instead of "\cite{key}

\section{ANALYSIS}
This is the analysis.

\section{EXAMPLES}
--examples--

\section{CONCLUSIONS}
This is the conclusion.

\newpage

\bibliographystyle{chicnarm}
\bibliography{mybib} % These is my BiBTeX reference list.

\end{document}

