The subtle glitch in JCR 1.0

After investigating JCR 1.0 (spawn of JSR-170) implementations (Alfresco and JackRabbit, both excellent realizations) for a few days, I feel a strange combination of excitation and disappointment. I am excited by the idea of having a standardized API to hit content repositories, a playground where proprietary interfaces have been ruling for a long time. The reason of my disappointment will take a little longer to explain.

One of the key selling point of JCR 1.0 is that it enables you to swap your repository from vendor A to vendor B, provided that they both support the same level of feature (so far JSR-170 defines 2 levels). This is true and it works but to some extent; and it is in this restriction that lies the glitch that annoyed me so much.

JCR repositories rarely come as naked JSR-170 implementations: they usually come complete with other ways of reaching their content (WebDav, CIFS, portals...) and - hopefully - useful administration tools.

Because JCR 1.0 is an extremely granular API, where familiar concepts like folders and files are not handled as such but abstracted as general purpose nodes, it allows each implementation to decide how to represent the classical hierarchy of folders everybody is used to and expects to find in a repository. And this is the crux of the problem: if you stick to the pure JCR API, you will be able to run your code on any compatible repository but the connected tools and other data retrieval channels will not recognize your data structure and will ignore it.

For example, a block of code will create a data structure that JackRabbit WebDav access represents as a folder containing a file, while the same block of code will store data that Alfresco will not be able to display in any of its data or web access tools. I have even come to inconsistencies (not the proper term because it is logical that it does not work) within the same tool: code that creates this folder and file that JackRabbit browser interface can render will be exposed as meaningless folder and files in its WebDav access.

The conclusion of this story is that yes, you will be able to swap one repository for another, but the trade-off is that you will potentially loose some or all of the extra features of the repositories. To me, this sounds like a major loss.

All this reminds me of JDO: so generic and versatile that it has never been good enough in one particular persistence strategy compared to Hibernate database-only persistence that has reached excellence and universality.

Let u’s hope that JCR 2.0, the upcoming spawn of JSR-283, will address this concern. But will it? Is it the interest of the expert group members to be potentially swapped-out when all of them look for lock-in strategies? Only time will tell.

Back from Oblivion

I have just uploaded a few screenshots of Celesstin 3, a great research project I have been lucky to work on back in 1990. The project, sponsored by IBM and Dassault, consisted in developing an automatic converter from mechanical drawings to the CAD system named Catia.

Entirely written in C, it was running on 5080 graphical terminals, backed by a 9370 VM/SP server (we also run it once on a 3090, where it only took a few minutes to compile instead of the usual 20 minutes). Part of the process was run on 6150 boxes where the inference engine named ATOME was used to make deduction about mechanical elements.

My job was to wire the different parts together behind a graphical interface, which was a brand new endeavor on a 5080 terminal, at that time. One guy of the team was a very talented icon designer and, if you look at the pictures, you will see we did a great job!

Strangely enough I put the menu bar on the right and the main button (equivalent to the lovely Windows Start button) in the bottom right corner. This does look counterintuitive nowadays, does not it?

This was mainly 2D display (you can notice some 3D components in the final interpreted stage of the recognition process) , so to grok the graPHIGS programming interface, I have invested my free time (i.e. after midnight) into developing a 3D roleplaying game a la Dungeon Master.

Unfortunately, I can not put the finger on the screenshots anymore... That is the fate of most of our software realization: hours of hard work that are bound to oblivion.

Broken Workflows

A nice and easy way to lose customers is to carefully implement broken workflows in your business. This is not an easy task and you might need professional assistance for succeeding in such a bold endeavor.

Or you can take real world examples as models.

Like Free, the French ISP, which is so hard to leave. Their broken workflow strategy is based on the MPOC Paradigm. The MPOC, or Multiple Point Of Contact, is the inefficient counterpart of the SPOC, or Single Point Of Contact. As such, the MPOC can increase the difficulty of reconciliation related messages, increasing the chance of breaking any existing workflow. Free (not as in beer) has established two points of contacts for subscription termination: one that deals with the physical aspects (like modem return) and one that deals with contracts and payment aspects. Needless to say that this is a big success: it is guaranteed to take a few months and many certified letters to terminate a subscription. Great job!

Or like Dell France, where a great deal of mastery has been deployed to ensure that you will not spend your money there. They follow the Black Hole Paradigm, where messages are either held captive, buried or lost. This is a very complex strategy whose main purpose is to prevent any form of end-user feedback and disable useless mechanisms like escalation. Dell masters this delicate art and uses it brilliantly: your internet order will be held captive for weeks before you get any feedback (while 72 hours maximum was announced), the web interface to query the order status will consistently return nothing and the commercial services that you can reach on the phone will not have internal access to any information about your order. Amazing implementation!

These are only two random examples but I am sure they will be very useful for anyone interested in broken workflows.

Have you experimented other broken workflows strategies or paradigms? Please do share them here!

Welcome to the future...

eop.

The Difficult Art of Good Example

I am almost done reading Core JavaServer Faces.

Wow. I see you coming, so I must immediately make the following disclaimer: I am not embracing the wild idea of reconverting to presentation-layer development. What I have seen in this book scared the heck out of me and I definitively prefer to stick to more trivial things like high-performance massively-scalable middleware development*.

This said, the book is pretty good, stuffed with detailed examples and very valuable insights and comments on the JSF strengths and weaknesses.

Did I mention examples? Yep! But I forgot to mention this one example that freaked me out, because of the potential bad habits it could create, while giving the impression it is pretty legitimate.

To demonstrate database connectivity, the authors use the infamous and pervasive login example. Type in your name and password, push login, then let's connect to the DB and redirect you to either the jolly welcome page or the less welcoming sorry page.

Now this book will be read by people who have no clue about the capacities of a J2EE container and they will take for granted that security must be implemented in the application. And people like me will have to come after that, clean the mess and watch the grim on their (JS) faces when I will have to explain that not everything in a book must be taken for granted.

Sure the authors detail the J2EE security mechanism afterwards, as a better way of doing things. But come on, it is too late, our reconverted ASP-or-whatever-other-horrific-MVC1 programmers will start implementing their own security algorithm in their JSF applications.

And they will fail.

There are plenty of other things an application can use a database for... Why this login example? Why not the famous stock value lookup example?

Beware bad examples: disastrous consequences might follow!

______
* shameless boasting

Your Eclipse IDE

Many Eclipse projects and sub-projects are now reaching an undeniable level of maturity. EMF is an incredibly useful modeling framework and TPTP promises to become a reference point in term of performance and test tools.

In this emerging wave of high quality stuff, WTP is finally out of the gloom and starts to deliver its promises. This lead me to wonder what will happen to Genuitec's MyEclipseIDE as the competition pressure of the freely available WTP will keep on growing.

Lost in the crowd of IBM committers, you can spot one contributor from Genuitec. How this contribution, which will obviously be minor, will play for or against MyEclipseIDE?

Will Genuitec focus on a few specific plug-ins that they will still be able to sell and support? Most probably, as there is still room available for specific gizmos like Struts page flow editors or Hibernate generators.

Will Genuitec react to this competition to tackle some deficiencies of their own plug-in suite, like the stupendous tendency to fork existing plug-in codebases (making their independant update impossible), the painfull habit to create dependencies to internal APIs (making each Eclipse upgrade a nightmare for their own developers) or the limitation of certain features to Windows-only environments?

Only time will tell. But one thing is sure: bright is the future of your Eclipse IDE!