Do you know how big your operating system is? These days, with cheap memory and ever faster processor speeds does it really matter? Do you know what's going on within the operating system? Or how much of it you use on a daily basis? The answer to all of these questions is probably no; in general, operating systems today are extremely well written pieces of software, often modular in nature and making efficient use of available memory and processing resources.

But if you do look into you favourite operating system, either by taking a look at the source code or it's architectural manuals, you may be surprised to learn what it has to do in order for you to just read email, write a document, or browse the web, or do all of these safely and concurrently. You'll most likely find that there are also many services or capabilities within the operating system that you may not need on a day to day basis. For instance, atomic (or even transactional) updates to multiple filesystem entries. However, if the types of applications you use increase in complexity then some or all of these things will be needed. And these days you don't have to download them into you operating system before you can run the applications: they're so well implemented and efficiently integrated already that you don't notice them when they're not needed.

This is all well and good, but what has this to do with middleware? Well we've heard a lot over the years about bloated middleware and the need for lightweight stacks or frameworks. Now I think a lot of the hype over these has often been driven by vendors or individuals with ulterior motives. Of course there are or have been suboptimal middleware implementations, where what you didn't need really did get in your way, e.g., through perceivable performance overheads. However, to infer that these are the normal situation is inaccurate. As is trying to give the impression that specific middleware architectures, such as Java Enterprise Edition, are necessarily bloated from the start. Sure if you provide a poor implementation that may be the case, but a good implementation should be far closer to the operating system analogy that I mentioned before: if you don't use something then you won't know it's there, but when you really do need it, the implementation will make it available to you opaquely.

Now of course I'm leading this topic to the subject of JBossAS 7, because it's a perfect implementation of what I've outlined above. The new architecture, including the modular service container, mean that services you don't need aren't going to impact you. But if your application, or something on which it depends, eventually has a dependency on one of these services, then it'll be made available automatically. You don't have to know a priori what you need, or have an in-depth knowledge of 3rd party dependencies. As a result AS7 boots in seconds and has a footprint that means it is highly embeddable.

So why start with just a web server, building up an ad hoc application server through trial and error, when there's an enterprise container that gives you the same performance benefits with no downsides? It's a bit like saying you should start with a raw file system, paging and swapping, and the concept of processes, then when you need them introduce threads, locks, shared memory and IPC. Not exactly the most efficient use of your time! With JBossAS 7 you will be able to use the application server for simple applications and not have to worry about the services that you don't need just yet. But when your needs increase, you can be sure that those services you didn't plan for previously will kick in, just as they do within the operating system you're probably reading this article on now. And since you probably don't even worry about what that is doing, why should you worry about what JBossAS 7 is doing for you under the covers? Let us worry about that and let us get it right so you don't have to!