Xebia Blog

I love Lisp. That’s right, ‘inefficient’, ‘hard-to-understand’, very much out of the ‘mainstream’, and ‘parentheses-obsessed’ Lisp. Unashamedly love it to bits.

Lisp is, of course, the most powerful language available. That’s right, what looks like an odd syntax actually is a terse syntax that allows for a great deal of configurability. Where you probably are used to formulating a combination of keywords and punctuation to get your ideas across, in Lisp you directly code in what amounts to other languages’ compiler-generated parse trees. List programs are lists (of lists of lists…) and Lisp’s parse trees are lists too and generating parse trees in code therefore is very easy.

(more...)

Filed under: Java
3 Comments

Everybody loves POJO's. Ever since Martin Fowler, Rebecca Parsons, and Josh MacKenzie coined the term back in 2000, the idea has taken the Java world by storm. Successful frameworks like Spring and Hibernate have centered on POJO's to make J2EE development a whole lot easier.

Since then JDK 1.5 came along and brought us annotations. And now everybody's going crazy again. And by claiming to support POJO's old-skool tech is now trying to become fashionable again.

Although I could not find an official definition of POJO, I think we can generalize from Martin Fowler's original definition that a POJO is not an EJB to a POJO is a Java object that is not tied to any specific framework, and therefore can be used by multiple frameworks in different situations and configurations. If you accept this definition, you'd have to agree this annotated POJO craze is silly.

(more...)

Filed under: AOP, Hibernate, Java, Spring
4 Comments

Over the past weeks I have been pulled into quite a few debates about SOA and, more specifically, about the “right” way to do it. And the definition of “right” gyrates alarmingly often towards the application of an ESB.

Every new computing trend elicits debate and any sizeable debate provokes vendors to aggressively position their –often already existing– products to take advantage of the customer’s interest in the hot, new trend. Of course, the energy pumped into ever inflating expectations inevitably finds a way out in the guise of confusion and disillusionment. The vendor hype surrounding ESBs has been especially effective to the extent that organizations that want a quick-fix solution (and don’t they all?) are sold on the idea that an ESB is the yellow brick road to “instant SOA”.

Here’s the gentle introduction: an ESB is not an essential part of SOA. Actually, leave any product in their glitzy shrink-wraps for now: SOA is about analysis and design, and not about technology.

Of course, there are a few basic components you’ll probably want to use get kick-started. But an ESB is not one of these “basic components”; in fact – and here comes the shocker to some – you should absolutely not use an ESB when starting with SOA because an ESB does not encourage good SOA. ESBs are integration solutions and integration solutions reinforce application silos while SOA is about tearing down those silos.

An ESB is a useful component in a services infrastructure as it is especially good for bridging to legacy applications. Many ESBs also support reliable messaging, asynchronous messaging, and several message exchange patterns, which are all useful capabilities -- just not in the initial stages of a SOA project. To put this in perspective, you might also want an orchestration engine at some stage in a SOA project -- but that too isn't where an organization should start a SOA initiative. All of this you just don't need when first getting started; an ESB should be a later-stage purchase.

Some parting words for all of the kind folk that tried to convince me of the essential nature of an ESB by drawing hub-and-spoke diagrams: a bus, by definition, is not a hub but a physically distributed set of federated hubs. It may start out centralized, but as the implementation evolves the infrastructure should allow for more physical distribution. You might want (and appreciate) to keep the bus’ configuration and control centralized however.

Filed under: Java
3 Comments

One of the things that changed considerably between Maven1 and Mvn2 is the way in which multi-module projects work. In Maven1 multi-module projects are implicit: A directory that contains subdirectories with project.xmls is a multi-module project. Using the multiproject plugin goals can be executed in all modules sequentially. In Mvn2 multi-module projects are explicit: The pom.xml must contain references to the sub projects. These references are relative links on the filesystem to directories where the subprojects pom.xmls can be found. A normal build will then invoke the build of the subprojects.

This is all very well documented on the Maven site and relatively easy to grasp, migrate and work with. What is not very easy or well documented is generating a decent site on a multi-module project. In this blog I will share my experiences on how this can be done with Mvn2.

(more...)

Filed under: Maven
3 Comments

There is one thing in software development that any developer should remember at all times: test, retest and test again. Any true Agile project revolves around testing. Test your code, screens, databases and test whether your user stories actually work. Nothing is left to chance and testing is done before everything else and after your done and your code will undergo regression testing when you're long gone. Pretty obvious, you might say, but some parts of testing are more obvious than others. Unit tests are pretty much covered, there are dozens of tools and frameworks for that, the same goes for screen testing. But one thing that still feels like new ground is functional testing (or acceptance testing).

In Agile projects there are a two constraints that apply to the 'traditional' way acceptance tests are performed: test first and agile (flexible) test cases. When working with dedicated testers, the developers need to work together with them as a single team. Using the 'test-first' approach, you need the input from the tester before you can start coding, otherwise you won't know when your work does what it needs to. One other problem that both developers and testers face is responding to changes. When the customer wants a new feature, you can't reply: "It was never build to do that!". We're agile, so we'll refactor the code if needed. Changes also apply to tests, requirements change and the software changes (database changes, user interface changes, etc.). So the tester needs to be able to deal with those changes.

There are a few things we can tackle. The magic word here is 'Fitnesse'. Fitnesse allows you to combine test case specification and execution on one page. This allows for very smart test cases, you could have something as simple as:

My test data:

The test:

(more...)

Filed under: Agile, Testing
No Comments

The Java Management eXtensions are really good to dynamically alter the behaviour of your application. The JMX API is standard in Java 5, but if you're stuck with an old version then you have to build your own or use an existing API. In WAS 5 you can easily integrate with the WebSphere API. This post will describe how to do that. I will do this by an example of how to get a JMX Managed Log4J configuration in WAS 5.

(more...)

Filed under: Java
No Comments