.net中调用esb

ESB相信很多人都听说过，又叫企业服务总线，是一种传统的企业服务集成架构。最近几年入行的年轻人肯定认为它已经过时了，现在流行的微服务和分布式的体系可以完美的将其替代。下面我们来讲讲ESB，至于它是否真的有用读者可以自己体会。

ESB主要是为了解决多个应用系统互联所面临的的复杂性，减低集成和维护成本。

举个例子，比如医疗业务系统可分为很多子系统，包括HIS、LIS、EMR等等，如果这些业务系统可能是由多个供应商开发的，可能会有构建语言的不同、通信协议的不同、数据传输格式的不同等问题，那么如何把这些系统用一条线串起来呢？就是ESB。ESB就是把服务的集成从系统层面提升到了平台层面，通过中间件调用各系统服务，以实现各系统通信。它需要保证多个应用系统的服务接入，协议转换，提供可靠的消息传输，数据格式转换，基于内容路由等功能。

有人可能会有疑问，应用A发送消息给ESB，ESB再将消息转换给应用B，那么应用A直接通过SOAP协议发送给B，效率不是应该更高吗？而且如果这些IT系统都在一个网络中，提供的WebService都在统一命名空间下，就可以相互通信，为什么还要加上这一层？有两点需要考虑。第一点。点对点做服务的时候，通常需要考虑日志记录，服务访问安全、传输安全、数据安全、路由分发等一系列问题，而这些完全可以统一管理，统一验证，灵活配置；如果应用A调用了应用B，再调用了应用C等具有逻辑流程的调用时，还可以在ESB上实现流程引擎；第二点，ESB是一个中间件平台，包含了消息中间件的全部功能，有异步消息处理机制，可以实现业务系统之间真正的松耦合的结构。

一．CXF

CXF的定位不是ESB总线，而是一个服务框架(Service Framework)，主要还是为关于服务的应用提供API上的支持，或者上下文上的管理。可是它的前身之中的一个的Celtix就是IONA公司捐献给开源界的ESB总线，所以总体上还是能提供ESB总线的功能。在CXF中的总线仅仅是起到一个共享资源的提供者的作用。这些贡献资源就相当于JBI规范中的绑定组件或服务引擎。即使如此CXF并没有提供了对JBI规范的完整实现。能够说它仅仅是一个相似的JBI容器。CXF支持与除了HTTP之外的其他协议的通信绑定，比如REST、JSON和CORBA等，所以对于Ajax有较强的兼容性。这相对与其他的ESB总线而言能够说是一个较大的优势。可是CXF的ESB总线是根据Spring框架来实现的，由Spring来管理Bus中的各个组件。而Spring对各个Bean或组件的管理是通过一个上下文的配置文件来实现的。这种方式相对与其它的ESB总线的方式而言，则不支持动态的热部署。也就是说CXF不是一个JBI容器，它必须依附与其它的容器来执行。现有的资料来看，CXF眼下能够部署在JBoss和Weblogic中，Tomcat因为不支持完整的J2EE规范，特别是基于JCA的EJB，所以对CXF支持的程度不理想。关于CXF的文档较为丰富，这部分是因为它本身是整合了Xfire和Celtix这两个本身较为成熟的开源项目。另外它较大的依赖于Spring框架，所以假设对Spring较为熟悉的话，在使用上一般就没有太大的障碍了。

二．Open ESB

OpenESB是Sun公司提出来的开源ESB项目，所以对JBI规范的支持程度就不用多说了。而GlassFish ESB则是将OpenESB的核心执行环境与GlassFish应用server以及NetBean的集成开发环境整合在一起的有一个ESB项目，当然其中还包括了一些OpenESB中已有的组件。

在OpenESB中提供了可以支持WS-BPEL2.0的引擎。可是如今这个组件支持WSDL1.1，暂不支持WSDL2.0。并且这个引擎要依托与NetBean集成开发平台，起码仅仅能得到基于NetBean的对应开发包和组件包。可是这个组件对BPEL提供了强大的支持，当中包含支持端点状态的监控、支持多线程运行、业务流程的调试、系统错误的可靠性恢复中各个业务流程实例的数据库持久化以及负载均衡等。在资料方面仅仅有一个演示视频，主要还是基于NetBean平台的使用介绍。其它发布的资料则则较少，特别是API方面差点儿没有。所以假设要对OpenESB进行依照自身的要求进行扩展则较为困难，除非对OpenESB的源码进行全面的分析。

三．ServiceMix

ServiceMix是Apache基金会下的一个ESB总线，同时也是一个独立的JBI容器。说它是一个独立的JBI容器，是由于它拥有自己独立的执行环境，能像应用server一样启动，并支持动态的热部署等，这一点则差别于CXF。

ServiceMix的容器执行环境采用内核的架构，并以Geronimo关于J2EE方面的实现为基础，所以在性能上还是较为出色的。在通信上，整合了ActiveMQ，也支持多种的通信协议，比如HTTP和JMS。同一时候在管理组件上採用了JMX的管理架构，从而可以对部署在总线上的各种组件进行动态的配置和管理，或通过Web的形式，或通过JMX远程訪问均可。ServiceMix内核可以整合到所处的操作系统中，从而作为OS的对外提供的服务。

关于ServiceMix的资料也较为的完备，关于组件扩展方面和流程引擎整合方面的资料则不够具体。假设要做进一步的总线上的扩展，则须要对源码进行较为深入的学习和研究，当然这一切的基础是对JBI的规范有较为全面的了解。

四．JBoss ESB

JBoss ESB是JBoss社区为面向SOA而提出的一个EAI系统平台。它提供了非常多EAI本身所应具有的功能，比如业务流程监控、集成开发环境、工作流用户接口、业务流程管理、分布式计算架构以及作为应用容器的功能等。JBossESB在功能上是较为强大的。但相对于上面的总线而言，它的技术架构方案是最独立的。由于它除了支持J2EE标准外，对于JBI规范压根就不沾边。当然也就不存在JBI规范中的规范化消息路由、服务引擎和绑定组件了。JBossESB除了支持 Web Service外，还支持多种的远程调用协议，比如JMS。仅仅是相对于ServiceMix和CXF而言，假设要对JBossESB进行扩展，可能要花费较大的时间和精力。

JBossESB相对上述的开源项目而言，一个非常大的优势在于文档资料是最为丰富和完备的。所以在开发和扩展上减小了不小的阻力。它而且依托于成熟的JBoss社区，周围齐全的开源项目支持，为后期的平台扩展提供了丰富的选择空间。

1.ESB的服务接入方式？

• RPC 远程过程调用(面向方法)
• SOAP 面向服务的架构(面向消息)
• REST 资源的状态转变(面向资源)

目前我们公司使用的HSF实际上就是RPC，还是JSON-RPC，RPC的另一种实现还有XML-RPC，通讯方式相同，采用调用本地服务一样的调用服务器的服务的方式，只不过传输数据格式不同，JSON格式更加高效。

XML-RPC实际上就是这三种方式的最早通信方式，基于HTTP传输协议+XML参数封装，一个XML-RPC消息就是一个请求体为xml的http-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点，用于访问服务的地址信息，用于传输信息的传输协议，用于所有可使用功能的名称和接口方法，在所有的请求和响应中所使用的数据类型及格式；

REST，是一种约束、或者开发方式，简单的说就是，用HTTP动词(GET,POST,DELETE,PUT)描述操作，表示资源的转换，用JSON格式传输数据。满足REST的约束叫RESTful风格。

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

现在ESB产品的实现方式基本上是二进制进行转换。

3.数据转换

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

4. 消息路由

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

1. 什么是ESB和注册服务管理

• ESB主要作用是兼容各种协议接口，将各种协议的数据进行编排转换，不适用于高并发场景的应用 。
• 服务注册时将所有的服务接口注册到一个中心的分布式服务集群上，各个业务系统直接访问分布式服务提供的调用接口位置进行调用。

2. ESB和服务注册的特点

• ESB是集中式转发，适合大量异构系统集成。总线上可以做流程引擎，安全监控等 。
• 服务注册时采用分布式调用，注册中心只记录了地址信息，然后直连调用，适合并发压力比较大的情况。

3. 总结

• ESB侧重于系统和服务集成，不能支持特别大的并发。
• 分布式侧重于服务治理，各服务提供各自的功能接口，由zookeeper进行服务注册发现，适合高并发及高可用场景。