Red Hat muscles in on Ellison's Java fluffing gig
Linux company claims middleware cred
Red Hat is chipping in on Oracle's plan to fluff server-side Java - reported exclusively by The Reg - so Larry Ellison's database giant can't claim all the credit for moving the platform forward.
The open sourcer has this week submitted a number of proposed specifications on the planned Java Enterprise Edition (Java EE) 7 to the Java Community Process (JCP). The JCP is the Oracle-controlled body with the final say on all new features in Java running on mobile, desktops, and servers.
Detailing its proposals for The Reg, Red Hat claimed that it has a strong tradition of contributing changes to Java, and that it's maintaining this tradition with Java EE 7.
Java EE 7 is actually an Oracle-authored plan, but the giant has made it clear it is looking to others in the Java EE market for help in its delivery. Under Oracle's plan, Java EE 7 is expected in the third quarter of 2012.
Rich Sharples, Red Hat's director of application platforms, told us that Red Hat was a big contributor to the Java EE 6, by virtue of its acquisition of JBoss in April 2006 for $350m. Until the acquisition, Red Hat was known for one thing: Linux. Some would say that's still the case.
This time around, Red Hat will collaborate on the same number of specs as it did for Java EE 6, Sharples said, but will do a bit more leading from the front on specific issues than it has in the past.
Red Hat has taken the lead in three big areas with its JCP submissions. The first of these is Context and Dependency Injection 1.1, a rev on the code that was one of the big enhancements in Java EE 6, and that allows for Java applications spread across multiple tiers to interact in a loosely coupled way.
The second big spec covers distributed data grids. Red Hat is keen on bringing distributed data grids to Java so that storage can scale to match the horizontal scaling of the Java virtual machines and the Enterprise Editions extensions.
"Scaling the data tier has been more complicated because of the state and nature of databases," says Sharples. The JBoss Infinispan data grid, which is now under development and which is going to ship in the next release of Red Hat's JBoss Enterprise Application Platform, is one example of data grids that Red Hat wants to see for Java platforms.
The company is also adding the application-isolation, security, class-loading, application-versioning, and quality-of-services features that are due to be part of the Java EE 7 spec to its own Java middleware.
The final big spec Red Hat is pushing provides for a consistent way to validate Java code, from the persistence layer back on servers out to the presentation layer on clients. In other words: Bean Validation. The idea is that having the same validation logic across the various Java stacks – mobile, desktop, and server – will make development easier and faster.
In addition to leading on the above fronts, Red Hat is participating in a number of Java Specification Requests (JSRs). It's working on the Java API for RESTful Web Services 2.0 (JSR-339), Java Message Service 2.0 (JSR-343), Java Server Faces 2.2 (JSR-344), and Java Content Repository API (JSR-333) efforts.
More generally, Red Hat is championing the use of HTML5 because, as Sharples told us, "we need more device independence."
Red Hat is also fully behind the adoption of Web Sockets, which is an upgrade to the HTTP protocol that is part of HTML5. Web Sockets does for full-duplex, bidirectional streaming between client and server over the TCP network instead of this ping-ponging that slows everything down in the HTTP stack. Technically, Web Sockets is a kind of on-demand upgrade to the HTTP protocol that you can call for in applications.
Sharples told us the company is also concerned about making Java applications "more amenable" to cloudy infrastructure. That concern extends to raw infrastructure clouds and for platform-as-a-service clouds, which don't let users get down into the guts of the virtual servers but instead expose runtime environments as services that they plop their code onto, and expose databases as services that they then hook those apps into.
"There are a lot of technical changes that need to be done for application isolation and multi-tenancy," Sharples said. ®
Sponsored: Global DDoS threat landscape report