Spring in Practice

December 1, 2008

Rod Johnson’s keynote address at SpringOne Americas 2008

Filed under: SpringOne — Willie Wheeler @ 10:44 pm
Tags: , , , , , ,

I’m at SpringOne right now, and very much enjoying the Westin Diplomat. My room is on the 21st floor and it overlooks the Atlantic. My balcony door is open and I can hear the waves crashing on the shore as I write. This is how life should always be. :-)

I attended Rod Johnson’s keynote a couple of hours back. The keynote itself was informative, offering a pretty good glimpse into where SpringSource sees itself going over the coming year, and I had a chance to chat it up with Thomas Risberg and Colin Sampaleanu just a little bit since we were all sitting at the same table. Recognizing an opportunity when I see one, I asked them when they thought Spring 3 would be coming out and they laughed in a way that suggested that this wasn’t the first time somebody had asked. Right now they’re shooting for late March or thereabouts, though that was just their impression as opposed to a definite statement.

Anyway, here are some highlights from the keynote.

SpringSource in 2008

Rod started the keynote with some SpringSource efforts and accomplishments over 2008. I won’t go into those in detail, but he mentioned several items, including

They’ve clearly been a busy company over the past year, but it may not be entirely clear what they’re up to. (Well, part of it is clear enough–they’re moving into the app server space.) The next part of the keynote explained where SpringSource is going as a company.

SpringSource in 2009

Rod noted that 2008 has been a tough year for the world economy in general, and thus one reasonable prediction is that that’s going to translate into pressure on IT budgets. One development he expects to see is license costs coming under increased scrutiny. Another is that he thinks IT will begin paying more attention to the costs associated with complexity, and will invest more in reducing that complexity.

I know from my own workplace that his ideas here are correct. Even before news broke that everything’s melting down, we were reevaluating our license situation and indeed even in some cases making changes. And one of the themes that our CIO has sounded time and time again is that we need to work to reduce complexity when we can. I suspect that these are common themes anyway, but with the tough economic times it’s pretty easy to believe that one can build a business strategy around this, and that’s what SpringSource is doing.

The SpringSource strategy: help customers control costs by managing and reducing complexity

This was really the theme of the keynote and Rod noted that they’d even changed their tagline to reflect it: “Weapons for the War on Java Complexity.” He explained how the various efforts over 2008 are generally aligned with managing complexity on different fronts. For example:

Continue targeting complexity in development by expanding the Spring Framework in a way that simplifies application development. Rod showed how with each new release of Spring, the SLOC for the pet store application dropped. He highlighted Spring Web MVC, Spring Web Flow and the acquisition of G2One in particular as representing a continued commitment to simplifying application development. Another notable item here includes Spring 2.5-style configuration via annotations.

Spring 3.0 moves the platform further along in this simplifying direction. Some highlights:

  • Spring 3.0 will support EL in XML configuration and in annotations. He didn’t say exactly where this would appear.
  • Spring Web MVC will provide first-class support for RESTful web services. The match is strong (Spring Web MVC already has a @RequestMapping attribute that serves well here), and RESTful remoting is simpler than say SOAP-based web services.
  • With Spring Web MVC, developers should adopt the annotated POJO model as Spring 3.0 will deprecate the Controller hierarchy and 3.1 will probably eliminate it altogether. Again the argument is that this is simpler than XML configuration.
  • Spring Web Flow should be seen not as a niche technology but as a core part of their web framework that potentially applies any time there’s a directed navigation requirement. Examples include wizards, back button, refresh, multiple UIs, and UI reuse.
  • Speaking of their web framework, they’re treating the following four projects as constituting a coherent, layered set: Spring Web MVC (the core), Spring JavaScript and Spring Web Flow (sitting on top of Spring Web MVC), and Spring Faces (sitting on top of the other three). He said that historically Spring hadn’t simplified web development as much as it could have, and their converging the four aforementioned web technologies into a single group is an effort to address this.

Finally (we’re still on the topic of managing complexity in development), Rod suggested that we take a look at @Configurable (which was available in Spring 2.0) and consider it a “secret weapon” against complexity.

The other major way in which SpringSource aims to manage/reduce complexity:

Target complexity not only in development but also in operations: Though it’s by no means unanimous, lots of people feel that Spring has done a pretty nice job of simplifying JEE development. Their idea is now to take that to the data center. Their commercial offerings align with this; for example, the Application Management Suite provides deep diagnostics for Spring-based applications, and the dm Server aims to make release management simpler and more flexible. Besides their commercial offerings, their investment in Covalent Technologies (better access to Apache and Tomcat expertise) represents a desire to strengthen their offering in hosting and operations.

They see Tomcat as being the platform of choice where WAR-based deployments are concerned, but they see server-side OSGi as the wave of the future. Because Tomcat is currently widely deployed (I think Rod said something like 70% of enterprises have deployed Tomcat?), SpringSource wants to be involved there, and that’s why they bought Covalent. But at the same time they are trying to encourage their customers and indeed the industry at large to make the transition to OSGi-based deployment.

And this leads to a couple of announcements he made.

A couple of product announcements

tc Server: The first announcement was that SpringSource will be releasing another server product to complement their current dm Server offering. This one is called tc Server for (you guessed it) Tomcat Server, and the idea is that it’s an enhanced version of Tomcat, one that includes management functionality to make it “ready for the data center.” The AMS product comes with it, and it will provide features such as visibility into Tomcat and app performance stats, deadlock detection, heap and thread dumps, and stuff like that. It will also be possible to manage tc Server WAR deployments through AMS. They’re expecting (if I understood correctly) a GA release in January 2009.

Rod emphasized that the Spring Framework itself would remain server-agnostic, despite the fact that SpringSource is a server vendor.

SpringSource Application Platform Configurator: The second announcement is that SpringSource will be making available a web application called the SpringSource Application Platform Configurator. Again, managing complexity is the driver here. This time they are addressing the complexity associated with managing dependencies between JAR files, eliminating version conflicts, and that sort of thing. The idea is that you go to this app (which they host), and you specify a bunch of parameters such as the app type (web app, Grails, batch, etc.), whether you’re OK with including pre-release software (such as milestone releases) or whether you allow only GAs, what sorts of capabilities you want and where your religious allegiances lie (is it OK to include JSF? is it OK to include Flex?), what hosting provider you’re using (WebSphere, WebLogic, dm Server, etc.), what OS, etc. (By the way, they don’t explicitly ask “where are your religious allegiances,” but Rod noted that they recognize this reality of how software is sometimes chosen and the configurator is designed accordingly.) Then at the end you register (free), get a text dump of the JARs you just chose, and get a dynamically-generated ZIP containing those JARs (and they’re of course mutually consistent so as to avoid versioning conflicts). That’s a cool idea. They don’t know though when this will be available for use; it’s not even in beta yet.

Well, there you have it. If you weren’t at the keynote, now it’s as if you were. :-)

I’ll post more as the conference progresses. Here’s another post on the same keynote.

[Update: Here's a related InfoQ article.]

October 1, 2008

Some thoughts on the new SpringSource maintenance policy

Filed under: Meta — Willie Wheeler @ 10:38 pm
Tags: , ,

At the risk of getting myself involved in a highly charged political issue, I have some thoughts about the new SpringSource maintenance policy that I wanted to share. Not sure that I know what I’m talking about, but I have no doubt that others will let me know if I’m totally off-base.

Initially I was a little disappointed when I heard the news about the change. I don’t have anything against capitalism, and I think that the Spring developers absolutely ought to benefit financially from all the good work that they’ve been doing over the years. The disappointment was really just a function of my being a bit of a cheapskate: I’m happy to contribute on the forums, contribute JIRA issues, even the occasional code patch, but I suppose I’ve grown too used to being able to download the latest and greatest for free.

But I found out that I misinterpreted the part about “major” releases in an important way, and now I feel a lot better about things.

I thought that SpringSource was saying that the community would be able to download binaries for 3.0, 4.0, 5.0 etc. for free, as well as 3.x (x > 0) releases as long as the 3.x releases were released within the first three months of the 3.0 release.

I’m happy to report that that’s totally wrong.

It turns out that the community will have access to binaries for 3.0, 3.1, 3.2, 3.3, etc., as they appear. The for-pay releases will be the 3.1.x (x > 0) releases that come out three months after the initial 3.1 release. Don’t take my word for it though. It’s right here and here too.

I can definitely live with that. Sure, I’d prefer to download 3.1.5 for free, but it’s not going to kill me to wait for 3.2. I think that there are probably a lot of developers who would feel the same way.

I have to wonder, though, whether SpringSource might do a better job explaining the change. It’s pretty easy to read

After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues.  Subsequent maintenance releases will be available to SpringSource Enterprise customers.  Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.

and think that you’re going to have to wait a year for an update. I interpret “major version” as meaning Spring 2, Spring 3, etc. Maybe that’s not the way SpringSource thinks of major versions (though that’s news to me), but it doesn’t really matter what SpringSource thinks – what matters is what the Spring community thinks, and I can’t be the only one who read the above passage thinking that we’d have to pay for version 3.3.

My understanding is that this change is about getting enterprises to start paying for Spring while letting smaller shops and individual developers still have access to pretty recent stuff. Enterprises are slower about upgrading versions. So say you’re an enterprise and you built an app against version Spring 3.0.2. It’s more painful for you to upgrade to version 3.1 than it is to just buy the enterprise license and get your 3.0.x upgrades, so you buy the license. On the other hand, smaller organizations are in many cases fine with going from 3.0.2 to 3.1, as are many individual developers (indeed, I think a lot of individual developers eagerly await new releases), so they can still use it for free without too much inconvenience. No doubt some smaller organizations and developers will be inconvenienced though.

If my understanding is correct, I think SpringSource ought to consider explaining it in roughly that way instead of this:

“The maintenance policy provides IT teams responsible for building and running mission-critical production systems with the quality, assurance and peace of mind that comes from reliable, predictable and guaranteed support direct from the source,” said Mark Brewer, vice president of enterprise delivery for SpringSource. “And, the policy will always give the developer community access to the same cutting-edge innovations they have come to expect with Spring.”

When developers read the above, they hear “blah blah blah.” Developers hate that kind of explanation. I assume that since Brewer is VP of enterprise delivery he’s addressing enterprise customers more than he is the community, but (1) it’s important to address the community since you don’t want people defecting from the platform, and (2) there’s a way to present the explanation so that it’s palatable to enterprises. I am myself in corporate IT leadership, and if somebody told me that the enterprise license allows you to get bugfixes without having to upgrade from 3.0.x to 3.1, I would be able to see value in that.

Anyway, I’m glad to discover that the situation is not what I had originally thought, and to my mind SpringSource is striking a reasonable balance between their desire (and right) to build a profitable business around Spring vs. their desire to maintain a supportive developer community. They just need to work on the communication. :-)

Blog at WordPress.com.