Thursday, December 28, 2006

[About] Old and New Year and Blog Issues

Our SE Blog is now "on the air" since August, nearly half a year, and we have more than 40 articles of good quality as also regular readers confirmed. So I am personally quite happy with the first months of this Blog.

For now, I wish all my colleagues and our readers merry christmas and a happy new year. I hope for more good articles from all contributors in the new year and for a steady growing community of readers.

However, as nothing is perfect, and I try to improve this Blog; so I am happy about comments and suggestions (maybe as a comment to this entry).

Currently (as there is a new version of released) I am reshaping the design of our Blog. The new design is clearer I think, better readable (width is not restricted) and most of all, we use two new features from the new Blogger: the better navigation, that allows to easily check older articles and the new labels to restrict the view to articles of a special category.

Tuesday, December 26, 2006

[Pub] The iBatis Persistence Framework

A Brief History of Persistence

Starting around 2000, (Java) developers figured out, that accessing relational databases using "plain" JDBC is a rather dowdy activity (a pain in the ass, one might call it too); moreover the differences in object-oriented design and relational databases got too obvious. As a matter of fact around that time a significant number of (partly Open Source) projects were founded to deal with that problem in creating frameworks to map between objects and relational databases in a more elegant way (Hibernate, Castor, Cayenne, OJB, Torque, DODS, Toplink, iBatis just to name a few). Interestingly enough, object-oriented databases were at that time already more or less dead (except for some niche-applications) and XML databases were not yet dead and still sounded promising at that time ;-)

All this was and is accompanied by different emerging and disappearing standards (Jürgen Höller got into details here).


However, today it seems, that we are in a settlement phase. At least in the last one or two years persistence in Java was nearly used synonymously with Hibernate, which is actually a pity. Hibernate is a powerful framework, no doubt, but by good reason recently many developers detect that using a full-blown O/R mapping solution like Hibernate is not always the best idea: Some go even so far to claim, that the whole idea is more or less flawed. The critics claim - and it might not be completly wrong - that frameworks like Hibernate let you start rather smooth, but the longer the project runs, the more you are fighting to get Hibernate do what you actually want it to do (performance, functionality). And to do so, you are forced to work on a low level with Hibernate, HQL, SQL, the Caching framework and whatnot, trying to get mappings so that the desired SQL statements are produced or injecting SQL statements into the framework and workarounds like that.

I do not want to go into details here, I just want to recommend the article from Ted Neward here. What I really do not like about this article are the references and comparisons to the Vietnam war, which is rather stupid and mostly unnecessary in my opinion, still, you can easily skip that part and go to the technical part, which is definitly recommended to consider.

...and the Rest of the Crowd?

So, is there a life after or instead of Hibernate? I think yes: first of all there are very interesting alternative persistence technologies like db4o based on direct persistence of object-graphs, which was also presented at our persistence event and I wrote a brief article recently. But also on the "relational side", there are several alternatives, most prominently I want to mention iBatis.

Apache iBatis

iBatis goes a very different way and is actually not an object/relational mapping tool it is better described by saying it is an object/SQL mapping framework. To get a iBatis application running you need the following artifacts:
  • A relational database and a schema (tables, views, stored procedures, constraints ...)
  • iBatis configuration file
  • iBatis SQLMaps
  • recommended: Spring as DAO framework
The configuration is best done using the Spring-Framework SQLMaps support (the iBatis team meanwhile stopped the development of their own DAO project and recommend to use Spring), check out the details there. Then you define mapping from objects to SQL statements like so:

So actually for all operations SQL statements have to be written (typically insert, update, delete). Depeding on the statement iBatis maps the parameter (parameterClass) or the result (resultClass) to objects. This is done automatically (in simple cases) or by creating a mapping declaration, where the mapping can be adjusted in details. In the Java DAO class the statement can be easily executed using the Spring template:

getSqlMapClientTemplate().update("updatePerson", person);

iBatis Learning Curve and Transparency

It is obviously not possible to introduce a framework thoroughly in a BLOG article, but I want to emphasize, that the learning curve for iBatis is a rather easy one plus the documentation is good and the mailing list helpful. For a skilled developer it should be possible to have the first iBatis application running within some hours.

An additional advantage (and disadvantage, depending on the point of view) is the fact, that using iBatis it is practically always clear, what's happing behind the scences (in contrast to full blown O/R mappers like Hibernate). Or as Bruce Tate expressed it:
"iBATIS is a JDBC helper framework that gives you some of the benefits of OR mapping and usage, but without as much risk."
But this reduction to mapping objects to SQL statements might also be a clear drawback, when you wish to gain a "better" abstraction from the relational database.

What now?

Which framework to choose is actually a difficult decision. But one is for sure: taking Hibernate "by default" is most probably not the best decision. Hibernate & Co are powerful but very complex integration frameworks with a high level of abstraction, defining own query languages to be learned; and a lot of mapping and configuration options are offered, which you better want to know in detail. iBatis on the other hand is very straightforward to learn and use and allows to easily use all functionality of the database without using framework "backdoors".

I suggest to have a close look at the options and decide carefully, but one thing is clear: Hibernate should only be used, if a skilled Hibernate (Castor, OJB, ...) expert is available or one person of the development team is willing to spend some amount of time to get one. Otherwise severe issues can be expected, probably at a time close to software delivery.

And not to forget: iBatis is available for Java, .net and Ruby and works with all databases (in the Java context) where a proper JDBC driver is available.

For more information about iBatis I suggest also the following resources:

Wednesday, December 20, 2006

[Tech] db4o License Issues

As a follow up to our "Java and Persistence" event, I received interesting news about a third licensing option for the object-oriented database db4o: Up to now, db4o was only available in a commercial license and in a GPL license. This GPL license has the significant drawback, that a usage of db4o most probably "infects" the own project and forces it to be under GPL license as well.

This is due to the fact, that db4o has a unique API, hence the project that uses db4o is derivative work. This fact obviously is very dangerous for Open Source project that do not intend to use the GPL license.

However since recently there is a third licensing option as can be read in the January Newsletter of db4o:
"db4o has issued a third licensing option for free/open source projects that want to embed db4o but do not want to (or are not able to) license their derivative work under the GPL in its entirety. This initiative aims to proliferate db4o into many more open source projects by providing compatibility for projects licensed under Apache, LGPL, BSD, EPL, and others, as required by our users." (quoted from the newsletter)
From my point of view, I am happy about this decision, as it makes a pretty interesting technology more accessible for a broader community of developers.
Read more about Persistence in the Java Environment, also covering db4o in the report following our "Java and Persistence" event.

Tuesday, December 19, 2006

[Event] Software Engineering for Everday Business - Review of the Third Event

The third Event in the series "Software Engineering for Everyday Business" dealt with modern architecture styles and development best-practices. Marcus Demolsky and I held the presentation. The key concept of this lecture was "patterns". I see patterns as best-practices on different "levels":
  • Software Build (best practices)
  • Testing
  • Enterprise Architecture
    • Coordination
    • Service Oriented Architecture
    • Event Driven Architecture
  • User Interaction Patterns (e.g., "Web 2.0")
  • Enterprise Application Patterns
  • User Interface Development (e.g., MVC)
  • Application Level Design Patterns
Hence we started refreshing the knowledge of design patterns (like Oberver, data access object, facade...), layered architecture, SOA, EDA, aspect oriented development and finally ideas and examples of "Web 2.0".

After this rather theoretical part, we showed some practical examples on frameworks like Spring and Maven. Particularly Maven is very interesting as a manifestation of build-automation best-practices. Eventually I ended with a round up and outlook to the last event in the series dealing with quality assurance and talked about automated testing and profiling using Eclipse TPTP.

Please check out the resources website for a download of all presentations.

I hope to see many of you at the last event in January!

Wednesday, December 06, 2006

[Pub] Testing Event-Driven Business Processes

With new paradigms for software development and software architectures (such as agile software development, service-oriented architectures, IOC containers, etc.) companies are able to respond faster to changes in a business environment. For our sense and respond system SENACTIVE InTime, we developed a testing framework that supports these paradigms by being able to test the correct behavior of event-driven business solutions. With our testing framework we show that software tests can be used to make model assertions for business processes.

We introduce process test specifications, which allow users to define simulation settings, test components, assertions and test scripts in order to make a business process testable. A detailed description can be found in the journal article on testing with event-driven business processes.

In the paper, we also outlined how the proposed concepts can be used for the testing of WS-BPEL processes. Nevertheless, we realized that testing BPEL processes is very hard since it is difficult to intercept process requests and responses. Alone the way BPEL requests and responses are structured (message parts etc.), it requires a great deal of work to handling/integrating this information into a testing framework.

Nevertheless, a BPEL process description includes also some very useful information which can be used for generating realistic input data. In our testing framework, we use a simulator which extracts the control flow of the BPEL process for generating event sequences.

Our testing framework is part of a larger, long-term research effort aiming to making testing an integral part of the management of business processes. Part of this work is the development of a test bed for testing, simulating and benchmarking business process solutions. One of our key ideas to improve our current testing framework is to use a standardized language for the definition of process test specifications.

[Event] Software Engineering for Everday Business- Review of the Second Event

The second presentation of the series “Software Engineering for Everyday Business”, initiated by UBIT of the Wirtschaftskammer Wien took place on November 30th. The content of the presentations focused on modeling and model driven software development.
Modeling was covered by introducing the basics of software modeling, a modeling language, and a modeling method. Model driven software development was covered by an introduction to the concepts, primary approaches, and tools as well as by a case study.

Part 1: Modeling

Understanding the concept of software modeling is simplified by drawing analogies to models as used in everyday life. Models as used by architects are specifically interesting as they play a role similar to software models in requirements elicitation, design, and documentation. Software modeling brings in an additional difficulty as the proper level of abstraction is not always obvious because, in fact, source code can be considered as just another kind of model.

The Unified Modeling Language (UML) is the de-facto standard for object-oriented software modeling. It provides a set of modeling concepts and notation supporting many typical modeling requirements. Despite the advantages of UML it is often beneficial to use additional modeling techniques to cover, e.g., graphical user interfaces and database design.

In classical software processes, it is recommended to use modeling in a rather waterfall-like manner, leading to an overhead of maintaining consistency of models, changing requirements, and system implementation. Agile modeling is an approach to employ modeling within an agile software development process, emphasizing the constructive and communicational aspects of modeling rather than creating documents to be handed off. This way, it better copes with the fact that models are abstractions which are subject to misunderstanding - unless the abstraction process were explicitly specified, which is exactly the subject of model driven software development.

Part 2: Model Driven Software Development

Model driven software development attempts to raise the level of abstraction and consequently the productivity of software development. These improvements are feasible based on the fact that many tasks of software implementation pertain to rather routine activities of handling a complex infrastructure which is often similar for a set of projects. Several approaches to model driven software development have been proposed, Model Driven Architecture (MDA) being the most well known. MDA aims at abstracting from details of specific implementation platforms thus potentially allowing to "model once and build anywhere".

Tool support is crucial for model driven software development. Several tools supporting MDA were presented and analyzed according to a catalogue of criteria. The state of practice is that many different tools exist, each having a different focus and supporting different aspects of UML. Standardization, the original aim of OMG when specifying the MDA, is only partly implemented. Therefore, the decision to base a project on a certain MDA tool is critical as it establishes a very strong dependency between the project and the chosen tool.

A case study, which was conducted using the MDA tool ArcStyler, revealed some of the details that need to be taken care of in an MDA project. These include the tool's support of modeling techniques and target implementation technologies, the time required to understand the tool, the need to work with different levels of abstraction, i.e., model and code, and others. The conclusion was that MDA tools can offer a considerable increase in productivity which, however, is not for free.


Most questions were triggered by agile modeling and by model driven software development. It was discussed how agile modeling and agile methods in general could be implemented in practice. Regarding model driven software development, most questions revolved around practical experiences and available tool support.


To dowload the slides from this presentation as well as from the last event please go to the dedicated download page.

This text was written by Gerhard Kramler and edited by Alexander Schatten