Messaging Services

Written on 10:47:00 PM by S. Potter

Since my previous post was on the subject of comparing J2EE stack with lighter weight frameworks, I thought I would make some more points before Rails, et al. gets a beating for not having as much functionality as J2EE. I am sure my full-on Java friends will feel triumphant after my last posting because such a comparison would be null and void due to comparing apples and pears. Many of my Java friends haven't bothered to really research Rails, TurboGears or Django and not even Ruby or Python. I get the impression that they refuse to because then they might be pursuaded and be proven wrong, or at least not completely right!:) From an abstraction level the Java-heads might be right. J2EE can be a million different things to a thousand different people (yes, you read that right). Rails, TG and Django do not try to do this. They are fully loaded web application frameworks. Does this mean then that the conversation stops? I think not and I will tell you why. The vast majority of J2EE apps are written for web browser clients, Swing/JFC desktop apps or simply (mostly Java) headless services. Now lets consider, say, Rails. Maybe 98% of its clients are browser clients (I assume a much higher percentage than J2EE apps), but other clients are SOAP, XML-RPC or REST based clients which could be headless services or desktop applications. They could even be other web applications. So what does this mean? That comparing J2EE and, for example, Rails isn't quite as proposterous as Java-heads might first think. However, the one major area where there is an absence of functionality in, certainly, the Ruby world, in my experience (unless another Ruby-ite can point us in the right direction) is a Ruby based messaging service, like the JMS implementations out there. Some people say though that this is not a big deal, because you can generate Ruby and Python bindings for messaging services like Tibco, MQ and even JMS implementations. My problem with this is that there does not seem to be a good open source messaging service that isn't too Java-centric. In this article I give a measely 5 points to the Java-philes, but overall you are still far behind;) PS I am not suggesting that Rails should provide any type of messaging service functionality, only Ruby, Python or a non-Java centric enterprise-ready open source alternative to JMS, MQ or Tibco. If I were suggesting the former, then I would be completely contradicting my previous blog entry and I do not wish to do so. Thanks for reading.

J2EE vs. FastCGI

Written on 10:29:00 PM by S. Potter

After a month hiatus I return... Here is a link to a reasonable (meaning non-emotional) discussion of J2EE vs. FastCGI on the issue of scaling. One side note to the discussion that is mentioned several times in this blog entry is how FastCGI's API is extremely simple whereas J2EE's is extremely, well, not. It isn't a completely fair comparison since many developers use Rails, TurboGears or Django as a framework around the FastCGI base. However, in my experience with J2EE (even when it first came out), there was always an aura of complexity in the specification due to its inherent level of abstraction. Rails and TurboGears (sorry I have never used Django on any production-worthy project) both have an aura of simplicity from their inception. Another point I would like to make regarding Rails, TurboGears and Django is how different each of these frameworks differ in their approach to offer simplicity. While I am hopeful for the future of all three of these projects only time will tell if they will retain the simplicity they so vehemently publicize.