KR100664921B1 - Apparatus and method for integrated middleware supporting multiple protocols for distributed computing - Google Patents

Abstract

It provides an Apparatus and method for integrated middleware supporting multiple protocols for distributed computing.

According to an embodiment of the present invention, an integrated middleware device may receive information about a device through an addressing module for allocating a unique network address in a predetermined network or an allocated network address when another device joins or leaves the network. And a discovery module for decrypting information using at least one of a plurality of distributed computing protocols according to the port of the received information, and a control module for requesting a service from the device based on the decrypted information.

Distributed computing, integrated middleware

Description

Apparatus and method for integrated middleware supporting multiple protocols for distributed computing}

FIG. 1 is a diagram showing devices mixed with a middleware device supporting a protocol for conventional distributed computing on a network.

2A is a conceptual diagram of an entire system in which a device incorporating an integrated middleware device according to an embodiment of the present invention is executed.

2B is a diagram illustrating a structure of hardware including an integrated middleware device according to an embodiment of the present invention.

3 is a block diagram illustrating a configuration of an integrated middleware device according to an embodiment of the present invention.

4 is a diagram illustrating a detailed structure of a discovery module of the integrated middleware device of FIG. 3.

FIG. 5 is a diagram illustrating a detailed structure of a description module of the integrated middleware device shown in FIG. 3.

FIG. 6 is a diagram illustrating a detailed structure of an eventing module of the integrated middleware device of FIG. 3.

7 is a flowchart illustrating a controlled device in a discovery step according to an embodiment of the present invention.

8 is a flow diagram illustrating a side of a device (Controle Point) for controlling a discovery step according to an embodiment of the present invention.

FIG. 9 is a flowchart illustrating a control device in a description step according to an embodiment of the present invention.

FIG. 10 is a flow diagram illustrating a side view of a device controlling a description step according to an embodiment of the present invention.

FIG. 11 is a flowchart illustrating an eventing step in a controlled device according to an embodiment of the present invention.

12 is a flowchart showing a side of a device (Control Point) for controlling the eventing step according to an embodiment of the present invention.

The present invention relates to an integrated middleware device and method, and more particularly, to a single middleware integrating and providing a framework supporting a plurality of protocols for distributed computing, thereby allowing an application developer to use a service on a distributed system. The present invention relates to an apparatus and a method for allowing a service to be independently implemented.

Representative protocols for distributed computing include UPnP (Universal Plug-and-Play) and Web Services.

UPnP technology is an architecture for peer-to-peer connectivity of all forms of intelligent products, wireless devices, and PCs. UPnP is designed to provide easy-to-use, flexible, and standards-based connectivity to ad hoc or unmanaged networks that are connected to the home, small office, public, or Internet. UPnP technology provides a distributed open network architecture that enables TCP / IP and Web technologies to enable seamless proximity networking. The UPnP device architecture defines a communication protocol between a controlling device (Control Point (hereinafter referred to as CP)) and a CP-controlled device (hereinafter referred to as Controlled Device (hereinafter referred to as CD)). The CP corresponds to a client and the CD corresponds to a service or a device providing a service. Communication in a UPnP-based network can be divided into six stages. An addressing step that assigns a unique network address to a device participating in the network, a discovery step that provides the ability to discover the presence of a new participating device to other devices on the network and searches for the CD of interest to the CP, a CD of interest to the CP A description step of acquiring detailed information about the control step, a control step in which the CP invokes a service of the CD, an event step in which the CP obtains information on a state change of the CD, additional information of the device or service through HTML, This is a presentation phase that provides the functionality.

Web service technology is a technology that enables application developers to develop more powerful applications using services published on the Web, enabling a distributed computing environment on the Internet. The key concepts that make up Web services-based networking technologies are SOAP, WSDL, and UDDI. Web services expose useful functionality to web users through a standard web protocol called Simple Object Access Protocol (SOAP). SOAP defines an XML format for messages. Web services provide an XML document called Web Service Description Language (WSDL) to describe the interface required for client applications. The WSDL defines what the request message for the web service should contain and how the response message should be represented. Client applications can find the necessary Web services through Universal Discovery Description and Integration (UDDI).

As described above, Web services and UPnP technologies are similar in that they provide a technology for providing connectivity and interoperability among services in a distributed computing environment. However, protocols for distributed computing, such as UPnP or Web services, are incompatible with each other because there are differences in the details and presentation formats of the protocols used for each step. Therefore, when devices equipped with middleware based on UPnP or web services are mixed on a network as shown in FIG. 1, devices supporting UPnP cannot communicate with and interoperate with devices supporting web services. In this case, the service developer is inconvenient to develop an application in consideration of whether the network is based on UPnP technology or Web service technology. In order to enable device application developers to develop applications independent of the technology on which the network is based, there is a need for an integrated middleware device and method that can support multiple protocols for distributed computing.

It is an object of the present invention to provide an integrated middleware apparatus and method for supporting multiple protocols for distributed computing, so that an application developer of a device can develop an application independently of a technology based on a network.

The object of the present invention is not limited to the above-mentioned objects, and other objects that are not mentioned will be clearly understood by those skilled in the art from the following description.

In order to achieve the above object, the integrated middleware device according to an embodiment of the present invention, an addressing module for assigning a unique network address in a predetermined network, through the network address assigned when other devices join or leave the network A discovery module that receives information about the device, decrypts information using at least one of a plurality of distributed computing protocols according to the port of the received information, and a control module that requests a service from the device based on the decrypted information It includes.

On the other hand, the integrated middleware device according to an embodiment of the present invention, the addressing module for assigning a unique network address in a predetermined network, a plurality of possible to provide their information through the assigned network address when joining or leaving the network And a discovery module for notifying other devices in the network using at least one of the distributed computing protocols of the network, and a control module for receiving a service request based on information from the device and transmitting a service performance result according to the service request to the device.

In order to achieve the above object, a method for supporting a plurality of protocols for distributed computing according to an embodiment of the present invention, the step of assigning a unique network address within a given network, other devices to join or leave the network Receiving information about the device through an assigned network address, decrypting the information using at least one of a plurality of distributed computing protocols according to the port of the received information, and transmitting the information to the device based on the decrypted information. Requesting a service.

On the other hand, the method for supporting a plurality of protocols for distributed computing according to an embodiment of the present invention, the step of assigning a unique network address in a predetermined network, when joining or leaving the network through the assigned network address itself Informing the other device in the network using at least one of a plurality of distributed computing protocols that can be provided, and receiving a service request based on the information from the device and transmitting a service performance result according to the service request to the device. Include.

Specific details of other embodiments are included in the detailed description and the drawings.

Advantages and features of the present invention and methods for achieving them will be apparent with reference to the embodiments described below in detail with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but can be implemented in various different forms, and only the embodiments make the disclosure of the present invention complete, and the general knowledge in the art to which the present invention belongs. It is provided to fully inform the person having the scope of the invention, which is defined only by the scope of the claims. Like reference numerals refer to like elements throughout.

In the present specification, an integrated middleware device supporting UPnP and a web service protocol as an integrated middleware device supporting a plurality of protocols for distributed computing will be described mainly for easy description of the present invention. However, it will be apparent to those skilled in the art that the present invention is not limited thereto, but may be extended to a middleware device capable of supporting two or more protocols for distributed computing.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

2A is a conceptual diagram of an entire system in which a device incorporating an integrated middleware device according to an embodiment of the present invention is executed.

The structure of the entire system is a structure in which one or more CPs (or clients) that require services and one or more CDs (or services) that provide services are connected to the network. A general CP or CD can support only one of UPnP or web services (220 and 230), and the CP 210 or CD 240 according to an embodiment of the present invention supports both UPnP and web services. Built-in communication with all devices is possible.

Hereinafter, CP is used as a client and CD is used as a service or a device providing a service.

2B is a diagram illustrating a structure of hardware including an integrated middleware device according to an embodiment of the present invention.

The device of the present invention may be configured as a digital device. Digital devices are devices with digital circuits that process digital data. Computers, printers, scanners, pagers, digital cameras, fax machines, digital copiers, personal digital assistants (PDAs), mobile phones, digital home appliances, digital phones, and digital projects. , Home servers, digital video recorders, digital TV broadcast receivers, digital satellite broadcast receivers, and set-top boxes.

The device (200, 270) with integrated middleware according to an embodiment of the present invention performs the operation of the input unit 240 receives a user input, the network interface 250 connected to the network for communication, the integrated middleware embedded device A control unit 210 for adjusting the operation of other parts, a memory 220 for storing data, an output unit 230 for outputting data to the outside, and an integrated middleware that supports a plurality of protocols for distributed computing. It may be composed of a chip (Embeded Chip). Meanwhile, in another embodiment, an integrated middleware device supporting multiple protocols for distributed computing may exist independently of the digital device.

The devices (200, 270) embedded with the integrated middleware is connected to the network and UPnP embedded device or Web service embedded device via the network interface 250 to communicate with each other.

3 is a block diagram illustrating a configuration of an integrated middleware device according to an embodiment of the present invention.

An integrated middleware device according to an embodiment of the present invention is largely an interface module for providing one integrated interface to an application layer, an implementation module for implementing an interface and integrating two or more protocols for distributed computing, and a first for distributed computing. A first protocol module for supporting the protocol and a second protocol module for supporting the second protocol for distributed computing. The interface module receives a command and information necessary for executing the command from the application layer, provides it to the implementation module, and delivers the information provided from the implementation module to the application layer. The implementation module manages the information provided from the interface module and drives the first protocol module or the second protocol module to generate a message of a suitable format based on the information, and is processed by the first protocol module or the second protocol module. The necessary information is obtained from the received message and provided to the interface module. The first protocol module and the second protocol module are driven as necessary to generate or process a message of the corresponding protocol.

3 illustrates an integrated middleware device supporting UPnP and web services among integrated middleware devices according to an embodiment of the present invention as a detailed module implementing each step of UPnP and web services. UPnP and web services integrated middleware device according to an embodiment of the present invention is composed of an addressing module, a discovery module, a description module, a control module, an event module, a presentation module. These modules include an interface module that provides a step-by-step interface as described above, and an implementation module that implements the interface. The middleware device according to an embodiment of the present invention provides an integrated solution of UPnP and web service as a TCP / IP based network middleware. Thus, it provides an addressing and presentation step that can be relatively independent of UPnP and Web services, a control step using the same message protocol as SOAP, and a UPnP and Web service at the same time in the discovery, description, and eventing phases. Provides support functions.

The term " module " as used in this embodiment refers to software or a hardware component such as an FPGA or an ASIC, and the module plays certain roles. However, modules are not meant to be limited to software or hardware. The module may be configured to be in an addressable storage medium and may be configured to play one or more processors. Thus, as an example, a module may include components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, procedures, subroutines. , Segments of program code, drivers, firmware, microcode, circuitry, data, DB, data structures, tables, arrays, and variables. The functionality provided within the components and modules may be combined into a smaller number of components and modules or further separated into additional components and modules. In addition, the components and modules may be implemented to reproduce one or more CPUs in an integrated middleware device.

The addressing module 310 assigns a unique network address to the CP or CD when the new CP or CD joins the network. Addressing is a basic function of TCP / IP-based networks. In the case of UPnP, newly added devices are assigned by DHCP clients within the device by requesting an IP address from a Dynamic Host Configuration Protocol (DHCP) server, or without a DHCP server. Use AutoIP Addressing (AutoIP) to assign IP addresses that are not used by other devices. In the case of a web service, it is assumed that the device has already obtained a valid IP address. The addressing step is an essential function to support the device or service, and can be said to be independent of UPnP and web services. Therefore, the addressing module of the integrated middleware device according to the embodiment of the present invention receives the information required to receive an IP address through the interface module 312 and the interface module, which provide a common interface to UPnP and web services, and automatically performs IP / DHCP An addressing implementation module 314 that delivers to module 316, and an automatic IP / DHCP module 316 that performs the actual addressing step.

The discovery module 320 allows the CP to find a service of interest and informs the CPs on the network when a new CD joins or withdraws from the network. The discovery phase of UPnP can be divided into two main stages. The first is when a new CD joins the network, and the second is when a new CP joins the network. When a new CD joins the network, the CD multicasts a message with basic information to announce its existence. In this case, the basic information includes a URL of a description of a device providing a CD, a device type, an expiration time of a notification message, and the like. On the other hand, when a new CP participates in the network, when the CP multicasts a message for finding a CD of interest, the corresponding CD transmits a response message to the CP. This mechanism is the same for Web services. However, UPnP uses the simple service discovery protocol (SSDP) based on HTTP as a protocol providing the above-mentioned multicast discovery mechanism, and the web service uses WS-Discovery based on XML. The discovery module 320 according to an embodiment of the present invention provides a mechanism for communicating with both a device using UPnP and a device using a web service. Detailed structure of the discovery module 320 for this purpose will be described later in FIG.

The description module 330 allows the detailed information of the CD found through the discovery module. In the description stage, UPnP expresses devices and services as device / service templates defined in a certain format, and web services express service details in WSDL. Both device / service templates and WSDL have many differences in the XML format or their detailed representation. The description module 330 supports both the UPnP and the description steps of the web service. The description thereof will be described later with reference to FIG. 5.

The control module 340 allows the CP to call a service provided by the CD and receive a response to the call. A service call is a remote procedure call that the CP sends to the CD requesting a service and the CD returns the result when the service completes. This is a mechanism common to both UPnP and Web services. Service invocation messages and response messages use the SOAP protocol. Accordingly, the control module 340 receives the service call command and the information about the service to be called from the application layer through the control interface module 342 and transmits the information to the control implementation module 344, and the control implementation module 344 receives the received information. Is transmitted to the SOAP module 346 to generate and transmit a service request message according to the SOAP protocol. When the service is completed, the result message is received and processed by the SOAP module and provided to the control implementation module. The control implementation module transmits this information to the application layer through the control interface module.

Eventing module 350 performs the eventing steps of UPnP and web services. When the CP wants to know the state change of the CD of interest, the integrated middleware device according to the embodiment of the present invention generates and transmits a subscription message to the event URL among the information about the CD acquired in the discovery step and transmits the CD. After registering the CP that sent the registration request message, each time the state of the CD changes, the event message containing the information on the state change is transmitted to the registered CPs. UPnP uses the General Event Notification Architecture (GENA) as the protocol for the eventing phase, and Web services uses the WS-Eventing protocol. The two protocols provide a similar mechanism but differ in their message format and details. Eventing module 350 supports both the eventing phase of UPnP and web services by providing one eventing interface module 351 and an eventing implementation module 352 that support both UPnP and web services. Detailed structure of the event module 350 will be described later in FIG.

The presentation module 360 performs presentation steps of UPnP and web services. The presentation module provides information or functionality about the CD via HTTP. Since the presentation function is an additional function, it is common or optional for UPnP and web service. The presentation module 360 provides an interface 362 to an application using UPnP and web services, and the presentation implementation module 364 provides the HTTP module 366 with information received through the interface to provide information about the CD. I will provide a function.

4 is a diagram illustrating a detailed structure of a discovery module of the integrated middleware device of FIG. 3.

The discovery module 320 includes the discovery interface module 321, the discovery implementation module 322, the UPnP SSDP module 323, the WS-Discovery module 324, and the multicast ports 325 and 326. The discovery interface module 321 is an interface part provided to an application developer, and the developer can control the discovery step through this module. The discovery interface module 321 receives from the application a command to send a message indicating the presence of a device, a command to send a message indicating that the device is removed, a command to search for a device of interest and information about the devices necessary for these commands. . The discovery implementation module 322 provides the device related information received from the discovery interface module 321 to the UPnP SSDP module 323 or the WS-Discovery module 324. In addition, the SSDP message or the WS-Discovery message decrypted from the UPnP SSDP module 323 or the WS-Discovery module 324 is received, and necessary information, that is, information about a device, is transmitted to the application layer through the discovery interface module 321. .

The UPnP SSDP module 323 generates an SSDP message of UPnP, decodes the received SSDP message, and provides it to the discovery implementation module 322. The WS-Discovery module 324 generates a WS-Discovery message of the web service, decrypts the received WS-Discovery message, and provides the WS-Discovery message to the discovery implementation module 322. The generation of the SSDP message and the generation of the WS-Discovery message may be simultaneously performed, or only one may be performed at the request of an application. Among the SSDP message and the WS-Discovery message, the multicasted message, for example, the Alive / Hello message and the Bye message, are transmitted and received through the multicast channel 239: 255: 255: 250. The SSDP message is sent and received on port 1900 325, and the WS-Discovery message is sent and received on port 3702 326. Therefore, messages multicasted in the discovery phase may be classified into SSDP messages and WS-Discovery messages according to ports used. Meanwhile, a unicast message, for example, a response message to a discovery message, of an SSDP message and a WS-Discovery message may be classified into an SSDP message and a WS-Discovery message by analyzing a header portion of the socket or the message where the message is received. .

The following is the UPnP SSDP: Response message format.

HTTP / 1.1 200 OK

CACHE-CONTROL: max-age = seconds until notification is discarded

DATE: Date when the response was generated

EXT:

LOCATION: URL of the UPnP description for the root device

SERVER: OS / version UPnP / 1.0 product / version

ST: Navigation Goal

USN: Advertisement UUID

For example, the UPnP SSDP: response message has a URL ending with .XML in the LOCATION header, and the UPnP / 1.0 tag is specified in the SERVER header, indicating that the analysis module is an SSDP message.

The following is the format of the WS-Discovery: ProbeMatch message, one of the WS-Discovery response messages.

<s: Envelope ...>

<s: Header ...>

<a: Action ...>

http://schemas.xmlsoap.org/ws/2004/02/discovery/ProbeMatch

</ a: Action>

<a: MessageID ...> xs: anyURI </ a: MessageID>

<a: RelatesTo ...> xs: anyURI </ a: RelatesTo>

<a: To ...> xs: anyURI </ a: To>

...

</ s: Header>

<s: Body ...>

<d: ProbeMatch ...>

<a: EndpointReference ...>

<a: Address ...> xs: anyURI </ a: Address>

[<a: ReferenceProperties ...> ... </ a: ReferenceProperties>]?

...

[<p: Policy> policy expression </ p: Policy>]?

</ a: EndpointReference>

[<d: Types ...> list of xs: QName </ d: Types>]?

[<d: Scopes ...> list of xs: anyURI </ d: Scopes>]?

<d: MetadataVersion ...> xs: nonNegativeInteger </ d: MetadataVersion>

...

</ d: ProbeMatch>

</ s: Body>

</ s: Envelope>

For example, the WS-Discovery: ProbeMatch message looks at the action part of the header part, that is, http://schemas.xmlsoap.org/ws/2004/02/discovery/ProbeMatch , indicating that the analysis module is a WS-Discovery message. .

FIG. 5 is a diagram illustrating a detailed structure of a description module of the integrated middleware device shown in FIG. 3.

The description module 330 includes a description interface module 331, a description implementation module 332, a UPnP module 333, a WSDL module 334, and a description builder module 335.

The description interface module 331 is an interface part provided to the application developer, and the developer can control the description step through this module. The description interface module 331 receives from the application a description request command and information about a device of interest obtained in the discovery step or detailed information about a device required for preparing a description document, and delivers the information to the description implementation module 332.

The description implementation module 332 analyzes the information about the device of interest provided from the description interface module 331 to cause the UPnP module 333 or the WSDL module 334 to send the description request message to the description document URL. . When the CD receives the description request message, the CD provides detailed information about the device received from the description interface module 331 to the UPnP module 333 or the WSDL module 334. In addition, the device / service template or WSDL message processed from the UPnP module 333 or the WSDL module 334 is transmitted to the application layer through the description interface module 331.

The description step is a step of providing detailed information of a device that a CD provides itself and detailed information about a service that can be provided by a CP. In order to express detailed information about a service, UPnP uses a device / service template and a web service uses WSDL. Accordingly, the UPnP module 333 receives the necessary information from the description implementation module 332 to generate a message representing detailed information about a service, generates and transmits a message in a device / service template format, and describes the description builder module 335. Decode the device / service template received from the) to provide the appropriate service information to the description implementation module 332. The WSDL module 334 receives the necessary information from the description implementation module 332 to generate a message representing detailed information about a service, generates and transmits a message in WSDL format, and receives the message from the description builder module 335. The WSDL message is decrypted to provide appropriate service information to the description implementation module 332.

The description builder module 335 dynamically transmits the generated device / service template or WSDL message using the corresponding information of the description implementation module 332 when a request for detailed information about the device or service is performed, and receives the received device / The service template or WSDL message is analyzed and delivered to the UPnP module 333 or the WSDL module 334. The received detailed information may distinguish the used protocol according to information about the CD decrypted in the discovery step, for example, a description URL or header information of the detailed information or a format of the detailed information.

As described above, the device / service template or the WSDL message may be provided as a dynamic stream whenever there is a corresponding request rather than a file. Meanwhile, in another embodiment, a device / service template or a WSDL message may be stored in a file form and provided when a request for corresponding information is provided. Whether the received description document is a device / service template or a WSDL message can be known from information about a device obtained in the discovery step, for example, a description URL.

FIG. 6 is a diagram illustrating a detailed structure of an eventing module of the integrated middleware device of FIG. 3.

The eventing module 350 is composed of an eventing interface module 351, an eventing implementation module 352, a UPnP GENA module 353, a WS-Eventing module 354, and an interpreter module 355. Eventing interface module 351 is an interface part provided to the application developer, the developer can control the eventing step through this module. The eventing interface module 351 determines whether a device of interest is a UPnP device or a web service device according to event control commands related to event registration and registration removal from an application, URL information for event registration, and information obtained in a description step. Get information and more.

The eventing implementation module 352 delivers the state information of the CD obtained from the UPnP GENA message or the WS-Eventing message to the application layer through the eventing interface module 351, and the affairs through the eventing interface module 351. The event control command provided from the application is analyzed and processed by the UPnP GENA module 353 or the WS-Eventing module 354. At this time, the eventing implementation module 352 may distinguish whether an eventing control command is a UPnP GENA command or a WS-Eventing command through information of a device acquired in the description step provided from an application, for example, a URL for event registration. Can be.

The interpreter module 355 analyzes the event control command transmitted from the CP and the event message transmitted from the CD and transmits the analyzed message to the UPnP GENA module 353 or the WS-Eventing module 354. Whether the received event control command is a UPnP GENA message or a WS-Eventing message can be known from the URL requesting event registration and registration removal or header information of the message. The CP may extract the eventing URL from the WSDL for the device template or service in the description step.

The following is the format of UPnP GENA: Subscribe and WS-Eventing: Subscribe messages.

SUBSCIRIBE publisher path HTTP / 1.1

HOST: Publisher host: publisher port

CALLBACK: <delivery URL>

NT: upnp: event

TIMEOUT: Second- requested subscription duration

In case of UPnP GENA: Subscribe message, it can be known that it is UPnP GENA: Subscribe message by looking at Publisher path, Publisher host: publisher port of HOST header, or NT (Notification Type) upnp: event value. The Publisher path is an element that indicates the path of the event URL, and the Publisher host: publisher port in the HOST header indicates the domain name (IP address) and port number of the event URL.

<s: Envelope ...>

<s: Header ...>

<wsa: Action>

http://schemas.xmlsoap.org/ws/2004/01/eventing/Subscribe

</ wsa: Action>

<wsa: MessageID> xs: anyURI </ wsa: MessageID>

<wsa: FaultTo> endpoint-reference </ wsa: FaultTo>?

<wsa: ReplyTo> endpoint-reference </ wsa: ReplyTo><wsa:To> xs: anyURI </ wsa: To>

...

</ s: Header>

<s: Body ...>

<wse: Subscribe ...>

<wse: NotifyTo> endpoint-reference </ wse: NotifyTo>

<wse: EndTo> endpoint-reference </ wse: EndTo>?

<wse: Expires> [ xs: dateTime | xs: duration ] </ wse: Expires>?

<wse: Filter Dialect = "xs: anyURI"? > xs: string </ wse: Filter>?

...

</ wse: Subscribe>

</ s: Body>

</ s: Envelope>

For the WS-Eventing: Subscribe message, we can see that it is a WS-Eventing: Subscribe message by looking at the / s: Envelope / s: Header / wsa: Action part.

Whether the received event message is a UPnP GENA message or a WS-Eventing message can be known from the information about the CD acquired in the description step when registering the event for the CD or by analyzing the format of the event message.

The following is the format of UPnP GENA: Notify message and WS-Eventing: Event message.

NOTIFY delivery path HTTP / 1.1

HOST: delivery host: delivery port

CONTENT-TYPE: text / xml

CONTENT-LENGTH: Bytes in body

NT: upnp: event

NTS: upnp: propchange

SID: uuid: subscription-UUID

SEQ : event key

<? xml version = "1.0"?>

< e : propertyset xmlns: e = "urn: schemas-upnp-org : event-1-0 ">

< e : property >

< variableName > new value </ variableName >

</ e : property >

other variable names and values (if any) go here

</ e : propertyset >

In the case of the UPnP GENA: Notify message, the UPnP GENA: Notify message can be seen from the NT (Notification Type) header or NTS (Notification SubType) header value.

(01) <s12: Envelope

(02) xmlns: s12 = 'http: //www.w3.org/2003/05/soap-envelope'

(03) xmlns: wsa = 'http: //schemas.xmlsoap.org/ws/2003/03/addressing'

(04) xmlns: ew = 'http: //www.example.com/warnings'

(05) xmlns: ow = 'http: //www.example.org/oceanwatch'>

(06) <s12: Header>

(07) <wsa: Action>

(08) http://www.example.org/oceanwatch/2003/WindReport

(09) </ wsa: Action>

(10) <wsa: MessageID>

(11) uuid: 568b4ff2-5bc1-4512-957c-0fa545fd8d7f

(12) </ wsa: MessageID>

(13) <wsa: To> http://www.other.example.com/OnStormWarning </ wsa: To>

(14) <ew: MySubscription> 2597 </ ew: MySubscription>

(15) </ s12: Header>

(16) <s12: Body>

(17) <ow: WindReport>

(18) <ow: Date> 030701 </ ow: Date>

(19) <ow: Time> 0041 </ ow: Time>

(20) <ow: Speed> 65 </ ow: Speed>

(21) <ow: Location> BRADENTON BEACH </ ow: Location>

(22) <ow: County> MANATEE </ ow: County>

(23) <ow: State> FL </ ow: State>

(24) <ow: Lat> 2746 </ ow: Lat>

(25) <ow: Long> 8270 </ ow: Long>

(26) <ow: Comments xml: lang = 'en-US'>

(27) WINDS 55 WITH GUSTS TO 65.ROOF TORN OFF BOAT HOUSE. REPORTED

(28) BY STORM SPOTTER. (TBW)

(29) </ ow: Comments>

(30) </ ow: WindReport>

(31) </ s12: Body>

(32) </ s12: Envelope>

For the WS-Eventing: Notification message, the http://www.example.org/oceanwatch/2003/WindReport in the action part indicates what event information is the event message, so the CP knows that the received message is WS-Eventing. . Since the CP specifies the state information of interest when requesting an event registration, the event message can be distinguished in response.

The eventing step provides a mechanism for the CD to deliver its status information to the pre-registered CP in the form of a message. The CP requests an event registration (Subscription) to the CD that wants to know the state change, and when the CD registers it, the CD sends an event message to the registered CPs whenever there is a change in the state. Here, UPnP implements the eventing phase using the GENA protocol and Web services using the WS-Eventing protocol. Accordingly, the UPnP GENA module 353 generates or processes event related messages using the UPnP GENA protocol, and the WS-Eventing module 354 generates or processes event related messages using the WS-Eventing protocol.

7 is a flowchart showing a discovery step in terms of a CD according to an embodiment of the present invention.

During the discovery phase, the CD receives a discovery message from the CP and sends a response message to it, or if it joins the network, multicasts a message indicating its presence, that is, an Alive / Hello message, or removes the device when leaving the network. Multicast the advertised message, the Bye message.

When a CD is newly added to the network, a CD assigned a unique network address provides basic information of the CD by issuing an Alive / Hello command through the discovery interface module 321 to inform its CPs of the same network. (S710). The basic information of a CD includes the URL for the description of the CD, the CD identifier, the type of CD, and the validity of the Alive / Hello message. The discovery implementation module 322 provides information about the CD to the UPnP SSDP module 323 and the WS-Discovery module 324 according to a command received through the discovery interface module 321 (S712). The UPnP SSDP module 323 generates a UPnP SSDP: Alive message and sends it to the multicast channel port (239: 255: 255: 250: 1900), and the WS-Discovery module 324 generates a WS-Discovery: Hello message. A multicast channel port 239: 255: 255: 250: 3702 is transmitted (S714). At this time, According to the application's decision Both UPnP SSDP: Alive and WS-Discovery: Hello messages can be generated and sent, or only one of them can be created and sent.

The CD issues a Bye command through the discovery interface module 321 before leaving the network (S720). The discovery implementation module provides the information of the CD required to generate the Bye message to the UPnP SSDP module 323 and the WS-Discovery module 324 (S722). The UPnP SSDP module 323 generates a UPnP SSDP: ByeBye message and sends it to the multicast channel port (239: 255: 255: 250: 1900), and the WS-Discovery module 324 generates a WS-Discovery: Bye message. A multicast channel port 239: 255: 255: 250: 3702 is transmitted (S714). Even at this time, Both UPnP SSDP: ByeBye message and WS-Discovery: Bye message can be generated and transmitted, or only one of the two messages can be generated and transmitted.

When the CD receives the multicast discovery message from the CP (S730), the corresponding module processes the discovery message according to the reception port and provides necessary information to the discovery implementation module 322 (S732). That is, the message received at the multicast port: 1900 is processed by the UPnP SSDP module 324, and the message received at the multicast port: 3702 is processed by the WS-Discovery module 324. The discovery implementation module 322 transfers the information obtained from the discovery message to the application through the discovery interface module 321 and transmits information necessary for generating a response message based on the CD information provided from the application to the UPnP SSDP module 323 or the WS. -Provided to the discovery module 324 (S736). The UPnP SSDP module 323 and the WS-Discovery module 324 generate a response message corresponding to the discovery message and transmit the generated discovery message to the CP that has transmitted the discovery message (S738).

8 is a flowchart illustrating a discovery step in terms of a CP according to an embodiment of the present invention.

In the discovery phase, the CP receives an Alive / Hello message or a Bye message from the CD, and searches for a CD of interest by multicasting a Search / Probe and Resolution message when participating in the network.

When the Alive / Hello message or the Bye message is received from the CD (S805), the module processes the message according to the receiving port and provides necessary information to the discovery implementation module 322 (S815). The discovery implementation module 322 provides information about the CD to the application through the discovery interface module 321 (S820).

When the CP is newly added to the network, the CP assigned the unique network address issues a search command through the discovery interface module 321 (S825). The discovery implementation module 322 provides the information provided through the discovery interface module 321 to the UPnP SSDP module 323 and the WS-Discovery module 324 (S830). The UPnP SSDP module 323 generates a UPnP SSDP: Search message and sends it to the multicast channel port (239: 255: 255: 250: 1900), and the WS-Discovery module 324 sends a WS-Discovery: Probe / Resolution message. It generates and transmits to the multicast channel ports 239: 255: 255: 250: 3702 (S835). At this time, both the UPnP SSDP: Search message and the WS-Discovery: Probe / Resolution message can be generated and transmitted, or only one of the two messages can be generated and transmitted according to the application's decision. The WS-Discovery: Probe message is used when searching for a service by type, and the WS-Discovery: Resolution message is used when searching for a service by service name.

Since the response message to the discovery message is received by the socket to which the CP transmits the discovery message, the response message may be distinguished whether the response message is a UPnP message or a web service message. On the other hand, as described above may be distinguished by the header information of the response message, or the format of the response message.

The discovery implementation module 322 provides information about the found CD to the application through the discovery interface module 321 (S850).

9 is a flow chart illustrating a description step in terms of a CD according to an embodiment of the invention.

The description step may be referred to as a step in which the CD provides detailed information about a service at the request of a CP. The application developer of the service device transmits information about a service to the description implementation module 332 through the description interface module 331 or references the description implementation module 332.

The CP requests the document by using the HTTP protocol using the location information of the device / service template acquired in the discovery step or the location information of the WSDL document. When the service receives a description request from the CP (S910), the description builder module 335 dynamically uses the information in the description implementation module 332 according to the URL of the description document that receives the request message to dynamically determine the device / service template or WSDL document. To transmit in streaming (S920). In another embodiment, the description builder module 332 may transmit a device / service template or WSDL document stored in a file form according to a request of the CP.

10 is a flowchart illustrating a description step in terms of a CP according to an embodiment of the present invention.

The CP acquires the location information of the description document in the discovery step and requests the description related document from the CD. That is, when the CP issues a description request command through the description interface module 331 (S1010), the description implementation module 332 according to the protocol format included in the CD information acquired in the discovery step may be used for the UPnP module 333 or the WSDL module. In operation 334, the location information of the description document and the like are provided (S1020) to generate and transmit a message requesting the description document (S1030). When the description document is received, the description builder module 335 analyzes the document and provides the document to the UPnP module 333 or the WSDL module 334 (S1040). Selection of the UPnP module 333 or the WSDL module 334 may be determined through the format of the information or description document acquired by the CP in the discovery step. The UPnP module 333 or the WSDL module 334 processes the received document and provides the received document to the description implementation module 332 (S1050). The description implementation module 332 analyzes information about the CD to describe the description interface module 331. Transfer to the application layer through (S1060).

11 is a flow chart showing the eventing step in terms of a CD according to an embodiment of the invention.

In the event of an event, when a CP requests subscription to a service of interest, the service registers and manages the CP in a subscription list. After that, the service sends an event message to the registered CPs when the state changes, and notifies the state change. When the CP makes a registration request, the CP sends the valid time information of the registration request. That is, when the valid time of CP registration elapses, the service no longer transmits an event message to the CP. Therefore, if the CP wants to continue receiving the event message, it revises the validity time by sending a registration renewal message. Meanwhile, when the CP no longer wants to receive an event message from the service, the CP may transmit an unregister message. The middleware device according to the embodiment of the present invention separately manages an event list for UPnP and an event list for web services.

When the service receives an event related message, that is, a registration message, a registration update message, and a registration removal message from the CP (S1110), the interpreter module 355 receives the event related message through a format of an event URL or an event related message. The classified message is classified as a UPnP-GENA message or a WS-Eventing message and transferred to the corresponding module (S1120). The UPnP-GENA module 353 or the WS-Eventing module 354 parses the message and provides necessary information to the eventing implementation module 352 (S1130). Eventing implementation module 352 analyzes the necessary information, and delivers the information about the CP that sent the event-related message through the eventing interface module 351 to the application layer, and corrects the CP-related information managed ( S1140). When the state of the service changes, the UPnP-GENA module 353 or the WS-Eventing module 354 generates and transmits an event message to a CP registered in a separately managed event list (S1150).

12 is a flowchart illustrating an eventing step in terms of a CP according to an embodiment of the present invention.

The CP makes a request for registration or registration update or a registration removal request to the service of interest through the event interface module 351 (S1210). Eventing implementation module 352 receives the registration, registration update, registration removal request and the information about the service through the event interface module 351, the corresponding module, that is, UPnP-GENA module based on the information about the service In operation S1220, information about an event and a request related to events may be transmitted to the WS-Eventing module 354. The UPnP-GENA module 353 or the WS-Eventing module 354 generates and transmits a registration request, registration update request, and registration removal request message (S1230).

When receiving an event message regarding the status of the service from the service (S1240), the interpreter module 355 determines whether the received message is a UPnP-GENA message or a WS-Eventing message and delivers it to the corresponding module (S1250). Whether the received message is a UPnP-GENA message or a WS-Eventing message may be divided into the format of the event message that the CP already knows or receives at the event registration. The UPnP-GENA module 353 or the WS-Eventing module 354 parses the message and provides necessary information to the eventing implementation module 352 (S1260). Eventing implementation module 352 analyzes the necessary information and delivers the information on the status of the service that sent the event through the eventing interface module 351 to the application layer (S1270).

Although embodiments of the present invention have been described above with reference to the accompanying drawings, those skilled in the art to which the present invention pertains may implement the present invention in other specific forms without changing the technical spirit or essential features thereof. I can understand that. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive.

According to the integrated middleware device and method of the present invention as described above has one or more of the following effects.

By providing an integrated middleware device and method, an application developer for a device can implement a service independently of a protocol used in a lower layer.

Claims (15)

An addressing module for assigning a unique network address within a given network; Receiving information about the device through the assigned network address when another device joins or leaves the network, and uses the at least one of a plurality of distributed computing protocols according to the port of the received information. A discovery module for decrypting; And Integrated middleware device supporting a plurality of protocols for distributed computing including a control module for requesting a service from the device based on the decrypted information The method of claim 1, Request detailed information about the device based on the information decrypted by the discovery module, receive the detailed information, and use at least one of a plurality of distributed computing protocols according to the information decrypted by the discovery module Middleware device supporting a plurality of protocols for distributed computing further comprising a description module for decoding the detailed information The method of claim 1, Request detailed information about the device based on the information decrypted by the discovery module, receive the detailed information, and determine at least one protocol among a plurality of distributed computing protocols according to the information included in the received detailed information. Integrated middleware device supporting a plurality of protocols for distributed computing further comprising a description module for decoding the detailed information using The method of claim 2 or 3, Request information about a state change of the device based on the information decrypted by the description module, receive information about the state change, and at least one of a plurality of distributed computing protocols in accordance with the information decrypted by the description module. Integrated middleware device supporting a plurality of protocols for distributed computing further comprising an eventing module for decoding the information on the state change using a single protocol The method of claim 2 or 3, Request information about a state change of the device based on the information decoded by the description module, receive information about the state change, and distribute a plurality of distributions according to information included in the received information about the state change Integrated middleware device supporting a plurality of protocols for distributed computing further comprising an eventing module for decoding the information on the state change using at least one of the computing protocols The method of claim 1, The discovery module Send a message for discovering the other device participating in the network using at least one of a plurality of distributed computing protocols available, receive a response message for the discovery message, and distribute a plurality of distributions according to a socket of the response message Integrated middleware device that supports multiple protocols for distributed computing that decrypts the response message using at least one of the computing protocols The method of claim 1, The discovery module Send a message for discovering the other device participating in the network using at least one of a plurality of distributed computing protocols available, receive a response message to the discovery message, and according to the information contained in the response message An integrated middleware device that supports multiple protocols for distributed computing that decrypts the response message using at least one of the distributed computing protocols of An addressing module for assigning a unique network address within a given network; A discovery module for informing the other device in the network by using at least one of a plurality of distributed computing protocols that can be provided when the user joins or leaves the network; And An integrated middleware device supporting a plurality of protocols for distributed computing, including a control module for receiving a service request based on the information from the device and transmitting a service performance result according to the service request to the device. The method of claim 8, And a description module for receiving detailed information based on the information from the device and transmitting the detailed information using at least one of a plurality of distributed computing protocols according to the URL of the request. Integrated middleware devices that support the protocol The method of claim 9, Receiving information about a state change based on the detailed information from the device, decrypting the request using at least one of a plurality of distributed computing protocols according to the URL of the request, and generating a plurality of information according to the decrypted information. Integrated middleware device supporting a plurality of protocols for distributed computing further comprising an eventing module for transmitting the information on the state change to the requesting device using at least one of the distributed computing protocols The method of claim 9, Receiving information about a state change based on the detailed information from the device, decrypting the request using at least one of a plurality of distributed computing protocols according to a format of the request, and generating a plurality of information according to the decrypted information. Integrated middleware device supporting a plurality of protocols for distributed computing further comprising an eventing module for transmitting the information on the state change to the requesting device using at least one of the distributed computing protocols The method of claim 8, The discovery module Receive a message searching for itself from the device, decrypt the discovery message using at least one of a plurality of distributed computing protocols according to a port of the received discovery message, and distribute a plurality of distributed according to the decrypted information Integrated middleware device that supports multiple protocols for distributed computing that transmits its information to the device using at least one of the computing protocols Assigning a unique network address within a given network; Receiving information about the device through the assigned network address when another device joins or leaves the network, and uses the at least one of a plurality of distributed computing protocols according to the port of the received information. Decrypting; And Requesting a service from the device based on the decrypted information; and supporting a plurality of protocols for distributed computing. Assigning a unique network address within a given network; Informing the other device in the network by using at least one of a plurality of distributed computing protocols that can be provided when the user joins or leaves the network through the assigned network address; And Receiving a service request based on the information from the device and transmitting a service performance result according to the service request to the device. Record carrier recording a program for performing the method according to any one of claims 13 and 14

Images