Stefan Norberg: Event-Driven Architecture
Another Swedish contribution to the conference was Stefan Norberg, enterprise architect at Unibet, a Swedish gaming company. He explained, very nicely, how you can use a domain EDA instead of simply reproducing the spaghetti architecture in an ESB. A domain EDA is an architecture where sub-systems or SOA services are loosely coupled using only asynchronous domain events and an event bus. Services produce and consume domain events on the bus and the event specification becomes the contract between producers and consumers. A very positive outcomes of this is the freedom that comes from loose coupling. For example, to add a new service, no changes are needed to the existing structure. On the downside, all events must be considered public APIs. For example, removing a field is difficult, bordering on practically impossible.
Stefan also related how they tried to build on this foundation by adding CEP, BPM, and BAM. (I heard once that too many three-letter abbreviations could give you periodontitis so this part of Stefan’s talk was a bit dentally hazardous.) Complex Event Processing (CEP) are services that listen to certain patterns in the stream of domain events. When it finds a pattern matching one of its configured rules, it emits a new domain event (a “meta” event) that other services may react to. One example was that nobody had used a Visa card from France in the last 5 minutes, which could indicate a payment problem. The promise of Business Process Modelling (BPM) is that business people could model and update their business processes without the need of technical staff and redeploys. Personally, I have my doubts about it’s usefulness, but I won’t rule it out. Finally, Business Activity Monitoring (BAM) aims at giving real-time reporting, or rather a dash board, of the status of business. According to Stefan, implementation of all these advanced services were greatly simplified by the EDA.
One thing I did not like was the way Stefan, without a glimpse of consideration, described how they automatically gave back some money to players who have lost big. This, of course, is to keep them playing, feeding a probably rather severe gambling habit. I am very doubtful as to the morality of this action and with Martin Fowler’s words ringing in my ears from yesterday I left the room with a bad taste in my mouth.
Nat Pryce: Test-Driven Development of Asynchronous Systems
I continued on my asynchronous journey by attending the “How do you test that?” track, lead by Steve Freeman. The speaker for this session was Nat Pryce, whom has written one of my favourite software development books, Growing Object-Oriented Software, Guided by Tests, together with track host Steve.
The problem of integration testing asynchronous systems is that your tests become really slow and fragile. In an asynchronous test, control returns to the test before there is a result. How should we find the result? How long should we wait? Some of the issues you may run into are flickering tests, false positives, slow tests, and messy tests. Nat’s clever solution was to use what he referred to as probes to query a common state between the tests and the system under test. The probe looks for the correct state (whatever that is). If the success condition is not met, we poll again. Finally, we fail on timeout.
I think that the examples Nate showed were great. It really proves that you can test-drive almost all kinds of systems; you just have to think about it a little harder. But just remember that there are issues with this kind of (integration) testing. For one, they are still slow. The probe idea is sound I think, but the test would still run for several 10ths of a second, far too long for a unit test. Secondly, the amount of work you have to do to get the tests working were in all related cases pretty extensive. And thirdly, it is a difficult task to keep the tests running. They have to be very isolated unless they become brittle. I believe that these kinds of technical integration tests are useful, but I would not overuse them. The big chunk of the test-driving effort should still lie with the unit tests.
Rod Johnson: Extreme Java Productivity with Spring Roo and Spring 3.0
Australian Rod with his thunder voice and Spring fame did a good job of making me wanting to try the Roo experience, although he suffered from a massive jet lag.
Spring Roo is a Rails-inspired code generation tool from SpringSource. Mainly, it is a way to generate an application, tests and its “plumbing” from a domain model. The generated code is heavy on aspects, but it’s all Java and you can edit stuff you don’t want Roo to manage and it will leave it alone. It is a round-trip generation model, where Roo will keep its internal model in sync with what you write. Generating from the model is done using the Roo shell with great context-sensitive assistance. I did find the commands pretty long, though. Since SpringSource now has control over Grails as well, they have some decent Rails-inspired tools for Java web development now.
That evening we had the opportunity to take a look at the Canonical office in London, on the 27th floor of a tall building near the river. Canonical is the company that creates the Linux Ubuntu distribution (with community help, of course) and supplies related products and services. I knew Matt and Mark from a course last year so it was great to meet them again. After a round to their local pub, Matt took us to a wonderful curry house just south of the river. The food and company was excellent. Thanks Matt! If you have any interest in Linux at all you should check out Ubuntu.
Summary of the Conference
All in all QCon London 2010 was a good conference. The service level was excellent. Food and drinks were good and free. I think the premises were large and slightly confusing. A few planning mistakes were made (like Fowler’s session). Also, there was very few places to sit during lunch. I really hate eating standing up. Content-wise, the conference was a bit of a disappointment to me. In only a few sessions did I feel that rush of inspiration that you seek from this kind of thing. For me, the best part was spending time with my bright and pleasant collegues. Or maybe I’m just getting old and can’t hack it anymore. ;)
Glad to have you with me this far. Thanks for reading!