My blog is now moving here to macstrac.blogspot.com or you can subscribe to the Atom feed.

I've not blogged in the longest time, its quite embarrasing. Not being able to easily blog while on the road doesn't help; so I'm switching to a new hosted blog which will hopefully help me to blog more often. Fingers crossed!

Crikey long time no blog! Am still alive, just crazy busy but I really will try and blog a bit more often. (I've a stack of posts I should write if I get time).

I just wanted to say I totally love the new spell checking in Firefox 2.0. This along with the excellent delicious plugin make it the best browser around. Am liking the cute safari-ness of Firefox 2.0 :)

Thanks to Jez for arranging this we now have a place and location for Wednesday's geeky curry and beer night...


See you all there! :)

Jason van Zyl (Mr Maven) is over in blighty for almost 2 whole days so figured it'd only be fair to drink beer and go for a curry. I wondered if folks fancied a rapidly arranged early session of the London Java Meetup - or having an Xtc a day late :). Both Jason and I are up for beer, geeking out and eating curry in any order....

I love ActiveMessaging. It brings the power and elegance of messaging to the world of Ruby and Rails..
It supports transactions, queues & publish subscribe, load balancing, failover, clustering, optional persistence, browsing of queues and a full management front end. Its based on the Ruby Stomp client which works great with Apache ActiveMQ and its Stomp support. Great work guys!

I wasn't totally sure if this would ever happen but I'm glad to see that AMQP has been released with some interesting chat over on InfoQ and brian's blog. Am also looking forward to TSSJS Barcelona; time to get on that plane...

A common question I hear from customers and users is how fast can Apache ActiveMQ go and how to get the most out of it. It generally depends on a lot of factors but to help folks get the most out of it we've compiled an Apache ActiveMQ Performance Tuning Guide

Even if you're stuck in production using some other proprietary JMS provider and you're not yet ready to switch to Apache ActiveMQ - you can still find it incredibly useful when testing JMS. As this FAQ entry shows, you can create a full in-JVM JMS broker (to avoid a separate process) with disabled persistence (to avoid having to clear out queues before each test case) with really fast startup times and create your JMS ConnectionFactory using one line of code. Coolio!

For those with a MacBook you should download MacSaber immediately. It works OK with the trackpad on older macs but its not quite the same :). Enjoy! So I wonder how long before there's a web version so we can have saber duals over IRC... :)

Distributed systems, highly concurrent software and SEDA is increasingly becoming the norm. Frequently we need to orchestrate across multiple asynchronous events/processes and the code can get very complex very quickly.

The traditional approach up to now is to ditch your programming language and use a declarative XML language like BPEL to create an orchestration then use some graphical tooling to create your process.

While that is a totally fine approach; I've hit lots of use cases for orchestration where there were no web services; it was just POJOs and events were asynchronous and some form of messaging was used like JMS or Spring Remoting etc. Or others have hit their heads on the restrictions that BPEL offers and wanted to add Java inside the BPEL.

e.g. implementing master/slave protocols inside ActiveMQ is a pure orchestration problem and BPEL just doesn't seem a good fit since we really just want a pure Java solution; the XML / XPath / WSDL / BPEL just adds lots of leaky abstractions we don't really need never mind the performance hit.

Now I"m not advocating here that we throw BPEL away - its a very useful way of expressing web service orchestration. Just that there could be other ways of solving this kind of problem when the world is not just a sea of web services.

So after a day of brainstorming with Hiram a new small Java library came along - may I introduce you to BeanFlow. Its a tiny library, just a few classes and only depends on commons-logging and Java 5. (Yeah we should maybe switch to the JDK's logging abstraction but it seems like noone uses it)

Basically we started off thinking of the problem in a traditional jbpm, openwfe, OSWorkflow kinda way. Then we kept thinking "Lets make it simpler"; we can use Java code to do boolean logic, handle state, do looping, call functions, create objects, aggregation and composition. So what is it about orchestration that doesn't fit with regular Java code?

In the end we boiled it down to just one single concept, joins. Everything else a Java programmer is capable of doing in their sleep.

So we basically started out tackling the join problem; how do you fork off multiple asynchronous tasks then join on some condition. It turned out to be really simple to do in regular Java code.

Rather than repeat myself I'd urge you to surf the documentation or the javadoc. The interesting thing is from this humble base; tackling the join problem, we ended up writing a traditional Workflow model in 1 class along with added a number of orchestration features to Tiger's concurrent packages (java.util.concurrent).

The interesting thing is its up to the implementer of an Activity or Workflow to decide how to do state management and remoting. e.g. implement a workflow as a single Entity Bean using JPA to deal with persistence & caching & transactions. Maybe its a transient workflow. Or its an itinerary based workflow, where the workflow state is sent in a message to a remote node which then instantiates the workflow and executes its next step before progressing to the next node etc.

Its a really simple idea; I kinda can't help think why doesn't everyone do this. It reminds me a little bit of the dependency injection wave a few years ago with Pico and Spring; folks often thought, whats the big deal its just a constructor :). So BeanFlow is so simple, its really no big deal. But I can't help think that we might start to see more folks using plain old Java code rather than XML to write more orchestration logic. BeanFlow rocks! :)


BTW thanks to folks who've given us great feedback on BeanFlow so far - Rob, Sam, Hani, Gregor, Glen & Euxx. Sam's idea was particularly clever; use enums for the workflow step value then on startup you can verify that there is a suitable Java method for each step - such as to catch this bad workflow with a useful error message early.

Update Great feedback from Euxx on how we could add annotations to the enum of a workflow to further validate allowable transitions. Great idea!

Thanks to Gregor for these great pictures. For me JavaOne isn't about the sessions or the big announcements; its hanging out with folks at the Thirsty Bear and the Tangosol/Solarmetric/BEA/InfoQ party along with the other drinking sessions.

If you use Eclipse and you spend a reasonable amount of time hacking confluence wiki content then do yourself a favour and just install TimTam right now.

Notice how its got smart completion on wiki macros, syntax highlighting and you gotta love the tree view of the wiki - try dragging and dropping the trees to make your content easier to navigate. e.g. see the nice tree layouts of ActiveMQ, ServiceMix and XBean wikis.

Thanks Zohar et al for TimTam! BTW an eclipse update site would be nice ;)

I'm now back in body but not quite in spirit from JavaOne ;). Had the usual heaps of fun; it definitely seemed the best JavaOne for quite a while. Lots of interesting things going on for sure. Its particularly interesting seeing how the large vendors are starting to figure out their own open source strategy.

In othe news, fellow ActiveMQ and ServiceMix hackers and LogicBlazers, Rob and Hiram are now blogging now - finally! :) Am subscribed! They've both already started to talk about the really interesting stuff they're working on.

Via Brian

Meanwhile, Obie apparently leaked ActiveMessagingM-Del a13g. Woot! It's good to see Stomp getting wider usage.

Cool stuff all around!

Yay! Go ActiveMessaging! :). Having both a good Rails story and a good Ajax story which worth work great with JMS and .Net, the world of messaging is getting easier and more powerful all the time.

There's been lots of fuss over Ruby on Rails. Then we had Grails which looks cool too. Then there's a JavaScript port that could run inside the browser itself.

However I think I've seen the future, SQL on rails be sure to checkout the screencast. :)

Thanks to Duc for passing on this link - I'm now a convert. 34721 is the magic number...

I've been wondering for a while if we would get some consolidation in the IoC/Dependency Injection space so that component developers can adopt a single approach which would work in any Ioc/DI container such as Spring, HiveMind, EJB3, SCA, XBean etc. One of the goals of IoC/DI has always been that the container is invisible; though right now we tend to have different container/spec specific annotations and APIs so I've been wondering if we can come up with a single DI contract we can all adopt.

So my first braindump of a possible approach is called AnDI; Annotation based Dependency Injection and tries to unify the very popular spring style with EJB3 style; using standard annotations from JSR 250. Note that its a wiki so comments/edits are most welcome.

There's not a whole lot new here; its based on existing practices in various DI containers and is quite similar to the DI model in EJB3 - its more my attempt to unify the various camps to try get us all using the same contract going forward. Incidentally you can happily use annotations on Java 1.4 by using retrotranslator on your code. Incidentally it'd take probably an hour to implement AnDI in the standard Spring distro.

Update: BTW many thanks to Hani Suleiman for help creating to this document and giving feedback from the JSR 250 expert group.