【61页】基于ESB的服务发现和管理的研究与实现-论文文档精品范文

目前，面向服务的架构，逐渐成为企业应用集成的发展主导方向。

是种定义集成基于服务的软件应用的方法，通过服务调用实现组合实现业务流程。

服务是离散的功能单元，封装了可重用的业务绪论研究背景国内外发展现状研究内容课题研究难点，基于的服务发现和管理的研究与实现第章于的服务发现和管理的研究与实现部分内容简介，基于的服务发现和管理的研究与实现，第章绪论研究背景国内外发展现状研究内容课题研究难点课题的创新之处论文组织结构第二章关键技术和规范面向服务架构企业应用集成和中间件技术技术可扩展标记语言简单对象访问协议企业服务总线概述的主要应用领域管理扩展本章小结第三章基于的服务发现和管理的分析架构分析架构对第三方的支持服务器端客户端非功能性需求分析功能性需求分析可行性分析本章小结第四章基于的服务发现和管理的设计控制台设计控制台权限控制设计代理设计代理安全设计本章小结第五章基于的服务发现和管理的实现与结果控制台实现控制台权限控制实现代理实现代理安全实现结果与分析本章小结第六章结束语总结展望参考文献致谢第章绪论第章绪论研究背景随着网络传输能力的日益增进，软件体系结构以及发布形态也发生了巨大的变化。

从软件体系结构的提出，到企业级服务总线的广泛应用，到云计算概念和实现的兴起，都说明了这样个发展趋势。

软件将向着越来越智能化，个性化，可移植化，可配制化的方向不断的发展。

随着企业之间和企业内部各种业务的发展，原有的应用系统越来越不能满足当前业务的需求，于是各个公司开发各种新系统来满足日益发展的各类业务的需要，使应用系统的数目越来越多。

但是由于先前的系统是由不同公司，在不同的平台下，甚至由不同的数据库，不同的语言实现，因此产生包括些编程语言差异平台差异命名冲突通信协议差异和数据差异所带来的异构性问题不可避免，因此对于企业之间的系统整合，数据和资源的共享，实现企业内部和企业之间的应用集成，已经逐渐成为企业信息化的个重要命题。

目前，面向服务的架构，逐渐成为企业应用集成的发展主导方向。

是种定义集成基于服务的软件应用的方法，通过服务调用实现组合实现业务流程。

服务是离散的功能单元，封装了可重用的业务逻辑，位置透明平台且可互操作，它具有基于松散耦合行业标准业务敏捷性和与协议无关性等优势。

典型的架构的基本要求服务间保持松散耦合，基于开放的标准，服务的接口描述与具体实现无关灵活的架构服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明在相对较粗的粒度上对应用服务或业务模块进行封装与重用等等。

而要实现架构的个核心问题就是如何把所有的功能应用数据或者服务通过种有效的方式连接起来，而服务的提供者和服务的请求者之间仍然需要这种显式的点到点的调用，那么这就不是个典型的架构。

因此，在中，我们还需要这样个中间层，能够帮助实现在架构中不同服务之间的智能化管理。

最早出现的集成模式是这样个的结构，在架构中的各服务之间设置个类似于的中间件，这个中间件充当整个架构的中央管理器的作用。

现在服务的提供者和请求者之间有了个智能的中转站，服务的请求者不再第章绪论需要了解服务提供者的具体细节。

这看上去是个好的结构。

事实上，传统的，就是通过这样种中转站的方式来试图解决企业内部的应用整合问题。

传统的，往往使用如和等的消息中间件进行跨平台，分布式的程序交互，修改企业资源规划以达到新的目标，使用中间件等方法来进行数据分配。

因此，实际上传统的是部件级的重用。

很不幸的是，由于基于部件的架构没有统对象，也可以是等等。

它支持多种传输协议，等，并整合了许多流行的开源项目，比如等。

虽然没有基于来构建其架构，但是它为，业务集成容器提供了适配器，因此可以很好地与容器整合在起。

而更关注其灵活性易开发性以及高效性。

从年发表版本以来，吸引了越来越多的关注者，成为开源中的支独秀。

目前许多公司都使用了，比如，以及等公司。

版本以后集成，面向的动态模型系统，支持动态热部署。

的主要应用领域为了应对越来越复杂繁琐的企业级信息系统平台，面向服务体系架构是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。

选用标准接口包装旧的应用程序把新的应用程序构建成服务，那么其他应用系统就可以很方便的使用这些功能服务。

只要人员选用标准接口包装旧的应用程序把新的应用程序构建成服务，因为使用户可以不受限制地重复使用软件，把各种资源互连起来，那么其他应用系统就可以很方便的使用这些功能服务。

第二章关键技术和规范支撑的关键是其消息传递架构企业服务总线。

是传统中间件技术与服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确安全传递和高效。

让不同的应用服务协调运作，实现不同服务之间的整合与通信。

在不同领域具有非常广泛的用途电信领域能够在全方位支持电信行业，运营支撑系统的应用整合概念。

是理想的电信级应用软件承载平台。

电力领域能够在全方位支持电力行业的数据整合概念，是理想的，数据采集与监视控制系统系统数据交换平台。

金融领域能够在全方位支持银企间业务处理平台的流程整合概念，是理想的，企业对企业的电子商务模式交易支撑平台。

电子政务能够在全方位支持电子政务应用软件业务基础平台信息共享交换平台决策分析支撑平台和政务门户的平台化实现。

管理扩展在编程语言中定义了应用程序以及网络管理和监控的设计模式体系结构应用程序接口以及服务。

通常使用来监控系统的运行状态或管理系统的些方面，比如重新加载配置文件清空缓存等。

优点可以非常容易的使应用程序具有被管理。

伸缩性的架构每个服务可以很容易的放入到中，每个的实现都提供几个核心的服务，你也可以自己编写服务，服务可以很容易的被部署，取消部署。

主要提供接口，允许有不同的实现。

体系结构分为以下四个层次设备层主要定义了信息模型。

在中，各种管理对象以管理构件的形式存在，需要管理时，向服务器进行注册。

该层还定义了通知机制以及些辅助元数据类。

代理层主要定义了各种服务以及通信模型。

该层的核心是个服务器，所有的管理构件都需要向它注册，才能被管理。

注册在服务器上管理构件并不直接和远程应用程序进行通信，它们通过协议适配器和连接器进行通信。

而协议适配器和连接器也以管理构件的形式向服务器注册才能提供相应的服务。

分布服务层主要定义了能对代理层进行操作的管理接口和构件，这样管理者就可以操作代理。

然而，当前的规范并没第二章关键技术和规范有给出这层的具体规范。

附加管理协议定义的主要用来支持当前已经存在的网络管理协议，如等。

图架构图设备层定义了如何实现管理资源的规范。

个管理资源可以是个应用个设备或个服务，它们可以用开发，或者至少能用进行包装，并且能被置入框架中，从而成为的个管理构件，简称。

管理构件可以是标准的，也可以是动态的，标准的管理构件遵从构件的设计模式动态的管理构件遵从特定的接口，提供了更大的灵活性。

该层还定义了通知机制以及实现管理构件的辅助元数据类。

在规范中，管理构件定义如下它是个能代表管理资源的对象，遵循定的设计模式，还需实现该规范定义的特定的接口。

该定义保证了所有的管理构件以种标准的方式来表示被管理资源。

管理接口就是被管理资源暴露出的些信息，通过对这些信息的修改就能控制被管理资源。

个管理构件的管理接口包括能够执行的操作能发出的通知事件能被接触的属性值管理构件的构建器。

管理构件通过公共的方法以及遵从特定的设计模式封装了属性和操作，以便暴露给管理应用程序。

例如，个只读属性在管理构件中只有方法，可读写的属性既有又有方法。

其余的的构件，例如代理提供的各种服务，也是作为个管理构件注册到代理中才能提供相应的服务。

对管理构件的存储位置没有任何限制，管理构件可以存储在运行代理的虚拟机的类路径的任何位置，也可以从网络上的任何位置导入。

定义第二章关键技术和规范了四种管理构件标准开放动态和模型管理构件。

每种管理构件可以根据不同的环境需要进行制定。

代理层是个运行在虚拟机上的管理实体，它活跃在管理资源和管理者之间，用来直接管理资源，并使这些资源可以被远程的管理程序所控制。

代理层由个服务器和系列处理被管理资源的服务所组成。

服务器为代理层的核心，设备层的所有管理构件都在其注册，管理者只有通过它才能访问管理构件。

管理构件可以通过以下三种方法实例化和注册管理代理本身通过另个管理构件远程应用程序。

注册个管理构件时，必须提供个唯的对象名。

管理应用程序用这个对象名进行标识管