Mar 27th, 2008, 11:59 PM
My two cents
I went to a New England Java Users Group meeting tonight where Mark Fisher presented on Spring Integration. Aside from the presentation, I haven't used S.I. before, though I've used Mule and am starting to use JBoss ESB lately too. Given that I haven't used S.I., my feedback might not be worth much, but I want to offer it any way given that S.I. hasn't been released quite yet and so this is a critical time for feedback.
Wether S.I. is to be considered an ESB or not ... in any case, it basically competes with ESBs and ESB-like things. And so, it can learn a lot from strengths and shortcomings of those competitors. I already like a lot of what I see in S.I. compared to Mule. In particular, I was always annoyed that Mule forces the UMO concept with inbound & outbound routers, even when the scenario presented is just a chain of things that happen with no "real" central component (i.e. a Bridge UMO is used). In this case, S.I. (and JBoss ESB) are better, IMO. I also like the simplicity of the interfaces in S.I. (compared to both Mule & JBoss ESB). I haven't looked at your type coercion / transformation stuff but Mule did a good job in that department; not so much in JBoss ESB.
Since you don't have a release 1 yet, take care of important issues that are likely to have ramifications across the API if no care is taken now. For example, JCA transaction support, streamed message bodies, type information for the body, automatic transformation/coercion of message body types to that needed. Streaming in Mule seems to me like an afterthought.
Minutia: I'm not sure if there's much point to splitting MessageHeader from Message and in extending Message with subclasses. One class is simpler.
And finally, there is one feature that I'm hoping to see in ESBs. In JBoss Messaging, they have a really well done JMS bridge that handles several different QoS levels, plus message batching. It's general purpose, not JBoss messaging specific. The issues that the bridge has to deal with are similar to those that a well done ESB should handle. I submitted a feature-request for JBoss ESB that I hope is of interest here: http://jira.jboss.org/jira/browse/JBESB-1629
I've seen an example on S.I. where two JMS destinations are tied together. That is basically a poor-man's implementation, whereas the JBoss message bridge is the robust implementation that's probably perfect. See links on the issue I submitted for interesting references to this matter.