NetKerne实现REST风格ESB研究.docVIP

NetKerne实现REST风格ESB研究 　　【摘要】在过去几年中，ESB逐渐发展壮大，现在提供了更为广泛的功能，ESB是一种应用集成工具，在很多关键领域提供了灵活广泛的功能，像连接、消息转换、处理中介等。NetKernel是一个软件系统，它将REST和Unix的基本属性组装成一个叫做面向资源计算的强大的抽象集。通过基于NetKerne实现REST风格的ESB技术，显示了ESB强大的鲁棒性、易用性。 　　【关键词】ESB；NetKerne；中间件；传输器 　　1.引言 　　SOA可以通过很多不同的模式和技术来实现。传统方式是选择WS-*规范中所列出的模式，而且可以从Apache ServiceMix这样的开源解决方案或Cape Clear 和Sonic Software商业套件等广泛的技术产品中任意选择一种。不幸的是，WS-*规范仍处于不停的修改中，并且开发人员不得不消化1300页的文档来得到技术细节，这足以让许多人望而却步。 　　市场上的商业ESB套件都已经获得各方的评估，由于这个IT团队相对较小，最终团队决定寻找这样一个解决方案：这个解决方案最终在各系统间引起的矛盾或冲突要小；它所需要的创新要在这个较小的IT团队人力资源所能承受的范围之内；它不应该迫使团队使用依赖于唯一供应商的中央服务集权式模型。大学的领域是极具流动性的，拥有多变的流程、多变的应用、以及多变的集成，因而，它所需要的是能反映大学正真的自然特性的一个总体构架和策略。 　　由于消息请求在之前已作为跨大学的中心传输机制，团队决定选择REST类型或面向资源（Resource-Oriented）的方式来实现SOA。REST基于一组较小的被广泛接受的标准，比如HTTP和XML，这些标准不需要很多开发步骤、不需要很多工具箱和执行引擎。采用REST类型的方式来实现SOA的有三个最主要的优点：较低的开销、投入市场较快、灵活的架构。面向资源的方式在REST风格方式的基础上提供了更广泛的扩展和独立通信基础。REST设计模式提倡使用HTTP，而面向资源的架构则支持将服务连接到HTTP以及诸如JMS或SMTP这样的通信协议上。 　　尽管有一些像Codehaus Mule那样的ESB实现支持REST，但只有1060 NetKernel是建立在在面向资源的计算平台2（Resource-Oriented Computing Platform，“ROC”）之上的。面向资源计算的核心是将信息（资源）的逻辑请求从发送请求的物理机制（代码）中分离出来。使用ROC建立的服务被证实是小巧、简单、灵活的，并且和传统方式相比较需要实现的代码更少。这些优点决定了它是创建技术平台理想的技术选择。 　　2.面向资源的企业服务总线（ESB） 　　面向资源的企业服务总线（ESB）是使用NetKernel来实现的。NetKernel的中心是一个REST风格或面向资源的微核，专门负责为物理代码解析逻辑URI请求并在空闲的CPU上安排执行请求。逻辑地址和物理代码的映射在应用结构中定义，实际的逻辑地址和物理代码的捆绑仅在请求处理的过程中发生，之后该捆绑被会自动废弃。 　　由于每个发送给微核的请求都会建立新的捆绑，所以系统管理人员可以在系统运行并激活了类似实时代码更新功能的环境下自由地修改逻辑地址和物理代码之间的关联。实际的性能似乎不会因为这样的迂回和捆绑而降低，但是当把URI地址作为NetKernel内部缓存的主键时确实可以提高性能。如果有资源被再次请求，并且依赖性没有受到任何修改的话，那么缓存的资源表示会直接被返回，系统无须再重新对其进行计算[1]。 　　使用面向资源微核有几个主要的优点。首先，服务间交互在逻辑层而非物理层进行，这决定了松散的耦合交??，也因此减小了在物理层实现所做的修改对客户和服务供应方之间的影响。其次，请求结果是被缓存的，因而可以减低合成服务和编制的总体开销。比如，如果一组编制好的服务依赖于同一个服务，那么该服务背后的物理代码将很少被执行。最后，所有向微核发送的内部请求都是异步的，因此随着主机服务器CPU个数的增加，其处理能力也会线性增长。 　　ESB主要负责服务的供应和安全性。服务供应包括将面向资源的服务通过HTTP或JMS等传输协议公布给用户。传输层负责将外部URI和访问方法映射到一个内部的面向资源的服务和动作。略去传输不看，以XML文档或JSON对象形式构建的请求体会作为名为“param”的参数传递。带来的结果是，面向资源的服务从传输特定逻辑的细节中解耦，实际上，在任何时候添加额外的协议都不会影响到现存的代码。 　　面向资源的服务依次去委托一组定制的基础服务和NetKernel提供的核心服务。Net-Kernel可以提供大量的核心服务，比如一些核心服务可以处理XML