Mule

[gaugat]

Has anyone used Mule (http://www.muleumo.org/) to add JMS support to the Spring Framework? I know that Spring now has JMS support. How does it compare to Mule?

[skleinei]

Gaugat:

Mule uses JMS as a communication channel. It has been using JMS before Spring supported JMS so they just used JMS directly.

As Spring now provides some JMS support, the Mule project may decide to use Springs JMS supprt.

-Stefan

[skroah]

I've given Mule a double look and each time I came away excited about the idea but a little less excited about its real usefulness to me right now. Any place that Mule would be extremely useful to me is a place that has to be occupied by a rabbit proof messaging and routing system and frankly Mule is a few meandering steps away from that. I'd like to see more focus in the short term on design refactoring, tests and docs not on new providers or even new features.

My requirements are a little unique though and I believe Mule is probably stable enough and well documented enough for a small competent team of developers who "need" the flexibility. I've had to spend considerable time browsing source just to get a general idea of some fairly large abstractions going on underneath the covers. I have a high level of tolerance for this but people I'd be pushing it on don't. Over a year ago when I pushed Spring, this wasn't so bad as there was a book, a website and a few developers who never seemed to take a break and have a beer.

ESB concepts don't seem to have any groundswell yet either, shocking in that EIP are pretty relevant to most companies. I can think of CapeClear and Mule and that's about it. It's also pretty clear to me that most enterprise developers are still pretty comfortable carving a lot of integration issues in stone and then walking away. I have requirements today that fit into an ESB world so I am pretty eager to see the concepts take hold more.

To answer the previous post. The Spring JMS support is just that JMS support. There is some primitive support for message conversion and for adding routing info., via the header, but it's not as complete as what Mule provides. If the Spring JMS support had added interceptor chaining to convert, massage messages and add routing info. it might be more close to what Mule provides or attempts to provide. This doesn't even touch on just swapping out a JMS endpoint with a Jabber or JXTA endpoint.

For now I'm using Spring and JMS, leveraging what I can of Spring JMS. In the near future I'd like to help Ross out and explore and flesh out the ESB stuff more. I have real world requirements today to route messages to Jabber, JMS, RMI, HTTP among others so the idea resonates with me pretty strongly.

[rossmason]

Skroah has explained the situation very well. The Jms templating in Spring provides a convenient way of sending and receiving Jms messages. Mule is focused on providing a ubiquitous messaging platform where messages can be sent and received over multiple transports such as Jms, http, smtp and tcp in a uniform way while handling all transformation and routing transparently for your business objects.

Spring and Mule are a powerful combination. The Spring container is very good at handling interactions between beans at within an application and Mule is very good at handling synchronous and asynchronous interactions over the network. Mule gives a lot of flexibility to allow your beans to send and receive objects over many protocols without your bean ever knowing it is taking part in a distributed application.

Also, Mule provides a convenient way to publish and receive Mule events in Spring by leveraging the ApplicationEventMulticaster. This means that spring beans can publish an event over any Mule transport using the publishEvent method on the ApplicationContext and can receive them by implementing an ApplicationListener. see (http://wiki.muleumo.org/display/MULE...ring+ Context).

"Any place that Mule would be extremely useful to me is a place that has to be occupied by a rabbit proof messaging and routing system and frankly Mule is a few meandering steps away from that. I'd like to see more focus in the short term on design refactoring, tests and docs not on new providers or even new features. "

There has been a lot of focus to test more varied messaging requirements as people raise them and we're in the process of locking down and documenting the routing features, which will be done for the next release.
There are also some new providers, namely udp and ip multicast and work has started on a jxta provider.

[Gideon]

Hi,

it is possiblem that someone can give me a example of something like this:

standalone Mule server with JMS support (ActiveMQ)
Consumer Bean inside Spring consuming JMS messages on a Topic
Publisher Bean Standalone and inside Spring publishing messages to a Topic

?

Thanks.

mfg Gideon

[wimv79]

Personally, I'm fan of the "proxyFactoryBean"-"ServiceExporter" combination, since this nicely integrates with aop and security.

You may wanna check out Lingo :

http://lingo.codehaus.org/
http://lingo.codehaus.org/Example

Wim Verreycken

[samineni6]

hai
iam new to mule
can anybody tell me how to work mule hello example on eclipse
reply me
bye

[soumyasree]

Hi,

We are facing a problem in handling Transaction Management, Our Project is developed on Mule ESB. We are using hibernate for persistance and we need to handle transactions using spring AOP.

We are able to see the transaction working in standard java project(Spring with Hibernate), but when we use the same in mule context, its not working as expected.

In short : On an exception in the code we need to roll back the data that is being inserted into the oracle tables, which is not happening as of now.We are following a declarative approach of spring and hibernate in handling transactions which sits on mule architecture.

Any example of how to configure this using mule will really help us. Thanks in advance,
soumya

[saddle.integration]

We proudly announce that Saddle goes Open source

www.saddle-integration.org

What is Saddle?

Saddle is an Open Source NetBeans-based graphical frontend to configure the Mule ESB. It allows you to graphically create, view, or edit the configuration files of Mule v2.x and 3.x.
You can even convert a v2.x configuration to a v3.x configuration.

Furthermore, it enables you to graphically map messages from different systems and to apply Java buisiness logic with all comfort you are used from your Java IDE.

Once the configuration work is done, Saddle allows you to administrate and monitor your runing Mule instances via any web browser.
This also includes the graphical tracing of messages through your integration schema.

Learn more about the features of Saddle in the documentation section.