Our Thinking

Open Source ESB Search - Introduction

Posted by Duane Colley on Jun 25, 2013 9:39:37 AM

This post begins a series that will share Online’s Portland office's experiences as we re-platform from a Sonic ESB Architecture to a more open ESB architecture for our Justice and Public Safety solutions.

As the center of Online's Public Safety Practice, Portland has been delivering Progress Sonic message exchange solutions for nearly a decade.

Due to the nature of police systems, we often provide the same/similar set of features and services across many clients when we implement an integration architecture. These services center around business process mediation and workflows. They are not human facing, CRUD, or administrative systems. They are message-centric, java-based, middleware offerings.

What are you doing now? What changed?

There are several reasons we need to modernize/diversify the solutions we offer. Sonic has been sold to a different company, leading to uncertainty about its future. Also, because it’s closed source, licensing costs are too high across the board, but especially severe for small projects. At the same time, open source or subscription based alternatives have matured and help to commoditize the ESB market to a certain degree.

How to decide?

We consumed high-level functional and non-functional requirements from our Public Safety team. At this level, we want to assure any options at least provide for our high level requirements and don’t preclude any other solutions we may need to support down the road.

We want a healthy, open source-based, thriving community with open support models. We want to be able to enroll this support and/or offload these offerings to our clients or even work within a hybrid support model.

What are some of those business requirements?

  • In messaging middleware Quality of Service (QoS) defines, roughly, how important any message is within any exchange. The highest QoS delivery level is “once.” To achieve this level of service (that the message will be guaranteed to be delivered) across an exchange, redundancies must be in place to allow for complete system failures without losing any message. This support is required.
  • Government agencies require highly secure communications. FIPS compliant messaging is required.
  • While no message may ever be lost, we must also understand, at each point in all workflows, when a message flowed through any system and where the contents of that message (and headers) was at each point. This is the “auditing” requirement.

What are some of those client requirements?

  • We want high-quality support. If we want or need it. But not if we don’t want or need it. We want to pay as we go. Not buy upfront.
  • We want solid, long-term business propositions. We are not looking to help fund a startup. Current ESB offerings include many long-term players. We are risk averse here.
  • No surprises. Licensing should be simple and fair. Access should be simple and fair. Our ESB choice will reflect against Online Business Systems during operations for these systems. Everything should work as expected.

What are some of those development requirements?

  • We extended a key development credo to this endeavor: Implement the “simplest thing that can possibly work.” Fewer moving parts wear more slowly, result in higher quality, and allow for higher test coverage.
  • We want to start simple and build out more complex systems via a microkernel approach. This contrasts sharply with other Big Bang systems approaches.
  • We want to integrate early and often. We should be able to add business value on day one.
  • We want to be able to test. Outside of a running container. Outside of a certain tool. Before we write code. While we sleep. We want solutions that have been built using Test Driven Development.
  • We want to BYOC (Bring Your Own Code… and IDE, frameworks, test platforms, etc.). We enjoy our programming languages, our tools, our OS’s. We want to build and use components, not drag and drop. This additional level of control is sometimes critical in meeting requirements and/or deadlines/budgets.
  • We want declarative, metadata-driven cross-cutting solutions. Not imperative, extension-based, paint-yourself-into-a-corner offerings.
  • We want modern, optional tooling that plays well with other projects.
  • We want to step into source code. We want to “watch” code repositories for changes. We want to use the power of collaboration. Not closed, COTS, antiquated, expensive offerings.

What are the next steps?

  1. Enumerate market ESB offerings.
  2. Perform gap analysis between features and requirements.
  3. Score ESB offerings.
  4. Create System Architecture and Design.
  5. Validate System Architecture and Design.
  6. Start “Iteration Zero” and spike high-risk unknowns.
  7. Implement complete exchange through delivery for a mid-sized project!

In the next post, I will discuss our choice of the Redhat JBoss Fuse architecture as we begin to implement our first project with it.

 

Topics: Languages, Tools

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates

Recent Posts