Wednesday, July 22, 2009

Which one is the best?

You've probably heard it many times, in various circumstances. What was your answer?

That trivial question may(or not) have been subject to a long answer with hopefully credible reasons. "The problem is ... Many tools provide XXX ... This tool is the best, in this case, as ...".
But you're the expert! The reasons motivating your choices should be obvious to anybody else without having a long discussion!

There is no best, there are needs and there are constraints to reach particular goals(short, medium or long term). All those variables usually fits in to a vision.

If there were a best, anyone who could afford it, would have it.

No, no why would I want to use crap seriously?? So many tools already suck and people keep providing more crap. Maybe I should suggest that they stop already, as there are many similar great tools out there.

A typical conversation about choosing a Linux distribution
Q: "What's the best Linux distribution? Ubuntu?"
A: "Wut??? Hell no, it's Debian and all the rest is crap including the derivatives."
Q: "Why?"
A: "Because Ubuntu doesn't ... and because I say so :-)"
Q: "But Ubuntu is easy and Debian is not user friendly!"
A: "Really? Not really .... Ah, I guess I just like things when they're complicated, must be the geek feeling."

A tool can meet needs but not all the constraints and vice-versa and what you'll probably be looking for is a balance.

  • Memory usage vs tons of features
  • Usability vs complexity/too much flexibility
  • Easily understood vs require 5 books + certification + hiring a consultant
  • Commercial support vs community support
  • Proven stability and acceptance vs the unknown
  • etc.

There are simple ways to decide :

  • You have a problem to address within constraints(time, budget, etc.)
  • You try looking for tools which are particularly good at solving your specific problem and that integrate perfectly in your custom infrastructure. However, no such tools seem to exist or there's that little thing that you dislike.
  • You then look for compromises and ways to solve the issues that won't get magically fixed by the tools.
  • You don't have time to look at all the existing tools and evaluate them. You'll be selecting few tools and trying them out. Hopefully software vendors will cover the tiniest details which are relevant to your business needs, in their documentation.
  • You decide and you live with it, maybe reevaluate your decision and revise your goals, but you move forward unless you really believe that you're wrong.

It's not easy to decide in the IT world. You might get it right or wrong but you may have the power to correct your mistakes. Whatever the choice, the rational move is trying to select wisely, going forward and take responsibility.

Tuesday, July 14, 2009

Playing with OSGI and JPA

I've been writing an IRC bot for fun, but it's far from being done. My goal is to experiment with JPA in an OSGI environment.

At work, I am using Hibernate, XDoclet to generate the XML and JPA isn't coming soon :-). My last JPA application was a pastebin application, with Wicket, hibernate search, Lucene, etc.

I'm using a friend's library Jerklib with Dynamic JPA. I'm still having some minor issues when deploying but I'll probably find a solution soon.

About the application
Environment
I have a multi-project with Maven and I'm using the maven bundle plugin and I'm developing in Eclipse 3.5 on Debian testing.
I'm using openjpa , dynamic jpa and couple of other dependencies

Design overview
a) Commands implemented as plugins : The bot has a set of factoids(learn, forget, etc...). Each command gets created using a factory.

// message listener //String operation = getOperation();
CommandFactory factory = ServiceFromOSGI.getCommandFactory(operation);

// if the factory is not null, redundancy for the operation parameter
// as a factory can have multiple commands
Command command = factory.createCommand(operation);
ircChannel.say(command.render(ircMessageContext));

b) The command service listens for removal or installation of commands and updates itself.

After writing couple of "users' commands", I would need to implement some administration commands(load/unload plugins, irc specific tasks, etc.).

Problems
The dynamic discovery is failing for now, the persistence provider class is not resolved, it might just be a bundling problem for openjpa. I wrapped it myself.

Conclusion
It's strange that many open source projects still don't provide an OSGI manifest. The maven-bundle plugin is very trivial to use for maven enabled project and there's still bnd.
While OSGI is an interesting technology, I personally don't know anybody using it in the enterprise unless they are an Eclipse shop. I think that it's mostly due to
  • the lack of "OSGI enabled jars"
  • the fear that OSGI might introduce unnecessary complexity
  • the lack of step by step complete examples(if possible with screencasts)

There's plenty of documentation about OSGI and lots of successful applications(Web, Desktop) using OSGI. Hopefully my bot will be one those applications :-)