Addressing Messaging Challenges Using Open Technologies
For Modern Applications Many businesses are faced with some new messaging challenges for modern applications, such as horizontal scalability of the messaging tier, heterogeneous messaging systems and access methods, and extreme transaction processing. This presentation/demo will cover how businesses can overcome these messaging challenges with the use of Spring and RabbitMQ technologies.
Tom will build a case for AMQP, explain how SpringSource is providing AMQP support via Spring AMQP and Spring Integration, explain how RabbitMQ is a modern messaging solution that offers a reliable, highly available, scalable and portable messaging system with predictable and consistent throughput and latency, and demonstrate how Spring Integration and RabbitMQ can be progressively introduced into a standard Spring web application.
About the speaker
Tom McCuch
Tom McCuch is a Solution Engineer for Hortonworks with over twenty two years of experience in software engineering. Tom specializes in the architecture, implementation, and deployment of distributed systems requiring high Reliability, Availability, and Scalability (RAS) features. Prior to Hortonworks, Tom worked for SpringSource - handling field architecture for their global accounts including Financial Services, Transportation, and Energy. Tom has consulted enterprise clients across multiple industries in the architecture of mission-critical solutions based on open source software as well as led the engineering of enterprise Java middleware supporting next-generation telecommunications products deployed at tier-1 telcos both in the U.S. and Europe.
Oleg is a Principal Architect with Hortonworks responsible for architecting scalable BigData solutions using various OpenSource technologies available within and outside the Hadoop ecosystem. Before Hortonworls Oleg was part of the SpringSource/VMWare where he was a core engineer working on Spring Integration framework, leading Spring Integration Scala DSL and contributing to other projects in Spring portfolio. He has 17+ years of experience in software engineering across multiple disciplines including software architecture and design, consulting, business analysis and application development. Oleg has been focusing on professional Java development since 1999. Since 2004 he has been heavily involved in using several open source technologies and platforms across a number of projects around the world and spanning industries such as Teleco, Banking, Law Enforcement, US DOD and others. As a speaker Oleg presented seminars at dozens of conferences worldwide (i.e.SpringOne, JavaOne, Java Zone, Jazoon, Java2Days, Scala Days, Uberconf, and others).
Introduction to Spring Integration and Spring Batch
In this session you will learn what Spring Integration and Spring Batch are all about, how they differ, their commonalities, and how you can use Spring Batch and Spring Integration together.
We will provide a short overview of the Enterprise Integration Patterns (EIP) as described in the highly influential book of the same name. Based on these patterns, we will then see how Spring Integration enables the development of Message-driven applications. This allows you to not only modularize new or existing applications but also makes it easy to integrate with external systems.
This session will also introduce Spring Batch. Spring Batch addresses the needs of any batch process, be it complex calculations in large financial institutions or simple data migration tasks as they exist in many software development projects. We will cover what Spring Batch is, how Spring approaches the concepts of batch and how Spring handles scaling batch processes to be able to handle any volume of data.
You will also see how Spring Integration and Spring Batch maximize the reuse of the integration support provided by the core Spring Framework. In addition to providing a robust, proven foundation, this also flattens the learning curve considerably to all developers already familiar with Spring.
About the speaker
Gunnar Hillert
Gunnar Hillert is a member of technical staff (MTS) at SpringSource, a division of VMware, Inc. He is a committer for Spring Integration, Spring AMQP and also contributes to the Cloud Foundry project. Gunnar heads the Atlanta Java Users Group and is an organizer for the DevNexus developer conference.
A native from Berlin, Germany, Gunnar has been calling Atlanta home for the past 11 years. He is an avid gardener specializing in anything sub-tropical such as bananas, palm trees and bamboo. As time permits, Gunnar works on his Spanish language skills and he and his wife Alysa are raising their two children tri-lingually (English, German, Spanish). Gunnar blogs at: http://blog.hillert.com/ and you can follow him on Twitter: https://twitter.com/ghillert
Gary has been in software engineering, concentrating on Enterprise Integration, for over 30 years on various platforms, and in the Java space since the late '90s.
He has been developing with the Spring Framework since 2004 and joined SpringSource/VMware in 2009 in a consulting role. From 2009 until the end of 2011 he taught Core Spring and Enterprise Integration with Spring to several hundred developers, as well as providing Enterprise Integration consulting services with Spring Integration, Spring Batch and Core Spring.
He has been a committer on the Spring Integration project for nearly 3 years and became a full time member of the engineering team in January 2012.
The Spring Data team is happy to announce the next major step in the evolution of exporting domain objects to the web using RESTful semantics: Spring Data REST 1.1.0.M1 is now available in the SpringSource milestone repository.
Spring Data REST is a set of Spring MVC components that you can add to your own Spring MVC applications that export your Spring Data Repositories to the web using RESTful, HATEOAS semantics. It provides a consistent interaction API by exporting repositories to RESTful URLs that are configurable in a couple different ways.
Spring Data REST supports CRUD for top-level entities (those domain objects directly managed by a Spring Data Repository) by literally writing a single line of code that defines an interface that extends Spring Data's CrudRepository interface. That done, your entities then have full RESTful semantics. You can create new ones, update existing ones, and delete them using standard URLs that are, following the principles of HATEOAS, discoverable. That means the user agent accessing your Spring Data REST application doesn't need to have advance knowledge of what resources you are exporting. It can discover what entites exist and what relationships exist on those entities by successive calls to URLs provided in the JSON. These "links" are the real foundation and power of a HATEOAS REST application.
Changes from the ground up
Version 1.1 is virtually a re-write from the ground up. Not only is it easier to configure than 1.0 and better conforms to Spring MVC expections for the transition to Spring 3.2, but the biggest change in the internals of Spring Data REST is that it now supports other types of Spring Data repository implementations beyond just JPA. The HTTP semantics for CRUD and manging relationships (if the datastore supports it) remain the same no matter what backing datastore is used.
That means it's now possible to export JPA entities and MongoDB entities within the same Spring Data REST application and access those entities using a common URL structure and using the standard Spring HATEOAS Resource representation for all entities and collections. The user agent accessing those RESTful URLs does not need any special knowledge on which datastore the backing entities are managed by and, most importantly, you don't have to write any code to get that functionality!
MongoDB support
Spring Data REST 1.1 now supports exporting MongoDB CrudRepository implementations. The same HTTP semantics apply to MongoDB @Document entities as apply to JPA entities. GET, POST, PUT, DELETE are of course supported, but so is @DBRef. You can view and manage the relationship between two documents using GET, POST, PUT, and DELETE and you can export finder methods based on your @Query definitions. Please reference the spring-data-mongodb reference documentation for the full details of how the object mapping differs from JPA style mapping and how query definitions work.
Gemfire support
Spring Data REST 1.1 now supports exporting entities that use the high-performance Gemfire database to different Regions. Read the Spring Data Gemfire documentation for the full explanation of the vast configuration options and how POJO mapping in Gemfire differs from other mapping technologies.
Neo4J support is next
Spring Data REST 1.1 is now set to support Neo4J GraphRepositorys with the next version of spring-data-neo4j, version 2.3. When that's generally available (which should be around or before the general availablity of Spring Data REST 1.1 RELEASE), you will be able to access @NodeEntitys and their relationships using standard HATEOAS semantics, just like you do with the other datastores.
Add it to your existing apps
Spring Data REST is designed in such a way that you can, if you wish, create an entire application for the Spring Data REST application. It's just a standard Spring MVC webapp after all. But things get really interesting when you add Spring Data REST to your own services.
Spring HATEOAS author Oliver Gierke has created an example application that demonstrates the use of HATEOAS principles in a modern web application. It's called spring-restbucks and is an implementation of the Restbucks application described in the Systematic Theology of REST services: REST in Practice by Jim Webber, Savas Parastatidis and Ian Robinson.
Mixin REST services
By mixing Spring Data REST with your other RESTful services, you can get a seamless integration between those domain objects exported by Spring Data REST--objects for which you didn't have to write any code to have them exposed--and those services that don't represent an actual entity but a process. You can see an example of how a payment service might interact with domain object CRUD in the spring-restbucks application, where credit card payment processing is handled by a custom controller, while object CRUD is handled by Spring Data REST. Your custom controllers can actually piggyback onto the Spring Data REST URLs so that a consistent and simple URL structure can be maintained throughout the appliation, no matter whether the URL refers to your custom controller, a Spring Data REST JPA Repository, or any of the other supported Repository styles.
It's not exclusive
It's not an either-or with Spring Data REST. If you don't want all of your Repositories exposed to a web client, no problem! There a several different ways you can turn off functionality for Repositories. You can embed annotations into your source code or, if you don't have access or simply can't add the Spring Data REST annotations, you can use a fluent, DSL-style configuration to tell Spring Data REST how your resources should be exposed. Using Spring Data REST in your application isn't an exclusive committment to only one way of doing things. Spring Data REST is structured in a what that it will play nicely with your existing application so you can incorporate those bits of functionality from Spring Data REST you want, while still maintaining all the custom-coded services you're used to creating in Spring MVC controllers.
JSONP support moving to a filter
The JSONP support that was built into Spring Data REST 1.0 has been removed from the core framework in preference to a forthcoming general-purpose JSONP Serlvet Filter that will work much better than the way JSONP was implemented in version 1.0. When that filter is generally available, then JSONP support can be added not just to Spring Data REST, but virtually any Servlet-based REST resource.
If you're planning on attending CONFESS_2013 in Vienna the first week of April, then you can hear all about Spring Data REST at my talk on exporting entities to the web.
we are happy to announce the next major release of our Eclipse-based tooling today: The Spring Tool Suite (STS) 3.2.0 and the Groovy/Grails Tool Suite (GGTS) 3.2.0.
major performance improvements for working with Spring projects
major improvements to the Live Spring Beans Graph
added support for Spring Integration 2.2
updated to include Groovy 2.0.7 and Grails 2.2.1 (Groovy 2.1 is available from the dashboard)
We continue to ship distributions both on top of Eclipse 3.8 and Eclipse 4.2. While the 4.2 stream of Eclipse has improved a lot in the Eclipse Juno SR2 release, we still recommend using the 3.8-based version for optimal performance and stability.
Updates from STS/GGTS 3.0.0 and 3.1.0 are available through the automatic "Check for Updates". Users of STS 2.9.x (or older) should start with a fresh installation of STS/GGTS 3.2.0.
The next version 3.3.0 is scheduled to arrive in July 2013, shortly after the Eclipse Kepler (4.3) release. Also watch out for milestone builds of 3.3.0 if you want to stay up-to-date with the latest developments.
Welcome back to another installment of This Week in Spring.
We've got a lot to cover, though, so let's get to it!
I'm presenting a webinar on March 14, 2013 - Multi Client Development with Spring! Join me to learn about REST, OAuth, Spring MVC, Spring Android, and much more!
Spring Security lead and ninja Rob Winch has announced the initial support for Java-based configuration in Spring Security.
This is a wonderful milestone. Recently, we've seen Java-configuration alternatives to the XML DSLs offered for Spring Social, Spring Batch and - now - Spring Security. Check out the Spring Security Java-based configuration for more details.
I had the unique privilege of visiting the Alibaba group in China where they're doing some amazing things with Spring. Read more in my blog, Spring at China Scale: the Alibaba group.
Someone asked me this the other day and I felt like it was worthy of a mention: in your Spring MVC @Controller class handler methods, make sure that the BindingResult argument is immediately after the model or command argument, like this:
@RequestMapping(...) public String handleRequest( @ModelAttribute @Valid YourCustomPojo attempt, BindingResult result).
In this example, handleRequest will validate the POJO (YourCustomPojo) - checking the POJO for JSR303-annotations and attempting to apply the constraints because the POJO is annotated with @Valid - and stash any errors in the BindingResult, which it makes available if we ask for it.
Do you want to use Cloud Foundry with the continuous integration capabilities offered by CloudBees? We got you covered! The Cloud Foundry and Cloud Bees teams worked to integrate the process, and the step-by-step introduction is given here.
Alvaro Videla has introduced and open-sourced his RabbitMQ simulator. The RabbitMQ simulator is an awesome visualization tool to demonstrate how RabbitMQ topologies work.
We are pleased to announce that Spring-AMQP 1.1.4.RELEASE is now available.
This is a minor maintenance release with fixes to a few minor issues in the AMQP Log4j Appender, as well as correcting an issue in the spring-rabbit manifest for OSGI users.
Welcome to another installment of This Week in Spring! It's been an exciting two weeks for Hadoop content - Hadoop enthusiasts should check last week's post for an HD quality replay of Building Big Data Pipelines with Spring Hadoop from SpringOne 2GX 2012.
SpringOne2GX 2013 has been announced!
This year, SpringOne will occur in Santa Clara, California, on September 9-12th, 2013. I hope to see you there!
Join me, Josh Long, for the upcoming webinar - Multi Client Development with Spring - on March 14th. The webinar will introduce how to build RESTful, Spring-based applications using Spring MVC, REST and mobile technologies like Spring Mobile and Spring Android and HTML5.
If you missed the Testing Web Applications with Spring 3.2 Webinar with Sam Brannen and Rossen Stoyanchev, you can see it in HD on YouTube.
Nicolas Frankel put together a post that demonstrates how to change the default scope of beans. Beans are singleton scoped if no scope is otherwise specified. This example uses a Spring framework BeanFactoryPostProcessor to achieve the effect. NB: this is not something I'd recommend doing! This is super hackety. It is, however, a nice illustration of just how flexible Spring is.
CORS, or cross-origin resource sharing is a technique for communicating across hosts, sidestepping the single-host policy limitations typical of Ajax communication. Spring MVC doesn't support it out of the box, but it's easy to add to an existing application, as this tutorial explains.
The Java Journal blog has put together a nice post on using JDBC from Spring. Spring's long since featured the support described in this blog, so hopefully you've at least heard about these facilities in the core Spring framework before! If you haven't, then check out this post.
The aptly-named Solutions to basic IT problems blog has a nice post on Spring Data JPA. This is a follow-up from his previous post, which introduced the Spring and Hibernate combination.
Welcome back to another installment of This Week in Spring!
This week I'm in Atlanta, GA with a few other SpringSource colleagues talking to developers at the DevNexus Java conference and - tomorrow - speaking at the Atlanta Spring User Group.
This show is bigger and better than ever this year!
I love the energy and community here.
If you're in Atlanta, GA, drop by the eHire labs (see the link above for the address) tomorrow night for the Spring User Group and we'll talk about REST, Spring MVC, Spring for Android, Spring Mobile, and more!
I look forward to seeing you.
As usual, though, we've got a lot to cover, so let's get to it!
The Spring Data release train "Arora" is now avialable, a synchronized, tested release of all Spring Data sub projects - check it out now!
Gary Russell has announced Spring Integration 3.0.0 M1.
There are no major new features in this first milestone, it is mainly refactoring, removing deprecations, etc. Browse the documentation 'what's new' and the release notes for more information.
The Lucky Ryan blog has a very nice post introducing HDIV -
which can be used to
prevent
cross site request forgery (CSRF), remove the ability to alter non-editable data (hidden fields, params…) and even has options to limit characters globally across form fields -
and explaining how to use HDIV with Spring MVC.
Your remoting layer (the layer that's exposed over the network)
might simply surface the domain model objects from your services layer.
Often, however, the object sent across the wire is a slightly different version of the data
used by the service. Perhaps fields are omitted because they contain too much data. Perhaps extra fields are added to communicate metadata about the service itself. Perhaps you simply want to flatten two different types into
a single object for ease-of-transport. Whatever the reason, the common pattern (or anti-pattern) to handling this is a DTO (data transfer object). We had these before with EJBs and DCOM and CORBA. Now we have
them with REST.
If you find you have to have DTOs, the jtransfo library introduced in this post seems like it might be helpful in reducing the tedious adapters from DTO to domain object. The post explains how to use JTransfo to automatically handle adapting domain objects to DTOs.
We are pleased to announce that Spring Integration 3.0.0.M1 is now available. There are no major new features in this first milestone, it is mainly refactoring, removing deprecations, etc. Browse the documentation 'what's new' and the release notes for more information.
We are happy to see more community contributors and are continuing our efforts to promote that growing trend, both in the core project and the extensions respository.
I am pleased to announce the first themed release of the Spring Data release train named Arora. Going forward we'll use names of famous computer scientists to label a set of Spring Data modules to make it easier to identify modules being compatible to each other. This mostly refers to the Spring Data Commons version they refer to.
Annotation based auditing support through @CreatedDate, @CreatedBy etc. (except Spring Data Gemfire)
Exposure of Spring Data Mapping information for all modules (to be used by Spring Data REST)
Spring Data Mapping information being read from accessor methods as well
Automatic registration of JodaTime Converters if present on classpath (Spring Data MongoDB)
Major improvements to mapping subsystem and query execution for Spring Data MongoDB
Extended querying options on query methods (Spring Data Solr)
Annotation support for Gemfire functions (Spring Data Gemfire)
A tag has been added to the gfe-data XML namespace for automatic basic client connection and region configuration. (Spring Data Gemfire)
Support for Lettuce Redis driver (raising the count of supported driver to 5, Spring Data Redis)
Dynamic removal of listener for running MesageListenerContainer (Spring Data Redis)
Refined Maven build to ease release process
Alongside the new major versions of the Spring Data Modules we've also published bugfix releases for Spring Data Commons (1.4.1), Spring Data JPA (1.2.1) and Spring Data MongoDB (1.1.2).
Note: The artifactId of the Spring Data Commons module has changed to from spring-data-commons-core to spring-data-commons. So if you're explicitly referring to it from your project, make sure you update the reference accordingly.
The binaries will be present in Maven central shortly if not already in place.
