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:kl...@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:fkr...@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
