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

 

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传输）

 

 

 

 

3.1.2 使用 Mule Studio配置连接器

 

    配置连接器和配置endpoint非常的相似，使用 Mule Studio比直接配置XML更容易。只需简单的对endpoint右键选择属性，如图3.1

 

    图3.2 显示了一个HTTP endpoint的配置页面。

   可以通过点击References tab页的connector后的加号，定义HTTP的连接器。

 

    添加连接器后，References tab页的下拉列表就可用这个连接器了，像图3.3  和图3.4 所示。

 

 

 

 

 

    现在你应当可以通过xml和mule studio顺利的 配置 endpoint和连接器了。

 

 

 

    现在来看mule 内置的一些传输。下面是本章将看到的传输和云连接器：

   1、File transport  --从本地或网络文件系统读写数据

   2、HTTP transport --发送接受HTTP 请求，暴露和消费 web service

   3、JMS transport—- 分发和接受JMS消息

   4、Email transport-- 从 IMAP 服务器接收email，使用SMTP发送email

  5、FTP transport—从ftp服务器获取文件或发送文件到ftp服务器。

  6、JDBC transport--使用jdbc读写关系型数据库

  7、MongoDB cloud connector—从MongoDB读写数据

  8、VM transport--使用虚拟内存传输来实现可靠的方式

  9、Twitter cloud connector--和Twitter API交互