I wrote a post a while back, To ESB or not to ESB, about when to use an ESB and when not to. It got a fair bit of pick up, and I’ve had a lot of people reach out to me about it with specific use cases. It got me thinking it’s time to revisit the topic and provide more practical information about your options for integration.
This is a multi-part post where I’m going to start by defining what an ESB really is,
Identity Management solution already exist so why look to an ESB for the integration services. Like any solution you want an identity and access management platform that meets certain criteria such as sustainability, ongoing innovation, Integration capabilities and completeness of platform.
Why are the above issues relevant for an identity management platform? The reasoning comes from the fact that almost all identity management platforms are built up by acquisition and not innovation.
In previous posts explaining the enterprise integration patterns with example Mule configuration I have covered Content-Enricher and Content-based Routing patterns, today I’ll talking about the “Message Filter” pattern.
How can a component avoid receiving uninteresting messages?
Use a special kind of Message Router, a Message Filter, to eliminate undesired messages from a channel based on a set of criteria.
I was recently tasked with revamping the developer documentation’s information architecture to address reader comments that it was too hard to find needed information. I worked with a team of people at MuleSoft to make the new information architecture a reality, as well as to write some new content that helped explain Mule ESB 3 concepts for new users, as well as to improve the quality of key topics in the docs and to write a new document,
Often I get the following question. Should we solve this integration problem using and ESB, using BPM or both?
There is no unique or simple answer to that question, because it depends on the use case. But there is definitively a place for ESB and a place for BPM and they can and should leverage each other. Let’s take a look at how to answer the question above.
Mule 3.1 introduces a very useful new <logger> element that makes it easy to inspect the content and properties of your messages in Mule while building or debugging a flow. It’s also perfect for logging errors, info messages etc. Mule has always supported logging with the <log-component> but while working with the new orchestration capabilities of Mule 3 flows, we found a real need for fine-grained logging. With the new message processor architecture,
I had a great time at Qcon London last week, it really is one of the more forward thinking conferences out there for the enterprise. I gave two talks on ESBs and Enterprise Mashups so I figured I’d share the slides.
With so many integration points and applications of Mule, troubleshooting issues can be a daunting task for those just starting out with Mule. This post will provide a few tips on how to get to the root of issues you may encounter.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.