JNoSQL in MicroProfile?

[Kevin Sutter]

Hi,
I know that we briefly discussed a persistence feature way back when we started MicroProfile.  At that time, we had talked about JPA, but decided that maybe relational databases were not the proper choice for cloud native microservice applications.

We also briefly discussed NoSQL databases, but which one would we choose?  There wasn't a standard defined and if we chose the "wrong one", then it could limit our applicability.

Recently, I've been re-introduced to JNoSQL.  This is not a standard, per se.  But, it is getting quite a bit of attention.  JNoSQL provides a programming model abstraction for NoSQL databases.  So, we wouldn't be tied to just MongoDB or CouchDB or whatever.  It provides both the basic communication mechanism as well as Java object mapping capabilities.

I'm not an expert, nor do I work with this group.  It just seems like a nice fit if we're interested in providing a persistence component for MicroProfile.  Before we take this too much further, I thought I would start the conversation here and see what the wider team thinks.

Thanks,
Kevin

[John D. Ament]

At one point, Otavio had indicated to me he was actually demoing JNoSQL on Hammock, since he didn't require a full runtime to work.  So I believe the technology still works together, but I personally haven't tested it.  I have personally tested and demo'd Hibernate OGM on Hammock via DeltaSpike's repositories, that was working as well.  I think it would be good to standardize on a concrete API for working with No SQL stores, but almost wonder if it makes sense to just wait a few weeks for EE4J to solidify to see if it makes sense as a spec over there rather than over here...

John

[Kevin Sutter]

Sure, but which path do you think will be quicker?  My money is on the MicroProfile process at this point...  There are just too many hiccups and hurdles on the EE4J road. 

Thanks for the anecdotal evidence of this type of integration working.  Does anybody know of a key player on JNoSQL?  Just to reach out and see if they are interested in MicroProfile?

--  Kevin

[John D. Ament]

Otavio (de Santana) works for Tomitribe, I believe they are aware of MicroProfile.  Their eclipse page seems to indicate the company is involved.

[Otávio Gonçalves de Santana]

Hey Kevin and John

I'm glad to hear this proposal.

We're CDI based, so that can work on both MicroProfile and EE4J efficiently.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/51d26b20-d1f1-478e-8124-a2e271ccf375%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Otávio Gonçalves de Santana

twitter: http://twitter.com/otaviojava

site:     http://about.me/otaviojava

[Ondro Mihályi]

Hi,

While I would also like to have at least a simple API to access standard SQL databases, I've seen the jNoSQL API and it's very lightweight and integrates with CDI very well, which fits MicroProfile.

It's up to the jNoSQL team if they want to do the work twice (for the JSR and for MicroProfile) or wait until the JSR is finished and then include it in MicroProfile. Maybe evolve it within MicroProfile and then port it to the JSR effort?

However, I'm also strongly in favor of having SQL API too. JPA is still very popular, but something inspired by jOOQ or Speedment would probably fit better in MicroProfile. SQL databases are still a good fit for many microservices, especially cloud-native relational DBs such as Amazon RDS, Amazon Aurora or MS Azure SQL DB. And SQL is a far more widespread standard than anything else in a DB world.

--Ondro

On Thursday, October 19, 2017 at 1:40:03 PM UTC+2, Otávio Gonçalves de Santana wrote:

Hey Kevin and John

I'm glad to hear this proposal.

We're CDI based, so that can work on both MicroProfile and EE4J efficiently.

On Wed, Oct 18, 2017 at 8:24 PM, John D. Ament <john.d...@gmail.com> wrote:

Otavio (de Santana) works for Tomitribe, I believe they are aware of MicroProfile.  Their eclipse page seems to indicate the company is involved.

On Wednesday, October 18, 2017 at 4:38:49 PM UTC-4, Kevin Sutter wrote:

Sure, but which path do you think will be quicker?  My money is on the MicroProfile process at this point...  There are just too many hiccups and hurdles on the EE4J road. 

Thanks for the anecdotal evidence of this type of integration working.  Does anybody know of a key player on JNoSQL?  Just to reach out and see if they are interested in MicroProfile?

--  Kevin

On Wednesday, October 18, 2017 at 3:27:01 PM UTC-5, John D. Ament wrote:

At one point, Otavio had indicated to me he was actually demoing JNoSQL on Hammock, since he didn't require a full runtime to work.  So I believe the technology still works together, but I personally haven't tested it.  I have personally tested and demo'd Hibernate OGM on Hammock via DeltaSpike's repositories, that was working as well.  I think it would be good to standardize on a concrete API for working with No SQL stores, but almost wonder if it makes sense to just wait a few weeks for EE4J to solidify to see if it makes sense as a spec over there rather than over here...

John

On Wednesday, October 18, 2017 at 1:32:24 PM UTC-4, Kevin Sutter wrote:

Hi,
I know that we briefly discussed a persistence feature way back when we started MicroProfile.  At that time, we had talked about JPA, but decided that maybe relational databases were not the proper choice for cloud native microservice applications.

We also briefly discussed NoSQL databases, but which one would we choose?  There wasn't a standard defined and if we chose the "wrong one", then it could limit our applicability.

Recently, I've been re-introduced to JNoSQL.  This is not a standard, per se.  But, it is getting quite a bit of attention.  JNoSQL provides a programming model abstraction for NoSQL databases.  So, we wouldn't be tied to just MongoDB or CouchDB or whatever.  It provides both the basic communication mechanism as well as Java object mapping capabilities.

I'm not an expert, nor do I work with this group.  It just seems like a nice fit if we're interested in providing a persistence component for MicroProfile.  Before we take this too much further, I thought I would start the conversation here and see what the wider team thinks.

Thanks,
Kevin

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/51d26b20-d1f1-478e-8124-a2e271ccf375%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kevin Sutter]

Hi Otavio,

Now that I look a bit closer, I see that you are one of or the key contributor for JNoSQL!  Excellent.  Especially since you are already very familiar with the MicroProfile effort.

It seems you are an Eclipse project, with multiple github repos under the eclipse umbrella.  And, you are a member of the Technology top-level project.  I suppose the same question has been posted to you as has been posted to MicroProfile.  As EE4J matures, do you foresee this JNoSQL project moving over to EE4J (from Technology)?

When I go to your jnosql.org site, I see that several of the eclipse github repos are forked over to the jnosql parent.  Is there a reason to have this type of staged development?  Just curious on the organization.

I also noticed that you dual license -- EPL v1 and Apache v2.  Again, just curious, but why did you dual license instead of just sticking with Apache v2?  I know that Tomitribe is very much an Apache-oriented project team, so I'm curious why the dual license with EPL.

What are your thoughts on the future of JNoSQL?  The overall topic of "Java NoSQL" has been discussed for a long time.  There have been some attempts at modernizing JPA implementations to also include NoSQL databases (with mixed success).  There has been some talk about extending the JPA spec with NoSQL constructs.  I see where your framework supports many different NoSQL database types and instances.  Are you actively working with these other organizations?  Or, is it mainly an independent effort interfacing with public APIs?  Do you see a path where maybe JNoSQL might integrate with MicroProfile and/or EE4J?

Thanks for your insights.  I'm quite interested in possibly bringing JNoSQL into the MicroProfile project, if there is enough community interest.

--  Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Uy-TwXuCEaM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAPc8kR1wURKTiFPR%3DzgusN2qerN47SKorNnXaQsceHqVAT5EUg%40mail.gmail.com.

[Kevin Sutter]

Ondro,

Interesting.  I didn't realize that JNoSQL was being proposed as a JSR.  Is there a link you can point me at?  My googling skills are coming up empty.  Per your comment, I'd like to see "..maybe evolve it within MicroProfile and then port it to the JSR effort?"

Relational databases are interesting.  I agree that they are still by far more prevalent in the industry, but net new microservice applications tend to focus on nosql databases.  Maybe that's a development statement and not a production statement?  I don't know.  That's just been my experience.

And, if we would decide to go down a relational database path, I'd push for JPA.  Maybe that's due to my past experiences, but I'd really question why re-invent the wheel?  If we're going to exert time and resource on some persistence solution for MicroProfile, I'd prefer focusing on the nosql path than attempting to figure out an alternate to JPA.  My two cents worth...

--  Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Uy-TwXuCEaM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/fc068869-8045-481c-bef5-415269da4a6c%40googlegroups.com.

[Ondro Mihályi]

Hi Kevin,

Although jNoSQL probably hasn't been submitted as a JSR yet, there were plans to do so. The goal is state in the wiki, which also links to a draft of a JSR proposal. Now, jNoSQL will probably target getting into EE4J and/or MicroProfile rather than becoming a JSR. Otavio could clarify more, as he's the main contributor and leader of the jNoSQL effort.

--Ondro

[Otávio Gonçalves de Santana]

On Fri, Oct 20, 2017 at 10:35 AM, Kevin Sutter <kwsu...@gmail.com> wrote:

Hi Otavio,

Now that I look a bit closer, I see that you are one of or the key contributor for JNoSQL!  Excellent.  Especially since you are already very familiar with the MicroProfile effort.

Thank you.

I'm the key, but not the only one. I have received some feedbacks from some NoSQL vendors about the API such as:

• Scylladb
  
• Couchbase
  
• OrientDB
  
• Hazelcast
  
• MongoDB
  
• Spring Data
  
• Ondro Mihályi
  
• etc. 
  

It seems you are an Eclipse project, with multiple github repos under the eclipse umbrella.  And, you are a member of the Technology top-level project.  I suppose the same question has been posted to you as has been posted to MicroProfile.  As EE4J matures, do you foresee this JNoSQL project moving over to EE4J (from Technology)?

 

    The Initial idea was a JSR to Java EE 9, however, with these changes and Java EE moving to Eclipse Foundation. I'm waiting for to see how the process will be on Eclipse; I believe JSR won`t be necessary anymore.

    But, yes, once clear the whole idea is to move it to EE4J. 

     The JSR proposal here: https://goo.gl/sNKeiC

When I go to your jnosql.org site, I see that several of the eclipse github repos are forked over to the jnosql parent.  Is there a reason to have this type of staged development?  Just curious on the organization.

   

 The site is deprecated, but it will receive a massive update in the next two weeks. The right one is on Eclipse repository: https://github.com/eclipse?q=jnosql

I also noticed that you dual license -- EPL v1 and Apache v2.  Again, just curious, but why did you dual license instead of just sticking with Apache v2?  I know that Tomitribe is very much an Apache-oriented project team, so I'm curious why the dual license with EPL.

   On that time, that was a SouJava decision as to move the code to Eclipse Foundation. 

What are your thoughts on the future of JNoSQL?  The overall topic of "Java NoSQL" has been discussed for a long time.  There have been some attempts at modernizing JPA implementations to also include NoSQL databases (with mixed success).  There has been some talk about extending the JPA spec with NoSQL constructs.  I see where your framework supports many different NoSQL database types and instances.  Are you actively working with these other organizations?  Or, is it mainly an independent effort interfacing with public APIs?  Do you see a path where maybe JNoSQL might integrate with MicroProfile and/or EE4J?

The initial idea was to create a JSR to go Java EE 9, that why we involve a lot of NoSQL vendors.

We saw the JPA tentatives, however, take an API created to SQL to NoSQL does not work very well. NoSQL has a vast diversity, different types and particular behavior from vendors we need to have an API that looks to all this.

I did as any standard step do, so I studied options and then take a decision over that based on NoSQL vendors feedbacks. There are details on the JSR doc.

Our initial scope is to submit in December as JSR, or any new process the EE4J will have, I believe until we'll have an update site, documentation, and more articles.

And yes, the idea is to work with EE4J and MicroProfile.

Thanks for your insights.  I'm quite interested in possibly bringing JNoSQL into the MicroProfile project, if there is enough community interest.

    I hope so. If there is more question, please, let me know.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8er%3Dg_pd47O6R6OGDHC1G9fg4X%2BGZOAjOxQLOH2ZRWQ5gmQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

Hi,

Am Samstag, 21. Oktober 2017 15:44:48 UTC+2 schrieb Otávio Gonçalves de Santana:

On Fri, Oct 20, 2017 at 10:35 AM, Kevin Sutter <kwsu...@gmail.com> wrote:

Hi Otavio,

Now that I look a bit closer, I see that you are one of or the key contributor for JNoSQL!  Excellent.  Especially since you are already very familiar with the MicroProfile effort.

Thank you.

I'm the key, but not the only one. I have received some feedbacks from some NoSQL vendors about the API such as:

• Scylladb
  
• Couchbase
  
• OrientDB
  
• Hazelcast
  
• MongoDB
  
• Spring Data
  
• Ondro Mihályi
  
• etc. 
  

It seems you are an Eclipse project, with multiple github repos under the eclipse umbrella.  And, you are a member of the Technology top-level project.  I suppose the same question has been posted to you as has been posted to MicroProfile.  As EE4J matures, do you foresee this JNoSQL project moving over to EE4J (from Technology)?

 

    The Initial idea was a JSR to Java EE 9, however, with these changes and Java EE moving to Eclipse Foundation. I'm waiting for to see how the process will be on Eclipse; I believe JSR won`t be necessary anymore.

    But, yes, once clear the whole idea is to move it to EE4J. 

     The JSR proposal here: https://goo.gl/sNKeiC

When I go to your jnosql.org site, I see that several of the eclipse github repos are forked over to the jnosql parent.  Is there a reason to have this type of staged development?  Just curious on the organization.

   

 The site is deprecated, but it will receive a massive update in the next two weeks. The right one is on Eclipse repository: https://github.com/eclipse?q=jnosql

I also noticed that you dual license -- EPL v1 and Apache v2.  Again, just curious, but why did you dual license instead of just sticking with Apache v2?  I know that Tomitribe is very much an Apache-oriented project team, so I'm curious why the dual license with EPL.

   On that time, that was a SouJava decision as to move the code to Eclipse Foundation. 

Both JPA (EclipseLink) is dual-licensed under EPL and except maybe for a few JSRs (like CDI) that currently use Apache v2 the default license for EE4J is also EPL (v2 more likely then) so it makes sense.

https://wiki.eclipse.org/EclipseLink/Examples/JPA/NoSQL and https://wiki.eclipse.org/EclipseLink/Examples/PolyglotPersistence show that EclipseLink already supports NoSQL databases, so a synergy between JNoSQL and EclipseLink under the EE4J umbrella looks like a very good approach to use synergies and make persisting seamlessly against either relational or non-relational databases possible.

 

What are your thoughts on the future of JNoSQL?  The overall topic of "Java NoSQL" has been discussed for a long time.  There have been some attempts at modernizing JPA implementations to also include NoSQL databases (with mixed success).  There has been some talk about extending the JPA spec with NoSQL constructs.  I see where your framework supports many different NoSQL database types and instances.  Are you actively working with these other organizations?  Or, is it mainly an independent effort interfacing with public APIs?  Do you see a path where maybe JNoSQL might integrate with MicroProfile and/or EE4J?

The initial idea was to create a JSR to go Java EE 9, that why we involve a lot of NoSQL vendors.

We saw the JPA tentatives, however, take an API created to SQL to NoSQL does not work very well. NoSQL has a vast diversity, different types and particular behavior from vendors we need to have an API that looks to all this.

I did as any standard step do, so I studied options and then take a decision over that based on NoSQL vendors feedbacks. There are details on the JSR doc.

Our initial scope is to submit in December as JSR, or any new process the EE4J will have, I believe until we'll have an update site, documentation, and more articles.

And yes, the idea is to work with EE4J and MicroProfile.

Integrating with EE4J / EclipseLink makes a lot of sense, while I don't really see how MicroProfile would benefit from swallowing all that's now under JNoSQL, just take Diana for dozens of concrete systems: https://github.com/eclipse/jnosql-diana-driver 

MicroProfile gathers 'Microservice Patterns' while relational or non-relational persistence as such is not one of those patterns. It depends on the particular services which if any persistence they require. 

There are patterns like http://microservices.io/patterns/data/database-per-service.html or http://microservices.io/patterns/data/shared-database.html but they do not specify the kind of database. Supporting such patterns may end up in MicroProfile, probably with something like CDI-based Artemis as a dependency or JPA or both, but 'bringing JNoSQL into MicroProfile' I'm afraid that would kill both. MicroProfile already struggles has almost too many de-facto sub-projects without defining them as actual sub-projects right now. 

JNoSQL also has a rather dynamic lifecycle right now, would be hard to align with MicroProfile. Using it in a future version under a data pattern or similar sounds more like it.

Werner

 

--  Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/51d26b20-d1f1-478e-8124-a2e271ccf375%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Otávio Gonçalves de Santana

twitter: http://twitter.com/otaviojava

site:     http://about.me/otaviojava

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Uy-TwXuCEaM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAPc8kR1wURKTiFPR%3DzgusN2qerN47SKorNnXaQsceHqVAT5EUg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8er%3Dg_pd47O6R6OGDHC1G9fg4X%2BGZOAjOxQLOH2ZRWQ5gmQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Kevin Sutter]

+1, Werner

As I continues to dig into this JNoSQL material and taking into account Ondro's suggestion of a JPA alternative...  I was starting to wonder whether the persistence layer really fit in with the MicroProfile programming model.  There are definitely persistent patterns that have been defined or proposed, but that doesn't necessarily mean that MP has to provide a defined persistence layer.  Still weighing the pros and cons of such a move...

Re:  licensing...  Otavio, as you have seen, Eclipse does not require EPL since MicroProfile is Apache v2 only.  No dual license required.  Just an FYI as you move your projects forward...

--  Kevin

[Leonardo de Moura Rocha Lima]

I think that every software eventually needs to handle data stored somewhere - be it remotely or locally. So having a persistence layer does make sense to me.

As an added information to people who'd like to know more about JNoSQL, I did a presentation about it on JavaOne (JavaOne 2017 - JNoSQL: The Definitive Solution for Java and NoSQL Database [CON4954]). If there's interest and the slides are not enough, I can do a video presenting it later this week.

Regards,

Leo.

[Rudy De Busscher]

I believe that some data storage is essential for MicroProfile.

When you see the micro-service as the owner of the data of a certain domain (like within the Self Contained Systems http://scs-architecture.org) you need to be able to store them.

Whether it should be using SQL or NoSQL, that is another discussion.

Rudy

[Otávio Gonçalves de Santana]

JavaOne 2017 - JNoSQL: The Definitive Solution for Java and NoSQL Database [CON4954] (EN)

https://www.youtube.com/watch?v=W5Z8c37m-VM&t=1471s

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/fc271925-3494-41ec-8616-ff39ed8e11c6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arjan Tijms]

Indeed, nodes in a microservice architecture often need to handle their own data.

In my previous jobs I always used JPA for this, sometimes in combination with an embedded DB (eg h2), sometimes combined with a separate dB per node (eg Postgres).

Well a NoSQL option may be handy, I’d hate to be “forced” into that with MicroProfile.

Kind regards,
Arjan Tijms