JP2004334896A - Framework having plug-and-play function and its reconstruction method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To integrate a plurality of networks having different communication protocols into a single integrated framework to enable a user application to find and use various network devices. <P>SOLUTION: An active configuration framework system has a plug-and-play (PnP) broker 104, and a service user uses the PnP broker to find and use a networking service and communicates with the networking service. A service agent registers services in a directory agent, a user agent transmits the description of a service required to the directory agent, and a directory agent checks the description of the service required with the description of a service to be offered, and returns an address of a suited service to the user agent. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a method and apparatus for integrating multiple networks with different communication protocols into a single unified framework to allow 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 features and user interaction. The invention also relates to a method by which applications, services and devices describe their capabilities and publish them to other applications, services and devices. In addition, the present invention allows physically distinct devices to connect, exchange information, negotiate data types, provide status for each operation, and achieve network plug and play. To provide a platform independent and transport independent protocol.

  With the advent of a global networking infrastructure, large-scale deployment of distributed services and applications has become commonplace. Current and future networks are expected to further deploy services that transmit time-sensitive information around the world and electronically mediate global transactions. Before such distributed services become universal, new mechanisms are needed to simplify the development, debugging, deployment and evolution of such services. Such a mechanism, regardless of the underlying protocol or interface, needs to find the required service and use the capabilities of that service.

  A typical distributed network system, such as one available at home, interconnects various different devices. It is almost impossible to interconnect all of these devices using a single, common communication protocol, since different home appliances (home devices) may inherently utilize different interfaces and protocols. It is. In some cases, it is convenient to use wiring that is already installed in most homes (e.g., to use existing power lines for communication with X-10 devices), but to use such existing wiring. The transmission speed of the network used is limited. For example, X-10 devices such as incandescent lamps and home security systems operate at data rates of a few 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.

  In contrast, various home automation applications currently being developed require effective interaction of various home appliances. Therefore, to enable effective interaction of all the different devices and services installed in the home, different networks should be integrated into a unifying framework and different networks located within different networks. Different network entities must provide a mechanism to discover and interact with each other.

  It is also desirable to provide a user application with a means to utilize remote services for various device interfaces and network protocols without requiring the application to handle low-level protocol-specific details.

  To achieve true plug-and-play capabilities, the framework must provide a mechanism to automatically discover the services offered by newly added devices. Within such a framework, descriptions of available network services and their network locations must be made readily available to all user applications. In addition, user applications must be able to automatically reconfigure their communication interface for communication with particular devices or services that may be encountered. In addition, the framework must include a security model that performs user authorization and authentication in order to control access to network services.

Jini ^™ is one of the existing candidates for achieving 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 building and deploying distributed systems. Jini provides "plumbing" to handle common but different parts of a distributed system. 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 network protocols and the APIs that implement them, facilitating the addition, discovery, access, and deletion of devices and services on the network.

  The use of Jini offers an easy way to discover services without knowing the underlying network technology. The improvement over Jini over other known infrastructures is that the user application can actually search for the service and let others discover the hosts that support the service. However, the main unsolved problem is "How user applications automatically use services on client machines". If the client user application only has a service interface, the client must have code that can understand this service.

For example, consider a situation where a user wants his application to browse a network for a camera service. If an application finds such a service on the network, the user can click on it and use it in his own application. If a user needs code to perform such a service, such code must be automatically downloaded on the user's machine. However, a major problem associated with this approach is how user applications utilize 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 not within the scope of the Jini ^™ specification and is left to the user application using the Jini ^™ service.

Another issue is the identification of the entity that defines the semantics of the camera service. For example, if major camera manufacturers, including Canon, Minolta, and Nikon, provide their own interfaces, camera services will not be interoperable and users will be able to code all three different camera services in code. Must be provided. Also, if Kodak decides to market the Jini ^™ camera, the user must manually modify the code to include an analysis of the Kodak interface. Such an extensible interface greatly increases network traffic and the size of the client code. It is preferred that all kinds of market-specific groups specify the interface collectively, and in many cases this will be necessary, but this is not likely to be immediate or efficient, especially For all types of devices used in the home, it is extremely impractical.

Another limitation that has not yet been resolved in known networks relates to how Jini ^™ based applications can access data residing on non-Jini ^™ based operating systems. That is, for example, how can a user access a Jini ^™ printer from MS-Word ^™ without Microsoft support for Jini ^™ . Even Java ^™ applications that want to use a Jini printer must rely on an operating system for access.

  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 ();
However, when this code is written, the programmer does not know whether 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.

Jini can be used such that a user interface (UI) component is added as an entry to a service's attribute list, so the client knowledge required for the service is minimal. The client simply needs to know that the UI is represented by attributes similar to applets. Since the UI can be provided as JavaBeans, the service can provide the client with a means by which the client can use the service by introspection and reflection. . This is essentially a message exchange between the client and server and requires manual configuration. However, adding UI components can prevent non-human clients (the machines that are created and used) from using the device. Another problem arises when the number of devices increases and the client program becomes complicated. In that case, the client must determine which objects in the returned list are true targets. In addition, every Jini ^™ device or application requires all the interfaces of all the devices (or at least “all types of devices”) needed to communicate during manufacturing. As a result, Jini ^™ does not actually solve the interoperability problem.

  HomeAPI, another existing networking system, is a set of object-oriented software services and application programming interfaces (APIs) that allow applications to discover and utilize various home devices. This system was designed so that the user application was not involved in the protocol-specific details of the devices and networks used by the application. The Home API provides a set of software objects that represent distributed services that facilitate developing user applications that utilize the services through the use of the Home API interface.

  However, the Home API does not provide the desired plug-and-play networking capabilities because it does not solve the problem of discovering new devices. Another disadvantage of the Home API is that it requires that all network devices provide a standard communication interface, which is not feasible in today's market.

  Other evolving network concepts, 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, at present there is no unified framework system that solves the interoperability issues of various competing network technologies and protocols and achieves network plug and play.

  Thus, there is a strong and widespread acceptance of a unified framework that interconnects various types of network devices and provides a uniform mechanism for device discovery and utilization, and such is the case. It is very advantageous. Such a unified framework allows the user application to communicate with the application-to-service communication protocol, discover the IP address of the host connected to the device providing the desired service, and even further details of the user interface of the network service. It eliminates the need to incorporate very low-level details and satisfies the other needs mentioned above.

  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. To provide a method and apparatus for allowing a user application to discover and utilize various network devices.

  Specifically, it is an object of the present invention to provide a method and apparatus for achieving dynamic adaptation and reconfiguration of network nodes in response to changes in available features and user interaction.

  Another object of the present invention is to provide a method by which applications, services and devices describe their capabilities and communication interfaces and publish them to other applications, services and devices.

  Yet another object of the present invention is to achieve network plug and play, where physically different devices connect, exchange information, negotiate data types and provide status about their operation. To provide a platform-independent and transport-independent protocol that enables

  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.

  In the framework of the present invention, the service user communicates with the service through a plug and play broker interface, independent of the communication protocol used by the device providing the service.

  Further, according to the present invention, there is provided a gateway for registering a service with a plug and play broker.

  Further, according to the present invention, there is provided an active configuration framework having a service agent, a user agent, and a directory agent. In the framework of the present invention, a service agent registers a service with a 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.

  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.

  The present invention also provides a method for automatically reconfiguring a 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. Thereafter, the user agent communicates the description of the requested service to the directory agent. Finally, the directory agent checks the description of the requested service against the description of the service to be provided and returns the address of the matching service to the user agent.

  Also, according to the present invention, there is provided a method for generating a communication interface for a service performed by a new network device added to a framework. According to the method of the present invention, a device generates a schema describing its communication interface. This schema can be in the form of an XML (extensible Markup Language) document. In that case, the user application generates a communication interface using an XML language parser.

  According to the present invention, a method for controlling a network device is provided. 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.

  By using the framework of the present invention, regardless of the number of different physical devices in the network, the complex mechanism for networking entity interaction only needs to be implemented once. Further, 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 is easy to deploy and use because it can be implemented as an add-on to a web server. Furthermore, in the framework of the present invention, the whole process of service discovery is transparent (transparent) to the user application and there is no distinction for physical connection (connection). For example, a plug and play device connected to a network need not be TCP / IP based. The service usage process is also transparent and is based on the capabilities of the various devices of interest and the authentication and authorization of the user. Connecting incompatible devices may require tunneling and full data conversion.

  The present invention provides an active configuration framework to facilitate device independent information exchange. Different protocols are required for multiple devices to connect, exchange information, negotiate data types, and provide status about their operation. These protocols are platform-independent and can be integrated into any device that needs to connect to other devices, regardless of format or function. Because these protocols are also transport independent, any device can connect to any other device and exchange information.

  In the framework of the present invention, as in the case of an active network, user-defined computations are located in the network. However, unlike active networks, all routing and forwarding semantics of the current Internet architecture are preserved by restricting the computing environment to the application layer. Network devices and services utilizing this framework, even when deeply embedded in the network infrastructure, are actually created, configured, and dynamically controlled by user applications on end systems. Such an application-defined entity runs at any node in the network, and individual packets can be programmed to propagate through the network and perform any actions.

  Achieving network plug and play across all types of distributed devices and services requires a unified framework. As used herein, the term “framework” or “substrate” refers to a system that integrates one or more networks. However, in many cases, the terms "framework", "substrate", and "network" are used interchangeably.

[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 environments 102 are interconnected using a network 101 such as the Internet, for example. The execution environment 102 acts in some sense as a network node. The execution environment 102 can be in a Java virtual machine or a Windows ^™ based machine known to those skilled in the art. 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, various components of the active configuration framework system of the present invention will be described in detail.

[Dummy device]
A dummy device is a device without the TCP / IP protocol stack, the 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 light bulb) must be manually assigned a house code and device code before connecting to a power line network. Further, such devices do not enforce security or access control for the services offered. Most such devices have no memory or processing power and can be characterized as legacy devices that still need to connect to the rest of the network.

[Gateway Device]
Typical network devices can interact in a peer-to-peer fashion 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. A first device connecting to a second device on a network not supported by the first device or a second device running a protocol not supported by the first device; A problem arises when the need is made. There are two approaches to solving this problem.

  The first approach is to load multiple communication stacks on a single network device. This allows the device to interact with any type of network device as long as it has the appropriate communication stack. Although the underlying transport is different, this approach works if the device understands the entire protocol stack.

  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 is invisible within a network and converts one network type to another. 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 a device with the ability to interact with a legacy network, this functionality is located at the gateway. Gateways are typically hosted on a programmable platform.

  In the framework of the present invention, when a PnP broker wants to establish a session with a legacy (dummy) device that requests a gateway for access, the gateway hides the presence of the device from the PnP broker. The PnP broker instead 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 over any channel in the session, it relays the data to the remote device over the gateway-dummy link. The present invention uses two types of gateways: The generalized gateway communicates with IP devices, and the specialized gateway communicates with non-IP devices through dummies. The specialized gateway exposes the dummy device to the network and includes programming logic for controlling and managing the device. Further, the specialized gateway implements the security policy of the dummy device. One gateway device can manage a plurality of dummy devices.

[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, treating 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, 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.

  PnP brokers allow networked entities to discover and utilize the capabilities of other networked entities (gateways or dummies). 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. There is a specific gateway for each type of device (eg, X-10X, 1394X, USB) in the network, one end of which is connected to this device cluster and the other end of which is connected to a PnP broker. 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 may represent a Jini cluster, while another may 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 its architecture.

  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 security enforcement mechanism 204 to control access to gateways and services.

  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. A service unit can be the entire user application / service or a 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.

  The PnP broker allows networked entities to discover and utilize the capabilities of other networked entities. The network connection entity can be a service user (user application). The user application discovers the service and requests to use it through the PnP broker. 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 run on the TCP / IP protocol stack. A PnP broker communicates with other PnP brokers in different clusters to play its role as a service broker or manager. A protocol between PnP brokers is called an inter-PnP broker protocol.

  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 (a 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. The HTTP protocol is also well known to those skilled in the art. A description can be found in "Paul S. Hethmon," Illustrated Guide to HTTP ", Manning Publications, 1997. The service unit can use a PnP broker directly connected to it, or 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 an inter-PnP broker protocol 404. Thus, a service unit can query and use services available in service units located in different device clusters.

[PnP broker function component]
FIG. 4 shows the internal components of the PnP broker. Typically, a PnP broker consists of 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 PnP broker protocol 303 is used for communication with another PnP broker 301. The PnP broker interface 302 provides an interface for 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. Have been. The service registry contains 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 is described in Natanaya Pitts-Moultis and Cheryl Kirk, "XML black book", Coriolis Group Books, 1999.

[Service Registry]
PnP brokers include a service registry to hold information about services. At a minimum, the registry stores information about gateways and services that are directly connected to the PnP broker. As shown in FIG. 3, these services are on the local PnP broker 104 or the remote PnP broker 1104. Further, the PnP broker registry can store information about services registered with other PnP brokers. This extended registry function allows a local PnP broker to maintain a local directory of services. This is important for the local environment 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. Ultimately, 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 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 the PnP broker, which will respond to each.

Service record
A service record is a set of available service units in a networked cluster, describing available services and services requested by other PnP brokers. A service record consists of zero or more service unit records in the local cluster. The service unit record is composed of 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 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-grained 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.

[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 Java RMI or HTTP described above 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. By examining the specification of the requested service type, the PnP broker can determine the characteristics of all or specific services registered with the remote PnP broker. The service discovery / availability agent sits on top of the SLP user agent and the SLP service agent.

  In addition, the PnP broker can periodically check for service availability 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 period of the availability check and cancel the check.

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. Using such a tunnel, commands, responses and data can be exchanged between user applications and services. According to the organization of the interface of the device, these commands, responses and data have a specific format and are exchanged under a defined protocol. The PnP broker can be instructed to operate on one of the following three protocols while managing this virtual pipe.

[Native data transfer in native packet]
After setting up the data pipe, the PnP broker enters the background to allow user applications and services to manage message streams and data formats. This approach is used by PnP brokers alone to discover the capabilities of other network entities and is useful when applications, services, and devices manage the interaction between user applications and discovered services. is there. Messages are exchanged directly between user applications and services without the involvement of a PnP broker. Message exchange is strictly a form of native data in native packets. To discover a service before making a service request or to query a service, a user application can use the PnP inter-broker protocol. For example, an IEEE 1394 compliant camera can use this data exchange format to send a data stream to a digital VCR.

[Native data transfer (tunneling) in PnP broker packet]
While the data format is selected and controlled by user applications and services, it is also possible for a PnP broker to set up data pipes and manage message streams. This approach is useful when there is no common messaging protocol between the user application and the discovered service. All messages are carried by the PnP inter-broker protocol. For example, an IEEE 1394 compliant camera sends a data stream through a PnP broker to digital VCRs in different clusters.

[PnP broker data in PnP broker packet (fully functional gateway)]
A PnP broker configures data pipes, manages message streams, and provides data format definitions for user application and service interaction. The broker also provides a common messaging protocol and a common data format between the user application and the discovered service. The message exchange information is included in the PnP broker data, which is formatted into packets. User application messages pass through the PnP broker, but the PnP broker does not check the content or semantics of the message. An example of this type of interaction is an IEEE 1394 enabled device interacting with a USB device.

[SLP User Agent]
A user agent is a process that runs 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.

[SLP Service Agent]
A service agent is a process that acts on behalf of one or more services to advertise services.

[Protocol and Interaction]
PnP brokers expose a standardized interface that allows user applications to take advantage of the plug and play capabilities of the network. Using this PnP broker interface, applications can be written to communicate with each other using a PnP inter-broker protocol independent of the transport layer. This design promotes portability and provides a scalable framework for network service discovery and selection. The PnP inter-broker protocol is based on the IETF Service Location Protocol v.2 and does not require the user application to know the name of the network host supporting the service. Rather, the user provides the desired service type and a corresponding set of attributes to the PnP broker through the PnP broker interface. These describe the desired services to the PnP broker. Based on this description, the PnP broker resolves the network address of the service using a PnP broker protocol, and the PnP broker protocol uses a service location protocol. The PnP broker interface also handles user identification and authentication mechanisms for devices or services. Once a service has been identified, the PnP inter-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 enables the PnP broker to use services at the PnP broker through service agents.

  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.

  A protocol between the PnP broker and the gateway.

  A protocol between the gateway and the dummy.

[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.

[Service Registration]
When needed, 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.

[Service Discovery]
The user application calls SearchService () to request the local PnP broker to search for a PnP broker that includes 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.

[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. TransferData (), ReceiveData (), and CloseService () calls provide additional functionality.

[Availability Check]
The user application or service unit calls StartAvailabilityCheck () to periodically check with the local PnP broker whether a specific service unit registered with either the local PnP broker or the remote PnP broker is operating. Request to do so.

User identification and authentication
In a preferred embodiment, the present invention utilizes a Java application environment. This is because it provides a suitable, currently available computing platform for distributed computing. In this environment, both code and data are portable 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 a class of an object on a virtual machine can be performed even when the object does not originate on that machine. As a result, the network supports the fluid configuration of movable objects as needed, and can invoke any part of the network to perform operations.

  Unauthenticated access to home devices can have serious consequences for the security of the entire framework. Controlled access to resources is the basis for security and security. Thus, one embodiment of the present invention uses a Java virtual machine and a Java programming environment to ensure the security of one device. Although systems can be designed to address faulty devices, network security is a more complex issue than device security.

  Another embodiment of the present 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 for generating a code checksum, and is used for access control. However, larger networks require more flexible distribution mechanisms for specifying security policies and naming code.

  The security model of the present invention is built on two concepts, principal and access control list. Services are accessed on behalf of an entity (principal). Principals generally come from a particular 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.

[PnP Broker Communication Protocol]
The PnP inter-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 a user application searches for 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 service it needs, with or without a centralized registry.

  Once a service has been discovered, other steps may be required to utilize the service. In an embodiment of the present invention, the user application negotiates access to the service, including quality of service and security requirements. Further, after successful negotiation of access to the service, the user application actually uses the service using the Java RMI, HOP, or HTTP protocol.

[Service Discovery / Registration Process]
The Service Location Protocol (SLP) is used for both lookup and discovery. FIG. 5 shows a service discovery procedure. The SLP automatically and without any pre-configuration checks the request of a user agent (UA) 502 against a service 512 provided by a service agent (SA) 504. The SLP handles the publication of services by the SA and the organization of services into an SLP directory 508 managed by a Directory Agent (DA) 511. The SLP also provides a means for the service to notify the user application of the capability and setting conditions of the service.

  The UA 502 in the PnP broker 501 understands service and resource requests by the user application 103. The SA 504 in the PnP broker 503 (which may be the same PnP broker or a different PnP broker) represents a network service and performs a service available to the UA 502. Since the SLP dynamically holds service attributes, the UA 502 can acquire current information. The service can be automatically searched for by the application, or it can be presented to the user with a service browser. SLP supports existing applications and facilitates the publication and discovery of new services.

  According to the invention, a service is described by a gateway. The gateway sets the value of the attribute (corresponding to the service) in the SA. For example, the printer may be described as a PostScript printer, a printer with blue paper available, or a printer on the same floor of the user's office. The UA 502 selects an appropriate printer by designating 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 may be possible to have no DA, in which case the request message would be sent directly to the SA. This is called discovery by broadcast (507).

  The service announces itself by registering with DA511. The service registration includes a list of all keywords describing the service and attribute value pairs (pairs of attributes and values). Registration also includes leasing to resources. Thus, after the lease expires, the service information is deleted by the DA 511. A leasing mechanism is implemented to avoid situations where service hardware is no longer available while services are being published forever. Explicit deregistration can also delete service information from DA as part of the SA's regular shutdown procedure. Further, the SA periodically registers the current attribute information, so that the UA can check the status, load, temperature, or other dynamic characteristics related to the service.

  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 SA 504 makes available to describe the service. The service browser first finds a service type available to the UA 502 and then determines all characteristics of all services available to the UA 502 by querying all information published by the SA for that service type. can do.

[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, which then sends an SrvReg message 506 to the DA 511. The registration includes a service URI for a particular instance of the service and an attribute value pair that describes the service. DA 511 can cache such registrations for various purposes. After the registration is cached, DA 511 responds with a SrvAck message. The service registration also includes a lifetime. The lifetime value allows DA 511 to expire a cached registration if the service becomes unavailable but could not unregister itself. This situation should only occur if SA 504 cannot issue SrvDereg message 506. During normal operation, the SA 504 periodically refreshes service registration with subsequent SrvReg messages. Such a "refresh" message may include updated information if any value changes, but need not include the complete set of attributes.

  The UA 502 of the PnP broker 501 makes a request to the DA 511 when a service is requested. There are several ways that the UA 502 can discover the DA 511. 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 a DHCP (Dynamic Host Configuration Protocol) 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 be operable without manual configuration. For this reason, UA 502 can use SrvReq to find DA 511. The 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, it may receive multiple unicast responses. The resulting DA resource is available for other service requests.

  Once the UA 502 obtains the address of the DA 511, subsequent service requests can be made directly to that entity. Taking a printer as an example, if the UA 502 seeks a printer service, an SrvReq is created. This message contains the service type "printer" and an optional list of attributes and values. The attribute value pairs describe the type of printer required. This message is unicast to DA 511, which is preset or discovered via multicast. DA 511 receives the SrvReq and performs a lookup on the cached registration to attempt to find a match for the requested attribute and value. The SrvRply is then unicast to the requesting UA 502. This response contains zero or more service URIs, depending on the match result. Thereafter, the user application finds the printer using the service URI.

  If there is no DA 511 in the facility, the PnP broker is restricted to finding SA 504, also in the raster. This may be acceptable in many small facilities, but for scalable applications of PnP brokers, and in large facilities with multiple clusters, DA511 must be used. Further, because the SLP DA 511 can be a gateway to an LDAP-based directory 509, the PnP broker interface uses the conversion schema 510 to provide a single API for all protocols.

  When the UA 502 wants to obtain a service handle, it sends a service type and a character string-based query for the requested attribute as a service request. When the service response is returned, it contains a URI pointing to the service. The URI includes the IP address of SA 504, or a name that DNS can resolve to an IP address. The URI also includes other information required 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. URIs are used to find services in a natural way, similar to conventional standards for representing resource locations. Further, character set issues can be addressed in a standard way.

[Interaction of PnP broker with user agent and service agent]
By using SLP, the PnP broker can make an accurate selection of the appropriate service from many other published devices of the same type. This is done by requesting only those services that match the keywords and requested attribute values requested by UA 502. Such keywords and attribute values can be combined into Boolean expressions by AND, OR operators, general comparison operators, and by using substring matching.

  The PnP broker makes the provision of configuration information transparent to the user and facilitates the work of setting a new service. All of these require a system administrator. After SA 504 is configured to advertise services to neighboring DAs 511, UA 502 can dynamically adapt to the changing conditions on the network as various services start and stop operation. For example, a web application can find a suitable printer as long as it is available, independent of the system that happens to be running at the moment.

  When the gateway wants to add a new device or service to SA 504, it supplies the available attributes and keywords for that service. The SA 504 can programmatically register with the SLP and assign values for attributes based on the unique configuration information of the service. The SLP then processes the registration (publication) and allows the establishment of a connection between the user application and the service.

  New service types can be defined as needed. It is also possible to deploy an experimental service type for limited use and then make it publicly available. This is performed using the naming authority function of the SLP. By default, most common service types use service template (scheme) definitions standardized by the Internet Assigned Numbering Authority (IANA). Defining an alternative service type is as easy as setting up a directory agent to use a scheme definition known to any alternative naming authority (typically a name known to the local administrator). It is. For example, to provide a security service at home, a service type of "service: secure: Door" can be defined. Of course, a user application utilizing this type of service handle must use the service's network protocol in order to communicate with the "secure" service, and furthermore the information contained in the URI of this particular service type Must be able to parse. This is inherent in the natural operation of any user application / server protocol.

[Using 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 its name Lightweight, but SLP is even more "lightweight" than LDAP. Also, SLP is superior to LDAP in resource management because it provides automatic directory management and does not require improper 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 are available in SLP, but not in LDAP.

  SLP enables discovery without pre-configuration. In contrast, LDAP first requires knowledge of the directory address and the directory scheme used by LDAP. SLP can evolve because non-standard attributes and new versions of standardized service type templates are possible.

  Embodiments of the present invention use SLPs to simplify the management of LDAP directories and enable SLPs to return information obtained from LDAP directories as needed. In another embodiment, the SLP is dynamically used to populate LDAP with a service entry, the SLP query is mapped to an LDAP query, and the LDAP is the back end of the SLP. One advantage of such a configuration is that the user application gets the user credentials directly from the LDAP directory.

[Service Usage Process]
The service discovery / registration process provides a service record that can be searched by the URI provided by the service location protocol. Exchange capabilities between PnP brokers are 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 the details of the service from the remote PnP broker.

  Upon receiving the QueryService () message, the receiving side PnP broker compares the received service record with its own service record. Thereafter, the receiving PnP broker returns a service record including the matching service record to the requesting PnP broker. This approach provides a technique for a user application to search among all service units, a particular type of service unit, or a service unit with a particular set of capabilities. After receiving the service record, the user application can initiate communication with the PnP broker to use the service or device.

  The local PnP broker requests the 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.

  The remote PnP broker responds with a result code specifying whether the requested service is accepted or rejected. The remote PnP broker may also include a redirection or retry after some time. If the service is accepted, the remote PnP broker sends a service handle identifying 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" (end of 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 within the framework. Can be. Availability checks can be performed on an entire device or on specific services provided within the device.

[PnP broker / gateway protocol]
The PnP broker / gateway protocol is based on a simple message exchange mechanism. The gateway registers the services to be provided on behalf of the service units directly connected to the gateway, as already described. The gateway also reflects changes made in the configuration of any service to the service agent at 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 if any of the directly connected gateways provide the required devices or services. The gateway also allows the service agent to register interest in a particular event within the gateway and receive notification of the occurrence of that event. Such an event may 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.

[Event notification mechanism]
In the framework of the present invention, the user application can register the event notification request with the server, so that the server is able to register the user application when a new device comes online or when the attribute of the device changes. Will be notified. To achieve this, the present invention provides a mechanism for delivering event notifications to registered users.

  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.

  However, the above event notification service is difficult to actually use in a lightweight notification service because it is designed to operate on a specific architecture and imposes a large code base.

  In addition to the capabilities provided for registering for notification of some types of events, the user can associate attributes with the notification request. Preferably, such notifications should be delivered with high reliability and ensure perfectly regular end-to-end delivery. However, when notifications are delivered over an unreliable transport, no acknowledgment or retry is required. The user application may also require that the demand side of the event provide an explicit confirmation of receipt to the supplier. For authentication, the user can digitally certify the notification to ensure the correctness and integrity of the notification.

  The framework of the present invention achieves event notification in two ways by using SLP. According to the first embodiment, the service agent sends 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 prohibited with SLP usage, but can cause flooding. Furthermore, this approach does not work efficiently for a large number of services, different languages, and digital signatures. The SrvReg includes a URI and an attribute of each service added / deleted / changed in the network.

  In another embodiment of the present 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 SAAdverts, the user agent unicasts the appropriate service request to the sending service agent. Announcements from service agents are made in an exponential back-off manner.

[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. The gateway / dummy protocol is unique, but exposes a standardized interface to the PnP broker.

[Example]
According to one embodiment of the present invention, the network has one or more PnP brokers. A PnP broker acts as an interface between a user and some services. In one embodiment, the PnP broker for the X-10 device provides some 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 particular service through the X-10 gateway. The following steps are required according to this embodiment for the user application to use the newly registered service in the network.

  1. An incandescent light bulb is inserted into the home power outlet.

  2. Since the incandescent lamp is a dummy device, it is connected to the power line network through the X-10 device.

  3. In the home network, the PnP broker and the X-10 gateway are already operational before the introduction of a new device.

  4. The X-10 gateway periodically polls for available addresses and checks if any devices have become active.

  5. The gateway recognizes that a new device has entered the network and registers both the device and the services provided by the device with the service agent of the PnP broker.

  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.

  7. The service agent registers a service provided by the device with the directory agent using a service location protocol.

  8. When the user wants to use the device, he queries and searches 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 the user agent are within one PnP broker).

  9. If the newly discovered device matches the user's device description, the service agent or directory agent returns a unique URI to the user agent along with the service parameters.

  10. The user application determines that this is a non-TCP / IP device, and the service session management agent in the PnP broker establishes a session between the user application and the device accordingly. However, in this session, the command / data transfer is performed by a PnP inter-broker protocol using the PnP broker as a gateway.

  11. The interface provided by the user application also includes information regarding the execution of a function in the device.

  12. The gateway informs the service agent of the state change in the service and updates it.

In FIG. 6, an exemplary home network according to an embodiment of the present invention includes a power line (X-10) cluster 613, telephone line (HomePNA / xDSL) clusters 602 and 606, and CAT5 (Ethernet, the same hereafter). )) A well-known network component such as a cluster 616, a USB cluster 610, and a 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. Home PC 620 is connected to various devices such as digital camera 617 and web panel 618 by Ethernet protocol. The web panel 618 is a product of NEC Corporation and has a touchpad and is a device that provides a user with a means for easily accessing the Internet. Ethernet cluster 616 communicates with residential gateway 605 through Ethernet hub 619. An 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 lamp 614 and the security manager 615 using X-10 wiring. Further, the home network has another home PCs 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 users to search for new devices / services within a web browser based interface. This embodiment uses the Microsoft Internet Explorer ^™ v5.0 web browser as the user interface, but other suitable browsers can be used.

  Devices / services appear 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 registration of device / service functions. After the right is given, the user can change device properties and interconnect devices. The PnP broker handles the authentication of the user to the device and the conversion of data / message in case of incompatibility. For example, X-10 devices 614 and 615 are dummy devices that can interact with the remaining devices in the framework by using a gateway device on PC 620. A PnP broker can also be implemented as an add-on to an HTTP server. The user can change the state of the power line devices 614 and 615 (turn on / off the light). 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. Typically, an analog TV 601 connected to a network (using an MPEG-2 decoder on PC 603) can also connect to a video-on-demand server if using the same type of interface. However, since the TV 601 and the network camera 612 do not share an interface, the user cannot directly view the camera image on the TV. When a Jini device (eg, a printer) is connected to the network, it operates with the non-Jini device as if it were a Jini device.

[Solution for Jini interface problem]
The shortcomings of the Jini interface model as one of the candidates for achieving network plug and play have already been described. The present invention overcomes the above shortcomings of the Jini interface 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 provided, the service can operate independently. The third option is reflection-based interoperability. In this case, the application queries the service about its interface and, through a reflection mechanism, affects the state of this interface. Finally, a fourth method is implementation-based interoperability. In this case, the same person or company will manufacture both the proxy and the service.

  Instead of moving code to the client and executing it within the Java virtual environment, unlike Jini, the present invention processes the address of the service and other parameters that describe the interface of the service, and stores this interface information in the client. To provide.

  One of the major 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 features and user interaction modes. Some interface models are based on the ability of a user to interact only with "traditional" software. In such a system, the user is limited in the ability to customize the application, so the application maximizes the capabilities of the device, i.e., up to the user's demands predicted by the service designer or the limitations of the program interface provided. , Can not be used.

  In many cases, the degree of freedom is limited by the user interface. Although the state of the application and the initial setting of the application can be operated only through the user interface, the user interface itself has little flexibility in setting. This is noticeable in monolithic programs, where it is extremely inconvenient to hook up the state of the application or make it accessible through a well-defined external protocol. In contrast, client / server programs provide a public interaction protocol, but have two major drawbacks. Interface specifications are often ad hoc, and only the programmer can change the application's view of networking features (by modifying client code).

  One approach to solving the above interface problems is to have the application program downloaded on the fly to a client device or computer, for example, as a Java applet. However, a problem with this approach is that the end user cannot customize the application as a related entity to interact with a heterogeneous set of services. That is, this approach cannot overcome small differences in protocols, even for functionally identical services, because applications are not transparent. For example, a light switch control program based on the above interface model will need to download a different application to use it each time a new light switch is encountered. Thus, this approach exposes functionality but is not an easy-to-operate format.

  Another approach is to avoid the above problems by standardizing the functional interfaces of various services and requiring that applications support these interface standards. The problem with this approach is that it is impractical to enforce a number of application-specific standards.

  Obviously, a model different from any of the above is preferred, ie a model that balances the requirements of exposing interfaces with the requirements of agreeing on protocol standards. The first difficulty in solving this problem is to define a single document schema that describes the available functions (interfaces) of the service and to convert related programs and user interfaces into a collection 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.

  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 combines the features of the two basic approaches described above, allowing for the upload / download of code fragments and imposing standards for the description and manipulation of non-application specific interfaces.

[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 it provides a static and immutable interface description as an announcement of device capabilities (on the server side). Further, by manipulating such an XML service interface description, clients can use services within the framework. The framework exposes programs and user interfaces to each service object to provide a standard location for operations.

  FIG. 7 shows an active configuration model of the present invention. According to 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 between all entities in the network, but can be operated 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 state of the interface or its use by the user application 703, it is reflected on the device or service by the reference (reference) 706.

  Thus, the present invention provides a programmable infrastructure for building any network service. In one embodiment of the invention, end-user applications are dynamically adapted and reconfigured in response to changes in available features and interaction modes. This embodiment combines the advantages of the Java applet concept of downloading code with the description and operation of a standardized interface. In the framework of the present invention, a user (or a user application generated by a machine) changes the state of a network or device simply by editing the interface description provided by the service and reflecting the edit on the device. be able to. Furthermore, devices or services are accessible through standardized APIs. Unlike conventional systems, which are characterized by attempting to standardize all APIs, the framework of the present invention allows various networking device vendors to map their product descriptions into the framework. It is possible. In this way, vendors can focus on syntactic definitions and device capabilities.

  According to the present invention, the device description is stored using declarative style XML and used in addition to the 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 explicitly 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.

Separating program / user interfaces from the objects they reference, such as those used in the framework of the present invention, is well known to Smalltalk ^™ models / views / controllers (M / V / C). Similar in architecture. Further 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. Have been.

  In the M / V / C architecture, the data (model) is separated from the display (view) of the data and the events (controller) that operate on 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.

  The present invention utilizes an 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. It is a subset of SGML and provides self-describing custom markup in the form of hierarchically 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 accompanying document schemas (document type definitions: DTDs). . However, unlike HTML, the set of tags in XML is flexible, and the semantics of the tags 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.

  Within the framework of the present invention, a device or service creates its own description schema as an XML document and its 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. Also, the schema embeds the service's interfaces within the XML / XSL definition so that the parser can read these interfaces without having to download the code to the user application. For example, an <ON> tag for a light switch may indicate the address and port number at which the device listens for method calls and other events.

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 the XML / XSL, and generates a user interface for the current configuration of the network. The 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, a public domain XML parser written in Java ^™ and an XML-enabled web browser such as Internet Explorer ^™ 5.0 are used for this purpose.

  While the present invention has been described with reference to preferred embodiments, it will be readily apparent to 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.

FIG. 2 is a diagram of an active configuration framework infrastructure. 1 is an overall design diagram of an active configuration framework. FIG. 4 is a diagram illustrating communication between two plug and play brokers. FIG. 3 is a diagram showing an internal representation of a plug and play broker. It is a figure which shows a service discovery (discovery) procedure. It is a figure of an example of implementation of an active configuration framework. It is a figure of an active configuration interface model.

Explanation of reference numerals

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 PnP Broker Protocol 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 Inter-PnP 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 Service 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 706 Reference 1104 Remote PnP Broker

Claims (17)

(A) at least one service;
(B) a service agent;
(C) In an active configuration framework having a directory agent,
The service agent registers the type and attributes of the at least one service with the directory agent;
An active configuration frame, wherein the directory agent returns an address of the at least one service by matching a type and an attribute of a service requested by a user application with a type and an attribute of the at least one service. work. The active configuration framework further includes a user agent,
The user agent sends the type and attributes of the requested service to the directory agent;
The active configuration framework of claim 1, wherein the directory agent returns an address of the at least one service to the user agent. The at least one service has a gateway and a device cluster;
The gateway connects the device cluster to the service agent;
The active configuration framework of claim 1, wherein the service agent communicates with the device cluster through the gateway. The active configuration framework further includes an execution environment,
The active configuration framework according to claim 1, wherein the application operates in the execution environment.   The active configuration framework according to claim 4, wherein the execution environment is a Java virtual machine. The active configuration framework according to claim 4, wherein the execution environment is a Windows ^™ based machine. In a method for automatically reconfiguring a framework in response to the addition of a network device,
The network device provides at least one service;
The framework has a service agent and a directory agent,
The method comprises:
(A) the service agent registers the type and attributes of the service to be provided with the directory agent;
(B) the directory agent matching the type and attributes required by a user application with the type and attributes of the provided service and returning an address of the provided service;
A method for performing automatic reconfiguration of a framework in response to addition of a network device. The framework further comprises a user agent;
The user agent sends the type and attributes of the requested service to the directory agent;
The method of claim 7, wherein the directory agent returns an address of the provided service to the user agent. The step (a) includes:
(1) the gateway checks the availability of the network device;
(2) the gateway registering the type and attributes of the provided service with the service agent;
(3) the service agent registers the type and attribute of the provided service with the directory agent;
The method of claim 7, comprising:   The method of claim 7, further comprising: (c) a session management agent using the address to establish a communication session between the user application and the network device. A method for generating a communication interface for a service performed by a device inserted into a framework, comprising:
The interface is used by a user application to use the service,
The method comprises:
(A) generating a service description schema for a service provided by the device, the service description schema including at least one of an XML document, a document type definition, or a style sheet;
(B) generating a communication interface for the service from the service description schema using an XML parser;
A method for generating a communication interface for a service performed by a device inserted into a framework, comprising: The method of claim 11, wherein the service description schema includes data and control flow specifications for the service. In the step (b), the service description schema generated by the device is mapped to a set of user interface widgets,
The method of claim 11, wherein a user can change the state of the device by clicking on a user interface widget that sends a command to the device for execution. In the step (b), a service description schema generated by the device is mapped to a hierarchy of objects representing a communication interface for the service;
The method of claim 11, wherein the service is used by the user application using a hierarchy of the objects.   The method of claim 14, wherein the hierarchical structure of the object is determined based on a function of the device when the user application uses the device. The method of claim 15, wherein the XML parser is an XML-enabled web browser. In a method for controlling a device inserted into a framework, the method comprises:
(A) generating a device description schema for the device, the device including at least one of an XML document, a document type definition, or a style sheet;
(B) the user application editing the device description schema, and reflecting the edited device description schema on the device;
The method of controlling a device inserted in a framework, wherein the device changes a state according to the edited device description schema.

Images