mule in action翻译13 : 3.1 理解连接器

最新推荐文章于 2019-09-18 17:20:46 发布

terrorist2008

最新推荐文章于 2019-09-18 17:20:46 发布

阅读量211

点赞数

分类专栏： ESB 文章标签： mule esb

本文链接：https://blog.csdn.net/terrorist2008/article/details/84613807

版权

ESB 专栏收录该内容

27 篇文章 3 订阅

订阅专栏

mule in action翻译13 : 3.1 理解连接器

第3章连接器

本章内容：

1、使用连接器整合不同的协议

2、云连接器API

3、整合SaaS APIs

应用集成的关键是四处运送数据。把珍贵的时间花费在编写WSDL、写JMS消费者程序、钻研供应商自相矛盾的文档上，并不会对你的集成应用提供多大的贡献。反而造成了负面影响：你费力编写代码却并不能解决实际的业务问题。甚至当这些琐碎的代码最终开发完成时，它们在各个项目或各个团队的实现也是不尽相同的。这给开发人员提高开发速度造成了困难，也会影响开发人员在不同团队间的流动。开发人员必须保证他们的传输代码是线程安全的，进行了正确的错误处理，且当协议或API变化时还需要更新代码。

让我们重新回顾一下这个问题，这实际上是相当简单的，例如去接受HTTP请求并把内容发送到JMS消息队列，我们在第一章已经使Mule实现了这个功能。这是一种比较简单的情况，但如果不使用类似Mule这样的集成框架，你需要完成下列这些步骤：

1、设置一个web服务器去接受请求

2、把HTTP请求转换为一个JMS消息

3、得到并正确的管理资源（连接工厂、会话等等）以发送JMS消息

4、正确的处理并发、日志、安全等等问题。

编写这些代码对你来说或许简单或许很难，这取决于你的技术水平和对一些能简化开发的第三方框架的属性程度。然而不管怎样，你或你的团队愿意去开发、测试、管理文档并进行维护这些东西吗？

还是使用Mule来简化这个问题吧。

Arnor Accounting 公司和 Frozen North Freezing公司

本章例子中用到这两个公司，Arnor Accounting 是一个小的公司，

但它前瞻性的使用了基于SaaS（软件即服务）的会计应用系统。

Frozen North Freezing 公司是提供小型冷却产品的公司。他们的产品功能与其他系统有许多集成点，

典型的是进行监控。

3.1 理解连接器

连接器是Mule对发送数据、接受数据以及和不同API进行交互的过程抽象出的一个概念。在mule中最常使用的连接器是 transport。transport 对协议提供了一个适配层，如HTTP JMS。transport提供数据源和数据“容器”。他们用来把数据放入流或从流取出数据。流的数据源被称作接入端口（ inbound endpoint）.

数据容器或数据目的地称作为接出端口（outbound endpoint）。

本章的第一部分包含mule的最重要的 transports。

另外一种连接器称为云连接器（cloud connector）。云连接器专门用来连接API。起初是指基于云的API(这正是其名字之起源)，比如 Twitter 或 Salesforce提供的API。这个定义现在有点模糊了，像你在本章随后看到一样，它也包含一些别类的API如MongoDB。云连接器通常不提供endpoints ，而是有映射API中定义的操作的处理器。云连接器包装了API的操作，大大提高了开发人员效率。

3.1.1 使用XML配置连接器

mule配置文件中经常会包含一个或多个连接器元素。每个transport都有自己的特殊的连接器属性。

例如，这是个文件连接器的配置

<file:connector name="fileConnector" autoDelete="false"/>

这是个进行安全代理的HTTP连接器

<http:connector name="HttpConnector"
       proxyHostname="${proxyHostname}"
           proxyPort="${proxyPort}"
       proxyUsername="${proxyUsername}"
       proxyPassword="${proxyPassword}" />

连接器元素包含一个name属性，它是endpoints中连接器的唯一标示。这使你可对一个transport配置多个连接器，每个连接器可以设置不同的参数。

配置中不包含任何连接器是绝对可能的，且甚至是常见的。为啥这样？若mule发现你的一个endpoints需要特定的连接器，它将自动实例化一个给你，这时连接器的默认值是根据你的配置参数生成的。如果这些自动生成的连接器能满足你的需求，那么这确实是一个很好的方式。

同一个协议多个连接器当你对某个特定的协议只有一个连接器时，不管它是默认自动创建的还是

你明确配置的，在endpoint都不需要添加一个对连接器name的引用。一旦某个协议有多个连接器，

使用该协议的endpoint将组织mule加载你的配置，并会抛出异常：

“There are at least two connectors matching protocol [xyz], so the connector to use must be

specified on the endpoint using the connector property/attribute.”

这时只要在每个endpoint引用一下使用的连接器的名字就行了。如：

<vm:endpoint onnector-ref="myVmConnector" name="LoanBrokerQuotes" path="loan.quotes"/>

对transport 而言，一个连接器提供了和特定协议通讯的基础。一个endpoint 通过渠道进行消息的发送或接受，而连接器给渠道提供了基础设施。例如一个JMS 连接器负责管理连接JMS broker，在通讯失败时进行重新连接和认证。一个JMS endpoint 负责发送和接受队列消息和话题。endpoint 是mule传输IO的基石；他们是你向流放入和取出消息的工具。

endpoint有两种“风味”：inbound 和 outbound。

inbound endpoint用来做消息源；outbound endpoint 用来发送数据。

inbound endpoint 可以完成功能如接收JMS消息、读文件流、从邮件服务器拉取邮件。

outbound endpoint 可以分发JMS消息、把记录插入到数据库表、向FTP服务器发送文件。

你也将在mule内部使用inbound endpoint 和 outbound endpoint以进行组件和流之间的通讯。

你可能注意到所有的endpoint都提供一个地址属性。为啥这样？这使一般的endpoint可以使用URI的方式配置目的地址，取代了设置endpoint多个属性值的方式。

三种情况下这是有用的：

1、一个地址可以用在一个endpoint的单独属性里。例如 endpoint使用HTTP传输时，

可以明确的配置完整的地址，而不用再单独的设置主机、端口、和路径。

2、当使用MuleClient时，地址是用来发送消息或从mule应用接收消息的。

3、不常见的是，一般的endpoint没有传输的命名空间可用。当你想根据不同的环境使用不同的传输时可能是

有用的。（例如根据是否部署了应用决定使用 VM 传输还是使用 JMS传输）