FUSE ESB

My company IONA provides support on Apache ServiceMix via a distribution called FUSE ESB available from the Open Source IONA site.

What's in FUSE ESB right now? Well, it's roughly a distribution of ServiceMix trunk. This implies that FUSE ESB is released ahead of the Apache ServiceMix distribution (the latest release is 3.1.1, whereas FUSE ESB is based on 3.2).

Why are you using the latest trunk instead of the most stable branch? Well, mostly because our customers needs some of the latest features available. We take great care of what is in our Fuse branch: we do not necessarily backport all new stuff from trunk. We may also add some specific customer needs inside our own distribution, features that are not present in the trunk version.

So is that a fork? Certainly not :-) We have always supported Apache ServiceMix and we will continue to do so. But our customers have specific needs, so we may need to do custom development or have custom branches for them to fullfill these needs. Over time, we put the features that we consider generic enough back to the community. But this level of support can not be provided in a community driven environment such as the Apache Software Foundation. Let alone the fact that our customers often require privacy regarding their issues or their specific needs, environments and projects, so that it becomes difficult to use the open mailing lists of the community.

So is that a closed source version? No. The Apache License would allow that (quite the opposite of the GPL), but this is not what we aim for. Our process is quite open: as an example, I've recently developed an AsyncBridge EIP pattern for FUSE ESB (see the issue) that will certainly be contributed back to the community...

Hopefully, this blog entry will clarify a bit the IONA policy with respect to the Apache projects it supports and the relationship between FUSE ESB and ServiceMix. Feel free to download it and give it a try...

Comments

Unknown said…
Guillaume

Can you point me to a good tutorial?

I would like to learn more,

Tom Debevoise
9:58 PM
Anonymous said…
Tutorial is at http://incubator.apache.org/servicemix/users-guide.html
4:02 PM
Unknown said…
but this tutorial isn't to FUSE, i don't succed a first example..
11:51 AM
Guillaume Nodet said…
As I explained, FUSE ESB is a branded distribution of Apache ServiceMix, so tutorials will apply to both without any problems.
1:37 PM
Unknown said…
mr Nodet, i install Fuse ESB.
if you follow a guide not succeded with succes nothing example. infact the FUSE, in fuse do only copy sa in hotdeploy.. same thing if you use maven..so i find a guide for fuse!!
12:12 PM
BRAUN Brice, le californien said…
I'am presently studying the opportunity of using esb on some products.

As I was surfing on servicemix website, I only found updates whose dates were previous November 2007 except in the forum. Moreover I am reading in this blog you "left" servicemix (but hopefully you did not go too far away ;)).
So I am a little worried, could you tell me if the community around the product is as active as it was before?
5:17 PM
Guillaume Nodet said…
Hi Brice! Can I know what in this post lead you to think I left ServiceMix? I'm working full time on it :-D Is that because I did not had any time to blog recently?
5:59 PM
BRAUN Brice, le californien said…
I'm happy to be wrong then :)

It's indeed because of the updates and most of all, I misunderstood the title working for IONA.

TY for your work
8:29 PM
Post a Comment

Popular posts from this blog

Apache Karaf

ApacheCon was really interesting this year! Recently, a lot of people have expressed a real interest in ServiceMix Kernel , our generic OSGi distribution for server side applications. We've been discussing moving this subproject into Apache Felix for several reasons: raise the visibility and awareness on ServiceMix Kernel attract a broader community Several Apache projects are planning to use ServiceMix Kernel as their container: this includes Apache James , Apache Directory and Apache ActiveMQ . The Apache Sling community is also willing to contribute to this effort along with some other groups like the OPS4J project. During this discussion, a name as been proposed by Jamie Goodyear: Apache Karaf . A carafe is a small container used for serving wine and other drinks (http://en.wikipedia.org/wiki/Carafe). In similarity to the name the Kernel allows applications to be more easily handled, and improves their characteristics (much like a bottle of wine left to breath in a dec
Read more

Camel Endpoint DSL

Image
Camel Endpoint DSL One of the new features of Camel 3.0  is an Endpoint DSL.  This new API aims to provide a type safe replacement for the URLs that are used in Camel to designate the consumer or producer endpoints.  These URLs provide 3 things: the scheme of the URL identifies the component to use, a unique name or id for the endpoint, and a set of parameters to customize the endpoint behavior. Here is an example of an FTP consumer endpoint definition: from( "ftp://foo@myserver?password=secret& recursive=true& ftpClient.dataTimeout=30000& ftpClientConfig.serverLanguageCode=fr" ) .to( "bean:doSomething" ); There are several drawbacks with such constructs : no type safety, bad readability and no simple completion. So we now use the meta model, which is currently extracted from the source using an annotation processor and written in various JSON files, to generate a fluent DSL for each endpoint.  The same
Read more

ActiveMQ Pooling

Over the past weeks, I spend some times load testing ServiceMix and ActiveMQ . I discovered two things: * ActiveMQ broker is currently single threaded for a given JMS connection. The main effect is that if you send messages from several threads on the same connection, all threads will be processing sequentially (well, not exactly, but they will all be processed by a single thread on the broker side). * ActiveMQ Resource Adapter does not pool sessions and producers: this means that sending a single message with Jencks using the JMS best practices in a J2EE environment (create a connection, create a session, create a producer, send, close all) will take three consecutive roundtrips to the JMS broker and is very CPU intensive for the broker (at least, when using JMX). The first problem is mainly apparent when using persistent messages and there are a few things than can be used to speed up things (see the LogicBlaze tuning guide for ActiveMQ). However these tuning tweaks are no
Read more