Java's Centre of Gravity Has Shifted

I was amused to read this slant on the rumours of IBM's takeover of Sun.

No, it wasn't industry analysts who were being asked their views on the merger. It was Rod Johnson, original developer of the Spring framework and CEO of SpringSource.

SpringSource isn't an IBM or an Oracle in size. Outside of the most tech-savvy segment of the Java development community, SpringSource and Rod Johnson are virtual unknowns. Yet the press was beating a path to this man's door. That in itself was somewhat surprising. Even more surprising was that Rod's reaction to what should have been major industry news was rather ho-hum. His reasoning was that in recent times, Java middleware has been influenced more by Open Source and independent developers than by large corporations, so it really doesn't matter either way if the merger goes ahead or not.

I tend to agree, with one caveat. The roadmap for an Open Source Java is still murky, and I'd like this to be clarified before I'm willing to yawn at the irrelevant plans of corporate titans. There are those like Stephen Colebourne who have almost a conspiracy theory about Sun's plans for Java. While I hope they're wrong, I too would like to see an open Java 7 specification that can be implemented by anyone and be certified as such.

If I can't have an open Java specification, I'm willing to settle for at least one safely Open Source (i.e., GPL-ed) implementation of Java, but I'm disappointed even there. Java is still not 100% Open Source. It still suffers from "encumbered code". There are a few libraries that have not been released under the GPL, and that is a lingering source of worry.

But in the main, Rod Johnson is right. A few years ago, JBoss began to shift the centre of gravity of Java away from the Weblogics of the J2EE world towards a more lightweight, Open Source implementation of J2EE. Today, that wrenching movement has continued with the marginalisation of J2EE itself.

I believe that Spring and Tomcat are ringing the death knell for heavyweight Java. If Java becomes a 100% open platform with a completely open specification and at least one completely GPL-ed implementation, then it won't matter which industry heavyweight buys which. It will be a mating of dinosaurs in the age of mammals.

Sun Tech Days Sydney - Day 3 (Community Day, 6 March 2008)

(I've already blogged about the first and second days.) There were 5 tracks on this (third) day, called "Community Day": GlassFish, NetBeans, Mobility, Solaris and Sun University. I attended 3 sessions each from the GlassFish and Mobility tracks.

Alexis Moussine-Pouchkine provided an introduction to the GlassFish project. GlassFish is almost exactly the same product as the Sun Java Application Server. The latter has a couple of extra proprietary bits added, and also provides more frequent updates.

A few tidbits that I noted:

The admin console looks pretty professional, unlike Tomcat's minimal one, and unlike the ugly raw JMX that I've seen in the past with JBoss (I haven't used JBoss in a while, thanks to Spring and Tomcat). GlassFish's admin console is even better than Geronimo's, which I thought was pretty good at the time. It's task-oriented, so users will find it easier to find what they need.

GlassFish logs to a bundled JavaDB database (Cloudscape/Derby).

Apparently, GlassFish has a third container apart from the web and EJB containers. It's called the ACC (Application Client Container). Developers can build a Swing client and bundle it with the ear file. Java Web Start is used to deliver it. Dependency Injection can be used even with the client.

In cluster mode, GlassFish keeps Applications, Configurations and Resources consistent across the cluster. GlassFish uses a dynamic clustering feature called Shoal that is built on top of JXTA.

There's a project called SailFin which is meant to bridge HTTP and SIP. This is useful not only for the telecom industry but also generally, to provide rich media capabilities to enterprise apps.

I haven't explored Sun's Portal offering before (OpenPortal). That's another thing on my growing to-do list.

GlassFish has a number of components:

The GlassFish App Server itself
OpenPortal (portal server)
OpenESB (Enterprise Service Bus, of which more later)
OpenSSO (single sign-on solution)
OpenDS (directory server)
Jersey (for RESTful services)
Hudson (continuous build)
jMaki (aggregates Ajax widgets and provides a common API wrapper)
jRubyOnRails
OpenMQ (message queue)
WoodStock (JavaServer Faces components)
JavaDB (Apache Derby pure Java database)
Apache Roller (blog software, one of the "Enterprise 2.0" offerings)
Slynkr (social tagging software, another of the "Enterprise 2.0" offerings)
SailFin (SIP-HTTP bridging software)

Here's the GlassFish project wiki that provides ongoing detail about the project.

David Pulkrabek from Sun's labs in Prague spoke about the future of JavaME development tools, and his demos were very impressive.

He showed a demo of how to record and replay a set of actions, that could be used in automated testing. Then he showed a demo of how a Sun SPOT device could be used to capture sensory inputs like orientation and 3-dimensional acceleration to control a game on a mobile device. Could this power the next Wii?

Next he showed how real devices and emulators are treated the same by toolkits. A mobile phone plugged into the laptop with a USB cable is detected by the tools, and the debugger can execute applications on the mobile phone, with breakpoints and variable editing, just as in a local emulator. The output of the mobile phone can be redirected back into the toolkit's console.

Very impressive. I think JavaME developers have a pretty good set of tools at their disposal, thanks to the work done at Sun's Prague labs.

But even JavaME pales into insignificance when compared to JavaFX Mobile. This session was from Noel Poore. JavaFX Mobile is a rather unfortunately named piece of technology, and will continue to cause Sun grief because of the needless confusion with JavaFX Script. Let me clarify. JavaFX Mobile is the name of a mobile device platform that Sun acquired when it took over SavaJe in May 2007. JavaFX Script is a new (as yet unreleased) scripting language for the UI, which essentially reduces Swing programming to a declarative style. Yes, JavaFX Mobile supports JavaFX Script, but that's the only (tenuous) connection. Sun should stop these silly and confusing names (The Java Desktop System was another one. That was just a Linux (or Solaris) desktop that could run Java).

JavaFX Mobile is based on the Linux kernel and Java SE. Note that it's Java Standard Edition, not JavaME, the Mobile Edition that the previous session dealt with. This has two major implications. One is that the full range of Java features is now available to mobile devices, not just the subset that JavaME used to provide. Second, from a market viewpoint, it removes the fragmentation that the various JavaME implementations necessarily suffered on account of their having to be tailored to devices. JavaFX Mobile is now a full-fledged platform that can take on the iPhone or Google's Android. It can still run MIDP Midlets, but Sun would encourage developers to build full-featured JavaFX Script-based UIs and applets rather than the comparatively anaemic Midlets, now that the full capabilities of a JavaSE platform are available.

The platform has three components: Core, Frameworks and User Experience (Applications).

Core: Kernel abstraction, Linux kernel 2.6, Core graphics, Core networking, Media engine, Device drivers, Filesystems and a C library (not glibc)

Frameworks: Content management, Java, Web content, Provisioning, Graphics, Connectivity, Multimedia, Networking, Messaging, Telephony

User Experience (Applications): Calendar, Browser, Phone, Camera, App Selector, Personal Utilities, Media Player, Content Viewer, System Utilities, Contacts, Messaging Apps, Home Screen, Themes and third party apps

Messaging includes IM and Presence (OMA IMPS and Jabber).

Jim Weaver (who has written many books on Java, including J2EE 1.4 and JEE 5) spoke next about JavaFX Script and showed a few demos. I'll just sum up my impressions on JavaFX Script.

First, JavaFX Script is to Swing as Groovy is to Java. It's a lightweight scripting approach to building GUIs, and it uses a declarative style.

Second, although JavaFX script is far less verbose than the equivalent Swing code, it still unfortunately looks like the dog's breakfast (compared to Flex, for example). I think it will only become popular when a graphical editor is layered on top of it.

I always like systems that are based on textual files that can be edited by hand if required, compared to systems that store data in binary format. But that doesn't mean I want to use the text editing approach exclusively. "Build graphically and tweak textually" is my motto for GUI development.

Michael Czapski from Sun's Sydney office spoke about JBI (Java Business Integration) and OpenESB.

Historically, approaches to integration have ranged from file transfer through shared databases and EAI to messaging. Messaging is the model currently in vogue. Models have progressed from point-to-point, through hub-and-spokes (brokered) to the "bus", which is a distributed, logically decoupled, anywhere-to-anywhere model.

ESB's facilitate a messaging-based bus model of integration.

JSR 208 deals with Java Business Integration, another unfortunately-named standard that doesn't immediately explain what it does.

This is a standard that governs how ESB components plug into the bus, allowing integrators to mix and match components from different sources to build up a "bus". I think it's more relevant to those who write components like adapters, BPEL engines, XSL transformation engines and the like rather than end-user organisations (like mine) that want to use a bus to integrate their applications. The latter don't care how the "bus" was put together, whether it is a monolithic piece of technology or a pluggable architecture that has components from different sources. [Well, we should care from a vendor lock-in perspective, but functionally, it makes no difference to us.]

JBI standardises component interfaces, component lifecycle (start, stop, deploy, undeploy, etc.), deployment model, monitoring and management, among other things.

It fosters loose coupling through WSDL interfaces, and implements WSDL 2.0 MEPs (Message Exchange Patterns).

The components that plug into a bus are either Service Engines or Binding Components. Examples of Service Engines are Aspect engines, BPEL engines, mashup processors, encoding, ETL, scripting, XSL transformation engines, etc. Examples of Binding Components are BCs for SAP, Siebel, CICS, CORBA, FTP, HTTP, Queues, etc.

OpenESB is Sun's JBI implementation. It uses NetBeans 6 for development and deploys naturally to GlassFish.

Michael demonstated a BPEL process that used two Binding Components (an input queue and an output file), with a Service Engine written on the spot using an EJB with Web Service annotations. The process read in a string from a queue (which was manually input), called the web service to turn it to uppercase, then wrote it into the file. Sure enough, when the file was opened, the string was there, in uppercase. Though it was a simple enough demo, it was fairly impressive.

NetBeans 6.0 is shaping up to be a good development platform for SOA. It has editors for BPEL and XSLT, among other things.

The last session I attended was by Alexis Moussine-Pouchkine again. This was on "Practical GlassFish". He talked about how GlassFish is built, the release cycles, etc.

There's reportedly a graphical installer from a third party (Izpack) for those who don't want to wrestle with the command line.

Alexis also demonstrated the Update Center, which works like Eclipse's.

He showed us some of the asadmin commands for command-line administration. These can obviously be used in scripts as well, which administrators would like.

From a competitive perspective, Sun has a migration tool that helps users automatically (to a large extent) migrate their current deployments on Tomcat, JBoss, WebLogic, WebSphere and older versions of Sun App Server onto GlassFish/Sun App Server. It's reportedly not foolproof, but it could help.

Documentation can be obtained by typing 'asadmin --help' on the command line or online.

That was the end of the three-day Sun Tech Days event. Very useful and informative.

My main takeaway, ironically, was nothing from Sun. It was Grails. I've started doing the InfoQ tutorial, and I'm mightily impressed. I'll blog more about Grails as I learn more.

Sun Tech Days Sydney - Day 2 (5 March 2008)

I blogged about the first day here. A lot more happened today, or so it appeared to me. I saw the most jaw-dropping piece of technology demonstrated today, but you'll have to wait a bit to hear more about it.

Sang Shin spoke about AJAX and Web 2.0 technologies. Sang has a wonderful blog at http://www.javapassion.com. This site is chock full of detailed courses on major Java technologies, all generously made available free of charge. His presentation today was based on some of those courses. It was hard for him to do justice to the depth of the topic in just one hour, but I'm sure his blog and the courses there will provide hours of useful instruction to anyone interested in exploring them in detail.

One of the useful tips I picked up while watching his demo was how to use the Firefox extension Firebug. This lets you monitor AJAX traffic, among other things.

The next session I attended was by a person from Atlassian. This session was on Grails. Now, I'd heard of Grails, but didn't quite know what it was all about. I assumed it was a very different technology from Java, something like Ruby on Rails. Only half right, as it turned out. Yes, the technology was inspired by Ruby on Rails, but it's based on Java technology. To be precise, it's a software stack consisting of Java, Groovy, Spring, Hibernate and HSQLDB.

It's a little hard to describe what Grails is. Those who attended Ben Alex's talk early last year on the coming Spring project tentatively called ROO (Real Object Oriented) will have a fair idea of what I'm talking about. Grails seems to have everything that ROO promised (but hasn't yet delivered on). It's a toolset that lets designers build applications based on the principles of Eric Evans's Domain-Driven Design, and it works very hard behind the scenes to build all the infrastructure required to make the domain objects just work. Persistence, a RESTful web interface, test cases, - all get automatically generated. An increasingly common theme that I'm hearing pervades Grails - "Convention over configuration." In other words, if you stick to standard naming conventions for things that you create, the system will make it very easy for you to build a working application with a minimum of coding.

That's the jaw-dropping technology I talked about at the beginning of this post. Grails is a developer's dream. One can knock together working code in minutes. InfoQ has a Grails guide and example code which I intend to work through as soon as I possibly can. I would recommend Grails to all Java developers looking for the next burst of productivity. Best of all, Grails applications can be exported into standard war files and run on standard app servers, so there is no need for any new run-time technology.

Funny how one can be searching for months for a productive development environment that lets you build applications rapidly yet correctly, and then one fine day, it comes up and hits you between the eyes. Praise the Lord! I intend to use Grails to illustrate concepts with working code from now on. I'll blog about my experiences with Grails as I get some experience with it.

(I also liked Atlassian's byline: "Where VB is only in the fridge.")

Lee Chuk-Munn presented next on JavaDB. This is, of course, the much-renamed Cloudscape/Derby pure-Java database that takes up all of 2 MB of space and supports database sizes of up to 700 GB. It is thread-safe and therefore OK for multi-user use, but is positioned as best for use as an embedded database. Since new owner Sun has to juggle other databases like MySQL and PostgreSQL as well, I suspect that the recommendation to use JavaDB for single-user or embedded use has more to do with positioning than with the actual limitations of JavaDB. Too many capable technologies (Linux, MySQL and Tomcat, anyone?) have been unfairly treated as toys in the past for me to swallow such a recommendation.

JavaDB has stored procedures, triggers, functions, built-in XA (distributed transactions), encrypted databases, crash recovery, etc. It also supports JDBC 4.0, with autoloaded drivers, scrollable and updatable ResultSets, better support for CLOB, BLOB, ARRAY and STRUCT, chained exception handling and XML datatype support. The only enterprisey thing JavaDB lacks at the moment is replication, but a basic version is said to be coming in version 10.4.

A very neat feature of JavaDB is the ability to place an entire database inside a jar file on a USB stick for use as a read-only database.

Another neat feature is the ability to define stored procedures in Java rather than a dialect of SQL. The actual command to create the database procedure merely references the Java static method.

Lee showed us examples of how JavaScript and Java may enjoy bidirectional communication using the long-presumed-dead applet technology. He also showed us Java/JavaScript code to demonstrate client-side persistence using embedded JavaDB.

JavaDB is pretty cool, when you stop to think about it. Relational database technology has been a big yawn for a few years now, but things like this make me sit up and take notice.

Carol McDonald spoke about JSF, AJAX, Woodstock, etc. I'm not terribly interested in JSF and would much rather it simply died. I'm not a big fan of web frameworks because I think all thin-client architectures follow a common design anti-pattern. My money is on SOFEA. Still, JSF is something that refuses to go away. Among the goals for the next version of JSF (2.0) is the now-common refrain "Convention over configuration".

After that were two sessions on security. They covered the usual ground, with nothing very spectacular that caught my attention.

A few tidbits from Raghavan "Rags" Srinivasan's session:
1. C14N stands for "canonicalization", the process of rendering XML documents into a common format (i.e., especially differing use of whitespace, which could otherwise play havoc with cryptographic techniques to detect tampering).
2. SAML can be used to make 3 kinds of assertions:
a) Authentication assertions ("This person (or program) is so-and-so.")
b) Attribute assertions ("This entity has the following properties.")
c) Authorisation assertion ("This principal may read data but not update it.")

OpenSSO is Sun's identity management solution. You may download and try it.

There was another talk on SOA security from a person from a company called Layer7. This was more high-level with no code.

The contents of all lectures will be put up on the Sun Java Tech Days website anyday now.

There was an OpenSolaris Installfest going on in the registration/catering hall, and they were giving out CDs and guidebooks. I'm definitely going to try and install OpenSolaris and report on the experience.

Today marks the end of the official Sun Tech Days conference, but tomorrow is a set of community events, which also I plan to attend.

I've been invited to drop by the GlassFish booth tomorrow to discuss my difficulties with the server.

Sun Tech Days Sydney - Day 1 (4 March 2008)

Today I attended the first day of Sun Tech Days in Sydney, and here are a few of my impressions.

Some major takeaways for me:

1. The Java and Open Source ecosystem has expanded so much in the last decade that Sun can no longer organise a conference to talk about just its own technology. This year, for example, topics included Ruby, JRuby, Rails, the Spring framework, JBoss Seam, MySQL and PostgreSQL, Grails, AJAX, REST, etc.

2. Sun is now irrevocably committed to Open Source. Open Source has become too powerful a force for any company to withstand. It gave me deliciously wicked pleasure to see James Gosling, the "father of Java" and a traditional Open Source skeptic, take the floor and defend Sun's pro-Open Source direction. I know from reading past interviews of Gosling's that he is no admirer of Richard Stallman or the GNU GPL. It must have hurt for him to see his brainchild released under the GPL! ;-D

3. There seems to be some competition hotting up between three players in the Java/Open Source world - SpringSource, Red Hat/JBoss and Sun. I got the feeling Sun was actually aligning with their old enemy Red Hat, because they seem to view SpringSource as their common enemy. SpringSource have taken over Covalent, the Apache services company, so there's a perception that they're pushing Tomcat over all other app servers, GlassFish included. That seems to irk Sun. Later, watching the JBoss Seam demo and learning that it is going to form the basis of a new JavaEE technology called Web Beans, I got the distinct impression that JBoss is proposing a rival to the Spring framework. However, both Sun and SpringSource favour Toplink over Hibernate as the persistence engine for their products, perhaps since Hibernate belongs to JBoss. This whole area bears watching in the near future. It has implications for organisations looking to deploy Open Source Java stacks, because sourcing pieces of the stack from mutually antagonistic parties may create integration problems, even if all the components are nominally Open Source.

4. There is a lot of "low-level" knowledge in the industry about how to use tools, but not enough "high-level" knowledge about why things are the way they are or even what is wrong with the way things are. This is as true of the presenters as of the audience (if audience questions at the end of each talk are any indication). Many presentations focused on syntax and mechanics of how to do stuff ("If you use this annotation, the system will automatically take care of such-and-such for you"), but did not provide more insights into architecture and design rationale. Worse, presenters did not do a good job of answering audience questions at an appropriately high conceptual level. [I felt I could have answered some of those questions better. E.g., "If REST makes the client manage its own state, then how do you secure a service against unauthorised access? Anyone can access the service." Answer: "Consider a simple system in which the userid and password have to be sent with each request. That solves the problem you have described. Now consider more sophisticated authentication tokens that can be sent (and checked) with each request." E.g., "Doesn't the service need to authenticate the client by looking up LDAP?" Answer: "A trusted identity provider has already looked up LDAP or a similar store to authenticate the client, and has provided a token to vouch for the client's identity, which the service now trusts."]

Mind you, the above critique takes nothing away from the fact that I learnt a fair bit at this conference.

1. For example, I had never before heard of the wireless device called a Sun SPOT, one of which was demo-ed at the conference. This tiny device fits in the palm of your hand, and has various kinds of sensors (e.g., light sensor, temperature sensor, 3-axis accelerometer, etc.) The devices can detect each other and a gateway wirelessly and the whole system can be used to collect and collate various kinds of real-world data very simply and display it graphically using a JavaFX Rich Internet client. Very cool. One of the Sun managers said the company is selling these below cost to encourage take-up, so if someone is interested in this sort of device, the Sun SPOT may be worth looking at.

2. I hadn't heard of Mercurial before either. This is a revision control system. Sun has changed their preferred revision control system twice, once from CVS to Subversion, and again from Subversion to Mercurial. From the Wikipedia description and its favourable rating in this comparison of revision control systems, Mercurial seems to be pretty good.

3. I was only vaguely aware that JDK 6 bundled a client-side HTTP server. I must try out this example they showed today:

import javax.jws.*;
...
// Define a web service
@WebService
public class SayHello
{
@WebMethod
public String sayHello()
{
return "Hello, World";
}
}
...
import javax.xml.ws.*;
...
// Publish the service using the bundled HTTP server in the JDK.
// This is a "transient" service hosted temporarily by the client workstation.
SayHello sayHello = new SayHello();
Endpoint endpoint = Endpoint.create( sayHello );
endpoint.publish( "http://localhost:8080/hello" );

I made a quick attempt to run this example but it didn't work. I'll need to do more research.

4. NetBeans 6.0 is not bad. It may be worth waiting for 6.1, though, because there's at least one issue with 6.0 that will be fixed in the next release. That's the ability to generate a simple CRUDish web interface to exercise JPA persistence logic, which was apparently working in version 5.5 but has mysteriously stopped working in 6.0.

5. Carol McDonald's two sessions (one on WSIT, JAX-WS and REST and one on Application development using plain JavaEE, Spring and JBoss Seam) were packed with technical content, but alas, I felt she couldn't add much in the way of design rationale or insight. Her blog entries here and here have more details of her presentation and should be of interest to many.

6. Apparently, SOAP's transport-independence is not just theory. Sun's Metro Web Services stack can use any of these transports - HTTP, JMS, SMTP or TCP. The TCP bit is the most interesting, as I don't think SOAP requires a more heavyweight transport. All of the qualities of service required by SOAP messaging are provided by the WS-* headers anyway, so it's best for SOAP to choose the lightest transport protocol that can possibly work. What about IP itself?

7. OpenSolaris makes for a pretty cool desktop. It boasts all the Compiz magic that Linux offers, so Unix in general is now no desktop slouch.

Some of my pet peeves:

1. A statement was made by one of the presenters that DTOs are an anti-pattern, and that detached entities are the way to go. I have railed against detached entities from the time I first heard about them. Mind you, I have nothing against detached entities as long as they stay within the application tier. It's when they are proposed as a means to export data to other tiers that I object. That immediately exposes the domain model to external parties, resulting in tight coupling. Change your domain model and your clients break. [Incidentally, if you consider the web tier to be part of "your" application and not an external party, you are guilty of "web application thinking" and not "SOA thinking". The web tier of your application is an external consumer of your application's services, as much as any external client.] One may hate DTOs and criticise them as an "anaemic domain model", but DTOs were never meant to model anything. They are mere structures that act as an envelope for a bunch of data items that are exported to other tiers. To the extent that they hide the actual domain model from external parties and decouple them, DTOs are your friend. [If you find it a pain to marshal and unmarshal DTOs, you perhaps haven't been using Dozer. Also, if you consider the XML documents within SOAP requests/responses to be DTOs in XML format, then you may similarly benefit from using TopLink's meet-in-the-middle mapping approach or JiBX's mapped data binding to marshal/unmarshal them. You certainly shouldn't be using JAXB to generate one from the other.]

2. Speaking of which, there was a lot of code generation demonstrated today of the sort I simply hate. I have explained before why, if we want to implement SOA, we cannot simply generate service implementations from domain models. I have also tried to mitigate the evils of code generation by proposing a set of explicit "service" classes that act to decouple the domain model from external parties. Annotating these intermediate service classes and automatically generating web services interfaces and WSDL files does no harm, because the required decoupling has already taken place. But as I complained before, this kind of architectural insight did not accompany the demonstrations. They were training technicians out there today.

Nevertheless, on the whole, I thought it was an entirely rewarding day (and the food was great!) I'll be there again tomorrow and will report on my impressions.