Fun with Camel Web Console

I've been playing with Apache Camel lately. I came across the camel-web console earlier but just got around to play with the source.

I find the project interesting because:

• It provides a Restful API to the routes, end-points, components ... , using Jersey jax-rs RI
• Uses JAXB for xml request content
• Content-type representation include Graphvic DOT file and even route definition in Groovy

You can send message (http POST to endpoint Restful URI), as well as create/modify routes interactively. Great for quick verification of concepts.

I do have a couple minor problems when building and running from source (881214):

• The version (1.3-dev) of maven-jaxb-schemagen-plugin does not exists on java.net Maven 2 Repo. I needed to add the Fuse Repo (http://repo.fusesource.com/maven2/) to the pluginRepositories.
• mvn jetty:run failed with ClassNotFoundException on sitemesh PageFilter. mvn jetty:run-war works

Also as a side note, here is an interesting comment on Mule and Camel:

"Camel will overtake Mule in the next couple of years, easily"

Spring OSGi Bundle App

This is more a reminder for myself.

Need a bundled jar (OSGified), try it here:

SpringSource OSGi Bundle App

Roo Karaf

Just came across Craig Wall post on Roo/OSGi Blueprint/Karaf. I've been fooling around with Roo lately and similar idea of deploying Roo code as OSGi bundle has occurred to me. In particular I like the Roo Rich-Domain-Object concept; the implementation using inter-type declaration and add hosts of functionality to the domain class ... and so on. But I don't care too much about the SpringMVC based web layer personally.

I have tried out some of the Roo tutorials. Since most of them are web-oriented applications, I got this wrong impression that Roo always create a WAR project. So the lingering question on how it is best to break a Roo project up into separate modules/artifacts (maven) has been in my mind for a while.

Then this article shed the light. When you first create a project in Roo, the packaging is a JAR, and the pom has minimal dependencies. The JPA stuffs are added to the pom when you create the first entity. Now if you package the project at this point, you still get a JAR. Now if you create any controller, Roo turn the project packaging to a WAR.

So, looks like it is feasible to just use Roo to build the Rich-Domain-Object and deploy it to an OSGi container. The complete picture would be to build a OSGi service layer on-top/side-by-side of the domain bundle exposing the service endpoint as jax-ws/jax-rs. And then a RIA web client consuming jax-rs services (may be something like the Sakai Fluid/Uxloader). 

Wave real-time collaboration, BPM modeling

This Gravity screencast demo providing real-time, cloud-based collaborative business process modelling within Google Wave. Gravity is a BPMN modeler created with GWT.

Leveraging the collaborative features of Google Wave, all business process modelling activities get propagated in near real-time to all other participants of the Wave. In addition, participants of the Wave can use all other features provided by Google and its developer community to enrich the collaborative modelling experience.

Very interesting demo and illustrates how real-time collaboration is going to change the way we do our business. This is just a gleam of the business implication of Wave as a collaboration technology.

Also see this related blog on bp-3.

Sling in Karaf

Sling in Karaf

Just found out that you can run Apache Sling in Karaf.


There is a contributed bundle, contrib/launchpad/karaf in Sling SVN. The bundle defines a simple Karaf features for Sling.


Instruction is included in README.txt in the bundle project.


Now you can create your custom bundles, create a features definition and use the Karaf Shell to manage your bundles during development. Say you are using declarative service, you can start and stop the provider(s) and test that the consumer(s) are behaving as expected.

OSGi rocks!

Building Servicemix 4

Has been working with the SMX4 source lately. A note about the build and run procedure; after building the project (mvn install) at the root level, the distributions (zip/tgz) can be found at ./features/assembly/target/ under the name apache-servicemix-4.1.0-SNAPSHOT.(zip|tar.gz).

It is not clearly stated from the instruction here, and is pretty outdated.

Rest and Enterprise Integration

Rest and Enterprise Integration

An interesting presentation RESTful Approaches To Financial Systems Integration.

First of all it is nice to know that it is not just me that ran into such integration hell in financial systems. 

I've adopt the REST approach in various projects (SILO) lately. Currently the REST APIs  are mostly consumes by UI applications only, which keep the UI nicely decoupled from the back-end. But the real benefit is that the resources exposed can be consumed easily by other systems, even by an Excel spreadsheet :- a revelation from the presentation.

I've also been doing quite a bit of dynamic programming, both on the server (Groovy,  Rhino) and the client side (Java Script). It is very simple to pull resources from the URL and process (render to some visual presentation) on the client. In an enterprise environment, simplicity is going to be a critical factor, because it encourage reuse. Until the developers from different LOB groups stop going about on their own way in accessing/processing the enterprise data, there will be no daylight for the integration hell.

In the presentation, Kirk talked about the flat-file and the database integration approach. Yes, they have been doing it for ages. The same piece of data may appear on 10 tables that belong to different LOB application. Oh, how I wish to replace those with just an URL!