Hi Scott,

Thanks for driving this initiative!

Some comments/questions inline.

2016-05-04 20:16 GMT+02:00 Scott Marlow <smarlow@redhat.com>:
Hi,

Below is an update on the WildFly NoSQL integration project.  The goal
is for deployed applications to have access to NoSQL databases (via
Hibernate OGM or native APIs).  Items 1-4, should be finished in our
first pass, with as much of the others items as we can do as well.

1. connection management will deal with obtaining NoSQL connections for
application use.

  - borrow/share Hibernate OGM connection configuration setup code
  - authentication integration
  - support transport level security

Any ideas how this code sharing could look like?

Hibernate OGM should still be usable without WF; So maybe there should be a separate project/repo which defines an SPI to obtain/manage connections and implementations for different NoSQL stores?

I think it'd be beneficial to define some sort of connection URL syntax which can be used in NoSQL datasource definitions:

    nosql:mongodb://192.168.1.100:27017[,another-host:another-port]/some_db?customParam1=xyz&customParam2=abc&...

This common syntax might do for most cases, for others it might be needed to support specialized schemes handled by store-specific SPI implementations.

Regarding pooling, many NoSQL drivers do it in one way or another, so maybe leave that to drivers, at least in the first iteration?

2. CDI programming simplifications will make it easy to inject NoSQL
data into your application classes.

  - https://github.com/antoinesd/javaee-nosql is initial idea

+1 Sounds nice. 

3. You will easily get a native NoSQL connection from the specified
NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in
your application.

Would you take measures to e.g. prevent closing a connection in application code?

4. You will also be able to easily use Hibernate OGM with the defined
NoSQL profiles (exactly how is TBD but will be awesome :-).
  - Hibernate OGM static module is included.

WDYM by "static module"? The Hibernate OGM Core module?

How would people add the OGM backend module for the NoSQL store of their choice? I suppose you don't mean to add all the backends we have to WF by default (as this would increase size quite a bit), so would people still use the module ZIP we provide?
 
  - need to align with OGM dependencies (e.g. Hibernate ORM + other
dependencies).

Note we aim at the ORM version part of WF at a given time. But there are times where we need a newer ORM version for a new OGM release (when using new SPIs not part in the ORM version coming with the currently released WF), so there should be a way to achieve that.
 
  - as mentioned above, OGM already has some connection setup code,
which might be good to share for WildFly + standalone NoSQL use.

I'm not sure how re-usable this is. It's geared towards OGM's needs, I feel having a separate SPI dealing just with connections would be more useful.
 
  - once WildFly has a common NoSQLSource (not a DataSource) that OGM
can use, OGM will be enhanced to use it.

+1

5. How best for the WildFly NoSQL subsystem to be optional?
  - Is it enough to not run the wildfly/testsuite/nosql tests by default?
  - Or do we need to start a separate https://github.com/wildfly/nosql
project for the NoSQL subsystems?

Would there be one OGM sub-system? Or one per NoSQL store? And how would people add them (see above)? As said before in this thread, there should be a way to update modules of specific stores to get the latest and greatest.

6. transaction enlistment

7. compensating transactions

8. runtime application monitoring

9. How soon can we make an evaluation distribution available for use on
OpenStack/OpenShift?
  - Would be great if we could do some load testing with all NoSQL
components.
  - Would be great if we could enable others to also test.

10. Are there any problems with our WildFly NoSQL subsystem injecting
MongoDatabase connections via:

    @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;

  - No @Resource support expected for standalone Java, TBD is whether a
runtime library can be used.
  - Any problems expected on other EE application servers if this
approach becomes popular?

11. WIP topic branch is at
https://github.com/scottmarlow/wildfly/tree/nosql-dev9.  Note that every
once in a while, commits are squashed and pushed to nosql-devN+1.

Any pointers where to start looking to see what's working already? 

12. Add proper unit tests
  - multi-threaded NoSQL access to show that works at all.
  - use NoSQL from different EE components (e.g. JAX-RS).
  - other use cases that represent how NoSQL could be used from WildFly.

Feedback/help is welcome!

Thanks,
Scott
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev