[Pub] What's new in Mule 2

Mule from MuleSource is one of the most used Open Source ESB in actual integration projects. On March 31, Mulesource announced the final Mule 2 release, a popular Open Source ESB. This major release comes with some new features and architectural improvements. For this purpose I've written an article for all german audience interested in Mule, for the JAX Center. The article is available online and covers the following topics:

• The new schema based configuration approach
• API changes
• New concepts such as Mule Context and Registry
  
• The role of Spring in Mule 2
• The changes of Transports and Transformers
• Migration from Mule 1.x to Mule 2
  

We've upgrade our prototype application to Mule 2, illustrating the basic concepts of an ESB. The prototype is available on here.

[Misc] Martin Fowlers live DSL book

Today I would like to point your interest on the project that Martin Fowler is currently working on. So if you look at his homepage, you can see that he is actually working on a book about Domain Specific Languages (DSL).

The interesting thing in this is that he is writing in publicy and you can even trace his work with an RSS feed he is providing. His motivation was partially that there is much hype in this topic and lots of specific talks and papers, but no holistic approach for this topic. So whoever is interested in DSLs (and Software Engineers should!) should read this to gain a broad view of this topic.

And Martin Fowler would not be Martin Fowler if he won't use simple examples to illustrate his views: It reads like an adventure in a castle where you walk around, turn the light on three times, open doors and panels, take a picture off the wall, and much more to obtain a treasure.

And this example illustrated that you have rules, input data and thus you might have something like a state machine that helps you to solve a task. So one core item in this book is to show the variety of how these state machines can be build using:

• Method Chaining
• Pushing Parameters into objects or nesting
• Literal collections (like being used in Ruby or Rails)
• Closures (please let them arrive in Java...)
• parsing XML or other notations
  

and even Macros or annotations. Doing this, he carefully outlines and distinguishes between internal and external approaches. So if you as a Software Engineer would have to solve such a problem you would normally remember only a few approaches. Using Martin Fowlers book, your senses will be quite sharpened to find the best solution for your problem.

But he already has more chapters written as expression builder, networks, lots of parser issues, symbol tables and much more.

To conclude: it's not only worthwhile to see a respected author nearly live working on a book. The current DSL textfragments will help a lot to fin the right hammer for lots of software engineering problems.

[Arch] Programmatic Dependency Injection

Depdenency Injection is a very cool approach to structure and decouple your software components Depdenency Injection can be seen as a design pattern. Therefore some different implementations of this pattern exisit. You can also write your own DI implementation, but in many cases software developers use existing frameworks like Spring or HiveMind, doing all the hard work. I've found an interesting article about programming dependency injection with an abstract factory. The popular factory pattern is a very common approach to abstract the complex initialisation of service components. Some ideas of the factory pattern can be found in DI framework. This article illustrates an abstract factory pattern with the two following key differences to the traditional factory:

• An optional factory interface replaces the abstract factory class
• Every factory method is responsible for creating an object and injecting its dependencies

Based on a simple example with two components he illustrates the following scenarios:

• Lazy-instantiation of service components
• Non-Singleton scope (if always a new instance of a object must be created)
• Wiring up objects dynamically
• Creation of local stateful objects with dynamic paramters for singletons

To summarize the article:

• Using factories, developers have to write more code to get started
• Factory implementation code changes significantly if code changes between lazy-initialization and eager-initialization or from singletons to non-singletons
• Abstract Factory design pattern include creating local stateful objects from dynamic parameters, handling checked exceptions thrown during object creation, and wiring up objects dynamically
• Better performance because it uses straightforward Java code and hardwiring

For those who are not familiar with Dependency Injection, look at this simple introduction article, illustrating Dependency Injection with a real life scenario. In this article, the autor also presents a simple implementation of a DI framework, by loading object implementations from a properties file.

Whether you use a DI framework or you implement your own DI, the DI approach brings a clean structure to your software components/systems and unit testing becomes easier by using mock objects. DI frameworks, such as Spring, provide a wide range of additional features, like AOP, Transacation Management, API templates, and some other stuff, which can be also used.

[Tech] Persistence Layer Generation

More than a year ago, I wrote a blog entry discussing Apache iBatis (my favorite "O/R" Mapping framework) and wrote mostly about the not so well known sub-project Abator. Today I realised that there was some significant updates on the iBatis project recently, and also a new Abator version, renamed to iBator as released.

iBator is a code-generation tool that makes kind of introspection into a relational database schema and with a supporting XML configuration generates basic iBatis SQLMaps, Java Classes, and DAO classes (Spring). iBator can be used by an Ant task, standalone command or Eclipse plugin. It seems that this subproject got more momentum recently and I hope for further updates soon.

So iBator allows to generate a significant part of the persistance code of an application, which also helps "iBatis rookies" in understanding how iBatis works. The problem of the original Abator was, that it did not allow roundtrip engineering: typically the code generation is only the first step in the development of a persistance layer. One will in many cases want to modify the generated DAOs to better fit the projects needs. It seems, that the recent iBator release allows a merging of new generated Java classes with changes made in the old ones by using the Eclipse plugin. However, I did not substantiate this feature as yet.

I believe, that iBator makes the already very easy and straightforward iBatis project even more accessible in providing good boilerplate code to start from, yet I would be curious about actual "roundtrip experiences"...

[Arch] JBI Misses the Mark

One of the main differences between Apache Service Mix and Mule ESB is the JBI implementation. Apache Service Mix is a full implementation of the JBI standard. However, you can plug in Mule to a JBI container by using the JBI transport from Mule. I personally love Mule, because it's extremly lightweight and Mule 2 fits ideally with Spring application, finally that Mule 2 is based on Spring 2.x. Up to now I didn't have a deeper look to Apache Service Mix. But based on Alex information, the combination of Apache Active MQ, Camel and Service Mix is a solid basis provided by Apache.

The last couple of years Ross Mason the founder of the Mule Project often discusses why he decided not to adopt JBI for Mule. In his blog "JBI misses the mark" he mentioned the basic idea of Mule:

"[...] Mule was designed around the philosophy of 'Adaptive Integration'. What this means for Mule users is that they can build best-of-bread integration solutions because they can choose which technologies to plug together with Mule. [...]"

About JBI he points the following assumptions and there consequences:

• XMLmessages will be used for moving data around
• Data Transformation is always XML-based
• Service contract will be WSDL
• No need for message streaming
• You need to implement a pretty heavy API to implement a service
• It’s not actually that clear what a service engine is in JBI

Another interesting point is:

"[...] JBI seems to be a 'standard' written by middleware vendors for middleware vendors. This 'vendor view' of the world is one of the main reasons Open Source has done so well. Traditionally, Open Source has been written by developers much closer to the problem being tackled. These developers can deliver a better way of solving the problem using their domain knowledge, experience and the need for something better. This was the ultimate goal Mule and given the success of the project I believe that goal has been realized with the caveat that things can always be improved (which we continue to do). [...]"

Im waiting for some comments (especially from Alex) and what he think about the statement about Ross :)

[Misc] Late April Joke: OLPC XO and Windows...

Ok. I do not tend to use strong words in this blog, but even considering to put Windows on the OLPC XO is probably the most questionable idea I have heard in the last years in the IT world. The whole idea of the OLPC was (with much effort!) to create an open system, from hardware to software, that everyone can modify. To create a device you can learn with and learn from. The hard- and software are linked together, co-evolved for high performance on a rather low performance hardware to achieve a highly efficient and powerful device. Just considering to put Windows on that device is such a weird idea, that I believed it was an April joke when I read the first article. Why would anyone want to destroy the OLPC idea that was definitly more than a cheap laptop by making just that: a cheap crappy Windows laptop. What is the rational here? If Mr. Negroponte believes he cannot drive the project any longer, he should leave or stop it, but not ruin everything that was build up with a lot of effort from many spirited developers worldwide.

I just write that article to sympathise with all OLPC members that feel betrayed at least just by circulating such an idea. It is like inviting the club of vegetarians to a summer party and promising the best vegetarian food and then offering bloody steak and spare ribs. Sorry guys for these bad news associated with a great and inspired project. Carry on, and leave this nonsense behind you!

[Pub] Service Composition

In my recent (German) Infoweek article I discuss service composition using the SCA and SDO standard and the open source runtime Apache Tuscany. This article is freely available on the Infoweek site. I personally think that both standards are very interesting and not enough known at the moment. The Apache Tuscany project is still in the incubator, but seems to have a good momentum. Recently a new version was announced, that also provides an integration with OSGi as the runtime works with Apache Felix. Javalobbly has an article about this new release and the Tuscany/OSGi integration.

However, what I am still waiting for is an integration of SCA/SDO in Apache Tuscany with JBI, i.e., that the runtime can be deployed as a JBI component e.g. in Service Mix. I have no objections against OSGi, however, my feeling is, that it would fit even better in the integration context of an JBI enterprise service bus.