KR20190069284A - Method of converting and interworking ocf resourse of internet service, and an apparatus performing the same - Google Patents

Abstract

Disclosed are a method for converting and interlocking an OCF resource of an internet service, and an apparatus performing the same. According to one embodiment of the present invention, the method for converting and interlocking an OCF resource comprises the steps of: receiving a request message from an OCF client device; retrieving a URI of an API of a Non-OCF Internet Service corresponding to a virtual resource included in the request message using a URI mapping table; obtaining a query and response corresponding to the request message from the non-OCF internet service by using the retrieved URI; and converting the query and response into an OCF response message and sending the OCF response message to the OCF client device.

Description

Technical Field [0001] The present invention relates to an OCF resource conversion and interworking method for an Internet service, and a device performing the OCF resource conversion and interworking method.

The following embodiments relate to an OCF resource conversion and interworking method for an Internet service, and an apparatus for performing the OCF resource conversion and interworking method.

Currently, there are platforms / frameworks that support various objects internet on the market. Each platform is competing to gain market dominance with its own advantages. Among them, the Open Connectivity Foundation (OCF) is led by Samsung and Intel, and various companies are participating to create related standards, and at the same time, they are working on an open source project (IoTivity) that implements standards.

IoTivity is an IoT open source framework that implements the OCF standard and aims to support connections between devices independently of various operating systems and communication protocols. IoTivity framework is divided into rich device or lite device depending on device type / performance. For devices with limited capabilities (eg, Arduino), only the core is loaded and only the core API is provided in C. On the other hand, the rich device provides a service API provided in C ++ / Java in addition to the core API. This service API makes it easier for users to develop applications.

Nowadays, companies such as many IT-related services and public institutions are able to use external services provided by external organizations in the form of open APIs. A typical example is a Google map, a portal site, or a weather channel. The agency provides a URL that can use the provided API, and the user calls the API provided by the agency in a RESTful manner.

Embodiments can provide an OCF resource by using an RESTful API description language (RAML, Swagger), a data modeling notation, or the like, and provide a technology for an OCF client to interact with an Internet service through the OCF resource.

The OCF resource conversion and interworking method according to an exemplary embodiment includes receiving a request message from an OCF client apparatus, receiving a URI of an API of a non-OCF Internet service corresponding to a virtual resource included in the request message using a URI mapping table, Acquiring a query response corresponding to the request message from the non-OCF Internet service using the retrieved URI; converting the query response into an OCF response message and transmitting the query response to the OCF client device; .

1 shows a functional block structure of an OCF framework.
2 shows an example of the resources of the OCF.
3 shows the structure of IoTivity.
FIG. 4 shows an example of an API calling method for using the weather service among Internet services.
5 is a schematic block diagram of a system for performing an OCF resource conversion and interworking method of an Internet service according to an exemplary embodiment.
6 is a diagram for explaining the Create operation during the CROUND operation.
7 is a diagram for explaining the Retrieve, Update, and Delete operations during the CROUND operation.
8 is a diagram for explaining the Notify operation during the CROUND operation.
9 is a schematic block diagram of the OCF server apparatus shown in FIG.

In the following, embodiments will be described in detail with reference to the accompanying drawings. However, various modifications may be made in the embodiments, and the scope of the patent application is not limited or limited by these embodiments. It is to be understood that all changes, equivalents, and alternatives to the embodiments are included in the scope of the right.

The terms used in the examples are used for descriptive purposes only and are not to be construed as limiting. The singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, the terms "comprises" or "having" and the like refer to the presence of stated features, integers, steps, operations, elements, components, or combinations thereof, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

The terms first, second, or the like may be used to describe various elements, but the elements should not be limited by terms. The terms may be named for the purpose of distinguishing one element from another, for example, without departing from the scope of the right according to the concept of the embodiment, the first element being referred to as the second element, The second component may also be referred to as a first component.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this embodiment belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Do not.

In the following description of the present invention with reference to the accompanying drawings, the same components are denoted by the same reference numerals regardless of the reference numerals, and redundant explanations thereof will be omitted. In the following description of the embodiments, a detailed description of related arts will be omitted if it is determined that the gist of the embodiments may be unnecessarily blurred.

Providers providing IT-related services are allowed to use services provided by providers from outside in the form of open APIs. The provider provides a URL that can use the provided API, and the user calls the API provided by the provider in a RESTful manner. In the present specification, this service is referred to as " Internet service ". The Internet service provides a URL that can call the API, and it delivers four commands (CRUD (Create, Retrieve, Update, Delete)) used in the RESTful method to the URL using a method supported by HTTP.

The following describes the Open Connectivity Foundation (OCF) and the IoTivity framework.

1 shows a functional block structure of an OCF framework.

In OCF, each object in physical world constituting IoT is managed as a resource model. In addition, interaction between objects is achieved through operation that satisfies RESTful method based on resource model. RESTful operations are Create, Retrieve, Update, Delete, Notify? CRUDN? Respectively.

2 shows an example of the resources of the OCF.

OCF is an ecosystem for IoT. OCF manages the physical and logical objects constituting the IoT ecosystem as resources. As shown in FIG. 2, a resource in the OCF is usually composed of a "resource URI" and an "attribute". In Fig. 2, the resource URI is " / room / temperature ", and the content enclosed between {} is an attribute. The attribute is of the form "name": "value". In FIG. 2, this corresponds to a resource indicating a temperature which is a logical data.

3 shows the structure of IoTivity.

In OCF, communication subjects include Client, Server, and Bridge. A client is the subject that initiates communication in a RESTful operation, and is the subject that responds to the communication initiated by the Server: client. Bridge is a function / device that allows OCF devices to communicate with non-OCF devices in OCF.

The communication procedure between OCF client / server in OCT framework can be divided into two categories of OCF Resource Discovery and Resource Manipulation.

The OCF Resource Discovery procedure is as follows.

Before starting communication, OCF client performs OCF Resource discovery procedure if it does not know information about server. There are two types of resource discovery: CoAP discovery and HTTP discovery. The present invention deals only with CoAP based resource discovery. CoAP based resource discovery is handled in such a way that a discovery request packet is forwarded to a promised multicast address and port and the response (s) sent by the devices joined to the multicast address are received . All OCF nodes must join this multicast address by default.

The Resource Manipulation procedure is as follows.

If the OCF client finds information about the server through resource discovery or through another path, the client performs operations on the server's resources through the CRUDN operation.

FIG. 3 shows the IoTivity framework. IoTivity uses the Constrained Application Protocol (CoAP, RFC7252), established by the IETF as a transport protocol. CoAP is a transport protocol designed for devices with limited capabilities (Constrained Devices).

The Internet service is described below.

FIG. 4 shows an example of an API calling method for using the weather service among Internet services.

Most Internet services provide a URL to call the API. The four commands (CRUD (Create, Retrieve, Update, Delete)) used by RESTful method for this URL and the methods supported by HTTP are shown in Table 1.

Currently the resources defined in OCF are targeted to physical objects or logical data. However, if you extend this definition further, services that are provided on the Internet, such as open APIs, can also be used as resources.

In the embodiment, an Internet service is converted into an OCF resource using a RESTful API description language (RAML, Swagger) and a data modeling notation, and the OCF client can provide a method of interworking with the Internet service through the resource. Hereinafter, embodiments will be described in detail.

5 is a schematic block diagram of a system for performing an OCF resource conversion and interworking method of an Internet service according to an exemplary embodiment.

Referring to FIG. 5, the service interworking system 10 includes an OCF client apparatus 100, an OCF server apparatus 200, and an Internet service 300.

The OCF server apparatus 200 is an OCF bridge apparatus for interworking between the non-OCF apparatus 200 and the OCF client apparatus 100.

The OCF server apparatus 200 performs the OCF resource conversion operation of the Internet service 300 and performs the OCF resource discovery and resource operation operation (CRUDN) requested from the OCF client apparatus 100 using the OCF resourceized Internet service Can be performed.

The OCF resource conversion of the Internet service is as follows.

(1) The OCF server apparatus 200 may create a data model schema (schema) 210 for the OCF resource in order to make the Internet service 300 an OCF resource, and store the created data model schema in the database 220. For example, a schema description language can use JSON.

At this time, the OCF server apparatus 200 can read the data model schema 210 for the Internet service 300 at the boot time or via an external command, and convert the data model schema 210 into the OCF resource 230. The generated OCF resource 230 for the Internet service 300 can be provided by the OCF server apparatus 200 to the OCF client apparatus 100 in the same form as the OCF resource representing the IoT objects 400 . In addition, the OCF resource 230 may be stored in the database 270 together with the OCF resource representing the IoT objects 400. Resources created on the basis of Internet services can be referred to as virtual resources.

(2) The OCF server 200 can store RESTful API information (or RESTful API description) 240 for the virtual resource 230 based on the Internet service 300 in the database 250. For example, the API description language can use RAML or Swagger.

Among the contents of the RESTful API description 240 for the Internet service 300, the resource URI includes URL information of the Internet service API to connect to the actual Internet service and retrieve the result value provided by the service. In order for the OCF client apparatus 100 to later obtain the actual result value from the Internet service 300 through the virtual resource 230, mapping information between the URI of the OCF virtual resource 230 and the API URI of the Internet service 300 Lt; / RTI > The OCF server apparatus 200 may store the URI mapping table in the database 250, and the URI mapping table may be as shown in Table 2 below.

OCF Resource Discovery is:

When the OCF client apparatus 100 performs a resource discovery operation (that is, when the OCF client apparatus 100 requests resource discovery to the OCF server apparatus 200), the OCF server apparatus 200 transmits the IoT objects 400, To the OCF client apparatus 100, a result including both the OCF resource representing the virtual resource 230 and the virtual resource 230 generated based on the Internet service 300.

The resource manipulation operation (CRUDN) is as follows.

When the OCF client apparatus 100 performs a CRUDN operation on the virtual resource 230 for the Internet service 300 returned from the OCF server apparatus 200 (that is, when the OCF client apparatus 100 performs a resource operation operation (CRUDN ) To the OCF server apparatus 200), the OCF server apparatus 200 searches the RESTful API information 240 for the Internet service 300 corresponding to the virtual resource 230 based on the URI mapping information And performs processing for individual CRUDN operations (Create, Retrieve, Update, Delete, Notify) (250).

6 is a diagram for explaining the Create operation during the CROUND operation.

Referring to FIG. 6, a virtual resource for the Internet service 300 may be created when the OCF server 200 is booted. Therefore, the Create operation may not be used.

7 is a diagram for explaining the Retrieve, Update, and Delete operations during the CROUND operation.

Referring to FIG. 7, the Retrieve, Update, and Delete operations may be performed in the same procedure.

1) The OCF client apparatus 100 may transmit a Retrieve / Update / Delete request message to the OCF server apparatus 200.

2) The OCF server apparatus 200 can search (or find) the URL corresponding to the API call of the Internet service 300 by searching the URI mapping table.

3) The OCF server device 200 may generate a query suitable for the Internet service 300 using the RESTful API description.

4) The OCF server device 200 may send a query to the Internet service 300.

5) The OCF server device 200 may receive a query response from the Internet service 300. [

6) The OCF server apparatus 200 can convert a query response into an OCF response message.

7) The OCF server apparatus 200 may return (or transmit) the OCF response message to the OCF client apparatus 100. [

8 is a diagram for explaining the Notify operation during the CROUND operation.

Referring to FIG. 8, the Notify operation is not normally provided by the Internet service, but a corresponding procedure may be performed in the OCF server apparatus 200.

1) The OCF client apparatus 100 may transmit a Notify request message to the OCF server apparatus 200.

2) The OCF server apparatus 200 can search (or find) the URL corresponding to the API call of the Internet service 300 by searching the URI mapping table. 3) The OCF server device 200 may generate a query suitable for the Internet service 300 using the RESTful API description.

4) The OCF server apparatus 200 checks the notification condition and if it satisfies the condition, it can generate and transmit the query to the Internet service 300.

5) The OCF server apparatus 200 can receive a query response, that is, a result value, from the Internet service 300.

6) The OCF server apparatus 200 can convert a query response into an OCF response message.

7) The OCF server apparatus 200 may return (or transmit) the OCF response message to the OCF client apparatus 100. [

4) to 7) can be repeatedly performed.

9 is a schematic block diagram of the OCF server apparatus shown in FIG.

Referring to FIG. 9, the OCF server apparatus 200 includes a controller 280 and a database 290.

The controller 280 can perform the OCF resource conversion operation and the interworking method of the Internet service in the OCF server apparatus 200 described with reference to FIGS.

The database 290 may include the databases 220, 250, and 270 of FIG.

The operation of the controller 280 and the database 290 may be substantially the same as the operations for the OCF resource conversion operation and the interworking method of the Internet service described with reference to FIGS. Therefore, a detailed description thereof will be omitted.

As described above, the embodiments can be utilized in the same manner as that of communicating with other objects in the OCF ecosystem by converting various Internet services existing on the Internet into OCF resources.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

The software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded. The software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device , Or may be permanently or temporarily embodied in a transmitted signal wave. The software may be distributed over a networked computer system and stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

Although the embodiments have been described with reference to the drawings, various technical modifications and variations may be applied to those skilled in the art. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI > or equivalents, even if it is replaced or replaced.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (1)

Receiving a request message from an OCF client device;
Retrieving a URI of an API of a non-OCF Internet service corresponding to a virtual resource included in the request message using a URI mapping table;
Obtaining a query response corresponding to the request message from the non-OCF Internet service using the retrieved URI; And
Converting the query response into an OCF response message and transmitting the converted OCF response message to the OCF client device
And an OCF resource conversion and interworking method.

Images