[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.

[Misc] Strong Opinions on Freedom

Today I listened to the IT Conversations Podcast: "Eben Moglen on Licensing in the Web 2.0 Era". I must say, that this talk made me thinking. It for sure left me with mixed emotions. Eben was discussing with Tim O'Reilly and I definitly disliked the fact, that he attacked O'Reilly on a quite personal and in my opinion unprofessional level.

Still, there is a point he makes. Eben Moglen is a professor of law at Columbia law school and founder of the Software Freedom Law Center (and working with Richard Stallman). He was recently busy with the GPLv3, and this was part of the discussion. The main point Eben again and again raised was however, that we wasted at least 10 years in discussing "Open Source" and not about discussing freedom. We should talk about patent laws and other regulations in the first place.

I think that there is something to it. I also tried in discussions and publications to focus less on Open Source, but on conditions that make Open Source the right way to go, as Open Source itself is not the issue. I always felt that e.g. protocols are the more important field of discussion and policy than Software actually is. And here is the point where legal policies could also play an important role for freedom (of choice) and lay a proper foundation for non-monopolistic commerce: If we would e.g. have a proper regulation on Office protocols, like defining that only open specified document formats (like used in Open Office) are allowed in public services, this would lead to a pressure to software vendors and to a proper competition on the market and finally also to a rich Open Source scene. Then we would have the freedom of choice, the freedom to use our data and information in any way we want plus it would have positive effects on the Open Source scene, but not the other way round.

Ok, these are my two cents to the topic. To conclude, I think that Eben is definitly making a valid point, even if he decides to use an aggressiv tone in his speech that is not appropriate in my opinion. Listen and decide for yourself.

[Pub] Implementing Enterprise Integration Patterns using Open Source Frameworks

Robert Thullner recently finished his excellent master-thesis with the title "Implementing Enterprise Integration Patterns using Open Source Frameworks". In his thesis he is refering to the EI Patterns described by Hohpe and Woolfe. Robert analyses a set of leading OS frameworks in this domain (Mule, Apache ActiveMQ, Service Mix and Camel) for how they implement patterns and how they support developers in implementing EI scenarios using patterns. (Particularly Camel impressed us from the conceptual level and also the ease of use).

He defines a set of scenarios using specific patterns (the figure above shows one of the scenarios) and are implemented with various (combinations) of technologies to evaluate and demonstrate the capabilities of the specific technology or mix of technologies. Finally he categorises the frameworks and gives hints on implementation best-practices.

I don't want to go into details here, but who is interested in Enterprise Integration Patterns and Open Source frameworks might want to download the full thesis here. The sources of his examples can be downloaded as well.

[Tech] Database Migration

I found an interesting project: migrate4j which was introduced at Javalobby today. The idea behind this tool is to leverage the issues that come up when applications are developed using a relational database and the database schema changes between version. I.e., databases at customers or used by other developers have to be modified to the needs of the new version of the software. Probably you even want to downscale again.

The main page of the project already gives a good insight into the functionality of this tool. The idea is to describe "up" and "down" grading steps in Java classes that can be executed within the build automation cycle. Up and down are relative to the current version of the database. So it should be possible to up- and downgrade the database to the desired level automatically when needed.

Very interesting idea, however, I am wondering, why there are not more tools like that around; everyone developing database-applications is fighting with such issues I suppose. Have I overseen such tools? Recommendations?

[Conf] IDC SOA Conference

Today I was invited to hold the keynote speach at IDCs SOA conference in Vienna. I was talking about building agile business processes from "decoupled" services. I discussed three different views on aggregation: 

• A "formal" top-down approach using Standards like BPEL or SCA; this approach typically is process driven
• Event-driven architectures, which is a rather bottom-up approach (and a very agile and flexible one!)
• And finally a data-driven approach using "syndication" features and standards, typically following the REST principles (which reminds me, that I want to write something about REST since an eternity...)

If you are interested in my presentation download it from my website.