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.
This post is by one of our MuleSoft champions, Antonio Abad.
Let’s start with a simple definition of both concepts:
“An ESB is basically the integration of the new and the old, providing a central place for the services, applications, and IT resources in general that you want to connect.”
“A microservice architecture (vs. the legacy monolithic architecture) is an approach to developing a software application as a series of small services,
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.
The core concepts of Mule ESB
The core concept of the ESB architecture is that applications are integrated by putting a communication bus between them and then enabling each application to talk to the bus.
What is hMailServer?
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
- Mulesoft project setup
- Outlook configuration for viewing mails
Steps for configuration:
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?”.
This is a follow up to the last post in which we discussed performance improvements on our XPath functionality obtained from the revamped XPath and XSLT support in Mule 3.6. This time, we’ll go through the same exercise but for the XSLT use case.
Just like with XPath, we worked with Luciano Gandini from the performance team. He came up with a test in which he measures the transactions per second (TPS) and latency of two XSLT transformations which inverts the tags of an XML.
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.