ChainBuilder ESB 产品升级
ChainBuilder ESB 是一个遵从Java Business Integration (JBI,Java业务集成) 技术规范的图形化的开源工具。它允许开发者们通过一个可视化的图形工具在他们的Service Oriented Architecture (SOA，面向服务的体系架构)环境中创建一些基于标准的ESB组件。
丰富的ChainBuilder ESB 集成平台有一些特定的战略目标，例如用已经存在的系统去连接新购买的软件应用。ChainBuilder ESB 提供一个嵌套在流行开发软件Eclipse环境中的图形化工具集，可以利用它来配置应用接口，在企业与外部供应链中，通过使用一些预建的组件来帮助加速统一应用的进程。
从技术角度看，ChainBuilder ESB 在一致的分层结构中提供了数据、应用、业务对业务的流程集成。作为一个全面的集成解决方案，ChainBuilder ESB取代了点对点接口，以灵活可靠的基础结构，连接各种应用系统和异构数据库而不论所需要的协议和数据格式。
ChainBuilder ESB宽广的功能跨越了集成所需的范围，包括从实时的，事务接口到以大批量，性能密集型的应用。通过自身支持的Web服务，XML技术，HL7 和 EDI可以看出，在与对外合作伙伴衔接，扩展业务和客户服务等方面，ChainBuilder ESB是一个理想的解决方案。ChainBuilder ESB 还提供了关键模块以创造一个具有成本效益的面向服务的架构。
ChainBuilder ESB核心功能包括：
通信协议：
1. 支持FTP、HTTP/SOAP，SMTP和POP3， TCP/IP，HL7 MLLP 和文件等多种协议。
2. 支持Java消息服务（JMS），包括IBM Websphere MQ。
基于Eclipse插件的集成开发环境：
1. 流程编辑器是ChainBuilder ESB的设计核心，它允许用户使用Eclipse的集成开发环境和项目向导完成对组件属性的定义。
2. 消息格式编辑器是一个图形化的用户界面，它可以构建变长、定长或结构的消息。HL7和X12编辑器可以实现图形化的建立或修正HL7和EDI X12格式的消息。
3. 映射编辑器可实现消息转换。
服务组件：
1. 主要使用在ESB（企业服务总线）中的组件是路由器和服务编排器。路由器根据消息的内容把消息路由到目的端点。服务编排器把多个组件串联在一起实现一个业务需求。
2. JDBC组件支持在基于XML格式的SQL语句来执行查询或更新功能。
3. 解析器组件可以解析EDI X12和HL7消息格式的文件，或者是变长、定长或结构的消息格式。
4. 转换器组件支持在非标准的，HL7和X12消息格式和XML格式的消息之间进行转换。
5. 脚本组件通过Groovy脚本和Java实现了用户自定义功能或业务逻辑。
公共服务：
1. 关键的基础设施，包括一个完整的日程安排框架组件，并可选择故障事件通知。
2. 建立自定义组件的框架。
3. 一个API（应用程序接口）框架用来编写用户自定义代码，以改变的一个组件或预先定义工作流的行为。
4. 包含了预先编译好的HL7标准和X12标准的消息库。
5. 支持Web服务或TCP/IP通信的证书管理。
6. 统一的字符编码标准、双字节字符集和本地化支持。
7. 全面的错误信息处理和可靠的消息传递。
8. 所有组件符合JBI（Java业务集成）标准。
监控：基于AJAX的Web界面
1. 远程访问并查看服务统计信息、服务运行日志文件和错误信息数据库。
2. 允许管理、监测和控制JBI组件、服务单元、应用和ChainBuilder ESB 服务器。
ChainBuilder ESB对于web service的实现方案
作为一个企业应用集成平台，ChainBuilder ESB以无缝的分层的体系结构为客户提供数据、应用程序以及业务流程的集成，ChainBuilder ESB将推动基础设施技术的进步，以灵活可靠的基础设施代替点对点的接口开发。作为高性能的消息平台与服务引擎，ChainBuilder ESB是最全面的集成解决方案，连接应用程序，数据库和其他系统，例如：高校的财务系统和其他系统，通过集成不同的信息标准，如XML技术， EDI技术等，这种多样性使得ChainBuilder ESB成为与外部伙伴相连接，扩大电子商务业务的理想解决方案。
清华大学已经为高校资金监控系统作了大量的工作，开发了教育部资金监控及分析预警系统，安装在高校的客户端软件–高校资金数据自动采集系统，连接教育部和高校两个系统之间的数据传输系统，还为目前使用量大的帐务系统开发了访问中间件。我们将最大化可能地保留原有系统，只在高校资金数据采集系统和帐务系统之间运用Chianbuilder ESB来采集系统，快速解决数据采集存在的问题，并增加系统的灵活性和扩展性。
ChainBuilder ESB自身定义了很多组件，至于针对此项目ChainBuilder ESB服务端的构建，我们可以根据下面的流程图来实现。
图 7：服务端的web service
HTTP组件属于绑定组件，在这个web service服务端里用来接收所有来自外界的请求以及返回所有的答复。
当HTTP接收到请求后，请求将传递给CBR在组件。CBR根据请求内容判断这个接下来的操作是得到高校的监控条件（getCondition）还是上传新的数据（uploadData）。根据不同的请求，CBR可以将决定执行哪条流程来实现客户的请求。
如果请求是得到高校监控条件，数据就会被传给SEQUNCER1。然后数据将进行依次三个操作。首先，用TRANSFORMER1把数据的格式转化成JDBC组件可以识别的格式；其次，把此格式的数据传给JDBC，JDBC将会执行对应的SQL语句来得到结果；最后，结果经由TRANSFORMER2转化为需要的格式传回SEQUENCER1。SEQUENCER1再将结果传回给CBR,CBR将结果传给HTTP。
如果请求是上传高校最新数据，数据就会被传给SEQUNCER2。然后数据将进行依次两个操作。首先，用TRANSFORMER3把数据的格式转化成ETL组件可以识别的格式；其次，把此格式的数据传给ETL，ETL将会执行对应的SQL语句来讲数据输入数据库。此后ETL会将执行成功与否的结果传给SEQUENCER2。SEQUENCER2将结果传回给CBR,CBR将结果传给HTTP。
ChainBuilder ESB对于自身内部的组件有着庞大的属性设定。通过对属性的设定，ChainBuilder ESB即可以实现数据按照我们预期的流程传送，对应的web service也会生成。以上内容也简要概述了通过ChainBuilder ESB开发web service服务端的基本流程。
待服务端建立好以后，一个WSDL文件将被生成，它包含所有对服务端功能、数据和方法的描述。客户端通过此WSDL文件可以生成客户端代码，通过客户端代码就可以实现web service远程调用。服务端和客户端能成功通讯后，基于ChainBuilder ESB的web service通讯就建立成功了。以上概要就是ChainBuilder ESB对于web service的实现方案。
什么是web service?
Web service是创建可互操作的分布式应用程序的新平台，基于XML、XSD等独立于平台、独立于软件供应商的标准，实现跨平台的可互操作性。我们可以认为Web service 是一个应用程序，它向外界显露出一个能够通过Web进行调用的API。客户能够用编程的方法通过Web来调用这个应用程序。
Web service的平台由三个技术组成：XML和XSD、SOAP以及WSDL。
XML和XSD
可扩展的标记语言(XML)在Web service平台中表示数据的基本格式。它易于建立和易于分析外，而且不依赖于平台和厂商。
W3C制定的XML Schema(XSD) 定义了标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。在web service应用中，所有使用的数据类型都必须被转换为XSD类型。
SOAP
Web service建好以后，简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。
WSDL
Web service描述语言(WSDL)是基于XML的语言的，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。
为什么使用web service?
Web service在应用程序跨平台和跨网络进行通信的时候是非常有用的。Web service适用于跨越防火墙的通信、应用程序集成、B2B集成、代码和数据重用，以及通过Web进行客户端和服务器的通信的场合。
长项一：跨越防火墙、代理服务器的通信
如果应用程序有很多，而且分布在不同的地方，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到每一个用户手中。如果用浏览器作为客户端，写下一大堆页面，把应用程序的中间层显露给最终用户。这样做的结果是开发难度大，程序很难维护。
如果中间层组件换成Web Service的话，就可以从用户界面直接调用中间层组件，从而省掉建立页面的那一步。要调用Web Service，可以直接使用Microsoft SOAP Toolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。
在一个用户界面和中间层有较多交互的应用程序中，使用Web Service这种结构，可以节省花在用户界面编程上的开发时间。另外，这样一个由Web Service组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过Web Service把应用程序的逻辑和数据“显露”出来，还可以让其它平台上的客户重用这些应用程序。
长项二： 应用程序集成
企业经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过Web Service，应用程序可以用标准的方法把功能和数据显露出来，供其它应用程序使用。
长项三： B2B的集成
用Web Service集成应用程序，可以使公司内部的商务处理更加自动化。跨公司的商务交易集成通常叫做B2B集成。
Web Service是B2B集成成功的关键。通过Web Service，公司可以把关键的商务应用“显露”给指定的供应商和客户。Web Service的实现比较简单，而且Web Service运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。不过，Web Service并不像EDI那样，是文档交换或B2B集成的完整解决方案。Web Service只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。
用Web Service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“显露”出来，成为Web Service，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。
长项四： 软件和数据重用
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。
当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。
Web Service在允许重用代码的同时，可以重用代码背后的数据。使用Web Service，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的Web Service就可以了。例如在项目高校资金监控系统中，如果我们想在客户端知道某个高校的监控条件，我们只需要发送这个学校对应的唯一的代码给web service, web service就可以帮我们在服务器端通过浏览数据库查询的所需要的信息。如果这个学校对应的监控条件有了更新，我们只需要更新服务器端数据库即可。
另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过Web Service“显露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
将来，许多应用程序都会利用Web Service，把当前基于组件的应用程序结构扩展为组件/Web Service 的混合结构，可以在应用程序中使用第三方的Web Service 提供的功能，也可以把自己的应用程序功能通过Web Service 提供给别人。两种情况下，都可以重用代码和代码背后的数据。
总之，灵活性、高效性、可延展性是web service给我们带来的优点。灵活，因为它不依赖于平台和开发语言，不因防火墙或者代理服务器而增加开发工作；高效，因为它通过远程调用充分利用服务器端的功能、方法以及数据，实现代码和信息的共享；可延展，因为它能够与其他的应用程序轻松的实现整合。鉴于以上优点，应用web service对于我们的工程大有裨益。
