JNoSQL/Q&A

Question and Answer

What is JNoSQL?

JNoSQL is a framework to help the Java EE user to use NoSQL technology so they can enjoy polyglot persistence in Java Enterprise Edition platform.

How JNoSQL solve this issue?

JNoSQL has two layers a communication, to connect NoSQL to Java, and mapping layer, an easier integration that abstract the Java model and communication layer:

• 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.
  • The Communication layer has the aka Diana
  • Diana has an API to each NoSQL type.
  • Each API brand has a TCK.
  • A Technology Compatibility Kit (TCK) is a suite of tests that at least nominally checks a particular alleged implementation of a NoSQL vendor for compliance.

• Mapping 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.
  • The Mapping layer has the aka Artemis
  • Artemis has Commons annotations
  • Artemis is a JPA API to NoSQL database
  • Artemis is a parser to communication layer

What is the goal to JNoSQL?

To create a standard to NoSQL technology with Java EE as a JSR within a JCP Process. You can access the JSR Proposal here: https://goo.gl/MBdtNP

• A brief about JCP

Why does not make the NoSQL connection with JPA?

JPA has the duty to do a mapping API to make a connection between Java Model and SQL database. The relational database has a particular behavior that does not belong to NoSQL technology such as transaction, SQL based, ACID; there is just one branch instead of four as NoSQL databases. So different technology results in a different standard. Nonetheless, the JNoSQL tries to keep the JPA nomenclature.

Communication Layer

Should a NoSQL vendor implement all types?

No, the project works as a module, in other words, you can apply just one API, e.g. Document, without a care about other ones, e.g. Key-Value API. However, if a vendor is a multi-model, the database should implement its specifics type, eg: Couchbase implements both key-value and document.