Reading between the lines of Red Hat's Google Web Toolkit play
Red Hat is partnering with Google to build on Google's Web Toolkit (GWT), technology that enables users to cross-compile and optimize Java code as JavaScript for use in different browsers.
But what does this mean? Why should anyone care?
Rich Sharples, director of Product Management at Red Hat, suggests that GWT was the shortest route to cutting through the clutter of competing RIA solutions like Appcelerator, a startup that employs some JBoss veterans and which just raised $4.1 million in venture capital and wants to displace Adobe AIR and other Rich Internet Application (RIA) platforms...like GWT:
The world doesn't need another Java framework for developing rich AJAX apps. so we've decided to go with what we think is a real leader - Google Web Toolkit.
But Red Hat's work with GWT isn't about competitors, as Sharples told me in a follow-up email. It's about customers and developers, and offers significant insight to Red Hat's development strategy:
If there is a grand plan, it's to deliver what developers and customers actually want. We're a demand-driven business - if we don't give customers that they want then we face the prospect of having to compete with some much larger and much more powerful competitors on [their] terms [, not the customers'].
I think that JBoss/Red Hat represents a maturity with respect to how it views technology that I haven't seen anywhere else....[T]he reason we can punch way above our weight is because we've accepted that we don't have to be the sole source of innovation for everything we ship: we're willing to forego some control for the advantage of being able to deliver a technology stack composed of the best, most popular components.
That's practical because we've spent the last 3 years building a very flexible and adaptable server-side platform (JBoss AS 5.0.0) - the same run-time can be use to deploy stateless GWT apps., Spring apps., Ruby apps. or BPEL or Java EE / Seam apps. or whatever else comes along. We won't inflict a different run-time on customers just because they choose a new framework or technology. Operations people like stability and consistency. Developers like choice.
In other words, Red Hat's work with GWT is a chance for Red Hat to cater to developers already-expressed desires for a Red Hat RIA story, but within the context of the enterprise. This, of course, requires a developer focus, and for that I also asked Michael Neale, a senior engineer on the JBoss Drools project with Red Hat, to give me the developer perspective on Red Hat's GWT development:
We started using GWT in various places, liked it, shipped stuff to customers, who said, "Hey we like that how did you do it? We want to do that." Now here we are, sharing our own integration dog-food, so to speak....
The browser isn't perfect, but it's what everyone has on their desktop, and it's now a reasonably rich run-time environment in its own right....GWT is [therefore] nice in that it lets you do rich client apps "in the large" yet have users in Internet Explorer, Opera, etc. and have them "Just Work."...
So what do we bring to GWT? Well Google built GWT for their own purposes..., so that gives it a flavour that suits them, but we are hoping to add widgets and features to it that are useful in more modern but still "boring business apps" - the bread and butter of the business world.
This last sentence describes Red Hat's overarching philosophy, in my opinion, and one of which its competitors would do well to take notice: Red Hat is all about taking the rapid, interesting innovation of open-source development communities and making it digestible by conservative, slow-moving enterprises. Red Hat's work with Google's GWT is no exception, as Sharples noted to me in a follow-up email:
From a technology perspective, I do think there is something interesting here: GWT represents a particular design centre that satisfies Google's primary requirement of massive scale by pushing state and processing onto the client. The established Java EE model - the market that JBoss successfully dominated - is all about doing the work on the server and limiting the client (browser) workload to rendering HTML and CSS, which gives you advantages around security and availability.
Both models have their place. They're both right for a certain set of scenarios. But where things get interesting is when you need to need both, i.e., high-value, secure, transactional applications that need to be served at massive scale (e.g., online banking, e-commerce). Combining those ideas could deliver some really interesting architectures that would apply equally well to other RIA technologies like Flash, JavaFX, etc.
In short, Red Hat is taking Google's vision of massive, Web-scale technology and applying it to more "mundane" enterprise needs.
Interesting in and of itself, but fascinating when you apply it to Red Hat's larger strategy: harnessing open source for the enterprise. No one does this better than Red Hat, which is why, for all Red Hat's potential pitfalls, it remains one of the most dangerous competitors to established software orthodoxy.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
- by eaudet1970 December 15, 2008 6:40 AM PST
- Great article!
- Like this Reply to this comment
-
(3 Comments)One thing, you mentioned that J2EE is oriented towards thin client where GWT is more of a fat client. You probably meant MVC (Model View Controller) that is really focusing on thin client. Java EE, if used in the right way, it will make your back a lot more scalable, secure, and maintainable. GWT is very easy to integrate with a Java EE backend.
- Erick Audet