A question I get asked a lot is “what can I do with Mule?” For anyone who has looked at proprietary middleware vendors, ESB is often categorized as a mediation engine and nothing else. They do this to sell more products. Our philosophy is that an integration platform should do a lot more. An integration platform often becomes the central nervous system for applications to talk to, and respond to each other. As such, you need a platform that covers different use cases and provides and end-to-end solution for those use cases. So this question isn’t just about Mule. It’s “what should I expect from my integration platform?” Today, I’m going to introduce some scenarios.
Application or service orchestration is the process of integrating two or more applications and/or services together to automate a process, or synchronize data in real-time. Often, point-to-point integration may be used as the path of least resistance. However, point-to-point integration always leads to a complex tangle of application dependencies (often referred to as “spaghetti code”) that is very hard to manage, monitor and maintain. Application orchestration provides a) an approach to integration that decouples applications from each other, b) capabilities for message routing, security, transformation and reliability, and c) most importantly, a way to manage and monitor your integrations centrally. More…
A REST or Web services API layer offers a decoupled interface to data and/or functionality of one or more applications. It provides a common, language-agnostic way of interacting with an application. Web services APIs offer a well defined contract, called WSDL, that describes the services in terms of its operations and data types used to exchange information. REST APIs don’t typically have this contract; instead they are documented with client libraries for most common languages,
Some common examples of where an API layer would be used include these scenarios: a) you need to connect to a legacy application that does not have a REST API, b) you want to publish an API that enables your partners to communicate with your systems through a well-defined interface or c) you want to connect to multiple applications or data sources, combine the data, and send the results to your mobile application. More…
Legacy System Modernization
Over time, large organizations in many industries develop large and potentially complex IT systems. As new technologies emerge, the challenge for many companies is how to adopt these new opportunities while leveraging prior investments in existing infrastructure components. Some examples of these backend legacy systems include iSeries Mainframes, EDI messaging standards, custom integration scripts, or flat file interfaces over legacy transports such as FTP or file-based interactions.
There has been much written on this topic under the heading of “Service Oriented Architecture” (SOA), but even SOA doesn’t fully address the fundamental need to have a communication layer in place. This communication layer is responsible for exposing legacy systems with their legacy data formats and legacy transport protocols in a straightforward way to new consumers. More…
Enterprise Service Bus
An Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure. ESB products enable users to build this type of architecture, but vary in the way that they do it and the capabilities that they offer.
The core concept of the ESB architecture is that you integrate different applications by putting a communication bus between them and then enable each application to talk to the bus. This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus. The concept of ESB was born out of the need to move away from point-to-point integration, which becomes brittle and hard to manage over time. Point-to-point integration results in custom integration code being spread among applications with no central way to monitor or troubleshoot. This is often referred to as “spaghetti code” and does not scale because it creates tight dependencies between applications. More…
With SaaS and cloud becoming increasingly popular, a major problem is emerging – the “cloud silo.” Without proper integration, critical data is being locked up in information silos. This integration challenge has risen to become the #1 barrier for adoption of new SaaS and cloud technologies by end-users. Mule iON is an cloud-based Integration Platform as a Service (iPaaS) that enables developers to create simple packaged integration applications (iApps), to solve common cloud-to-cloud and cloud-to-premise integration problems. Mule iON is the easiest way for SaaS providers and integrators to solve the integration problem, knocking down the barriers for new customer adoption. More…
The landscape of integration has changed dramatically over the last couple of years, and is set to evolve much further. When looking for an integration/ESB offering, keep expectations high, for innovative integration products and mediation are just the beginning.
No related posts.