Why

History Key

  • New content
  • Removed content

Recent Versions

Choose two versions to compare, or click the link to view it.

  1. 6. about 3 years by dbastin
  2. 5. about 3 years by dbastin
  3. 4. about 3 years by dbastin
  4. 3. about 3 years by dbastin
  5. 2. about 3 years by dbastin
  6. 1. about 3 years by dbastin
 

The motivation behind this project was born of the fact that we were dissatisfied with the way existing (open or commercial) Enterprise Application Integration (EAI) or data migration (ETL) solutions treat their users, for the following reasons:

  • A lot of cool functionality is often locked away behind the "Enterprise" edition.
  • The documentation and examples are often incorrect and contradictory. Even the simplest examples of some open source solutions we have tried are buggy under trivial loads.
  • Configuration is primarily in XML. Not cool. In our view, XML makes things harder to test and also maintain.
  • Quite often existing solutions are not written for easy testability. Integration end points need to be easy to "mock" as often times the only end-to-end solution is the production environment.
  • Existing solutions always treat inbound end points the same as outbound endpoints, making the configuration parameters confusing and often contradictory.
  • As far as we could tell, no existing solution is test driven.
  • Often there is no evidence of the code base being exercised with a continuous integration (CI) loop.
  • The existing source code is often a mess. Huge classes (>100 NCSS is big for us), and badly defined interfaces. We guessed that in most cases, coding standards are not automatically enforced.

We wanted to build a robust solution that addressed these concerns and we have already achieved some of these goals. Hopefully, our code continues to be maintainable enough for us to achievebuild themthe all.best integration solution on the planet.