Long-awaited JBoss AS 5.0 moves closer to release date

A Red Hat official revealed on a blog that the first release candidate for JBoss Application Server 5.0 will be out soon

The first release candidate of Red Hat's long-brewing JBoss Application Server 5.0 will be available imminently, according to a blog post by Sacha Labourey, chief technology officer of Red Hat's JBoss division.

"JBoss AS5.0 RC1 just got frozen and will be released this week," Labourey wrote. A second release candidate should be ready in six to seven weeks, and general availability will follow "closely thereafter," he added.

Red Hat believes the product's flexible architecture will serve as a differentiator in the market, according to Labourey.

An application server revolves around three technology tiers, he wrote: A base runtime -- in JBoss' case, the Java virtual machine -- core middleware services, and the APIs (application programming interfaces) and methodologies on top.

"JBoss AS 5.0 is the first release which will give us the ability to cleanly separate those three layers," he wrote. "The JBoss Microcontainer abstracts us from the runtime environment and our core enterprise services have been completely componentized and aspectized so they can be fully leveraged from any higher level framework/API/language."

Red Hat plans to support component-based Java development specifications such as OSGi (Open Services Gateway initiative), which is backed by the likes of Sun and IBM.

But the company decided against throwing its lot entirely in any one camp, he wrote.

"Our core architecture is not dependent on any fashionable spec or language du jour," he added. "Personalities can be plugged in and out, a la carte. You don't have to make a bet on which is 'the' API you need, and then be locked in one of the few [application server] implementations that implement such API -- possibly relying on weaker core middleware services."

The scope of changes to the product extended the development process, which started three years ago, according to Labourey.

But the project was not just "a fancy engineering exercise," he said. "This investment will have a drastic impact on the overall JBoss Enterprise Middleware offering, its longevity and its ability to adapt to market changes."

Red Hat's arms-length embrace of technologies like OSGi is perhaps to be expected given the company's history, according to one observer.

The original JBoss micro-kernel "gave a component-oriented way to do Java and applications before there were other viable options," said Michael Cote, an analyst with Redmonk. "As with lots of teams who've already invented a technology that others try to standardize, it looks like the JBoss folks see OSGi as being more faddish [as opposed to] the way things will be."

But the company may nonetheless be making a wise move, he said.

"Rather than build their core on OSGi, they're building the core on their own stuff, and supporting OSGi as a sort of way of using that JBoss-specific core," he said. "The hedge there being that they can add on support for whatever comes into fashion if OSGi becomes tomorrow's bell-bottoms. If you have the time to build an architecture that lets you hedge like that, it's usually a good thing."

At this point, it's anyone's guess as to which Java component technology will emerge as the leader, or whether multiple approaches will gain steam, he added: "There's plenty of OSGi enthusiasts building up, but this question of how Java components will be solved is still early on. We need more time to see what developers far and wide like using."

Red Hat faces competition in the application server market from big platform vendors such as Oracle and IBM, as well as on the open-source side through SpringSource's recently announced application server platform, which leverages OSGi.

More about: Gateway, IBM, JBoss, Leader, Leader Computers, Oracle, Red Hat
References show all

Comments

1

Rich D

Sun 11/10/2009 - 01:32

SoS or FoF

First there was binary code and then languages. Now there are API and frameworks built to specifications. For the future I propose the specifications of specifications (SoS) or frameworks of frameworks (FoF).

The goal : developers can choose to write their apps using any API and transform them to any other API, thus running in any framework.

Therefore any new technology of the future will be accessible.

Things needed ....

XML specification language (XMLSP) to write specifications.
this should describe high level framework and application concepts such as
life-cycle management and middleware services. By adhering to xmlsp you write
your own API and are able to transform it to any other API.

While writing this I came to the realization that if this was possible there could be
thousands of specifications and frameworks and we would be in the wild wild west of
specs. Why is this bad? because it does not allow people to gain skill in one
particular area such as J2EE, etc therefore employers would have a hard time finding
someone with the skills they need and ramp up time would be much longer before they can
contribute to a project ... we are basically back were we started which is coding in
languages with no specs, since anyone can do as they please.

so please stop the madness!

Rich

Post new comment

The content of this field is kept private and will not be shown publicly.
Users posting comments agree to the TechWorld comments policy.
Login or register to link comments to your user profile, or you may also post a comment without being logged in.
Related Whitepapers
Latest Stories
Community Comments
Whitepapers
All whitepapers

Twitter Feed