WO2003107596A1

WO2003107596A1 - Method for creating a bridge between jini and upnp subnetworks and system for implementing said method

Info

Publication number: WO2003107596A1
Application number: PCT/DE2003/001876
Authority: WO
Inventors: Igor Jovanovski; Jochen Sauter
Original assignee: Siemens Aktiengesellschaft
Priority date: 2002-06-13
Filing date: 2003-06-03
Publication date: 2003-12-24

Abstract

The invention relates to a separate entity (JUB) in the network, which is designated as a bridge and translates between Jini and UPnP protocols. Said bridge presents each available UPnP network service (US) as a Jini service (JS) and vice versa each Jini service (JS) as a UPnP service (US). The Jini client (JC) sees all UPnP services (US) as real Jini services (JS) and vice versa. This reduces costs and prevents problems resulting from hardware restrictions.

Description

description

A bridging method of Jini and UPnP subnetworks and arrangements for implementing this method

The invention relates to a method and arrangements for bridging between a UPnP sub-network and a further part of the network.

Such methods and arrangements are known from the European patent application EP 1058422 Al. Here, a home audio video interoperability (HAVi) -Teilnetz over a bridge with a Universal Plug and Play (UPnP) -Teilnetz is connected.

Jini and Universal Plug and Play are two competing technologies that allow spontaneous networking of devices and services. However, there are many user devices that support only one of the two technologies, and it is not directly possible currently to UPnP services of Jini supported users (clients) access terminals or vice versa.

A device (device) with a UPnP proxy and a JINI proxy for the treatment of service calls from users would lead a much larger development effort for the manufacturer of the equipment and higher costs.

The other option (the User Device) to equip the user with Jini and UPnP, is due to

Hardware limitations on the user side is not always feasible. As needed, for example Jini significant computing and storage capacity and therefore can not currently run on small devices such as PDAs and smartphones. Which the object underlying the invention now is to provide devices and arrangements, which can be accessed while avoiding the disadvantages mentioned above in JINI-supported networks to UPnP devices and services or in UPnP supported networks on JINI facilities or services.

Dies'e object is achieved as regards the method by the features of claim 1.

The subclaims relate to preferred embodiments of the inventive method and arrangements for implementing this method.

The invention relates generally to a separate entity on the network, which is referred to as a bridge and translates between UPnP and Jini protocols. This bridge represents each available UPnP network service as a Jini service or in the other direction, a Jini service as a UPnP service. Here the JINI user sees all UPnP services as real JINI services and just in reverse Direction.

The invention is explained in more detail below based on illustrated in the drawings embodiments. Here shows

Figure 1 is a schematic diagram of a JINI UPnP bridge between users and service providers,

2 shows a block diagram of such a bridge, and

Figure 3 is a diagram showing an access from a UPnP-enabled user unit to a Jini service. Additional information concerning these two architectures UPnP and JINI themselves are, for example, on the corresponding website http: // www. sun.com/jini/specs/index.html, especially "Jini ™ Device Architecture Specification", or http: //www.UPnP.org/download/UpnPDAlO_20000613.htm available.

1 shows a JINI UPnP Bridge JUB is shown to access the JINI user JC and / or UPnP user UC and which in turn accesses JINI services and UPnP services JS US.

2 shows a basic block diagram of such a JINI UPnP bridge is shown, a bridge management unit BMF and other bridge elements Bl, B2 ... special standardized services, such as print services, and a general bridge element Bl for services which are not standardized. This bridge elements each contain two separate translation programs (plugins) J2U for translations of Jini for UPnP and a program U2J for translations of UPnP by Jini.

The bridge management unit BMF provides an apparatus or a service in a respective other user different from the power network by a syntactic selection criterion established and announces a corresponding service in the respective user part mains. Further, the bridge management unit BMF forms a runtime environment for at least a separate translation program (plug-in) or U2J J2U a respective bridge element Bl ... Bn.

The stand-alone translation program for translating U2J UPnP by JINI disassembled or parses the interface description of the UPnP service and generates a new Jini interface, which contains methods for each action of the UPnP service. Because UPnP supported mainly action parameter of primitive data types and a few complex types that can be expressed as a string value, a mapping of the UPnP action parameters on JINI method parameter is relatively straightforward.

In the case of stand-alone translation program J2U for translations of Jini for UPnP the matter is more difficult, because a JINI interface can optionally complex data types, so have the method parameters, all of which are expressed as Java classes. These classes may in turn use complex class types for fields and methodological parameters themselves. In most cases, the UPnP there will be no direct mapping to one or a few data types supported. With the help of the inventive method the corresponding Java class is recursively for their fields and methods using the Java Reflection API, scanned (introspected) for each non-primitive parameters of a Jini method. Based on this structural information, a UPnP action for each method as well as for each constructor of Java classes generated. The recursion proceeds until methods to achieve contained only primitive parameters or not primitive parameters that have already been studied and recursively already mapped to UPnP actions. In order can be used to map a certain JINI method to a UPnP action called UPnP relief efforts to build step by step UPnP Actions higher order up to the top of the Rekursionshierarchie plane, then the UPnP action at the highest level the callable JINI method represents.

To support such a hierarchical structure of higher order a UPnP Action, in an advantageous embodiment of the arrangement for implementing the method according to the invention, a parameter stack may be present, which holds the necessary at each stage of the building process of the UPnP actions parameters. To illustrate the dynamic behavior of such an arrangement is shown in Figure 3 an example of a control sequence (Flow of Control) is shown for a given Jini Printer Service accessed from a UPnP-user (client).

In Figure 3 this, the services JIN -Printerservice JPS and JINI lookup service JLS, the JINI UPnP Bridge JUB and the user UPnP client UC are shown, wherein the service with the service JPS JLS, the service with the bridge JLS JUB and the bridge JUB with the user UC is connected.

The service JPS registered at the entrance to a signal reg at a nearest service JLS, which is a mandatory present in each Jini network directory service. The bridge management unit BMF continuously tracks all offered by the Jini network services and asks a query 1, the newly announced services from. In this way will be found from the bridge JUB or from the bridge management unit BMF new JINI Printer Service. Then the corresponding stand-alone translation program J2U the bridge part Bl is loaded into the bridge management unit BMF, with this advertising itself through an announcement as a UPnP service to the user UC. A UPnP users can now find this service to retrieve its description and a corresponding service request sl to the bridge JUB or to the translation program J2U the bridge unit Bl send. The service request sl is mapped by the translation program J2U on a service request to s2 Jini service. It is now each result r2, for example, a status message indicating that the print job is transmitted to the printer translated back through the stand-alone program U2J of the bridge portion Bl in a response to the UPnP rl user.

Claims

claims

1. A method for bridging between Jini and UPnP subnetworks, wherein in accordance with a selection criterion of a bridge management unit (BMF) at least one UPnP device and / or at least one UPnP service (US) is determined in a UPnP sub-network and in which the at least one detected UPnP device and / or the at least one detected UPnP service over the bridge management unit (BMF) as a Jini device and / or a JINI-service (JS) is announced.

2. The method of claim 1, wherein the bridge management unit a runtime environment for at least a separate translation program (PI, U2J) for translating requests (sl) and results (rl) forming at least one device and / or the at least one service.

3. The method of claim 2, wherein the at least one independent

Translation program disassembled an interface description of a UPnP service and creates a new JINI interface that includes a corresponding method for each action of the UPnP service.

4. A method for bridging between Jini and UPnP subnetworks, wherein in accordance with a selection criterion of a bridge management unit (BMF) at least one Jini device and / or at least one Jini service (JS) in a JINI sub-network is detected and in which the detected JINI device and / or the detected Jini service over the bridge management unit as a UPnP device and / or a UPnP service (US) is announced.

5. The method of claim 4, wherein the bridge management unit forms a runtime environment for at least a separate translation program (PI, J2U) to translate requirements and results of the devices and / or services.

6. The method of claim 4, wherein the at least one independent

Translation program for each non-primitive parameters of a JINI method searches the corresponding Java class (introspected) until only primitive parameters and / or non-primitive parameters that are already assigned to UPnP actions occur, thereby gaining a structural information and the information from the structure, and the primitive parameters and / or the non-primitive parameters which are already assigned to UPnP actions, as long as UPnP actions higher order are formed until the current UPnP action of the respective JINI method corresponds.

7. An arrangement for bridging between Jini and UPnP subnetworks that implements a method according to any one of the preceding claims.

8. An arrangement for bridging between Jini and UPnP subnetworks that implements a method according to claim 6 in which a stack (UST) for UPnP actions is available.