对ESB的一点理解

 ESB简介

 

ESB(Enterprise Service Bus)是支持系统间连接(Control & Service Flow Coordination), Messaging(Connection), 转换/路由(Mediation), Web Service等的标准的接口，是构成SOA的解决方案。

系统除去了应用程序间直接的Point-to-Point式连接关系，通过ESB来构建应用程序间间接的连接关系并确保了Service Broker，即最小化了因各个应用程序变动所带来的影响。但是在此过程中，服务呼叫会带来一些性能的低下。但是在这里这种问题得以解决，即在同一平台上通过服务接口公开服务而在实际服务的构建时是通过Micro Flow来组合了组建或者单位模块。ESB为了分散服务组建的集成，与Process Manager传送遵循自身标准的消息并支持基于流程的整合管理。

提供这些功能，ESB成了SOA构架上的中间层即构建Service Orchestration Layer的核心因素，模仿ESB的诸多相关产品涌入市场。Forrester根据这些供应商的设立和产品信息分为ESB专业供应商、基于EAI的供应商、基于平台的供应商等。ESB专业供应商提供的产品忠诚于Web Service或者ESB的原本功能和标准，是最初迈出ESB市场的供应商。基于EAI的供应商不仅提供之前EAI(Enterprise Application Integrator)供应商整合中心的BPM中心的产品还提供ESB功能。基于平台的供应商以自家公司平台解决方案为中心的BPM解决方案并应用与ESB或者进行另外的产品化的供应商。

ESB的特点

 

要支持SOA，ESB需要具备几个特点。遵循标准接口的消息传送和应用程序间的关联较小的(LooselyCoupled)状态下，可以进行联动并利用独立的应用程序来开始、停止、重新启动流程。UpRight的UPESB则在支持SOA的构架上接轨高性能的引擎构造并支持各种流程模式，具有优秀的扩展性。

ESB的应用范围

SOA和ESB是持续发展的领域。因此可对ESB的定义和应用范围产生混乱或者误解。随着ESB的应用范围越加广泛，越来越难以真正理解ESB。例如，ESB的作用不仅是目前的EAI，之后还会包含BPM的部分领域，在服务管理方面等会添加比目前想象的更多功能。

下图展示着从传统的EAI通过ESB扩展到BPM的发展方向。

 

如果一个系统的业务速度并不重要而且编成的修改量又少，则SOA的引进则无太大意义。即不需要引进SOA并对企业业务的所有功能进行服务化。

在这里可以提到一个问题，引进SOA是否所有的服务都要通过ESB来进行呼叫。ESB是在互不相同的环境下以标准方式提供可复用的环境，保证系统的扩展性、安全性、可用性。SOA的使用就是从ESB开始的。如果服务前端(front-end)直接呼叫特定服务，则不能严格保证ESB所提供的标准化、可复用性、扩展性、安全性、可用性等。同时，ESB还整合管理各服务的接口。如果一些服务是通过ESB呼叫而另一些服务是直接被呼叫，则服务前端提问服务的位置信息的目的地为多个并且服务的物理位置包含与代码，因此每次服务位置有变动时都要修改编成代码。

概括来说ESB承担整个服务的有关管理和Orchestration，才算正确构建SOA。在Business Process Layer上运行的BPM也需要能与ESB整合的构造，这与Service Orchestration Layer上运行的ESB不同。原因是因为BPM和ESB都重复使用基于流程的技术，如此分离的构造会伴随着功能上的问题。

在ESB平台上引进BPM解决方案并支持各种服务、BPM、EAI、BPM、EAI、规则、Web Service 是有效率的。

 

 

 

本文出自 “upright” 博客，请务必保留此出处http://5894434.blog.51cto.com/5884434/1007880