Open Source SOA or Open Source ESB

Many teams are actively refreshing their integration platform and evaluating open source ESB (Enterprise Service Bus) capabilities and benefits.  Fewer are evaluating their SOA strategy and establishing open source SOA (Service Oriented Architecture) platform infrastructure, metrics, and measurements required to guide teams towards agility and responsiveness.

Back in 2009, Dion Hinchcliffe described how SOA infrastructure “can indeed really help make the transition to SOA faster and easier”. He also described how the situation “is increasingly becoming a head-to-head competition between commercial and open source SOA solutions.”  Four years later, proprietary SOA products are further marginalized by open source SOA affordability, performance, and comprehensive capabilities.

 

When comparing ESB products, you will notice almost all Enterprise Service Bus products support enterprise integration patterns, deliver all required ESB features (i.e. web services, message transformation, protocol mediation, content routing), and offer a graphical development workbench. ESB Proof of Concept (PoC) evaluations are often won or lost based on the product’s extensibility and roadmap and vendor’s responsiveness and open source culture.   Dion mentions the open source SOA value in “The transparency of and ability to influence open source projects continues to be no small factor either as implementers struggle with more opaque less-frequently updated commercial products.”  In complementary technology spheres (e.g. Cloud, API Management) with increasing velocity, the transparency and influence value proposition is a business imperative.

 

While integration teams may use an open source ESB to rapidly integrate service endpoints, a broader value proposition is gained when integration teams use an open source ESB to eliminate service-oriented anti-patterns of isolation, uniqueness, and duplication.  To reduce service-oriented anti-patterns, teams desire to share and re-use assets, consolidate functionality, and conform projects to common standards.   To achieve these best practices, teams rely on an open source ESB to deliver the following required architectural attributes:

▪   Interoperability

▪   Abstraction

▪   Resource location virtualization

▪   Ability to scale and manage service

▪   Declarative policies and platform independent models

▪   Separation of concern

▪   Loose coupling

 

 

At a minimum the open source ESB implementation should encourage mediation flow re-use that decrease unique service endpoint definitions by bridging disparate protocols, message formats, and locations.

 

Strive to avoid complexity and inefficiency by specifying an optimal platform component mix, defining ‘the right tool for the job’, and developing scalable, agile integration solutions.   In a ‘selecting an open source ESB webinar, I propose an integration reference architecture decision framework, ESB use cases, and product selection guidelines.

 

 

When teams expect SOA benefits, but only rely on an open source ESB, many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams.

 

On your road to SOA, you will find an open source ESB is the first cornerstone of an open source SOA, and the other three SOA platform corners are filled with governance registry, message broker, and data service servers encourage SOA patterns and practices.

 

An open source SOA & Integration Platform guides integration teams towards implementing best-practice SOA patterns, overcoming SOA anti-patterns, and implementing SOA principles across message bus, registry, service monitoring, legacy applications, message queues, business service, and data service components.   For example, a governance registry promotes sharing schema models and meta-data to reduce duplicative implementations.  A list of platform components to consider incudes:

 

Open source ESB (Enterprise Service Bus): delivers content routing, protocol mediation, and message transformation that loosely couples service consumer from service provider.  An ESB adapts protocols, formats, and interaction styles to connect with any IT asset by implementing Enterprise Integration Patterns and Message Exchange Patterns

 

Open Source Governance Registry: store development-time and run-time policies, track dependencies, facilitate lifecycle management, encourage team collaboration, and guide the development process.

 

Open Source Message Broker: exchanges communications asynchronously or publishes messages for timely access by many subscribers.

 

Open Source Business Process Server:  standardize and automate human workflow, orchestrate long-running and stateful business process activity, and integrate applications with business process services.

 

Open Source Data Services Server: provides a lightweight, developer friendly, agile development approach for secure and managed integration across federated data stores, performing data transformation, enforcing data validation, creating composite data views, and exposing data as a services.

 

Open Source Business Rules Server:  brings the agility of shared business rules to your SOA Platform.  A single rule set across all service operations allows working memory state sharing across business rule invocations

 

Open Source Application Server: exposes multi-tenant service endpoints sharing business logic, data, and process across the entire IT ecosystem.

 

Achieving SOA governance and a SOA portfolio require focused strategies, consistent programs, and collaborative execution. Ad hoc SOA governance programs often fall far short of encouraging consumer adoption, tracking service consumption, and illustrating business value. Too often, there is little or no insight into service reuse and:

 

  • How to enable business functionality as an API or service
  • Who is writing re-usable APIs or services
  • Who is consuming APIs and services
  • How APIs and services are being used

 

You may have invested significant time and effort creating services.  Have you reached maximum service agility, adaptability, adoption? Are applications now easier to build? Is it time for a SOA portfolio review?

SOA portfolio review objectives include determining if the service-design methodology, service contract boundaries, and service coupling minimize portfolio redundancy and duplication while maximizing adoption.  To achieve SOA benefits, many forward thinking teams complement SOA governance strategies with API management to drive service reuse and maximize open source SOA success.

To achieve SOA success and reduce SOA anti-patterns, build a strategy, adoption plan, and infrastructure.   When considering open source ESB and an open source SOA over a closed source, proprietary ESB and SOA,  Ron Schmelzer’s advice to

“consider OSS and vendor solutions equally and evaluate them on an equal footing. You might be surprised to find what truly fits the bill for your SOA implementation needs. Check your FUD at the door. Make sure you aren’t losing an advantage by prematurely eliminating OSS from your SOA infrastructure mix.”

Ron made his recommendation three years ago, and the open source SOA value proposition is even stronger today. The open source SOA landscape has advanced and evolved since Jeff Davis wrote his open source SOA book.   Maybe it is time for us all to update our open source ESB and open source SOA story.