Java is Still the Future for Enterprise App. Development

I tried to add a comment to the Forrester blog but I received a “Validation Error” – here’s my comment to Mike Gualtieri’s blog post : “Java Is a Dead-End for Enterprise App Development”

Mike makes some valid points but to claim that Java is a dead-end is a bit sensationalist. By Forrester’s own data – it’s the only mainstream tech. that’s showed sustained growth over the last couple of years – I’m fairly sure 2010 data will continue the same trend.

Sure, Java has it’s limitations and it’s continued commitment to compatibility has hindered its ability to meet new needs but there still really is no better alternative. While Ruby, Scala, Groovy, etc. are compelling for some applications they would need unprecedented sustained growth before they become real main-stream alternatives to Java or .NET. During that adoption ramp they will no-doubt expand to meet additional requirements and their simplicity will be compromised.

These things move at glacial paces – I still meet with customers who are only just starting out with Java. It’s important not to be biased by what the alpha-geeks are looking for – it’s the late majority that provide the momentum.

The JBoss Product Lifecycle Explained

There was a fairly innocuous post on the interwebs at the end of last week which Oracle employees have jumped all over in an effort to discredit JBoss. I’ll rise above the petty mud-slinging and instead use this post to explain the relationship between upstream projects that JBoss uses and the downstream platforms that JBoss supports. It is my hope that people can then make their own informed decision about what to use to deploy their own applications.

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).

Screen shot 2010-11-21 at 8.55.41 AM.png

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 :

Screen shot 2010-11-21 at 8.40.58 AM.png

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.

Screen shot 2010-11-21 at 8.56.33 AM.png

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.

Screen shot 2010-11-21 at 9.17.25 AM.png

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.

JBoss World Red Hat Summit 2010

Summit2010_OfficialSpeaker_jbw_180x150_0310LL.png

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 !

Oracle and the Java Opportunity

I guess there’s a chance that we’ll know more tomorrow but regarding the future of Java under Oracle’s control – I’m still neutral to optimistic and sticking to what I said 6 months ago :

DZone: With Oracle’s acquisition of Sun, are you concerned at all about some of the potential changes that will come as a result, to the governance and licensing options to the OpenJDK?

Rich: I’m really not that concerned. There are all sorts of scenarios that people are suggesting. I still believe Oracle will do the right thing. They have far too much to lose, by either accidently or purposely sabotaging OpenJDK. They have a very healthy business based around Java. Creating unrest, creating any kind of distrust or fragmentation of the Java community really isn’t going to help Oracle. So I think they’ll do the right thing. I also think they probably have the ability to invest in Java more than Sun had over the last five years at least. Sun kind of had some fairly pressing financial issues. I think that, above all else, probably hindered some of the progress of Java over the last five years.

So overall, I’m coming in neutral to slightly optimistic. If things do go awry, I’m sure Red Hat the rest of the Java community will step up and help Oracle to get back on track. So, yeah, I’m pretty comfortable with it.

My only real concerns is that Oracle understands products and monetization much better than they understand community and collaboration so I think a misstep or two are more likely to occur than Oracle purposefully sabotaging Java. Harming Java will devalue their investment and their chances of getting a decent return.

On the positive side – I think there’s still huge growth potential for the Java platform – I see no reason why it can’t become the dominant standard for the enterprise – I personally think we’re at the start of the decline of Microsoft and Java is the only viable alternative to Microsoft’s enterprise foothold. Microsoft’s enterprise presence is not insignificant but neither is it guaranteed – it’s largely based on an historically well adopted OS and Microsoft’s missteps in that area are pretty well known by now .

Java needs some strong leadership, investment and a open, vibrant and growing community.

I raising my mug of tea to The Next Decade of Java !

JBoss Application Platform Q&A

Yesterday we started a series of Web Casts covering JBoss Application Platforms (Recording, Slides). We didn’t manage to cover all the questions in the Q&A so as promised here they are :

Q: When using your Apache & Tomcat bundled software, do you provide any additional security patches above and beyond what the Apache & Tomcat communities provide ?

A: Red Hat has a dedicated Security Response Team who’s role is to track alerts and security vulnerabilities in the community which may affect users of Red Hat products and services. They work with Open Source communities to identify, classify, diagnose and coordinate fixes. If Red Hat discovered a vulnerability in any Open Source project we would work with the community to coordinate a fix, we wouldn’t keep it secret.Where we might differ from the upstream project is in how we communicate the presence of vulnerabilities and deliver fixes to our customers.


Q: can you guys point out to any benchmarks on jboss as in comparison to the other j2ee containers available (ideally updated every once in a while) online for the people who look into jboss AS evaluation to come and compare it easily with the other AS and

We don’t currently have any public benchmarks comparing JBoss to other vendors. All proprietary vendors have specific restrictions in their EULA forbidding use in benchmarks, so the only viable way to provide a comparison is by comparing vendors submissions for some thing like SPECjAppServer2004. JBoss has long argued that SPECjAppServer2004 does not represent contemporary use of modern app. servers (a position that IBM now agree with) as such we’ve never paid much attention to SPECjAppServer2004 and we’ve never made a public submission. JBoss has been working with SPEC on a new benchmark which we think does better represent modern application server usage and we will, in time, provide our own public submissions.

Meanwhile, many customers who have moved large deployments from our proprietary competitors to JBoss typically cite overall cost saving as the main reason. Performance and overall cost are tightly linked.


Q: what is the official release date of EWP ?

A: Right now the best date I can give you is that it will be released sometime in this Calendar Quarter.


Q: why isn’t seam part of the web toolkit ?

A. That’s the long-term goal. ie. to separate the frameworks from the run-tmes as they typically evolve at different rates. We also want all the frameworks to be certified on all the run-times. This is a form of Pace Layering and I think it provides the greatest flexibility / agility.


Q: What is the level of support you give spring as part of the web toolkit ?

A. With the first version of the Web Framework Kit – Spring is a Technical Preview and not recommended for production use. The intention is to promote Spring to fully supported in the next minor release.


Q: why do you think glassfish managed to have jee5 server so soon ?

A. Because Sun is the spec. lead for Java EE – they have to deliver the Spec., the Reference Implementation and the TCK. It’s impractical for anyone to deliver an implementation before Sun. Just as it is impractical for anyone to deliver an implementation of Java CDI before Red Hat (the spec. lead).


Q: Are these versions (EWS, EWP, EAP) available in the community version, or only the enterprise version ?

A : The community version for EWS is Tomcat, mod_jk and Apache HTTP – you can see the exact versions included in EWS here. JBoss EWP only exists as a ‘profile’ in AS 5.1. You can see the exact component versions for the platforms on their respective web pages, eg. component page for JBoss EAP.


Q: When will EAP 5.0 be Java EE 6 certified ?

A. There is no plan to certify EAP 5.0 with the EE 6 TCK. EAP 5.0 supports Java EE 5, though it does include some features of Java EE 6 – specifically JAX-RS (RestEasy) and the Web Profile. If you want to see ho were progressing with Java EE 6 then take a look at JBoss AS 6.


Q: I would like easier upgrade path in RH Jboss vs jboss.org when you have your customized apps.. or is this a no problem ?

A : As long as you’re using the same base versions – portability should not be a problem. You can use this page to see what version level of components are included in EAP.


Q: What type of improvements are you looking at in order to support Cloud environments ?

A. Here are some of my thoughts :

  • Larger managed domains, possibly shared across BUs, requiring delegated administration and isolation.
  • More automated – everything needs to be easily automated or autonomous by design
  • Automation is just as likely driven by pre-defined policy as by a human sys. admin.
  • Better support for virtualized environments
  • Lower resource utilization
  • More dynamic – eg. to deal with elasticity – grow and shrink environments depending on pre-defined policies

Bob McWhirter and Marek Goldmann have been experimenting and prototyping some of these areas as part of the StormGrind project – take a look.


Q: Would web application developed in Jboss work on tomcat ?

A: JBoss EWP / EAP is a superset of Tomcat – as long as you limit your app. to use just the Web Container (ie. Servlet, JSP) – your app. will be portable. The web-container in JBoss EWP / EAP is based on Tomcat 6.0.18 so obviously supports the same versions of the Servlet (2.5) and JSP (2.1) specs. Tomcat 6.0.18 is also what we include in JBoss EWS.


Q: are there any limitations in the number or requests handled by using mod_jk ?

A. Good one – let me find out. Check this space for an update.
A. I checked with Jean-Frederic Clere, his response is :
“Apart from the OS limitations and httpd limitations (configuration in
httpd.conf, MaxClients for example) there aren’t any limits in the
number of requests mod_jk could handle.”


Q. where can I get the slides ?A. At some point they’ll appear along with the recorded sessions here.

JBoss : Vision and Execution

Another nice score card from Gartner puts JBoss Enterprise App. Platform in the leader’s quadrant of the Gartner Magic Quadrant for Enterprise Application Servers. That’s the fourth year in a row, in case you were wondering. Unscientific as it is – comparing with last year I’d say the leaders are widening the gap (cumulative advantage ?) and JBoss specifically has inched up on the Ability to Execute axis.

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.

Releases / Lifecycles and other Product Management Miscellany

jbosscorp_logo.png

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.

Screen shot 2009-11-06 at 9.50.09 AM.png

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.

Screen shot 2009-11-06 at 9.54.11 AM.png

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.

JBoss Open Choice

Earlier this week we announced a couple of things. First, a change in our platform strategy, second some new products to implement that strategy. We felt we had to give that strategy a name and “Open Choice”, while unoriginal, best illustrated what we’re doing. And what we’re doing is expanding our support to include Open Source technologies  beyond what we’ve typically supported and beyond the JBoss constellation.

This is a reaction to a) customer demand; and b) the realization that not all the cool stuff is created by JBoss. What we’re also doing is reacting to market demand. Java EE, while hugely successful is not the only game in town any more.

j2ee-spring1

We want to ensure that our customers get to choose whatever frameworks, languages, development models they want without causing major disruption for the operations people who have to manage the applications for the other 90% of the application lifecyle (ie. outside development). We also want to remove the risk of deploying new developer oriented tech. by providing a stable, consistent operational footprint (JBoss) to run the resulting apps.

Note – I normally don’t use Job Trends data in isolation to make serious decisions, but it’s convenient and lazy way to find what keywords are trending.

So yes, this is a reactive move; we’re reacting to customer demand and market pressure – we’re really not reacting to anything that Spring Source is doing. I’ll post another blog explaining what we’re including in our Web Framework Kit and why; but Spring Framework is included for much the same reason as struts – they’re mature technologies and both are very widely deployed :

spring-struts

It’s no secret that a big chunk of our business comes from our much larger but less nimble competitors and we have to ensure that migration is a simple and low risk proposition.

spring

As the chart shows (if you have any faith in the data) – Spring Framework usage is fairly evenly distributed across the Java container landscape. By making JBoss a better place to run Spring (among other things) – I believe that we can change this landscape dramatically.

This really isn’t about Spring Source – in fact we don’t even compete with Spring Source. Our sights are set much higher.

New – JBoss MASS – Migration Analysis Tool

jbossmass_logo_450px

It’s been just over 3 months since we created the JBoss MASS project and today we’re announcing the first major code contribution – The Migration Analysis Tool (MAT) was created by Mitch Mocle and team at Middleware Connections. The tool is used as a starting point for estimating the effort required to migrate a group of J2EE applications  from an Oracle/BEA WebLogic environment to a JBoss AS / JBoss EAP environment.

The tool produces detailed HTML reports covering Server Configuration, Deployed Applications and Class Dependencies. Read More on the MAT sub-project page.

This is an important first step. The goal of JBoss MASS is to provide a common place to develop tools for migrating to JBoss – if you have or are thinking of developing such a tool and think that Open Source collaboration might be a good way to enhance and maintain the technology – get in touch.