Besides some changes to existing building blocks, such as the event bus, which is now much more powerful, the [...]]]> Today, I finalized the 0.5 release of the Axon Framework. There is quite a number of changes since the 0.4 version. The 0.5 version is a major step towards production readiness of the framework.

Besides some changes to existing building blocks, such as the event bus, which is now much more powerful, the 0.5 version also includes some new features.

Read on to find out more.

New features

• Code restructuring. The package structure has been changed to better reflect the different architectural components Axon Framework provides. It should be easier to find the one you’re looking for.
• Command Bus. The command bus is added to Axon. It provides you the ability to explicitly define commands and dispatch them to your command handlers. Furthermore, the command bus provides you the ability to process commands regardless of their type using interceptors. This is useful for, for example, logging, authorization and correlation of incoming commands.
• JPA Event Store. The easiest CQRS configuration is on using full-consistency. That means everything should run within a single transaction. Since transactions over multiple data sources involve a huge performance penalty, Axon provides a JPA Event Store. Its performance is not as good as the FileSystem version, but is does provide transaction support.
• Easy switching between full-consistency and eventual consistency. You can easily choose to process all commands and related events inside a single transaction, or to handle events asynchronously. Choosing for consistency or high-performance is just a matter of configuration. No coding required.
• Per-event listener configuration of asynchronous processing. It is now possible to decide on synchronous vs asynchronous event processing for each event handler individually, just by adding an annotation. If you configure a transaction manager for your event listeners, Axon will process the events in batches and manage the transactions around them.
• Support for rolling snapshots. All event stores will automatically pick up snapshot events. Snapshot events are an important performance booster when aggregates generate a lot of events. Instead of reading all passed events, the event store just needs to read the last snapshot event and the regular events created since the snapshot.
• Transactional Event Processing. Configuring transactions in asynchronous event processing is now a lot easier. 0.5 includes a SpringTransactionManager you can use in combination with Spring’s PlatformTransactionManager.
• Major documentation update. The documentation has been restructured to make it easier to find what you’re looking for.

Maven Central

Where the 0.4 version required configuration of a repository in your project’s pom.xml, the 0.5 version doesn’t. All required artifacts are available in the maven central repository.

Workshop and professional support

We believe that the 0.5 version of Axon Framework is a major step towards production readiness. Therefore, JTeam has decided to provide professional support for the Axon Framework and organize workshops to get you acquainted with the numerous features and choices involved with CQRS.

The first workshop is planned for Friday May 21st in Amsterdam, The Netherlands. For more information, visit http://www.jteam.nl/training/workshop/cqrs-axon-framework-training-workshop.html.

Getting started

Want to get started? Visit www.axonframework.org and download the reference guide. That should contain enough information to get you started. If you still have questions, drop me a message.

This blog item gives you an inside scoop into the continuous integration environment at JTeam. You’ll learn about the why, what and how of continuous integration. The tools we use are mainly open source.

A number of years a go not many people new the term continuous integration. That [...]]]>

This blog item gives you an inside scoop into the continuous integration environment at JTeam. You’ll learn about the why, what and how of continuous integration. The tools we use are mainly open source.

Why continuous integration?

A number of years a go not many people new the term continuous integration. That has changed a lot. All people at JTeam know what it is about and all projects use an environment that is set up to actually do continuous integration. For those that do not know what continuous integration is and those that need a short recap, we briefly explain what we think continuous integration is. Let’s start with the definition from Martin Fowler:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly

Key to continuous integration is delivering high quality artifacts. It is not the silver bullet, developers still need to create great code, but using a good continuous integration process helps finding bugs. Checking your quality standards a long the way increases the effect. Of course extra actions are still necessary. You can think about actions like: manual code reviews, performance tests, functional tests, etc.

JTeam has been using continuous integration from the start. Recently we implemented the second version of our continuous integration environment. We introduced new tools, the process however stayed the same.

What do you need?

Continuous integration is about a lot of different things. So lets review them here. First of all, we have sources and a build. We tend to write a lot of java code, but we also need configuration files, html, style sheets, etc. With maven the way to structure your files has been standardized. We are using maven 2 for all our projects. Maven makes the life of a developer a lot more efficient while doing the normal tasks. Team leads and project leads also have reasons to implement maven in there projects. Maven has a lot of plugins that enable the projects spectators to see what is happening at the project.

Most of our projects are executed by more than one person, therefore a good source repository becomes very important. The source repository gives us more advantages, which I’ll talk about later. Within JTeam we have chosen to use subversion for storing the sources of the projects.

You can share sources and you have an automated build. Of course maven integrates very well with some IDE’s and it integrates kinda with some others. One of the important features of Maven is that it downloads dependencies from an online repository. Dependencies are libraries your project depends on. To limit network bandwidth, to store locally created libraries and to make libraries that are not available in an online repository accessible, you can connect to an internal repository. In maven this is called a proxy or a mirror. At JTeam we use a repository called Artifactory. Artifactory is a product from jfrog.

Having an automated build is not enough for good continuous integration. The automated build must be a continuous build. There are a lot of tools available that can give you continuous build. Some examples are : Hudson, CruiseControl and Luntbuild. We use Teamcity from Jetbrains to integrate all subversion checkins, run all the tests and every night run the maven reports. These maven reports are then published on a server so everybody can check the current status of the project. Teamcity is not open source and, there is a free license available, we use the commercial license. I explain later on why.

The following image gives you an overview of all services you need to have available for you to use in your project. The image shows more tools then I have discussed so far. They are not directly related to continuous integration, still they are very important for you when doing projects. Jira is about keeping track of requirements, issues and time estimations as well as time spend. Confluence is our knowledge base in which we document all our knowledge we gather while doing projects. Both jira and confluence are products from atlassian and very well known.

A last thing I would like to mention is a plugin for maven, the dashboard plugin. We are using this plugin now for a few projects and it gives some nice overviews. Graphical views of checkstyle, pmd, cobertura. When combining it with a database there is also the possibility of historical data, which is working very nice as well. You can find more information on the website including a lot of sample reports. http://mojo.codehaus.org/dashboard-maven-plugin/

Hai All, time for a news item completely different from most of the others. This time it is a personal blog item. For the last ten years I have been working for two big consultancy firms as a java consultant. Before I did java, I worked with c/c++, MS Access, COM/COM+ using VB, [...]]]>

Hai All,

time for a news item completely different from most of the others. This time it is a personal blog item. For the last ten years I have been working for two big consultancy firms as a java consultant. Before I did java, I worked with c/c++, MS Access, COM/COM+ using VB, html, javascript, etc. For around 7 years I have been working with java now. Next to java I was always interested in front end frameworks. In the beginning we called them dhtml, nowadays we call them ajax. If you have read posts of mine on this blog, you know I am interested in and experimenting with frameworks like: Google Web Toolkit, Wicket, jQuery and Flex.

Next to the front end frameworks I am also focussing on back technologies like OSGi and security. Therefore the articles on felix or OSGi in general and spring security are still very important to me.

The problem with my current (still for 1 week) and my previous job was the type of projects that we did. Always the old technology for the bigger companies likes banks and insurance companies. All the cool stuff was done in the evening. I also wanted something else than companies of thousands of people. I wanted more control of the company and not a lot of layers of managers on top of me. With my current employer I know I had lots of opportunities, but not the ones I wanted. Of course I will miss the people I have been working with. I did like all the things I did outside of my day to day work. But not enough to overcome the type of projects and roles that I did and got.

Concluding, I have learned a lot, had fun, but the projects we did were not really what I wanted. So, time for a change.

I have found my new challenge in a small company called JTeam. Well small, they are small in he amount of people compared to what I was used to. They do a lot of projects with all the technologies I am writing about on this blog. One thing I think was pretty cool is the answer I got when I asked for a mac to work on. The reply was that there were some issues with java 6 on the mac (not that I did not know). Since almost all there projects are on java 6 that might be a problem. Hmm, I am used to Websphere 5.1 and java 1.4. This is a cool problem to have. Luckily Apple has provided a beta release of java 6, so maybe I can use my own mac . JTeam gives me the opportunity to work on my technical skills as well as my (pre-)sales skills. Another great thing is the possibility to start writing a book. So who knows, maybe in the future I’ll do that as well.

If you have reached this far, the last thing I want to tell is that I will continue blogging. I think the number of items and topics will even increase. If you want to learn more about JTeam please check the website. To my (almost) old colleagues a warm thank you for the past two years and to my new colleagues, I am proud to be part of the team “JTeam“.