JP3711866B2 - Framework having plug and play function and reconfiguration method thereof - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a method and apparatus for integrating multiple networks with different communication protocols into a single unified framework to enable user applications to discover and utilize various network devices. The invention also relates to a method for achieving dynamic adaptation and reconfiguration of network nodes in response to changes in available functions and user interaction. The invention also relates to methods by which applications, services and devices describe their capabilities and publish them to other applications, services and devices. Furthermore, the present invention allows physically different devices to connect, exchange information, negotiate data types, provide status for each operation, and achieve network plug and play. And a method for providing a platform independent and transport independent protocol.
[0002]
[Prior art]
With the advent of global networking infrastructure, large-scale deployment of distributed services and applications has become commonplace. In current and future networks, it is expected that more services will be deployed to disseminate time-sensitive information to the world and to mediate global transactions electronically. Before such distributed services become universal, new mechanisms are needed to simplify the development, debugging, deployment and evolution of such services. Such a mechanism will need to discover the necessary services and use their capabilities regardless of the underlying protocol or interface.
[0003]
A typical distributed network system, such as one that can be used at home, interconnects a variety of different devices. Because various home appliances (home devices) may inherently use different interfaces and protocols, it is almost impossible to interconnect all these devices using a single common communication protocol It is. In some cases, it is convenient to use wiring that is already installed in most homes (eg, using an existing power line for communication with an X-10 device). The transmission speed of the network to be used is limited. For example, X-10 devices such as incandescent bulbs and home security systems operate at a data rate of several bits per second. On the other hand, devices such as digital TVs, cameras, or VCRs require much higher transmission data rates. Such devices are typically interconnected using the IEEE 1394 architecture protocol, with data transfer rates reaching 400 Mb / s.
[0004]
In contrast, various home automation applications currently being developed require effective interaction of various home appliances. Therefore, to enable the effective interaction of all the different devices and services installed in the home, the different networks are integrated into a unified framework and are located in different networks. Must provide a mechanism for network entities to discover and interact with each other.
[0005]
It is also desirable to provide a user application with a means of using remote services without requiring the application to handle low level protocol specific details for various device interfaces and network protocols.
[0006]
To achieve true plug-and-play capability, the framework must provide a mechanism to automatically discover services provided by newly added devices. Within such a framework, descriptions of available network services and their network locations must be readily available to all user applications. In addition, the user application must be able to automatically reconfigure its communication interface for communication with specific devices or services that may be encountered. In addition, the framework must include a security model that performs user authorization and authentication to control access to network services.
[0007]
Jini ^TM Is one of the existing candidates to achieve network plug and play (Jini is a trademark of Sun Microsystems, Inc.). Jini is a set of application programming interfaces (APIs) and runtime contracts that facilitate the construction and deployment of distributed systems. Jini provides "plumbing" that handles common but different parts of distributed systems. Jini consists of a programming model and a runtime infrastructure. By defining APIs and contracts that support leases, distributed events, and distributed transactions, the programming model allows developers to build reliable distributed systems even when the underlying network is unreliable. help. The runtime infrastructure consists of a network protocol and an API that implements it to facilitate the addition, discovery, access, and deletion of devices and services on the network.
[0008]
The use of Jini provides an easy way to discover services without knowing about the underlying network technology. An improvement over Jini over other known infrastructures is that the user application can actually search for a service and let others find a host that supports that service. However, the main unresolved issue is "How do user applications automatically use services on client machines?" If the client user application is only provided with a service interface, the client must have code that can understand this service.
[0009]
For example, consider a situation where a user wants his application to browse a network for camera services. If an application finds such a service on the network, the user can click it and use it in his own application. If a user needs code to perform such a service, such code must be automatically downloaded onto the user's machine. However, the main problem associated with this approach is how user applications use such services. If the user application has an extensible interface, it can query the remote service interface to obtain its unique characteristics and enable its use. However, the definition of such an extensible interface is Jini ^TM Jini not within specification ^TM It is left to the user application that uses the service.
[0010]
Another issue is the identification of entities that define the semantics of camera services. For example, if major camera manufacturers, including Canon, Minolta, and Nikon, each provide a unique interface, the camera service will not be interoperable, and users will be able to use all three different camera services in code. Will have to provide to. Also, if Kodak is Jini ^TM If the camera is decided to be marketed, the user must manually change the code to include an analysis of the Kodak interface. Such an extensible interface greatly increases network traffic and client code size. It is preferable that all types of market-specific groups collectively specify an interface, which in many cases will be required, but this is not likely to be realized quickly and efficiently, especially It is extremely unrealistic for all kinds of devices used at home.
[0011]
Another limitation that has not been resolved in the known network is Jini. ^TM How non-Jini based application ^TM It is about whether the data on the base operating system can be accessed. That is, the user can, for example, Jini ^TM Without MS support for MS-Word ^TM To Jini ^TM Can you access the printer? Java that wants to use a Jini printer ^TM Even applications must rely on the operating system for access.
[0012]
For example, when a user program requests access to a print method, the following code fragment is used.
object o = Lookup (GeneralPrintService);
GeneralPrintService pservice = (GeneralPrintService) o;
pservice.print ();
[0013]
However, when this code is written, the programmer does not know if an interface named GeneralPrintService really exists at code execution time. Furthermore, if a programmer wants to print an image on multiple devices, it must anticipate multiple interfaces and print accordingly.
[0014]
Jini can be used such that user interface (UI) components are added as entries to the service's attribute list, so the client knowledge required for the service is minimal. The client need only know that the UI is represented by attributes similar to applets. Since UI can be provided as JavaBeans, through introspection and reflection, the service can provide the client with a means by which the client can use the service. . This is essentially a message exchange between the client and server and requires manual configuration. However, adding a UI component may prevent non-human clients (machines that are created and used) from using the device. Further, when the number of devices increases and the client program becomes complicated, another problem arises. In that case, the client must determine which object in the returned list is the true target. Furthermore, every Jini ^TM Devices or applications require all interfaces (or at least “all types of devices”) of all devices needed to communicate at the time of manufacture. As a result, Jini ^TM Does not actually solve the interoperability problem.
[0015]
Another existing networking system, HomeAPI, is a set of object-oriented software services and application programming interfaces (APIs) that allow applications to discover and use various home devices. The system was designed so that the user application is not involved in the protocol-specific details of the devices and networks used by the application. The HomeAPI provides a set of software objects that represent a distributed service that facilitates developing user applications that utilize the service through the use of the HomeAPI interface.
[0016]
However, the Home API does not solve the problem of discovering new devices and therefore does not provide the desired plug and play networking capabilities. Another shortcoming of HomeAPI is that it requires all network devices to provide a standard communication interface, which is not feasible in today's market.
[0017]
Other developing network initiatives such as HomePNA, HomeRF, Bluetooth, PIANO, X-10, CEBus, IEEE 1394, USB, HAVi, etc. simply provide various protocols for network connectivity. These communication protocols are well known to those skilled in the art. However, there is currently no unified framework system that solves the interoperability problems of various competing network technologies and protocols and achieves network plug and play.
[0018]
[Problems to be solved by the invention]
Thus, there is a strong and wide acceptance of a unified framework that interconnects various types of network devices and provides a uniform mechanism for device discovery and use, and there are such This is very advantageous. Such a unified framework is such that user applications can find application-to-service communication protocols, discovery of the IP address of a host connected to the device providing the desired service, and even details of the user interface of the network service While eliminating the need to incorporate such low-level details and satisfying the other requirements described above.
[0019]
[Means for Solving the Problems]
Accordingly, one object of the present invention is to overcome the above limitations of known networking systems and integrate multiple networks with different communication protocols interconnecting various devices into a single unified framework. It is to provide a method and apparatus that allows a user application to discover and utilize various network devices.
[0020]
Specifically, it is an object of the present invention to provide a method and apparatus that achieves dynamic adaptation and reconfiguration of network nodes in response to changes in available functionality and user interaction.
[0021]
Another object of the invention is to provide a way for applications, services and devices to describe their capabilities and communication interfaces and publish them to other applications, services and devices.
[0022]
Yet another object of the present invention is to achieve network plug and play by physically different devices connecting, exchanging information, negotiating data types, and providing status for each operation. It is to provide a method and apparatus for providing a platform independent and transport independent protocol.
[0023]
In order to achieve the above object and achieve the effects of the present invention, an active configuration framework system is provided. The framework of the present invention interconnects services and service users. The framework also has a plug and play broker. In the framework of the present invention, a service user uses a plug and play broker to discover, use, and communicate with a networking service.
[0024]
In the framework of the present invention, a service user communicates with a service through a plug and play broker interface independent of the communication protocol used by the device providing the service.
[0025]
The present invention also provides a gateway for registering a service with a plug and play broker.
[0026]
The present invention also provides an active configuration framework having a service agent, a user agent, and a directory agent. In the framework of the present invention, the service agent registers the service with the directory agent. The user agent then communicates the description of the requested service to the directory agent, which returns the location of the matching service.
[0027]
In the framework of the present invention, a service can consist of a device cluster and a gateway. The service agent communicates with the device cluster through this gateway.
[0028]
The present invention also provides a method for automatically reconfiguring the framework in response to the addition of a new network device. According to the method of the present invention, the service agent registers the service with the directory agent. The user agent then communicates a description of the requested service to the directory agent. Finally, the directory agent matches the description of the requested service with the description of the service it provides and returns the address of the matching service to the user agent.
[0029]
The present invention also provides a method for generating a communication interface for a service executed by a new network device added to the framework. According to the method of the present invention, the device generates a schema that describes its communication interface. This schema can be in the form of an XML (eXtensible Markup Language) document. In this case, the user application generates a communication interface using an XML language parser.
[0030]
The present invention also provides a method for controlling a network device. According to the method of the present invention, the user application edits the device description schema and returns the edited device description schema to the device. In response, the device changes state according to the edited device description schema.
[0031]
DETAILED DESCRIPTION OF THE INVENTION
A unified framework is required to achieve network plug and play across all types of distributed devices and services. The term “framework” or “substrate” as used herein refers to a system that integrates one or more networks. However, in many cases, the terms “framework”, “substrate”, and “network” are used interchangeably.
[0032]
By using the framework of the present invention, complex mechanisms for networking entity interaction need only be implemented once, regardless of the number of different physical devices in the network. In addition, these mechanisms are hidden from user applications that interact with the management broker through a device-specific gateway. The framework of the present invention is based on well-known Internet-related protocols such as SLP, HTTP, XML, JavaRMI, and IIOP, and can be implemented as an add-on to a web server, so it is easy to deploy and use. Furthermore, in the framework of the present invention, the entire service discovery process is transparent to the user application (transparent) and has no distinction to physical connections (connections). For example, plug and play devices connected to the network need not be TCP / IP based. The service usage process is also transparent and is based on the capabilities of the various devices covered and user authentication and authorization. When connecting incompatible devices, tunneling and complete data conversion may be required.
[0033]
The present invention provides an active configuration framework for facilitating device-independent information exchange. Different protocols are required for multiple devices to connect, exchange information, negotiate data types and provide status for each operation. These protocols are platform independent and can be incorporated into any device that needs to connect to other devices, regardless of their form or function. Since these protocols are also transport-independent, any device can connect to and exchange information with any other device.
[0034]
In the framework of the present invention, user-defined calculations are placed in the network as in the case of an active network. However, unlike active networks, all routing and forwarding semantics of the current Internet architecture are preserved by limiting the computing environment to the application layer. Network devices and services that make use of this framework are actually created, configured, and dynamically controlled by user applications on end systems, even when deeply integrated into the network infrastructure. Such application-defined entities can be executed at any node in the network, and individual packets can be programmed to propagate through the network and perform any action.
[0035]
[Active Configuration Framework components]
A complete active configuration architecture consists of a dummy device, a gateway device, and a PnP broker connected directly or indirectly to the network. The architecture of the active configuration framework is shown in FIG. As shown in FIG. 1, the network has one or more execution environments 102. The execution environment 102 is interconnected using a network 101 such as the Internet. The execution environment 102 acts as a network node in a sense. The execution environment 102 is a Java virtual machine or Windows known to those skilled in the art. ^TM It can be in the base machine. The execution environment 102 has one or more PnP brokers 104 connected to non-intelligent (ie, dummy) devices through a gateway (not shown). The user application 103 discovers, uses, and communicates with the device through the PnP broker 104. In the following, the various components of the active configuration framework system of the present invention will be described in detail.
[0036]
[Dummy device]
A dummy device is a device without a TCP / IP protocol stack, a Java virtual machine, or both. Such devices are not directly accessible from the network and require a gateway as an intermediary. Such devices need to make certain configuration choices before being installed on the network. For example, each X-10 device (such as an incandescent bulb) must be manually assigned a house code and device code before connecting to the power line network. Further, such devices do not implement security or access control for the services presented. Most of these devices have no memory or processing power and can be characterized as legacy devices that still need to be connected to the rest of the network.
[0037]
[Gateway device]
Regular network devices can interact in a peer-to-peer manner with a single network type (eg, IP or IPX). This means that a device of a certain network type can only communicate with devices of the same network type that are physically connected to the same network. The first device connects to a second device on a network not supported by the first device or to a second device running a protocol not supported by the first device; Problems arise when you need There are two approaches to solving this problem.
[0038]
The first approach is to load multiple communication stacks into a single network device. This allows the device to interact with any type of network device as long as it has an appropriate communication stack. Although the underlying transport is different, this approach works well if the device understands the entire protocol stack.
[0039]
In order to solve the problem of connecting a plurality of different devices, the framework system of the present invention uses a gateway. A gateway is a device that exists invisible in a network and converts one network type to another network type. This approach is used in embodiments of the present invention where the destination device is legacy and each source device must model the destination in order to communicate with the destination. This is the case, for example, for fax devices and e-mail devices. Rather than adding the ability for the device to interact with the legacy network, this functionality is placed at the gateway. The gateway is typically hosted on a programmable platform.
[0040]
In the framework of the present invention, when a PnP broker wishes to establish a session with a legacy (dummy) device that requires a gateway for access, the gateway hides the presence of that device from the PnP broker. Instead, the PnP broker creates a session with the gateway and passes the address of the dummy device to the gateway. From this point on, when the gateway receives data through any channel in the session, it relays the data to the remote device through the gateway-dummy link. The present invention uses two types of gateways: The generalized gateway communicates with the IP device, and the specialized gateway communicates with the non-IP device through the dummy. The specialized gateway exposes the dummy device to the network, and includes programming logic for controlling and managing the device. Furthermore, the specialized gateway implements a dummy device security policy. One gateway device can manage a plurality of dummy devices.
[0041]
[PnP broker]
The PnP broker acts as a service broker for applications, services, and devices. The PnP broker extends the Infobus concept for distributed systems and treats the entire network as a Software Bus. Infobus systems are well known to those skilled in the art. A detailed description can be found in Reaz Hoque, “Connecting JavaBeans with InfoBus”, Wiley Computer Publishing, Nov. 98. Software Bus is also well known to those skilled in the art, and Brian Oki, Manfred Pfluegl, Alex Siegel, and Dale Skeen, "The Information Bus-an architecture for extensible distributed systems", Proceedings of the 14 ^th Symposium on Operating Systems Principles, p. 58-68, Asheville, North Carolina, December 1993.
[0042]
A PnP broker allows networked entities to discover and use the capabilities of other networked entities (gateways or dummy). The gateway registers its capabilities with the corresponding PnP broker, and the dummy device discovers the gateway and communicates with the PnP broker through this gateway. Each type of device in the network (eg, X-10X, 1394X, USB) has a specific gateway that is connected to this device cluster at one end and connected to a PnP broker at the other end. X-10, HAVi, IEEE-1394, and USB are well-known communication protocols. If two different gateways want to interact with each other, a PnP broker can be used for communication. For example, one gateway can represent a Jini cluster while another gateway can be a gateway for an IEEE 1394 cluster using HAVi. In the framework of the present invention, the gateway communicates with passive (non-TCP / IP) devices by using a dummy designed for that architecture.
[0043]
FIG. 2 shows the overall design of the active configuration framework. The PnP broker 104 operating in the execution environment 102 communicates with the dummy device 203 and the user application 202 through the gateway 201. The gateway device 201 operates on the network node 205 within its operating system environment. Node 205 provides a security enforcement mechanism 204 to control access to gateways and services.
[0044]
Networked entities are subdivided into meaningful functions called service units. In principle, the architecture defines one meaningful function as one service unit from the point of view of the user application. The service unit can be the entire user application / service or it can be part of the user application / service. Commands, responses, and data can be exchanged between a user application and a service unit, between a service unit and a service, or between a service unit and another service unit. The service unit registers its function with the PnP broker.
[0045]
A PnP broker allows networked entities to discover and use the capabilities of other networked entities. The network connection entity can be a service user (user application). The user application discovers the service through the PnP broker and requests to use it. The PnP broker provides a transport-independent interface (referred to as a PnP broker interface) for connecting a service unit and a user application. This interface is designed to work on the TCP / IP protocol stack. A PnP broker communicates with other PnP brokers in different clusters to fulfill its role as a service broker or manager. A protocol between PnP brokers is called a PnP broker-to-broker protocol.
[0046]
Each device cluster has at most one PnP broker. When there is no local PnP broker, the user application / service unit can use a remote PnP broker (PnP broker connected to another gateway) through an Internet communication protocol such as Java RMI or HTTP. The Java RMI protocol is well known to those skilled in the art. A detailed description can be found in Downing, Troy Bryan, "Java RMI: Remote Method Invocation", IDG Books Worldwide, 1998. HTTP protocols are also well known to those skilled in the art. The description is in “Paul S. Hethmon,“ Illustrated Guide to HTTP ”, Manning Publications, 1997. Service units can also use PnP brokers directly connected to it, and between PnP brokers. It is also possible to use a remote PnP broker by using a protocol, in the network system shown in Fig. 3, the service unit 406 has services 1406 and 1402 connected to the remote PnP broker 1104 through the inter-PnP broker protocol 404. In this way, a service unit can query and use services available in service units located in different device clusters.
[0047]
[PnP broker functional components]
The internal components of the PnP broker are shown in FIG. The PnP broker typically comprises a service registry 305, a service discovery / availability agent 304, a service session management agent 306, a service location protocol (SLP) user agent 308, and an SLP service agent 307. The inter-PnP broker protocol 303 is used for communication with other PnP brokers 301. The PnP broker interface 302 provides an interface to the user application 103. The Service Location Protocol (SLP) is well known to those skilled in the art and is described in James Kempf and Pete St. Pierre, "Service Location Protocol for Enterprise Networks: Implementing and Deploying a Dynamic Service Resource Finder", John Wiley and Sons, 1999. Has been. The service registry includes one or more service records. All information in the service registry is described as XML (eXtensible Markup Language) to facilitate searching, indexing and exchange. XML is also well known to those skilled in the art, and Natanaya Pitts-Moultis and Cheryl Kirk, "XML black book", Coriolis Group Books,
1999.
[0048]
[Service Registry]
A PnP broker includes a service registry to hold information about services. At a minimum, the registry stores information about gateways and services that are directly connected to that PnP broker. As shown in FIG. 3, these services reside at the local PnP broker 104 or the remote PnP broker 1104. Furthermore, the PnP broker registry can also store information about services registered with other PnP brokers. This extended registry functionality allows the local PnP broker to maintain a local directory of services. This is important for local environments and eliminates the need for a separate “centralized” SLP directory agent in the network. For example, if the local PnP broker supports print servers, the registry may have information about all compliant print servers. Finally, this information can be used for load balancing, fault tolerance, or caching. The PnP broker service registry can also act as a network directory that provides information about all compliant devices within range of the local PnP broker, regardless of device type. In this case, one of the PnP brokers in the network will be designated as the central directory responsible for finding and registering all PnP brokers. All requests from other devices for network resources are sent to this PnP broker, which will respond to each.
[0049]
[Service Record]
A service record is a set of available service units in a networked cluster that describes available services and services requested from other PnP brokers. A service record consists of zero or more service unit records in the local cluster. The service unit record includes a service unit ID field followed by zero or more attribute records. The service unit ID field identifies the type of service unit and the service provided by that service unit. A device has only one service unit, but can also have multiple attributes. The attribute record includes an attribute ID field, its value, and access control information. Attribute records are mainly used to implement fine access control for each service or device. In addition, the attribute record stores the current state of the device and a description of the interface that can be used to change it.
[0050]
[Service Discovery / Availability Agent]
PnP brokers require a service discovery / availability agent to discover remote PnP brokers and identify available services. Service discovery is performed by comparing the requested service type specified by the local PnP broker with the service types available on the remote PnP broker. The above-mentioned Java RMI or HTTP can be used to send the requested service type from the local PnP broker to the remote PnP broker and send the response from the remote PnP broker to the local PnP broker. A specified check of the requested service type allows the PnP broker to determine the characteristics of all or specific services registered with the remote PnP broker. The service discovery / availability agent is located above the SLP user agent and the SLP service agent.
[0051]
Furthermore, the PnP broker can periodically check the availability of the service using a service discovery / availability agent. The local PnP broker requests the appropriate PnP broker to perform an availability check. In an embodiment of the present invention, the user can specify the availability check period and cancel this check.
[0052]
[Service Session Management Agent]
When a user application discovers a service or device and wants to use it, the PnP broker establishes a virtual pipe (tunnel) between the user application and the service. This is called a service session. Such tunnels can be used to exchange commands, responses and data between user applications and services. According to the organization of the device interface, these commands, responses and data have a specific format and are exchanged under a defined protocol. The PnP broker can be commanded to operate in one of the following three protocols while managing this virtual pipe.
[0053]
[Native data transfer in native packet]
The PnP broker enters the background after setting up the data pipe, thereby allowing user applications and services to manage message streams and data formats. This approach is useful when the PnP broker is used alone to discover the capabilities of other network entities, and when applications, services, and devices manage the interaction between user applications and discovered services. is there. Messages are exchanged directly between the user application and the service without the involvement of the PnP broker. Message exchange is strictly a form of native data in native packets. A user application can use the PnP broker-to-broker protocol to discover a service or request a service before requesting the service. For example, an IEEE 1394 compliant camera can send a data stream to a digital VCR using this data exchange format.
[0054]
[Native data transfer (tunneling) in PnP broker packets]
While the data format is selected and controlled by user applications and services, a PnP broker can also set up data pipes and manage message streams. This approach is useful when there is no common messaging protocol between user applications and discovered services. All messages are carried by the PnP broker-to-broker protocol. For example, an IEEE 1394 enabled camera sends a data stream through a PnP broker to digital VCRs in different clusters.
[0055]
[PnP broker data in PnP broker packets (fully functional gateway)]
A PnP broker sets up data pipes, manages message streams, and provides data format definitions for user application and service interactions. The broker also provides a common messaging protocol and common data format between user applications and discovered services. Message exchange information is contained in PnP broker data, which is formatted into packets. User application messages pass through the PnP broker, but the PnP broker does not examine the content or semantics of the message. An example of this type of interaction is an IEEE 1394 compliant device that interacts with a USB device.
[0056]
[SLP user agent]
A user agent is a process that operates on behalf of a user to establish a connection with a service. The user agent acquires service information from the service agent or directory agent.
[0057]
[SLP service agent]
A service agent is a process that operates on behalf of one or more services to publish services.
[0058]
[Protocol and interaction]
The PnP broker exposes a standardized interface that allows user applications to take advantage of network plug and play capabilities. With this PnP broker interface, applications can be written to communicate with each other using a PnP broker-to-broker protocol independent of the transport layer. This design promotes portability and provides a scalable framework for network service discovery and selection. The inter-PnP broker protocol is based on IETF Service Location Protocol v.2, and it is not necessary for the user application to know the name of the network host that supports the service. Rather, the user provides the desired service type and corresponding set of attributes to the PnP broker through the PnP broker interface. These describe the desired service for the PnP broker. Based on this description, the PnP broker uses the PnP inter-broker protocol to resolve the network address of the service, and the PnP inter-broker protocol uses the service location protocol. The PnP broker interface also handles user identification and authentication mechanisms for devices or services. Once the service is identified, the PnP broker-to-broker protocol uses Java RMI or HTTP to allow user applications to use the discovered service. Another important feature of this framework is provided by the gateway. The gateway registers the capabilities of the device with the PnP broker and allows the PnP broker to use the service through the service agent at the PnP broker.
[0059]
In summary, the protocol suite of the present invention consists of the following protocols and interfaces:
An interface between the PnP broker and the user application.
A protocol between one PnP broker and another PnP broker.
Protocol between PnP broker and gateway.
-Protocol between gateway and dummy.
[0060]
[PnP Broker Interface to User Application (PnP Broker Interface)]
The PnP broker exposes standardized APIs and interfaces to user applications for service registration, service discovery, service requests, and availability checks. In addition, the PnP broker handles user identification and authentication for the appropriate service or device.
[0061]
[Service Registration]
When necessary, the service unit or user application calls RegisterService () or UnregisterService () to register or unregister itself with the local PnP broker as a service unit or user application, respectively. After a user application or service unit is registered with the PnP broker, its functionality is included in a response to a QueryService () or SearchService () request from another user application or service unit.
[0062]
[Service discovery]
The user application calls SearchService () to request the local PnP broker to search for a PnP broker that contains a registered service unit with a particular service. The user application calls QueryService () to find out what service unit is registered and the function of the service unit registered in the PnP broker specified by the user application.
[0063]
[Service Request]
The user application or service unit calls OpenService () to request the local PnP broker to initiate a service session with a particular service unit registered with either the local PnP broker or the remote PnP broker. Additional functions are provided by the TransferData (), ReceiveData (), and CloseService () calls.
[0064]
[Availability Check]
The user application or service unit calls StartAvailabilityCheck () to periodically check with the local PnP broker whether a specific service unit registered in either the local PnP broker or the remote PnP broker is operating. Request to do.
[0065]
User identification and authentication
In the preferred embodiment, the present invention utilizes a Java application environment. This is because it provides a currently available computing platform suitable for distributed computing. In this environment, both code and data can be moved between machines. This environment has built-in security that allows code downloaded from another machine to operate with a reasonable level of reliability. Due to the strong typing in the Java application environment, identification of an object's class on a virtual machine can be performed even when the object is not generated on that machine. As a result, the network supports a fluid configuration of movable objects as needed and can call any part of the network to perform operations.
[0066]
Unauthenticated access to home devices can have serious consequences for overall framework security. Controlled access to resources is the foundation of safety and security. Thus, one embodiment of the present invention uses a Java virtual machine and Java programming environment to ensure the security of one device. Although the system can be designed to handle faulty devices, network security is a more complex issue than device security.
[0067]
Another embodiment of the invention uses the MD5 checksum of the code as a means of referencing the code and as a basic access control mechanism. MD5 is an encryption procedure that generates a checksum of a code and is used for access control. However, as the network grows, there is a need for a more flexible distribution mechanism for specifying security policies and naming code.
[0068]
The security model of the present invention is built on two concepts: principals and access control lists. Services are accessed on behalf of an entity (principal). Principals generally come from a specific user of the system. The service itself can request access to other services based on the identity of the object that implements the service. Whether or not access to the service is permitted depends on the access control list corresponding to the object.
[0069]
[Communication protocol between PnP brokers]
The inter-PnP broker communication protocol is divided into two parts. First, a set of protocols and mechanisms are used to discover new devices and services in the network. The discovery procedure is a service discovery protocol that specifies how the user application explores the network infrastructure and how the user application can register itself and its services. Based on part. On the other hand, the lookup procedure is based on a protocol that specifies how the user application queries the registry to find the services it needs in the presence or absence of a centralized registry.
[0070]
Once a service is searched, other steps may be required to use that service. In an embodiment of the present invention, the user application negotiates access to the service, including quality of service and security conditions. Furthermore, after successful negotiation of access to the service, the user application actually uses the service using Java RMI, HOP, or HTTP protocol.
[0071]
[Service Discovery / Registration Process]
Service Location Protocol (SLP) is used for both lookup and discovery. FIG. 5 shows a service discovery procedure. The SLP automatically matches a user agent (UA) 502 request with a service 512 provided by a service agent (SA) 504 without any prior configuration. The SLP handles the service announcement by the SA and the organization of the service into the SLP directory 508 managed by the directory agent (DA) 511. The SLP also provides a means for the service to notify the user application of the service capability and setting conditions.
[0072]
The UA 502 in the PnP broker 501 understands service and resource requests by the user application 103. Similarly, the SA 504 in the PnP broker 503 (which may be the same PnP broker or a different PnP broker) represents each network service and provides a service available to the UA 502. Since the SLP dynamically holds service attributes, the UA 502 can obtain current information. The service can be searched automatically by the application, or it can be presented to the user in a service browser. SLP supports existing applications and facilitates the publication and discovery of new services.
[0073]
According to the invention, services are described by gateways. The gateway sets the value of the attribute in the SA (corresponding to the service). For example, a printer can be described as a Postscript printer, as a printer that can use blue paper, or as a printer on the same floor of a user's office. The UA 502 selects an appropriate printer by specifying necessary keywords and attribute values in the request message SrvReq 505 to the DA 511, and waits for a response. DA 511 responds with a response SrvRply 505 containing the network location of the appropriate service. In a small facility, it is possible that there is no DA, in which case the request message will be sent directly to the SA. This is called discovery by broadcast (507).
[0074]
The service announces itself by registering with DA511. Service registration includes a list of all keywords describing the service and attribute value pairs (attribute and value pairs). Registration also includes a lease to the resource. Thus, after the lease expires, the service information is deleted by the DA 511. The leasing mechanism is implemented to avoid situations where service hardware is no longer available while services continue to be published forever. Explicit deregistration can also delete service information from the DA as part of the SA's orderly shutdown procedure. It is also possible for the UA to check the status, load, temperature, or other dynamic characteristics related to the service by periodically registering the current attribute information by the SA.
[0075]
In the framework of the present invention, services are classified according to their service type. Each service type defines a set of available keywords and attributes that the SA 504 makes available to describe the service. The service browser first determines all characteristics of all services available to the UA 502 by finding a service type available to the UA 502 and then querying all information published by the SA for that service type. can do.
[0076]
[Interaction between user agent and service agent]
As part of the service / device registration process, the gateway of the service unit 512 first registers the service or device with the SA 504, and then the SA 504 sends a SrvReg message 506 to the DA 511. This registration includes a service URI for a particular instance of the service and an attribute value pair that describes the service. The DA 511 can cache such registrations for various purposes. After the registration is cached, DA 511 responds with an SrvAck message. Service registration also includes a lifetime. If the service becomes unavailable but fails to deregister itself, the lifetime value allows the DA 511 to expire the cached registration. This situation should only occur if the SA 504 is unable to issue the SrvDereg message 506. During normal operation, the SA 504 periodically refreshes the service registration with subsequent SrvReg messages. Such a “refresh” message may include updated information if any value changes, but need not include a complete set of attributes.
[0077]
The UA 502 of the PnP broker 501 makes a request to the DA 511 when a service is requested. There are several ways in which UA 502 can discover DA511. In addition to statically setting the address of the DA 511 in the UA 502 at startup, the UA 502 can request the address of the DA 511 using DHCP (Dynamic Host Configuration Protocol) well known to those skilled in the art. A third option is to multicast on the link and receive DA announcements. Although these three options coexist, it is important that the SLP can operate without manual configuration. For this reason, UA 502 can use SrvReq to find DA511. SrvReq is multicast to the IANA assigned multicast address for the SLP. IANA is an Internet Assigned Numbering Authority standard well known to those skilled in the art. Since this is a multicast request, multiple unicast responses may be received. The resulting DA glue can be used for other service requests.
[0078]
Once UA 502 obtains the address of DA 511, subsequent service requests can be made directly to that entity. Taking a printer as an example, when the UA 502 tries to search for a printer service, an SrvReq is created. This message includes a service type “printer” and a list of optional attributes and values. The attribute value pair describes the type of printer requested. This message is unicast to DA 511, either preconfigured or discovered through multicast. DA 511 receives the SrvReq and performs a lookup on the cached registration to attempt to find one that matches the requested attribute and value. The SrvRply is then unicast to the requesting UA 502. This response includes zero or more service URIs depending on the match result. The user application then uses the service URI to find the printer.
[0079]
If there is no DA 511 in the facility, the PnP broker is also limited to finding the SA 504 in the raster. This may be acceptable in many small facilities, but DA511 must be used for scalable applications of PnP brokers and in large facilities with multiple clusters. In addition, because SLP DA 511 can be a gateway to LDAP-based directory 509, the PnP broker interface uses conversion schema 510 to provide a single API for all protocols.
[0080]
When the UA 502 wants to obtain a service handle, the UA 502 transmits a service type and a character string-based query of the requested attribute as a service request. When a service response is returned, this includes a URI pointing to the service. The URI contains the IP address of SA504, or else a name that DNS can resolve to an IP address. The URI also includes other information necessary for the UA 502 to use the service. For example, in the case of a printer, the queue name and the address of the computer hosting the print service are returned. The URI is used to find services in a natural way similar to traditional standards for representing resource locations. Furthermore, the character set problem can be dealt with in a standard way.
[0081]
[Interaction of PnP Broker with User Agent and Service Agent]
By using SLP, a PnP broker can make an accurate selection of appropriate services from many other published devices of the same type. This is done by requesting only services that match the keyword requested by the UA 502 and the requested attribute value. Such keywords and attribute values can be combined into Boolean expressions by AND, OR operators, common comparison operators, and by using substring matching.
[0082]
The PnP broker makes the provision of configuration information transparent to the user and facilitates the work of setting a new service. Both of these require a system administrator. After SA 504 is configured to publish services to neighboring DAs 511, UA 502 can dynamically adapt to conditions that change on the network as various services start and stop operations. For example, a web application can find it as long as a suitable printer is available, independent of the system that happens to be currently running.
[0083]
When the gateway wants to add a new device or service to the SA 504, it provides available attributes and keywords for that service. The SA 504 can programmatically register with the SLP and assign a value for the attribute based on the configuration information unique to the service. The SLP then processes the registration (publication) and allows the connection between the user application and the service to be established.
[0084]
New service types can be defined as needed. It is also possible to deploy experimental service types for limited use and then make them publicly available. This is performed using the naming authority function of the SLP. Most common service types, by default, use a service template (scheme) definition standardized by the Internet Assigned Numbering Authority (IANA). Defining an alternate service type is as easy as configuring a directory agent to use a scheme definition known to any alternate naming authority (usually a name known to the local administrator) It is. For example, in order to provide a security service at home, a service type "service: secure: Door" can be defined. Of course, user applications that utilize this type of service handle must use the service's network protocol to communicate with the "secure" service, and the information contained in this special service type's URI. Must be able to analyze. This is inherent in the natural operation of any user application / server protocol.
[0085]
[Use SLP with LDAP]
LDAPv3 (Lightweight Directory Access Protocol) is well known to those skilled in the art and is becoming popular as a general-purpose directory access protocol. LDAP has Lightweight in its name, but SLP is “lighter” than LDAP. SLP is also superior to LDAP in resource management because it provides automatic directory management and does not require inappropriate resource placement in a hierarchical, less flexible namespace. Adding new service types in SLP is much easier than in LDAP. Queries by type are more efficient with SLP than with LDAP. Attribute descriptions for existing resources can be used in SLP, but not in LDAP.
[0086]
In SLP, discovery without prior configuration is possible. In contrast, LDAP first requires knowledge of the directory address and the directory scheme used by LDAP. SLP can evolve because it allows non-standard attributes and new versions of standardized service type templates.
[0087]
Embodiments of the present invention use SLP to simplify the management of the LDAP directory and allow the SLP to return information obtained from the LDAP directory as needed. In another embodiment, the SLP is used dynamically to enter service entries in LDAP, and the SLP query is mapped to the LDAP query, and LDAP is the back end of the SLP. One advantage of such a configuration is that the user application obtains user authentication information directly from the LDAP directory.
[0088]
[Service Usage Process]
The service discovery / registration process provides a service record that is searchable by a URI provided by the service location protocol. The exchange capability between PnP brokers is provided by exchanging QueryService () messages containing service records. This query describes the requirements of the service that the user application wants to use, and requests details of the service from the remote PnP broker.
[0089]
When receiving the QueryService () message, the receiving PnP broker compares the received service record with its own service record. Thereafter, the receiving PnP broker returns a service record including the matched service record to the requesting PnP broker. This approach provides a technique for a user application to search among all service units, a specific type of service unit, or a service unit having a specific set of capabilities. After receiving the service record, the user application can initiate communication with the PnP broker to use the service or device.
[0090]
The local PnP broker requests establishment of a service session between the user application and the service by sending a message to the remote PnP broker. This message consists of a user application service handle, a remote service unit handle, a protocol ID (via native / tunnel / gateway), a requester (requester) ID, and a requester credential.
[0091]
The remote PnP broker responds with a result code that specifies whether the requested service is accepted or rejected. The remote PnP broker can also include a redirect or retry after some time. If the service is accepted, the remote PnP broker sends a service handle that identifies the start of the service session. A service session deals with data transfer between a user application and a service unit or between two service units. When the user application completes the use of the service, it requests the local PnP broker to send a “close service” message to the remote PnP broker. Further, when the user application needs to periodically determine whether the service is available, it requests each PnP broker to perform an availability check between the PnP brokers in the framework. Can do. The availability check can be performed for the entire device or for specific services provided within the device.
[0092]
[PnP broker / gateway protocol]
The PnP broker / gateway protocol is based on a simple message exchange mechanism. As described above, the gateway represents a service unit directly connected to the gateway and registers a service to be provided. The gateway also reflects changes made in the configuration of any service for the service agent in the PnP broker. This registration is based on a lease and can be renewed by either the gateway or the service agent. Registration provides current information to the service agent. When a PnP broker receives a request for a particular service, it first checks the service agent to determine whether any directly connected gateway provides the required device or service. The gateway also allows service agents to register that they are interested in a particular event in the gateway and receive notification of the occurrence of that event. Such an event can be the addition / deletion of a device / service in the network. If the service record of the service matches the requirements of the application, the user application can set up a service session between the service unit in the gateway and the user application.
[0093]
[Event notification mechanism]
In the framework of the present invention, since the user application can register an event notification request with the server, the server can detect when the new device is online or when the attribute of the device changes. Will be notified. To accomplish this, the present invention provides a mechanism for delivering event notifications to registered users.
[0094]
There are several well-known network event notification protocols such as CORBA (Common Request Broker Architecture) event service, X-Window system event, SGAP, and BSCW. For example, the CORBA event service is described in detail in Robert Orfali and Dan Harkey, “Client / Server Programming with Java and CORBA”, Wiley, 1996.
[0095]
However, the above event notification service is designed to work with a specific architecture and imposes a large code base, so it is difficult to actually use in a lightweight notification service.
[0096]
In addition to the capabilities provided for registration for notification of some types of events, the user can associate attributes with notification requests. Preferably, such notifications should be delivered reliably and ensure a perfectly ordered end-to-end delivery. However, no acknowledgment or retry is required when the notification is delivered over an unreliable transport. The user application may request that the demand side of the event provide an explicit confirmation of receipt to the supply side. For authentication, the user can digitally certify the notification to ensure the correctness and integrity of the notification.
[0097]
The framework of the present invention achieves event notification in two ways through the use of SLP. According to the first embodiment, the service agent transmits a multicast announcement (SrvReg) after the service is updated. After receiving the update, the user agent can perform a browser update and the DA can update the registration. Such usage is not explicitly forbidden with SLP use, but can cause flooding. Furthermore, this approach does not work efficiently with many services, different languages, and digital signatures. SrvReg also includes the URI and attributes of each service added / deleted / changed in the network.
[0098]
In another embodiment of the invention, the service agent announces the SAAdverts message by broadcasting to all user agents in the network. The SAAdverts message contains a list of all service types offered. After obtaining the SAAdverts, the user agent unicasts the appropriate service request to the sending service agent. Announcements from service agents are made on an exponential backoff basis.
[0099]
[Gateway / Dummy Protocol]
The gateway / dummy protocol is a special protocol that reflects the type of device integrated by the network. The network may consist of an X-10 gateway, a USB gateway, and an IEEE 1394 gateway that connect X-10, USB, and IEEE 1394 devices / services to the rest of the network, respectively. The dummy device stores a record of a type corresponding to the service record in a proprietary format. Although the gateway / dummy protocol is unique, it exposes a standardized interface to the PnP broker.
[0100]
[Example]
According to one embodiment of the present invention, the network has one or more PnP brokers. The PnP broker acts as an interface between the user and some services. In one embodiment, a PnP broker for an X-10 device provides several buttons or other user interface widgets linked to services provided by the USB device. As used herein, the term “user interface widget” includes buttons, dialogs, text windows, scales and other graphical components used to create a graphical user interface for a user application. When a button is clicked, the PnP broker simply invokes a specific service through the X-10 gateway. The following steps are required for the user application to use the newly registered service in the network according to this embodiment.
[0101]
1. An incandescent bulb is inserted into the household power outlet.
[0102]
2. Since the incandescent bulb is a dummy device, it is connected to the power line network through the X-10 device.
[0103]
3. In the home network, the PnP broker and X-10 gateway are already in operation before the introduction of new devices.
[0104]
4). The X-10 gateway periodically polls for available addresses and checks whether any devices have become active.
[0105]
5. The gateway recognizes that a new device has entered the network and registers both that device and the services provided by that device with the service agent of the PnP broker.
[0106]
6). The service agent obtains a lease to use the device. This lease must be renewed after each lease period, thereby requesting the gateway to check if the service is still available.
[0107]
7. The service agent registers the service provided by the device with the directory agent using the service location protocol.
[0108]
8). When the user wants to use the device, the user makes an inquiry and search for the requested service using the PnP broker interface. The user agent at the PnP broker then contacts the directory agent or goes directly to the service agent (if both the service agent and user agent are in one PnP broker).
[0109]
9. If the newly discovered device matches the user's device description, the service agent or directory agent returns a unique URI along with the service parameters to the user agent.
[0110]
10. The user application determines that this is a non-TCP / IP device and accordingly, the service session management agent in the PnP broker establishes a session between the user application and the device. However, in this session, command / data transfer is performed by the inter-PnP broker protocol using the PnP broker as a gateway.
[0111]
11. The interface provided by the user application also includes information regarding the execution of functions within the device.
[0112]
12 The gateway informs the service agent of changes in the state of the service and updates it.
[0113]
In FIG. 6, an exemplary home network according to one embodiment of the present invention includes power line (X-10) cluster 613, telephone line (HomePNA / xDSL) clusters 602 and 606, CAT5 (Ethernet) cluster 616, USB cluster 610. , And well-known network components such as Jini device cluster 609. Residential gateway 605 is used to interconnect various networks including Ethernet, HomePNA, xDSL, and Jini. The Ethernet cluster includes the user's home PC 620. The home PC 620 is connected to various devices such as a digital camera 617 and a web panel 618 by the Ethernet protocol. The web panel 618 is a product of NEC Corporation, and is a device that has a touchpad and provides a user with a means to easily access the Internet. The Ethernet cluster 616 communicates with the residential gateway 605 through the Ethernet hub 619. The Ethernet hub 619 also provides a home network bridge to the Internet. The home PC 620 is connected to the speaker 611 and the network camera 612 using USB wiring, and to the incandescent light bulb 614 and the security manager 615 using X-10 wiring. Further, the home network has another home PC 603 and 607, a television 601, and a telephone 604. The xDSL cluster 606 including the home PC 607 is connected to the residential gateway 605 through the bridge 608. A PnP broker running on PC 620 allows the user to search for new devices / services within a web browser based interface. This embodiment uses Microsoft Internet Explorer as the user interface. ^TM Use a v5.0 web browser, but other suitable browsers can be used.
[0114]
The device / service appears in the browser with configurable properties when inserted into the corresponding network. The device specific gateway stores the device / service description. If the directory agent is in the network, the directory agent handles device / service function registration. After being authorized, the user can change device properties and connect devices. The PnP broker handles user authentication to the device and data / message conversion in case of incompatibility. For example, X-10 devices 614 and 615 are dummy devices that can interact with the rest of the devices in the framework by using a gateway device on PC 620. The PnP broker can also be implemented as an add-on to the HTTP server. The user can change the state of the power line devices 614 and 615 (light on / off). If the device (eg, camera 617) is TCP / IP based, the user can perform manual settings based on the interface provided by the camera and view the images taken by the camera. The user can query the video on demand server for a list of available movies. Normally, an analog TV 601 connected to the network (using an MPEG-2 decoder on the PC 603) can also connect to a video on demand server if it uses the same type of interface. However, since the TV 601 and the network camera 612 do not share an interface, the user cannot view the camera image directly on the TV. If a Jini device (eg, a printer) is connected to the network, this device operates with the non-Jini device as if the non-Jini device was a Jini device.
[0115]
[Solutions to Jini interface problems]
The shortcomings of the Jini interface model as one of the candidates to achieve network plug and play have already been described. The present invention overcomes the disadvantages of the Jini interface described above while borrowing the Jini security model. To solve the problem of Jini's interface, the following four approaches can be used. First, standards-based interoperability can be provided. According to this approach, all services have standard APIs, and services will implement those standard APIs. The second option is sandbox-based interoperability. In this case, if a Java virtual machine having an appropriate security model is given, the service can operate independently. The third option is reflection-based interoperability. In this case, the application asks the service about its interface and affects the state of this interface through a reflection mechanism. Finally, the fourth method is implementation-based interoperability. In this case, the same person or company will manufacture both the proxy and the service.
[0116]
Unlike Jini, instead of moving code to the client and executing it in the Java virtual environment, the present invention processes the address of the service and other parameters that describe the interface of the service and passes this interface information to the client. To provide.
[0117]
One of the main advantages provided by the framework of the present invention is the dynamic adaptation and reconfiguration of end-user applications in response to changes in available functions and user interaction modes. Some interface models are based on the fact that users can only interact with “conventional” software. In such systems, the user is limited in their ability to customize the application, so the application maximizes the capabilities of the device, ie, to the user demand predicted by the service designer or to the limits of the program interface provided. , Can not be used.
[0118]
In many cases, the degree of freedom is limited by the user interface. The application state and the initial setting of the application can be operated only through the user interface, but the user interface itself does not have much freedom of setting. This is prominent in monolithic programs, and it is extremely inconvenient to provide hooks in the application state or to make the application state accessible through a well-defined external protocol. In contrast, the client / server program provides a public interaction protocol, but has two major problems. Interface specifications are often ad hoc, and only the programmer can change the application's view of network functions (by modifying the client code).
[0119]
One approach to solving the above interface problem is to allow application programs to be downloaded on the fly to a client device or computer, for example as a Java applet. However, the problem with this approach is that the end user may not be able to customize the application for interaction with a heterogeneous set of services as an associated entity. That is, this approach cannot overcome small differences in the protocol even for functionally identical services because the application is not transparent. For example, a light switch control program based on the above interface model needs to download a different application in order to use it each time a new light switch is encountered. Thus, this approach exposes functionality but is not in an easy-to-operate form.
[0120]
Another approach is to avoid the above problems by standardizing the functional interfaces of various services and requiring the application to support these interface standards. The problem with this approach is that it is impractical to enforce a number of application specific standards.
[0121]
Obviously, a different model from any of the above is preferred, i.e. a balanced model of the requirement to expose an interface and the requirement to agree on a protocol standard. The first difficulty in solving this problem is to define a single document schema that describes the available functions (interfaces) of a service, and to move related programs and user interfaces into a set of services (and vice versa). It is to associate. A second difficulty is to provide software that can generate a user interface using a document written in the above schema and implement a runtime environment when a custom user interface is not available.
[0122]
One embodiment of the present invention utilizes a component based application framework with an architecture independent document model for component description. A detailed description of such a component-based application framework can be found in David Krieger and Richard Adler, “The emergence of distributed component platforms”, IEEE Computer Magazine, p. 43-53, March 1998. This framework, by combining the features of the two basic approaches described above, enables code fragment upload / download and imposes standards for the description and manipulation of non-application specific interfaces.
[0123]
[Active configuration model of the present invention]
In the active configuration model of the present invention, an XML (eXtensible Markup Language) description is associated with all network devices. XML is used because the XML description provides a static and immutable interface description as a publication of device capabilities (on the server side). Furthermore, by manipulating such an XML service interface description, the client can use services in the framework. The framework exposes a program and user interface to each service object to provide a standard location for operations.
[0124]
FIG. 7 shows an active configuration model of the present invention. In accordance with the present invention, every device or service 701 in the network specifies its functional interface definition 702. These interface definitions are communicated to the client by announcement 705. These interface definitions are static on the server side (similar to IDL in CORBA). These interfaces are shared among all entities in the network, but can be manipulated by any user application. User applications have full control over the use of service interfaces and the metadata presented by such interfaces. If there is a change 704 in the interface or its use state by the user application 703, it is reflected in the device or service by the reference (reference) 706.
[0125]
Thus, the present invention provides a programmable infrastructure for building arbitrary network services. In one embodiment of the present invention, end user applications are dynamically adapted and reconfigured in response to changes in available functions and interaction modes. This embodiment combines the idea of a Java applet that downloads code with the benefits of standardized interface description and manipulation. In the framework of the present invention, a user (or user application generated by a machine) simply changes the state of the network or device by editing the interface description provided by the service and reflecting the edit on the device. be able to. Furthermore, the device or service is accessible through a standardized API. Unlike conventional systems characterized by trying to standardize all APIs, the framework of the present invention allows various networking device vendors to map their product descriptions to the framework. Is possible. In this way, vendors can focus on syntactic definitions and device capabilities.
[0126]
In accordance with the present invention, device descriptions are stored using declarative style XML and used in addition to application code. The main function of the XML device description is to provide data and control flow information. By exposing this control / data separation, the present invention clearly incorporates metadata into the design so that storage and manipulation are independent of the application, so that the application is designed for future changes. can do.
[0127]
Separating program / user interfaces, such as those used in the framework of the present invention, from the objects they refer to is well known to those skilled in the art. ^TM This is similar to the Model / View / Controller (M / V / C) architecture. More details on the model / view / controller architecture can be found in G. Krasner and ST Pope, "A Cookbook for Using the Model View Controller User Interface Paradigm in Smalltalk-80", Journal of Object Oriented Programming, August / September 1988. Has been.
[0128]
In the M / V / C architecture, data (model) is separated from data display (view) and events (controller) that manipulate the data. Similarly, a document in the system of the present invention acts as a glue that associates the data with a user interface / program for manipulating and viewing the data.
[0129]
The present invention uses the XML syntax to create a device description schema as an XML document type definition (DTD). XML is a markup language for documents that contain structured information. This is a subset of SGML that provides self-describing custom markup in the form of hierarchical named values and advanced means for referencing other documents. Along with similar protocols such as XSL (Extensible Style Sheets) and XLink (Extensible Linking Language), XML provides the ability to specify, discover and combine groups of associated document schemas (Document Type Definitions: DTDs). . However, unlike HTML, the set of tags in XML is flexible, and tag semantics are defined by the DTD that accompanies the document. Other metadata markup languages such as Resource Description Format, Dublin Core and XML-Data have also been proposed.
[0130]
Within the framework of the present invention, a device or service creates its description schema as an XML document and accompanying DTD and stylesheet. This schema provides markup tags for language-independent service descriptions and for mapping user interfaces (programs) to service objects and vice versa. The schema also incorporates service interfaces within the XML / XSL definition so that the parser can retrieve these interfaces without having to download code to the user application. For example, an <ON> tag for a light switch can indicate the address and port number on which the device listens for method calls and other events.
[0131]
An XML parser is used by the client user application to generate a user interface from these service descriptions. The client maps lexical types to user interface widgets, parses XML / XSL, and then generates a user interface for the current configuration of the network. A user (or user application) can change the state of any network device by simply clicking on the dynamically generated UI widget corresponding to that device. This action changes the current UI state on the user's machine and sends the appropriate command (defined by the device vendor and embedded in the XML document) to the device for execution. In an embodiment of the present invention, for this purpose, Java ^TM A public domain XML parser written in Java and Internet Explorer ^TM An XML-enabled web browser such as 5.0 is used.
[0132]
Although the present invention has been described with reference to preferred embodiments thereof, it will be appreciated by those skilled in the art that various changes in form and detail may be made without departing from the scope and spirit of the invention. Is possible.
[Brief description of the drawings]
FIG. 1 is a diagram of the infrastructure of an active configuration framework.
FIG. 2 is an overall design diagram of an active configuration framework.
FIG. 3 is a diagram illustrating communication between two plug and play brokers.
FIG. 4 is a diagram showing an internal representation of a plug and play broker.
FIG. 5 is a diagram showing a service discovery procedure.
FIG. 6 is a diagram of an implementation example of an active configuration framework.
FIG. 7 is a diagram of an active configuration interface model.
[Explanation of symbols]
101 network
102 execution environment
103 User application
104 PnP broker
201 Gateway device
202 User application
203 Dummy device
204 Security enforcement mechanism
205 Network node
301 PnP broker
302 PnP broker interface
303 Protocol between PnP brokers
304 Service Discovery / Availability Agent
305 Service Registry
306 Service Session Management Agent
307 Service Location Protocol (SLP) service agent
308 SLP User Agent
404 PnP broker-to-broker protocol
406 Service Unit
501 PnP broker
502 User Agent (UA)
503 PnP broker
504 Service Agent (SA)
507 Discovery by broadcast
508 SLP directory
509 LDAP directory
510 conversion schema
511 Directory Agent (DA)
512 services
601 Television
602 HomePNA cluster
603 Home PC
604 telephone
605 Residential gateway
606 xDSL cluster
607 Home PC
608 bridge
609 Jini cluster
610 USB cluster
611 Speaker
612 Network camera
613 X-10 cluster
614 Incandescent light bulb
615 Security Manager
616 Ethernet cluster
617 Digital Camera
618 Web Panel
619 Ethernet Hub
620 Home PC
701 Device / Service
702 Interface definition
703 User application
704 change
705 Announcement
See 706
1104 Remote PnP broker

Claims (15)

In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service ;
The user application communicates with the service providing means through the plug and play broker independently of a communication protocol used by the service providing means for providing the service;
An active configuration framework characterized by The service providing means includes a gateway and a device cluster,
The gateway connects the device cluster to the plug and play broker;
The active configuration framework of claim 1, wherein the plug and play broker communicates with the device cluster through the gateway. In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service;
The service providing means includes a gateway and a device cluster,
The gateway connects the device cluster to the plug and play broker;
The plug and play broker communicates with the device cluster through the gateway;
The plug and play broker is connected to the gateway using a first communication protocol;
The gateway is connected to the device cluster using a different second communication protocol;
The gateway performs conversion between the first communication protocol and the second communication protocol ;
An active configuration framework characterized by In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service;
The service providing means includes a gateway and a device cluster,
The gateway connects the device cluster to the plug and play broker;
The plug and play broker communicates with the device cluster through the gateway;
The gateway registers the service in the plug and play broker by setting an attribute corresponding to the service in the plug and play broker ;
An active configuration framework characterized by The active configuration framework according to claim 2 , wherein the gateway periodically updates the status of the service in the plug-and-play broker in response to a request from the plug-and-play broker. The user application is a remote user application remote from the plug and play broker;
The active configuration framework of claim 1, wherein the remote user application communicates with the plug and play broker through an internet communication protocol. The active configuration framework further includes another plug and play broker,
The user application communicates with the other plug and play broker;
The active configuration of claim 1, wherein the other plug-and-play broker communicates with the plug-and-play broker to allow the at least one user application to use the service. Framework. In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service;
The active configuration framework further includes another plug and play broker,
The user application communicates with the other plug and play broker;
The other plug and play broker communicates with the plug and play broker to allow the at least one user application to use the service;
The active configuration framework further comprises a directory agent;
The plug and play broker registers the service with the directory agent using a service location protocol (SLP) ;
An active configuration framework characterized by The plug and play broker has a service registry;
The service registry includes information about the service and other network services;
The active configuration framework of claim 1, wherein the at least one user application uses the service registry to discover the service and the other network service. In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service;
The active configuration framework further includes another plug and play broker,
The other plug and play broker discovers the service by sending a query to the plug and play broker ;
An active configuration framework characterized by In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service;
The active configuration framework further includes other plug and play brokers and directory agents;
(A) the at least one user application sends a description of the requested service to the other plug and play broker;
(B) the other plug and play broker communicates with the directory agent;
(C) the directory agent returns to the other plug-and-play broker a service address that matches the description of the requested service;
(D) The other plug-and-play broker establishes a session between the user application and the service providing unit using the address .
An active configuration framework characterized by In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service;
The plug and play broker has a service registry;
The service registry includes information about the service and other network services;
The at least one user application uses the service registry to discover the service and the other network service;
(1) The service providing means includes a gateway and a device cluster,
(2) The gateway connects the device cluster to the plug and play broker,
(3) The plug and play broker communicates with the device cluster through the gateway;
(4) The gateway registers the service in the plug and play broker by setting an attribute corresponding to the service in the plug and play broker,
(5) The plug and play broker registers the service with the directory agent .
An active configuration framework characterized by In an active configuration framework in which at least one service providing means and at least one user application are connected to a network,
Providing a plug-and-play broker that identifies available services connected to the network and enables communication between a user application requesting the service and service providing means for providing the service;
The plug and play broker is
(A) a plug and play broker interface communicating with the user application;
(B) a plug-and-play broker-to-broker protocol for communication between the plug-and-play broker and other plug-and-play brokers in the framework;
(C) a service registry having at least one service record storing information about the service;
(D) a service discovery / availability agent that searches for the network address of the service and obtains the availability status of the service;
(E) a service session management agent that establishes a communication session between the service providing means and the user application;
(F) a service location protocol user agent searching for the address of the service;
(G) having a service location protocol service agent that publishes the service ;
An active configuration framework characterized by The at least one service record has a service identification field storing the type of service and a plurality of service attribute records;
The service attribute record has an attribute identification field that stores the type of the service attribute, an attribute value field that stores the value of the service attribute, and an access control field that stores access control information of the service .
The active configuration framework according to claim 13 . In a plug and play broker in an active configuration framework comprising at least one service providing means and at least one user application,
(A) a plug and play broker interface communicating with the user application;
(B) a plug-and-play broker-to-broker protocol for communication with other plug-and-play brokers in the framework;
(C) a service registry having at least one service record storing information about the service;
(D) a service discovery / availability agent that searches for the network address of the service and obtains the availability status of the service;
(E) a service session management agent that establishes a communication session between the service providing means and the user application;
(F) a service location protocol user agent searching for the address of the service;
(G) a service location protocol service agent that publishes the service;
A plug-and-play broker characterized by comprising:

Images