Rod Johnson writes:

As an open source software provider, we think we should be open about our strategy, too. We’d like to share how we got here, where we’re going and why the journey will be good for Spring, good for Spring users and good for SpringSource.

Our History

The Spring story began in 2001, when I began working on the 30,000 lines of framework code I published along with Expert One-on-One J2EE Design and Development in 2002. My objective was to help others to avoid the pitfalls that I had encountered completing J2EE projects since 1999.

It quickly became clear that others liked the ideas in that code - such as Dependency Injection and the Spring data access abstraction - and benefited from putting them into practice. I was approached by readers who requested that I publish the code and who wanted to contribute.

I quickly came to see some important benefits of open source.

• Most users get the functionality they need for free
• It develops a strong community, which contributes to making the software better
• Open source is inherently anti-bureaucratic
• Open source can underpin a business model with lower sales and marketing costs than a traditional enterprise software company—meaning better value for customers.
• Open source projects (and, hence, open source companies) can attract developers worldwide, rather than in any one geographical area. This represents a huge pool of talent that isn’t available to traditional software vendors.

Real value, Real cost

These benefits are great, but they don’t suspend the laws of gravity or economics.

No software gets developed by magic. In the case of Spring, we brought together an outstanding group of developers early on. There was a big personal cost to those individuals, which could not have been sustained forever. I spent around 18 months out of the workforce working on Spring and the ideas behind it. This affected my family’s financial stability: we even needed to redraw a significant amount from our mortgage. Juergen Hoeller was fortunate to have an employer who understood the potential savings Spring could deliver in building their software product. However, he soon needed to move to part time work–with a corresponding salary sacrifice–to maintain his commitment to Spring. It was that long, intense, focused effort from Juergen and myself that set Spring up for what it is today. Other core developers like Colin Sampaleanu and Thomas Risberg were able to make a more intermittent contribution, through devoting their own personal time and at a sacrifice of their families and friends. This situation was not sustainable enough to underpin critical infrastructure for the enterprise.

In the long term, all software development requires investment. Not just investment in writing code: investment in maintaining it for the long haul.

We founded SpringSource (then Interface21) in 2004 to enable that investment.

The following year we were able to make our first high profile hire, who helped to increase the firepower of the team and its intellectual leadership—Adrian Colyer: IBM Senior Technical Staff Member, lead of the AspectJ project. This was a big milestone. For the first time we were able to make it possible for someone to work on Spring who couldn’t do so otherwise.

Initially our business was based around consulting and training. It became clear that those businesses could not sustain the level of investment that our user community expected and could not enable the delivery of the vision that we were passionate about delivering as technologists. Our growth was constrained; too many of our best people spent the bulk of their time and energy delivering services, with little left to write software; and we were worried that we would burn out our staff with the level of travel and overtime that we were forced to require.

When Spring 2.0 was released several months behind schedule, we realized that our then business model was a starting, rather than an end point. Also in 2006 our vision grew, as the broadening of the Spring Portfolio and our exploration of the potential of the OSGi and Spring models demonstrated the transformational potential of a Spring-based server platform.

We decided to raise funding in 2007 to realize this vision, and bridge our transition from a services business to a software company that could sustain the creation of top quality software.

The benefit was dramatic. We were able to recruit more star developers into the team and enable them to contribute more to open source. We were able to focus talented product developers among our existing staff toward enhancing and extending the Spring Portfolio. We were able to ensure the future of AspectJ after IBM reduced its investment.

Our record of open source releases in the last few months speaks for itself:

• Spring 2.5
• Spring.NET 1.1
• Spring Security 2.0
• Spring Web Flow 2.0
• Spring Batch 1.0 (co-developed by SpringSource and Accenture)
• Spring Web Services 1.5
• Spring Integration
• Spring Dynamic Modules 1.0
• Spring IDE 2.0
• AspectJ 1.6

All these releases move those projects forward significantly and deliver real benefits to users.

We’re also making significant contribution to other open source projects such as Apache Tomcat, Apache HTTPD (the Apache web server that powers much of the Internet) and other Apache projects, and the Mylyn project at Eclipse.

Our Values

Over the last 5 years the Spring team has evolved from a project team into a company, and our business model has changed from a services business into a software company with an outstanding services capability. Throughout this transformation we’ve maintained our core values. In particular:

• We’ve always been focused on technical leadership and excellence.
• We don’t aim to deliver me-too solutions, but to advance the art.
• We deliver pragmatic technical solutions. Software is only as valuable as the results it delivers in the real world.
• We believe that long-term success in open source business requires significant contribution to open source.
• We’re proud of our integrity. We are honest with our community, our users and customers.
• We strive to deliver the utmost value to our customers.
• We treat our users, customers, partners and competitors with respect.
• We value our community and strive to act in its best interests.

Our actions flow from these values. For example:

• We won’t reinvent a good wheel. We will use existing projects where possible, getting involved in them if we think they are important to our users, as with AspectJ, Tomcat and Equinox. We are the most active contributors to the first two of those projects. To this end, you will see us get more involved in the Apache and Eclipse communities. We aim to be the leading provider of enterprise Java open source, so it’s natural for us to take an active role in the communities behind important open source projects.
• We will create new projects where no good solution exists. Spring Batch is a great example of this—bringing Spring values of power, simplicity and consistency to an area that has been sadly neglected in Java infrastructure.

The strength of these values has helped our company through a period of rapid growth. It has also been a key factor in the success of our integration with Covalent, a long-established open source company we acquired in January 2008. The two organizations had a similar culture, making it natural for the staff to integrate. And it helps us to continue to attract outstanding technical and business talent.

Our (and Your) Software

At SpringSource we develop three types of products, which are distinct:

• Ubiquitous programming models and infrastructure. This covers the Spring Portfolio, as well as AspectJ (which we lead) and Tomcat (to which we are a leading contributor). We want everyone to be able to use these projects. Many of them are de facto standard.
• The SpringSource Application Platform. A complete application server product building on the Spring Portfolio and other Apache and EPL software.
• Enterprise value adds. Value adds to both categories of open source products. We provide these via annual subscription to a commercial license for our customers. They enhance productivity in building Spring applications (as in SpringSource Tool Suite), or the operational experience of running those products in production (as in SpringSource Application Management Suite). They do not define programming model or deployment model, but enhance the experience obtainable by using the first two categories of product. Users are not forced to purchase these value adds (unlike with a traditional software license); they can confirm for themselves that they provide value for money.

Our Business Strategy

We redefined enterprise Java with Spring. Our mission is to continue to provide the technical leadership and solutions to take enterprise Java to the next level. We are building a great software company around this.

Currently there is a stark misalignment of software value delivered and economic activity around enterprise Java. The lion’s share of revenue goes to BEA (Oracle) and IBM, yet significant parts of the runtime their customers use is open source, and the innovations that matter in enterprise Java mostly come from elsewhere.

It’s clear that the enterprise Java market needs fresh solutions and it’s also clear that the market would like the solutions from a open source company. We believe that it will be us.

We make money by:

• Providing world class support and services. This includes dependable 24×7 support, outstanding training and consulting services and indemnification for enterprise customers who are understandably risk-averse.
• Adding subscription products that deliver value to complement the Spring Portfolio.
• Selling subscriptions to enterprise editions of our full-stack products.

Our Licensing Strategy

Our recent release of the SpringSource Application Platform under the GPL v3 has generated much discussion. I’d like to take the opportunity to explain our licensing strategy, and why we believe it is the right choice for the Spring community.

First, let’s be completely clear and get an important question out of the way:

We remain committed to the Apache License (and the EPL) everywhere we’ve used it. However, not all software is alike. Different licenses are appropriate for different products. This year, SpringSource has brought several important new products to market for which different licensing is appropriate.

Licenses other than the Apache License have two purposes for us:

• For additional products available only to our customers. These products satisfy a real need for those customers, and help to sustain the open source software that they and others benefit from.
• To ensure that ISVs and OEMs using our new stack products don’t get a free ride from software we develop for our community, and that software vendors can’t compete with us with our own code. The GPL v3 license used for the SpringSource Application Platform meets this goal, while remaining free to end users or open source usage.
  Let’s consider the second point in detail where the SpringSource Application Platform is concerned. This is a full stack product that competes with offerings from Oracle/BEA (WebLogic, OC4J), IBM (WebSphere) and Red Hat (JBoss). All those vendors recognize that they also need a mature OSGi-based runtime. We have a substantial technology lead in this area. All three will need to do the heavy lifting we’ve done with SpringSource Application Platform’s dm-Kernel™.

Suppose that we published SpringSource Application Platform under the ASL. We could expect these vendors to compete with us in short order and they would likely charge their customers for products that use the technology. Not only would this be unfair, but it would reduce our ability to invest in the product - ultimately hurting the entire community.

So we chose a license that means that end users can freely benefit from our work, but competitors can’t compete with us with our own code.

Where Next?

For years, we’ve created great technology. Today we’re creating more than ever. We’re proud that we’ve helped to drive the transformation of enterprise Java from the misery of EJB 1.x and 2.x to agile development with POJOs. We’ve delivered billions of dollars of value to enterprise customers and we’ll deliver much more in the future.

We’re excited about continuing the story and delivering more, better infrastructure. The enterprise Java community needs a company focused on delivering best of breed solutions. We redefined enterprise Java once with Spring and it’s another new season for enterprise Java with the SpringSource Application Platform . Please challenge us as we challenge the status quo.

Tags: SpringSource

Kas Thomas of CMS Watch writes a thoughtful piece on the pros and cons of the new SpringSource Application Server.

Posted by Kas Thomas
Tuesday, May 13, 2008
5:41 PM

He begins with an overview:

The recently announced SpringSource Application Platform is (according to its creators) “a completely module-based Java application server that is designed to run enterprise Java applications and Spring-powered applications with a new degree of flexibility and reliability.” Spring geeks will recognize it as the long-awaited integration of Spring with OSGi.

The real value-add of OSGi comes in terms of lifecycle management of classes, cleaner isolation of code, and more thoroughgoing code reuse. With OSGi, there’s no need for every deployed web app to hide its own copy of xalan.jar (or whatever) under WEB-INF, as so often happens on J2EE appservers. A bundle gets exposed once, and the various apps that need to use that code can do so without getting caught in classloader hell.

More interesting is that bundles can be hot-swapped without breaking any running apps. You can update part of an app (just the bundles that need updating) without disturbing the rest of the app or having to bounce the server.

There are other benefits as well, but efficient code reuse and the ability to hot-swap code modules are core to what OSGi is about. Which may explain why WebSphere, WebLogic, JBoss, Jonas, and others are moving to (or already have moved to) OSGi-based architectures.

He covers the downside:

Still, there’s a down side to all the wonderfulness. New programming patterns are in play with OSGi (representing a new learning curve for developers), and overall complexity has not gone down; it has merely been shifted around. Also, some people are put off by the project’s GPLv3 license. (Spring itself will continue to use the Apache license, however.)

He concludes that it is a good thing:

My take? The OSGi-powered SpringSource Application Platform represents an important paradigm shift, one that has the potential to revitalize Java EE development (much as Spring itself did when it debuted on the first day of Spring in 2004). How? By raising expectations around code reuse, serviceability, reliability, remote management, hot upgrades that don’t break anything, version-based conflict resolution, and other difficult issues that (frankly) have long needed solving in order for Java EE development to go to the next level.

Tags: SpringSource

Just a reminder that we’re aggregating news & views here, both positive & negative.

Ivan Ristic writes:

I first encountered (and used, in production) Spring Framework in its pre-1.0 days, and it was love at first sight. I loved it because of its vision, a very good design of its MVC and database libraries, and, most importantly, quality (I am yet to encounter a single bug in it, actually). The licence, Apache Software License version 2, was right too. I had even wanted to join the development team, but ultimately decided to focus on ModSecurity instead. Spring had a lot going for it: the Java server-side programming was in a state of disarray. We needed a beacon to guide us.

Fast-forward a few years, and we have Spring firmly established as the leading player in server-side programming. Then, a few more years down the road, the bloat is starting to appear, after the development team (apparently) decided small and focused is not beautiful after all. In parallel with the evolution of the framework, Rod Johnson (the author of Spring) grew his consultancy business, Interface21.

Then, the inevitable happened. The success of Spring became too tempting. Interface 21 sought venture capital, changed its name to SpringSource, and went on to buy Covalent (or merge with, depending on whom you ask), a quiet but persistent company, also in good standing with the community.

My fear, when I heard the news of funding, was the same as Corby’s (from a post at InfoQ):

If anyone had the ability to grow organically, I thought Interface21 did.
VC don’t give you money unless they’re going to grow you 20X. I am very
concerned about seeing an explosion of Spring subprojects that lack the
quality or the relevance of Spring core. And VC don’t give you money
unless you’re going to cash out. I don’t see Interface21 operating as a
standalone IPO, so that means they will be actively seeking
acquisition. I hate to see one of the big guys get ahold of this very
independent entity.
I wish the Interface21 folks great financial success, but I hope Spring
does not turn into a bloated, slow-release monster. I have already
heard rumors that Benchmark Capital is pressuring Rod Johnson to change
his name to something more kid-friendly.

Things started to go wrong after SpringSource had decided to experiment with their licensing strategy. They introduced a number of proprietary products and started using other open source licences. Their most recent product, SpringSource Application Platform, is licensed under GPLv3, in stark contrast to ASLv2 used for the framework itself. (GPL allows business to essentially retain control of the code base.) The changes made many members of the community feel insecure, and lead to heated exchanges on the forums. Prior to the changes the company was often called a darling of Open Source (it sounds like something I would have said too), because they were a rare example of someone building a business (Interface21 consultancy) around the restriction-less Apache Software Licence. I can only conclude that, under the changed circumstances, their business was not growing fast enough, and that they felt that they needed to do things differently.

This story is a clear demonstration of the challenges facing open source commercialisation. Where we previously had a clean separation of the project and the company, now we have a company that is using the project to build a proprietary business model around it. They may still be contributing to the open source parts–today–but do you trust them they will continue to do so? SpringSource are saying they are on the same path they have always been. Maybe they believe that, but they are not, and users see it. SpringSource are saying they will keep the Spring Framework alive and open source. I actually believe they are being honest when they say that. But I also know that people come and go and that, eventually, the prosperity of the company may matter more at some point in the future.

Let me be clear when I say there is nothing wrong with making money of your work, be it open source or not. It’s the change of direction that’s making everyone nervous. For many people open source is about freedom and certainty. They don’t want to have vendors to depend on. They’ve chosen to work with Spring Framework on the basis it’s vendor-free. So it’s not surprising that they are starting to feel twitchy now that they’ve realised the company behind their favourite project is a vendor too. If SpringSource want to preserve their hard-earned credibility they need to act fast to insulate themselves from the core Spring Framework project. It’s certainly a tough thing to do (convincing the VCs, I mean), but it’s the only thing that would bring the user trust back.

Tags: SpringSource

Rod Johnson, CEO SpringSource, writes:

Spring Security 2.0 has been released. This is a major step forward for the Spring Portfolio. Spring (Acegi) Security is already the Java platform’s most widely used enterprise security framework, with over 250,000 downloads on SourceForge and over 20,000 downloads per release. Through making it so much simpler to use, this release will undoubtedly take adoption to a new level.

I’m particularly pleased about this release for a number of reasons:

• It’s a great thing for the Spring community. It’s (a lot) simpler to use, as well as more powerful. It puts the most powerful enterprise Java security solution within the reach of many more users, pretty much eliminating the hurdles to adoption. See this tutorial for an example of just how much easier it makes it to secure a typical web application. The proliferation of XML bean definitions is a thing of the past.
• It’s a continuation of the work of Spring 2.x, through applying the power of a custom XML namespace to enable aggressive defaulting, while still allowing for customization.
• Like Spring 2.5, it exhibits the current Spring Portfolio trend toward radical reduction in the need for XML.
• It’s a proof of the value of the SpringSource business model. Our revenue model enables us to invest more than ever in creating open source software. Without being able to hire both Acegi/Spring Security creator Ben Alex and the other major committer, Luke Taylor, this release either wouldn’t have occurred or would have been much less extensive.
• It’s good for the fairy kingdom.

Acegi/Spring Security creator Ben Alex and Luke Taylor have done a great job. Ben will be talking about Spring Security at Java One next month. If you’ll be in San Francisco then, it will be a great opportunity to hear about the new features and get a chance to talk to the guy behind the product.

Download here.

Tags: SpringSource

Thanks to Scott Davis of aboutGroovy for pointing this out.  In an InfoQ interview with Keith Donald and Jeremy Grelle, Groovy and Grails seems to figure prominently in the next version of Spring Web Flow 2.1.

I think you’ll also see us explore scripting languages as means of defining control flow in the 2.1 release. Grails, which builds on the Web Flow 2 engine, has already shown that a Groovy-based flow definition language is viable, and we are working with Graeme on incorporating his GroovyFlowBuilder back into Web Flow proper. In addition, I think there is real opportunity in broadening the flow definition language into what I call a “site definition language”, where you can define an entire site macrostructure declaratively, where some of the site elements are flows. Jesse James Garrett’s Visual Vocabulary is really an inspiration for some of these ideas, and I think there is a lot of interesting work to do in this area.

The entire interview can be found at InfoQ.

Tags: Groovy Grails, SpringSource

James Sugrue interviews SpringSource COO Neelan Choksi at Dzone.

James Sugrue: Could you give me a brief overview of what SpringSource Enterprise is?

Neelan Choksi: There are three main parts to the product:

• Spring Enterprise Edition - the enterprise version of Spring which is certified, warranted and indemnified. This includes the latest bug fixes as well as enterprise-class monitoring integration.
• SpringSource Support - support from the source maximizes production uptime, developer productivity and application performance using Spring
• SpringSource Performance Suite - applications to ensure that customers develop, test and run Spring applications effectively.

Sugrue: What was the motivation for the product?

Choksi: Spring software has been downloaded more than five million times, and is now the ubiquitous platform for applications throughout the world of enterprise Java. With SpringSource Enterprise, customers receive stable, secure and trusted downloads and support directly from the creators of Spring.

SpringSource Enterprise is available as a subscription based service, with three levels (silver, gold and platinum). It’s a natural evolution of where we’ve come as a company. Spring started when Rod Johnson wrote J2EE Development without EJB. From there we became an open source project, and as we grew we became a consulting organisation. We found that the consulting could be mitigated if we provided more training, and now we’ve reached this level of support for our enterprise customers.
Sugrue: With three levels of support, how do you guarantee quality assistance 24/7?

Choksi: The platinum level of support is the highest, which gives a 1 hour response time. We have support engineers based in Canada, Austria and the UK. So we use a “follow the sun model” with our support team spread right across the globe.

Our tier 1 support comprises of about 10 people. But we ensure that our product developers are close to the support team. This ensures that we always have a relevant offering for the community, and also stops any notions of an ivory tower. Product development are 25% customer facing, be that with support, consultancy or sales. This is one of the key parts that makes Spring what it is today – encountering and solving the real problems that customers face.

Sugrue: That’s a really nice model. Where did you get the inspiration for it?

Choksi: Well, McDonalds have done this forever. Everyone from the CEO down has to spend at least some time customer facing, at the tills.

In the earlier years of Spring, Rod would work on consulting and training material as well as product development. He believes that witnessing the full lifecycle is a big part in staying rational and sane. It’s also Rod’s strongest argument against the JCP – there are some specification writers that have never written a J2EE app.

When people join SpringSource, it’s not unusual for them to meet Rod one or two days in. In fact, I remember on new employee pair programming in a bar with Rod just after meeting. Again, it’s a concept of having no ivory towers.

Sugrue: What has the uptake been like so far for SpringSource Enterprise?

Choksi: All the releases have been in beta so far. But the downloads and the feedback has been really good and positive. Support has always been popular and a lot of customers want a portal. Managers want to see how much developers are using it and want access to this knowledge network and see all questions that have been asked.
We’ve bundled four and a half years of experience into the knowledge network.

Sugrue: What do you provide with this that isn’t obvious using Spring as an open source tool?

Choksi: The Tool Suite is a combination of Spring IDE, AJDT and Mylyn. The three core open source component provide us with the key difference – it’s like a consultant in a box. Using Mylyn, the knowledge in the developers and support team’s heads is made accessible to you right in your IDE.

With Mylyn as part of the toolsuite you get task focussed help and runtime error analysis with common causes and their appropriate fixes. This results in a massive productivity gain.
Sugrue: SpringSource recently acquired Covalent. How is that working out, and what does it mean for the immediate future?

Choksi: The main point of the acquisition is that we can provide Tomcat support direct to our customers. Covalent is now a SpringSource division, so we can provide HTTP and ActiveMQ support. The combination of Tomcat, Spring and ApacheHTTP drove the deal. It’s a cultural fit.

The size of SpringSource has quadrupled in the last 18 months, so for now we are focussing on the execution of first class support.

Sugrue: When do you expect to release Spring 3.0 and what can we expect to see included?

Choksi: Spring 3.0 is built for Java5, so we take advantage of features like annotations and generics. We will also support the latest version of JavaEE, with things like profiles.
We want the framework to be the core foundation technology for creating web applications over enterprise applications. Spring MVC has been completely rejuvenated. Annotations have brought it to forefront of modern technologies like Ajax.

We’re adding REST support to Spring and adding in a Spring Expression Language, so that you can switch configurations between platforms. There’s no exact date for release available just yet. We plan to have an Early Access build around Q3, with a final release scheduled for Q4.

Tags: SpringSource

Ryan Headley writes:

For a number of weeks now, my primary 8 to 5 job has been working with Grails as well as attempting to bring someone from the .Net world along with me. I’ll say he’s coming along, though seems to be doing things in the straight out “Java” way, which is fine when working with Groovy/Grails…matter of fact, I think its a selling point.

Now where one would think that Groovy should be easier to learn, there are still loads more “recipes” on the net for traditional Java and this is where my colleague is getting his information. In a way it bothers me that he doesn’t seem to want to learn to do things the “Groovy” way, I find myself not so worried about since I know it will run (its Java after all). That’s a beautiful thing when you think about it. He can learn from real world Java examples, and then adapt them to the Groovy way of doing things. Now, I’m not a .Net guy and I don’t pretend to be, but he keeps mentioning that he’s not used to all of this “blackbox stuff” going on. (Referring to all the nifty things Grails does for you) so I think that is why he is doing things the more traditional way…because its familiar. And it works!

I can’t say enough about my experience with Grails thus far. Grails makes me want to go out and find good..scratch that…CHEAP Java hosting. Not that I want to abandon PHP, I’m still a PHP guy, but Grails has got me excited about Java again. The layers are still there but for 80-plus percent of the folks out there, Grails does the right thing for you and you needn’t worry about your hibernate configuration, or your Spring setup, etc. (To be honest, I could hardly fight my way through that sort of thing anyway, which is probably why I’m digging the Grails thing).

It works, and its concise (at least when compared to its mother language). I’m pretty sure that I’m beginning to annoy my fellow colleagues that are still working on traditional Java. I’ll be working away on something in the Groovy/Grails world and come across something that just makes me giddy, and I feel a smile form on my face, and perhaps even get the giggles. Then I’ll have to run over to anyone who will listen and say “Check this out…” I’m pretty sure there gonna move me to the basement and turn the light out, (”I believe you have my thtapler”).

I’ve been complaning alot about people griping an not giving examples, so here’s a quick example of how you’d read in a form and populate an object in grails…are you ready?:

In the controller–(example, saving a person)

person.properties = params
person.save()

Are ya kidding me? Thats all I had to do? What if I’m sending parameters from my form that the object doesn’t have? It doesn’t care, it just won’t do anything with it. How’s that for getting something done.

Sure, scaffolding is cool, helps ya hit the ground running, but there’s oh so much more than that. Again, I can’t say enough about it, and I’m only just starting out with it.  The current project isn’t exaclty HUGE or enterprise level (yet), but it will grow to be bigger than its current implentation and new features will be getting added for a long time to come, so I’m sure there will be a number of rants as well. For now however, I’ll remain sitting back in my chair at work, quietly giggling…hope that doesn’t make me creepy!

Finally, if you are at all interested in the Groovy/Grails world, I HIGHLY recommend “Groovy Recipes” by Scott Davis. If you’ve ever heard Scott speak, (and enjoyed it like I did), then you’ll love the book because its written just as he speaks. Clear and concise, (much like the language the book covers…) and delivered very well. Perhaps I’ll have to give it a full review in the near future.

Anyway, I’ve sucked up enough time today…gotta go get my giggle on…

Tags: Groovy Grails, SpringSource

Dion Almaer writes:

One Response to “Consilidation in the Open Source Java Stacks?”

1. Stephan Schmidt Says:
   April 15th, 2008 at 1:27 pm In June 2007 I wrote as a comment to someones blog post:

   “I believe the Java stack started with Apache incubating alot of projects and incorporating even more (like lucene). JBoss followed by buying open source developers (Hibernate, the King) and Spring almost started as a stack.

   Obviously in the last years all stack providers aimed to complete their stack and reduce the risk that their users would switch to another stack or incorporate technologies from another stack.

   Beside Apache I think you forget the Grails stack. From my feeling it’s much faster growing then the JRoR stack.”

   One year later I still believe this is the way things flow in open source Java land.

   Peace
   -stephan

Tags: Groovy Grails, SpringSource

Ken Rimple explains the basics of Spring WebFlow and concludes that Spring WebFlow is easier with Grails.

He begins:

Everyone has had to code an application at some point where they were forced into a particular set of navigational flows. There are a few ui-centric workflow packages out there, including Open Symphony’s OSWorkflow, and Spring’s WebFlow. Other developers at my shop have worked with WebFlow and were pleased with its features. But did you know that Grails embeds WebFlow and makes it available within its controllers automatically?

He covers the basics of WebFlow:

For a thorough introduction to Spring Webflow, I suggest visiting the SpringSource site. However, in general, webflows can be broken up into distinct components:

• State - This is a ‘definable moment’ within the webflow, such as a View State, where the application is waiting on user input.
• Transition - An event, often fired by a user taking an action, that moves the webflow from one state to another.
• Action - Code that can be performed within a transition, or on the start or ending of a given State
• View - A (GSP) page that is rendered during a ‘view state’.
• Flow Scope - A semi-session-like container that lives for the life of the webflow. Data captured from one view to the next

He concludes:

Without too much more ceremony, I can simply say that although Spring WebFlows are a great feature, and take a lot of pain out of implementing flow-based application logic, they are made even easier by Grails.

For more Flow goodness, check out the grails documentation page on it.

Tags: Groovy Grails, SpringSource

Rod Johnson, CEO of SpringSource, blogs:

If the tech community were to host their own version of the popular TV show The Biggest Loser (or maybe Celebrity Fit Club) you would see enterprise Java front and center—bloated, overweight, tired, and drained.

The future of enterprise Java is becoming clear. The morbidly obese legacy platforms are in decline, with leaner solutions increasingly used in production as well as in development. Legacy technologies such as EJB are becoming less and less relevant.The lukewarm takeup of Java EE 5 leaves it looking increasingly like the last gasp of traditional J2EE bloatware. Meanwhile, the Java EE 6 specification is finally set to allow for greater modularity, in a radical change which will have important implications for developers and is likely to rejuvenate competition among implementations. As the standards and the products based upon them have gathered pound after pound of cellulite, SOA, Web 2.0 and other infrastructural changes continually impose new requirements that were not foreseen when J2EE was conceived a decade ago, as a chubby but cute baby.

So much for the past. What does the future hold?

I think the big picture is one of an exciting period of change. Analysts at Gartner Group agree, writing in the report Trends in Platform Middleware that

The popular Java Platform, Enterprise Edition (Java EE) and .NET platform middleware technologies are increasingly inadequate to cover needs for extensive scalability and performance, event-based programming styles, advanced service-oriented architecture (SOA) and dynamic application developments.

Here are my predictions:

• We will once more see real competition in the application server space, rather than a continued monopoly of a decreasing number of large vendors. Through version 5, Java EE did not serve the needs of the developers and their organizations so much as the needs of vendors who were protected from competition by the many cumbersome and irrelevant legacy APIs that needed to be implemented by any new entrant. With Java EE 6 needing to embrace modularity to remain relevant, renewed competition is likely.
• Tomorrow’s application server will have a dramatically smaller footprint than the Jabba the Hut of today. The patients must lose hundreds of pounds or perish. Consider another analyst comment:
  

  Consider the trend (over the past year or two) by Web CMS vendors toward embedding, bundling, or otherwise targeting Tomcat as a runtime framework instead of, say, JBoss. If all you need is a servlet engine and web server, why bring along EJB runtimes, a JMX framework, JAAS/JACC, and all the other scaffolding that comes with a full-blown J2EE appserver?

• The application server of tomorrow will not merely implement JCP specifications. With the rise of OSGi on the server side and the emergence of SCA, the JCP is no longer the sole source of specifications relevant to enterprise Java. The ubiquity of open source and the emergence of open source de facto standards introduces another element in the mix. A small number of open source projects are now more relevant to the majority of enterprise Java applications than the majority of the specifications that make up Java EE. This must ultimately begin to affect the characteristics of application servers.
• The market will need to address the gap between Tomcat and WebLogic/WebSphere. Currently an important part of the market is neglected. The majority of Java web applications are most at home on Tomcat. A minority actually want some of the more esoteric functionality of a full-blown application server, such as JCA, or specialized capabilities such as distributed transaction management. But a larger minority need some of the operational and management features of those products, but are not interested in the esoteric APIs and the bloat they bring along with them. As more and more end user companies look to phase out legacy application servers in favor of better suited technologies, there will inevitably be a response to market demand, with products that hit the sweet spot and bridge this gap.
• The gap between application servers and ESBs will be bridged. This is a logical consequence of the rise of POJO middleware. The same underlying platform should be able to address web and SOA requirements. Spring already provides a consistent component model across different deployment scenarios (something that Gartner have also repeatedly mentioned); a similar consistency of the rest of the platform is overdue, and likely to develop quickly as the dead hand of legacy J2EE ceases to hold back progress.

In my next blog on this topic, I’ll look at some of the technologies likely to play a role in tomorrow’s lean and powerful platform infrastructure.

Tags: SpringSource