To achieve efficient implementations with Async APIs, the need for new protocols and exchange patterns has become critical. Which is why we are excited to announce the release of the Mule WebSockets connector!
A WebSocket is a bi-directional, full-duplex, and persistent connection that is established on top of your existing HTTP infrastructure. Now, you no longer need to open new ports, modify firewalls, routers, or support new protocols.
Streaming in Mule 4 is now as easy as drinking beer!
There are incredible improvements in the way that Mule 4 enables you to process, access, transform, and stream data. For streaming specifically, Mule 4 enables multiple parallel data reads without side effects and without the user caching that data in memory first.
Ok, so now that you’ve read about the new HTTP connector in Mule 3.6 and seen the cool demo that Dan put together it’s my turn to drill down into some of the more interesting details – why we built the new connector,
We put a lot of effort in Mule 3.3 to improve error handling in Mule ESB. One of the most common requirements during error handling was the ability to continue processing the same message that was being processed at the time of the exception. And that’s why that is the default behavior for the new exception strategies shipped with Mule 3.3.
Another very common use case was the need to differentiate between handled and unhandled exceptions within a flow.
Since Mule is built on Java and Spring, it has native integration capabilities to invoke Java and Spring components. In this tutorial, we shall learn how to pass request received from HTTP endpoint on to Java component and receive response.
Please complete Hello World lesson from last week before proceeding further.
In the vast majority of cases, HTTP requests are processed synchronously: the operation that the client wants to perform on the targeted resource is executed by the same thread and the result is returned right away. This is usually done by connecting the HTTP layer directly to the service layer.
This post demonstrates a slightly different approach where HTTP requests are first sent to a messaging layer, then processed by dedicated agents whose responses are eventually returned synchronously to the client that is blocked waiting.
As discussed recently in this blog, web streaming APIs are a hot topic. One goal of streaming APIs is to reduce polling and replace it with resource efficient event-driven content distribution mechanisms.
With PubSub Huddle meetup happening in London today (unfortunately, I couldn’t go), it seems like good timing to tell you what we’ve done with one of the recently proposed protocols, PubSubHubbub (aka PuSH).
In my last blog post I showed a simple flow to retrieve an RSS feed periodically, split it and send each RSS entry via eMail. The solution has one major drawback, though: once the Mule application is restarted, Mule has forgotten which feed entries have already been sent. The RSS feed is retrieved again and another bunch of eMails is sent.
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.