Open Might Be the Best Step for SOA
The general attitude of business organizations towards Service Oriented Architecture, or SOA, has changed significantly over the course of the term's existence. When SOA first made its appearance as a buzzword in the early 2000s, enthusiasm for the new model quickly reached a fever pitch. Companies with big infrastructure problems were so sure that SOA was the fix they'd been waiting for that they were willing to pour millions of dollars into massive top-down SOA initiatives with long, hazy ROI timelines.
By 2009, things had changed. Service Oriented Architecture was no longer the belle of the ball, to say the least. The vast majority of the sweeping top-down SOA initiatives that had been launched with such high hopes had failed miserably, leaving companies millions of dollars in the hole and years behind on architectural improvements. Some studies estimate that as few as 20% of the SOA initiatives launched at the peak of the model's popularity had never been fully realized.
Why SOA Still Matters
In today's competitive economy, efficient, intuitive automation and integration of business processes is always a mission critical concern. SOA isn't just an architect's pipe dream - it's an essential step forward that organizations must make if they want to stay competitive and agile despite growing complexity in their business model and IT footprint.
Implementing SOA means solving two sets of problems - SOA technical problems related to the actual architecture, and SOA strategic problems, which describe the day-to-day process by which the SOA plan will be carried out.
Does Open Source ESB Make Sense for SOA?
The advantages offered by ESB architecture have made it the de-facto strategy in the industry for SOA-enabling integration scenarios involving more than three systems.
The success of ESB has resulted in a flood of ESB "products," both open source and proprietary. When choosing an ESB solution, it is important to remember that ESB is not a product - it's an architecture.
Some proprietary ESB "products" are in fact re-factored versions of the same vendor's legacy broker-model EAI software. These products maintain strong links to the top-down SOA model, and as such, often favor interoperability with the vendor's other offerings (SOA registries, web servers, databases), and suffer from performance, integration, and tooling problems if third party components are added.
What Makes MuleSoft's Mule ESB Different?
MuleSoft is known for its robust API-led Connectivity solutions. To enhance the connectivity solutions, MuleSoft with open source projects like Mule ESB leverage the power of open standards and open source communities to avoid these issues:
- Mule ESB is designed with stability, re-usability, and modularity in mind - open source developers rely on the strength of individual pieces of code to provide easy points of entry for other community members.
- Mule ESB is agnostic to format, and compliant with standards - Mule ESB supports more data formats and protocols than any other open source ESB, including support for both proprietary formats and open standards. Additionally, unlike some open source ESBs, which sacrifice interoperability in favor of compliance with a single standard, Mule ESB supports all major open messaging standards, but is able to pass data in native formats, transforming it or enhancing it only as needed, for improved performance and simplicity. ESBs that subscribe to only one standard require all data to be "normalized" into a standard-compliant format, adding an additional step to the integration chain.
- Mule ESB's open source community is made up of hundreds of users and developers with real-world integration problems who rely on Mule to solve them. If a developer needs to support an obscure format and writes a new connector to do so, they can then contribute the connector back to the codebase. Likewise, if a problem is found, while MuleSoft offers 24/7 fast-response support for enterprise clients, often times the bug will be quickly identified and fixed by the community. This ensures that Mule ESB's components are always streamlined to solve real world problems in an efficient, stable manner.
Glossary of SOA Buzz Terms
What is SOA?
Service-Oriented Architecture (SOA) is a design paradigm and discipline that helps IT meet business demands. Some organizations realize significant benefits using SOA including faster time to market, lower costs, better application consistency, and increased agility. SOA reduces redundancy and increases usability, maintainability and value. This produces interoperable, modular systems that are easier to use and maintain. SOA creates simpler and faster systems that increase agility and reduce Total Cost of Ownership (TCO). More on SOA from Gartner Research's summary on service-oriented architecture (SOA) here.
What is an ESB?
An Enterprise Service Bus (ESB) is a software architecture model used in providing a platform to developers for designing the communication between the software applications. In today's world it means connecting systems that can talk securely and effortlessly from cloud to premise without having to be re-constructed each time a system is modified or replaced.
What is iPaaS?
It’s no secret that cloud integration is one of the main challenges facing today’s enterprises. In order to meet the growing need for secure and reliable cloud integration solutions, several vendors have started to offer integration services known as 'Integration Platform as a Service' (iPaaS). Want more? MuleSoft provides a good summary of Gartner Research's in-depth overview into iPaaS here.
What is SaaS?
This definition thanks to a leader in the world of SaaS, Salesforce. Software as a Service (or SaaS) is a way of delivering applications over the Internet—as a service. Instead of installing and maintaining software, you simply access it via the Internet, freeing yourself from complex software and hardware management.
SaaS applications are sometimes called Web-based software, on-demand software, or hosted software. Whatever the name, SaaS applications run on a SaaS provider’s servers. The provider manages access to the application, including security, availability, and performance. More from Salesforce on SaaS right here.
