三、 如何实现ESB的各个功能

1.ESB的服务接入方式？

• RPC 远程过程调用（面向方法）
• SOAP 面向服务的架构（面向消息）
• REST 资源的状态转变（面向资源）
  目前我们公司使用的HSF实际上就是RPC，还是JSON-RPC，RPC的另一种实现还有XML-RPC，通讯方式相同，采用调用本地服务（方法）一样的调用服务器的服务（方式）的方式，只不过传输数据格式不同，JSON格式更加高效。
  XML-RPC实际上就是这三种方式的最早通信方式，基于HTTP传输协议+XML参数封装，一个XML-RPC消息就是一个请求体为xml的htpp-post的请求，服务端执行了之后也以XML格式的编码返回，后来这个标准演化成了SOAP，可以理解为SOAP是XML-RPC 的高级版本；
  SOAP，简单对象访问协议，是一种轻量的、简单的、基于xml的远程访问协议，可以实现多种传输层或应用层协议结合使用，如TCP/HTTP/SMTP等,实际上应用最广泛的还是基于HTTP+XML的实现，相对于XML-RPC，SOAP更好的利用了XML，有相应的服务描述语言，也是一段XML,也就是WSDL(Web Services Description Language),专门用来描述怎么访问web服务，描述了哪些细节呢？一般包含4点，用于访问服务的地址信息，用于传输信息的传输协议（比如通道数），用于所有可使用功能的名称和接口方法，在所有的请求和响应中所使用的数据类型，具体什么格式，这里不再展开，有兴趣可以查看一下以下链接：
  WebService之WSDL文件讲解
  最后说REST，非协议非规范，只是一种约束、概念或者开发方式，简单的说就是，用HTTP动词（GET,POST,DELETE,DETC）描述操作，表示资源的转换。满足REST的约束叫RESTful结构，其实目前公司的并不是RESTful风格。
  近年来的REST被炒得很火，但不是所有情况都是适合的，REST目前都是基于HTTP/HTTPS，而SOAP可以支持很多传输协议，从HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，简单邮件传送协议），甚至JMS（Java Messaging Service，Java消息传递服务）。而SOAP已经是一个工业标准，它具备良好定义的协议，以及一套良好确立的规则，在大型和小型系统中均有采用。

2.ESB的如何进行协议转换？

现在使用的ESB协议转换基本上使用的ESB产品，实现基本上二进制进行转换；具体的可以找相应的产品的，比如 WSO2d产品的实现：
WSO2 ——（7）ESB功能：协议转换
目前有一些问题需要再调查一下，cxf3.1目前也只支持wsdl1.1，axis2的最新版也不支持wsdl2.0，需要继续查询资料如何转换；有些企业再做接口对接的时候可能只提供wsdl,需要自己根据wsdl生成服务端提供服务给他们，可以利用soapUI实现。有些企业只支持wsdl1.0，我们要实现自己的ESB就要提供wsdl1.0与wsdl2.0版。

3.数据转换

• 在应用间交换不同格式的信息
• 操作消息的负载内容，包括加密、压缩和编码转换
• 在异构的传输协议的数据类型间格式化消息
  此过程也是依赖工具比如Mule可以用Transformer 进行转换，比如将JMS格式message转化为其他类型的数据，JDBC Transformer可以将CSV或xml文件中的数据转移到数据库中等等操作

4. 消息路由

• 基于消息内容和复杂规则路由消息
• 消息的过滤、聚合以及重新排列序号
  此过程也是依赖工具比如Mule可以用case when 等逻辑判断，根据消息中指定的消息将消息发送到不同的服务端进行处理。

ESB的主要应用场景是集成，特别是对无法改变的异构系统做适配整合，比如遗留系统，外部系统。在逻辑上和运行时都是集中的。逻辑上会有集中的高层视野，有利于可管理性，也就是便于治理。

但也有集中的复杂性特别是演进时的节奏纠缠，需要想办法应对。运行时的集中则有比较大的容量和可用性风险。

微服务的通讯一般是自治的，在运行时是分散的，容量和可用性风险可以分散应对。逻辑上也是分散的，这一点有好处也有坏处，分散复杂性的同时也失去了统一视野。

折中的办法是建立服务治理中心，作为逻辑中心，采用事后模式的治理演进风格。