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 Orchestration

Application OrchestrationApplication 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…

API layer

API LayerA 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,

including Ruby, Java, PHP and JavaScript. SOAP Web services have traditionally been adopted in the enterprise for publishing internal services as well as for exchanging information with partners in B2B transactions. On the Web, REST is the preferred way of publishing an API and we are now seeing this influence enterprise behavior.

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

Legacy System ModernizationOver 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

ESBAn 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…

Cloud Integration

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.

Follow: @rossmason@mulesoft

 

 

 

 

 

 

 

No related posts.

Interested in 3 days of knowledge sharing, hands-on labs, industry focused sessions, and plenty of networking? Register for the premier integration event, CONNECT London »

2 Responses to “Not your Grandfather’s ESB: Legacy Modernization, Cloud Orchestration, API Publishing”

Karl May 23rd, 2012, 1:47 pm

Love the concept – its a shame that Mule completely prices itself out of this use case though. To be used in this manner it has to be HA with large scalability and replicated Test / Dev environments.

At current premium support rates that leads to far too high ongoing cost structure especially if validated on a per business transaction basis

Ross Mason June 4th, 2012, 2:57 pm

Hi Karl,

What’s your use case? Feel free to ping me directly ross at mulesoft

Leave a Comment