Application Platform Strategies Blog

Open Source is not as Open as Standard Specifications

Blogger: Anne Thomas Manes

Following up on Kirk's post last week on Sun's Project Jigsaw...

The situation is actually more troubling than it appears, and it reaches beyond the question of modularity. Jigsaw is Sun's effort to incorporate a module system (JSR 294) into Java SE. After years of haggling with the OSGi Alliance, it appears that JSR 294 will support interoperability with the established and widely-supported OSGi framework (JSR 291), although it still seems pointless to me to develop two different module systems. (Note that JSR 291 is an approved spec, and JSR 294 is not.) See the OSGi blog for a bit more history on this battle.

The really troubling bit is that Sun is hard at work developing OpenJDK 7, and it is incorporating non-approved specifications like JSR 294 into it, but it has not yet submitted a JSR for Java SE 7. I guess that Sun now believes that supplying a single open source implementation of the Java SE 7 platform is good enough, and that defining a standard specification that enables other vendors to develop their own implementations is no longer necessary.

This maneuver establishes OpenJDK 7 as what Burton Group refers to as a "Rebel" framework. It's comparable to other popular open source frameworks such as Struts and Spring.In this case a very popular framework -- but non-standard, and available from only one source.

What are the implications for Java going forward if Sun decides to abandon its standardization system, the JCP? What's to become of Oracle JRockit? And IBM's implementations of Java on z/OS and other operating systems? Sun will not build ports of OpenJDK 7 for all possible platforms. Should the other vendors simply abandon their implementations in favor of Sun's implementation?

Based on the JCP Executive Committee meeting minutes, it appears that Sun is breaking away from the JCP because it doesn't want to concede to Apache's demand (which is echoed by the rest of the JCP members) for an unencumbered license to the JDK TCK. See Stephen Colebourne's blog for a summary of this battle.

All-in-all, an acquisition of Sun by IBM is sounding better and better all the time. Let's hope the deal proceeds.

Sun, JCP, & Jigsaw

Blogger: Kirk Knoernschild

Recently, Sun announced Project Jigsaw, an effort to modularize JDK 7, within the OpenJDK community. Neil Bartlett posted an interesting perspective on Jigsaw, and noted that:

"Jigsaw will be fully supported by Sun, although it is not an official Java standard backed by a JSR"

This is certainly a troubling approach taken by Sun. Without question, the tangled history of OSGi and JSR 294 has been interesting. But the industry has already decided that OSGi is the de facto standard for modularity on the Java platform, with most vendors baking OSGi into their products. And OSGi is supported by an official JSR 291.

While Jigsaw is not part of Java SE 7 (yet), Sun must tread carefully. By lending full support to Project Jigsaw, they are giving indication of their willingness to bypass the JCP when they deem necessary.  This move stands to undermine the JCP entirely, and serves notice that if Sun decides to move in a different direction, they reserve that right.

IBM to Acquire Sun?

Blogger: Anne Thomas Manes

By now, no doubt, you've heard the rumor that IBM is contemplating a Sun acquisition. My colleagues that cover data center strategies have written about the implications of such a move on the server market. Here, I'll talk about the implications on Java.

Although IBM has been investing in other languages (especially PHP in WebSphere sMash), Java still remains at the center of the WebSphere universe. I have no doubt that IBM would love to take responsibility for the Java platforms. 

And I suspect the rest of the Java community wouldn't mind it, either. Sun has been a proprietary proprieter of the Java platform. The Java Community Process (JCP) is supposed to be an open governance body, but Sun maintains special rights to the process. After many years, Sun finally released an open source implementation of Java SE 6, but at the same time imposed IP rights restrictions in the license for the Java SE Test Compatibility Kits (TCKs) that limit the way someone might use other open source implementations (e.g., Apache Harmony).

If past experience can be used as a forward indicator, IBM would be a more open proprietor of the Java platform. When IBM created Eclipse.org, it relinquished full control to the Eclipse Foundation. IBM now has no more influence on Eclipse than any other Foundation member. If IBM does acquire Sun, let's hope they adopt a similar open model for Java.

What you talkin' 'bout Willis?

Blogger: JP Morgenthal

Having worked years in the software industry, I'm hesitant to attack software company executives' comments because there's usually some meat behind their statements.  But, I was reading the following article by Stephen Shankland at CNET, "With JavaFX, Sun seeks new coders, new revenue." and all I could think is the pressure is getting to Jonathan Schwartz of Sun.  I kept reading waiting for the punchline or at least a glimpse of how far gone he is, such as "we expect Skynet to be our biggest customer", but no such luck.

Here's some of the really questionable quotes:

• But Chief Executive Jonathan Schwartz, despite Sun's dropping revenue, low stock price, and large new layoff, believes that JavaFX will overcome its obstacles.

Perhaps, but this would top Microsoft Excel overtaking Lotus 123 as the greatest comeback in software history.  While I understand the reasoning behind JavaFX Script, it has nothing to do with Java, doesn't leverage Sun's existing base of developers on the Java platform and is proprietary when they could have used an established dynamic programming language.  At least I can code C# in Silverlight.

• "We're more relevant today than any other software developer on the face of the Earth."

I'll leave this one as an exercise to the reader to analyze.

• "The problem with browsers, when viewed as the default mechanism for delivering content for the Web, is that browsers have become hostile territory," Schwartz argued. "Internet Explorer is owned by Microsoft. Firefox is owned by Google, at this point. Chrome is owned by Google. Beyond that, with maybe (the exception) of Safari, which is owned by Apple, there is no safe route to distribute your content into the marketplace."

Granted, there's still issues with CSS support, but compatibility across browsers continues to get better because developers are demanding it and because Firefox and Webkit are focused on superb industry-standard implementations that many users point to as reference implementations.  Moreover, the minor nuances are not getting in the way of building rich application interfaces.

And, yes, Google has made a large contribution to the Mozilla Foundation, but it doesn't own the extremely large base of developers that have contributed to Firefox or it's ecosystem.  Mozilla's Chief also maintains a strong stance that Google does not influence Mozilla's direction in a proprietary direction and will seek alternate financing if that ever became the case.  Regardless, there's no basis to represent the Mozilla community as being 'owned' by Google.

In the race for the one stop shop for rich user experience, across mobile and desktop platforms, in my opinion, JavaFX is the horse in last place, with one of it's shoes falling off and an overweight jockey.

Websphere 7 & OSGi

Blogger: Kirk Knoernschild

I recently spoke to Tim Francis, IBM Distinguished Engineer, and Walt Noffsinger, product manager for Websphere Application Server (WAS), about WAS 7, which was released in October. WAS 7 has a few significant new features, and Walt pointed out that enterprise customers are especially excited about three of them - flexible management options, business level applications, and runtime provisioning based on OSGi.

While the first two are rightfully cool, it's the latter where I want to focus. Few are aware that WAS 6.1 was redesigned and packaged as OSGi bundles. But the capabilities of the OSGi Service Platform were not exposed to the enterprise developer. And in fact, WAS 6.1 didn't take advantage of the dynamic capabilities of OSGi. Instead it was just laying the foundation for what was to come in WAS 7.

WAS 7 improves upon the 6.1 implementation in a key way. Whereas WAS 6.1 was packaged as OSGi bundles, WAS 7 leverages this capability through dynamic provisioning of only the capabilities that are needed. So if an EJB container isn't needed, the EJB Container bundle isn't started. This reduces startup time for applications and also reduces their memory footprint. While those are real advantages, that's where the advantages of OSGi stop in WAS 7.

Tim mentioned that the WAS team has always taken backward compatibility very seriously, and that's evident with WAS 7 still supporting J2EE 1.2. And to ensure that compatibility, more complete bundle lifecycle capabilities will have to wait on the OSGi Enterprise Expert Group, of which IBM is a participant. That includes exposing the benefits of OSGi to the enterprise developer, who are still left dealing with the Java EE deployment model along with any proprietary goodies offered by the container. The dream of a dynamically adaptable application platform, and developers realizing the advantages of OSGi, are starting to arrive. Hopefully, there will be more to come.

OSGi: A New Cake for the Data Centre

Speaking at Burton Group's Catalyst Conference in Prague, Drue Reeves, VP and research director for Data Centre Strategies says:

Data centres must be more dynamic, especially in today's rapidly changing markets and economies, but organizations can only change as fast as their infrastructure allows.

According to Drue, the Dynamic Data Centre is all about having an agile, fluid IT infrastructure that can automatically change to meet business demands.

What’s on servers in data centres? It turns out that application servers take up a decent percentage of the server estate. At the financial services firm I worked for nearly 50% of servers in the data centres were dedicated to running application servers and this figure is fairly typical.Drue asked me how OSGi fits into the picture of improving operational agility, so I’m going to start answering that by looking at how we deliver the Java applications hosted on those servers.

Enterprise Java program design has matured to an art form. We create loosely-coupled components and carefully layer them on top of each other. Then, we do the artless bit: the packaging. We stuff all the components and all their dependencies into one monolithic archive file for deployment into an application server.Kirk Knoernschild describes the problems with packaging and deploying Java applications this way in his “OSGi in the Enterprise” overview:

Small changes, even if isolated to specific areas of an application, require packaging and redeploying the entire application and often a restart of the JVM instance hosting the application. Transitive dependencies among JAR files when adopting new frameworks are difficult to manage. Homegrown frameworks must be deployed with each application that uses them. Dealing with the problems of multiple class paths is a burden when troubleshooting runtime errors. Fighting through the problems encountered when different JAR files contain the same fully qualified class is painful. The amalgamation of each of these issues, combined with many others that tend to surface, reveals a packaging and deployment model that is broken.

That sounds bad. And it is bad. It’s certainly a maintenance and operations nightmare. And it’s not going to give us the agility we need to move and change those applications dynamically around the data centre. It’s like designing and creating an incredibly elaborate layer cake, then throwing all of it into a big sack. If we want to replace any of it, we have to take it all out, add a different kind of chocolate and build it all again.

OSGi gives us a way to package and deploy each of the layers and tastes separately, more like a bento box than a squashed cake. If you don’t like chocolate mousse, fine. Swap it for a lemon tart. It doesn’t affect the taste of the rest. If the crème brûlée has turned, you don’t need to return the whole box for a new brûlée If the chef demands you eat the tiramisu with the apple sorbet, that’s easy. If we’re sharing the desert and we both want vanilla ice cream, but you want the Madagascar variety, that’s okay, we can have our own versions.

Sure, so OSGi give us a better way of packaging and deploying Java applications. So what?

Well look behind this and it is actually a big deal. OSGi solves some of the thorniest Java deployment and operations problems, namely:

• Eliminates application dependency problems No more guesswork. No more tracking down classloader problems in production. OSGi requires explicit declaration of dependencies between modules.

• Minimizes footprint. Application servers and their hosted services can be “right-sized” by allowing administrators to build the minimal Java application platform. Only the bundles with the explicitly required capabilities will be installed. The platform will dynamically adapt by loading capabilities on demand.
• Solves versioning problems- multiple versions of the same software module can be deployed within the same JVM instance.
• Enables hot deployment - modules can be deployed and updated within a running system without restarting the application or the JVM.

Solving these problems breaks down barriers to Java application mobility and supports changing the workload dynamically as demanded by Drue.

Platform vendors are all busy rebuilding their application servers based on OSGi. There are 2 flavours of OSGi fit out you can see them doing: retrofit and ground-up. You can roughly interpret that as “OSGi for me” and “OSGi for everyone”. SpringSource’s Adrian Coyler characterises the “OSGi for me” vendors as saying:

I happened to use it internally but there's no real way you could tell; it's just my private way of partitioning out my internals

The ground up, “OSGi for everyone” platforms, of which SpringSource dm Server and Paremus’ Infiniflow are good examples are not only building an “a la carte application server”, but exposing the full capabilities of OSGi to enterprise applications.

Is OSGi ready for the enterprise and perhaps more importantly is the enterprise ready for OSGi? Kirk Knoernschild answers these key questions in his “OSGi in the Enterprise” and in recent blog posts: here and here. Certainly the enterprise data centre is ready for technologies that enable fluid and adaptable configuration of workloads.

Spring-ing past Java EE?

Blogger: Joe Niski

SpringSource has been busy this month, just as I put the finishing touches on Burton Group's first in-depth look at the flexible Spring Framework (It's a lightweight container! It's a data access tool! It's a web framework! It may not wash your car, but you could extend it . . .)

For many developers tired of the grunt work involved in Java EE programming, Spring has made life easier for over four years. Today's announcement of the SpringSource Application Platform just might free developers from ever touching a Java EE server or deployment descriptor ever again. (Well, maybe eventually . . .)

Built on the Apache Tomcat servlet container, the innovative and proven OSGi service framework, and Spring, SpringSource Application Platform offers functionality comparable to a Java EE server but with a more modular service infrastructure and a more developer-friendly programming model than Java EE. It has tremendous potential to live up to its “next-generation application platform” label.

The combination of SpringSource Application Platform and the Spring Enterprise Edition bundle of support, software, and tooling constitutes a full stack for enterprise software development, deployment, and management. It may seriously disrupt the server market currently dominated by IBM, BEA, Oracle, and RedHat in the next two to four years.

Annotations: Are they a step forward or backward?

Blogger: Anne Thomas Manes

Paul Fremantle wrote recently about the new JSR181 annotation support added to the Apache Axis2 project. JSR181 allows you to add annotations to a Java class or interface, such as "@WebService" and "@WebMethod" to automatically convert the class into a web service and a method into a web service interface (portType). You can use these annotations in place of writing a services.xml configuration file or running utilities like java2wsdl and wsdl2java to generate the WSDL and services.xml configuration files.

For people that prefer the code-first development approach, annotations look like a wonderful feature. Just write your code, add a couple of annotations, compile, and presto -- you have a web service. What more could you ask for? Dennis Sosnoski wrote an excellent article explaining some of the advantages of the code-first approach. When used with build tools, such as Ant and Maven, the code-first approach also enables a lot of highly productive automation.

At some point I'm going to write a full-length rebuttal to Dennis's article explaining why I think code-first development is such a bad thing. His approach of adding a layer of abstraction by using a separate data binding framework (JiBX, in this case) to generate the WSDL and schema is a step in the right direction, but I still have a fundamental problem with generating schemas from code because it results in a proliferation of incompatible schema types -- increasing redundancy and complexity. Schema types should be the first-order sharable entities within a SOA initiative.

Annotation-driven development assumes code-driven development, and given my opinions about generating schemas from code, you can imagine that I'm not going to be a fan of annotations.   But I have more fundamental concerns about annotation-driven development. For one thing, in order to compile a class containing annotations, you have to include a proprietary JAR in your classpath that is responsible for compiling the annotations. Paul touches on this point in his blog post:

[I could write a whole blog post about whether Java with annotations are really POJOs! After all, to compile a normal Axis2 POJO service I don't need anything Axis2-related in my classpath - I fix all that up later with XML descriptors. In this case, although the annotations are standard, I still need to have WebService specific JARs in my classpath to compile these "POJOs".]

Paul also goes on to explain about all the cool stuff you can configure using annotations. Basically, anything that you could configure in the services.xml file could also be configured using parameters in an annotation. But, of course, that means your annotations are no longer simple. And, they rapidly become proprietary -- because every framework supports a unique set of annotation parameters. Once you add annotations to a class, it's no longer a POJO.

I'm also really concerned about embedding infrastructure-related functionality into the application's source code.  I'd much rather keep all that infrastructure-related stuff in a configuration file that can be edited without going back to the source code. Today you may want to expose the service using SOAP and WSDL -- but at some point down the road, wouldn't you also like to expose it using a RESTful HTTP interface or whatever the next latest and greatest middleware technology might be? Do you really want to go back to the source code to update an annotation?

Keeping infrastructure-related information in a configuration file is a good thing. Admittedly, configuration files have become a lot more complicated than the average developer would like. And no one really prefers to write in XML. But I don't think this move to annotations is any better. All we're doing is shifting the complexity, and in the process, we're reducing the flexibility of our code. I really think annotations are a step backward.

Comparing Web Frameworks

Blogger: Richard Monson-Haefel

Link: Raible Designs | Comparing Web Frameworks: Time for a Change?.

Matt Raible is considering updating his evaluation of Java web frameworks - personally I can't wait to read the results of his research.  I wish he was including Spring MVC if only because its so popular, but I understand the need to limit the number of frameworks evaluated.  Matt does excellent analysis and I've depended on his expertise in the past. Keep an eye out for his update because it will be well worth the read.

The APS team has frequently spoken about doing a more comprehensive web framework evaluation our selves - perhaps one that utilizes the new "subthread" format.  A subthread document is actually composed of several documents including a Technologies and Standards, a Market Landscape, and at least three Product Profiles. They take an enormous amount of effort to write but the resulting coverage is very deep and the format is very flexible.  For example, next quarter I'll complete a subthread on Rich Mobile Application development for the enterprise. That document includes a 27 page technology and standards document, five product profiles (Java ME, Flash Lite, Mobile Ajax, Microsoft .NET CF, and BlackBerry MDS) ranging from 10 - 25 pages each, and a market landscape which will probably be another 20 - 30 pages long. I've spent almost the entire year working on it.

The amount of time and research required to write a subthread makes us careful about taking them on - I could do a whole subthread on web frameworks but that would put me out of action of at least a couple of quarters. I could also so a subthread on Rich Internet Applications or build on the Rich Mobile Application subthread I'm just now completing.  In the end we have to let the needs of our customer drive our research so the decision is ultimately up to them. What would you prefer?