Integration has been an enterprise challenge for a long time. In order to create the new products, applications, and services that businesses need to confront the digital revolution, you have to connect systems, data, and devices. There’s no way around it. Enterprises struggled with point-to-point integrations, which created a spaghetti-like mess of code, and then, for many years, companies found a better integration solution with ESBs (Enterprise Service Bus) and an ESB integration approach.
The principles of SOA were sound, it was the implementation that failed. Service-oriented principles should be the underpinning philosophy behind integration; and an enterprise service bus pattern, when delivered with lightweight solutions, has been proven effective.
Service Oriented Architecture (SOA) has been both hailed as a modern and agile approach to enterprise architecture and software development as well as deemed as a colossal waste of time and money.
An Enterprise Service Bus (ESB) is a set of principles and rules for connecting applications together over a bus-like infrastructure. ESB products enable users to build this architecture, but they differ in their methodology and the capabilities they provide. Mule as an ESB is the runtime engine of Anypoint Platform.
hMailServer is a free, open source, e-mail server for Microsoft Windows. It supports the common e-mail protocols like IMAP, SMTP and POP3.
Let’s have a look at a simple example of sending emails using hMailServer Administrator. Here, hMail administrative server is used for configuring email server on local machine. We need to do following 3 steps for sending emails via MuleSoft:
hMail server setup on local machine for setting up email server and creating domain and different usernames
There is a lot of interest in how Mule supports emerging patterns like CQRS (Command Query Responsibility Segregation), so I wanted to create a series of blog posts discussing an insightful approach. Over the course of the series so far, we described the initial problem at hand and how to solve it using CQRS and API-led Connectivity. Next, we designed and implemented the synchronous Query API application followed by the implementation of the asynchronous Command API application with a composable API architecture.
This all began with a very popular request: “We want to be able to throw an Exception from a flow”. The motivation for this is that it’s fairly common to run into “business errors” (errors not related to the handling and transmission of data but the data itself) which should actually be treated in the same way as a connection or system error (things like the remote endpoint is down).
Given the popularity of the request we decided to look into it and started by asking: “which are the use cases in which you would throw an exception?”.
If you have read the Mule ESB 3.6 release notes then you already know what I’m about to say, but just to recap, here we go…
A lot of effort was put in 3.6 to upgrade our libraries stack. Even though we try to stay innovative, it doesn’t make sense to reinvent the wheel all the time, so we use a lot of third-party libraries. However, keeping those up-to-date while maintaining our strict backwards compatibility policy is something that’s really difficult to do.
In spite of JSON’s reign as the king of API data format, XML still remains the exchange data format of choice for a number of systems. Any service exposing functionality through SOAP, and many application built years ago (or even nowadays) still depend on XML to share data – to such an extent that in April 2013 the W3C published a new spec for version 3.0 of the XPath, XSLT and XQuery standards.
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.