Iconic Architectures - A Conversation With Rod Johnson
|Artist:||James Sugrue - DZone||Plays:||164|
|Length:||41:57 minutes (8 MB)||Downloads:||43560|
|Format:||MP3 Mono 44kHz 80Kbps (CBR)||Download:||Click to download|
About this podcast
We're kicking off our series of conversations with the leaders in the Java world today with a discussion with Rod Johnson on the Spring Architecture. I talked with Rod about the history of Spring and what we can expect from it in the future. We also covered a lot of other interesting topics such as what a typical day is like working for SpringSource, and the usefulness of Spring certification.
It was interesting for me to find out how Rod would define Dependency Injection in simple terms and his opinions on test driven development.
James Sugrue: So, the first thing I would just like to ask about is a history of how Spring came about; just kind of from the beginning.
Rod Johnson: Originally, Spring grew out of my experience as an architect, largely working in financial and other large enterprises in London from the late 90's through to 2000/2001. During that time, I gained quite a lot of experience in what worked and what didn't work in J2EE. Out of that, I ended up writing my first book: "One on One J2EE Design and Development"
Spring was intended as a practical incarnation of those ideas, if you like. So, for example, what would now be called the Inversion of Control or Dependency Injection container, really was built in terms of providing an adequate configuration mechanism for enterprise Java applications. Much of the other functionality, like Springs's transaction abstraction were also designed to deliver practical solutions for things that I found hadn't worked so well in traditional J2EE.
Sugrue: With regards to Dependency Injection. Martin Fowler has written a bit about that in his papers "Inversion of Control." Was it in Spring or was it in Martin's papers first? Or was it an idea that had been going along for a while?
Johnson: Oh, Martin's paper was much later. I would not claim that Spring was the first product that did Dependency Injection. I mean, Spring was undoubtedly the first mainstream project that did Dependency Injection. I would suggest that Dependency Injection being known and being prevalent is definitely something that came about through Spring.
But, it is fundamentally a simple idea with which you can build an awful lot of sophisticated functionality. So, I think what we did with Spring is both take that idea to the mainstream well in advance of Martin's paper, and also I think we have gone by far the farthest, and continue to go the farthest, in terms of driving the consequences of that idea.
I mean, very often, if you start off with a simple idea, the consequences of really working that through, doing some of the hard work to see everything that can be done with it, can be very interesting. And I think, that is what we have done with Spring.Really, in Spring, there were two things that I think were pretty key to Spring's success from a purely technological point of view.
One was the idea that a component model or a framework really shouldn't address just one technology.So, for example, it shouldn't just focus on dependency injection. It should focus on the range of things that you need it to solve practical problems. So, it was very much a technology that was about providing a practical solution to problems people really had, rather than saying "Hey. We love dependency injection. Let's do something that does dependency injection." So, it was always about a complete mix of things to deliver a coherent solution.
The second thing that Spring has always been really focused on is the idea of enabling a POJO programming model. So, we had really the key technologies of the combination of dependency injection and AOP, which were all used to enable the infrastructural concerns and everything that really wasn't part of your mainline business logic to enable that to be pulled out of the logic in your POJOs.
Sugrue: One interesting thing I have found is that people struggle with the definition of Dependency Injection. I think, the POJO principle and Spring, is something that a lot of people understand. Just one interesting thing to find out would be if you were asked in an interview to explain Dependency Injection, how would you explain it?
Johnson: The easiest way to explain Dependency Injection is in terms of the Hollywood principle. The Hollywood principle is of course don't call me, I will call you.
Traditionally, when programmers have written business logic in languages such as Java or any non-trivial applications, they need to access configuration that is external to the code. I mean, in trivial applications you can hard code everything in Java or a similar language. In any kind of real world business applications, there are things that you need to externalize.
The traditional way to do that was to write in your code something that when it started up; it went and made calls to all kinds of things. So, for example, it would start up and say "All right. I am going to read some properties files. I am going to read some XML. I am going to access a database."
With Dependency Injection it is very different because the dependency injection container actually injects or provides to the business logic the things that it needs, but the way in which that information is obtained is handled by the container rather than handled by the business logic.
So, in other words, the business logic specifies through Java language constructs what references and values it needs, and it is the role of the container to find them and inject or provide them. Whereas in a traditional approach, there was no separation between specifying what you needed and where you were going to find it.
Sugrue: That's nice explanation I think. When it comes to POJOs, when you were starting out with Spring, the very first versions, how were people in the industry reacting to this idea that POJOs could be this powerful because of the container that they were in? Was there any doubt or was it taken really well straightaway?
Johnson: I think that whenever you look at anything like Spring that has gotten a very large community; it looks in retrospect like it was inevitable. In fact, I think that a lot of people thought that we were crazy.
Certainly, I think, because the idea of dependency injection is really so simple as a concept, there is a natural tendency to think "Well, you know this can't really solve complex problems." In fact, in my second book "J2EE without EJB," I talk quite a bit about what I call the complexity industry. A lot of people feel that "Well, a complex solution must be inherently more powerful."
The reality is that I think what we have achieved in Spring with a combination of dependency injection, AOP is actually far more powerful than previous generations of technology to solve the same problems.
So, for example, if you have a container that is handling injection of references and also has a powerful proxying mechanism, you can inject references that change over time and make that completely transparent.
I think, Spring gradually grew throughout 2003. I think, it really hit the mainstream in early 2004. But, I think, there was a lot of skepticism out there in 2003. Fundamentally, I think, two things helped Spring become adopted widely so quickly.
First, there was the fact that Spring really did what it said and did it very well. But, the second thing, frankly, was that the previous generation of technology was so good and bad. Fundamentally, unless people realize they have got a problem, they are not necessarily receptive to a better solution.
Sugrue: And the Pico Container was out around the same time or maybe before this?
Johnson: Spring was actually earlier than Pico Container. The Pico Container actually popped up, I think, in April of 2003 and did a release in June 2003. Spring actually was founded as an open source project in February. So, they were completely independent. I think, it was an idea whose time had come, but I think Spring actually was marginally earlier.
I don't know. For some reason a lot of people think Pico Container was ahead of Spring, which was not the case.
Sugrue: I think it is possibly because you do have a mention or have an example of, Pico Container in one of your books. So, that is why I thought possibly it was before.
Johnson: We actually always had a friendly relationship with the Pico Container guys. I think that they introduced the idea of constructive injection, which was something that we adopted in Spring as a result of what they had done. So certainly, I think, we benefited quite a bit from some of the ideas that they pioneered.
Sugrue: So, your initial aims with Spring were to solve the problems with J2EE at the time. Do you think that anything has changed since then? Has Spring grown into something bigger than what you initially thought?
Johnson: Oh absolutely. Well, I think, firstly things have changed in... You mentioned was it difficult to get uptake of Spring early on was their skepticism? Well, I think, in the battle of ideas, Spring won.
So, if you look, for example, at Spring opposed to EJB at that time, Spring really was the representation in thinking that said "Hey, this EJB model is madness. We need to move away from it." If you look at EJB 3, it is pretty much a dumbed down imitation of Spring.
So, I think, in terms of the battle of ideas, Spring won. In terms of where Spring has gone itself, we have very much kept moving forward. So, Spring does a great deal more than it used to do.
So, for example, if you look at the Spring framework, it has expanded in many areas, like or example, JSP Applet support, support for integration with more and more for different projects... If you look at Spring Webflow, Spring Security, Spring Web Services, even Spring .Net, there is a very, very broad range of areas where the Spring framework has grown and Spring has expanded its reach.
Sugrue: Throughout the whole portfolio, how do you maintain your ideas and your architecture, all the way through all the products that you do? Is it through things like reviews, or is there some kind of manifesto that all Spring employees follow?
Johnson: Well, firstly, Spring is unusual, possibly even unique, in that it is an open source project that grew out of a book. So, there were many things in terms of the philosophy that we're already out there then, which helped the community and the company have a continuity of vision.
We do a lot of reviews. For example, I am just back from a full week of face to face meetings between all the project leads, which we had in Europe. We spend a lot of times doing reviews. We discuss in terms of objectives. We are pretty good at being very open and very direct in terms of giving each other feedback. And we really do try to adhere to the consistent values that people see in Spring.
Over time, I think, we have actually started to do more and more work face to face where people regularly meet up and sit together and write code together.
Sugrue:You say that you have these reviews and things. Just to find out a bit more about what actually goes on behind the scenes, are these kind of high level meetings, or does it go all the way down to code examples?
Johnson: It is really all of the above. Typically, what we do is we run through all the projects that we are involved in and also projects that now SpringSource is involved in outside Spring, like for example, Tomcat, because now we are doing by far the majority of the development of Tomcat.
So, we get our technical folk together. We have plans and objectives for each set of releases, which are generally defined by myself, and Adrian, and Peter Cooper-Ellis. Then, we have each project lead take the group through what he or she is working on. And then we have very open discussions. Then, after that, we typically have a few days of breakout meetings whereby small groups will focus on particular things.
That is just the more formal part of the program. You will frequently see at night, people just at the bar with a beer and a laptom pair programming or just really working through ideas.
Sugrue: Actually, one thing that you mentioned there that I find quite interesting is you are doing a lot of the development for Apache Tomcat. You are also members of the Eclipse Foundation at this stage. Do you find that Spring is growing into a big company that is really rivaling companies like Google and Sun. While not doing exactly the same things; you are one of the big players in the software industry at the moment?
Johnson: Well, I think, it would be a bit presumptuous to say that we are rivaling Google or Sun, at least in terms of market capitalization. But, we do believe that we are actually a very significant player, particularly in the enterprise Java space.
I think, you mentioned the three things that we have alluded to. Spring obviously, Eclipse, and Tomcat and Apache are, we feel, the three most important sources of enterprise Java for open source for the majority of users. We have expanded as a company to the point where we are broader even than Spring.
So, we are very deeply involved in the Apache Foundation. Our employees do the majority of development on Apache Tomcat over three quarters of the commits over the last couple of years. We also do the majority of development on the Apache HTTP web server. And we are involved in a number of other projects including ActiveMQ, which is another very popular project.
On the Eclipse Foundation, where our tooling strategy is based around Eclipse, we're involved in the Equinox and Mylyn projects at Eclipse, and we also laid the AspectJ project through Eclipse.
I think, it's similar to the way in which I said that the philosophy of Spring was not so much "let's take a cool technology," but was very much "this is the kind of problem that we know you had because we used to have this problem. We're going to combine some technologies to give you a solution." We're really trying to do the same thing with the company, whereby the fundamental purpose of the company is to be a software company that provides you with software that will make you more successful in Enterprise Java. And, that of course is substantially covered by Spring, but there certainly are a number of other important technologies out there, like Tomcat, like Eclipse, and we need to be in a position where we can add value to those technologies and provide support to those technologies.
Sugrue: And, being such a big player now, has anyone else tried to take you over, anyone tried to buy Spring out or SpringSource, or have you managed to just maintain this kind of independent status all the way through?
Johnson: Over time, it's pretty obvious that what we're doing is impacting some big players. So, certainly, I think, we've had opportunities in that direction that we could have pursued if we wanted to. But, frankly, we believe that we have a tremendous opportunity to execute our technology vision and to do it as an independent company. So, we certainly don't feel that we need to try to go out and be acquired.
Sugrue: I suppose we've covered what the fundamental architecture and principles are in the Spring framework with dependency injection, AOP, and POJOs. I suppose, they would be the three main points in Spring. Or, is that an oversimplification?
Johnson: In terms of the philosophy, yes. I mean, the broader aim is at the highest level to take complexity that formerly complicated applications and move it in the framework. So, there are various ways in which we do them and the most important ways are Dependency Injection and AOP. Of course, there are parts of Spring that are class libraries, like Spring JDBC, like Spring's integration with a number of third party technologies.
So, I think, the special thing about Spring is that although the core idea is maybe relatively simple, there is a great deal of work that needs to be done to actually realize that vision. A good example of that is the integration between Spring and the OSGI module system. With Dependency Injection, you have the ability to express inject references. And, as I said, those references can dynamically change over time. With OSGI, this provides a very interesting benefit with potentially you can inject a reference to something in a different bundle; and if that bundle changes, using OSGI functionality, you have the ability for that reference to be transparently updated.
That sounds very simple in terms of the benefit and the end result is you write code that doesn't know anything about OSGI modularization, but can still benefit from it at runtime. Yet, obviously, if you think about the kind of smarts that need to go into the implementation to do that, transparently interacting with the OSGI environment, ensuring thread safety, as you can see, there's a great deal of heavy lifting that has to happen at runtime.
So, I think with Spring, a lot of what we've done is ensuring that the programming model remains very simple, but potentially there is quite a lot of heavy lifting that's happening at runtime in order to make that happen.
Sugrue: So, when it comes to Spring 3.0, I think, it's due for release at the end of this year. Is that correct? Or, is it early 2009?
Johnson: Yes. You'll see the first milestone of Spring 3.0 either at the end of September or the beginning of October, and we'll go GA early in 2009.
Sugrue: As for the main points of Spring 3.0, I think one of the main ones that sticks out in my mind is the REST stuff.
Johnson: Yes. That's the biggest single feature in 3.0. It's something that we have had a huge demand for from the community. And, it's obvious that REST is now something that people really care about and certainly I can understand why. I mean, REST is simple. REST is the kind of technology that actually makes a lot of sense in terms of efficiently and easily handling a number of remoting requirements.
So, REST, we're going to have comprehensive support that essentially grows out of Spring MVC, but really can be used across various parts of the framework. We are updating Spring to run on Java five and above only. So, the last version of Spring that runs on any version of Java prior to Java five will be Spring 2.5. Now, the vast majority of our user base is on Java five or even Java 6. So, in Spring 3.0, we will do a bit of housecleaning in that we will update internal APIs in Spring as well as many external APIs to being Java five only.
There will be a bunch of deprecation. So, one thing that we really want to make sure that we do is ensure that it's very clear to our user what best practice is as of now. So, for example, if you look at Spring MVC, there are many classes, like Simple Form Controller and Abstract Wizard Controller, that no longer represent best practice. So, they will be deprecated in the Spring 3.0 release and they will actually be removed in the next major release. So, we will definitely take the opportunity to start to help people migrate to best practices.
We will also be doing some pruning. So, certain things will be removed from Spring 2.5. So, for example, the support for commons attributes, which was a very old pre-annotation attempt to get annotations in Java and also support for Oracle Toplink, which really now has been superseded by the Eclipselink project. We think that those removals will have only effect a tiny proportion of our users and they can either stick with 2.5 until they get rid of those obsolete dependencies in their code or alternatively they can drop that part of Spring 2.5 writing to Spring 3.0 and it should still work.
We are introducing, as well, a new expression language in Spring 3.0. This will provide a similar value to JSP expressions, and it will be usable in both annotations, syntax inside spring, and also in XML configuration.
So, for example, you will be able to specify injection paths in terms of if you want navigating properties and methods, as well as the traditional kind of direct references. We think that that will help to further simplify configuration in Spring.
Sugrue: OK. It is actually really nice to see that you are deprecating and dropping things out just to maintain best practice, instead of just leaving everything in there "just in case". I think that is a fantastic thing to do.
Johnson: Yeah, I think, it is very important to ensure that it is easier for people to move forward with best practice. And bear in mind that the nature of open source is such that existing relatives of the project are there.
So, I think, you can actually be more energetic about this sort of thing in open source than you can in a proprietary product. Because in a proprietary product, essentially the vendor controls all the distribution, so it can actually get really hard to get an older version. Whereas it is never going to be hard to get an older version of Spring if that is what you really need.
Sugrue: So, and have you looked further down the line for Spring 3.5 or Spring 4.0, or is it 100% focused on the next release at the moment?
Johnson: Actually, one point that I should have made about Spring 3.0 is also there will be further work towards unifying the Sprint MVC programming model and the Spring Web Flow programming model. So, it should become increasingly clear that we have a soup-to-nuts solution from the simplest web applications with free navigation right through to complex wizard and conversational flows. And we will be able to do that so that there is an extremely natural path for either migration from Spring MVC to Spring Web Flow or in fact, in many cases, using both of them in the one logical application.
In terms of moving forward, we are pretty focused on the 3.0 release right now, but one thing that we're looking at moving forward is tracking some of the specs that are coming out of Java EE 6. So, we were originally looking at implementing some of those specs in Spring 3.0, but of course Java EE six is not being delivered in the timeframe we expected. So, that is going to be something that we address next year.
Sugrue: When you look at where Spring is now, and where Spring 3.0 is going to be, are you very proud of the job that you have done and all the engineers at Spring have done up to now?
Johnson: Very much so, I mean, one of the things that I feel particularly proud of is that if you look at any application that is written using the latest version of Spring versus applications that were written using earlier versions of Spring, they are very, very much simpler.
So, I think that we have actually demonstrated that as the framework and the rest of the Spring projects get broader and broader in scope. And as there is some very complex code in there underneath, the reality that the user sees is getting simpler and simpler. So, I think, we have actually demonstrated that you can actually do more while making it easier to use for the end user. That is probably one of the things that I feel proudest of.
The other thing that I think that we are proud of is the level of quality that we have achieved. For example, I had a question this morning from a customer who was interested in comparing Spring MVC versus Seam? I mean, obviously I talked about lots of technical arguments, but I said, "Look, why don't you just go away and have a look in the issue trackers, have a look at the number of open issues that are classified as bugs."
And when you do that with Seam or many other projects, really, the comparison is incredible in favor of Spring. I think, in the case of Spring, it was something like 14 versus 240 for Seam. So, I think, the level of quality that we have achieved is truly acceptable compared to what is out there.
Sugrue: When you talk about quality, I presume as followers of best practice that you do a lot of test-driven development and a lot of unit testing. But, do you worry about coverage statistics. What is your opinion on code coverage with unit tests?
Johnson: We do. Pretty much all development in Spring projects is test-driven. And I think that something has been extremely helpful in terms of getting the good quality that we have achieved. We do worry about coverage, so we definitely track coverage across all of our projects.
We are not kind of the Taliban of test coverage, in that we don't have people writing pointless code so they can get from 97% to 99%, but we do really care about coverage and we like to try to ensure that the coverage gradually increases across all of our projects.
Actually, I have had some interesting discussions with Peter Cooper Ellis. Peter is really surprised at just how few bugs that we have in Spring. And I think, that is an example of how our embrace of test-driven development definitely gives us an advantage versus many traditional software vendors.
Sugrue: And you said there were maybe 14 open issues that you mentioned as an example...
Johnson: That is 14 open issues that are bugs. By the way, if you just go to look at the issue tracker, you will see many more than that, but the majority are enhancement requests.
Sugrue: OK, I see. And do you find that you don't have a lot of bugs logged in your issue tracker because they are caught at development time, or do you still get a lot that fall through the cracks of initial unit-testing?
Johnson: Well, I think that unit-testing really helps in two ways. Firstly it helps in terms of identifying defects early, but secondly it helps in terms of making it possible to resolve defects more quickly because you have a good safety nest of regression tests.
We do, of course, do a variety of other tests, so we do a variety of system tests. Some of those we do in terms of the Spring Enterprise, SpringSource Enterprise release, rather than purely around Spring Framework. So, for example, we run tests on different types of hardware, et cetera, different operating systems, and against different third-party products.
Sugrue: So, what do you see happening in Java and in Enterprise Development over the next few years? Can you predict anything, or have you seen any kind of technologies or ideas or standards that are rising that really need to be watched?
Johnson: In terms of the standards space, I think OSGI is really the standard to watch. OSGI is having a big impact on a wide variety of areas, and I would expect that we'll gradually see a move away from the traditional kind of Java EE deployment units more towards OSGI-based deployment units, which have superior modularity and which also aren't tied to a traditional Java EE server environment.
So, that's certainly the biggest impact in terms of what we see in the standard space. We're also involved in Java 86, and we think that a number of the things that are being done there are very positive, but frankly, in some ways, I think Java EE six is recognizing what developers are already doing rather than making the same kind of potential change possible that OSGI will.
Sugrue: One of the things that I think about is that the line between applications being on the desktop and applications being on the web or through the Internet will decrease with OSGI. Would you agree with that, that we'll really have proper cross-platform applications in the next few years?
Johnson: I think that OSGI is a big part of the solution. It isn't the whole solution because if you look at the use of OSGI in Enterprise programming, OSGI is still not tremendously mature for that yet, or tremendously usable for that yet. And I think, that's one of the areas where we believe we've cracked a lot of those problems in SpringSource DM server.
But, certainly, in terms of the potential to have business logic that is decoupled from a particular environment, OSGI is definitely a part of the solution in terms of deployment, and I think Spring is the core of the solution in terms of component model, because if you put those two things together, what you end up is both a module system and a component model that don't actually make problematic assumptions about where that code needs to run. And I think, that's very, very beneficial.
It's very beneficial as we see the rise of Solar and virtualization, so we're seeing the traditional kind of silo approach broken up.
I think, we're definitely seeing profound changes in how people deal with web applications. I think, we're going through a very creative period of disruption and innovation in the web tier.
So, for example, there are folk using JSF, there are folk using traditional MVC-based approaches, there are folk using GWT, folk using Flex, folk using AJAX, with various of those technologies, and I think it's unclear whether or not there will be a single winner, but I think, ultimately, this is extremely beneficial in terms of the experience that developers can create for web users. And certainly, that's something that all Java projects really need to be able to support on the service side.
Sugrue: One keyword that's become very popular in CVs has obviously been Spring, and a lot of recruiters are looking for Spring developers. I suppose, first, that's a very flattering thing for SpringSource and for you. Rather than it being a buzzword, what should people really know rather than to just have Spring on their CV?
Johnson: Well, I think, the key thing is whether or not they actually have practical experience with it. So, you know, if I were interviewing someone who claimed to have Spring skills, I think I'd probably be getting them to draw up an architecture diagram on a whiteboard from top to bottom and getting them to describe how they'd use Spring in every part of the stack.
You know, for example, what is it that, in the middle tier, Spring can do for you? How do you go about doing the most of it? Also, for example, how can Spring make your applications more testable? What would be the kind of testing practices that you would adopt in a Spring-based application?
So, I think, the key thing with a technology like Spring that's been around for some time now is really, people who are putting Spring on their CVs should actually have experience building applications using Spring. So, you know, I'd definitely be trying to get them to talk through how they've used the Spring stack through development, and you know, also supported the use of Spring in production?
We are also, at SpringSource, providing now a certification program. There's now the opportunity of folk doing SpringSource certification for Spring framework and other projects. So, you know, that potentially provides another option for employers in terms of how they can evaluate people's possession of Spring skills.
Interviewer: Are there actual courses that you can go on, certified courses, courses from SpringSource, to get certification?
Johnson: There are. It consists of two parts. Firstly, SpringSource has a comprehensive training program on Spring Framework and other Spring projects, also AspectJ, ActiveMQ and Tomcat, that we deliver worldwide. So, normally what happens is that people complete, say, the Spring Framework training course, and then they're eligible to sit a certification exam.
People who have already had very significant experience with Spring prior to us putting the certification program in place, or people who've actually made contributions to the community through forum posts or patches or whatever can provide for special consideration so they can sit the exam without actually having to complete the training first.
Sugrue: That sounds very good.
Johnson: The exam is a fairly demanding exam. I mean, we believe in setting the bar pretty high.
Sugrue: It sounds like it'd be worth having, though.
Johnson: Yes, I believe so. I mean, certainly, I think, we've had very positive feedback from the developers who've completed it. I think, they feel that it's both worthwhile in terms of their marketability, but also worthwhile in terms of the fact that it actually resulted in them learning more about Spring.