I think the Spring Framework's inception was like that of any successful piece of open source software, which is it came from developers with an itch to scratch. Originally I developed the core ideas of the Spring Framework in the context of my first book on J2EE architecture, and my motivation for doing that was having a better solution to some of the problems that I was seeing as an architect and developer. In particular, clearly in the days of J2EE 1.2 and 1.3 in particular, the platform was extremely complex. There were many patterns that actually turned out to be anti-patterns. Spring was designed to try to cut through some of that complexity, and as we like to say, make the right thing easy to do.
2. What are the main goals of Spring? What's the philosophy behind it?
The philosophy behind Spring is to make simple things simple and complex things possible. That isn't something of course we coined, it was actually coined I think by Alan Kay the creator of Smalltalk. With Spring we aimed to remove the hurdles, to remove the incidental complexity that prevents you from doing your job if you are a developer. If you are a developer for example working in a bank or working in an insurance company you want to be focused on that domain. You want to spend your day thinking about banking or thinking about insurance. The problem is that traditionally infrastructure and enterprise Java hasn't done a great job of abstracting complexity and removing it from your business logic. The fundamental goal of Spring is to enable business logic to be implemented in POJOs and to completely hide infrastructural complexity. Obviously you are never going to get to that 100% point but we do really try very very hard to have a clean break between your business logic, which shouldn't depend on the framework, shouldn't depend on a particular runtime environment, and the infrastructural concerns that we manage.
There were quite a number of projects in the Spring Portfolio. Some of the most significant projects, apart from the Spring Framework which sits at the core; Spring Web Flow, that is a next generation web framework for developing sophisticated web applications; Spring Security, which is a rebranding of Acegi Security for Spring which is a very long established and mature product; Spring Batch, which is a more recent project that is being co-developed between Interface21 and Accenture; Spring Dynamic Modules for OSGi, which is an integration of the Spring component model with the OSGi module system. There are also a number of community led projects such as Spring RCP, which is a rich client framework for Swing development, and also Spring Modules. Other projects include the Spring Java Configuration project, which I spoke about yesterday at QCon.
The Spring Framework provides, fundamentally, a very powerful component model and a focus on enterprise services. It does include the Spring MVC web framework. Spring Web Flow is a next generation web framework, which is focused on managing conversational state and interactions that span multiple requests. If you think about a traditional MVC model whether with Spring MVC, Struts, WebWork, any of those kind of technologies, they are all pretty much the same. There really isn't that much difference conceptually between Spring MVC and Struts, there is a difference in implementation but conceptually what you end up with is typically a class that processes a particular request and then a template that renders the view. The problem with that model is that oftentimes it doesn't accurately reflect how we think about the process.
Sometimes it reflects it very well. So for example if you have a website that has a lot of free navigation, that model is perfect -- you go to a particular URL, a particular class processes that request, generates a response -- that makes perfect sense. But imagine for example you're booking a seat on an airplane. Now it no longer makes sense, because if you were doing that with the traditional MVC model, what you would end up with is the interaction being managed by the developer, not by the framework. So there would be management of session state and there would need to be the management of the certain number of steps through the process and for example whether it was possible to go back. Previously with Spring MVC we did have a capability for handling wizard flows but it really wasn't very sophisticated.
To get sophisticated support for such cases what you really need to do is model the conversation or flow as a first class citizen. So for example if I am going to book a seat on an airplane, there exists a first class concept that we call the flow, which is that set of steps in which I could go forwards, I could go backwards, I could launch a subflow, like for example entering my air miles number or applying for the airline's air miles program. And in Spring Web Flow the notion of the flow is handled as a first class citizen. We have recently announced the development on Spring Web Flow 2.0. This is a very major release. Two of the key goals are to insure that Spring Web Flow has the best possible integration with JSF and we believe that it will have the best integration with JSF of any web framework. And also to insure that Web Flow was not only an excellent solution for complex interactions but it is also an excellent solution for simpler interactions. So, ensure that even if you were trying to do something that is less sophisticated, Spring Web Flow is still going to be a simple, productive technology for doing that.
5. That seems to match very closely with the philosophy of Spring that you mentioned earlier.
Well I think, Ryan, the fundamental concepts are very consistent across the Spring Portfolio. Clearly the Spring brand is something that has a great deal of value, and it would be very destructive to the community around Spring to brand things that didn't share the values and architectural principles and indeed the quality of Spring, as Spring. So the things that you will typically see in a Spring Portfolio project is the combination of simplicity and power. We have a very strong view that partly comes out of the fact that Spring is extremely heavily used in large enterprises. We have a very strong view that you must never leave the user hitting a wall.
So it's fine to have a naïve solution that handles simple cases, but what happens if there is a more complex case? Can the developer go every step of the way with the framework and find for the more complex cases that they still have a good solution? If you look across the Spring Portfolio you see that combination of simplicity and power, where essentially each of those projects makes something easier. But on the other hand, they also use a lot of architectural principles that are very common, very core to Spring such as, for example, the notion of pluggability. We're firm believers in the use of interfaces. If you look for example at Acegi Security for Spring or you look at Spring Web Flow or Spring Batch, you will find that there are lot of strategy interfaces that enable you to customize very deeply how the frameworks work for advanced scenarios.
6. One of the other projects that you have mentioned was Spring Batch
Spring Batch is an interesting project because it's co-led between Interface 21 and Accenture. It's actually one of the first significant movements within Accenture to embrace open source, and indeed not just embrace it, actively participate and create open source software. The motivation for Spring Batch was that Accenture saw that, world-wide, they had many projects that were doing batch processing in Java. Batch processing is something in which Accenture have decades of expertise. So they had some valuable insights into the kind of things that they saw coming up again and again across projects. They also saw that, as in most of their Java projects these days, their batch projects in Java were using Spring, so they wanted to have a consistent solution that they could use across different projects, they wanted it to be open so that clients weren't locked into Accenture and they felt that Spring and the Spring community was the ideal way to achieve that.
That's a very interesting partnership which I am really quite excited about. We do have already pretty good support for Spring in tooling. The two products that have the best tool support out there for Spring are Eclipse with the Spring IDE plugin. Spring IDE is a very powerful plugin that enables you to visualize your Spring beans to refactor seamlessly across Java and Spring configuration, for example if that configuration is in XML, and also to navigate through your application, so you can go straight from an XML bean definition to the source and vice versa. So that project gives really good tool support in Eclipse, but it is also important to note that in IntelliJ 7, the Spring support is really very very good in the IntelliJ products.
So Eclipse isn't the only game in town. Having said that, the Spring tooling initiative that we have undertaken with Tasktop Technologies is focused around Eclipse and specifically it is focused around the Mylyn Eclipse environment. This actually comes back to my points about the commonality across the portfolio. Looking at what Mik Kersten has achieved with Mylyn, there are clearly a lot of values that are very similar to what we have tried to do in Spring. So for a start, one of the things that we're really proud of in Spring is that we don't just commoditize something that is out there commercially. For example it wasn't like the Spring Framework was a zero license cost dumbed-down version of some commercial software.
It created a new product category. And indeed there have since been some commercial imitators of parts of what Spring does. We saw a lot of the same values in Mylyn. We really think that Mylyn is a stunningly good idea, I think Mik Kersten is a true innovator in the tooling space. And we think that Mylyn has the capability to provide dramatically enhanced productivity for Java developers. We think that is true regardless of whether you use Spring, but if you are using Spring we are going to be providing an Eclipse distribution based on Mylyn and also incorporating Spring IDE, AJDT, all the various plugins that you would want as an enterprise developer using Spring. And we believe that will harness the power and focus of the task oriented approach in Mylyn and make it very very relevant to Spring developers.
We are going to be previewing that product at The Spring Experience show in December and we are going to be doing this in a mixture of open source software -- so significant improvements to AJDT, Mylyn and also Spring IDE -- and also software that is available to Interface21 support subscription customers. Our subscription customers will get the full tools suite, they will get maintenance, updates etc. but people who don't wish to purchase anything from us will still find that we have substantially improved the open source tooling like Spring IDE as we go down this way.
I think Spring has fostered a flourishing ecosystem both inside, and we have already talked about that, and also outside the Spring fold so to speak. So we see significant adoption in both open source projects and communities, and also proprietary software vendors. So for example in the open source space there are quite a number of Apache products which use Spring pretty heavily, for example ServiceMix, Camel, are 2 of the many Apache projects that use Spring. Grails is another example of an open source project which uses Spring pretty heavily. But we have also seen from a number of commercial software vendors adoption of Spring for various purposes. Probably the most far-reaching of those is BEA.
In Weblogic 10 Spring is used in the core of the server. Spring is used to implement parts of the EJB 3 specification and implement the injection and interception functionality of that specification. Another example of a software vendor is GigaSpaces, GigaSpaces 6 and the OpenSpaces project is heavily based on Spring. Terracotta are also doing significant work around Spring as indeed are Oracle. I think it is interesting to think why this has happened. And I think the reasons firstly include the fact that obviously Spring is open source. If you have software that is open source it is much more available to people to add on to it, to build it into what they do. Secondly Spring is open source under the Apache Software License.
We believe that the ASL is an excellent license. It is an excellent license because -- we sometimes refer to this as non-toxic -- the ASL is non toxic. Essentially it is about as liberal as a license can be. If you want for example take Spring and you want to start "Ryan Enterprises" and you want to shrink wrap Spring in that, modify Spring, whatever. So as long as you observe the license and so long as you include the notice that your piece of software includes Apache-licensed software, you can do pretty much what you like. You are not restrained in using it in an open source environment and using it in a commercial environment. We think that is very important. We think that it is very beneficial to adopt the licensing strategy that supports whatever use people want to make of it without letting the lawyers get in and mess everything up as they like to do.
So that's part of it but I think the fundamental reason that Spring has led to this wide adoption, for example as a component model, is that it is very extensible. It is very extensible and it is not tied to any particular environmental assumptions. For example if you look at BEA they are using Spring in the core of the Java EE server. If you look at GigaSpaces they are using Spring as the preferred component model for a radically different deployment model from Java EE. And Spring is equally at home in either of those situations. As I mentioned earlier Spring aims to provide a clean abstraction between your business logic and the underlying infrastructure. This means that it is not really tied to Java EE or the JavaSpaces APIs in those cases. Interestingly Gartner have recently highlighted the importance of Spring to what they call XTP or Extreme Transaction Processing. They have identified the fact that many XTP vendors are settling on Spring as a de-facto standard programming model for exactly these reasons, that it doesn't impose environmental assumptions such as we see for example in Java EE.
Yes. Spring.Net is an important part of the Spring Portfolio. It is a .Net version of the Spring Framework. I don't say .Net port because that would actually be selling it short. What Spring.Net is, is a version of the Spring component model -- so for example IoC, dependency injection, lifecycle management -- which is virtually identical to what we have in Spring Java but implemented from the ground up in C#, so there is nothing that came out of the Java Language Conversion Assistant or anything like that. It is written in idiomatic C#. The core of Spring.Net, as the core of the Spring Framework, is the IoC container and that is virtually identical. It also has the AOP support, though of course it doesn't have access to the AspectJ integration that was introduced in Spring 2.0. So if you are looking at the core component model it is the same.
Around that there are also a bunch of enterprise libraries, so for example in Spring.Net 1.1 we introduced the transaction abstraction, which is very similar to Platform TransactionManager for Java. There is also the kind of integration that you see with data access libraries like iBatis, as there's an excellent .Net version of iBatis. So Spring.Net exists because the set of problems in the world of .Net is actually pretty similar to the set of problems in the world of Java. At a conceptual level there is nothing in .Net that gives you the degree of sophistication that you get with Spring in terms of DI and AOP. The languages are clearly extremely similar so the same proven benefits apply on the .Net side of the fence as in Java.
Beyond the core container the requirements around the enterprise integration are slightly different because clearly the .Net platform has different strengths and weaknesses to the Java platform. But we have found that many of the core concepts around Spring, such as the notion of templates, as we call them, the fact that all your infrastructural components can be injected and it makes them very configurable with strategy interfaces etc., those kind of patterns are equally applicable to tackling the various complexities on the .Net platform. It's probably important to note here that the goal of Spring.Net is not to enable you to port your application from Java to .Net or from .Net to Java. The goal is to (a) solve problems in the .Net world that weren't previously solved so Spring.Net has value even if you are completely uninterested in Java.
But it is also particularly valuable to companies whose staff are doing both Java and .Net development. In fact that was the initial reason that I was excited about Mark Pollack founding the Spring.Net project, and was encouraging Mark back in 2004, because I have seen a lot of banks where actually the same developers spent significant amounts of time developing Java and developing .Net code. In that kind of situation it's actually really extremely compelling to have the same component model, the same patterns, with each technology platform. And of course there really isn't any other project or vendor that is providing something like that.