mule transports_mule-transport-tcp-CSDN博客

creating transports 创建传输器章节译文

传输器可以用来以统一的方式实现消息通道并联通潜在数据源或消息通道。mule对数种主要协议提供了传输器，包括：文件、FTP、HTTP、JMS、JDBC、Quartz等，在muleForge上还有其他社区贡献的传输器。

创建一个新的传输器时、需要实现一系列org.mule.transport包下的mule接口、并继承抽象类。一个快捷方式是使用maven 传输器Archetype作为你自己传输器的代码模版。如果你想更新一个现有的传输器可以使用模块Archetype。mule传输器类型包括：

inbound-only仅入站：组件只接收事件不能分发事件。
outbound-only仅出站：组件只能分发事件不能接收。
inbound-outbound出入：组件可以接收也可以分发事件。

译者注：事实上这里的传输器是transport的直译，但这个叫法会给人以错觉，似乎mule应该有这么一个重要的Transport接口或 AbstractTransport抽象类以及一大堆具体的传输器类，事实上没有！；似乎传输器与transformer转换器都是mule的组件之一，事实上它们是两码事。mule只有上面提过的那么一个transport包而没有任何的接口或类以Transport结尾！这里的transport译为传输更贴切（虽然不那么顺畅），传输代表某种传输协议（如HTTP、JMS、JDBC、WwebService等），mule里的传输更多的只是一种概念，是mule ESB领域指代传输协议的用语。为了实现按照某种传输协议进行消息传输的功能，需要实现以下接口，这些接口的实现共同组成了针对某种传输协议的传输：

Connector连接器：用于管理Receivers接收器、Dispatchers分发器、Requesters请求器 ，并负责存储配置信息（我们只能配置connector如<cxf:connector...而不能配置transport因为传输只是一个概念，transport说不要迷恋哥、因为哥只是个传说）。实现org.mule.api.transport.Connector接口，mule通过Connector来注册监听器、创建传输特定的Message Dispatchers分发器 ，配置参数由所有Message Receivers接收器 共享。Dispatchers分发器 和Requesters请求器 都存储在Connector中。通常，对于多个inbound入站和outbound出站只需要一个Connector？（only one connector instance is needed for multiple inbound and outbound endpoints as multiple Message Receivers, Dispatchers and Requesters can be associated with a connector. However, where the underlying transport API has the notion of a connection such as the JMS or JDBC API, there should be a one-to-one mapping between the Mule connector and the underlying connection.）
Message Receivers接收器 ：传输的服务部分实现，例如一个TcpMessageReceiver会创建一个服务端socket套接字来接收进入的请求，当用到这个传输处理入站消息的时候Receivers接收器 实例会被创建出来（也就是说如果使用了cxf:inbound则CXF的Connector和Receiver会被创建）。实现org.mule.api.transport.MessageReceiver接口，接收器负责接收外来数据、打包成事件。Receivers接收器 本质上是传输的服务实现（译者注：意思是比如你用CXF传输那么接收器就启动了一个CXF服务。对映的Dispatchers分发器 就是传输的客户端实现现），例如HTTP接收器就是一个HTTP服务器（译者问：如jetty？）
Message Dispatchers分发器 ：传输的客户端部分实现，例如一个TcpMessageDispatcher打开一个套接字来发送请求。实现org.mule.api.transport.MessageDispatcher接口，对应于传输的客户端调用，例如CXF分发器将发送wbeservice调用，分发器在发送消息之前必须调用MuleEvent.transformMessage()来做所有的必要的转换。
Message Requesters请求器： 并不像Receivers接收器 那样等待外来的入站事件，而是向资源或消息通道请求消息。默认的mule service都是用Receivers 来监听消息，但是你也可以编程式地使用Requesters 向消息通道或资源请求消息。实现org.mule.api.transport.MessageRequester接口，经常在编程中用到它，一般的默认mule配置不会用到。
Message Adapter适配器 ：包含在消息体中，作用是作为默认MuleMessage和传输使用的原始消息类型之间的桥梁。例如，JMS消息适配器暴露了getPayload()方法来访问原始JMS消息的Payload，并且所有headers头和用户属性都可以作为消息属性被访问到。实现org.mule.api.transport.MessageAdapter接口，适配器致力于提供一个统一的消息读取途径。适配器提供了读取消息payload和消息属性（消息头、自定义属性或其他元数据）的方法。
Transformers转换器（需要的话）：用来在传输特定的数据格式和其他格式之间转换数据，例如从HTTP响应到字符串，Dispatchers分发器 会调用MuleEvent.transformMessage()来转换消息。
配置Endpoints端点：定义了使用什么传输、它还包含主机、队列名或过滤器、事务信息这些设置。在service上定义端点会使mule创建相应协议下的传输 Connector连接器（意思就是即使你没有配置<cxf:connector...但是你用了<cxf:inbound...则CXF的Connector和Receiver等会被创建）
另外需要实现org.mule.api.transport.MessageDispatcherFactory接口，创建消息分发器实例的工厂类。

对于以上所有接口mule还提供了抽象实现，以下是可用的抽象类：

Connectors连接器：org.mule.transport.AbstractConnector实现了所有默认功能，例如线程配置、接收器/分发器管理。你也可以在这里直接设置一些默认属性如默认的端点属性，除非你在配置端点的时候重新配置否则你的设置将作为默认设置生效。有时候Connectors负责管理传输的链接资源，如JMS或JDBC，这些连接器类型在连接器与连接之间会有一个一对一映射，所以如果你要链接2个或多个JMS服务器那么必须创建新的连接器。对于其他传输，一种协议只对应一个共享连接器。如TCP连接器、每个TCP接收器管理它自己的ServerSocket、Connectors连接器则管理多个接收器（译者注：下面就是一堆需要覆写的方法了掠过不表）
Message Receivers接收器：每种传输的接收器行为有所不同，通常有两种类型：Polling轮询方式和Listener-based监听器方式。轮询方式接收器对资源进行轮询，资源是比如文件系统、数据库、流；监听器方式接收器把自己注册为相应传输的监听器，如JMS的javax.message.MessageListener、Pop3的javax.mail.MessageCountListener（译者注：下面仍然是一堆需要覆写的方法，这里文档与mule2.2.1的代码有偏差，如重要的CxfMessageReceiver类的启动CXF服务端方法doInitialise()就没提到，不清楚这一段文档适用哪个版本。也有可能这里正是使用mule+CXF发布webservice的弱项所在，mule+CXF发布webservice仍然处于“初级阶段”：mule仅仅是把CXF的ws实现类发布出来就完事不管了，后续的消息进一步处理都没有支持如消息流转、路由....看来mule的意思还是把所有业务逻辑都添进CXF的ws实现类，够对付的。有机会再看看mule3吧看看这个CxfMessageReceiver有没有长进）
Polling Message Receiver：...P370

Thread Management线程管理：接收器对每请求分派一条线程是很通行的做法，所有接收器线程都来自接收器的WorkManager，WorkManager负责在一条新线程中执行作业单元，WorkManager具备线程池。WorkManager 是 org.mule.api.context.WorkManager 的实现，实际上org.mule.api.context.WorkManager 仅仅是javax.resource.spi.work.WorkManager的包装类、加了一些生命周期方法。AbstractMessageReceiver具备一个getWorkManager() 方法用来让你的接收器得到线程池（杯具的是CxfMessageReceiver就没有用到或覆写这个方法！其他接收器如tcp、jms、udp、bpm、ftp、xmpp都用到了，mule对CXF发布ws就是全权交给CXF自己去搞，没有涉及自身的多线程调用？），在单独线程中跑的作业必须实现javax.resource.spi.work.Work。使用WorkManager 安排作业应调用scheduleWork(...)而不是startWork(...)。

Message Dispatchers分发器：传输客户端调用代码实现，分发器负责以某种传输发出请求，比如向socket套接字写入或调用webservice，AbstractMessageDispatcher提供了一个基础实现，给实现类留下3个需要实现的方法：doSend(MuleEvent)——如果端点是同步的那么在请求线程中调用本方法并可能阻塞；doDispatch(MuleEvent)——当端点是异步的则以与请求线程不同的线程执行；doConnect()——...；doDisconnect()——...；doDispose()——...；