Tuesday, October 03, 2006

Reuse or Rewrite AndroMDA Cartridges?

Someone asked me what is the best way to work with AndroMDA in case that the architecture (structure, naming, process, etc.) is different than the AndroMDA's one. Reuse all the cartridges as far as possible and extend them or rewrite them from scratch?

My opinions are as follow:
  • Think of a framework everytime you use AndroMDA. This includes the cartridges AndroMDA offers. When you are using frameworks you mostly don't want to rewrite them. You want to reuse and extend them. So, reuse and extend already available AndroMDA cartridges is the way to go.
  • If your team is only a small team never think of building your own architecture, thus you don't need to rewrite the cartridges. By building your own architecture (e.g. using your own directory structure, using your own naming convention, etc.) you mostly need to write your own cartridges which is costly. Remember that the developers of AndroMDA and AndroMDA cartridges are not beginners. They had many thoughts poured into the cartridges and most of them are experienced architects and developers. So you can be sure that the architecture of applications generated by AndroMDA cartridges are a stable architecture and has a good thought.
  • Never forget that AndroMDA is an Open Source project. If you think you have better ideas just join them and give them some inputs to make the available cartridges much more better!
So, when should we write our own cartridges?
  • In case that you are doing a re-engeneering project which means that you have all those source codes and you want to integrate AndroMDA cartridges slowly into the whole application development process you need to write your own cartridges. In this situation you can slowly "generate" some of the repeating codes by using your own cartridges. Already available AndroMDA cartridges will mostly miss this purpose. But again, if you write a new application reuse and extend available AndroMDA cartridges as far as you can.
  • Only build your own architecture and thus create your own cartridges if you and your team have the capacity and resources to do this.
Happy modeling,

Sunday, September 24, 2006

Next year conference...

Next year at OOP 2007 Frank and I will offer a session about MDA and product line engineering. In this session we'll show how to use MDA with product line techniques in a pragmatic way by using Open Source Java products. We'll underline the importance of Business Rules, so that we will be able to build a flexible solution for some domains which is based on the same business requirements.

This should be a practical session and not a theoretical one as often the case in product line sessions. I would also like to thank Gernot who made this session possible!

Sunday, August 20, 2006

The Heavyweight Champions are... Springframework and Hibernate?

There are a lot of argumentations exist trying to proof whether a combination of Springframework and Hibernate is still a "lightweight" or already a "heavyweight" champion. Please see following discussions in TSS for some of arguments:

My conclusions after working with Springframework and Hibernate in some of my projects are: yes, Springframework and Hibernate are already our heavyweight champions! Why?

  1. It's getting on my nerves as I have to create SpringBeans by editing those Spring XML files. This is the same with Hibernate hbml files. I know there are some tools available (e. g. Spring and Hibernate plugins) to help me finish these annoying works. But still... at the end this is just the same as working with EJB 2.x with those deployment descriptors. You might say, I can use annotations. The problem is I still have to deploy in JDK 1.4.x. So annotations just won't work. I also know that Springframework 2.0 uses XML schema so the XML files are easier and shorter to create, but again, I hate creating XML files by hand and you?

  2. Special for Springframework XML files and this is often the case: you need one XML file for remote client context, one XML file for local client context and one XML file for test? Gee, how many XML files should I write or copy and paste plus edit?

  3. Hibernate should protect us from the database behind it. Is this true? Until a certain level yes, but if you try to work with Oracle and at the same time with MySQL you will still need to understand the differences between those databases! Do you know that Oracle always saves "" (empty string) as a null value? And this is not the case with MySQL! So welcome back to the relational database!

  4. Do you know how many methods do we have in Hibernate just to persist or create a new object? What are these methods actually for: save, saveOrUpdate, persist, merge? Man, in SQL we just have one command: insert! Do we really need those different kind of methods just for a simple thing? Why can't we just say "save" and everything will be taken care by Hibernate?

  5. I think you already heard a lot about architecture discussion to DTO or not. If not you can check out some interesting discussion in Springframework forum: Transfer Objects. You also can find the same discussion in TSS: Protecting the Domain Model. So, what's the hell why we use POJO if we still have to use DTO? You don't need to use DTO at all - many of us would loudly say, but what if we need to physically separate the tiers? In this case you will meet the most hated exception in Hibernate: Lazy Loading error if you are not carefully design your POJO! So sometimes we need DTO and sometimes not?

  6. If you are by fall putting something wrong in the XML files - both Springframework and Hibernate - (not syntactically because your schema will help you in this case) and you get some errors because of these things. Good luck and have fun trying to find them!

So what are your options?

  1. Accept those points above and be sure to know them best. Why not? You think, the combination of Springframework and Hibernate is still easier to use than EJB 2.x? More flexible than EJB 3.x? Yes, you are right. So, better to have a bad solution than no solution at all. Wow, you are what I call a pragmatic Java programmer.

  2. Use AndroMDAwith the Springframework and Hibernate cartridges. Oh my, I don't want to have something to do with MDA and UML. But what are the advantages of AndroMDA? No need to create those damn XML files - both for Springframework and Hibernate - by hand. You have a standard architecture which will be strongly followed by everyone in your team (if you have one) all the time. Nothing like sometimes with DTO, sometimes without DTO. But still you need to implement those DTOs! Yes, but at least you have the skeletons created for you.

  3. Build your own Dependency Injection and your OR mapper framework which are far better than Springframework plus Hibernate and don't forget at the end you should put them as Open Source products and release them through TSS news :-) So we all can admire your new products: oooh a new very easy framework but also it can support any complex situations (= all you can eat framework - and yes, Springframework is probably getting in this direction too. Of course you don't need to use everything but... we have that, we have this, ... You know what I mean).

It seems that using the option number 2 you will get back those "lightweight" Springframework with Hibernate (no XML files - they will be generated and we always use the same architecture everywhere)? It could be. With the price of using UML? Is this still "lightweight" or we just move our weight somewhere else? At the moment I prefer to use the option number 2 as I feel that I have lot more advantages in comparison of using the option number 1 or 3. But this should not be a general case and should be proven case by case!

Allright, at the end I admit that there are actually no "heavyweight" or "lightweight" frameworks, everything are relative to what exist and to what you know. In any case just take one of your options above and try to solve the problems you need to solve for your customers.

Happy coding and greets,

The most interesting discussion in year 2005 I've followed and joined sofar about MDA and the future of Java is this one at TheServerSide.com: Beyond Java. More than 760 threads... with many interesting and great ideas...

Thursday, August 17, 2006

Happy Anniversary Indonesia!
p.f. 17 August 2006 - 61 years

FYI: Java island is located in Indonesia... so if you want to learn Java language you need to know Indonesian language first :-)

This should be your first exercise...

Selamat Ulang Tahun Kemerdekaan Indonesia yang ke 61! Semoga selalu panjang umur! Untuk membaca pidato Presiden RI, silahkan untuk melihat artikel ini di KOMPAS: Pidato Presiden 17 Agustus 2006.
Jorn Bettin has written this comment on the "Standardisation of Model Driven Approach":

Also, beyond the realm of MDA, in relation to model driven approaches and the use of domain-specific languages in general, there is the question of when and to what degree will standardisation occur. Usually the more domain-specific a language can be made, the more value it adds. Yet, the closer a domain-specific language gets to capturing part of the competitive edge of an organisation, the less incentive for industry wide "standardisation".

From my point of view standardisation will only happen if we could get a direct positive impact from it. So, this is actually very pragmatic. A very good example is the use of AndroMDA. I could imagine that there are a lot of organisations out there - which are all the user of AndroMDA - which have standardised their "DSL" based on AndroMDA DSL elements like Entity, Service, tagged values, etc. Why? Because you get directly benefits from it. You can generate your codes easily when you use AndroMDA DSL.

So, just a specification will not help to standardise anything (or at least it will take very long = OMG). I always take the example of JCP (Java Community Process). You need 3 components to be able to standardise APIs:
- Specification
- Reference Implementation
- Test Compatibility Kit

... and this is not the case with OMG. No reference implementation, no test compatibility kit. IMO, Open Source project like AndroMDA could bring the standardisation a step further. Just like succesful Open Source projects Hibernate, Spring, Struts, etc. which are de-facto standard and not de-jure standard.

Wednesday, July 26, 2006

Welcome to Lofi model @ work Blog! Here I will post all my ideas and comments about software development... Stay tuned!