Talking TomEE with David Blevins
From November's JAX Magazine, we sat down with TomEE's David Blevins to discuss the project that takes Tomcat one step further for this generation's applications.
JAX: Best place to start I guess, what is TomEE, what was the thinking behind starting it and what problems does it set out to solve?
Blevins: TomEE is the Java EE version of Tomcat. The idea was there and many people have wanted to see Tomcat go beyond just servlets for quite some time. If you trace the origins of TomEE, you can go as back as far as the early 2000s with the OpenEJB Tomcat stack which is also where the EJBs in WARs feature of Java EE 6 originates. The EJB 3.1 Embedded EJB Container API comes from there as well. The thing that finally made TomEE possible, though, was the addition of the Web Profile to Java EE 6.
JAX: So was it feasible or way off at that point?
Creating TomEE was incredibly difficult. Having implemented Full Profile EE servers for over 10 years, I knew it was going to be hard even with some of the legacy parts of Java EE cut out and not in the Web Profile. Once we dropped the basic parts, we were still only 40% there. It took almost a year to fill those gaps. It doesn't take a lot of code, but it takes the right code. I think part of the real value of TomEE is that we have put so much work into the completeness of the integration and have done it in an incredibly simple and direct way.
JAX: Can you outline the main parts that go into TomEE?
TomEE includes all of the Web Profile technologies, all of which are very relevant. Just to list them off, beyond Servlets and JSP we have JSF, CDI, JPA, JTA, EJB Lite and Bean Validation. That's the core. They're all incredibly important. I think actually of all the technologies, Bean Validation tends to get the least buzz [about it], but it's perhaps the most relevant to every single one of those specifications. If you're using JPA, you need Bean Validation.
JAX: So it's something developers might take for granted I guess?
Yes, definitely. It's not a large API, but it's definitely important. Validation is as important to data as unit testing is to code. With all the focus there is on testing, there really needs to be an equal focus on valid data.
JAX: Was CDI an absolute must for your team for the main release?
We all saw it as critical. CDI is a very compelling technology. It's essentially the new integration layer for Java EE and in a lot of ways it obsoletes EJB. At the Java EE level, we're moving more and more onto CDI.
JAX: There's obviously a heavy reliance on Tomcat - taking onboard its good points and moving beyond it. How close are the ties between TomEE and other projects?
All the projects are at Apache and the ecosystem there is very close. We all collaborate quite a bit. When we put out a TomEE announcement, we have people from Tomcat, MyFaces and OpenWebBeans all chipping in and helping. It's definitely a good community. In technical terms, though, the way Tomcat has been written means that we need almost nothing to be added or changed in Tomcat itself to make TomEE possible, which is a really good testament to that project.
JAX: So it's refinement then?
I'd describe TomEE as an extension of Tomcat. The Tomcat architecture is pretty amazing when you think how old it is, it was really ahead of its time. It is very much an event-based architecture and it was through that event-based architecture that we were able to make these great extensions to how things are deployed, started and stopped. We didn't have to change anything architecturally. We just followed the path that was laid out there. Hats off to Tomcat for having that really flexible architecture.
JAX: So what does it allow you to do that regular Tomcat doesn't then? What scenarios does thrive in?
In terms of what Tomcat offers out of the box, it's about 2/7ths of the Web Profile. So there are a significant number of extra technologies in TomEE. These are the typical technologies that people usually add themselves. I think that TomEE thrives in any scenario that involves Tomcat and the reason is because often you start out with Tomcat installed and then the first thing you do is you go to build it to be more than Tomcat...
JAX: And if the extra stuff is there, there's no need to go hunting?
Exactly. From day one there is a better alternative.
Adding these things as you go can cause several problems. The first one is it can be a huge waste of time. You start with a basic Servlet app and now you want to persist some data to a database. So now you need to add a JPA provider. That one is easy, but then every time you learn about a new bit of technology, it becomes harder and harder. Say you want to add CDI, but you don't know much about it so you have to both learn CDI and how to integrate CDI into Tomcat and with all your other libraries at the same time. So you're coupling learning about a technology with integrating that technology. Having to integrate a technology you know nothing about is a terrible position to be in. You might get something working, but you don't really know if that's the way it should work and every time you run into a problem you don't know if the problem comes from not integrating it properly or if it is an actual bug or if you're misunderstanding completely and expecting the technology to do something it isn't supposed to do. It's an incredibly frustrating position to be in. We then repeat this on every new technology we want to add to our application.
We're all mature enough to know that we don't "just use servlets", as if the only useful Java APIs have already been created and everything that came after is all stuff no one ever uses. As if the average war file doesn't have a ton of additional libraries in it. These days even new war files are packed with a ton of libraries we know we'll need even before we've written a line of real code.
Second, just because you add a library to a webapp and can get some use of it, doesn't mean it is fully integrated. For example you can't drop CXF into Tomcat and expect Web Services security to work with the Servlet security. You can't drop OpenJPA into Tomcat and expect JTA-managed EntityManagers to work. CDI, for example, has a strong integration focus, but even if you drop OpenWebBeans into Tomcat you've still only got 60% of what that spec has to offer. CDI injection is not going to work on your Web Service, because they're different technologies.
So again, you're back to Googling, writing integration code and solving this problem as if no one's ever solved it before. As the number of useful Java technologies the industry has to offer grows, it just becomes harder and harder to do it yourself and keep everything consistent.
Then there are performance considerations to be had. APIs do a tremendous amount of scanning do these days, which involves reading every single class file in an application looking for annotation declared components. Tomcat will scan your entire Web app for servlets, listeners and filters. Then if you add MyFaces it will scan your entire Web app for manage beans. Now it's scanned twice. Then you throw OpenWebBeans in there and now it's going to get scanned a third time. You throw OpenJPA in there and it's going to scan your webapp a fourth time looking for entity beans. Throw CXF in there and now CXF is going to scan your entire Web app for Web Services.
It's incredibly wasteful, it's not quick. Not only has the number of scans gone up but the amount of jars that have to be scanned has gone up. OpenWebBeans is going to scan MyFaces, OpenJPA and CXF. And CXF is going to scan OpenJPA, MyFaces and OpenWebBeans (laughs)
JAX: Wow. That's a bit time consuming.
It's not entirely efficient, no.
JAX: I think that's fair to say.
These are some of the things we take care of in TomEE. We scan once to the best of our ability, we share that information with MyFaces, OpenWebBeans and Tomcat. We try to cut the redundant scanning down much as possible. It's not perfect and we're still going down that path, but we're very far down it. It's certainly more than you'd get by just throwing those individual specifications on Tomcat.
Another aspect is the level of testing we do as we make improvements like these. I'm not sure how many tests other people have for their Tomcat stacks, but I can say from a TomEE perspective, we run hours and hours on TomEE every day because of the very large compliance test suite that is the TCK, which all certified implementations have to pass. If you do it in linear time, it's days of tests. If you break it up and parallelise it like we do, it's a couple of hours of tests but still a couple hundred hours of machine time. That's a significant level of protection you're getting knowing that everything you have in there is complete and passes these set of tests. And you can get that in 27mb.
JAX: Yeah, that is impressive.
It's not a large tradeoff either. The really critical thing we're trying to do with TomEE is to not subtract from the Tomcat experience, only add. It's a difficult challenge and we work extremely hard at it. We never claim perfection so if you find something that ruined your Tomcat experience let us know and we will fix it.
- The Components of TomEE
- Certification and the next steps.