Once upon a time, I couldn’t do without my middleware. To make my application resilient and scalable, and to allow it to talk to everything else in the enterprise, I had no choice but to stand up an ESB in my architecture. It was literally in the middle of everything I did. Then, when I moved to the cloud, my world began to change.
All CIOs share a common priority: ensuring development teams have the skills and experience to apply best practices that support the organization’s needs effectively. Certification is one the most important qualifications to help evaluate a team’s skill set, and are considered a strategic tool for building a foundation of expertise to drive both individual and team success.
Certifications are growing in importance
Research shows that training alone is not enough.
A short while back I wrote a piece, Why Message Queues Suck. The gist of the piece is that for the same labor and overhead required to implement and maintain an inter-service notification architecture using message queues, you can just as easily implement inter-service notification by Direct To Endpoint communication. (Please see Figure 1 below.)
As you might imagine, the piece caused quite a stir, particularly on Reddit.
Keeping up to date with the latest versions of NodeJS comes with several advantages including access to the latest language features (as seen in Node Green) as well as performance improvements that can have a direct impact on your web services. The benefits are even more prominent in the context of a microservice architecture where there’s a constant need to orchestrate and maintain different versions of NodeJS across many instances.
That being said,
Application program interfaces (APIs) have become extremely valuable to hugely successful companies such as Facebook, Twilio, and Expedia. They are, in fact, a strategic investment for any business. You can offer your APIs as your entire business, have your APIs become part of your core business, or even use other companies’ APIs to build your business – you get the idea.
Because they are so important,
In this post, I will show the differences between chaining flows with VM transport versus chaining flows with flow reference. When I need to divide my Mule flows into reusable units, I often break them into smaller flows and then chain them together in a main flow.
Flows can be chained together using flow-refs or using VM connectors; most recent examples use the flow-refs. However, flow-refs are a Mule 3 addition and in Mule 2 VM connectors were used to chain flows.
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?”.
We are very happy today to unveil today not one, but two major updates across the MuleSoft developer experience: 1.) our brand new documentation platform, and 2.) a totally revamped developer forum.
A brand new doc platform
You can have the greatest technology in the world, but it means nothing if you don’t have fast, intuitive, and eminently searchable documentation by its side. When you couple those two things together,
If you have read the Mule ESB 3.7 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.7 to upgrade our libraries stack. That effort actually began in 3.6, and although the list of upgraded libraries is not so big as it was on that release, it’s somehow more significant given that we upgraded some dependencies that we held very close to our hearts and core.
Tired of googling and reading about OData without having a chance to play with it? Get happy then, this post is for those pragmatics like me that enjoy learning by doing rather than dealing with theory. If you enjoy the trial and error process, I can assure you that you won’t be disappointed.
What is OData?
Open Data Protocol (OData) is an open protocol to allow the creation and consumption of queryable and interoperable RESTful APIs in a simple and standard way.