For several years, I've been mulling over the idea of creating a DSL for configuring Mule. Indeed, there is a treasure trove of pre-existing transports and connectors for Mule, which is very compelling for anyone building connected applications (which, nowadays, is probably everybody). Unfortunately developers can be put off by the XML-based DSL used to configure Mule, and thus may pass the opportunity to leverage all this available goodness.
As Rx is gaining traction, more and more developers are getting accustomed to its concepts and primitives. With this mind, and knowing that Mule is at core an event processing platform, it dawned on me that instead of creating a DSL that would mimic the XML artifacts (which are Mule specific), I'd rather create bindings to allow using Mule's essential moving parts via Rx.
In summary, RxMule adds a number of classes to RxJava that make it possible to observe:
- Mule inbound endpoints from traditional transports, including global endpoints and endpoints defined by URIs,
- raw message sources, like the new HTTP Listener Connector,
- Anypoint Connectors message sources.
Observable<MuleEvent> instances from different sources. A MuleEvent is what Mule creates and processes.
It wraps a MuleMessage which contains the actual
data and meta-data that's being processed.
You can read more about the structure of a MuleMessage here.
The following demonstrates an asynchronous HTTP-to-Redis bridge, that only accepts one request per remote IP:
So why don't you take RxMule for a spin and see if it helps you achieving your application and API integration needs: with Mule at its core, I bet it will! Bug reports and pull requests are welcome at GitHub.
