Author: buildbot
Date: Thu Dec 16 16:10:03 2010
New Revision: 780793
Log:
Staging update by buildbot
Added:
websites/staging/river/trunk/content/river/spec/
websites/staging/river/trunk/content/river/spec/devicearch-spec.html
websites/staging/river/trunk/content/river/spec/discovery-spec.html
websites/staging/river/trunk/content/river/spec/discoveryutil-spec.html
websites/staging/river/trunk/content/river/spec/entry-spec.html
websites/staging/river/trunk/content/river/spec/event-spec.html
websites/staging/river/trunk/content/river/spec/images/
websites/staging/river/trunk/content/river/spec/images/devicearch-spec2.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/devicearch-spec3.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/devicearch-speca.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/discovery-spec2.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/discovery-spec3.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/discovery-spec4.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/discovery-speca.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/event-spec2.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/event-spec3.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/event-spec4.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/event-speca.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/jini-spec2.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/jini-spec3.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/jini-spec4.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/jini-speca.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/jinilogo.75w.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/js-speca.gif (with
props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec10.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec11.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec12.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec13.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec14.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec15.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec16.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec17.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec18.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec19.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec2.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec20.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec21.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec22.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec23.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec24.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec25.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec26.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec27.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec28.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec29.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec3.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec4.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec5.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec6.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec7.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec8.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-spec9.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servicediscutil-speca.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/servnUI.gif (with
props)
websites/staging/river/trunk/content/river/spec/images/servonly.gif (with
props)
websites/staging/river/trunk/content/river/spec/images/txn-spec2.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/txn-spec3.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/txn-spec4.gif
(with props)
websites/staging/river/trunk/content/river/spec/images/txn-speca.gif
(with props)
websites/staging/river/trunk/content/river/spec/jini-spec.html
websites/staging/river/trunk/content/river/spec/joinutil-spec.html
websites/staging/river/trunk/content/river/spec/js-spec.html
websites/staging/river/trunk/content/river/spec/jxpnote-spec.html
websites/staging/river/trunk/content/river/spec/lds-spec.html
websites/staging/river/trunk/content/river/spec/lease-spec.html
websites/staging/river/trunk/content/river/spec/leaseutil-spec.html
websites/staging/river/trunk/content/river/spec/lookup-spec.html
websites/staging/river/trunk/content/river/spec/lrs-spec.html
websites/staging/river/trunk/content/river/spec/mailbox-spec.html
websites/staging/river/trunk/content/river/spec/schema-spec.html
websites/staging/river/trunk/content/river/spec/servicediscutil-spec.html
websites/staging/river/trunk/content/river/spec/serviceui-spec.html
websites/staging/river/trunk/content/river/spec/standard.css
websites/staging/river/trunk/content/river/spec/txn-spec.html
Added: websites/staging/river/trunk/content/river/spec/devicearch-spec.html
==============================================================================
--- websites/staging/river/trunk/content/river/spec/devicearch-spec.html (added)
+++ websites/staging/river/trunk/content/river/spec/devicearch-spec.html Thu
Dec 16 16:10:03 2010
@@ -0,0 +1,286 @@
+<!--
+ ! Licensed to the Apache Software Foundation (ASF) under one
+ ! or more contributor license agreements. See the NOTICE file
+ ! distributed with this work for additional information
+ ! regarding copyright ownership. The ASF licenses this file
+ ! to you under the Apache License, Version 2.0 (the
+ ! "License"); you may not use this file except in compliance
+ ! with the License. You may obtain a copy of the License at
+ !
+ ! http://www.apache.org/licenses/LICENSE-2.0
+ !
+ ! Unless required by applicable law or agreed to in writing, software
+ ! distributed under the License is distributed on an "AS IS" BASIS,
+ ! WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ ! See the License for the specific language governing permissions and
+ ! limitations under the License.
+ !-->
+
+<html>
+
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<meta name="GENERATOR" content="Quadralay WebWorks Publisher 5.0.4">
+<meta name="LASTUPDATED" content="Wed Oct 25 11:09:21 2000">
+<link rel="StyleSheet" href="standard.css" type="text/css" media="screen">
+<title>Jini Device Architecture Specification</title>
+</head>
+
+<body bgcolor="#ffffff">
+
+<a href="#skip" title="Skip navigation bar"></a>
+<table width="100%"><td align=left><tr>
+<td align=left><a href="../../spec-index.html">Spec Index</a>
+<td align=right><i>Jini Device Architecture Specification</i></td>
+</tr>
+</table>
+<a name="skip"></a>
+<br clear="all">
+
+
+<hr align="left">
+<table width="90%">
+<tr>
+<td align="right" font size="4"><b>Version 1.0</b></td>
+</tr>
+</table>
+
+<blockquote>
+<h2 align="left"><a name="1028364"> </a>DA - Jini<font
size="-1"><sup>TM</sup></font> Device Architecture Specification
+</h2>
+<h3 class="Heading2">
+ <a name="1028365"> </a>DA.1 Introduction
+</h3>
+<p class="Body">
+ The Jini<font size="-1"><sup>TM</sup></font> technology infrastructure is
built around the model of clients looking for services. The notion of a service
encompasses access to information, computation, software that performs
particular tasks, and in general any component that helps a user accomplish
some goal. Services can themselves be clients of other services, and can be
grouped together to provide higher-level functionality.
+</p>
+<p class="Body">
+ <a name="996929"> </a>The Jini architecture requires a service to be defined
in terms of a data type for the Java<font size="-1"><sup>TM</sup></font>
programming language that can then be implemented in different ways by
different instances of the service. A service can be a member of many different
types, allowing a single service instance to provide a variety of functionality
to clients. This is a standard practice in object-oriented software. However,
the distributed nature of a system of Jini technology-enabled services and/or
devices allows data types for the Java programming language to be implemented
in a combination of software and hardware in a way that is unique.
+</p>
+<p class="Body">
+ <a name="996902"> </a>The core of the idea that enables this implementation
flexibility is quite simple. Services are defined via an interface, and the
implementation of a proxy supporting the interface that will be seen by the
service client will be uploaded into the lookup service by the service
provider. This implementation is then downloaded into the client as part of
that client finding the service. This service-specific implementation needs to
be code written in the Java programming language (to ensure portability).
However, since this code comes from the actual instance of the service being
used, it can know in great detail the specifics of the particular service
implementation for which it is the proxy. Not only can the code that is
downloaded know about the software used to implement the service, the code can
know specifics about the hardware on which the service resides. In the limit
case of this, the hardware could be all that there is to the service, and the do
wnloaded software could act as a network-level device driver, taking method
calls in the Java programming language from the client and generating specific,
hard-coded requests to the hardware on the other end of the network wire.
+</p>
+<p class="Body">
+ <a name="996903"> </a>This approach to services requires that there be a
piece of code written in the Java programming language that can be downloaded
by the client of the service and some hardware that ultimately runs the
service. Between these two points, however, there are a number of options
concerning the software structure, hardware structure, and location of
components that can be chosen by the service provider. These options allow
trade-offs to be made in the functionality provided and the cost of the
underlying hardware.
+</p>
+<p class="Body">
+ <a name="996904"> </a>In what follows we begin by discussing in more detail
the requirements placed on a service to be part of a system of Jini
technology-enabled services and/or devices. We then discuss some examples of
combinations of software and hardware that can be used to implement Jini
technology-capable services once the specialized implementations in hardware
begin to play a role.
+</p>
+<h4 class="Heading3">
+ <a name="996905"> </a>DA.1.1 Requirements from the Jini Lookup Service
+</h4>
+<p class="Body">
+ <a name="996906"> </a>The actual offering of a service places very few
requirements on the entity that makes the offer; indeed, it is possible to
implement a device using a Jini technology-enabled software services that
offers a service in such a way that the code written in the Java programming
language that is downloaded by the client transmits bit patterns to the
hardware that are directly interpreted. In such cases the amount of
intelligence needed for a a Jini technology-enabled device is minimal. The code
written in the Java programming language could talk directly to the device
controller in much the same way that the device would be talked to if it were
on the local computer's bus (with, of course, some modifications for dealing
with the network-centric aspects of the communication).
+</p>
+<p class="Body">
+ <a name="996907"> </a>Unfortunately, providing a service is only part of
what is needed to be a Jini technology-enabled service. To be part of a system
of Jini technology-enabled services and/or devices, a service must also be able
to participate in the Jini discovery protocol and register itself into the
local Jini lookup service. This is how a service makes itself known to the
djinn, and how the service is accessed by other members of the djinn.
+</p>
+<p class="Body">
+ <a name="996908"> </a>These two requirements are intimately connected. The
major goal of the Jini discovery protocol is to allow a device or service to
obtain a Java Remote Method Invocation (Java RMI) reference to the local Jini
lookup service. Once this reference has been obtained, the service needs to
register itself in that Jini lookup service, allowing other participants in the
djinn to find and use the service.
+</p>
+<p class="Body">
+ <a name="996909"> </a>The interface to the Jini lookup service is a full
Java RMI interface, and the implementation of that service uses all of the
mechanisms of Java RMI, including the distributed garbage collection and the
dynamic downloading of code. As such, there is an implicit assumption that the
service that holds a reference to the Jini lookup service lives inside a full
Java virtual machine (JVM) that is at least capable of running the full Java
RMI system.
+</p>
+<p class="Body">
+ <a name="996910"> </a>This assumption is most evident if we consider the
possibility of alternate implementations of the Jini lookup service, which
might support remote interfaces beyond that specified by the Jini lookup
service itself (currently the interface <code
class="Code">net.jini.core.lookup.ServiceRegistrar</code>). Such an
implementation would have a different Java RMI proxy than the current
implementation, which would be downloaded if the device had a full JVM and Java
RMI runtime. Devices without a full JVM and Java RMI runtime would need a
different way of dealing with such implementations of the service.
+</p>
+<p class="Body">
+ <a name="996911"> </a>In addition to the need to download the stub code for
the Jini lookup service, registering with the service requires the creation of
an object of type <code class="Code">net.jini.core.lookup.ServiceItem</code>,
which is itself made up of a set of objects in the Java<font
size="-1"><sup>TM</sup></font> programming language. Maintenance of these
entries in the Jini lookup service can require the creation of other objects in
the Java programming language of the type <code
class="Code">net.jini.core.entry.Entry</code>. All of these objects are most
easily constructed by using a running JVM.
+</p>
+<p class="Body">
+ <a name="996747"> </a>Finally, registrations with the Jini lookup service
are leased, with the lease that is returned requiring renewal for the service
to continue to be shown in the lookup service. The specification of the lookup
service does not include a specification of the lease object that is returned
by a registration. All that is specified is an interface written in the Java
programming language that must be supported by the (local) object that is
returned as the lease. Thus the design of the Jini lookup service requires that
the code that implements the class that in turn implements the <code
class="Code">net.jini.core.lease.Lease</code> interface be downloaded into the
service that registers so that the lease can be renewed.
+</p>
+<h3 class="Heading2">
+ <a name="1000290"> </a>DA.2 Basic Device Architecture Examples
+</h3>
+<p class="Body">
+ Now we will look at three different approaches for implementing a a Jini
technology-enabled service in hardware. Each of the approaches will look the
same to a client of the service. Each approach takes a different route to
interacting with the Jini lookup service and in providing an interface written
in the Java programming language to clients of that service. In each case, a
different trade-off was made between the complexity of the device, the
flexibility of the device, and the directness of the communication between the
client wanting to use the service and the device that implements the service.
+</p>
+<p class="Body">
+ <a name="1000292"> </a>All but the first of the examples make use of
<em>interposition</em>, that is, the ability of a service to add a proxy
between itself and the client of the service. The service can use this proxy as
an agent to the Jini technology infrastructure, off-loading from the service
some of the work needed to join the federation of Jini technology-enabled
services and/or devices.
+</p>
+<p class="Body">
+ <a name="1000293"> </a>The examples given in this chapter are not the only
options available to the service designer who wishes to produce a service that
includes a hardware component. Rather, the examples are meant to show some
samples of the range of implementation possibilities that are open to such
designers. In effect, this document is meant to show that, within the overall
Jini architecture, there is no single Jini device architecture. Instead, the
device space is freed up, allowing different services to have hardware
implementations with different price, performance, functionality, and
flexibility design points.
+</p>
+<h4 class="Heading3">
+ <a name="1000294"> </a>DA.2.1 Devices with Resident Java Virtual
Machines
+</h4>
+<p class="Body">
+ <a name="1000295"> </a>An obvious design for a device that can become part
of a federation of Jini technology-enabled services and/or devices is one that
includes the computing power, memory, and nonvolatile store necessary to have a
full JVM and those parts of the Java application environment necessary to
support the Jini technology infrastructure (in particular, those parts needed
for code loading, Java RMI, and any required security). This would make the
device into a specialized computing entity, with part of the device dedicated
to the parts of the Java platform required by the Jini architecture. On this
approach, the hardware implementation is abstracted behind a device-local
software abstraction, which in turn is abstracted behind the proxy code used by
the client to contact the service. This sort of architecture is shown in Figure
DA.2.1.
+<br><CENTER><img src="images/devicearch-speca.gif" alt="Shows two nodes on a
Network - Service Client (containing Client (containing Proxy)) and Service
Provider (containing Hardware Implementation and JVM). There is an arrow and
the words Private Protocol pointing from the JVM to the Hardware
Implementation. The action, indicated by a dashed arrow from the Service Client
to the Network, along the Network, and to the Service Provider, is
communication via the Java RMI protocol." height="311" width="480">
+</CENTER>
+<a name="1000326"> </a><div class="TableTitle">Figure DA.2.1: A Full Jini
Technology-Enabled Device</div><p class="Body">
+ <a name="1003431"> </a>Such a device would be able to make full use of Jini
technology and Java technology, uploading code that is used to communicate with
the device and downloading code that might be needed for the service provided
by the device. Such a device can make use of the native Java RMI protocol for
communication over the network, and has a loose tie between the communication
protocol and the particular software protocol governing the running of the
device itself. On this approach, the device becomes a specialized network
appliance offering a particular service (or set of services) via an embedded
Java platform.
+</p>
+<p class="Body">
+ <a name="1000327"> </a>In effect, this approach uses a hardware
implementation for the local implementation of a Java RMI server, isolating the
hardware behind two levels of indirection. The first is that provided by the
local proxy code that is uploaded into the Jini lookup service and then
downloaded into the client of the service. Additionally, the local JVM and code
written in the Java programming language resident on the service device allow
mediation between the client proxy and the hardware itself.
+</p>
+<p class="Body">
+ <a name="1000328"> </a>A device that took this approach could easily have
multiple services implemented on the device in a way that was mediated by the
JVM on the device. Further, such a device could be evolved with no impact on
the client or the network protocol used between the client and the service,
since any change in the hardware would be seen only by the JVM and any
server-side code that talked directly to the hardware.
+</p>
+<p class="Body">
+ <a name="1000329"> </a>While simple and flexible, this approach does add
some cost to the device. In particular, the device would need to have a
microprocessor capable of running the JVM, some memory in which to create and
store classes, and some nonvolatile store (either disk or NVRAM) from which to
load the JVM and Java class files. All of these are in addition to the hardware
needed to implement the a Jini technology-enabled service that the device
provides. This extra hardware will increase the cost of producing the device.
+</p>
+<p class="Body">
+ <a name="1000330"> </a>Meeting these requirements does not call for a hosted
version of the JVM or a full version of the Java platform running on the
device. The JVM could run on any form of microkernel or directly on the
hardware of the device. Further, there are large parts of the Java platform
that would not be required for the minimal device--such things as the graphics
and user interface classes, which form a significant chunk of the current
release, would not be needed. Other parts of that release could also be
dropped, allowing a stripped-down Java platform to suffice for Jini
technology-enabled devices. It would be worthwhile to determine the exact
definition of such a subset of the Java platform and size that component; it
would be something close to the definition of embedded Java technology with the
additional classes needed to support Java RMI.
+</p>
+<p class="Body">
+ <a name="1000331"> </a>What is important for this kind of approach is for
the device to be able to download any code written in the Java programming
language (although whether that code is run could depend on the local security
manager), utilize the Java RMI communication system, and handle the
requirements of a general virtual machine. By presenting a standard JVM, the
device gets full membership in a federation of Jini technology-enabled services
and/or devices and complete flexibility in the ways in which the machine
communicates between the proxy it provides other members of the federation and
the device itself.
+</p>
+<h4 class="Heading3">
+ <a name="1000332"> </a>DA.2.2 Devices Using Specialized Virtual
Machines
+</h4>
+<p class="Body">
+ <a name="1000333"> </a>We can lower the barrier to entry for a device
manufacturer if that manufacturer is willing to give up some of the flexibility
provided by the Jini architecture. This can be done by allowing the device to
become part of a Jini system of services and/or devices using Jini technology
with a specialized virtual machine that is tuned to allow only those operations
needed by the Jini discovery protocol and Jini lookup service.
+</p>
+<p class="Body">
+ <a name="1000334"> </a>To do this, the device manufacturer would need to
implement the interfaces to the Jini discovery and Jini lookup service in the
device itself, include specialized knowledge of the kind of leases that are
handed out by the Jini lookup service and be able to renew those leases
directly, and have sufficient functionality to download and use the stubs for
these services. This is a particular set of functionalities that is
considerably smaller than that required by the whole of the JVM, and should be
possible to implement in much less code. For example, such a JVM would not need
to contain a security manager, a code verifier, or a number of the other
components that are required for a full JVM.
+</p>
+<p class="Body">
+ <a name="1000335"> </a>Such a device would contain a JVM specialized for the
application environment for Jini technology, allowing the Jini discovery and
Jini lookup services to be accessed and leases of a particular sort to be
renewed. This would limit the flexibility of such a device, as the device would
not be able to have software changes made over time to the protocol used by the
proxy for the device. The specialized knowledge of the kind of lease that is
handed out by the lookup service would also tie such a device to a particular
implementation of the lookup service. However, this penalty in serviceability
might not outweigh the simplicity of the overall device.
+</p>
+<h4 class="Heading3">
+ <a name="1000336"> </a>DA.2.3 Clustering Devices with a Shared
Virtual Machine (Physical Option)
+</h4>
+<p class="Body">
+ <a name="1000337"> </a>A third approach uses a full JVM, but amortizes the
cost of the JVM (both software and hardware) over a number of different
devices. In this approach, a group of devices each uses a physically co-located
JVM as an intermediate layer between the device and the system of services
and/or devices using Jini technology. The device loads code written in the Java
programming language into this local virtual machine, allowing that local
machine to interact with the device, and then delegates to the local JVM the
requirements of interacting with the Jini lookup service, Jini discovery, and
Jini leasing.
+</p>
+<p class="Body">
+ <a name="1000338"> </a>This approach is very much like the first one
discussed in this section, except that the JVM used by the devices is shared.
It is still a full JVM, allowing the downloading of code and complete Java
platform functionality. However, the most likely implementation of such a
device would allow multiple (and perhaps different) kinds of physical devices
to be plugged into the overall device to get the sharing of the Java
application environment.
+</p>
+<p class="Body">
+ <a name="1000339"> </a>Such a device might best be thought of as a "Jini
device bay." This bay could provide power, a network connection, and a
processor running a JVM and appropriate parts of the Java platform. Physical
devices that are used to provide a particular kind of Jini technology-enabled
service could be plugged into the device bay and announce themselves to the bay
in whatever way the two decided was appropriate. This could be using a
proprietary protocol (allowing a device manufacturer to produce both the basic
device or devices and the device bay) or some other industry standard,
local-device identification scheme.
+</p>
+<p class="Body">
+ <a name="1000340"> </a>As part of the local announcement, a new device would
tell the device bay where to find the code written in the Java programming
language that is needed by a client of the service, and (possibly) where to
find code that would allow the device bay to interact with the device. This
allows devices to carry their own "drivers," both for the local machine and at
the network level.
+</p>
+<p class="Body">
+ <a name="1000341"> </a>Upon detection of the new local device, the Jini
technology-enabled device bay would register the services provided by the new
device (previously known by the device bay) with the Jini lookup service. It
would be the role of the device bay to renew leases on the Jini lookup service
entries, and to detect removal of any of the devices for which it was acting as
proxy. The device bay would provide the Jini lookup service with the code
handed to it by the device so that service clients could download that code.
+</p>
+<p class="Body">
+ <a name="1027595"> </a>The client of the device service would believe that
it is talking to the device registered in the Jini lookup service, but would
actually be talking to the device bay. The device bay would act as a dispatcher
to the particular device for which it was acting as a proxy, along with any
translation of protocol between the network protocol used by the service proxy
and the protocol used between the device bay and the actual device.
Graphically, the architecture of such an approach is shown in Figure DA.2.2.
+<br><CENTER><img src="images/devicearch-spec2.gif" alt="Shows two nodes on a
Network - Service Client (containing Client (containing Proxy)) and Service
Providers (containing 3 Java Devices and JVM). There are arrows pointing from
the JVM to each of the Java Devices, and the words Java Device Bay outside the
block. The action, indicated by a dashed arrow from the Service Client to the
Network, along the Network, and to the Service Provider, is communication via
the Java RMI protocol." height="331" width="480"></CENTER>
+<a name="1027650"> </a><div class="TableTitle">Figure DA.2.2: Clustering
Multiple Devices With a Single Proxy in One Device</div><p class="Body">
+ <a name="1026931"> </a>The savings for the device manufacturer in this case
comes from the ability of multiple physical devices to share a device bay,
which contains the intelligence, memory, and perhaps other components (such as
the power supply). By sharing these resources among multiple devices, the extra
cost and engineering needed to interact with a system of services and/or
devices using Jini technology can be amortized over a large number of devices.
+</p>
+<p class="Body">
+ <a name="1000396"> </a>The cost of this approach to the device manufacturers
is that the protocol between the device acting as the Jini technology-enabled
device bay and the devices that are placed in that bay must be defined in
advance and cannot change over time. Because there is no way of introducing
dynamic behavior in the particular devices, the pairing of device and Jini
technology-enabled device bay must be controlled and known beforehand.
+</p>
+<p class="Body">
+ <a name="1000397"> </a>It should be noted that the Jini technology-enabled
device bay itself is a Jini technology-enabled device, which can be thought of
as providing services to those devices housed within it. As such, it could be a
revenue item in its own right. Variations in the implementation could be
provided to support various internal announcement protocols (device bay,
jetsend, etc.) or hardware buses (including network-like buses such as
firewire).
+</p>
+<h4 class="Heading3">
+ <a name="1000398"> </a>DA.2.4 Clustering Devices with a Shared
Virtual Machine (Network Option)
+</h4>
+<p class="Body">
+ <a name="1000399"> </a>A variation on the device bay approach uses the
network rather than a physical enclosure and backplane. On this alternative, a
proxy for the JVM used by the various service devices would exist on the
network. Service devices could be added to the network, discover the existence
of such a proxy device, and register with that proxy. Such a registration could
include the code written in the Java programming language needed by a client of
the device (either directly or as a URL to use to obtain the code) and code
needed by the proxy to communicate with the service device.
+</p>
+<p class="Body">
+ <a name="1027018"> </a>When a service device registers with such a network
proxy, the proxy device would register with the Jini lookup service on behalf
of the service device, thus allowing the service device to become a part of the
federation of Jini technology-enabled services and/or devices. Requests to the
new service would go first to the proxy for that device, which could then
forward the requests (after appropriate protocol translation) to the particular
service device. In addition, the proxy could handle the Jini
technology-specific tasks such as renewing leases for the service. This
alternative is shown in Figure DA.2.3.
+<br><CENTER><img src="images/devicearch-spec3.gif" alt="Shows two nodes on a
Network - Service Client (containing Client (containing Proxy)) and Network
Proxy (containing JVM). Also on the Network are three devices, labeled Service
Providers. There is a grey arrow pointing from the JVM to the Network, and grey
arrows from the Network to each of the Service Providers. Action is also
indicated by a dashed arrow from the Service Client to the Network, along the
Network, and to the Service Provider." height="384" width="480"></CENTER>
+
+<a name="1027075"> </a><div class="TableTitle">Figure DA.2.3: Clustering
Devices With a Jini Technology-Enabled Proxy on the Network</div><p
class="Body">
+ <a name="1026937"> </a>This alternative requires somewhat more hardware for
the individual device, as it requires each service device using such a proxy to
be able to be placed on the network and have its own power supply and network
connection. However, the devices would not need individual CPUs, memory, or
persistent store; all of that would be provided by the networked proxy for the
Jini technology-enabled device.
+</p>
+<p class="Body">
+ <a name="1026890"> </a>Devices using this option would need to have a
protocol parallel to the Jini discovery protocol between the individual service
devices and the network proxy for those devices. This could be a specialized
code on the network, known in advance, that the devices can use to identify
themselves to the network proxy. This will have to be particular to the device
and the proxy for that device. However, once this protocol has been decided
upon, no other intelligence needs to be built into the device. All of the
intelligence can be built into the network proxy, perhaps uploaded into the
proxy by the service device (which could easily carry code written in the Java
programming language, even though it cannot execute that code). The protocol
the network proxy uses to talk to the devices for which it is a proxy also
needs to be statically defined in advance and cannot be changed. However, it
can be any protocol the particular device needs.
+</p>
+<p class="Body">
+ <a name="1026891"> </a>In this approach, the individual devices will be more
complex than they would be in the Jini technology-enabled device bay approach.
However, the number of devices that can be served by a network available proxy
is not limited by the physical constraints of the proxy device. Nor is there
any requirement that the devices and the proxy device be co-located, which is a
requirement on the physical clustering scheme.
+</p>
+<p class="Body">
+ <a name="1000458"> </a>This is also the approach that can be taken to build
"gateways" between the Jini technology-enabled devices and other
network-managed devices. Such devices, which already speak a particular
protocol, can be spliced into the system of Jini technology-enabled services
and/or devices by providing a network proxy that speaks the Jini technology
protocols on behalf of such devices, and the existing specialized protocol to
such devices. This is the approach that can be used to add consumer electronic
devices, factory controls, or home environment controls into the system of Jini
technology-enabled services and/or devices.
+</p>
+<h4 class="Heading3">
+ <a name="1000459"> </a>DA.2.5 Jini Technology-Enabled Software
Services over the Internet Inter-Operability Protocol
+</h4>
+<p class="Body">
+ <a name="1000460"> </a>A final method for connecting devices or services
that are not purely based on Java technology software into a system of Jini
technology-enabled services and/or devices, centers on using the Object
Management Group (OMG)'s Internet Inter-Operability Protocol (IIOP). This
protocol defines a standard for data transmission that will be supported by a
subset of Java RMI.
+</p>
+<p class="Body">
+ <a name="1000461"> </a>This approach relies on the ability of a device to
read an IIOP stream directly, either because the device includes an
implementation of a Common Object Request Broker Architecture (CORBA) Object
Request Broker (ORB) or because the device knows what IIOP streams to expect
and can interpret streams of these known forms directly.
+</p>
+<p class="Body">
+ <a name="1000462"> </a>This approach requires the Jini lookup service to
supply implementations of its interfaces over both the native Java RMI protocol
and the IIOP protocol. This is supported by Java RMI over IIOP as long as the
interfaces conform to any subsetting requirements established by the OMG. At
the present time it appears that the Jini lookup service interfaces are in
conformance with the Java RMI over IIOP subset.
+</p>
+<p class="Body">
+ <a name="1027465"> </a>Devices that contain a CORBA ORB could directly
interact with the Jini lookup service using the IIOP protocol. The fact that
the Jini lookup service generated this protocol via Java RMI would be
transparent to the service itself, and the fact that the service was using a
method other than Java RMI to reply to the Jini lookup service (to renew
leases, for example) would be transparent to the Jini lookup service. Current
differences between the Java RMI programming model and the CORBA programming
model would need to be dealt with by the device itself; for example, the device
would not be able to download the implementation of the stub for the Jini
lookup service, and would need an implementation of the <code
class="Code">Lease</code> class used by the Jini lookup service.
+</p>
+<p class="Body">
+ <a name="1000464"> </a>Devices that do not include a CORBA ORB could
directly interpret the IIOP stream and attempt to interact with the Jini lookup
service. This approach requires very little software support on the side of the
device (since the bitstream from the wire is being directly interpreted).
However, it is an approach that will work only with known versions of the Jini
lookup service that exports known implementations of a lease. Any alteration of
either the lease implementation or the protocol used by the Jini lookup
service, even those that would be invisible to other clients of the service,
would make it impossible for the device directly interpreting the IIOP protocol
to interact with the new version of the service. Hence this alternative, while
lowest in cost with respect to the hardware and software needed by the device,
is also the least reliable in the face of implementations that can change over
time or that are open to alternate implementations.
+</p>
+<p class="Body">
+ <a name="997129"> </a>
+</p>
+
+<h3 class="Heading2">
+ <a name="43987"> </a>DA.3 History</h3>
+<p>
+<table align="center" border="1" bordercolorlight="#FFFFFF"
bordercolordark="#000000" cellpadding="5" cellspacing="0" summary="history of
this specification">
+ <caption><p class="Body">
+ <a name="01887"> </a>
+</p>
+</caption>
+ <tr bgcolor="#CCCCCC">
+ <th>Version</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td valign="top">v1.0
+ </td>
+ <td>Initial release of this specification.
+</td>
+ </tr>
+</table>
+<h3 class="Heading2">
+ <a name="0188"> </a> License
+</h3>
+<p>
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+<ul>
+ <a
href="http://www.apache.org/licenses/LICENSE-2.0";>http://www.apache.org/licenses/LICENSE-2.0</a>
+</ul>
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+</blockquote>
+
+<hr>
+<a href="#skip" title="Skip navigation bar"></a>
+<table width="100%"><tr>
+<td align=left><a href="../../spec-index.html">Spec Index</a>
+<td align=right><em>Jini Device Architecture Specification</em></td>
+</tr></table>
+<a name="skip"></a>
+
+<hr>
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+<ul>
+ <a
href="http://www.apache.org/licenses/LICENSE-2.0";>http://www.apache.org/licenses/LICENSE-2.0</a>
+</ul>
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+</body>
+</html>
+
+<!-- This HTML file was initially created with Quadralay WebWorks Publisher
3.5.0 -->
+<!-- by Susan Snyder -->
+<!-- Last updated: 01/27/05 -->
