Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

JNoSQL

The JNoSQL is a several tool to make easy integration between the Java Application with the NoSQL. JNoSQL has a standard API. However, NoSQL has a diversity even when both are the same type. Eg. two column family databases, HBase and Cassandra, they have particular behavior and resource that make their individual such as Cassandra Query Language and consistency level that just does exist on Cassandra. So the API must be extensive and configurable to have support also to a specific database. To solve this problem the project gonna have two layers:


Communication API: An API just to communicate with the database, exactly what JDBC does to SQL. This API is going to have four specializations, one for each kind of database.


Abstraction API: An API to do integration and do the best integration with the Java developer. That is going to be annotation drive and going to have integration with other technologies like Bean Validation, etc.


Diana

Duke-diana-min.png

The Diana Project has a goal do the low-level API, in other words, communicate with the NoSQL databases. This project is going to work as a driver to NOSQL databases. At overall it has four APIs inside, one for each NoSQL kind, beyond it own TCK. A test compatibility kit, the TCK, are a test group that makes sure if an A NoSQL database does support a database, e.g., If A key value database wants to prove its database has Diana support.
So even Diana does not do the abstraction level, supports to make the developer life easier, it makes easier integration with frameworks that do this.
Diana is valuable also alone when a developer what to use just the communication layer, that is going to easier to change to another database of the same type.


Artemis

Duke-artemis-min.png


Artemis is the integration and abstract layer, in other words, it takes the communication level, Diana, and it does integration with others technologies such as Bean Validation and also with an entity model. It has a CDI engine; its formula is simple:
Diana plus CDI equals to Artemis.

Artemis-integration.png


As Diana have, Artemis also has an API to each database flavor. Using CDI as the engine, each component is configurable, and it has features such as:

  • Persist an object through annotation
  • Make replaceable any component (reflections, entity conversions, cache, persistence lifecycle and more).
  • Observer event a continued existence database lifecycle (each databases kind has an individual event).
  • An important point about CDI events is how easy is create and add new functionalities without change the core code. That is easy to use bean validation just listen to an event.


References

Back to the top