Why Adopt JBoss Enterprise Platforms?

Since we started releasing our Enterprise Platform offerings, there has been some confusion as to why would someone become a subscriber and adopt the enterprise platforms, such as the Enterprise Application Platform or the Enterprise SOA Platform, versus just downloading the jboss.org bits and using them for free?

This is certainly a legitimate question, and one that I get a lot. It also has some history behind it, since our original product model was every release on jboss.org was a supported product that you could purchase a support subscription for. With this split between having jboss.org releases be just for community consumption, and not for paying customers, confusion has reigned supreme. With that, let's talk about the reason we even went down this path.

One of the biggest issues our customers faced was stability. Under the old product model, there were fairly major changes and/or feature enhancements even in dot dot dot releases, which had the potential for breaking customers applications. That was certainly the number one problem our customers were facing, and we had to address that. While there are other issues that drove us to the new product model, stability was the number one reason. Many of our customers want a product that they can deploy, and that they know will guarantee compatibility over many years. We just didn't deliver that under the old model.

With that in mind, what are the differences between the enterprise platform releases and the jboss.org releases?

I will use our JBoss Application server, and Enterprise Application Platform as an example. With the JBoss AS project, we release based on passing two test suites (unit tests and compatibility matrix tests) which are a part of the open source project. When we have the features and fixes targeted for that release, and the test suites are 100% passing, we release the code to the community. Now, the test suites are substantial, with getting close to 4,000 tests in them. Having said that, it is run with one JVM, the Sun 1.5 JVM, on one OS platform, which happens to be Red Hat Enterprise Linux (this has actually been the case for many years, even before the Red Hat acquisition of JBoss). Now, let's contrast that to what we do for the Enterprise Application Platform.

We still do use the aforementioned test suites, but we run them on a combination of JVM's and OS's. For example, with EAP 4.3, we have run the test suites against the following JVM and OS combinations:

1. BEA JRockit 1.5 JVM on RHEL 4 x86
2. BEA JRockit 1.5 JVM on RHEL 4 x86_64
3. BEA JRockit 1.5 JVM on RHEL 5 x86
4. BEA JRockit 1.5 JVM on RHEL 5 x86_64
5. BEA JRockit 1.5 JVM on Windows 2003 x86
6. BEA JRockit 1.5 JVM on Windows 2003 x86_64
7. HP 1.5 JVM on HP-UX 11i IA64
8. HP 1.5 JVM on HP-UX 11i PA-RISC
9. Sun 1.5 JVM on RHEL 5 x86
10. Sun 1.5 JVM on RHEL 4 x86_64
11. Sun 1.5 JVM on Solaris 9
12. Sun 1.5 JVM on Solaris 10
13. Sun 1.5 JVM on Windows 2003 x86
14. Sun 1.5 JVM on Windows 2003 x86_64
15. Sun 1.5 JVM on RHEL 4 x86
16. Sun 1.5 JVM on RHEL 4 x86_64

This is our tier 1 set of platforms, and post the release we have continued to test other combinations, such as the IBM 1.5 JVM (EAP 4.3 was released in January, 2008). Through this testing we catch issues both with the test suite, and with our code that never makes it to our customers. Besides this testing, we also incorporate some of the individual component test suites, such as:

• EJB 3
• JBoss Web Services
• JBoss Remoting
• Hibernate

This in and of itself is a big step forward in our quality, but that isn't were we stop.

We have created another set of tests for performance and scalability. We do performance and scalability testing for:

• EJB 3
• JBoss Seam

These are our two most important parts of the Enterprise Application Platform, from a performance perspective, for our customers. Therefore, we want to make sure that there aren't any inherent performance and scalability problems with these features of the platform. We also use these tests for reliability testing, in the form of a soak test.

In the soak testing, we run at high-load, for an extended period of time (24 to 36 hours). This allows us to make sure there aren't issues that our customers will face that affect uptime of their deployments. Once again, we don't stop there.

With Hibernate we test against the following set of databases:

1. Microsoft SQL Server 2005
2. MySQL 5.0
3. PostgreSQL 8.2
4. Oracle 9i
5. Oracle 10g

Against the above databases, we also use the database portion of the J2EE 1.4 TCK to make sure our EJB 2.x implementation works appropriately across these databases as well. This is also our tier 1 list of databases, just like the JVM and OS combinations. Since release, we are also doing testing with DB2 and Sybase. Again, we aren't done yet.

We also do testing around our clustering technologies, such as:

• HTTP Session Replication
• JMS Clustering
• JMS Fail-over

With the introduction of JBoss Messaging in the EAP 4.3 release, we now have clustering and fail-over capabilities that were not in the old JBoss MQ that it replaces, and hence we have added testing specifically for these new capabilities. Finally, there are a set of tests that cover installation and management, which include:

• GUI Installer
• JBoss Operations Network (JON)
• RPM testing

Whew! As you can see this is a lot of testing that is new with the Enterprise Application Platform, that never existing with our old product model, and is only applied to the platform products. Now what do we do with all the fixes that result from all this new testing?

Fixes go directly onto the appropriate branch for the enterprise platform, and they also go upstream into the community. Of course, the fixes that go upstream don't have any SLA associated with them and the code branches are substantially different from each other. Also, the upstream jboss.org releases may also have new features in them that aren't in the enterprise platforms. Post release of the enterprise platforms, we also do quarterly cumulative patch releases, and over time, because we don't add new features, the code continues to diverge from the upstream jboss.org releases. This goes right to the heart of the stability our customers want, and we deliver these platforms with a quality level that is unmatched in our old model.

If you want a stable platform to develop your applications on, that won't break your applications over time (3 year full support, with 2 year of security errata support), then the JBoss Enterprise Platforms are for you!