If the entire Glassfish eco-system does come to Google, as I have written about for the past two to three months, the continuation of the clustering work on v. 3.1 is priority one, as the Oracle engineers are doing via Sun management, but that does not say that strong consideration to countering BizTalk does not get addressed in the form of extending JBI, and making the Glassfish ESB, the de-facto standard among integration platforms. First of all, there is a pre-built marketplace of independently developed JBI components, that would allow Google to emphasize its own standard implementations of JBI components, that embrace and extend the Google technology offering, and make sure that the enterprise is not forgotten in the long slog, but inevitable, of destroying Microsoft. Apple is priority one with the iPhone v. Android mega-battle among developers, but you can’t keep your eye off Redmond, and Chrome OS only addresses Windows from the front-end, you have to go to the back-end to truly kill off the threat of millions of shops around the world, that run the Server from Microsoft, and are ripe for an upgrade cycle on .Net w/ Visual Studio being recently refreshed, and BizTalk coming on-line for real, for once, in the second-half of this year. That is why when the deal between Google and Oracle does happen to swap hardware know-how for an enterprise java implementation, it has to be everything, Oracle cannot be scared for the competitive implications, they have to give Google all of Glassfish, including the Reference Implementation, and the ESB…. The ESB, as I have long argued with the guys from MuleSoft about on TSS, has to be standardized, you can’t have competing platforms, running around doing their own technology, it has to come from Java, and it has to come from Google, and the integration spec’s will still run through the JCP, as dictated by Google, because they don’t have a lot of enterprise software experience, and need the expertise of JBoss, SAP, and even SpringSource, if Google can get Spring back in the standards game. Integration has to come from JBI, as that is the only model that guarantees portability among vendors, and is the only definitive success of the ESB-era, an era that has seen so little growth, for all the potential that is there, that it has to be on the backs of the remaining vendors, to get on-board the Google Enterprise Java train, and back Glassfish, and become premium ISVs because they are essentially partnering with the only company, left, who can successfully fend off Microsoft, on all fronts, including the enterprise side. I sometime go to that Glassfish ESB sites, and marvel at the components that are available, as it is exactly what I tried to do when I was at Sun, but that was with EJB components, in the era of v. 2.0 and 2.1, when Spring had a legitimate grief with the EJB component standard, it was not ready for prime-time. JBI is ready for prime-time, today. Google only enhances its reputation with Java developers, who have bet their career on the only development technology in the last twenty years to really provide an alternative completely off of Microsoft. Google has to get in this game, they were built on the vision of kicking slow, proprietary, lock-in software out of the marketplace, and letting developers make money on their own talents, not the scraps left behind by a uni-vendor marketplace. Google is every developer’s dream, it gives them code that is relatively straight-forward to handle, they publish their API’s, they work diligently on cementing open source software’s place in the enterprise. Google and Glassfish would be a lethal combination. With a platform to build around, Google would kick-up the refresh cycle on Java to a level that a hardware vendor could never do, and make it so easy to use enterprise Java, that people begin to come back, off of PHP, Python, Spring, Hibernate, and non-standard web application development, and on to Google’s implementation of JSF, Servlets, EJBs, JBI, and Go, Guice, and WebToolKit, that will all be part of the Enterprise Java R.I. The ESB simply ups the ante of how deep Google is able to go in to accounts, and provide everything that a company needs, they just need an area Google account manager, to keep them updated on their monthly bill for AdWords, Android, Chrome OS, and Glassfish. That is the marching orders of all Google account rep’s: get your customers to buy-in to the Google model, get them all on the web advertising innovation kick, get the company’s developers using Google products to code, and then getting them to take the all-you-can-eat Google offering, which still is millions of dollars cheaper per year than Microsoft Windows, and all its business-killing tie-ins. Google does not need to make a lot of money in enterprise software on the current model. They just need to convert all those enterprise customers to AppEngine via Glassfish development, as Spring runs on Glassfish, today, and would just be another piece of the standard that is offered for enterprise java shops. Google does not need to charge per CPU pricing, or per user pricing, they just need customers to buy-in to the Google model of putting absolutely everything on the web, and the money will follow. The more depth, more data, more Java applications working properly in the enterprise, the more productive Google’s customers are with their technologies, the more they will throw at Google, just to keep them happy. There is a real dearth of ideas of where to go next, with Enterprise Java, no one is happy. Only Google can step in and create the vigor that was there in 2000, when there were 32 application server implementations, from all sorts of companies, nearly all of which have either morphed or died, or been bought. Google would get Enterprise Java back on the radar, it is in their interests to take on Spring as a supported technology, but you are not going to kill .Net with Spring, its just not gonna happen. Google, more than any move out of shipping iterations of Android and Chrome OS, needs an enterprise software story beyond AppEngine, to give developers a reason to flock back to Java, to get behind Guice, to get in to the cloud, to get on the phone, to get in the t.v., to get on the ads, to set-up Buzz and Wave marketplaces, to establish Google as the leading voice for developers who simply refuse to be locked-in to a vendor’s whim. Only Google can deliver this, and only Google will get the developers’ attention, if Glassfish comes over, it is time for the discussion to be had of what terms can be had: what level of sophistication does Oracle get from Google on x86 hardware datacenters? who leads the JCP? who makes money off of Enterprise Java on the ERP end of the business? what do you do if the Google Glassfish ESB is up against the Oracle WebLogic ESB, in a competitive account? how should it be handled? All of these questions need answers, to take the next step, but it is time. It is time to take on Microsoft on all-fronts, and that means staring down the long-embedded challenge of .Net, wherever it lives, at IIS, at building a better Glassfish Developer Tool set, at making the ESB run smoothly from download, to set-up, to implementation, all of this is needed to be done, all of this is necessary for Microsoft not to get free from the death grip that Google has them in, but it only happens if someone at Google walks across 101, and sits in Chuck Phillips’ office, and says we are willing to do a deal with you. One-time offer, take-it-or-leave-it, and no more for some time, but we are willing to give you our hardware spec’s for you to sell in your Sun server division, in exchange for controlling interest in the Reference Implementation of Enterprise Java. Nothing else needs to be exchanged, except engineers, moving from one company to the next, or consulting with each other, and remaining the same employee of the same company, just working together, in both are mutual interest. Does that not make sense? Java