camel in action的前言（翻译）

      语言是软件开发的一个重要方面。他们告诉我们一个程序应该如何表达。他们迫使我们编码时需要精确和无二义性的词汇。最后，他们将知识共享给开发者。不，我不是在谈论Java，Haskell，或PL / 1。我说的关于我们用于人和人之间交流的人类的语言，从开发者到开发者，或从最终用户到产品经理。长期以来，世界企业应用集成（或EAI，因为它是俗称的“整合的黑暗时期”）缺乏这样的词汇。每一个厂商提供的专有解决方案，这不仅与一个其他厂商的产品技术水平的服务进行集成，而且还用不同的语言描述的主要组成部件及其功能。这不仅造成了混乱，而且也是抑制创造一个可以让开发者可以跨企业集成的广阔空间的社区的一个关键。每一个使用或开发群组都被他们特有的语言所绑架。具有讽刺意味的是，集成开发者都面临着同样的“巴别塔”的问题（即相互之间没有规则和语义定义用于交流的问题）在他们的设计软件解决方案中！

        建立共同的词汇，解决知识共享和协作是企业集成模式的关键因素（EIPs）。每个这65种模式都有一个描述性的名称，它代表一种挑战集成空间的的设计方案。除了支持有效的沟通，这些词汇也提高了抽象层次，我们可以描述集成存在的问题及对策。

       一个共享的词汇是前进了一大步，但另一个巨大的进步，是我们无法想象当时我们的语言将促进发展的一系列开源即时通讯和企业服务总线（ESB）的产品。这些包含EIP词汇的工具直接在平台上实现了多种模式。通过Apache camel，分流模式直接在camel DSL中转化为的“分流”的元素。我们无法想象到一个更直接的翻译模式语言来实现平台。

       克劳斯和Jon通过向我们展示了如何使用camel模式语言撰写的真实信息解决方案带来了一个伟大传奇故事。这样，他们不仅涵盖像路由和转换的基本概念，而且还深入到开发过程中经常被忽略的部分，包括测试，监控和部署。他们找到了模式语言和camel核心概念的适当平衡，通过运行的代码，可以帮助您构建易于理解和强大的信息解决方案。

       我是ActiveMQ（一个开源的高性能的消息代理）和ServiceMix的原创始人之一（一个基于JBI和OSGi的开源ESB）。以我们正在做的这些项目和我们如何用它们为例，我发现企业集成模式正变得越来越重要;我们正在使用的模式的唯一区别是上下文和技术。

       已经有许多库和多年来的框架，以帮助整合。但频繁的企业集成模式背后的理念转变为只是这样一些复杂的类层次结构或对象连接在一起，这样往往丢失原来的意图和模式。该开发者从此被迫专注于底层的细节和一些复杂的类库API，失去大局观和模式。

       整合是很难的，一旦你开始按照一个途径往下整合东西时，代码可以非常容易爆发式增长;使用一种敏捷的解决方式来实现易于理解，沟通，适应，并保持集成解决方案是是至关重要的。

       因此，我们决定现在是时候了开发新的集成框架，以EIPs为核心，并试图提高抽象层次，使开发人员可以有一个简单的领域特定语言使用，使用非常简洁的条件，描述和声明是什么企业集成模式。使用约定优于配置的方法，开发者使用企业集成模式语言声明描述自己想做的事;这将是既快速又容易把事情做好，对于开发团队中的任何开发者也很容易（包括开发编写代码后，自己几个月！），可以非常容易地了解和适应的代码。

       有很多不同的地方使用EIPs，无论是一个独立应用、web service服务栈、像ActiveMQ企业消息代理，亦或是像ServiceMix的成熟的ESB，所以我们需要一个轻量级的中间件框架来让所有需要嵌入它的地方使用。我们也希望开发人员可以专注于企业集成模式，首先，不要迷失在不同的中间件的API和技术。

       我们也希望开发商能够使用任何他们希望的DSL（无论是Java，XML，Groovy，Scala，Ruby，或者其他的）然而，在运行时，仍然能够反思框架和理解所有正在使用的EIPs。他们将能够在项目生命周期中的任何点让团队核心模式，自动文档的模式形象化，甚至支持像在设计或运行时的企业集成模式的图形编辑。

       因此apache  camel诞生，并且我们看到的是越来越多的开发者在apache camel中找到了一个思路去设计和实现和维护企业集成模式导致了代码、社区、中间件的数量、技术、数据格式爆发式地增长。

       在这本书中，克劳斯和Jon依据apache  camel描述了企业集成模式和概念。然后他们带领你如何很容易理解地把他们的概念适用于许多真实生活场景并且提供可扩展和高效的解决方案，快速集成到和匹配你的需要。我希望你享受阅读本书，像我一样！