search

reTHINK-project / core-framework

The main goal of WP3 is to provide the reTHINK core framework comprised by the runtime environment where Hyperties are executed and the messaging nodes used to support messages exchange between Hyperties.
Apache License 2.0
1 stars 0 forks source link

Publish Data in the Catalogue Runtime #158

Closed pchainho closed 8 years ago

pchainho commented 8 years ago

How to publish data (eg hyperty descriptors and data schemas) in the catalogue?

emmelmann-fokus commented 8 years ago

A catalogue (internally !) is split in two functional components. a) a catalogue broker and b) a catalogue database.

Several catalogue databases may connect to one catalogue broker. So in order to get your objects in the catalogue, you will run your catalogue database implementation / the corresponding dockerized image.

Please see https://github.com/reTHINK-project/dev-catalogue

pchainho commented 8 years ago

Sorry, but I couldn't see the procedure for this data publish in the https://github.com/reTHINK-project/dev-catalogue: could you be more precise?

emmelmann-fokus commented 8 years ago

Sure:

Catalogue Database

To run the catalogue database, you have to provide IP and port of the southbound coap interface of the catalogue broker (which is on port 5683 by default).

Synopsis:

java -jar rethink-catalogue-database-*-jar-with-dependencies.jar serverIP serverPort [ObjectsPath]

Example:

java -jar catalogue_database/target/rethink-catalogue-database-0.1-jar-with-dependencies.jar localhost 6683 catalogue_objects

Using custom hyperties/protostubs

In order to include your own hyperties/protostubs in the database, you can specify a folder path as an argument when running the database. The hyperties/protostubs inside that folder will be parsed on start. Please view the provided examples inside the catalogue_objects folder, to see the formatting.

A Hyperty descriptor is defined in a file with the ending ".hyperty", while protostubs have the ending ".stub". If your javascript code is contained in a seperate file, it needs to have the same filename as the hyperty descriptor it belongs to (excluding file extension), in order to be included in the sourcePackage. Example:

"SecondHyperty.hyperty" is the descriptor for a hyperty. It contains a sourcePackage, but that is missing the sourceCode field. The source code that belongs to it, is contained in a file called "SecondHyperty.js". If the hyperty descriptor file contains a sourcePackage, the contents of "SecondHyperty.js" is read and added as sourceCode to the sourcePackage.

pchainho commented 8 years ago

thx for the detailed explanation. However, I understand this means you have to restart the database when you have to add, remove or update some Hyperty or Stub descriptor, right?

emmelmann-fokus commented 8 years ago

As of now, yes.

We can discuss for a later phase, if this needs to be changed or if a trigger should be provided that causes during execution to re-read the data.

I'm not reluctant to discussing this feature but let's focus for the ongoing phases to urgent open issues. Catalogue wise, we have a stable implementation of the existing features that would well suit a hackatron and the first review.

Also note, that from the user side (who is interacting via the broker), the user would hardly notice as only one (of potentially several) databases would have to be restarted. Most of the information stored in the catalogue would be seamlessly accessible even while one single database restarts.