Skip navigation

For at least the past 5 years we hear from people that application servers are dead. And earlier this month we heard again how you shouldn't be using them and should be looking at lightweight solutions and the cloud. Phew! I'm glad that that's been pointed out to me, as I was really beginning to worry! Here I was trying to make sure we produced the fastest, most configurable, dynamic and extensible implementation available because it'll form the basis of JBossEverywhere; so we will have to stop that before we waste any more time.


Now of course I'm being sarcastic here. If you've learnt only one thing from my blogs over the past years it's that I don't believe application servers are going away any time soon. It should be no surprise to learn that those vendors who don't have an application server (hint ... not a complete stack) seem to like the original post, whereas those of us who do don't! But as I've said before, my background is as a scientist, so I try to put scientific method before business logic as often as I can, since it usually shows where the business logic will be going eventually anywhere! So try to believe that what I'm about to state is done in an objective way.


If application servers were to vanish, what would replace them? Well let's look at the arguments given for moving away from an application server because they've got to include the answer, right? So let's start with the usual reason for dumping the application server: "it's a monolithic piece of bloated code that includes more things than you really need." (I'm paraphrasing here.) I have this to say to all those who make such statements: try factoring implementation from requirements first before jumping to such conclusions! Yes there are bloated application servers. But then there are bloated implementations of many software components; if your chess program is taking more than 1k of memory then you should feel ashamed I'm not going to point names or name fingers but suffice it to say that not every application server should be tarred with the same brush!


This argument does lead us to ask what are the reason people need an application server? I'll start by stating that I am not going to go into the history of enterprise middleware over the last 40 plus years! I've done that before and there are also enough texts elsewhere that it's left as an exercise to the reader. Suffice it to say that there has been much research, development and deployment experience in this field that the reasons why your transaction service, say, does something in a particular way is very well understood. Fundamentally what the industry has learnt is that there are various core services or capabilities, that your average enterprise user needs. These include transactions, security, messaging, persistence and high availability. It doesn't matter whether you're developing in the bespoke world of the 1970s or through to the Java EE era of today, you'll be able to look at an enterprise application of that period and see those common core components in one way or another.


In the past, these components were thrown together into packages or toolkits for developers to use, with little thought as to how they could interact efficiently or even if they should interact at all. How you could, for instance, make developing transactional applications easier, was often an afterthought. This lead to inefficiencies in developer productivity as well as bugs! So we learnt that we needed to package these things better and consider how they interworked, how they could be used more easily and importantly, how they and applications using them, could be managed better. Why is it worth calling out management? Because the vast majority of these applications are deployed and expected to run for years (decades), so it is inevitable that the people who developed them will not be around at some point in the future.


All of these factors and others (e.g., threads and concurrency control) lead to the concepts of containers and developer frameworks, and from these came standards such as J2EE. Of course some standards are not perfect and they need a lot of love and attention to get them where they need to be. But if you look beyond the standard (or maybe beneath it) at the implementation, you can sometimes see the pearl in the oyster: that these core services are needed and must be packaged correctly or they are of limited utility. Just because a standard may not be good (initially) does not invalidate the reasons that spawned it!


We have answered the question of what are the reason people need an application server? So that should help with the other question of what would be the replacement? If you listen to some folks, it's an arbitrary collection of component implementations, many of which don't come from groups that have even thought about how they may work together in a single application, let alone be deployed for decades! If you listen to other folks the answer is a framework, but unfortunately even the best frameworks need something on which to run, and then you're left to your own devices! And of course I haven't even bothered discussing the niceties that standards bring, such as interoperability and portability, which often go unanswered or unavailable, if you take an ad hoc solution. And I probably shouldn't throw in a comment about lack of maturity of some of these components that are expected to work out of the box and with each other! So neither the framework nor hodge-podge collection of components is really an alternative. You will end up back in the 1970s, having to manage the stack yourself and figure out if version A of component B will really work well with version C of component D. That's hard enough at times with two components, so just try to imagine how hard it'll be when they become N components: O(n)!


But you might ask whether cloud is a game changer and we really need to unlearn everything of the past 4 decades or more, and come up with a completely new approach to enterprise middleware. If you do believe that, then I have a grape coloured cat I'd like to sell you too


In fact in the original post apparently the cloud is the way to go, or simply through Tomcat. Well I can't disagree with the former, since we are heavily involved with that through a range of approaches including OpenShift. PaaS is a good option for many developers, but guess what? Issues such as fault tolerance and security don't vanish as a result of moving to the cloud; if anything, they become more important (remember Amazon or Sony outages?!) You may want to abstract away from on premise APIs such as Java EE, but under the covers it makes far more sense to keep it application server based. (And keeping the EE APIs helps you with portability anyway - remember that you may actually want to move out of the cloud some day!)


And as for Tomcat? Well this is a great way to go down the hodge-podge route if you aren't careful. What you really need is an architecture that can start lightweight and grow seamlessly and opaquely with your needs so that the infrastructure takes the complexity! And yes, I'd recommend JBossAS 7 for that because we've designed it with this scenario in mind! There's also OpenChoice if you need something supported today.


One thing I do have to agree with is that your Java applications need a safe and secure place to run. But that place is here already. You really don't want to be reinventing the wheel just because you don't agree with the way it's packaged. Changing the packaging is a lot easier than changing the contents! And I'd argue that for many applications the packaging is pretty good anyway, especially if you don't want to be locked in by a specific vendor. (Look at CDI before you consider vendor specific frameworks, and doubly so if you've already gone down that route!)


So the application server is here to stay, even if it's under the PaaS covers. Yes there are implementations that do the rest of us a disservice because of their bloated ways. But we need to look beyond them. Maybe the problem is that the term "application server" is too tainted by the past, so we have to change it to something else (I like "Bob" for instance). After all, what's in a name?


JBossAS 7.0 is here!!

Posted by marklittle Jul 12, 2011

There have been many highs in my career and many of those have happened since I joined JBoss and took over from Sacha. But today has to be in my top 1 or 2 ever! Today we can officially announce the release of JBossAS 7.0 Final! And it's EE6 Web Profile compliant too, so check out the project pages. It's taken us a while to get here and we've taken some pretty drastic and innovative steps along the way. Sometimes those decisions haven't been ease to make and we've thought long and hard about them. For instance, I recall Jason Greene, Scott Stark and I discussing for ages the various ramifications of continuing with the then current micro container architecture versus radical changes. The decision to change wasn't easy, but even then well over a year ago, we believed it was the right one to make. And now, with the new micro services container, it's proven itself! Some risks are worth taking.


But not every problem on our path has been technical or come from within Red Hat. Without going into details, let's just say that at times it seemed that processes and red tape were being thrown in our way. However, we got past these and the results speak for themselves: the fastest, most configurable and adaptable EE6 implementation (Web Profile) out there. And full EE6 is next on the roadmap, with JBossAS 7.1 due out soon. So if you haven't already tried it I encourage you to download it and give it a try.


I want to take this opportunity to thank everyone who has been involved in the development of JBossAS 7.0. This includes a diverse group of people including the projects, our QE teams, docs, support, product management, program management, marketing and many others. It would be impossible to single out those individuals who have stood out during the last 18 months since everyone has been a rockstar. However, I do want to mention Jason Greene again: any team is influenced both negatively or positively by it's leader and Jason has lead most positively by example throughout. And of course Bruno Georges, the engineering manager, who took over the role just over a year ago and mustered his troops so well! See what I mean? It's really hard to call out one person without immediately thinking of all of the others involved! A great team effort.




Red Monk interviews

Posted by marklittle Jul 11, 2011

As you can imagine, there was a lot going on at JBoss World/Red Hat Summit this year and I've posted bits and pieces about this already. One of the things that always happens at these gatherings is interviews with press and analysts. Well this time was no exception. But one of the ones that stood out for me was the RedMonk interviews by Stephen O'Grady. If you haven't already seen them then check them out, as Stephen separately interviews Mark Proctor, the Drools lead, and myself. Both are worth listening too as you'll get some great sound bites on our project/product split, our long term vision and aspirations, and I think a reference to an upcoming workshop that RedMonk are holding coincident with a beer festival!


Independence Day

Posted by marklittle Jul 5, 2011

Whether or not you live in the US, it's hard not to know that the 4th of July is American Independence Day. This is the time when they celebrate winning the War of Independence from the British Empire, though really I think we let them win ;-) But either way, it's an important day, which has also been used to a few times to mark other events, such as the thinly disguised remake of H G Well's War of the Worlds. Well as fate would have it, we're about to release JBossAS 7 Final and it just so happens that it'll be so close to Independence Day we simply couldn't pass up this opportunity!


I've already discussed 10 reasons why you should be interested in JBossAS 7, as well as how this really represents a significant move away from the past. Hopefully you also registered for one of the sneak peek webinars we've been giving, and maybe you were at JAXConf recently to get some hands on demonstrations of what AS7 can do. But think of this too: with JBossAS 7 we're giving our communities the chance to declare independence from their previous overlords (aka closed source application servers)! Learn a lesson from the people of 1776 and stand up for your rights: no longer should you have to suffer the indignities of slow boot times and bloated containers taking up all of your available memory and processing power; cast off the shackles of 20th century architectural application server oppression.


Yes, yes, I know this sounds a lot like a sales pitch, but I'm a developer. I've been developing application servers since the 1990's and I've been using JBoss since the 3.x series. And putting my objective hat on for a minute, I can say that I have never come across a Java application server (or container) that performs as well as JBossAS 7 does or has the modularity and capabilities it has. So if you're using an application server, or just using some components, such as JMS or transactions through some other "lightweight" framework, then you really should check out JBossAS 7 Final!

Filter Blog

By date:
By tag: