river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter_firmst...@apache.org
Subject svn commit: r896336 [1/5] - /incubator/river/jtsk/trunk/doc/specs/html/
Date Wed, 06 Jan 2010 07:11:40 GMT
Author: peter_firmstone
Date: Wed Jan  6 07:11:39 2010
New Revision: 896336

URL: http://svn.apache.org/viewvc?rev=896336&view=rev
Log:
Revert Modifications to Jini Spec r896181

Modified:
    incubator/river/jtsk/trunk/doc/specs/html/devicearch-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/discovery-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/discoveryutil-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/entry-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/event-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/jini-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/joinutil-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/js-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/jxpnote-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/lds-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/lease-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/leaseutil-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/lookup-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/lrs-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/mailbox-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/schema-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/servicediscutil-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/serviceui-spec.html
    incubator/river/jtsk/trunk/doc/specs/html/txn-spec.html

Modified: incubator/river/jtsk/trunk/doc/specs/html/devicearch-spec.html
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/specs/html/devicearch-spec.html?rev=896336&r1=896335&r2=896336&view=diff
==============================================================================
--- incubator/river/jtsk/trunk/doc/specs/html/devicearch-spec.html (original)
+++ incubator/river/jtsk/trunk/doc/specs/html/devicearch-spec.html Wed Jan  6 07:11:39 2010
@@ -23,7 +23,7 @@
 <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>River Device Architecture Specification</title>
+<title>Jini Device Architecture Specification</title>
 </head>
 
 <body bgcolor="#ffffff">
@@ -31,7 +31,7 @@
 <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>River Device Architecture Specification</i></td>
+<td align=right><i>Jini Device Architecture Specification</i></td>
 </tr>
 </table>
 <a name="skip"></a>
@@ -46,16 +46,16 @@
 </table>
 
 <blockquote>
-<h2 align="left"><a name="1028364"> </a>DA - River Device Architecture Specification
+<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 River 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.
+  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 River 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 River 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.
+  <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.
@@ -64,110 +64,110 @@
   <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 River technology-enabled services and/or devices. We then discuss some examples of combinations of software and hardware that can be used to implement River technology-capable services once the specialized implementations in hardware begin to play a role.
+  <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 River Lookup Service
+  <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 River 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 River 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).
+  <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 River technology-enabled service. To be part of a system of River technology-enabled services and/or devices, a service must also be able to participate in the River discovery protocol and register itself into the local River 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.
+  <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 River discovery protocol is to allow a device or service to obtain a Java Remote Method Invocation (Java RMI) reference to the local River lookup service. Once this reference has been obtained, the service needs to register itself in that River lookup service, allowing other participants in the djinn to find and use the service.
+  <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 River 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 River lookup service lives inside a full Java virtual machine (JVM) that is at least capable of running the full Java RMI system.
+  <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 River lookup service, which might support remote interfaces beyond that specified by the River 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.
+  <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 River 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 River 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.
+  <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 River 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 River 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.
+  <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 River 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 River 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.
+  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 River technology infrastructure, off-loading from the service some of the work needed to join the federation of River technology-enabled services and/or devices.
+  <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 River architecture, there is no single River 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.
+  <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 River 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 River 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 River 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.
+  <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 River Technology-Enabled Device</div><p class="Body">
-  <a name="1003431"> </a>Such a device would be able to make full use of River 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.
+<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 River 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. 
+  <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 River technology-enabled service that the device provides. This extra hardware will increase the cost of producing the device.
+  <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 River 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.
+  <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 River 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.
+  <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 River architecture. This can be done by allowing the device to become part of a River system of services and/or devices using River technology with a specialized virtual machine that is tuned to allow only those operations needed by the River discovery protocol and River lookup service.
+  <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 River discovery and River lookup service in the device itself, include specialized knowledge of the kind of leases that are handed out by the River 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.
+  <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 River technology, allowing the River discovery and River 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.
+  <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 River 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 River lookup service, River discovery, and River leasing.
+  <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 "River 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 River 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.
+  <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 River technology-enabled device bay would register the services provided by the new device (previously known by the device bay) with the River lookup service. It would be the role of the device bay to renew leases on the River 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 River lookup service with the code handed to it by the device so that service clients could download that code.
+  <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 River 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.
+  <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 River technology can be amortized over a large number of devices.
+  <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 River 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 River technology-enabled device bay must be controlled and known beforehand.
+  <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 River technology-enabled device bay itself is a River 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).
+  <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)
@@ -176,38 +176,38 @@
   <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 River lookup service on behalf of the service device, thus allowing the service device to become a part of the federation of River 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 River technology-specific tasks such as renewing leases for the service. This alternative is shown in Figure DA.2.3.
+  <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 River 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 River technology-enabled device.
+<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 River 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.
+  <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 River 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.
+  <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 River technology-enabled devices and other network-managed devices. Such devices, which already speak a particular protocol, can be spliced into the system of River technology-enabled services and/or devices by providing a network proxy that speaks the River 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 River technology-enabled services and/or devices.
+  <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	 River Technology-Enabled Software Services over the Internet Inter-Operability Protocol
+  <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 River 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.
+  <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 River 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 River lookup service interfaces are in conformance with the Java RMI over IIOP subset.
+  <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 River lookup service using the IIOP protocol. The fact that the River 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 River lookup service (to renew leases, for example) would be transparent to the River 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 River lookup service, and would need an implementation of the <code class="Code">Lease</code> class used by the River lookup service.
+  <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 River 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 River lookup service that exports known implementations of a lease. Any alteration of either the lease implementation or the protocol used by the River 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.
+  <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>
@@ -257,7 +257,7 @@
 <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>River Device Architecture Specification</em></td>
+<td align=right><em>Jini Device Architecture Specification</em></td>
 </tr></table>
 <a name="skip"></a>
 

Modified: incubator/river/jtsk/trunk/doc/specs/html/discovery-spec.html
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/specs/html/discovery-spec.html?rev=896336&r1=896335&r2=896336&view=diff
==============================================================================
--- incubator/river/jtsk/trunk/doc/specs/html/discovery-spec.html (original)
+++ incubator/river/jtsk/trunk/doc/specs/html/discovery-spec.html Wed Jan  6 07:11:39 2010
@@ -22,14 +22,14 @@
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <meta name="GENERATOR" content="Quadralay WebWorks Publisher 5.0.4">
 <link rel="StyleSheet" href="standard.css" type="text/css" media="screen">
-<title>River Discovery & Join Specification</title>
+<title>Jini Discovery & Join Specification</title>
 </head>
 <body bgcolor="#ffffff">
 <a href="#skip" title="Skip navigation bar"></a>
 <table width="90%">
 <tr>
 <td align=left><a href="../../spec-index.html">Spec Index</a></td>
-<td align=right><em>River Technology Core Platform Specifications</em></td>
+<td align=right><em>Jini Technology Core Platform Specifications</em></td>
 </tr>
 </table>
 <a name="skip"></a>
@@ -46,13 +46,13 @@
 <blockquote>
 <h2 align="left">
 <a name="40553"></a>
-  <a name="999930"> </a>DJ - River Discovery & Join Specification	 
+  <a name="999930"> </a>DJ - Jini<font size="-1"><sup>TM</sup></font> Discovery & Join Specification	 
 </h2>
 <h3 class="Heading2">
   <a name="18973"> </a>DJ.1	 Introduction
 </h3>
 <p class="Body">
-  <a name="2506"> </a>Entities that wish to start participating in a distributed system of River technology-enabled services and/or devices, known as a <em class="Emphasis">djinn</em>, must first obtain references to one or more River lookup services. The protocols that govern the acquisition of these references are known as the <em class="Emphasis">discovery</em> protocols. Once these references have been obtained, a number of steps must be taken for entities to start communicating usefully with services in a djinn; these steps are described by the <em class="Emphasis">join</em> protocol.
+  <a name="2506"> </a>Entities that wish to start participating in a distributed system of Jini<font size="-1"><sup>TM</sup></font> technology-enabled services and/or devices, known as a <em class="Emphasis">djinn</em>, must first obtain references to one or more Jini lookup services. The protocols that govern the acquisition of these references are known as the <em class="Emphasis">discovery</em> protocols. Once these references have been obtained, a number of steps must be taken for entities to start communicating usefully with services in a djinn; these steps are described by the <em class="Emphasis">join</em> protocol.
 </p>
 <h4 class="Heading3">
   <a name="2830"> </a>DJ.1.1	 Terminology
@@ -65,14 +65,14 @@
 </p>
 <ul>
 
-  <li class="SmartList1"><a name="3844"> </a>A <em class="Emphasis">discovering entity</em> is simply one or more cooperating objects in the Java programming language on the same host that are about to start, or are in the process of, obtaining references to River lookup services. 
+  <li class="SmartList1"><a name="3844"> </a>A <em class="Emphasis">discovering entity</em> is simply one or more cooperating objects in the Java programming language on the same host that are about to start, or are in the process of, obtaining references to Jini lookup services. 
   <li class="SmartList1"><a name="2834"> </a>A <em class="Emphasis">joining entity</em> comprises one or more cooperating objects in the Java programming language on the same host that have just received a reference to the lookup service and are in the process of obtaining services from, and possibly exporting them to, a djinn. 
   <li class="SmartList1"><a name="2835"> </a>An <em class="Emphasis">entity</em> may be a discovering entity, a joining entity, or an entity that is already a member of a djinn; the intended meaning should be clear from the context.
   <li class="SmartList1"><a name="3796"> </a>A <em class="Emphasis">group</em> is a logical name by which a djinn is identified.
 </ul>
 
 <p class="Body">
-  <a name="2836"> </a>Since all participants in a djinn are collections of one or more objects in the Java programming language, this document will not make a distinction between an entity that is a dedicated device using River technology or something running in a <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">JVM</span> that is hosted on a legacy system. Such distinctions will be made only when necessary.
+  <a name="2836"> </a>Since all participants in a djinn are collections of one or more objects in the Java programming language, this document will not make a distinction between an entity that is a dedicated device using Jini technology or something running in a <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">JVM</span> that is hosted on a legacy system. Such distinctions will be made only when necessary.
 </p>
 <h4 class="Heading3">
   <a name="2670"> </a>DJ.1.2	 Host Requirements
@@ -82,7 +82,7 @@
 </p>
 <ul>
 
-  <li class="SmartList1"><a name="2672"> </a>A functioning <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">JVM</span>, with access to all packages needed to run software written to the River specifications
+  <li class="SmartList1"><a name="2672"> </a>A functioning <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">JVM</span>, with access to all packages needed to run software written to the Jini specifications
   <li class="SmartList1"><a name="2735"> </a>A properly configured network protocol stack
 </ul>
 
@@ -98,7 +98,7 @@
 <ul>
 
   <li class="SmartList1"><a name="2741"> </a>An IP address. IP addresses may be statically assigned to some hosts, but we expect that many hosts will have addresses assigned to them dynamically. Dynamic IP addresses are obtained by hosts through use of <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">DHCP</span>.
-  <li class="SmartList1"><a name="2742"> </a>Support for unicast <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">TCP</span> and multicast <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">UDP</span>. The former is used by subsystems using River technology such as Java Remote Method Invocation (<span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">Java RMI</span>); both are used during discovery.
+  <li class="SmartList1"><a name="2742"> </a>Support for unicast <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">TCP</span> and multicast <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">UDP</span>. The former is used by subsystems using Jini technology such as Java Remote Method Invocation (<span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">Java RMI</span>); both are used during discovery.
   <li class="SmartList1"><a name="2743"> </a>Provision of some mechanism, such as a simple <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">HTTP</span> server, that facilitates the downloading of code (for example, for service proxies or Java <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">Java RMI</span> stubs) by remote parties. This mechanism does not have to be provided by the host itself, but the code must be made available by some cooperating party.
 </ul>
 
@@ -507,7 +507,7 @@
   <a name="19194"> </a>DJ.2.5	 The Multicast Announcement Protocol
 </h4>
 <p class="Body">
-  <a name="19195"> </a>The multicast announcement protocol is used by River lookup services to announce their availability to interested parties within multicast radius. Participants in this protocol are the multicast announcement client, which resides on the same system as a lookup service, and the multicast announcement server, at least one instance of which exists on every entity that listens for such announcements.
+  <a name="19195"> </a>The multicast announcement protocol is used by Jini lookup services to announce their availability to interested parties within multicast radius. Participants in this protocol are the multicast announcement client, which resides on the same system as a lookup service, and the multicast announcement server, at least one instance of which exists on every entity that listens for such announcements.
 </p>
 <p class="Body">
   <a name="19196"> </a>The multicast announcement client is a long-lived process; it must start at about the same time as the lookup service itself and remain running as long as the lookup service is alive.
@@ -1516,13 +1516,13 @@
   <a name="19569"> </a>Whether or not calls to the discovery request service will need to be bridged across <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">LAN</span> or wide area network (<span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">WAN</span>) segments will depend on the network protocol being used and the topology of the local network.
 </p>
 <p class="Body">
-  <a name="19570"> </a>In an environment in which every <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">LAN</span> segment happens to host a River lookup service, bridging might not be necessary. This does not seem likely to be a typical scenario.
+  <a name="19570"> </a>In an environment in which every <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">LAN</span> segment happens to host a Jini lookup service, bridging might not be necessary. This does not seem likely to be a typical scenario.
 </p>
 <p class="Body">
   <a name="19571"> </a>Where the underlying transport is multicast IP, intelligent bridges and routers must be able to forward packets appropriately. This simply requires that they support one of the multicast IP routing protocols; most router vendors already do so.
 </p>
 <p class="Body">
-  <a name="19572"> </a>If the underlying transport were permitted to be local-area IP broadcast, some kind of intelligent broadcast relay would be required, similar to that described in the <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">DHCP</span> and <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">BOOTP</span> specifications. Since this would increase the complexity of the infrastructure needed to support the River discovery protocol, we mandate use of multicast IP instead of broadcast IP.
+  <a name="19572"> </a>If the underlying transport were permitted to be local-area IP broadcast, some kind of intelligent broadcast relay would be required, similar to that described in the <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">DHCP</span> and <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">BOOTP</span> specifications. Since this would increase the complexity of the infrastructure needed to support the Jini discovery protocol, we mandate use of multicast IP instead of broadcast IP.
 </p>
 <h4 class="Heading3">
   <a name="19573"> </a>DJ.5.3	 Limiting the Scope of Multicasts
@@ -1540,7 +1540,7 @@
   <a name="19577"> </a>DJ.5.5	 Address and Port Mappings for TCP and Multicast UDP
 </h4>
 <p class="Body">
-  <a name="19461"> </a>The port number for River lookup discovery requests is <code>4160</code>. This applies to both the multicast and unicast discovery protocols. For multicast discovery the IP address of the multicast group over which discovery requests should travel is <code>224.0.1.85</code>. Multicast announcements should use the address <code>224.0.1.84</code>.
+  <a name="19461"> </a>The port number for Jini lookup discovery requests is <code>4160</code>. This applies to both the multicast and unicast discovery protocols. For multicast discovery the IP address of the multicast group over which discovery requests should travel is <code>224.0.1.85</code>. Multicast announcements should use the address <code>224.0.1.84</code>.
 </p>
 <p class="Body">
   <a name="19635"> </a>
@@ -1611,10 +1611,10 @@
 A similar timeout is implied for the no-arg form of this method. It invokes the one-arg form of the method, passing to it a timeout value. The timeout in milliseconds may be specified globally using the <code>net.jini.discovery.timeout</code> system property. A default equal to 60 seconds is assumed if the system property is not set, set to a negative value, or cannot be parsed as an <code>Integer</code>.
 </p>
 <h4 class="Heading3">
-  <a name="19664"> </a>DJ.6.1	 River Technology URL Syntax
+  <a name="19664"> </a>DJ.6.1	 Jini Technology URL Syntax
 </h4>
 <p class="Body">
-  <a name="19665"> </a>The syntax of the River technology URL is that of a <em>hierarchical</em> URI with a <em>server-based naming authority</em> (host and optional port). The URI syntax is defined in RFC 2396. The components of the URL must satisfy the following requirements:
+  <a name="19665"> </a>The syntax of the Jini technology URL is that of a <em>hierarchical</em> URI with a <em>server-based naming authority</em> (host and optional port). The URI syntax is defined in RFC 2396. The components of the URL must satisfy the following requirements:
 </p>
 <ul>
 
@@ -1708,7 +1708,7 @@
     <td valign="top">v3.0
 	</td>
     <td>Correct specification for the computation of Discovery Format IDs.<br>
-    Clarify River Technology URL syntax.<br>
+    Clarify Jini Technology URL syntax.<br>
     Clarify that null format ID unicast responses only need version number.<br>
     Add format id for net.jini.discovery.x500.SHA1withRSA format.<br>
     Miscellaneous edits.
@@ -1753,7 +1753,7 @@
 <a href="#skip" title="Skip navigation bar"></a>
 <table width="100%"><tr>
 <td align=left><a href="../../spec-index.html">Spec Index</a>
-</td><td align=right><em>River Technology Core Platform Specifications</em></td>
+</td><td align=right><em>Jini Technology Core Platform Specifications</em></td>
 </tr></table>
 <a name="skip"></a>
 



Mime
View raw message