Apache Camel教程– EIP,路由,组件,测试和其他概念的简介

公司之间的数据交换增加了很多。 必须集成的应用程序数量也增加了。 这些接口使用不同的技术,协议和数据格式。 但是,这些应用程序的集成应以标准化的方式建模,有效实现并由自动测试支持。 企业集成模式(EIP)[1]中存在这样的标准,该标准已成为描述,记录和实现集成问题的行业标准。 Apache Camel [2]实现了EIP,并提供了标准化的内部特定于域的语言(DSL)[3]来集成应用程序。 本文对Apache Camel进行了介绍,其中包括一些代码示例。

企业整合模式

EIP可用于将集成问题分解为较小的部分,并使用标准化图形对其进行建模。 每个人都可以轻松理解这些模型。 此外,无需针对每个集成问题每次都重新发明轮子。

使用EIP,Apache Camel弥补了建模和实现之间的空白。 EIP模型与Apache Camel的DSL之间几乎存在一对一的关系。 本文使用一个在线商店示例来说明EIP与Apache Camel的关系。

用例:在线商店中的订单处理

通过实现一个小用例来介绍Apache Camel的主要概念。 阅读本文后,开始自己的项目应该非常容易。 最简单的入门方法是使用Maven原型[4]。 这样,您可以在几分钟内重建以下示例。 当然,您也可以一次下载整个示例[5]。

图1从EIP角度显示了示例。 任务是处理在线商店的订单。 订单以csv格式到达。 首先,必须将订单转换为内部格式。 由于商店仅出售dvd和cd,因此必须拆分每个订单的订单项。 其他订单项目将转发给合作伙伴。

1 :EIP集成问题的观点

此示例显示了EIP的优点:集成问题分为几个小的持久性子问题。 这些子问题每次都很容易理解和解决。 在描述了用例之后,我们现在来看一下Apache Camel的基本概念。

基本概念

Apache Camel在Java虚拟机(JVM)上运行。 大多数组件都是用Java实现的。 但是,这不是新组件的要求。 例如,骆驼标本组件是用Scala编写的。 Spring框架在某些部分中使用,例如,用于事务支持。 但是,在2.9版[6]中,Spring依赖项已降至最低。 Apache Camel的核心很小,仅包含常用组件(即,几种技术和API的连接器),例如Log,File,Mock或Timer。

由于Apache Camel的模块化结构,可以轻松添加更多组件。建议Maven用于依赖项管理,因为大多数技术都需要附加库。 不过,当然也可以手动下载库并将其添加到类路径中。

Apache Camel的核心功能是其路由引擎。 它根据相关路由分配消息。 路由包含流和集成逻辑。 它是使用EIP和特定的DSL实现的。 每封邮件都包含一个正文,几个标头和可选附件。 消息从提供者发送到消费者。 在两者之间,可以对消息进行处理,例如过滤或变换。 图1显示了消息如何在路由内更改。

提供者和使用者之间的消息由消息交换容器管理,该容器包含唯一的消息ID,异常信息,传入和传出消息(即请求和响应)以及使用的消息交换模式(MEP)。 “仅输入” MEP用于单向消息(例如JMS),而“输入” MEP执行请求-响应通信,例如基于客户端HTTP的请求及其来自服务器端的响应。

在简短解释了Apache Camel的基本概念之后,以下各节将提供更多详细信息和代码示例。 让我们从Apache Camel的体系结构开始。

建筑

图2显示了Apache Camel的体系结构。 CamelContext提供运行时系统。 在内部,处理器处理端点之间的事务,例如路由或转换。 端点连接了多种要集成的技术。 Apache Camel提供了不同的DSL来实现集成问题。

2 :Apache Camel的体系结构

骆驼语境

CamelContext是Apache Camel的运行时系统,并连接其不同的概念,例如路由,组件或端点。 以下代码片段显示了Java main方法,该方法启动CamelContext并在30秒后停止它。 通常,CamelContext在加载应用程序时启动,并在关机时停止。

public class CamelStarter {

public static void main(String[] args) throws Exception {
 
   CamelContext context = new DefaultCamelContext();

   context.addRoutes(new IntegrationRoute());
 
   context.start();

   Thread.sleep(30000);

   context.stop();

   }

}

运行时系统可以包含在JVM环境中的任何位置,包括Web容器(例如Tomcat),JEE应用服务器(例如IBM WebSphere AS),OSGi容器,甚至是云中。

领域特定语言

DSL通过使用更高的抽象级别来促进复杂项目的实现。 Apache Camel提供了几种不同的DSL。 Java,Groovy和Scala使用面向对象的概念,并为大多数EIP提供了一种特定的方法。 另一方面,Spring XML DSL基于Spring框架并使用XML配置。 此外,OSGi蓝图XML可用于OSGi集成。

Java DSL具有最佳的IDE支持。 Groovy和Scala DSL与Java DSL类似,此外,它们还提供了现代JVM语言的典型功能,例如简洁的代码或闭包。 与这些编程语言相反,Spring XML DSL需要大量XML。 此外,它提供了非常强大的基于Spring的依赖项注入机制和漂亮的抽象来简化配置(例如JDBC或JMS连接)。 在大多数使用情况下,选择纯粹是一个品味问题。 甚至可以组合。 许多开发人员使用Spring XML进行配置,而路由是通过Java,Groovy或Scala实现的。 路线

路线是Apache Camel的关键部分。 此处指定了集成的流程和逻辑。 以下示例显示了使用Java DSL的路由:

public class IntegrationRoute extends RouteBuilder {

@Override
 

public void configure() throws Exception {
 

from(“file:target/inbox”)
 

                      .process(new LoggingProcessor())
 


                      .bean(new TransformationBean(), 


                                  “makeUpperCase”)                                             
 


.to(“file:target/outbox/dvd”);
 
}

}

DSL易于使用。 每个人都应该甚至不了解Apache Camel就能理解上面的示例。 该路线实现了所述用例的一部分。 订单从外部来源放置在文件目录中。 处理订单,最后将其移动到目标目录。

路由必须扩展“ RouteBuilder”类并覆盖“ configure”方法。 路由本身以“ from”端点开始,并在一个或多个“ to”端点处结束。 在这两者之间,将实现所有必要的过程逻辑。 一个“配置”方法中可以实现任意数量的路由。

以下代码段显示了通过Spring XML DSL实现的相同路由:

<beans … >
 
<bean class=”mwea.TransformationBean” id=”transformationBean”/>
 
<bean class=”mwea.LoggingProcessor” id=”loggingProcessor”/>
 

<camelContext xmlns=”http://camel.apache.org/schema/spring”>
 
<package>mwea</package>
 
<route>
 
        <from uri=”file:target/inbox”/>
 


                    <process ref=”loggingProcessor”/> 


                    <bean ref=”transformationBean”/>
 


        <to uri=”file:target/outbox”/>
 
   </route>
 
</camelContext>
 
</beans>

除了路线,Apache Camel的另一个重要概念是它的组件。 它们为几乎所有技术提供集成点。

组件

同时,有超过100个组件可用。 除了HTTP,FTP,JMS或JDBC等广泛的技术外,还支持更多技术,包括来自Amazon,Google,GoGrid和其他公司的云服务。 每个发行版中都添加了新组件。 通常,社区也很容易构建新的自定义组件。

Apache Camel的最惊人的功能是其均匀性。 所有组件都使用相同的语法和概念。 每次集成,甚至其自动单元测试都看起来相同。 因此,复杂度大大降低了。 考虑更改上面的示例:如果应该将订单发送到JMS队列而不是文件目录,只需将“ to”端点从“ file:target / outbox”更改为“ jms:queue:orders”。 而已! (当然,必须先在应用程序中对JMS进行一次配置)

虽然组件提供了技术接口,但是可以使用处理器和Bean向路由添加自定义集成逻辑。

处理器和豆

除了使用EIP,您还必须经常添加单独的集成逻辑。 这非常容易,并且始终使用相同的概念:处理器或Bean。 两者都在上面的路线示例中使用。

处理器是一个简单的Java界面,只有一种方法:“处理”。 在此方法内,您可以执行解决集成问题所需的任何事情,例如转换传入的消息,调用其他服务等等。

public class LoggingProcessor implements Processor {
 
@Override
 
public void process(Exchange exchange) throws Exception {
 
System.out .println(“Received Order: ” +
 
exchange.getIn().getBody(String.class));
 
}
 
}
 

“ exchange”参数包含Message Exchange,其中包含传入消息,传出消息以及其他信息。 由于实现了Processor接口,因此您已经依赖于Camel API。 有时这可能是一个问题。 也许您已经拥有无法更改的现有集成代码(即您无法实现Processor接口)? 在这种情况下,您可以使用Bean,也称为POJO(普通的旧Java对象)。 您将收到传入消息(这是方法的参数)并返回传出消息,如以下片段所示:

public class TransformationBean {
 

public String makeUpperCase(String body) {
 

String transformedBody = body.toUpperCase();

return transformedBody;
}
 
}

上面的bean接收一个String,对其进行转换,最后将其发送到下一个端点。 再次查看上面的路线。 传入的消息是一个文件。 您可能想知道为什么这样做? Apache Camel提供了另一个强大的功能:从头开始包含150多个自动类型转换器,例如FileToString,CollectionToObject []或URLtoInputStream。 顺便说一句:可以轻松创建其他类型转换器并将其添加到CamelContext [7]。

如果Bean仅包含一个方法,则甚至可以在路由中将其省略。 因此,上述调用也可以是.bean(new TransformationBean())而不是.bean(new TransformationBean(),“ makeUpperCase”)。

添加更多的企业集成模式

上面的路线在处理输入订单之前,先使用翻译器EIP对其进行转换。 除了这种转换之外,还需要更多的工作来实现整个用例。 因此,在以下示例中使用了更多EIP:

public class IntegrationRoute extends RouteBuilder {
 
@Override
 
public void configure() throws Exception {
 
from(“file:target/inbox”)

.process(new LoggingProcessor())
 
.bean(new TransformationBean())

.unmarshal().csv()
 
.split(body().tokenize(“,”))
 
.choice()
 
.when(body().contains(“DVD”))
 
.to(“file:target/outbox/dvd”)
 
.when(body().contains(“CD”))
 
.to(“activemq:CD_Orders”)
 
.otherwise()

.to(“mock:others”);
 

}

}

每个csv文件说明一个包含一个或多个订单项的单个订单。 camel-csv组件用于转换csv消息。 之后,拆分器EIP分离消息正文的每个订单项。 在这种情况下,将使用默认的分隔符(逗号)。 但是,复杂的正则表达式或脚本语言(例如XPath,XQuery或SQL)也可以用作拆分器。

每个订单项目都必须发送到特定的处理单元(请记住:有DVD订单,CD订单和其他已发送给合作伙伴的订单)。 基于内容的路由器EIP无需任何单独的编码工作即可解决此问题。 DVD订单通过文件目录处理,而CD订单发送到JMS队列。

在此示例中,ActiveMQ用作JMS实现。 要将ActiveMQ支持添加到Camel应用程序,只需为camel-activemq组件添加相关的maven依赖关系,或手动将JAR添加到类路径中。 而已。 其他一些组件一次需要更多配置。 例如,如果要使用WebSphere MQ或其他JMS实现而不是ActiveMQ,则必须配置JMS提供程序。

除了dvds和cd以外,所有其他订购商品都发送给合作伙伴。 不幸的是,该界面尚不可用。 相反,使用Mock组件暂时模拟此接口。

上面的示例令人印象深刻地展示了如何在一个路由中使用不同的接口(在本例中为File,JMS和Mock)。 尽管技术差异很大,但您始终会应用相同的语法和概念。

自动单元和集成测试

自动测试至关重要。 但是,它通常在集成项目中被忽略。 原因是由于几种不同的技术而导致的过多的工作和很高的复杂性。

Apache Camel解决了这个问题:它通过JUnit扩展提供测试支持。 测试类必须扩展CamelTestSupport才能使用Camel强大的测试功能。 除了其他声明外,还隐式支持模拟。 不需要其他模拟框架,例如EasyMock或Mockito。 您甚至可以模拟分别通过生产者或使用者模板将消息发送到路由或从路由接收消息。 使用该测试套件可以自动测试所有路线。 值得一提的是,每种技术的语法和概念都相同。

下面的代码片段显示了示例路线的单元测试:

public class IntegrationTest extends CamelTestSupport {
 

@Before
 

public void setup() throws Exception {
 

super.setUp();
 
context.addRoutes(new IntegrationRoute());
 

}
 

@Test
 

public void testIntegrationRoute() throws Exception {
 
// Body of test message containing several order items
 

String bodyOfMessage = “Harry Potter / dvd, Metallica / cd, Claus Ibsen –
 

Camel in Action / book “;

// Initialize the mock and set expected results
 
MockEndpoint mock = context.getEndpoint(“mock:others”,
 
MockEndpoint.class);
 
mock.expectedMessageCount(1);

mock.setResultWaitTime(1000);

// Only the book order item is sent to the mock

// (because it is not a cd or dvd)
 

String bookBody = “Claus Ibsen – Camel in Action / book”.toUpperCase();

mock.expectedBodiesReceived(bookBody);
 

// ProducerTemplate sends a message (i.e. a File) to the inbox directory
 

template.sendBodyAndHeader(“file://target/inbox”, bodyOfMessage, Exchange.FILE_NAME , “order.csv”);
 

Thread.sleep(3000);
 
// Was the file moved to the outbox directory?

File target = new File(“target/outbox/dvd/order.csv”);

assertTrue(“File not moved!”, target.exists());

// Was the file transformed correctly (i.e. to uppercase)?
 

String content = context.getTypeConverter().convertTo(String.class, target);

String dvdbody = “Harry Potter / dvd”.toUpperCase();
 
assertEquals(dvdbody, content);
 
// Was the book order (i.e. „Camel in action“ which is not a cd or dvd) sent to the mock?

mock.assertIsSatisfied();
 
}
 

}

setup方法创建一个CamelContext实例(并执行其他一些操作)。 之后,添加路由,以便可以对其进行测试。 测试本身会创建一个模拟并设定其期望值。 然后,生产者模板将消息发送到路由的“ from”端点。 最后,一些断言验证了结果。 该测试可以与其他JUnit测试相同的方式运行:直接在IDE中或在构建脚本中。 甚至敏捷的测试驱动开发(TDD)都是可能的。 首先,在实现相应的路由之前,必须编写Camel测试。

如果您想了解有关Apache Camel的更多信息,第一个地址应该是“ Camel in Action”一书[8],其中详细介绍了所有基础知识和许多高级功能,包括每章的工作代码示例。 胃口大开之后,让我们现在讨论何时使用Apache Camel…

系统集成的替代方法

图3显示了三种集成应用程序的选择:

  • 自己的定制解决方案 :实施一个针对您的问题的单独解决方案,而无需将问题分成几小部分。 这可行,并且可能是小型用例的最快替代方案。 您必须自己编写所有代码。
  • 集成框架 :使用一个框架,该框架有助于使用几种集成模式以标准化方式集成应用程序。 它大大减少了工作量。 每个开发人员都会很容易理解您的工作。 您不必每次都重新发明轮子。
  • 企业服务总线(ESB) :使用ESB集成您的应用程序。 在幕后,ESB通常还使用集成框架。 但是还有更多功能,例如业务流程管理,注册表或业务活动监视。 通常,您可以在图形用户界面中配置路由和诸如此类的东西(您必须自行决定是否可以降低复杂性和工作量)。 通常,ESB是一个复杂的产品。 与使用轻量级集成框架相比,学习曲线要​​高得多。 但是,因此您将获得一个非常强大的工具,该工具应该可以满足大型集成项目中的所有要求。

如果您决定使用集成框架,那么在JVM环境中您仍然可以选择三种不错的选择:Spring Integration [9],Mule [10]和Apache Camel。 它们都是轻量级的,易于使用和实施EIP。 因此,它们提供了一种集成应用程序的标准化方法,即使在非常复杂的集成项目中也可以使用它们。 可以在[11]中找到这三个集成框架的更详细的比较。

我个人最喜欢的是Apache Camel,这是因为它具有出色的Java,Groovy和Scala DSL,并结合了许多受支持的技术。 Spring Integration和Mule仅提供XML配置。 如果我需要Mule的某些独特的连接器来连接专有产品(例如SAP,Tibco Rendevous,Oracle Siebel CRM,Paypal或IBM的CICS交易网关),则仅使用Mule。 如果仅需要集成广泛的技术(例如FTP,HTTP或JMS),则仅在现有的Spring项目中使用Spring Integration。 在所有其他情况下,我将使用Apache Camel。

尽管如此:无论您选择这些轻量级集成框架中的哪个,都可以通过轻松的工作轻松实现复杂的集成项目,这将带来很多乐趣。 切记:繁琐的ESB通常具有太多的功能,因此也有太多不必要的复杂性和工作量。 使用正确的工具完成正确的工作!

Apache Camel已准备好用于企业集成项目

Apache Camel已于2011年7月庆祝其第四个生日[12],它代表着一个非常成熟且稳定的开源项目。 它支持在企业项目中使用的所有要求,例如错误处理,事务,可伸缩性和监视。 也提供商业支持。

最重要的收获是其可用的DSL,几乎每种可考虑的技术都有许多组件,并且事实是,无论必须集成哪种技术,都可以始终使用相同的语法和概念(甚至用于自动测试)。 因此,应该始终将Apache Camel视为重量级ESB的轻量级替代品。 通过下载本文的示例开始。 如果您需要任何帮助或更多信息,可以找到一个很棒的社区和一本写得很好的书。

资料来源:

参考: Apache Camel教程– 有关Java EE / SOA /云计算博客的JCG合作伙伴 Kai Wahner的EIP,路由,组件,测试和其他概念介绍


翻译自: https://www.javacodegeeks.com/2012/05/apache-camel-tutorial-introduction-to.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值