When asked about JBoss (Open Source J2EE-based application server) in his August interview with Linux Magazine, Sun Microsystems’ CEO, Scott McNealy claimed in so many words that Open Source is hampering Sun’s ability to effectively market J2EE against Microsoft’s competing .NET standard. [jboss.org]
This strikes me as wrong. In my more cynical moments it reads more like ‘Open Source is hampering Sun’s ability to effectively market their own J2EE server product’. Microsoft are closer to the mark with their ‘software as services’ angle. Although thats still not quite right. Open source software usually has no pricetag – for the software itself. But that’s only a tiny part of the story. As all the software giants are so keen to tell us, TCO is the key. The upfront purchase price of almost any enterprise system is a very small part of the whole cost.
Where its really at is ‘services supporting software’. This is what customers are really after. They want to know that if they have a problem, someone will be on the case to fix it. If your enterprise software is processing a million bucks worth of transactions an hour and it goes down, who cares if it cost 100,000 pounds or 10 pounds? It seems to me that software as a ‘product’ will be increasingly sublimated into software as a service. Support and technical expertise of those offering it will be the differentiators when it comes to choosing one over the other. Lets face it, your CEO probably couldn’t tell you whether your enterprise was running Solaris, Linux or NT, .NET, J2EE or mod_perl. And probably doesn’t care. He has more important things on his mind. And that’s how it should be.
Of course, the technical merit of a product is important, but as software (purchase) prices tend towards zero and interoperability becomes more transparent, choosing a supplier becomes less ‘who’s got the best product on a features/price basis’, but ‘who offers the best service on a quality/cost basis’. If the software is free, try it all. Choose your shortlist, then find out what the service offerings are. Chances are, if its ‘none’ or ‘the dev mailing list’, however comfortable your developers are with this, your Ops, Support and QA teams probably won’t be. The people who are carrying the can, those whose continued employment depends on uptime, they will want guaranteed, knowledgable and rapid support on the end of the phone. The legal team will just want someone to blame. But that’s another story.
2 open source projects that could be worth looking at…
beanutils from Jakarta contains heaps of useful utility methods for working with beans, introspection etc. There’s also something support for DynaBean objects, which are like dynamic beans that can be defined at runtime. They make a neat wrapper around regular java beans too so you can access them in a Map-like manner.
Jexl is cool, its a simple expression language for evaluating expressions on beans. Jexl is a little like the Velocity expression language and is a super set of the JSP Expression Language. So you can use it to navigate bean property trees, accessing maps, arrays, collections, indexed properties and ‘map properties’ (a term coined by the beanutils project for getter methods that take a String argument) as well as methods. So the following are valid Jexl expressions…
[James Strachan’s Radio Weblog]
I looked at the beanutils stuff. I’m actually working from the other direction, grabbing all the properties from a bean and iterating through them looking for placeholders in the HTML that match each property name. That seemed easier than parsing the HTML and looking up properties on the bean. It should also make it easier to add user-defined markup – the code just does indexOf(openingMarkup + propertyName + closingMarkup) and replaces it with the property value. I wanted something that was ‘developer-driven’ – so the natural direction to go in seemed to be to emphasise the model acting on the view, rather than the other way around. Performance may be an issue, I have no feel at all for the performance of introspection and repeated calls to indexOf. I’m deferring worrying about that!
Didn’t get as much accomplished over the long weekend as I’d hoped, what with having to do a from-scratch reinstall of the OS on my new machine. WinXP Professional. Hmm. Reinstalling everything seems to have sorted out the random twice-hourly spontaneous reboot problem though.
What I did get done:
Tried out Maven. Looks very good, if somewhat complex to get going initially. I like the idea that you can specify all your dependencies in one project file. What would be really good is if you could bootstrap an entire build process starting with just the project.xml file. Maybe it can, I haven’t looked into it in sufficient depth yet.
Started using TortoiseCVS (yet another fine recommendation from JoeW). Works very well, but for some reason I have to type my password in every time I want to do anything – it would be nice to have it cache it.
Mucked about with my toy project, ViewBeans a bit more. Knocked up a quick-n-dirty site using Maven, and got the code doing string replacements based on bean introspection (including nested beans), which is quite cool. Need to learn more about taglibs, and how it might be accessed from within a JSP, and possibly consider how to deal with subclasses.
Russell has been having issues with custom tags and logic in pages. Interestingly, he remarks that it will never be possible to fully remove logic from pages. Its interesting because that was exactly what I had in mind for ViewBeans. Its still just an idea buried in my head, and some snippets of very dodgy experimental code, but it just might work…
There was some discussion last night regarding the use of JMS behind altRMI to
make asynchronous calls. Taking the idea further, I wondered if it might be
possible to implement asynchronous callbacks using temporary queues. So
requests that take a long time, but need to return a response to the user could
present a ‘please wait…’ message, or pop up an alert when the response has
arrived, without the client having to poll the server.
Some sample code I found here
looked a bit like this:
Queue tempQueue = qSession.createTemporaryQueue();
TextMessage request = qSession.createTextMessage();
QueueReceiver qReceiver = qSession.createReceiver(tmpQueue);
qReceiver.setMessageListener(new MyMessageListener(. . .));
Could be interesting, perhaps.
Post XtC thoughts:
Frameworks / Infrastructure code / Plumbing, call it what you will. It should be easy, really easy to use. If the framework coders have to perform unnatural acts to ensure that the users of the framework don’t have to, so be it. That’s part of the appeal anyway (or is that just me?). Writing frameworks is something of a masochistic activity in that sense. Producing something that is so easy to use its almost a no-brainer. Hard to use frameworks won’t get used. Or if they do, they’ll probably be misused. Its a tough balance. You want to make the lives of developers using your framework easier, without making their decisions for them, or taking away control.
AltRMI is a good example of a framework done well – its what RMI should have been. Simple exterior, clever interior.
Paul Hammant had some wise words to say on interface / implementation separation. So important for reuse, testability, just about everything thats worth having. The collections stuff from Java 1.2 being a good example:
Map myMap = new HashMap();
What if I want a map that survives restarts?
Map myMap = new PersistentMap();
Done and dusted. No client code ever needs to know. The counter example being java.io.File. What if I want to slot in a caching file layer? or some other data source that pretends to be a file? Out of luck…
Want reusable code? Interface – implementation separation.