Select a language
At Red Hat, we’re customer driven; we have to be because our annual subscription model depends on it. If we’re not providing ongoing value to our customers, there’s no incentive for them to renew their subscriptions. Our JBoss Open Choice application platform strategy is rooted in these concepts. It came about through conversations with our customers about the way they’re building modern applications and what they’re most concerned with going forward.
Why JBoss Open Choice?
Before migrating to JBoss many of our customers start out on expensive, complex closed-source application servers from the two largest commercial vendors, but soon realize that the value they’re receiving from these proprietary vendors fails to justify the expensive license costs that range from $15,000 to $40,000 per CPU and the ongoing annual support and maintenance costs at 20% of the license fee. In addition to the high-cost, we believe many existing Java application servers can’t easily address the variety that exists in today’s market. Our customers are looking for a flexible and stable platform, which is what the JBoss Enterprise Middleware portfolio delivers.
JBoss Open Choice, at its core, is about this flexibility. The flexibility to choose the programming model that fits your application – Java EE, POJOs, OSGi, Spring, Rich Applications or whatever comes next. Our JBoss customers use all of these programming models in their environments, but today, have to use multiple platforms with different footprints, management tools and steep learning curves. Our unique JBoss Microcontainer architecture is designed to support this variety of programming styles, without making compromises in operational capabilities or locking a customer into to a specific deployment model. The JBoss Open Choice strategy is intended to provide our customers with the flexibility they need both today and tomorrow, while at the same time, making it easier for operations teams to manage through the evolutions in programming models that occur over time.
Why Is Our Architecture better?
As evident from the earlier days of JBoss when we introduced our microkernel architecture in 2000, the open source development model forces us to aim to create a highly flexible and pluggable architecture that can easily integrate the best enterprise services and technologies that open source has to offer. With the JBoss Microcontainer, we’ve expanded this concept in an effort to create a platform that provides both flexibility, but also maintains operational stability that isolates users from any change in programming style. As a result, we believe we are a generation ahead of the competition in understanding how to build a flexible microcontainer based application server.
As an example, many of the other application server vendors are focusing on OSGi-based architectures or are trying to augment their existing monolithic, single-programming model architecture into something it was never meant to support. Their approach has resulted in multiple products, all with separate architectures and separate management learning curves. For JBoss, initiatives like OSGi don’t provide a rich enough basis for our core foundation – in many respects OSGi delivers just a sub-set of the JBoss Microcontainer’s requirements. Due to the dynamic nature of Java technologies, we believe implementations that are based purely on OSGi or are focused on single, monolithic programming models will be severely limited and will not provide the flexibility and manageability that all server vendors will require in the coming years.
Customers Speak. We Listen.
Our customers have spoken – the one size fits all approach taken by the two largest proprietary application server providers no longer works for today’s dynamic Java environment. Our customers use a variety of programming models and require lighter- weight platforms to support these, backed by a single management footprint – this is something that these vendors simply don’t provide today. We’ve seen success with JBoss at the expense of these large commercial vendors because our customers require a flexible architecture and affordable solutions that won’t lock them in; this is exactly what JBoss Open Choice is intended to provide.