Steve Loughran makes a declaration :Autogenerating a SOAP service from implementation classes is dangerously brittle against accidental change, and misses out on the flexiblity opportunities of XML
Sort of agree, but got me thinking. I think one of the major reasons why CORBA failed to take off was the lack of tool support… it was too da’n difficult to build and test (There are other reasons, but thats probably the subject of another rant). Imagine if Visual Studio had a CORBA wizard instead of an ATL wizard. The fact that one can now wrap existing classes in almost any language, from Java or C# to Ruby as a Web Service without much effort is probably the biggest indicator that Web Services use will be widespread. So I was wondering, does the roots of WS’s success contain the seeds of its own disctruction?
I sure hope not. And thats because I don’t think this is really a object vs xml issue. Its much more a object vs service design question. When people start designing for SOA, I believe much of this will be moot. Will people mess up on the way? You bet. Will some architects continue to design traditional objects? Sure. But once most architects “get” SOA, thats when you start thinking differently, and thats when it doesnt really matter if your WSDL is compiled into a class with methods. I am pretty sure that over the next few years, different ways of implementing the WSDL contract will be developed. We can surely access the power of the XML-Schema without having to manually parse and create XML documents. In spite of that, Web Services will be worthwhile only if one starts to design for services, as opposed to objects. That’s a shift that has to be made.
GCJ has always been an interesting project to watch, but only recently have I felt emboldened enough to try out some (precompiled) apps, thanks to the folks at RedHat. I used the precompiled versions of tomcat and ant on some of our smaller projects, on a RH9 desktop. Herewith, some experiences.
In spite of knowing better, I harboured delusions about native vs bytecode compilation. So the first thing I did was to time gcj-ant against java-ant on a small webapp as well as a small swing project and found no measurable difference between the two. gcj-ant however managed to compile both projects correctly, but I suppose that is not saying much. Though I must admit I have been using gcj compiled Eclipse on a RHEL box, and that seems to start up much faster. (But its Eclipse 2, so again, not much use!)
Tomcat was more interesting. I was pleseantly surprised to find everything runs well, at a resonable speed. Startup is however much slower than using Java.
The first thing to watch out for is that the rpm is packaged in accordance with FHS (or is it LSB these days). So it has startup files in /etc/init.d/ and server.xml resides in /etc/tomcat/, and logs go to /var/logs/tomcat/. The process runs as user tomcat and all files are owned by root or tomcat. All very nice and secure, but a pain to develop on. You end up spending a lot of time typing chmod -r 777 in frustration, to get you application to write its log, to read the logs, or when you want to clean your jsp working directory.
Its fun to see stack traces starting from __libc_start_main and going through org.apache.catalina.core.StandardContext.start() (/usr/lib/lib-org-apache-catalina-4.1.27.so) . But there hides the deal breaker. The GCJ runtime shows Unknown Source in the stack trace, while the Sun JVM shows me the line number in the source code for the exact same bytecode. And that is why its a no-go for a developer.
So right now, I see no particular reason to use gcj in anger. The speed is similar, stability is similar, and trouble shooting ability is significantly lower. Since most of our work is server side, this solves no problem that we have. There may be a more compelling argument for desktop apps, where this seems very cool.
Another bottleneck is that its still too difficult to compile large applications myself. The RedHat compilations are done using some bleeding edge code from GCC HEAD. Most online HOWTO’s seem to require five unofficial patches to GCC to do stuff. Scary stuff!
Next stop: IKVM . I think IKVM has a more compelling use case — java/.net interop. This may be how things will come to pass, if mono catches on.