9:45 a.m.
On 05/10/2016 10:01 AM, Emmanuel Bernard wrote:
That reminds me that we wanted to make the connection to JDG as
simple
as MongoDB and the like. (i.e. a URL scheme more or less).
I'm talking about JDG remote here even though local would be a nice to
have.
How hard would that be?
I think that org.wildfly.clustering.dispatcher.CommandDispatcher is for
invoking nodes on the WildFly cluster but I'm not sure of the API for
invoking JDG remote and whether that is planned to be part of WildFly
already, as part of our clustering effort.
Could/should JDG access fall into NoSQL integration?
Emmanuel
On Wed 2016-05-04 14:16, Scott Marlow wrote:
> 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
>
> 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
>
> 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.
>
> 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.
> - need to align with OGM dependencies (e.g. Hibernate ORM + other
> dependencies).
> - as mentioned above, OGM already has some connection setup code,
> which might be good to share for WildFly + standalone NoSQL use.
> - once WildFly has a common NoSQLSource (not a DataSource) that OGM
> can use, OGM will be enhanced to use it.
>
> 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?
>
> 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.
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev