Can Mule Spring further?

Just wondering.

Mule 2 is already very Spring-oriented, or at least very Spring-friendly. Will Mule's distribution, which is currently a nice set of Maven-build artifacts, evolve to a set of OSGI bundles a la Spring for version 3?

If MuleSource follows that path and distributes Spring Dynamic Modules, that would allow people to run on the SpringSource dm Server, if they want it, and benefit from sweetnesses like hot service replacement.

I doubt that Mule could use SpringSource dm Server as a default platform unless they clear up what I think could be licensing incompatbilities. But end users could make that choice and put the two Sources, Mule and Spring, together.

Just wondering.

The Build Manifesto

My ex-colleague Owen has just introduced the Build Manifesto. I invite you to read it and share your thoughts with him.

Soon Serving Spring

I finally had a chance to step beyond trivialities with the SpringSource dm Server.

To make things clear, this server is all about giving life to Spring Dynamic Modules (DM). Spring DM is not new but putting this technology in action was awkward: you had to deal with an embedded OSGI container and figure a lot of things out. The SpringSource dm Server provides an integrated no-nonsense environment where dynamic modules live a happy and fruitful life.

The benefits of dynamic modules are well known, and mostly derived from the OSGI architecture. The goodness Spring adds on OSGI is the clean model for service declaration and referencing. This is priceless as it enables a true highly cohesive and loosely coupled application architecture within a single JVM. If you come from a world of EJBs and troubled class loaders, this is the holy grail.

To exercise this sweet platform beyond the obvious, I have built the prototype of a JMS-driven application. The architecture was pretty simple: a bundle using Message Driven POJOs to consume a Sun OpenMQ destination, which then informs clients of new messages through a collection of listener service references. The idea was to allow the deployment of new clients or the hot replacement of a particular client at runtime. Verdict? It just works. The SpringSource dm Server goes to great length to isolate you from bundles going up and down (depending on the cardinality of your references to OSGI services, you may still get a "service non available" exception).

What I really enjoyed was the possibility to use bundles of Spring wired beans as first class citizen applications. Gone is the need for wrapping Spring in a web application to get a proper life cycle... POJOs rule!

Version RC2 of the server still has some rough edges (for example, the deployment order in the pickup directory is fuzzy and the logging messages are badly truncated and ill formatted) but they are minor compared to the amount of work done on the platform itself.

For me, the main challenge remains in making this server truly production-grade. Here are some points that I think need improvement:

• Consoles all the way down: You have to juggle between the Web Admin Console, the Equinox OSGI console and JConsole to perform different bundle management operations. The SpringSource dm Server needs a single console to rule them all.
  
  
• The configuration management is unclear: I ended up using an extra module, the Pax ConfigManager, to load external properties file in the OSGI Configuration Admin service. The SpringSource dm Server needs a default tool for this before going to production.
  
  
• A proper service Shell script is missing: you just get a start and a stop script, which is not enough for production. A unique script with the classic start/restart/stop/status commands would be way better. If the matter of licensing was not such a hot subject in SpringSource currently, I would suggest them to use Tanuki's Wrapper as their boot script.

It is obvious that SpringSource will take this server to the next level and make it production ready pretty soon. It might already be done while I write this.

I you are a latecomer like me and have not started to seriously investigate this technology, now is the time.

Final painted all over it

In my previous post, I mentioned that I let Eclipse add final statements everywhere in my code. I initially was reluctant to this idea.

Then I came to work on a piece of code which was heavily dealing with string processing. The temptation to re-use a variable and assign a different string to it several times, as the processing was happening, was really high. Using the final keyword forced me to declare a new variable each time. The great benefit was that I had to create new variable name each time, thus making the code clearer in its intention.

Hence, using only final variables makes the code stricter and cleaner. Moreover it is a safety net for the days when I am sloppy: final variables give me the big no-no if I feel inclined to repurpose one of them!

In Clean Code Uncle Bob advocates against such a systematic use of the final keyword for the reason it creates too much visual clutter. I agree with him though you quickly tend to visually ignore these keywords. Scala has solved the cluttering issue elegantly thanks to specific declaration keywords instead of a modifier (val for values and var for variable).

Did I just say Scala?

Microtechniques: a little more conversation?

Interestingly, just when I was about to write about the pleasure of not typing many things while coding in Eclipse, J. B. Rainsberger just posted about the potential importance of typing fast. I guess this is the nature of the webernet: everything and its opposite at the same time, and leave it to the readers to sort things out!

I was reflecting about my coding habits with Eclipse after a thread in the Java forums, where a poster was complaining about the continuous compilation feature, prompted some internal debates (my, myself and I often disagree). Interestingly, this feature has been touted by others as a key one.

I personally like the continuous feedback. The rare time I write C# code in SharpDevelop, it takes me a while to remember that I have to tell the IDE to look at my code. First, I do not like to have to tell my friend the computer to do things. Second, I want the continuous feedback. I do not mind if the compiler is temporarily confused because my syntax is momentarily broken. I want the early warning that this feature gives me.

In fact, continuous compilation creates a neat state of flow, where you actually engage into a conversation with the IDE. And this is where my stance about not typing comes into play. I do not type class names, but merely each capital letter of its name and let the code assistance propose me something that fits. I do not write variable declarations: I either assign it automatically or extract it from existing code. I less and less write method declarations but extract them. I allow Eclipse to add keywords (like final) and attributes (like @Override) everywhere it thinks necessary. I leave it up to the code formatter to clean up my mess and make it stick with the coding conventions in place.

All these automatic features do not dumb me down. They establish a rich conversation between my slow and fuzzy brain and the fast and strict development environment. The compiler tells me: "ok, this is what I understand" and the IDE tells me: "alright, here is what I propose". And then I correct course or keep going.

So maybe we need a little less typing and a little more conversation?

Just Read: Clean Code

I have been expecting this new book from Uncle Bob for quite a while so, as soon as I have got my copy, I rushed through it!

If you have no idea about who is this guy named Robert C. Martin and mainly expect people to "sent you teh codez", then you have to read this book. This will not transmogrify you into a craftsman but, at least, you will get a fair measure of the journey you still have to go through and be pointed in the right direction.

If you are familiar with Uncle Bob's writings and attend his conference talks, there will be no new concepts for you in this book. It will still be an insightful reading because of the extensive code samples and the refactoring sessions where you can actually follow the train of thoughts, and the actions they entail, as if you were in the master's head. It's like being John Malkovitch, but a little geekier.

The book itself is somewhat structurally challenged and lacks a little consistency, from a reader standpoint.

But who cares? As long as you can read this kind of stuff:

Clean code is not written by following a set of rules. You don't become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.

Robert C. Martin, Clean Code

... is the form so important?

Colliding Cow Bells

I found that the original Large Hadron Collider Rap was lacking cowbells. Here is the reviewed version that is now fully compliant with Christopher Walken and Blue Oyster Cult's standards:

Code Onion

The code of an application is like an onion, which is why it may make you cry sometimes. It looks like this:


The core

This is the code domain where unit test coverage is the highest, hence refactoring is free. This code is as clean as it can be. This is the comfortable place where everybody wants to work in. Thanks to high test coverage, the feedback loop is short and fast so morale and courage are high when it comes to touch anything in this area.

The borders

This is where most of the compromises happen. Dictated by the use of frameworks or application containers, code becomes invaded with inane accessors, class names end up hard-coded in configuration files, out-of-code indirections (like JNDI based look-ups) weaken the edifice. Unit and integration tests help building reasonable confidence but some refactoring can induce issues that can only be detected when deploying in a target container. This slow and long feedback loop reduces the opportunities to make things better in this area.

The wilderness

This is the outside world, where the rift between the world of code and the harsh reality of life resides. Databases inhabit this place and provide great services but they mismatch with objects. The network is there too, always happy to teach your application pesky lessons about latency, droped packets or broken pipes. Worst of all, users (yes, Tron, they exist) have invaded this area: from there they will constantly find creative ways to abuse your innocent code.

Tensions exist at the touch surfaces between these three layers, resulting in incongruous invasions of concerns and perversions of one layer into another. Ideally these layers would not exist: we would not need frameworks to bridge the world of pure code with the real world. In the meantime this dream comes true, we will have to keep dealing with the code onion and, every now and then, shed a tear on less than ideal code.

ESB Testing Strategies with Mule

SOA World Magazine has just put online my latest article, "ESB Testing Strategies with Mule", which they have published in their August issue.

That's silver, Jerry!

That's silver... for Mule In Action in the current Manning early access best seller roaster. And the book is only getting better thanks to our great reviewers!

Reading Calendar Irony

My six readers (according to Google Reader), will certainly appreciate the irony of my reading calendar.

Here are the two books I am currently reading:

Isn't this coincidence really fun?