Just 6 months after JBoss AS 6 was released, JBoss AS 7 (codename Lightning) is now available. Congratulations and a big thank you to the JBoss AS team and community. JBoss AS 7 is a major release in every respect and will become the technology underpinning for much of what we do at JBoss for the next decade. I believe it also represents a shift in the way developers will think about enterprise Java and it opens up new possibilities for deployment that were unthinkable 5 years ago due to technical and economic limitations.

If you’ve been following the AS 7 candidate releases (and AS 6 before it) then you already know that AS 7 includes some significant new features. I’m not going to list them all; but here are the highlights:

Developer Productivity

• Startup-time and memory utilization have been significantly reduced which leads to a much more productive developer experience – no more coffee breaks during deployments and restarts.This required some significant rethinking and a fair amount of innovation (something we’re good at apparently)
• The Java EE 6 Web Profile provides a much leaner, less complex platform for developers who focus purely on the web-tier – less to learn, fewer design choices – increased developer productivity
• More flexible and powerful modular classloader – less time debugging and configuring classpaths; more time writing applications
• Testable by Design with Arquillian with out of container testing for the business logic so developers can be more productive while delivering better quality applications.

Price / Performance

• It’s probably a little early to claim significant performance gain over the competition right now but request path performance is a goal and the hard work of tuning and performance improvements starts now, One early indicator will hopeful give you a sense of what we’d like to achieve is the recent SPECjms2007 submission from Red Hat. SPECjms is a pretty narrowly focussed benchmark and not all the JMS vendors are represented, that said this is pretty significant for us as it is the first public benchmark submission from JBoss and good practice for future activities

Operational Ease of Use

• Some of the more significant advances in JBoss AS 7 are around the operational ease of use. The configuration has been completely refactored around a multi-node domain model, though the simple single-instance view has been maintained for developer use as well
• There are stable, easy to use management APIs – so AS 7 deployments can be completely automated from Java or any other scripting environment.
• New shiny, task oriented domain console that also allows you to manage multiple, distributed nodes.

Anyway – time to stop reading and start playing : learn more about JBoss AS 7 here and get the bits here and provide feedback on community site.

Next post – how AS 7 relates to Red Hat’s commercial, fully supported distribution – JBoss Enterprise Application Platform 6.

Another day, another survey – this one from Tools Vendor ZeroTurnaround. From what I can tell survey participants were self-selected – but the results underline what has been a solid trend over the last several years and I’ve seen the same in internal surveys I’ve commissioned.

Below is the 2009 / 2010 Container Popularity chart. Note the significant decline of Websphere and Weblogic and the growth in leaner, Open Source containers like JBoss, Jetty and Tomcat.

Glassfish bucked this trend – likely due to uncertainty about it’s future under it’s new owner Oracle. JBoss showed only a little growth – I’ll put this down to a fairly slow year in 2010. But 2011 is going to be very, very different. We already have a Java EE 6 Web Profile container (released last week) and JBoss AS 7 is taking shape pretty rapidly. With our increased attention to slimming the footprint and increasing the speed of adopting new technology and standards like Java EE 6 — my prediction is that JBoss will catch or overtake Tomcat in the next year.

So thanks for the opportunity to explain some of this.

First the obvious disclaimer – yes I work for Red Hat. Specifically I am the Director of Product Management for JBoss Enterprise Application Platforms and as such responsible for the product roadmap and technical direction of JBoss branded products like JBoss EWS, EAP and EWP.

So let me explain Red Hat’s model – something we call the Fedora / RHEL model internally. Red Hat provides subscriptions for use of its Enterprise distributions. A subscription provides the following (in no particular order) :

• long-term world-class technical support – and we do it very well (PDF report)
• long-term application compatibility
• long-term stability and predictability
• long-term partner certifications
• legal assurance
• long-term provision of security patches, performance enhancements bug fixes and RFEs

It may seem contrary if you’re used to the traditional model of “buying bits” but in our model, the provision of the bits is somewhat secondary; it’s something we have to do to support the value outlined above. For example, partners will only certify their applications and products if we have some way of identifying specific releases – supporting a continuous stream of releases is impractical. We can only provide application compatibility if we focus on specific identified releases.

So, one of the entitlements of a subscription is access to the supported binary distributions of a product – this is the thing to which we can apply all the other things I’ve outlined above.

For all of Red Hat’s products there are one or more upstream Open Source projects. In the case of JBoss EAP – the JBoss AS project is the primary components but JBoss EAP also includes Seam, mod_cluster, Apache CXF to name a few. Some of the projects that Red Hat uses in it commercial platforms are essentially Red Hat (or JBoss) projects – we provide the majority of developers, drive the roadmap and the release cadence (eg. JBoss AS, Seam, Hibernate), for others we’re merely one collaborator among many (eg. Apache CXF, OpenJDK, Apache HTTP).

The upstream Open Source projects is where the innovation happens – the focus of many of the Open Source projects driven by Red Hat is to act as technology incubators. Releases for projects like JBoss AS are frequent, experimental features are released, refined and re-released. That’s the focus – agility, speed, innovation. There’s never been any promise, implicit or otherwise that any given release is suitable for running your business critical applications. In fact we make it pretty clear on JBoss.org :

OK, so let’s dig into the relationship between project (or community) releases and platform releases. I’ll use JBoss AS (project) / JBoss EAP (platform) as examples as they are among the most widely downloaded / deployed :

Let’s take the JBoss AS 5 branch which was the foundation of the most recent JBoss EAP 5 family. JBoss AS 5 was focussed on a couple of big things : i) providing a new level of modularity via the Microcontainer 2.0; and ii) providing a Java EE 5 certified container. JBoss AS 5.0.1 was released in February 2009, followed a few months later by 5.1.0.

JBoss AS 5.1.0 met our functional criteria for JBoss EAP so that is what we picked up for our ‘productization’ process and JBoss AS 5.1.0 essentially became the Alpha Release for JBoss EAP 5.

The productization process is really not dissimilar to the kind of process you’d see in any other software company – we bring in all the major components, refine the dependencies, remove duplicates, perform additional testing above and beyond the community / project testing – focussing on security, performance, scalability, failure, longevity and the component integration points. We also look at documentation and the certification of third-party products like databases, Operating Systems, JVMs and other Application that work with JBoss. During this process we also run a traditional Early Access Program (aka Alpha, Beta) – this augments the attention the individual components receive during their own community release cycles. We’re fortunate to have some very willing customers who are able to apply significant resources to push our technology very hard using real-life applications and operational scenarios – often finding issues that are very hard to flush out in QE or during community release cycles.

The result of this process is an Enterprise Platform GA that differs from the upstream binary release we started with. First, we bundle additional components – like APR (Apache Portable run-time), Seam, mod_cluster, Apache CXF. And the core JBoss AS we include has a large number of fixes to address the security, performance and other issues identified during the productization process.

But that’s just the start.

JBoss EAP is supported for 7 years and with every additional minor or micro release we further improve the performance, security and stability of the Enterprise Platform. We’ve now released 2 micro and one minor release of JBoss EAP – that’s about 150 top-level issues in total. While the issue rate will slow over time – we’ll still be in a position to fix issues and respond to new security threats in 2016.

All those fixes are made available upstream and will ultimately make there way in to upstream binary releases but what the upstream project can’t guarantee is that those fixes will be isolated from more substantial changes and improvements – community releases typically don’t distinguish compatible bug fixes from more intrusive changes that provide the innovation.

OK so what happens to the community project once we’ve delivered an application platform? Well in the case of AS 5.0, from a Red Hat contributor perspective – the work was complete and Red Hat’s developers moved on to the next wave of innovation in AS 6 and AS 7. The goal of AS 6 is to deliver a Java EE 6 Web Profile implementation, the goal of AS 7 is to tackle the operational use-cases with a new domain model and console.

So to summarize this rather long post – if you want to deploy your business critical applications and receive long term support from Red Hat then the JBoss Enterprise Platforms are what I would recommend – if you’re more interested in seeing how those platforms will evolve and more interested in emerging technology but willing to take on more risk then upstream projects are where you should be looking. It all a matter of assessing the risk.

I’ll be speaking at JBoss World / Red Hat Summit again this year. I’m part of 3 sessions focussed on JBoss :

JBoss Enterprise Application Platform Roadmap, Wednesday 2pm

I’ll be sharing our 3-year roadmap and will touch on Java EE 6, HornetQ, Infinispan, support next-Gen (aka Cloud) infrastructure. I’ll also go through some of the changes we’ve recently made to our “release taxonomy”. What I expect you to get from the session is a clear understanding of our major areas of focus and the direction that JBoss EAP is heading in so you can better plan your own deployments. I looked at the feedback forms from last year and the only 2 negative comments were “more chairs please” – hopefully we’ll have a bigger room this year but come early.

Andiamo – Towards Operational Excellence with JBoss, Wednesday 5.30pm

Myself, Andy Miller, Brian Stansberry, Jason Greene and Charles Crouch will be holding this BOF session to discuss some of the changes we’re considering for JBoss EAP 6. Generally the discussion will be around operational ease of use, management, monitoring, tuning, diagnostics, deployment. Getting community input at this stage is super important so come along and tell us what you’d like to see. There’s a good chance of beers afterwards

Java 2020

I’ll be sharing the stage with fellow Brit. and JBoss CTO – Mark Little to discuss Java past, present and future and give a Red Hat perspective of some of the challenges and opportunities ahead. We’ll be covering Next Gen. Infrastructure (aka cloud), Multi-language VMs, virtualization, SOA and many other subjects. We may have time towards the end to discuss England’s performance in the World Cup.

If there are questions or areas you’d like to see us specifically cover in these sessions – either leave me a comment or drop me an email (rich dot sharples at my employer dot com) or message (@richsharples).

JBoss World and Summit represents a great opportunity for me to meet some of my colleagues, learn about other technology areas at Red Hat and spend time with customers. As with all tech. conferences – the real value is in the contacts you make and the hall-way conversations you have. I’ll be around all week – if you want to chat – get in touch.

See you in Boston !

“First they ignore you, then they laugh at you, then they fight you, then they produce lame marketing videos, then you win.”

- with apologies to the late Mahatma Gandhi.

Actually, I’d say if your competitors are producing videos at the rate that the Websphere marketing team are producing them about JBoss I think you can safely conclude that they’ve given up all hope competing with products and technology. The latest almost makes me feel a little embarrassed for the Websphere team. How the mighty have fallen.

Apparently it was Apache Web Server’s 15th birthday yesterday – congratulations to anyone who’s ever been involved in the project. I doubt any would have thought that 15 years on, Apache would have become the dominant Web Server on the Web and the foundation of one of the most successful and recognized Open Source forges. For a history of the Apache Web Server and the Apache Software Foundation, head over to the ASF Blog.

Red Hat has been a supporter of Apache Web Server for a long time and has shipped and supported a version in its Red Hat Enterprise Linux for as long as I’ve been noodling with it. Last year we started shipping a standalone, multi-platform distribution as well – JBoss Enterprise Web Server. Earlier today we released the latest version of it and expanded our support for Apache HTTP Server to 14 different Operating System / architecture combinations. The exact component versions are listed here and there’s more information in the Release Notes. If you’re deploying Apache HTTP or Tomcat at scale – Red Hat also supports management of Apache HTTP Server and Tomcat alongside all JBoss products via JBoss Operations Network.

ForgeRock OpenAM is the market leading open source Authentication, Authorization, Entitlement and Federation product. ForgeRock is providing the community with a new home for Sun Microsystems’ OpenSSO product.

Good luck to ForgeRock – I recognize quite a few of the names as fellow Sun / iPlanet / Netscape Alumni. It will be interesting to see how this plays out – it got ugly the last time something like this happened.

Zallinger’s “March of Progress” from wikipedia.

I’ve been part of the Java ecosystem for long enough to see and be part of every Java EE / J2EE release to date. I still have a Forte SynerJ box-set somewhere – we claimed it as the first fully integrated J2EE 1.2 App Server and IDE – that was around 1999 and I was part of Sun for every subsequent release up to Java EE 5.

With the final votes in for Java EE 6 and with the year and decade coming to an end – it seems a fitting time to look back and see how far the Java EE platform has evolved :

• J2EE 1.2 (1999) – announced just short of 10 years ago was the first attempt to create an umberalla specification to cover some existing web-tier, messaging and data access technologies (JDBC, Servlets, JTA, etc.) as well as the new middle tier technology – EJBs.
• J2EE 1.3 (2001) – was from my recollection the first broadly adopted and deployed version, it added Connectors (a standard way to connect to back-end ‘legacy’ systems), some rudimentary support for XML Web Services and a pluggable security layer. EJBs got a major overhaul.
• J2EE 1.4 (2003) – added JMX, a gaggle of specs. to support Web Services (JAXR, JAX-RPC). I think around this time – everyone had written their first App. using EJB’s and had learned that combined with CMP (Container Managed Persistence) they weren’t exactly getting the productivity boost they were hoping for. I think J2EE 1.4 was the “Vista” of Enterprise Java – over-engineered and ultimately underwhelming.
• Java EE 5 (2006) – A name change and some new hope – mandatory XML deployment descriptors gave way to annotations, persistence took a lesson from the de-facto ORM solution – Hibernate. There was an alternative to, ahem, RPC-style Web Services with the inclusion of JAX-WS.
• Java EE 6 (2009) – It’s been a while in the making and had a bad start but after ten years I think we now really see the start of a cohesive platform with a common programming model via CDI (JSR-299) and many of the criticisms leveled at the platform have been answered.

Java EE 6 also defines the new Web Profile – this is essentially a slimmed-down EE focussed on web applications. I think it’s much more than that – I think it’s an opportunity to really redefine the Enterprise Java platform and shed some of the legacy APIs. While the backward compatibility that EE dictates has been good – it’s also contributed to some bloat in the platform.

It’s interesting to see how the size of the Java EE spec. has changed over the years (assuming size of the spec. is a reasonable indicator of complexity)

• J2EE 1.2 weighed in at just 140 pages;
• J2EE 1.3 added about another 25% (174 pages);
• J2EE 1.4 increased it by almost 40% (246 pages)
• Java EE 5 actually bought the page count down by 10%;
• and the last draft of the Java EE 6 spec. I read only added about 6% (236 pages) – despite some pretty major enhancements.

Despite several rounds of consolidation and various acquisitions – vendor support has remained impressive. There were 18 J2EE 1.2 certified servers, and even seven years later there were still 13 (for Java EE 5). I’d be surprised if there weren’t at least 10 vendors supporting Java EE 6 at some point – even after Oracle has assimilated BEA and Sun.

Despite its huge adoption, Java EE and the process by which it is defined (the JCP) has drawn a lot of criticism. Releases have often fallen short of expectations, been perceived as overly complex or taken too long to deliver; but despite the criticisms nobody can deny that Java EE has been a huge success. Java EE is not just a specification – its grown into an entire category of the software industry. I can think of no other technology that has bought so many competing vendors together to define such a broad and widely use platform.

I’m sure the JCP isn’t perfect and I’m sure vendor politics gets in the way of progress from time to time and Sun’s stewardship of Java hasn’t been flawless but step back and try to imagine what our industry would be like without an open and collaborative Java ecosystem. It will be interesting to see whether Oracle take a different approach (as they’ve suggested in the past) when they become the new stewards of Java. Let’s hope hey continue to encourage collaboration and diversity.

The various expert groups that define the Java platform is not, as many suggest, completely controlled by big vendors. My own company Red Hat is not an industry behemoth, there are divisions and offices within companies like IBM and Oracle that are bigger than Red Hat and JBoss, the middleware business unit of Red Hat is only a part of the entire company. Despite that – Red Hat has demonstrated yet again it’s willingness to punch way above it’s weight and has had an influence on Java EE disproportionate to it’s size. Congratulations to Gavin King, Pete Muir, Sacha Labourey. Emmanuel Bernard, etc for tirelessly pushing for simplicity in the EE platform.

JBoss AS 6 Milestone 1 is out and includes some of the key Java EE 6 features. Releases seem to be coming pretty frequently so you’ll see more EE 6 feature appearing over time.

Interestingly, Salesforce.com were joined by a couple of other PaaS vendors in the MQ this year – it will be interesting to see if there really is a new wave of infrastructure bearing down on the established platforms. The contemporary PaaS offerings I see today under-achieve as general purpose developer platforms and that leaves them competing with IAAS based on more traditional / established technology (Java, .NET) on cost and convenience terms. It will be good to see “Cloud” get beyond the current over-hyped phase so we can see how this will play out.

More Red Hat commentary here.

This week we GA’d JBoss EAP 5.0. As you’d expect from a new release there’s a long list of new features, capabilities and APIs and at some point I’ll talk about those some more. But the intention of this post is to give you an idea of some of the other less visible things that have happened with this release. EAP 5.0 marks a key milestone in the evolution of JBoss and demonstrates where we’re heading with the JBoss Platforms.

Performance

We set some pretty aggressive performance targets for this release. By comparison to JBoss EAP 4.3 we see an increase in peak throughput of about 20%, faster response times and more scalable HTTP connection handling. Performance is an ongoing activity and we’re continuing our investment in improving it in future releases. Performance at any cost is interesting to few outside of Formula 1 and Rocket Science and it isn’t a goal – we’re specifically interested in price / performance using a broad range of typical, real-life workloads.

Quality

Popular Open Source technologies (like JBoss AS – on which EAP is based) have always had the benefit of a large community who actively poke and prod. and push the software in different ways; who peer into the design and code and offer improvements.The result is some pretty decent, efficient and well polished code. But with the JBoss platforms we go one (or several steps) further. For EAP we had a long and active Early Access Program. It started back in April and is only now winding down as FCS customers complete their work. The diagram Below illustrates how we connect the AS and EAP lifecycle, the upstream (AS) GA essentially starts our EAP Early access program. This allows enterprise customers to start using a stable (though incomplete) release with the full backing of Red Hat Global Support.

Obviously the diagram is a massive oversimplification – EAP is more than AS – it is the integration point for Seam, RESTEasy, the installer, mod_cluster and the Apache Native components.

With every release we also enhance our QE coverage; in the case of this release there was a bigger focus on Performance, Stress and Longevity testing using larger and more complex topologies and a broader range of workloads.

Lifecycle

We’ve also refreshed and restated our product update and support policy for all JBoss platforms – the hope is that it’s more clear, better aligned with other products from Red Hat and puts even more distance between us and our Open Source competitors.

Ease of Use

A while back we kicked of an Internal initiative called “Andiamo” – I talked a little about it at JBoss World, and Mark wrote about it recently. While much of what we have planned around Operational and Development Ease of Use is planned for release beyond EAP 5.0, EAP 5.0 does lay the foundation for some of the things we need to achieve. The new Microcontainer provides us a very flexible and powerful toolbox that will allow us to build the middleware platform for the next decade. Specifically around ease of use, and as a taste of things to come we did provide a first cut of the new embedded console (it replaces the old JMX and Web Consoles). It has pretty limited functionality right now but I think it achieves the goal of making simple tasks simple to do.

What’s Next ?

The EAP Springtime Release (nominally EAP 5.1) is well underway and we’ll be pushing for even greater performance gains as well as defining the target platform for an upcoming Common Citeria (EAL 4+) certification.

We’re also underway with the EAP Lancer Release (nominally EAP 6.0) which will be the first major output of the Andiamo work as well as supporting the new Java EE 6 platform.

Onwards and Upwards.