Hi Fred- As an FYI, sometime ago now so I don't recall all the details, but I have had several users/community developers ask me (online, @conferences, etc) when/if ever Geode was considering implementing the *JCache* API. I definitely think there is value in doing so.
One of the major concerns for many organizations (I have 1 in particular) was to avoid vendor lock-in. In this 1 particular customer's case, they went to great effort to abstract away GemFire, so much so that I would not recommend this pattern (as it was overly complicated and a bastardization of the framework), which employed *Spring's Cache Abstraction*, but it worked none-the-less. Coding to the Geode API certainly ties your application to a implementation of IMDG, or what have you. This is one of the significant advantages of *Spring Data Geode*, particularly if you are using the right abstractions ( GemfireTemplate, SD *Repositories*, SDG Function Annotations for POJO-based Function Definition and Interface-based Function Execution, etc). Like *Spring*, *JCache* (JSR-107) is a well-known, widely used and standard API, and many other IMDG implementations are falling in line (e.g. Hazelcast <https://hazelcast.org/features/#Standards> [1]). I don't really see much value in implementing yet another proprietary interface, or product specific API. I'd rather see the current Geode APIs improve! There is always this fear of breaking users applications. Well, that is part of API evolution and is nothing new in software. Every major API, Framework and platform, including Java itself, has introduced API breaking changes. The appropriate time to introduce these changes is in "major" version updates, e.g. Apache Geode 2.0. Additionally, I also think it makes more sense to latch on to standard APIs, e.g. *JCache*, (whether fully baked or not; preferably baked) and widely adopted, "open" frameworks and platforms, e.g. *Spring Boot*. *Spring Boot's* auto-configuration support is second to none, and with over 10 million monthly downloads now, it is hard to argue with that. From a user experience standpoint, nothing is or will be as simple as auto-configuration that quietly backs away when the user starts to customize things. Building on the shoulders of giants (integrating), particularly ones that iterate/innovate quickly, gives you real momentum. Food for thought. -j [1] https://hazelcast.org/features/#Standards On Mon, Apr 24, 2017 at 8:20 PM, Fred Krone <fkr...@pivotal.io> wrote: > That's great, Wes. I will take a look. Thanks. > > John -- good feedback to consider and I was hoping this would come up. > > "In my mind, there really are only 2 approaches... *Spring* and > non-*Spring*, > or rather PCF and non-PCF, and since PCF is primarily based on Boot (given > Microservices/applications are the new concurrency), then I am really > saying the same thing." > > This would be cover non spring and attempt to give the community something > that had the same standardized experience as JSR 107 -- starting with the > Cache interface itself. Although we don't necessarily have to implement > Cache, it's method signatures are essentially a (non spring) caching > standard for Java developers at this point. We considered full blown JSR > 107 implementation but thought it was too robust for the needs mentioned > (that's not to say we couldn't get there incrementally). I think those > needs still exist open-source outside of PCF and don't cannibalize. > > > > > > > On Mon, Apr 24, 2017 at 7:44 PM, Real Wes <thereal...@outlook.com> wrote: > > > > > Here is a simple Java client _for enterprise use_ that I developed for > > Geode and distributed to several enterprises. It has similarities and > > differences for your goal. This project creates both server and client > > regions dynamically. It lists regions, alters regions… really anything > > that GFSH can do. It differs in that it calls GFSH to do its work rather > > than a Java interface. You can think of this as a Java API on top of > GFSH. > > > > You can use this model and keep the similarities while adjusting for the > > Java interface. > > > > Similarities > > - Client uses SDG and complies with JSR-107 > > [the Cache Manager is here: https://github.com/Pivotal- > > Data-Engineering/ClusterManagement/tree/master/ > > cluster-management-client/src/main/java/com/geode/cache/manager ] > > - After the server creates its region, client creates its region > > [ see createRegions at: https://github.com/Pivotal- > Data-Engineering/ > > ClusterManagement/blob/master/cluster-management- > > client/src/main/java/com/geode/cache/manager/RegionCreator.java<https:// > > github.com/Pivotal-Data-Engineering/ClusterManagement/ > blob/master/cluster- > > management-client/src/main/java/com/geode/cache/manager/ > RegionCreator.java> > > ] > > > > Differences > > Server dynamically calls GFSH to execute commands > > > > How it works > > - Whenever the client calls a region that does not exist, the client > looks > > for a <region name>.properties file. If the properties file exists, the > > region is created with the dynamic properties. > > - If <region name>.properties does not exist, default region properties > > are loaded and used to create the region. > > - properties are formed into a GFSH string and passed to a server > function > > - The server function calls GFSH using internal calls. It calls the > > GfshParser, executes the command, and then returns the parsed results. > > [see https://github.com/Pivotal-Data-Engineering/ > > ClusterManagement/blob/master/cluster-management-server/src/ > > main/java/com/geode/gfsh/GfshCommand.java] > > > > Limitations > > It uses internal calls to call GFSH. I have made requests to make this a > > stable public interface. Andrew Baker had a good idea to return gfsh > > results in JSON format with a new —results=json property to pass to GFSH. > > > > Strengths > > That is uses GFSH can be viewed as a strength to keep a consistent API, > > whether Java or GFSH > > > > TESTS > > You can start by running server tests at: https://github.com/Pivotal- > > Data-Engineering/ClusterManagement/tree/master/ > > cluster-management-server/src/test/java/com/geode/gfsh > > > > Client tests are at: https://github.com/Pivotal-Data-Engineering/ > > ClusterManagement/tree/master/cluster-management-client/src/ > > test/java/com/geode/management/client > > > > > > Regards, > > Wes Williams > > > > On Apr 24, 2017, at 6:51 PM, Kirk Lund <kl...@apache.org<mailto:klund > > @apache.org>> wrote: > > > > A couple things I'd like to see: > > > > 1) completely new API that doesn't reuse the old API classes (or at least > > not the giant classes such as Cache and Region interfaces) > > 2) separation of API and Impl so that users can compile their code > against > > a dedicated client API jar > > > > On Mon, Apr 24, 2017 at 3:03 PM, Fred Krone <fkr...@pivotal.io<mailto: > fkro > > n...@pivotal.io>> wrote: > > > > In an effort to improve Java developer ease of use for caching with > Geode I > > am looking for feedback on going forward with creating a Java client. > This > > client will allow for server-side region creation and distributed data > > caching. This would allow for a thin client that fits with microservice > > caching patterns and also abstracts a cleaner client-server experience > > driven interface. > > > > Initially we were going to update the Region interface but were concerned > > with breaking existing applications. We also would like to provide > Region > > creation to a client application and so propose here solving both of > these > > areas with a Java client. > > > > It would have new project repo for the client. > > > > It would provide new Region interface for clients. The specifics of the > > API design are too lengthy for this conversation but implementation will > > resemble JSR 107 Cache interface. > > > > It would use the new security framework. > > > > > > *An example*, > > > > The client application simply creates an instance of client and points it > > to the locator: > > > > > > org.apache.geode.client.Client client = Client.create(locatorHost, > > locatorPort); > > > > > > Client has the following methods: > > > > package org.apache.geode.client; > > > > > > public interface GeodeClient { > > > > /** > > > > * creates the region on the servers, or gets the region if it exits, > > returns a PROXY region > > > > */ > > > > public Region getOrCreateRegion(RegionAttributes attributes, String > > name); > > > > > > /** > > > > * Returns a PROXY region if the region exists on the server > > > > */ > > > > public Region getRegion(String name); > > > > > > > > > > > > > > MVP > > > > The smallest set of features to test this idea, learn and iterate, and > get > > the client into the communities hands for future iterations is: > > > > > > Create a server side Region from a client > > > > Region interface has CRUD on par with javax.cache.Cache (from JSR 107) > > > > Calls are asynchronous -- futures > > > > > > > > Also would like feedback on which future functionality would be most > useful > > from a thin client: > > > > Function execution > > > > Durable clients > > > > User defined serialization > > > > Register interest > > > > Queries > > > > CQ > > > > Near side caching > > > > Create disk stores from client > > > > Region group membership > > > > Client subscription load balancing > > Transactions > > > > > > Thanks, > > -Fred > > > > > > > -- -John john.blum10101 (skype)
