JP2001290724A - Framework having plug-and-play function and its reconstructing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable a user application to find and utilize various network devices by integrating a plurality of networks having different communication protocols into a single unified framework. SOLUTION: This active configuration framework system interconnects a service and a service user. The framework has a plug-and-play(PnP) broker 104. The service user finds a networking service by using the PnP broker, utilizes the networking service and communicates with the networking service. The service user communicates with the service through the interface of the PnP broker independently of a communication protocol used by a device offering the service. A gateway 201 for registering the service in the PnP broker is also provided.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION The present invention integrates multiple networks with different communication protocols into a single unified framework, allowing user applications to discover and utilize various network devices. Method and apparatus. 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 a method by which applications, services and devices describe their capabilities and publish them to other applications, services and devices. Further, the present invention enables physically different devices to connect, exchange information, negotiate data types, provide status about each operation, and achieve network plug and play. To provide a platform independent and transport independent protocol.

[0002]

BACKGROUND OF THE INVENTION 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, the development, debugging,
New mechanisms are needed to simplify deployment and development. Such mechanisms need to discover the required services and use the capabilities of those services, regardless of the underlying protocol or interface.

[0003] Typical distributed network systems, such as those available at home, interconnect a variety of different devices. It is almost impossible to interconnect all of these devices using a single, common communication protocol, as 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., using existing power lines for communication with X-10 devices), but such existing wiring can be used. The transmission speed of the network used is limited. For example, X-10 such as incandescent lamps and home security systems
Devices 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.

[0004] 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 located 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.

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

[0006] To achieve true plug and play capabilities, the framework must provide a mechanism to automatically discover 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.

[0007] Jini ^™ is one of the existing candidates for achieving network plug and play (Ji
ni is Sun Microsystems, Inc.
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. A that supports leases, distributed events, and distributed transactions
By defining PIs and conventions, the programming model helps developers build reliable distributed systems, even when the underlying network is unreliable. The runtime infrastructure consists of a network protocol and the API that implements it.
Facilitate access and deletion.

[0008] The use of Jini provides 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 camera services. If the application finds such a service on the network,
You can click on it and use it in your 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 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 not within the scope of the Jini ^TM specification,
It is entrusted to the user application that uses the ni ^™ service.

[0010] Another issue is the identification of the entities that define 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 kinds of devices used in the home, it is very impractical.

[0011] 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, without Microsoft support for Jini ^™ , a user can see how MS-Word ^™ to Ji ^™
Will it be able to access the ni ^TM printer.
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. Additionally, if a programmer wants to print an image on multiple devices, expect multiple interfaces,
It is necessary to print accordingly.

Jini has a user interface (U
I) The client knowledge required for the service is minimal because the component can be used to be added as an entry to the service's attribute list. 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 a UI component 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.

[0015] Another existing networking system, the Home API, is an object-oriented software service and application programming interface (AP) that allows applications to discover and utilize various home devices.
This is a set of I). 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, HomeAPI does not provide the desired plug-and-play networking capabilities because it does not solve the problem of discovering new devices. Ho
Another disadvantage of meAPI is that it requires that all network devices provide a standard communication interface, which is not feasible in today's market.

HomePNA, HomeRF, Blue
tooth, PIANO, X-10, CEBus, IE
Other evolving network concepts, such as EE1394, 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 problems of various competing network technologies and protocols and achieves network plug and play.

[0018]

Accordingly, there has been strong and widespread recognition of a unified framework for interconnecting various types of network devices and providing a uniform mechanism for device discovery and utilization. It is very advantageous to have such a thing.
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.

[0019]

SUMMARY OF THE INVENTION Accordingly, one aspect of the present invention is as follows.
One objective is to overcome the above limitations of known networking systems and integrate multiple networks with different communication protocols to interconnect various devices into a single unified framework, allowing user applications It is an object of the present invention to provide a method and an apparatus for enabling a network device to be discovered and used.

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

It is yet another object of the present invention to provide a network plug and play in which physically different devices connect, exchange information, negotiate data types, provide status about each operation. A method and apparatus for providing a platform-independent, transport-independent protocol that can be achieved.

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. Also,
This framework 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, a 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.

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

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.

According to the present invention, there is provided a method for automatically reconfiguring a framework in response to 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
The description of the requested service is checked against the description of the service to be provided, and the address of the matching service is returned to the user agent.

According to the present invention, there is also provided a method for generating a communication interface for a service executed by a new network device added to a framework. According to the method of the present invention, the device comprises:
Generate a schema describing the communication interface. This schema is based on XML (eXtensible Markup Langu
age) It can be in the form of a document. In that case, the user application uses the XML language parser to
Create a communication interface.

Further, 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.

[0031]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Achieving network plug and play across all types of distributed devices and services requires a unified framework. 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.

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 SL
P, HTTP, XML, Java RMI, and IIO
It is based on well-known Internet-related protocols such as P and can be implemented as an add-on to a web server, making it easy to deploy and use. Furthermore, in the framework of the present invention, the whole process of service discovery is transparent to the user application (transparent) 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, with the capabilities of the various devices covered,
Based on user authentication and authorization. Connecting incompatible devices may require tunneling and full data conversion.

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 about their operation. These protocols are platform-independent and can be incorporated 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.

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. Execution environment 102
Is a network 10 such as the Internet, for example.
1 are interconnected. The execution environment 102 acts in some sense as a network node. Execution environment 1
02 is a Java virtual machine or a window known to those skilled in the art.
ows ^™ based 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, various components of the active configuration framework system of the present invention will be described in detail.

[Dummy Device] The dummy device is T
A device without the CP / 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 of these 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] A normal network device is a single network type (for example,
(IP or IPX) allows interaction in a peer-to-peer manner. 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 arises. 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 in 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 to the device the ability to interact with the 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. After this point,
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 the IP device and the specialized gateway communicates with the non-I
Performs communication with the P device. The specialized gateway exposes dummy devices to the network and includes programming logic for controlling and managing the devices. Furthermore, 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 and treats the entire network as a Software Bus. The Infobus system is well known to those skilled in the art. For a detailed description, see Reaz Hoq
ue, "ConnectingJavaBeans with InfoBus", Wiley Comp
uter Publishing, Nov. 98. Software Bus is also well known to those skilled in the art, and is described by Brian Oki, Manfred Pfluegl,
Alex Siegel, and Dale Skeen, "The Information Bus
-an architecture for extensible distributed syste
^{ms ", Proceedings of the 14 th} Symposium on Operatin
g Systems Principles, p.58-68, Asheville, North Ca
rolina, December 1993.

The PnP broker allows a networked entity to discover and use the capabilities of another networked entity (gateway 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, US
Each B) has a specific gateway, which is connected at one end to this device cluster and at the other end to a PnP broker. X-10, HAVi, IEEE-139
4 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 is an IEEE using HAVi.
It can be a 1394 cluster gateway. 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
Through the communication with the dummy device 203 and the user application 202. Gateway device 20
1 runs on the network node 205 in its operating system environment. Node 205 provides security enforcement mechanism 204 to control access to gateways and services.

The networked entities are:
It is 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 are
It is possible to exchange 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 through the PnP broker and requests to use it. The PnP broker is a transport independent interface (P) for connecting service units and user applications.
nP broker interface). This interface is designed to run on the TCP / IP protocol stack. The 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 Pn
Has a P broker. When there is no local PnP broker, the user application / service unit
It is possible to use a remote PnP broker (a PnP broker connected to another gateway) through Internet communication protocols such as Java RMI and HTTP. The Java RMI protocol is well known to those skilled in the art. For a detailed description, see Downing, Troy Bryan, "
Java RMI: Remote Method Invocation ", IDG Books Wor
ldwide, 1998. The HTTP protocol is also well known to those skilled in the art. See Paul S. Hethmon, "Illustr
ated Guide to HTTP ", Manning Publications, 1997,
It is in. The service unit can use a PnP broker directly connected to it,
Remote P by using inter-broker protocol
It is also possible to use an nP broker. In the network system shown in FIG.
Is a service 14 connected to a remote PnP broker 1104 via an inter-PnP broker protocol 404.
06 and 1402 are used. Thus, one service unit can query and use the services available in service units located in different device clusters.

[PnP broker function component] P
FIG. 4 shows the internal components of the nP broker. Usually, the PnP broker includes the service registry 305, the service discovery / availability agent 3
04, service session management agent 306, service location protocol (SLP: service loca
option protocol) user agent 308 and SL
It comprises a P service agent 307. The PnP inter-broker protocol 303 is used for communication with another PnP broker 301. PnP broker interface 3
02 provides an interface to the user application 103. Service Location Protocol (SLP) is well known to those skilled in the art and is described by James Kempf and
Pete St. Pierre, "Service Location Protocol for En
terprise Networks: Implementing and Deploying a Dy
namic Service Resource Finder ", John Wiley and Son
s, 1999. The service registry is
Contains one or more service records. All information in the service registry is extensible markup language (XML) to facilitate searching, indexing and exchange.
It is described as XML is also well known to those skilled in the art,
Natanya Pitts-Moultis and Cheryl Kirk, "XML black
book ", Coriolis Group Books, 1999.

[Service Registry] The PnP broker includes a service registry to hold information about services. At a minimum, the registry must have its PnP
Stores information about gateways and services directly connected to the broker. As shown in FIG. 3, these services are on the local PnP broker 104 or the remote PnP broker 1104. Further, Pn
The P broker registry can also 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 a print server, 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 also provides information about all compliant devices within range of the local PnP broker, regardless of device type.
It can also act as a network directory. 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.

[Service Record] A service record is a set of available service units in a network-connected cluster, and describes available services and services requested from other PnP brokers. The service record is composed 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 the service unit and the service provided by the 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 primarily used to implement fine-grained access control for each service or device. In addition, the attribute record contains the current state of the device, and
Stores a description of the interface that can be used to modify it.

[Service Discovery / Availability Agent] The PnP broker searches for a remote PnP broker and identifies available services.
Requires a service discovery / availability agent. 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 checking the specified service type, Pn
The P broker can determine the characteristics of all or specific services registered with the remote PnP broker. Service discovery / availability agents are SLP user agents and SLs
Located above the P service agent.

Further, the PnP broker can periodically check the availability (availability) of a 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 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 device interface, these commands, responses and data have a specific format and are exchanged under defined protocols. 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, thereby enabling the user application and service to manage the message stream and the data format. 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
This is the format of native data in the native packet. User applications can use the PnP inter-broker protocol to discover services before making service requests or to query for services. 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 Packets While the data format is selected and controlled by user applications and services, the PnP broker can also set up data pipes and manage message streams. It is. 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 IEEE1394 compatible camera is a PnP
Digital VCs in different clusters through broker
Send data stream to R.

[Pn in PnP broker packet
P Broker Data (Fully Functional Gateway)] PnP
A broker configures 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 a common data format between the user application and the discovered service. The message exchange information is included in 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 USB
An IEEE 1394 compliant device that interacts with the device.

[SLP User Agent] A user agent is a process that operates on behalf of a user to establish a connection with a certain service. The user agent acquires service information from the service agent or directory agent.

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

Protocols and Interactions The PnP broker exposes a standardized interface that allows user applications to take advantage of the network's plug and play capabilities. With 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 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 the PnP
The nP inter-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 is identified, the PnP inter-broker protocol uses the Java RMI
Alternatively, using HTTP, the user application can 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 the PnP broker
Allows the service to be used through a service agent at the nP broker.

In summary, the protocol suite of the present invention consists of the following protocols and interfaces. Interface between PnP broker and 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 provides a standardized API and interface to the user application for service registration, service discovery, service request and availability check. Publish. Furthermore, P
The nP broker handles user identification and authentication for the appropriate service or device.

[Service Registration] When necessary, the service unit or the user application respectively
RegisterService () or UnregisterService to register or unregister yourself with the local PnP broker as a service unit or user application
Call (). 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 including a registered service unit having a specific 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 notify the local PnP broker of a service session with a specific service unit registered in either the local PnP broker or the remote PnP broker. Request to start. TransferData (), Receiv
The eData () and CloseService () calls provide additional functionality.

[Availability Check] The user application or the service unit is assigned to StartAvailab
Calls ilityCheck () to request the local PnP broker to periodically check whether a particular service unit registered with either the local PnP broker or the remote PnP broker is running.

User Identification and Authentication In the 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. Accordingly, one embodiment of the present invention provides a Java virtual machine and a J
The ava programming environment is used to ensure the security of one device. While the system can be designed to handle 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. MD
Reference numeral 5 denotes an encryption procedure for generating a code checksum, which is used for access control. However, large networks require a more flexible distribution mechanism for specifying security policies and naming code.

The security model of the present invention is built on two concepts, a principal and an 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 access to the service is allowed or not
Depends on the access control list corresponding to the object.

[PnP Broker Communication Protocol] Pn
The P-to-P 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 searches 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 service it needs, with or without a centralized registry.

[0070] Once a service has been searched, other steps may be required to utilize the service. In an embodiment of the present invention, the user application includes the quality of service and security requirements,
Negotiate access to services. Furthermore, 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. SLP
Automatically, without any prior configuration, checks the request of a user agent (UA) 502 against a service 512 provided by a service agent (SA) 504. SLP is SA
Announcement of services by the company and S managed by the Directory Agent (DA) 511
And the organization of services into the LP directory 508. 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 is
Understand the requests for services and resources by the user application 103. PnP broker 503
The SA 504 in (the same PnP broker or a different PnP broker) represents each network service and performs a service available to the UA 502.
The SLP dynamically retains service attributes, so the UA5
02 is capable of acquiring 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.

According to the present 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 can 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 sends a response SrvRply50 containing the network location of the appropriate service.
Responds with 5. In smaller facilities, it is possible that there is no DA, in which case the request message is sent directly to the SA.
Will be sent to This is called discovery by broadcast (507).

The service publishes itself by registering with the DA 511. The registration of the service includes a list of all keywords describing the service and attribute value pairs (pairs of attributes and values). In addition, registration,
Includes leases to resources. Thus, after the lease expires, the service information is deleted by the DA 511. The leasing mechanism is implemented to avoid situations in which service hardware is no longer available when services are being published forever. Also, explicit deregistration is
As part of A's regular shutdown procedure, D
It is possible to delete service information from A. Also, the SA periodically registers the current attribute information, so that the UA can check the status, load,
It is also possible to check temperature or other dynamic characteristics.

In the framework of the present invention, services are classified according to their service types. Each service type defines a set of available keywords and attributes that SA 504 makes available to describe the service. The service browser starts with the UA502
After finding a service type available to the UA 502, all characteristics of all services available to the UA 502 can be determined by querying all information published by the SA for that service type.

[User Agent-Service Agent Interaction] 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 the SrvReg message 5
06 is sent to DA511. The registration includes a service URI for a particular instance of the service and an attribute value pair describing the service. DA 511 can cache such registrations for various purposes. After the registration is cached, DA 511
Responds with an 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 deregister itself. This situation is SA50
4 should only be able to issue the SrvDereg message 506. During normal operation, the SA 504 periodically refreshes the service registration with a subsequent SrvReg message. Such a "refresh" message may include updated information if any of the values change,
It 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 DA 511 in UA 502 at startup, UA 50
2 is a DHCP (Dynamic Host Configurator) known to those skilled in the art.
It is also possible to request the address of the DA 511 by using the communication protocol. 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 DA 511. The SrvReq is multicast to the IANA assigned multicast address for the SLP. IAN
A is an Internet Assigned Numbering Au well known to those skilled in the art.
thority standard. Since this is a multicast request, it may receive multiple unicast responses. The resulting DA resource is available for other service requests.

[0078] Once the UA 502 has obtained 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 tries to find a printer service, an SrvReq is created. This message contains the service type "printer" and a list of optional 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. DA511 is
Receives the SrvReq and performs a lookup on the cached registration and attempts to find a match for the requested attribute and value. Then, SrvRp
ly is unicast to the requesting UA 502. This response may contain zero or more services U, depending on the match result.
Including RI. 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 acquire a service handle, it sends a service type and a character string-based inquiry for the requested attribute as a service request. When the service response is returned, this is the URI pointing to the service
including. The URI contains the IP address of the SA 504, or a name that DNS can resolve to an IP address. The URI is UA502
Includes any other information needed by you 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. In addition, the character set problem is
Can be dealt with in a standard way.

Interaction of PnP Broker with User Agents and Service Agents By using SLP, the PnP broker can make an accurate selection of the appropriate service from many other published devices of the same type. Can be. This is done by requesting only 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 the 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 service to neighboring DA 511,
The UA 502 can dynamically adapt to 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. SA5
04 can programmatically register with the SLP and assign values to attributes based on the unique configuration information of the service. After that, the SLP
Handles registration (publication) and allows the establishment of a connection between the user application and the service.

A new service type 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. Most common service types, by default, are IANA (Internet Assigned Numbering Au
service template (scheme) definition standardized by (thority). 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 security services at home, use "service: secure: Doo
You can define a service type of "r." Of course, user applications that use this type of service handle must use the service's network protocol to communicate with the "secure" service, and , This special service type U
It must be able to analyze the information contained in the RI. This is inherent in the natural operation of any user application / server protocol.

[Using SLP with LDAP] LDAPv3 (Lightweight Directory Access Protocol)
ocol) is well known to those skilled in the art and is becoming popular as a general purpose directory access protocol. LDAP is called Lightweight in its name, but SLP is LD
It is even "lighter" than the AP. SLP also provides LDAP in resource management to provide automatic directory management and to avoid improper resource placement in hierarchical and less flexible namespaces.
Is better. Adding new service types in SLP is much easier than in LDAP. Inquiry by type is L in case of SLP
It is more efficient than DAP. Attribute descriptions for existing resources are available in SLP, but LDA
Not possible with P.

[0086] In the SLP, discovery without prior configuration is possible. On the other hand, LD
The AP first starts with the directory address and the LDA
Requires knowledge of the directory scheme used by P. SLP can evolve because non-standard attributes and new versions of standardized service type templates are possible.

Embodiments of the present invention use SLP to define L
Simplifies the management of the DAP directory and allows the SLP to return information obtained from the LDAP directory as needed. In another embodiment, the SLP is LD
Used dynamically to enter service entries into the AP, SLP queries are mapped to LDAP queries, and LDAP is the back end of SLP. One advantage of such a configuration is that the user application obtains 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.

The receiving side PnP broker uses QueryService ()
Upon receiving the message, it compares the received service record with its own service record. Then, the receiving side P
The nP broker returns a service record containing 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 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 sends the remote Pn
Requests the establishment of a service session between the user application and the service by sending a message to the P 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 that specifies 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. The service session is between the user application and the service unit,
Alternatively, it handles data transfer between two service units. When the user application completes the use of the service, the user application notifies the local PnP broker of "close s
ervice "(end of service) message to remote PnP
Request to send to broker. Further, when the user application needs to periodically determine whether a 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 for an entire device or for 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, as described above, represents the service units directly connected to the gateway and registers the services to be provided. 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 for the service matches the requirements of the application, the User Application
A service session between a service unit in the gateway and a user application can be set up.

[Event Notification Mechanism] In the framework of the present invention, the user application can register an event notification request in the server. Will be notified to the user application when has changed. To achieve this, the present invention provides a mechanism for delivering event notifications to registered users.

The network event notification protocol includes CORBA (Common Request Broker Architecture).
There are several well known things such as event services, X-Window system events, SGAP, BSCW. For example, the CORBA event service is Robert
Orfali and Dan Harkey, "Client / Server Programming
with Java and CORBA ", Wiley, 1996.

However, the event notification service described above
Designed to operate on a particular architecture, and imposing a large code base, it is difficult to actually use in lightweight notification services.

In addition to the capabilities provided for registration for notification of some types of events, the user can associate attributes with the notification request. Preferably,
Such notifications should be delivered reliably and guarantee a completely 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, after the service is updated, the service agent sends a multicast announcement (SrvRe
g) is sent. After receiving the update, the user agent can make a browser update and the DA can update the registration. Such usage is described in SL
The use of P is not explicitly prohibited, but can cause flooding. Furthermore, this approach does not work efficiently for many services, different languages, and digital signatures. Also, Sr
vReg includes the URI and attributes of each service added / deleted / changed in the network.

[0098] In another embodiment of the present invention, the service agent broadcasts to all user agents in the network to send the SAAdver.
Announce ts message. SAAdverts
The 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 and reflects the type of device integrated by the network. The network is X-10, USB and I
An X-10 gateway connecting each of the IEEE 1394 devices / services to the rest of the network,
It can consist of a USB gateway and an IEEE 1394 gateway. The dummy device stores a record of the type corresponding to the service record on its own (pro
(prietary) format. Although the gateway / dummy protocol is unique, it exposes a standardized interface to the PnP broker.

Embodiment According to one embodiment of the present invention, a network has one or more PnP brokers. P
An nP broker acts as an interface between a user and some services. In one embodiment, X-1
The PnP broker for device 0 provides some buttons or other user interface widgets linked to the 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, PnP
The 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 polls available addresses periodically to check if any devices have become active.

5. The gateway recognizes that a new device has entered the network, and passes both the device and the services provided by the device to Pn.
Register with the P broker service agent.

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. Then P
The user agent at the nP broker 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 accordingly,
A service session management agent in the PnP broker establishes a session between the user application and the device. 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 one embodiment of the present invention includes a power line (X-10) cluster 613, telephone line (HomePNA / xDSL) clusters 602 and 606, CAT5 (Ethernet®). ) It comprises well-known network components 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 is connected to the home PC 62 of the user.
Contains 0. 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 of 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. Also, home PC 620
Are 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. XD including home PC 607
The SL cluster 606 is connected to the residential gateway 605 through a bridge 608. PC620
The PnP broker running above allows users to search for new devices / services within a web browser based interface. This embodiment uses Microsoft Internet Explore as a user interface.
r Use a ^TM v5.0 web browser, but other suitable browsers can be used.

When a device / service is inserted into the corresponding network, it appears in the browser with configurable properties. 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 being given the right, the user can change device properties and interconnect devices. Pn
The P-broker handles the authentication of the user to the device and the conversion of data / message in case of incompatibility. For example,
The X-10 devices 614 and 615 use the gateway device on the PC 620 to
A dummy device that can interact with the rest of the devices in the framework. PnP broker is HTT
It can also be implemented as an add-on to a P 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. Usually, (MPE on PC 603
An analog TV 601 connected to the network (using a G-2 decoder) 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 view the camera image directly on the TV. If a Jini device (eg, a printer) is connected to the network, the device
It works with non-Jini devices as if the ni device were a Jini device.

[Solution to the Problem of the Jini Interface] 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 relates to Jini
Overcome the above shortcomings of the Jini interface while borrowing a 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 a standard API, and the services
You will implement PI. 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 for 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 in the Java virtual environment, unlike Jini, the present invention handles the address of the service and other parameters that describe the interface of the service, and this interface Providing information to clients.

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 functions 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 has limitations in the ability to customize the application, so the application maximizes the capabilities of the device, i.e., up to the user demand 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 to make the state of the application accessible through a well-defined external protocol. On the contrary,
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 that the application program
To be downloaded on the fly to a client device or a 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 the application is 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, while this approach exposes functionality, it is not an easy-to-operate format.

[0120] 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, that is, a model that balances the need to publish interfaces with the need to agree on protocol standards. The first difficulty in solving this problem is the available functions (interfaces) of the service.
Is to define a single-document schema that describes the related documents and user interfaces to a set of services (and vice versa). 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 Da
vid Krieger and Richard Adler, "The emergence ofdi
distributed component platforms ", IEEE Computer Maga
zine, 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 describing and manipulating interfaces that are not application specific.

[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 (CORB
A as in IDL). These interfaces are shared between all entities in the network, but can be operated by any user application. The user application
It has full control over the use of service interfaces and the metadata presented by such interfaces. User application 7
If there is a change 704 in the state of the interface or its use by 03, 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 edits 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, device descriptions are stored using declarative style XML and are 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 explicitly incorporates metadata into the design, so that storage and manipulation is 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 to architecture.
For more information on the model / view / controller architecture, see G. Krasner and ST Pope, "A Cook
book for Using the Model View Controller User Inte
rface Paradigm in Smalltalk-80 ", Journal of Object
Oriented Programming, August / September 1988.

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

According to the present invention, a device description schema is created as an XML document type definition (DTD) using an XML syntax. 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. XSL (Extensible Styl
e Sheets) and XLink (Extensible Linking Language)
XML, along with like protocols, provides the ability to specify, discover, and combine groups of accompanying document schemas (document type definitions: DTDs). But HT
Unlike ML, the set of tags in XML is flexible, and the semantics of the tags are defined by the DTD that accompanies the document. Resource Descripti
Other metadata markup languages, such as on Format, Dublin Core and XML-Data, have also been proposed.

[0130] 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, since the schema embeds the service's interfaces in the XML / XSL definition, the parser can read these interfaces without having to download the code to the user application. For example,
The <ON> tag for the light switch can indicate the address and port number at which the device listens for method calls and other events.

The user interface can be used for these services.
In order to generate from the description, the XML parser
Used by user applications. Cry
Ant uses the lexical type as a user interface widget.
After mapping to XML and analyzing XML / XSL
User for the current configuration of the
Generate the interface. User (or user
Application) dynamically responds to that device
Simply click on the generated UI widget
Therefore, change the state of any network device
be able to. This action is performed on the user's machine
Change the current UI status and change the appropriate command
(Embedded in XML document defined by device vendor
Sent to the device for execution. Embodiment of the present invention
So, for this purpose, Java ^TMPubli written in
Domain domain XML parser and Internet Explorer^TM 
An XML-compatible web browser such as 5.0 is used.

Although the present invention has been described with reference to preferred embodiments, it will be readily recognized by those skilled in the art that the form and details of the present invention may be changed without departing from the technical scope and spirit of the present invention. Various changes are possible.

[Brief description of the drawings]

FIG. 1 is a diagram of an active configuration framework infrastructure.

FIG. 2 is an overall design diagram of an active configuration framework.

FIG. 3 is a diagram showing 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 (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 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 50 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 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 In Interface definition 703 user application 704 change 705 announcement 706 reference 1104 remote PnP broker

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI theme coat ゛ (Reference) H04L 29/06 H04L 13/00 305B

Claims (32)

[Claims] 1. An active configuration framework comprising: (a) at least one service and at least one service user; and (b) a first plug and play broker, wherein the at least one service user comprises An active configuration framework, wherein the service is used by using the plug-and-play broker. 2. The service user communicates with the service through the first plug and play broker independent of a communication protocol used by a device providing the service.
Active configuration framework as described in. 3. The service comprises a gateway and a device cluster, wherein the gateway associates the device cluster with the first
The active configuration framework of claim 1, wherein the first plug and play broker communicates with the device cluster through the gateway. 4. The first 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, 4. The active configuration framework according to claim 3, wherein the gateway performs a conversion between the first communication protocol and the second communication protocol. 5. The gateway registers the service with the first plug and play broker by setting an attribute corresponding to the service in the first plug and play broker. The active configuration framework according to claim 3. 6. The gateway, in response to a request from the first plug and play broker,
The active configuration framework according to claim 3, wherein the status of the service is periodically updated by a plug and play broker. 7. The service user is a remote service user remote from the first plug and play broker, wherein the remote service user communicates with the first plug and play broker through an Internet communication protocol. The active configuration framework according to claim 1, characterized in that: 8. The active configuration framework further comprises a second plug and play broker, wherein the service user communicates with the second plug and play broker, wherein the second plug and play broker The active configuration framework according to claim 1, wherein the at least one service user communicates with the first plug and play broker to enable the at least one service user to use the service. 9. The active configuration framework further comprises a directory agent, wherein the first plug and play broker registers the service with the directory agent using a service location protocol. An active configuration framework according to claim 8, wherein 10. The first plug-and-play broker has a service registry, the service registry includes information about the service and other network services, and the at least one service user configures the service registry. 2. The method of claim 1, wherein the service and the other network service are used to discover the service.
Active configuration framework as described in. 11. The active configuration framework further comprises a second plug and play broker, wherein the second plug and play broker sends an inquiry to the first plug and play broker, The service of claim 1, wherein the service is found.
Active configuration framework as described in. 12. The active configuration framework further comprises a second plug and play broker and a directory agent, wherein: (a) the at least one service user writes a description of a required service to the second (B) the second plug and play broker communicates with the directory agent; and (c) the directory agent sends the service address that matches the requested service description to the directory agent. Returning to a second Plug and Play broker, wherein (d) the second Plug and Play broker establishes a session between the service user and the service using the address.
Active configuration framework as described in. 13. The service includes a gateway and a device cluster; (2) the gateway connects the device cluster to the first plug and play broker; and (3) the first plug and play broker. A plug and play broker that communicates with the device cluster through the gateway; and (4) the gateway configures the service in the first plug and play broker by setting an attribute corresponding to the service. The active configuration framework according to claim 10, wherein the first plug and play broker registers the service with the directory agent. (5) The first plug and play broker registers the service with the directory agent. . 14. The first plug and play broker, comprising: (a) a plug and play broker interface for communicating with the service user; and (b) the first plug and play broker and other components in the framework. A plug and play broker protocol for communication with a plug and play broker, (c) a service registry having at least one service record storing information about the service, and (d) a network address of the service. A service discovery / availability agent that searches for and obtains the availability status of the service; (e) a service session management agent that establishes a communication session between the service and the service user; The active configuration framework according to claim 1, comprising: a service location protocol user agent for searching for an address of a service; and (g) a service location protocol service agent for publishing the service. 15. The at least one service record has a service identification field for storing the service type and a plurality of service attribute records, wherein the service attribute record stores an attribute identification field for storing the service attribute type. The active configuration framework according to claim 14, further comprising: an attribute value field for storing a value of the service attribute; and an access control field for storing access control information of the service. 16. An active configuration framework comprising: (a) at least one service; (b) a service agent; and (c) a directory agent, wherein the service agent has a type and an attribute of the at least one service. Registering with the directory agent, the directory agent matching the type and attributes of the service requested by the user application with the type and attributes of the at least one service and returning an address of the at least one service Active configuration framework characterized by: 17. The active configuration framework further comprises a user agent, wherein the user agent sends the type and attributes of the requested service to the directory agent, wherein the directory agent The active configuration framework according to claim 16, wherein addresses of two services are returned to the user agent. 18. The at least one service has a gateway and a device cluster, the gateway connects the device cluster to the service agent, and the service agent communicates with the device cluster through the gateway 17. The active configuration framework according to claim 16, wherein: 19. The active configuration framework according to claim 16, wherein the active configuration framework further has an execution environment, and the application operates in the execution environment. 20. The active configuration framework according to claim 19, wherein the execution environment is a Java virtual machine. 21. The active configuration framework of claim 19, wherein the execution environment is a Windows ^™ based machine. 22. A method for performing automatic reconfiguration of a framework in response to adding a network device, wherein the network device provides at least one service, wherein the framework includes a service agent and a directory agent. The method comprising: (a) the service agent registering a type and an attribute of a service to be provided with the directory agent; and Matching the type and attributes of the service provided,
Returning an address of the provided service. A method for performing automatic reconfiguration of a framework in response to addition of a network device. 23. The framework further comprises a user agent, wherein the user agent sends the type and attributes of the requested service to the directory agent, wherein the directory agent The method of claim 22, returning an address to the user agent. 24. The step (a) comprises: (1) the gateway checking the availability of the network device; and (2) the gateway recognizing a type and an attribute of the provided service to the service agent. 23. The method of claim 22, comprising: registering with the directory agent; and (3) the service agent registering the type and attributes of the provided service with the directory agent. 25. The method of claim 22, further comprising: (c) a session management agent establishing a communication session between the user application and the network device using the address. . 26. A method for generating a communication interface for a service performed by a device inserted into a framework, wherein the interface is used by a user application to utilize the service, the method comprising: (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; and (b) using the XML parser. Generating a communication interface for the service from the description schema, the method comprising: generating a communication interface for a service performed by a device inserted into the framework. 27. The method of claim 26, wherein the service description schema includes data and control flow specifications for the service. 28. In step (b), the service description schema generated by the device is mapped to a set of user interface widgets, and a user clicks on a user interface widget that sends a command to the device for execution. 27. The method of claim 26, wherein the state of the device can be changed by doing so. 29. 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, and the service uses the hierarchy of the object. 27. The method of claim 26, wherein the method is utilized by the user application. 30. The method of claim 29, wherein the hierarchical structure of the object is determined based on a function of the device when the user application uses the device. 31. The method of claim 30, wherein the XML parser is an XML-enabled web browser. 32. A method for controlling a device inserted into a framework, the method comprising: (a) the device comprising at least one of an XML document, a document type definition, or a style sheet. (B) the user application edits the device description schema and reflects the edited device description schema on the device; and (b) the device edits the device description schema. A method for controlling a device inserted into a framework, characterized in that the state is changed according to a configured device description schema.