Bruno Fernandez-Ruiz

While developing our trading application, I have come across two key things Rails does not have:

* Transactions. Rails does not offer distributed transaction management. This does not bother me much, since I am not a fan of having transactions span across multiple datasources. However, Rails does not offer cross entity transaction management on a single datasource for unrelated entities. The Rails model works well for ensuring autocommits on parent-child relationships, but anything beyond that requires extensive work and bookeeping in your controllers. For most jobs, the Rails model is enough, and does the job. It actually does the job pretty well. But there are jobs, such as updating multiple trading and position tables where Rails is not the right tool.

* Security. Rails is absolutely agnostic of security. Authentication, authorisation and Access-Control Lists are foreign to the framework, by design. The whole plumbing required may become daunting, and while there are engines and plugins out there doing part of the job, I truly hate taking ownership for the security bits within my application.

Localisation and internationalisation is yet another third a bit weak in Rails, but I am yet to have true requirements in this area to be able to give an opinion.

Anyway, Django looks like a promising alternative. It offers both more comprehensive transaction management support and a complete security model, with the whole plumbing being in the framework itself. Whether it will fit the shoe, we’ll see as soon as I write the order island book.

No, they never do. Here is the deal.

A centralized Enterprise Architecture (EA) function represents a compromise between the distributed functions in the enterprise. The distributed functions give up some control to invest in the enterprise technology strategy. As with any good investment, the returns need to outweighed the risk profile, otherwise the business functions will pull out of the whole EA thingy.

If the Enterprise Architecture function does not clearly articulate the returns on investment in technology, it will have trouble to enforce architecture governance. As much as the return may seem obvious to those situated in the realm of the enterprise — nevertheless detached from the actual business functions — returns on investment in technology need to be articulated, forecasted and measured on an ongoing basis to provide adequate architectural steering.

Even if EA is the right thing to do for most mature-growth organizations, the whole EA initiative is doomed to fail in the long-term without following this basic principle. Without it, it is hard to ascertain the required degree of adoption of the EA principles (how much EA do we need?), and the lack of clarity and transparency will eventually end up with the disengagement of the business functions.

Until an EA function is able to clearly articulate these returns, it should refrain itself from becoming a policing and dictatorial authority: The Ends Don’t Justify the Means.

The Java EE 5 architecture, with its use of annotations brings the Java world close to being agile. The architecture is absolutely fantastic and powerful, with superb messaging (JMS), persistence (EJB3), transactions (JTA), and integration (JCA) capabilities.

However, on the presentation side, for the web world, Java is still behind both .NET and agile frameworks like Rails or Django. JSF is cumbersome, and still too attached to the systems-programming intensive request-response Model2 that ended up in JSPs and Struts. Wicket and Tapestry are possibly the top component-based development web frameworks for Java. But they are both only used by a relatively small community, and documentation, mostly in the case of Wicket, is deficient, especially when it comes to topics such as integration with persistence frameworks.

In terms of setting a complete development environment, it is painful. Setting up Netbeans/Eclipse, JBoss/Geronimo/Glassfish, Wicket, and EJB3 to play nicely with each other is not easy, and it has lots of rough edges. It takes too long to setup an environment and start coding.

That myriad of frameworks and standards is what makes Java EE so powerful, yet so cumbersome. I was hoping annotations could have solved most of the integration complexity, but I am disappointed. So, sadly, my hopes for a “new Java” are yet once again down. Java EE still gets on your way to being productive.

I am back to Rails for the time being, at least until Java EE 5 matures.

I have tried for the last couple of days to overcome some of the transaction management problems I was having with Rails, and the more I look at it, the more I am convinced Rails is not right for my trading application. Rails has its sweet spot, and for me, there won’t be anymore PHP.

I came back to my usual Java stack, with the usual suspects, Tapestry, Spring and Hibernate. But, after the Rails experience, it was just … yuck! The development environment is complex to setup, there are library dependencies, tons and tons of XML sit-ups! Enough!

I would like to use annotations, and it seems like Hibernate and Tapestry all have it in already, so no more need for XML files, and complex build and packaging using XDoclet. But development environment support for this flavour is very flaky. So much, that I got frustrated.

And this made me re-evaluate an old friend: EJBs. The EJB3 in JavaEE 5 leverage the annotations to make it expressive and put the focus on the model.

I have no more need for Spring, which I was only using for transaction management. I am happy with stateless EJBs.

I have no more need for accessing Hibernate directly. I rather using Entity Beans, and have the implementation be Hibernate3 (wow, I am sooo surprised to read this … given how such of an anti-entity beans advocate I have been!!).

And as for Tapestry - well, sorry. It’s just too much, even with Hivemind. Unit and integration testing is still hard with Tapestry, and there are far too many conventions around.

Which only left me JSF and Wicket on the web component development frameworks front. And given that I don’t like the JSP baggage in JSP, I’ll go for Wicket, which shares a lot of the Tapestry principles.

So, my new stack is Wicket 1.2 and EJB3. Let’s see how it goes.

I was reading yesterday the tutorial for the Globus Toolkit 4 (GT4), especifically this and this page. It highly disturbs me. Something is not right. It reminds me of the CORBA, and early day’s of EJBs. 90% systems programming, for 10% application programming. Thankfully AOP, Spring, Hibernate and friends kicked in to help, and introduced Inversion of Control to the masses. Hollywood’s principle for everybody.

In GT4, you code manually the WSDL, and your Java classes reference directly the framework and XSD namespaces.

I believe writing the WSDL/XSD by hand is a good thing when you are writing truely reusable (web) services, to ensure they are not just doing RPC over a pretty crappy protocol (HTTP), and you are focusing on the message. However, if Globus is to be used for parallel computing, ala my beloved PVM, you actually want RPC-style, and Globus should be generating the WSDL automatically upon deployment without developer’s intervention.

Additionally, when it comes to the Java side, the code looks like an EJB in the 90s. I don’t care if you could generate that code, it simply sucks as a class.

I look forward to the Spring of GT4 to come out really soon!

Scarcity is a requirement for a good to be economic. However, http://www.onethousandpaintings.com/ offer something that could be offered by thousands of artists out there. So, it is not scarce. Or is it?

Painting a Miro or a Picasso is only within the painters’ own ability, and I don’t want to buy some cheap street plagiarism. But some people actually do, and these copied paintings sell on the streets. They don’t probably sell to me and you, but they sell to a few to which the good is scarce. To those few, the painting either has an economic value, or its utility is fully artistic and they assign zero value to money. Assuming they are not infinitely rich, because they could buy the original Miro or Picasso, it only leaves us with two options: either they are infinitely stupid not to assign value to money, or the copied painting truely has some economic value.

Corolary: don’t try to market to everybody, but create scarcity for a few to which the goods have economic value.