WO2003019369A2 - Systeme de reseau distribue pour dispositifs informatiques a contraintes de ressources - Google Patents

Systeme de reseau distribue pour dispositifs informatiques a contraintes de ressources Download PDF

Info

Publication number
WO2003019369A2
WO2003019369A2 PCT/CA2002/001375 CA0201375W WO03019369A2 WO 2003019369 A2 WO2003019369 A2 WO 2003019369A2 CA 0201375 W CA0201375 W CA 0201375W WO 03019369 A2 WO03019369 A2 WO 03019369A2
Authority
WO
WIPO (PCT)
Prior art keywords
service
client
lookup
network
interface means
Prior art date
Application number
PCT/CA2002/001375
Other languages
English (en)
Other versions
WO2003019369A3 (fr
Inventor
Lawrence T. Smith
Cameron Roe
K. Steven Knudsen
Original Assignee
Psinaptic Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Psinaptic Inc. filed Critical Psinaptic Inc.
Priority to CA002449953A priority Critical patent/CA2449953A1/fr
Priority to US10/483,209 priority patent/US20040181530A1/en
Publication of WO2003019369A2 publication Critical patent/WO2003019369A2/fr
Publication of WO2003019369A3 publication Critical patent/WO2003019369A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services

Definitions

  • the present invention relates to a distributed networking environment.
  • the present invention relates to a method and a system for facilitating communication by resource-constrained computing devices.
  • Jini Java is a trademark of Sun Microsystems Inc.
  • RMI Red Microsystems Inc.
  • the latency of a network is variable. Delays in sending and receiving information are dependent on factors such as the physical medium, traffic on the network, and information routing algorithms.
  • Networks are insecure. This is especially true of heterogeneous networks wherein the devices exchanging information cannot control the route that information takes.
  • Network topologies are variable. This is most obvious in mobile networks when devices move between network access points. In the future, multi- mode devices will move between network types (e.g., from a cellular network to a wireless local area network to a wired desktop network).
  • Networks are not uniform. Multiple networks mean multiple sets of rules, protocols, access, authorization, and security protocols, all controlled by disparate organizations and individuals. Accessing and securing resources across these networks is complicated by inconsistent administration practices.
  • Jini network technology [1] purports to address these problems by defining mechanisms to support the federation of machines or programs into a single, dynamic distributed system.
  • Devices participating in such a system can enter and leave at will, can tolerate network and system variability (as described above), can offer "services" and resources to other devices and systems in the federation.
  • a "service” refers to an entity that can be used by a person, group of people, organization, program or other service.
  • the "service” can be anything that can be offered by a computational, networked device, including- access to a network, computation, storage, information, access to hardware (such as a printer, modem, etc.) or another user.
  • devices are able to discover and utilize the "services" provided by members of the federation. This is accomplished through protocol definitions that support network transactions via six primary mechanisms [1][2], as follows:
  • Lookup This is a set of protocols and interfaces that define a Jini Lookup Service [1]. This is a service that maps interfaces indicating the functionality offered by a service to sets of objects that implement the service.
  • an "object” is a software program or subprogram that can be executed (run) on one or more devices in the federation.
  • Jini services employ objects based on Java, and can run on any devices that support a Java Virtual Machine (JVM).
  • JVM Java Virtual Machine
  • Objects in a Lookup Service may contain other Lookup Services, allowing for a hierarchical structure. Users (clients) of a Lookup Service may add new services, dynamically extending the functionality of the federation.
  • Discovery The process of finding a suitable Lookup Service is referred to as Discovery.
  • Lookup Services listen for and respond to requests for Lookup Services.
  • a Lookup Service may announce its presence on the network via a broadcast message.
  • a client device may use the announcement to locate and utilize a suitable Lookup Service.
  • Join Once found a Lookup Service has been found, a client device may join its service(s) to that Lookup Service by providing one or more objects.
  • the Join protocol defines the mechanism to accomplish this.
  • Leasing The use of a resource, granted for a specific amount of time, is known as a lease.
  • the duration of the lease may be fixed by the grantor, or negotiated. To maintain it, the lease must be renewed periodically. This allows for the expiration and cleanup of services that are no longer required, or whose owners have left the federation.
  • leasing helps manage interactions between devices in a variable network environment.
  • a transaction refers to the mechanism used to ensure that service operations are consistent and complete within the federation. That is, a transaction allows a set of operations to be grouped in such a way that they either all succeed or all fail. To members of the federation, the operations in the set appear to occur simultaneously. By utilizing transactions, consistency over a set of operations on one or more remote participants can be enforced. If all the participants are members of a transaction, one response to a remote failure is to abort the transaction, thereby ensuring that no partial results are written.
  • Events An object residing on a device may register an interest in an event occurring in another object residing on a different device in the federation and receive notification when the event occurs. Thus, events provide a mechanism for maintaining consistency of state (information) in the federation.
  • Jini Using Jini, devices can spontaneously form federations (network communities) through the Discovery and Join protocols. The only requirement for devices is that they host a suitable Java Virtual Machine (JVM) and can communicate.
  • JVM Java Virtual Machine
  • UML Unified Modelling Language
  • a device using Discovery and Join connects to one or more other devices to form a network, the device polls the network for a Jini Lookup Service. The device then registers itself with the Lookup Service. Alternatively, the device may itself already host a Lookup Service, which then becomes available to (discoverable by) other devices in the network. Devices in the network may query the Lookup Services they have discovered to determine whether desired services are available. Desired services can be downloaded and executed locally by a device. Because this process is automatic, devices (and hence, users) need not perform complicated installation procedures to couple Jini-enabled devices to the network and enable the devices to function cooperatively with other devices on network.
  • RMI Remote Method Invocation
  • the primary Lookup Service behaviour is defined by the ServiceRegistrar interface which is implemented as an RMI proxy.
  • a client device needs to use the Lookup Service, it downloads the ServiceRegistrar object.
  • Execution of ServiceRegistrar methods is done via the proxy that makes RMI calls back to the device originating the service.
  • This is illustrated in Figure 2.
  • both client devices discover the Lookup Service and each obtains a ServiceRegistrar object.
  • the device on the right side of the diagram registers for event notification using its ServiceRegistrar, which uses an RMI proxy call back - (indicated as RMI.notify) to the Lookup Service.
  • the Lookup Service sends event notifications directly to the device.
  • the device on the left side of the diagram joins the Lookup Service (i.e., registers a service using its ServiceRegistrar, which uses an RMI proxy call back, RMI.register, to the Lookup Service).
  • the device on the right receives a RemoteEvent message concerning the service recently registered with the Lookup Service.
  • Jini Lookup Service implementation is large (e.g., typically, over 2 megabytes of static Java bytecode) because it must support the RMI protocol to satisfy RMI proxy objects such as the ServiceRegistrai".
  • RMI proxy objects such as the ServiceRegistrai.
  • a host computer that provides at least one network client with access to at least one network service in a distributed computing environment.
  • the host computer includes a data processing system that is configured to. provide the network clients with access by transmitting lookup service interface means to the network clients.
  • the lookup service means is "self-contained", in that it includes a reference to the network service sufficient to allow the network client to communicate with the network service.
  • a method for providing at least one network client with access to at least one network service in a distributed computing environment comprising the steps of (1) receiving at a host computer an access request to a lookup service from the network client; and (2) transmitting lookup service interface means to the network client, the lookup service means including a reference to the network service.
  • a computer-readable medium including processing instructions for a general-purpose computer.
  • the processing instructions define in the computer a data processing system for interfacing the computer with a network.
  • the data processing system is configured to transmit lookup service interface means over the network to at least one network client.
  • the lookup service means includes a reference to at least one network service available over the network.
  • an electronic signal that defines lookup service interface means in a client computer that interfaces with a computer network.
  • the lookup service means including a reference to at least one network service available over the network.
  • a host computer that provides at least one network client with access to at least one network service in a distributed computing environment.
  • the host computer comprises a data processing system which has a lookup service including information associated with the at least one network service.
  • the data processing system is configured to transmit lookup service interface means to the network client.
  • the lookup service means comprises an interface object that is configured to facilitate non-proxy communication with the lookup service.
  • a method for providing at least one network client with access to at least one network service in a distributed computing environment comprising the steps of (1) receiving at a host computer an access request to a lookup service from the network client, the host computer including a lookup service comprising information associated with the network service; and (2) transmitting lookup service interface means to the network client, the lookup service means being configured for non-proxy communication with the lookup service.
  • the data processing system includes a lookup service (hereafter referred to as a LUS for differentiation from other lookup service implementations) that comprises information associated with each network service.
  • the LUS implements at least one of the Lookup Service functions consistent with a Jini Lookup Service host, as defined in the Jini technology specification [1].
  • the data processing system implements the LUS using non-Java programming languages, although in one variation the data processing system implements the LUS using a Java Virtual Machine.
  • the lookup service interface means (hereinafter referred to as a ServiceRegistrar software object) comprises a non-proxy interface object that is configured to facilitate non-proxy communication with the LUS. Also, the data processing system is configured to transmit the ServiceRegistrar software object to the network client using a non-RMI protocol.
  • the present invention provides a Host computing device comprising a memory, a data communication means, an operating system, the memory comprising instructions for: (i) exporting a pre-marshalled, non-proxy, self- contained ServiceRegistrar software object that implements a ServiceRegistrar interface and ServiceRegistrar behaviour (as defined in the Jini technology specification [1]), (ii) hosting a LUS compatible with the a non-proxy, self-contained ServiceRegistrar software object and consistent with a Jini Lookup Service host as defined in the Jini technology specification [1], and (iii) utilizing the data communications means to transfer the non- proxy, self-contained ServiceRegistrar software object to a second computing device.
  • the computing device does not use Java or support a Java Virtual Machine. It does, however, offer Java software based services and accepts the registration of Java software based services. These services reside on the device in a pre-marshalled form, having been prepared by a separate computing device similar to a Client computing device or a Client device itself (i.e., a device that supports a suitable JVM). Such a client device is shown in Figure 5.
  • the depicted Client computing device that can acquire and use services or may offer zero or more services.
  • the hardware device is associated with an operating system.
  • the operating system may be only a state machine or something more complex.
  • the Java virtual machine depends on the operating system.
  • the data communications transceiver supports wired or wireless media.
  • Host computing device refers to the device that hosts the LUS. It offers the ServiceRegistrar software object and other services that have been registered with the LUS.
  • the LUS program or subprograms may be implemented using Java on the Host device, or instead may be implemented using a non-Java programming language or languages on the Host device.
  • Client computing device refers to any device that can participate in a Jini federation. No specific claims related to the client device are made. It is required in this description to illustrate the functions of the Host device and the software design approach employed to support the functions of the LUS.
  • An advantage of the present invention is that it obviates or mitigates the problem of implementing Lookup Service functionality on a memory-constrained computing device.
  • the other primary mechanisms described above are unchanged and thus, it is not necessary to describe them in great detail here. More information may be obtained from the references listed herein, which are hereby incorporated by reference.
  • a further advantage of the present invention is that it avoids the use of proxy objects in the implementation of the LUS ServiceRegistrar interface. Instead of utilizing a proxy software object to implement the ServiceRegistrar interface [1] and having the proxy invoke ServiceRegistrar methods via a proxy protocol, a non-proxy ServiceRegistrar software object is offered by the LUS.
  • the ServiceRegistrar interface is realized using a self-contained software object that implements the interface and its behaviour on the requesting device.
  • the ServiceRegistrar object relies on the Java Virtual Machine of the client device on which it has been instantiated. It uses that JVM and its supporting subprograms (contained in general in ancillary Java class files) to perform all Java-dependent operations required by the LUS. The primary such operation is the marshalling of new service items in response to register requests, and the unmarshalling of service items retrieved from the LUS. Unmarshalled service items become Java software objects when loaded by the Client's JVM. Thus, the JVM of the client device is required to support class loading and serialization as indicated in Figure 1.
  • the ServiceRegistrar software object communicates changes in its state to the LUS program or subprograms on the Host device.
  • the LUS program or subprograms notify other devices possessing ServiceRegistrar objects obtained from the LUS. Tins behaviour is illustrated in the general case in Figure 7 and for a specific state change in Figure 8.
  • the LUS program or subprograms maintain persistently on the Host device all state information relevant and common to all ServiceRegistrar software objects it has granted to requesting Client devices.
  • Changes in state information are communicated to the objects. For example, if an administrator changes the groups associated with the LUS, that change is communicated to all ServiceRegistrar software objects. Temporary or transient state and other information may be maintained in the ServiceRegistrar objects instantiated on the Client devices. Provision is made to synchronize that information with the information stored on the Host device or other Client devices. This is accomplished via prescribed messages passed between the ServiceRegistrar and one or more subprograms on the Host device. [0021] Implementing the LUS and ServiceRegistrar in this way results in a compact, efficient LUS suitable for use by small, resource-constrained devices.
  • FIG. 2 is an illustration of the operation of an RMI-based Jini Lookup Service
  • Figure 3 represents the Host and Client computing devices with the UML actors
  • FIGS. 4 and 5, respectively are deployment diagrams of the preferred embodiments of the Host and Client devices
  • Figure 6 is an illustration of the ServiceRegistrar interface definition including the required operations
  • Figure 7 illustrates the maintenance of state information by a ServiceRegistrar object, using the Event mechanism as an example
  • Figure 8 depicts the operation of a non-RMI-based LUS.
  • FIG 8 an interaction is illustrated between a computing device (hereafter referred to as a Host) that hosts a Lookup Service (hereinafter referred to as a 'LUS') according to the present invention, and two client computing devices.
  • the LUS employs a non-RMI-based ServiceRegistrar implementation. Both devices discover the LUS and each obtains a ServiceRegistrar object.
  • the device on the right side of the diagram registers locally for event notification using its ServiceRegistrar.
  • the device on the left side of the diagram joins the LUS using its local ServiceRegistrar, which sends a message to the LUS indicating the new service. Since the device on the right has registered for event notifications, the LUS sends it a message with the details of the newly registered service provided by the device on the left.
  • the device on the right then downloads the service to use on its local JNM.
  • the LUS programs or subprograms support all Jini network technology Lookup Service mechanisms as required by the Jini specification [1].
  • the ServiceRegistrar according to the present invention, is implemented as a self-contained Java software object. For each public method (i.e., method of the ServiceRegistrar object that can be invoked by a client device; see Figure 6), many of the computations related to the ServiceRegistrar and LUS functions are done on the local, client computing device. All Java-dependent operations required to fulfil the requirements of the LUS implementation are executed by the Service Registrar object on the Client device. The two main operations are class loading and serialization (marshalling and unrnarshailing of service items).
  • the ServiceRegistrar software object encapsulates much of the LUS functionality and, thus, supports the ability of a Host computing device to act as a LUS.
  • the ServiceRegistrar software object contains a reference to each service offered by the Host. This reference is sufficient to allow a client to acquire the service via the ServiceRegistrar.
  • the Host computing devices marshals a ServiceRegistrar object (flattens, serializes, and packages into a byte array for transport according to the RMI specification [3]) before sending it to a client computing device.
  • FIG. 3 depicts the UML actors representing the Host and Client computing devices.
  • the client must have a Java Virtual Machine that supports class loading and serialization, the Host may have a Java Virtual Machine or may not.
  • the ServiceRegistrar is pre-marshalled and stored on the Host at some previous point in time (for example, at the time the Host was assembled).
  • the preparation (marshalling) of the ServiceRegistrar is accomplished using a computing device similar to a Client device (i.e., that supports a suitable JVM).
  • An example of such a device is a commercial personal computer supporting a recent JVM from Sun Microsystems.
  • a simple marshalling program can be constructed using Sun's Jini technology implementation running on that platform.
  • the client unmarshals the received byte array and unmarshals locally the ServiceRegistrar software object.
  • the ServiceRegistrar object maintains a communications link back to the Host. Both sides use the link to maintain state information, manage events, and satisfy service requests and inquiries.
  • this communications link is a TCP/IP socket connection as supported by standard Java networking technology.
  • the LUS is changed if a client registers a service with it using its local ServiceRegistrar object.
  • a client device having requested notification of new services, is notified of a new service when it is registered by another client device.
  • the act of service registration results in a message being sent to the LUS by the registering client's local ServiceRegistrar object.
  • the message includes the new service software object and other pertinent information.
  • the LUS decodes the message and adds the new service to its local storage.
  • the LUS notifies all client devices that have registered (via the ServiceRegistrar notify method) for new service events by sending a message to the clients' local ServiceRegistrar objects.
  • All data structures, state machines, communication protocols, and subprograms required to maintain the state of the LUS are implemented in the ServiceRegistrar object and by software on the Host computing device insofar as required to meet the Jini technology specification [1].
  • RMI Remote Method Invocation
  • the LUS does not unmarshal registered services on the Host device or within the ServiceRegistrar objects on client devices.
  • Client devices supplying RMI-based services either implement RMI host software or redirect service requests to a suitable secondary device.
  • client devices that use RMI-based services locally must implement RMI client software.
  • the LUS is effectively distributed across the Host and client devices. This has several advantages when the devices involved are small, resource-constrained computers, including a reduction of computational and storage requirements, lower power consumption, and reduced physical size.
  • This approach is well suited to devices that are simple in nature and function, and that need only to supply a simple service for use by other computing devices.
  • a temperature sensor will need only to provide a sendee that allows a client to request a temperature measurement.
  • the sensor has little interest in hosting services other than its own.
  • This invention allows small devices, such as sensors, to host their own services primarily because the LUS implementation is small and, hence, cost-effective.
  • the ServiceRegistrar object includes the Service Item object for each service registered with the LUS.
  • Each Service Item object identifies for each service a servicelD, a service element, and an attribute set.
  • the servicelD is a numerical identifier that uniquely identifies the associated service.
  • the service element can either be an object that represents the associated service, or a proxy that facilitates access to the service.
  • the attribute set is a collection of attributes identifying properties associated with the service.
  • the ServiceRegistar object also provides the methods defined for a ServiceRegistrar object, as described in the Jini specification. As shown in Fig. 6, the ServiceRegistar object provides methods to (1) register services with the LUS, (2) locate services that match a template, (3) modify attributes values for existing services, (4) receive notifications when services are modified, and (5) query the collection of services according to class, attribute value and type. [0035]
  • the ServiceRegistar object implements a "register" method 410 to register services with the LUS. To register a new service, the "register" method 410 is invoked, carrying the Service Item of the associated service as an argument, and with the ServicelD of the Service Item object being set to zero. The register method 410 queries the Service Item objects included with the ServiceRegistrar object -4&!$ against the service element of the passed Service Item.
  • the new Service Item is added to the ServiceRegistrar object, with a new unique value being assigned to the ServicelD.
  • the service element of the passed Service Item matches the service element of any Service Item already registered, the passed Service Item replaces the existing Service Item in the ServiceRegistrar object. In either case, the register method then notifies the LUS of the change.
  • the "register" method 410 is invoked, carrying the Service Item of the associated service as an argument, but with the ServicelD of the Service Item object being set to the value returned upon initial registration. As above, the passed Service Item replaces the existing Service Item in the ServiceRegistrar object. The register method 410 then notifies the LUS. [0038] .
  • the ServiceRegistrar object implements two "lookup" methods 412 to locate the Service Item objects that match a template. One "lookup" method (the single parameter lookup method 412a) returns the service element of the matching Service Item.
  • the other "lookup" method (the two parameter lookup method 412b) returns the number of matching Service Item objects (at most 'MaxMatches' items). In each case, the lookup method 412 queries the Service Item objects included with the ServiceRegistrar object to satisfy the lookup request.
  • the ServiceRegistrar object implements a "notify" method 418 which allows a client terminal to register with the LUS for notification that, for instance, a Service Item object registered with the LUS has been changed, or if a Service Item ⁇ 2 has been removed.
  • the notify method 418 is configured to request that the LUS notify the requesting client terminal that any of the following events have occurred: (1) the changed Service Item 4 matches the template before the notify request, but does not match the template afterwards; (2) the changed Service Item 402 does not match the template before the notify request, but does match the template afterwards; and (3) the changed Service Item 402 matches the template both before and after the notify request.
  • the ServiceRegistrar object 4 ⁇ ® notifies the LUS of the desired template and transition combination.
  • the ServiceRegistrar object implements a "getEntryClasses” method 420 to return the set of classes of the Service Item objects ⁇ ®2 that match a specified template.
  • the ServiceRegistrar object implements a "getFieldValue” method 422 to return the values of the Service Item objects that match a specified template.
  • the ServiceRegistrar object implements a "getServiceTypes” method 424 to return the set of types of the Service Item objects 4S& that match a specified template. In each case, the method queries the Service Item objects included with the ServiceRegistrar object to satisfy the request.
  • the Host computing device is a general- purpose computer having a processing unit, an operating system and memory.
  • the processing unit is a small, low-power microprocessor or microcontroller capable of hosting an operating system (real-time or not).
  • the LUS state machine is realized using a non-Java programming language.
  • Java may be employed to realize the LUS state machine.
  • the operating system hosts a Java Virtual Machine.
  • the JVM version is able to support the LUS machine implementation; typically this is at least a Java 2 Microedition (J2ME)-level JNM.
  • Application programs written in Java are executed by the system.
  • the operating system may be separate from the JNM or may be integral.
  • the processing unit is physically coupled via a standard data bus to the memory, which may comprise a limited amount of static or dynamic electronic data storage, such as static random access memory (SRAM), dynamic random access memory (DRAM), erasable programmable read-only memory (EPROM) and the like.
  • the processing unit is physically coupled via a standard communications interface such as a parallel or serial data bus to a wireless communications transceiver.
  • the transceiver supports a standard wireless protocol such as Bluetooth or IEEE 802.11.
  • the wireless protocol is capable of transporting Internet Protocol packets.
  • the transceiver is the main means of data communications for the unit. Secondary communications may be provided by other interfaces, such as Ethernet or RS232.
  • the present invention is implemented in the device disclosed in copending patent application S.N. 09/666,880 filed September 20, 2000 by the present inventors.
  • the Host computing devices are available to the network clients over a network, such as the Internet
  • the LUS is maintained in the memory of the Host computing device
  • the network clients include a processing unit and a memory for receiving and executed the methods implemented in the ServiceRegistrar object.
  • the network client initiates a discover operation for the LUSs by transmitting over the network a user datagram protocol (UDP)-based message using a multicast request protocol, requesting a response from all available LUSs.
  • UDP user datagram protocol
  • the Host computing device If the Host computing device satisfies the criteria specified in the message, the Host computing device responds to the network client with a unicast response containing the ServiceRegistrar object.
  • the discovering network client may receive multiple ServiceRegistrar objects, one for each respective LUS.
  • the ServiceRegistrar includes the Service Item object for each network resource registered with the LUS. Consequently, using the ServiceRegistrar the network client is able to access the network services registered with the LUS, without further communication with the Host computing device, by invoking the lookup method 412 of the ServiceRegistrar object.
  • the Host computing device serializes the ServiceRegistrar 400 from the information contained in the LUS, and then transmits the serialized object to the network client. Upon receipt, the discovering network client unmarshalls the serialized ServiceRegistrar object.
  • serialization of the ServiceRegistrar object may be performed offline by another computing device, with the serialized ServiceRegistrar object being stored on the Host computing device. This latter variation is particularly advantageous since it reduces the resource requirements of the Host computing device further, and would allow the Host computing device to be implemented, for instance, as a state machine rather than as a general-purpose computer.
  • the network client may wish to update the ServiceRegistrar object(s) that it has received. If so, the network client initiates another discover operation by establishing a TCP/IP connection with one of the Host computing devices, and then transmitting over the TCP channel a unicast request message. The Host computing device responds to the network client with a unicast response containing the ServiceRegistrar object.
  • the network client may also wish to register its sendees with one or more of the LUSs. If so, the network client initiates a join operation by invoking the register method 410 of the ServiceRegistrar object. If register method 410 is successful, the ServiceRegistrar object notifies the Host computing device of the new service, by serializing the Service Item object for the new service and then transmitting the serialized object to the Host computing device. Upon receipt, the Host computing device does not umnarshall the serialized object, but instead stores the object in memory. As will be appreciated, by serializing the Service Item object locally on the network client, and by relieving the Host computing device from unmarshalling Service Items objects, the resource requirements of the Host computing device are reduced further.
  • the network client may also wish to register for event notification of a change to the LUSs. If so, the network client initiates an event operation by invoking the notify method 418 of the ServiceRegistrar object. Upon completion of the notify method 418, the ServiceRegistrar object notifies the LUS of the notification parameters. Subsequently, if the LUS detects that the specified template and transition combination has occurred, the LUS notifies the ServiceRegistrar object of each network client registered for the specified template and transition.
  • FIG. 7 A change in the state of a ServiceRegistrar object owned by the device on the left is caused by the registration of a new service.
  • the ServiceRegistrar object owned by the device sends a message to the LUS (hosted by the middle device) indicating that a Serviceltem has been added.
  • the LUS sends an update to all other devices that have registered for notifications, namely, the device on the right.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un ordinateur hôte fournissant un accès à au moins un service de réseau à au moins un client de réseau dans un environnement informatique distribué. Ledit ordinateur hôte comprend un système de traitement de données configuré de façon à fournir un accès aux clients de réseau par transmission de moyens d'interface de service de recherche audits clients de réseau. L'ordinateur hôte comprend également un service de recherche doté d'informations associées à chaque service de réseau. Les moyens de service de recherche sont autonomes en ce qu'ils comprennent une référence au service de réseau suffisante pour permettre la communication entre le client de réseau et ledit service de réseau. Les moyens d'interface de service de recherche comprennent un objet d'interface non proxy configuré afin de faciliter une communication non proxy avec ledit service de recherche.
PCT/CA2002/001375 2001-08-29 2002-08-29 Systeme de reseau distribue pour dispositifs informatiques a contraintes de ressources WO2003019369A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA002449953A CA2449953A1 (fr) 2001-08-29 2002-08-29 Systeme de reseau distribue pour dispositifs informatiques a contraintes de ressources
US10/483,209 US20040181530A1 (en) 2001-08-29 2002-08-29 Distributed networking system for resource-constrained computing devices

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US31535601P 2001-08-29 2001-08-29
US60/315,356 2001-08-29

Publications (2)

Publication Number Publication Date
WO2003019369A2 true WO2003019369A2 (fr) 2003-03-06
WO2003019369A3 WO2003019369A3 (fr) 2004-02-05

Family

ID=23224026

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2002/001375 WO2003019369A2 (fr) 2001-08-29 2002-08-29 Systeme de reseau distribue pour dispositifs informatiques a contraintes de ressources

Country Status (3)

Country Link
US (1) US20040181530A1 (fr)
CA (1) CA2449953A1 (fr)
WO (1) WO2003019369A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167713A1 (fr) * 2014-04-28 2015-11-05 Oracle International Corporation Système et procédé pour prendre en charge un modèle de domaine de dérivation et un modèle mandataire, et pour mettre à jour des informations de service pour une messagerie entre des domaines dans un environnement médiateur de transactions entre des machines

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9317255B2 (en) * 2008-03-28 2016-04-19 Microsoft Technology Licensing, LCC Automatic code transformation with state transformer monads
US9210065B2 (en) * 2009-06-22 2015-12-08 Alcatel Lucent Providing cloud-based services using dynamic network virtualization
US10514683B2 (en) 2015-09-16 2019-12-24 Profire Energy, Inc. Distributed networking system and method to implement a safety state environment
US10432754B2 (en) 2015-09-16 2019-10-01 Profire Energy, Inc Safety networking protocol and method

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000077618A2 (fr) * 1999-06-14 2000-12-21 Sun Microsystems, Inc. Service de decouverte de recherche

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2469751A1 (fr) * 1979-11-07 1981-05-22 Philips Data Syst Processeur d'intercommunication du systeme utilise dans un systeme de traitement de donnees reparti
US4468736A (en) * 1982-06-08 1984-08-28 Burroughs Corporation Mechanism for creating dependency free code for multiple processing elements
US5293619A (en) * 1991-05-30 1994-03-08 Sandia Corporation Method and apparatus for collaborative use of application program
US5369570A (en) * 1991-11-14 1994-11-29 Parad; Harvey A. Method and system for continuous integrated resource management
US5625845A (en) * 1992-10-13 1997-04-29 International Business Machines Corporation System for facilitating continuous, real-time, unidirectional, and asynchronous intertask and end-device communication in a multimedia data processing system using open architecture data communication modules
JP2544581B2 (ja) * 1994-02-14 1996-10-16 インターナショナル・ビジネス・マシーンズ・コーポレイション 会議システム制御方法、会議装置及び会議システム
US5560005A (en) * 1994-02-25 1996-09-24 Actamed Corp. Methods and systems for object-based relational distributed databases
US5760769A (en) * 1995-12-22 1998-06-02 Intel Corporation Apparatus and method for identifying a shared application program in a computer during teleconferencing
US6247026B1 (en) * 1996-10-11 2001-06-12 Sun Microsystems, Inc. Method, apparatus, and product for leasing of delegation certificates in a distributed system
US6134603A (en) * 1998-03-20 2000-10-17 Sun Microsystems, Inc. Method and system for deterministic hashes to identify remote methods
US5953526A (en) * 1997-11-10 1999-09-14 Internatinal Business Machines Corp. Object oriented programming system with displayable natural language documentation through dual translation of program source code
US6823056B1 (en) * 2000-09-01 2004-11-23 Bellsouth Intellectual Property Corporation Multiple services per trigger within a telecommunications network
US7159026B2 (en) * 2002-01-31 2007-01-02 Telcordia Technologies, Inc. Service performance correlation and analysis

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000077618A2 (fr) * 1999-06-14 2000-12-21 Sun Microsystems, Inc. Service de decouverte de recherche

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KAMINSKY A: "JiniME: Jini Connection Technology for Mobile devices" ONLINE, 3 August 2000 (2000-08-03), XP002253531 *
SMITH L ET AL: "A JINI LOOKUP SERVICE FOR RESOURCE-CONSTRAINED DEVICES" PROCEEDINGS. IEEE INTERNATIONAL WORKSHOP ON NETWORKED APPLIANCES, XX, XX, 15 January 2002 (2002-01-15), pages 135-144, XP001121564 *
SUN MICROSYSTEMS: "Jini (TM) Lookup Service Specification" JINI (TM) LOOKUP SERVICE SPECIFICATION, XX, XX, 25 January 1999 (1999-01-25), XP002154577 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015167713A1 (fr) * 2014-04-28 2015-11-05 Oracle International Corporation Système et procédé pour prendre en charge un modèle de domaine de dérivation et un modèle mandataire, et pour mettre à jour des informations de service pour une messagerie entre des domaines dans un environnement médiateur de transactions entre des machines
US9723110B2 (en) 2014-04-28 2017-08-01 Oracle International Corporation System and method for supporting a proxy model for across-domain messaging in a transactional middleware machine environment
US9749445B2 (en) 2014-04-28 2017-08-29 Oracle International Corporation System and method for updating service information for across-domain messaging in a transactional middleware machine environment
US10091333B2 (en) 2014-04-28 2018-10-02 Oracle International Corporation System and method for supporting a bypass-domain model for across-domain messaging in a transactional middleware machine environment

Also Published As

Publication number Publication date
CA2449953A1 (fr) 2003-03-06
US20040181530A1 (en) 2004-09-16
WO2003019369A3 (fr) 2004-02-05

Similar Documents

Publication Publication Date Title
Becker et al. Base-a micro-broker-based middleware for pervasive computing
US6845393B1 (en) Lookup discovery service in a distributed system having a plurality of lookup services each with associated characteristics and services
Mascolo et al. Mobile computing middleware
Lee et al. Protocols for service discovery in dynamic and mobile networks
US6983285B2 (en) Apparatus and method for dynamically verifying information in a distributed system
US6157944A (en) System and method for replicating a client/server data exchange to additional client notes connecting to the server
JP2002505466A (ja) 遠隔メソッド呼出し方法及び装置
US20020147652A1 (en) System and method for distruibuted client state management across a plurality of server computers
US7827230B2 (en) Cell-based computing platform where services and agents interface within cell structures to perform computing tasks
Andersen et al. Enabling synergy in iot: Platform to service and beyond
JP2001290724A (ja) プラグアンドプレイ機能を有するフレームワークおよびその再構成方法
CN101739295A (zh) 基于进程调用扩展程序的方法和装置
Sen et al. Cian: A workflow engine for manets
US20040181530A1 (en) Distributed networking system for resource-constrained computing devices
US20020198895A1 (en) Apparatus and method for dynamically verifying information in a distributed system
EP1644838A2 (fr) Protocole de communications interprocesseur
Hackmann et al. Supporting generalized context interactions
Smith et al. A jini/sup tm/lookup service for resource-constrained devices
Dobson et al. Adaptive middleware for autonomic systems
You et al. Context-based dynamic channel management for efficient event service in pervasive computing
JP2006171917A (ja) 無線マルチホップアドホックネットワークのためのプロトコル
Preuveneers et al. Suitability of Existing Service Discovery Protocols for Mobile Users in an Ambient Intelligence Environment.
EP2317726A1 (fr) Découverte d'un service indépendant du transport
Kastner et al. How Dynamic Networks Work: A short tutorial on spontaneous networks
Back et al. A ZigBee Adaptor for Data Distribution Service-Based Interoperation Among Heterogeneous Internet of Things Devices

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ PL PT RO RU SE SG SI SK SL TJ TM TR TT TZ UA US UZ VN YU ZA

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2449953

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 10483209

Country of ref document: US

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP