Yesterday morning I presented a 2-part session at The Spring Experience entitled “Enterprise Integration Patterns with Spring”. The first presentation included an overview of core Spring support for enterprise integration - including JMS, remoting, JMX, scheduling, and email. That presentation also included a high-level discussion of several of the Enterprise Integration Patterns introduced in the book of the same name by Gregor Hohpe and Bobby Woolf. In the second presentation, I officially unveiled “Spring Integration” - a new addition to the Spring portfolio. Spring Integration builds upon Spring’s core support while providing a higher level of abstraction largely inspired by those patterns. Here I would like to provide a brief overview of the topics I discussed in that session. You can also read two articles about Spring Integration that appeared yesterday on eWeek and InfoWorld.
The Spring Blog
I was cruising the blogosphere today and encountered one of the shortest blogs I’ve ever read. To quote nearly the entire entry, “Every time you use Acegi, a fairy dies. The sad thing is there really isn’t anything better around…”.
Between our community forums, developer lists, JIRA, user conference BOFs, training, support, consulting and team blog, we receive a great deal of community feedback. There is little doubt that many people have sought improvements to the Spring Security (formerly Acegi) configuration format, and we’ve invested a lot of time in making that possible.
Since the introduction of Spring dynamic laguage support in Spring 2.0 it has been an attractive integration point for Groovy, and Groovy provides a rich environment for defining Domain Specific Languages (DSL). But the examples of Groovy integration in the Spring reference manual are limited in scope and do not show the features in Spring that are targeted at DSL integration. In this article I show how to use those features and as an example we add bean definitions to an existing ApplicationContext with a Groovy DSL from the Grails distribution.
By popular demand, the Spring Framework Maven artifacts are now being uploaded to the Spring Snapshot Maven Repository. You can find details about all of the Spring Portfolio Maven repositories in my previous post but I’ll reprint the details for the Spring snapshot repository here.
The Spring Snapshot Maven Repository is located at http://s3.amazonaws.com/maven.springframework.org/snapshot. Using this repository requires you to add an entry to the <repositories/> element in your POM. It should look like this:
We’re changing our name. This week, Interface21 will become SpringSource.
As we have built the company, Interface21 has earned a reputation for exceptional products, thought leadership, outstanding people, professionalism and top quality support and services. As we continue to deliver all of those things, we believe that changing our name will help our company bring them to a wider audience.
When I founded Interface21 in 2004, I had to pick a name. I believed Spring to be the future of enterprise Java, and “Interface21” reflected those feelings—the framework for the 21st Century. Now we’re well into the 21 Century. Spring has proven to be more successful than I could have dreamed, and has become a de facto standard for enterprise Java. It’s also growing in popularity on the .NET platform. Millions worldwide have downloaded Spring Portfolio products. All the major Spring committers work here.
Spring Web Flow 2.0 M2 has just released. I am particularly excited about this release because it sets the foundation we need to realize the bold vision we have for our community for the future. In this entry, I’ll explain what that vision is, and exactly what this foundation will enable. I’ll also go into detail about the architecture of Web Flow 2.0, and compare it to the 1.0 version.
The Spring Web Flow 2.0 Vision
* UPDATE: The vision above was updated on 1/11/08 after considering large amounts of feedback from the Spring community since The Spring Experience 2007. Based on that feedback, Spring Web Flow 2.0, scheduled to release in March 2008, will remain focused on the orchestration of controlled navigation and application transactions in a web application, usable as a complement to Spring MVC in an action-based MVC environment and JavaServerFaces in a component-based environment. When used with JSF, Spring Web Flow 2.0 can power an entire JSF-based web application as a “black box” or can be mixed with standard JSF navigation handlers that implement free-navigation requirements. 2.0, therefore, will be an evolutionary release adding first-class support for JSF and Ajax, supporting Java 1.4+, and providing full backwards compatibility with the SWF 1.0 flow definition language.
Spring 2.5 introduces an approach for writing annotated Web MVC controllers, which we haven’t been blogging about much yet… I’ll take the opportunity to give you an overview of what Spring MVC is really about these days.
Spring MVC is essentially a request dispatcher framework, with a Servlet API variant and Portlet API variant. It operates very closely within its hosting environment - either Servlets or Portlets. Think about Spring MVC as providing foundational facilities and conveniences on top of the Servlet/Portlet container: e.g. flexible request mappings, separation between controller processing and view rendering phase, data binding, basic JSP tag libraries that complement the JSTL, etc. The building blocks of sophisticated HTTP request processing.
We recently hosted a webinar on the theme of “Spring in Production.” I promised then to make the recording of the webinar and accompanying slides available on our website. Unfortunately the engineers producing the webinar for us forgot to set the ‘record’ flag, so I need to re-record the session for you :(. I’m traveling at the moment but I’ll try to do that and make it available as soon as I can.
The good news is that there’s no need for you to miss out in the meantime. I wrote a white paper on the topic of “Spring in Production” that covers the material from the webinar and more besides. This white paper is available right now for download.
Last night I attended a New England Java User Group (NEJUG) meeting where Reza Rahman presented a "comparative analysis" of EJB 3 and Spring. Reza is one of the authors of EJB 3 in Action. I enjoyed meeting Reza and respect him for presenting what may be considered a controversial topic. Also I appreciate that he did attempt to address pros and cons for both EJB 3 and Spring. Nevertheless, I feel compelled to clarify a few points that were not wholly accurate in his coverage of Spring and which led me (and other attendees) to believe the presentation was motivated by a bias toward EJB 3. To be fair, unlike a fixed specification version, Spring is constantly evolving and some of the things that I will point out here are new features. On the other hand, some are Spring 2.0 features that have been available for more than a year. I personally believe that a "comparative analysis" must account for the up-to-date feature set of the latest stable version of the products being compared. I think it goes without saying that I might be a bit biased as well, but my motivation here is to provide a wholly objective response so that the presentation could perhaps be revised to reflect a more 'apples-to-apples' comparison. I will provide brief responses to 10 "themes" of the presentation.
Several users have asked whether we are committed to Spring Java Configuration, and how it sits with the annotation configuration option introduced in Spring 2.5. The answer is yes, we are committed to Java Config; and these two approaches are not mutually exclusive.
These two configuration approaches are quite different: the @Autowired annotation in the Spring Framework configures components using annotations in business objects, while Spring Java Config takes a unique approach of externalizing the annotations in dedicated configuration classes. Neither of these approaches is uniquely right or wrong, and they are compelling for different circumstances. There is even no reason that both couldn’t be used in the same application.