Java vs Ruby vs Clojoure

Java:

Time spent to think on what to write: 0

Time spent in writing: 60

Clojure:

Time spent to think on what to write: 30

Time spent in writing: 5 (if you’re good with brackets)

Ruby:

Time spent to think on what to write: 5

Time spent in writing: 5

ESB = Enterprise Service Bullocks

As you can see from the title I’m not a big fan of Enterprises Services Buses.

I’m not the only one, Jim Webber motivated already in these nice slides why, I’ll just add my impressions, as a newbie.

I’ve tried using serviceMix and I had a quick look to some other not OS vendors.

The first weird thing is that everybody is writing an ESB, you got so many choices, even the Apache foundation has two ESBs: ServiceMix and Synapse, must be an easy thing to write is so many companies are writing their own version: don’t assume knowing and writing code for one will work elsewhere!

The second very bad thing is maintenance. I had to change a little some JBI components written a couple of months ago, it has been painful, ServiceMix is all about XML configuration but you have no clue on what’s talking with who, which service is connected to what and why, you change a name and bang, nothing works anymore. Aweful.

You might buy one of those cool ESB (Oracle, Tibco, the list is long) offering a “nice UI” to drag and drop components, well I’m sceptical, never been a big fan of this type of tools (vendors too, to be honest).

Testability. Assuming that you care about testing how do you want to test this stuff? Writing long running integration tests?

I tried a little and I ended up pinging ServiceMix to understand if it’s up or not (it akes honestly ages to came up) and do some clever wait on JMS queues for messages in order to understand if the bus still works but hey… That’s not cool at all. It’s slow and breakes very easily.

Instead of an ESB you might consider the architecture proposed by Jim on the slides mentioned above, if that’s not enough (maybe you’ve got some syncronized JMS queues) you might try to have a look to Scala, I think (and I’ll try to write something more about it) you can write an ESB (only what YOU need, no XML, no bullshit) in a day or so with a couple of Scala Actors.

Maven Facts

1. Maven will never tell you which phases or goals are available in the pom, you have to guess or check the on-line documentation
2. Maven by default uses text files to dump the test execution results, if you want to see what’s happening on the console you have to call it with -Dsurefire.useFile=false
3. Maven can skip the executions of the tests (sometimes might be useful!) call it with -Dmaven.test.skip=true
4. Maven knows what inheritance is (and therefore claims that it’s object oriented… grrr…) so if you can’t find where some property is defined have a look up on the parent
5. Maven is based on XML but you won’t write as much XML as with Ant
6. Maven can create Eclipse project files and even download the sources for you (mvn eclipse:eclipse -DdownloadSources=true)
7. Maven downloads stuff from the internet  (#1 failure reason for 99% Maven presentations) but can be run in offline mode (if you had a sucessfull install previously), try mvn -o
8. Maven uses repositories, but since not all the libs in the world are in repositories you should setup a local repository (Archiva works well)
9. Maven uses repositories, but since you don’t want to hog all your company bandwith you should setup a local repository
10. Maven goes great with stuff like Hudson, Sonar
11. Maven build profiles are really cool
12. Maven is not silver bullet but I’ll never go back to Ant

You might want to keep an eye on these four opensource project…

• Apache ODE (Orchestration Director Engine) executes business processes written following the WS-BPEL standard. It talks to web services, sending and receiving messages, handling data manipulation and error recovery as described by your process definition. It supports both long and short living process executions to orchestrate all the services that are part of your application.

• JBoss DNA is a new unified repository system that is JCR-compliant and capable of federating information from a variety of systems. To client applications, JBoss DNA looks and behaves like a regular JCR repository that they search, navigate, version, and listen for changes. But under the covers, JBoss DNA gets its content by federating multiple external systems (like databases, services, other repositories, etc). This way, the unified repository content stays up-to-date and in sync, even though the external systems still own the information and existing applications still work. Plus, JBoss DNA sequences the content in the repository, extracting patterns and structured content that makes the repository more useful and effective.

• Convergence is a project aimed at integrating Computational Grids with In-Memory Data Grids (IMDG)

• SubRecord is a stack of enterprise aspects:

Data repository

• repository for storing flexible records in Amazon SimpleDB manner
• CRUD
• underlying storage is HBase – distributed storage for massive data hosting – Learn more…

Logs repository

• Collecting logs from many sources/interfaces like (remote) files, JMS, HTTP and dedicated API

API/interface

• RESTful services channel – Learn more…

GUI/Console interface

• GUI interface with many capabilities
• Trace/control Core module in real time

Tracing events (CEP/ESP)

• Registering logical events that can be identified and used in rules
• Rules can trigger specifing events to alert/trigger another events on some specific circumstances

Metrics

• Measuring time of invocations – record time/context before service is invoked and after
• Collect metrics reports for specific services

Processing (data)

• Collected data can be processed by scheduled, automatic tasks
• Unification of models can be done using adaptive processing
• Aggregating, normalizing,…

Session management

• Providing session token based authentication/authorization across multiple applications
• Authenticate once and be logged to entire federation of applications, SSO

Application monitoring

• Monitoring services
• Report failures

OSGI integration

• The application is supposed to be an OSGI bundle