Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
FIWARE Global Summit - A Multi-database Plugin for the Orion FIWARE Context Broker
1. Scale Up for a Real Smart Future
Berlin, Germany
23-24 October, 2019
A Multi-database Plugin for the Orion
FIWARE Context Broker
Anurag Vashisth (Technical Specialist,
NEC Technologies India Pvt Ltd.)
2. A Multi-database Plugin for the Orion FIWARE Context Broker
2
Ø Background: Fiware Orion
Ø Motivation
Ø Multiple database support idea
Ø High level approach to support other databases
Ø Implementation approach: Git submodules for database plugins
Ø Database Plugin layer and North/South bound interface
Ø Low level architecture: Proposed to support Multiple DB
Ø Low level architecture: For MySQL Database plugin
Ø MySQL Database: NoSQL JSON collection
Ø MySQL Database plugin: Connector C++
Ø MySQL Database plugin: CRUD Operations Overview
Ø MySQL Database plugin: Database Object Classes
Ø Overview of files modified for implementation
Ø Data in MySQL database by Create Entity API
Ø Challenges
3. Background: Fiware Orion
• Fiware Orion is a C++ implementation of the NGSI9/10 REST API binding developed as a part of the
FIWARE platform.
• Orion Context Broker allows to manage all the whole lifecycle of context information including updates,
queries, registrations and subscriptions.
• Fiware Orion context broker acts as a central component to any smart solution.
• In any smart solution, we’ve some components which are generating the context data and some are
consuming the generated information.
4. Motivation
Currently FIWARE Orion supports MongoDB only and it’d be great if other databases are supported. This will bring the following opportunities:
§ The database could be given as a choice to the business, it will allow to use an existing database of the solution. So if Orion will support
multiple database or able to communicate with other database directly, it will ease the integration of Fiware framework with other framework or
platforms.
§ Time/performance
• Time saving to convert by the pipeline of format conversion via Cygnus.
• Consumer application can directly communicate with Orion if database is same.
5. Multiple database support idea
§ As shown in past slides, Orion, support only MongoDB as a native database to keep
only the latest context information. However it may be needed to support multiple
databases, a high level approach is shown below:
Context Broker
Database-1
Context Provider
1026
Database-2 Database-n
Applications Subscribers
6. High level approach to support other databases
§ The high level idea to support other databases is shown below:
§ We need to develop a generic ‘DB I/F layer’ in Orion using which other databases
could be integrated as shown in below picture:
Backend layer (Database connector/s)
“DB I/F layer”
MongoBackend
Context Broker (Core context function)
MySQLBackend Other DB
MongoDB MySQL DB Other DB
7. Implementation approach: Git submodules for database plugins
§ We use the git submodule feature and create a soft link for each type of database
connector layer(library to access the DB). In this we will create new repository for
each type of database and link it with the main repository.
Reference: https://git-scm.com/book/en/v2/Git-Tools-Submodules
§ The main project would remain Orion.
• Submodule1 may refer to support of MySQL
• Submodule2 may refer to other database and so on…
8. Database Plugin layer and North/South bound interface
§ There would be no change
in North bound / South
bound interface, a common
database backend layer
would be inserted to handle
to desired database.
9. Low level architecture: Proposed to support Multiple DB
Database connector
REST
Database
JSON PARSER
mongoBackend mysqlBackendpostgresBackend
Backend Selection
layer based on
configuration provided
by user.
In Fiware/Orion github repo we
have submodules which is acts as
a folder in it. We have to add
submodule or backend code
based on the requirement.
Service Routine
(Generic DB I/F layer)
10. Low level architecture: For MySQL Database plugin
Rest(libmicrohttpd)
Incoming HTTP Request
JSON parse library
ServiceRoutines
MySQL Connector for C++
MySQL DB
ConnectionTreat()
Document Store
This connector
would be used to
talk to MySQL DB
11. MySQL Database: NoSQL JSON collection
§ MySQL can act as a NoSQL JSON Document Store so programmers can save data
without having to normalize data, set up schemas, or even have a clue what their
data looks like before starting to code. NoSQL + SQL = MySQL
JSON Binary Format
12. MySQL Database plugin: Connector C++
§ MySQL Connector/C++ 8.0 is a MySQL database connector for C++ applications that
connect to MySQL servers. Connector/C++ can be used to access MySQL servers
that implement a document store, or in a traditional way using SQL queries. It
enables development of C++ applications using X DevAPI, or plain C applications
using X DevAPI for C.
13. MySQL Database plugin: CRUD Operations Overview
§ CRUD operations are available as methods, which operate on Schema objects. The
available Schema objects consist of Collection objects containing Documents, or
Table objects consisting of rows and Collections containing Documents.
Operation Document Relational
Create Collection.add() Table.insert()
Read Collection.find() Table.select()
Update Collection.modify() Table.update()
Delete Collection.remove() Table.delete()
14. MySQL Database plugin: Database Object Classes
§ The following figure shows database object class diagram. We’re using ‘Collection’
methods for this purpose.
16. Data in MySQL database(Document Store) by Create Entity API
17. Challenges
§ A new layer would need to be developed to choose among the databases.
§ The technical challenge is to support the C++11 and interworking with legacy(C++98)
C++ code.
§ There were run-time size issues of linking the MySQL connector library as static and
Dynamic. We later used the dynamic library type.
§ There is a thread on Fiware Orion community:
• https://github.com/telefonicaid/fiware-orion/issues/3132
• It discusses that MongoBackend code is legacy driver and there are usage issues in
MongoDB version > 3.4