Apache Camel 2.2.0 用户指南：企业级集成框架解析

4星 · 超过85%的资源需积分: 10 88 浏览量更新于2024-08-01 收藏 2.67MB PDF 举报

"Apache Camel 2.2.0 用户指导手册" Apache Camel 是一个强大的开源集成框架，基于已知的企业级集成模式，具有强大的Bean集成能力。这个框架允许开发者实现企业集成模式，进行路由和中介规则的创建。 Camel 提供了多种实现方式，包括基于Java的领域特定语言（DSL）或流利API，通过Spring为基础的XML配置文件，以及Scala DSL。这意味着无论是在Java、Scala还是XML编辑器中，用户都能在IDE中获得路由规则的智能补全功能。 Camel 的一大特色是使用URI，使其能直接与各种传输或消息模型如HTTP、ActiveMQ、JMS、JBI、SCA、MINA或CXF Bus API协同工作，并且能够处理“文件”、“FTP”、“SMTP”等传统协议。这一特性使得Camel具备了高度的灵活性和可扩展性，可以在多种场景下无缝集成不同的系统和服务。在第2章“快速入门”中，用户将了解到如何快速开始使用Camel，包括安装步骤、构建第一个Camel应用以及基本的路由定义。第3章“开始使用”详细介绍了如何设置和运行Camel项目，涵盖了基本的概念，如路由、组件、数据类型转换以及错误处理策略。第4章“架构”深入讨论了Camel的内部结构，包括Camel上下文、路由构建器、Endpoint等关键概念，帮助开发者理解Camel如何处理消息和路由决策。第5章“企业集成模式”是Camel的核心内容之一，它详细解释了23种经典的EIP（Enterprise Integration Patterns），如内容过滤器、路由器、聚合器等，这些都是构建高效集成解决方案的基础。第6章“烹饪书”提供了实践性的示例，展示了如何使用Camel解决实际问题，这些示例涵盖了各种常见的集成需求。第7章“教程”是一系列逐步指导，帮助用户从零开始学习Camel，涵盖从简单的路由到复杂的集成方案。第8章“语言附录”和第9章“模式附录”提供了Camel支持的各种语言选项和模式的详细参考，方便开发者查阅和学习。第10章“组件附录”列出了Camel支持的所有组件，每个组件都有详细的说明和使用方法，这为用户利用Camel连接各种外部系统提供了便利。最后，附带的索引可以帮助读者快速查找所需的信息。 Apache Camel 2.2.0版用户指南是一个全面的学习资源，它不仅涵盖了Camel的基本用法，还深入到高级特性和最佳实践，是开发人员、架构师和系统集成者理解和应用Camel不可或缺的参考资料。

Component mailComponent = new org.apache.camel.component.mail.MailComponent();

myCamelContext.addComponent("pop3", mailComponent);

myCamelContext.addComponent("imap", mailComponent);

myCamelContext.addComponent("smtp", mailComponent);

The second (and preferred) way to populate the map of named Component objects in the

CamelContext object is to let the CamelContext object perform lazy initialization. This

approach relies on developers following a convention when they write a class that implements

the Component interface. I illustrate the convention by an example. Let's assume you write a

class called com.example.myproject.FooComponent and you want Camel to

automatically recognize this by the name "foo". To do this, you have to write a properties file

called "META-INF/services/org/apache/camel/component/foo" (without a ".properties" file

extension) that has a single entry in it called class, the value of which is the fully-scoped name

of your class. This is shown below.

Listing 1.Listing 1. META-INF/services/org/apache/camel/component/fooMETA-INF/services/org/apache/camel/component/foo

class=com.example.myproject.FooComponent

If you want Camel to also recognize the class by the name "bar" then you write another

properties file in the same directory called "bar" that has the same contents. Once you have

written the properties file(s), you create a jar file that contains the

com.example.myproject.FooComponent class and the properties file(s), and you add

this jar file to your CLASSPATH. Then, when application-level code invokes

createEndpoint("foo:...") on a CamelContext object, Camel will find the "foo""

properties file on the CLASSPATH, get the value of the class property from that properties

file, and use reflection APIs to create an instance of the specified class.

As I said in Section 4.1 ("Endpoint"), Camel provides out-of-the-box support for numerous

communication technologies. The out-of-the-box support consists of classes that implement the

Component interface plus properties files that enable a CamelContext object to populate

its map of named Component objects.

Earlier in this section I gave the following example of calling

CamelContext.getEndpoint().

myCamelContext.getEndpoint("pop3://john.smith@mailserv.example.com?password=myPassword");

When I originally gave that example, I said that the parameter to getEndpoint() was a URI.

I said that because the online Camel documentation and the Camel source code both claim the

parameter is a URI. In reality, the parameter is restricted to being a URL. This is because when

Camel extracts the component name from the parameter, it looks for the first ":", which is a

simplistic algorithm. To understand why, recall from Section 4.4 ("The Meaning of URL, URI,

URN and IRI") that a URI can be a URL or a URN. Now consider the following calls to

getEndpoint.

13 CHAPTER 3 - GETTING STARTED WITH APACHE CAMEL

myCamelContext.getEndpoint("pop3:...");

myCamelContext.getEndpoint("jms:...");

myCamelContext.getEndpoint("urn:foo:...");

myCamelContext.getEndpoint("urn:bar:...");

Camel identifies the components in the above example as "pop3", "jms", "urn" and "urn". It

would be more useful if the latter components were identified as "urn:foo" and "urn:bar" or,

alternatively, as "foo" and "bar" (that is, by skipping over the "urn:" prefix). So, in practice you

must identify an endpoint with a URL (a string of the form "<scheme>:...") rather than with a

URN (a string of the form "urn:<scheme>:..."). This lack of proper support for URNs means the

you should consider the parameter to getEndpoint() as being a URL rather than (as

claimed) a URI.

Message and Exchange

The Message interface provides an abstraction for a single message, such as a request, reply

or exception message.

There are concrete classes that implement the Message interface for each Camel-supported

communications technology. For example, the JmsMessage class provides a JMS-specific

implementation of the Message interface. The public API of the Message interface provides

get- and set-style methods to access the message id, body and individual header fields of a

messge.

The Exchange interface provides an abstraction for an exchange of messages, that is, a

request message and its corresponding reply or exception message. In Camel terminology, the

request, reply and exception messages are called in, out and fault messages.

There are concrete classes that implement the Exchange interface for each Camel-supported

communications technology. For example, the JmsExchange class provides a JMS-specific

implementation of the Exchange interface. The public API of the Exchange interface is quite

limited. This is intentional, and it is expected that each class that implements this interface will

provide its own technology-specific operations.

Application-level programmers rarely access the Exchange interface (or classes that

implement it) directly. However, many classes in Camel are generic types that are instantiated

on (a class that implements) Exchange. Because of this, the Exchange interface appears a

lot in the generic signatures of classes and methods.

Processor

The Processor interface represents a class that processes a message. The signature of this

interface is shown below.

Listing 2.Listing 2. ProcessorProcessor

CHAPTER 3 - GETTING STARTED WITH APACHE CAMEL 14

package org.apache.camel;

public interface Processor {

void process(Exchange exchange) throws Exception;

}

Notice that the parameter to the process() method is an Exchange rather than a

Message. This provides flexibility. For example, an implementation of this method initially

might call exchange.getIn() to get the input message and process it. If an error occurs

during processing then the method can call exchange.setException().

An application-level developer might implement the Processor interface with a class that

executes some business logic. However, there are many classes in the Camel library that

implement the Processor interface in a way that provides support for a design pattern in the

EIP book. For example, ChoiceProcessor implements the message router pattern, that is, it

uses a cascading if-then-else statement to route a message from an input queue to one of

several output queues. Another example is the FilterProcessor class which discards

messages that do not satisfy a stated predicate (that is, condition).

Routes, RouteBuilders and Java DSL

A route is the step-by-step movement of a Message from an input queue, through arbitrary

types of decision making (such as filters and routers) to a destination queue (if any). Camel

provides two ways for an application developer to specify routes. One way is to specify route

information in an XML file. A discussion of that approach is outside the scope of this document.

The other way is through what Camel calls a Java DSL (domain-specific language).

Introduction to Java DSL

For many people, the term "domain-specific language" implies a compiler or interpreter that can

process an input file containing keywords and syntax specific to a particular domain. This is not

the approach taken by Camel. Camel documentation consistently uses the term "Java DSL"

instead of "DSL", but this does not entirely avoid potential confusion. The Camel "Java DSL" is a

class library that can be used in a way that looks almost like a DSL, except that it has a bit of

Java syntactic baggage. You can see this in the example below. Comments afterwards explain

some of the constructs used in the example.

Listing 3.Listing 3. Example of Camel's "Java DSL"Example of Camel's "Java DSL"

RouteBuilder builder = new RouteBuilder() {

public void configure() {

from("queue:a").filter(header("foo").isEqualTo("bar")).to("queue:b");

from("queue:c").choice()

.when(header("foo").isEqualTo("bar")).to("queue:d")

.when(header("foo").isEqualTo("cheese")).to("queue:e")

.otherwise().to("queue:f");

15 CHAPTER 3 - GETTING STARTED WITH APACHE CAMEL

}

};

CamelContext myCamelContext = new DefaultCamelContext();

myCamelContext.addRoutes(builder);

The first line in the above example creates an object which is an instance of an anonymous

subclass of RouteBuilder with the specified configure() method.

The CamelContext.addRoutes(RouterBuilder builder) method invokes

builder.setContext(this) – so the RouteBuilder object knows which

CamelContext object it is associated with – and then invokes builder.configure().

The body of configure() invokes methods such as from(), filter(), choice(),

when(), isEqualTo(), otherwise() and to().

The RouteBuilder.from(String uri) method invokes getEndpoint(uri) on the

CamelContext associated with the RouteBuilder object to get the specified Endpoint

and then puts a FromBuilder "wrapper" around this Endpoint. The

FromBuilder.filter(Predicate predicate) method creates a

FilterProcessor object for the Predicate (that is, condition) object built from the

header("foo").isEqualTo("bar") expression. In this way, these operations

incrementally build up a Route object (with a RouteBuilder wrapper around it) and add it

to the CamelContext object associated with the RouteBuilder.

Critique of Java DSL

The online Camel documentation compares Java DSL favourably against the alternative of

configuring routes and endpoints in a XML-based Spring configuration file. In particular, Java

DSL is less verbose than its XML counterpart. In addition, many integrated development

environments (IDEs) provide an auto-completion feature in their editors. This auto-completion

feature works with Java DSL, thereby making it easier for developers to write Java DSL.

However, there is another option that the Camel documentation neglects to consider: that of

writing a parser that can process DSL stored in, say, an external file. Currently, Camel does not

provide such a DSL parser, and I do not know if it is on the "to do" list of the Camel

maintainers. I think that a DSL parser would offer a significant benefit over the current Java

DSL. In particular, the DSL would have a syntactic definition that could be expressed in a

relatively short BNF form. The effort required by a Camel user to learn how to use DSL by

reading this BNF would almost certainly be significantly less than the effort currently required

to study the API of the RouterBuilder classes.

CHAPTER 3 - GETTING STARTED WITH APACHE CAMEL 16

剩余580页未读，继续阅读

semitone

粉丝: 0
资源: 3

Apache Camel 2.2.0 用户指南：企业级集成框架解析

app-release.apk

camel 手册

camel-jing-2.2.0.jar

camel-freemarker-2.2.0.jar

camel-jpa-2.2.0.jar

camel-http-2.2.0.jar

camel-jms-2.2.0.jar

camel-jxpath-2.2.0.jar

camel-groovy-2.2.0.jar

camel-jing-2.2.0-sources.jar

最新资源