Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Spring Data Geode 1.0.0. Apache Geode Incubating M3 Released

DZone's Guide to

Spring Data Geode 1.0.0. Apache Geode Incubating M3 Released

This release focuses on the out-of-box experience in order to get users up and running as quickly and easily as possible.

· Big Data Zone
Free Resource

Learn best practices according to DataOps. Download the free O'Reilly eBook on building a modern Big Data platform.

I apologize to both the Spring and Apache Geode communities for the delay, relative to the Apache Geode M3 release announcement, but I am very excited and pleased to follow that with the release of Spring Data for Apache Geode 1.0.0-incubating.M3.

You can get the bits from Maven Central by including the following dependency in either your application Maven or Gradle build files …

Maven

<dependency>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-geode</artifactId>
  <version>1.0.0.APACHE-GEODE-INCUBATING-M3</version>
</dependency>

Gradle

compile 'org.springframework.data:spring-data-geode:1.0.0.APACHE-GEODE-INCUBATING-M3'

Including the spring-data-geode dependency will transitively pull in all required Apache Geode artifacts so you can start building Spring applications that use Apache Geode today.

What’s New

While not much functionally changed between Apache Geode M2 and M3 (mainly bug fixes), many things did change in Spring Data Geode. One key feature stands above all the rest.

Setting the Stage

For too long, Apache Geode (originating from Pivotal GemFire) has been overly complicated to configure and use properly, making it difficult for users to get up and running as quickly, and as easily as possible. To gain more insight into the problem, check out my talk in the August, Apache Geode Clubhouse Meeting.

While Apache Geode (and by extension, Pivotal GemFire) has much stronger consistency guarantees, and often times, better performance, it is hard to compete with the simplicity and out-of-box experience with some of the alternatives (for instance), especially when they are good enough in a majority of the use cases.

Simplicity will beat flexibility and performance nearly every, single, time; Just ask developers. You can tune for performance many different ways, but no amount of application code is going to make it any simpler to do. Less is more.

Problem/Solution

The problem has been rooted in the fact that Apache Geode has lacked an opinionated and consistent programming/configuration model, particularly for application development. So really, we don’t need to look any further than the Spring Framework. However, that still leaves “opinion”.

Once again, Spring gives us Spring Boot, and what a beautiful piece of engineering it is, so elegant, so simple. And, as you will see below, it has truly been an inspiration for the work on Spring Data Geode.

Shut Up and Show Me “The Code”…

In the past, Spring developers had to configure Geode with either XML, or Java config, and then use a bootstrapping mechanism, like Gfsh, or Spring Boot, to get up and running. This has even been demonstrated in the guides. Neither one was really a significant advantage over the other until now.

From this milestone release onward, Spring Data Geode will include a new set of annotations, very similar in form/function, and complimentary to, Spring Boot annotations, but specifically for SD/Apache Geode, with 1 simple goal in mind…

Simply the out-of-box experience in order to get users up and running as quickly and easily as possible

So, let’s take our XML and Java config example and do it one more time…

@SpringBootApplication
@PeerCacheApplication
@WithReplicateRegions("myDistributedMap")
public class ExampleApplication implements CommandLineRunner {

  public static void main(String[] args) {
    SpringApplication.run(ExampleApplication.class, args);
  }

  @Resource(name = "myDistributedMap")
  private Region<String, String> myDistributedMap;

  @Override
  public void run(String... strings) throws Exception {
    assertThat(myDistributedMap.put("key", "value")).isNull();
    assertThat(myDistributedMap.get("key")).isEqualTo("value");
    assertThat(myDistributedMap.putIfAbsent("somekey", "somevalue")).isNull();
    assertThat(myDistributedMap.replace("key", "value", "newvalue")).isTrue();
  }
}

Pretty easy. This example is rather simplistic, but you can probably imagine some application configurations (for example; just follow the hierarchy) becoming pretty involved rather quickly.

This is a teaser for now, so stay tuned for more.

Conclusion

There will be many different annotations to address all the unique concerns in a consistent and robust way, providing out-of-box defaults along with many convenient, “enabling” features. Many of the details of this new Annotation configuration model are still a work in progress, such as proper examples and documentation.

In the interim, I have started the beginnings of a reference implementation that will showcase many of the features and functionality of using Spring and Apache Geode together (like the new Annotation configuration model).

Look for more communications from us down the road soon.

As always, feedback is most welcomed, and you can reach out to us in JIRA or on StackOverflow.

Thanks all!

Find the perfect platform for a scalable self-service model to manage Big Data workloads in the Cloud. Download the free O'Reilly eBook to learn more.

Topics:
configuration ,m3 ,geode ,data ,model ,apache ,spring ,annotation

Published at DZone with permission of John Blum. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}