企业服务架构论文.doc

《企业服务架构论文.doc》由会员分享，可在线阅读，更多相关《企业服务架构论文.doc（42页珍藏版）》请在三一文库上搜索。

1、企业服务架构论文企业服务架构论文 基于面向服务架构的电力企业应用集成 摘要 随着信息化的发展，应用系统的集成问题越来越受到人们的关注，企业要求针对其 业务过程对信息进行整合管理，分布式异构系统的集成问题是企业应用集成要解决的关 键问题。传统应用集成由于实现技术在异构平台互操作、接口统一描述等方面存在局限 性导致集成系统缺乏动态可扩展性，异构平台间的互操作性差，且无法摆脱技术厂商及 应用环境的限制，因而企业应用集成的目标很难实现。面向服务架构(Service Oriented Architecture，SOA)的提出为企业应用集成提供了一种动态、可扩展的架构方案。Web Services 的逐渐

2、成熟化为 SOA 以及企业应用集成提供了技术支持。 本课题首先在分析传统企业应用集成解决方案不足的基础上探讨了 SOA，分析了 SOA 的实现关键及实现方式，在此基础上给出了以 Web Services 作为实现技术的“Web Services+SOA”的面向服务应用集成方案，设计了以 Web Services 为基础的面向服务集 成框架，并分析了面向服务集成软件的层次结构，最后结合某电力企业调度系统的实际 情况，引入了 SOA 的思想到其应用集成中，通过实验系统的开发，验证了解决方案的 可行性。 关键词：异构；应用集成；面向服务；Web Service Abstract With the d

3、evelopment of internet/intranet and the distributed systems increasing，the application system integration is sharing us in the face. But traditional Enterprise Application Integration(EAI)has not only a great way to dynamic expansibility and interoperating in isomer us systems but also been restrict

4、ed by technical manufacture and application environments which is caused by the realization technology localization in interoperation，unification description of interface and loose couple etc. Service-Oriented Architecture (SOA) is brought forward by Gartner Group. And with Web Services development

5、and maturation，SOA has realization technology support. Based on analyzing the shortage of traditional EAI resolvents，SOA is described in this paper. And the realization modes and key of SOA are also anatomized.Then“Web Services+SOA“is put forward as the optimal resolve for EAI in actual technology l

6、evel. Next the author designs the services-oriented application integration system framework which is realized with Web Services. And systems hierarchy is also analyzed from software point of view. KEY WORDS: isomerous ；application integration；service-oriented；Web Services 目 录 摘要 .I Abstract II 1 绪论

7、 .1 1.1 课题背景与意义 .1 1.2 课题国内外现状 .1 1.2.1 国外的研究进展 .1 1.2.2 国内的研究进展 .2 1.3 本文的主要工作 .2 2 SOA 架构概述 .3 2.1 体系结构 .3 2.1.1 起源 .3 2.1.2 体系结构 .3 2.1.3 SOA 优越性6 2.2 SOA 系统的实现过程6 2.2.1 系统协作 .6 2.2.2 SOA 实现技术8 2.2.3 实现 SOA 的方法学 .9 2.3 系统安全控制 10 3 基于 WEB SERVICE 的电力企业应用集成 13 3.1 电力企业信息化建设中问题分析及应用集成的必要性 13 3.2 电力企

8、业应用集成(EP-EAI)的提出 14 3.3 以 Web Service 技术设计，实施 EPEAI .15 3.3.1 Web Service 技术.15 3.3.2Web Service 下电力企业平台系统的总体结构设计16 3.4 SOA 与 WEB服务 .17 4 调度系统设计 19 4.1 系统设计 19 4.2 模块的设计 19 4.2.1 管理者登录模块 19 4.2.2 数据管理模块 22 4.2.3 控制模块 24 4.2.4 设定整合模块 24 4.3 数据整合和集成需求 24 5 调度系统的实现 26 5.1 系统信息显示的实现 26 5.2 信息显示的实现 27 5.

9、2.1 风机的数据显示 27 5.2.2 数据的直观图 29 5.3 控制、设定的记录的实现 31 结论 35 参考文献 36 致谢 38 外文文献翻译原文 39 外文文献翻译译文 43 1 1 绪论 1.1 课题背景与意义 SOA（Service-Oriented Architecture，面向服务的架构）是一种建立、维护、管 理 IT 系统和业务流程的方法。在 SOA 架构下，以服务或组件形式出现的业务逻辑可以 被共享、重用和配置，如此以来，应用集成变得轻而易举。过去，应用开发一直采用先 开发、后集成的模式，而在 SOA 架构下，任何一种应用都由若干种服务组成，这些服务 在开发之初就已经考

10、虑到重用问题，提供了标准的接口，可以被各种应用和其他服务所 调用。现在随着网络技术的发展，在信息化建设中产生了大量为满足产品或服务需要的 软件系统，如：ERP、CRM、OA、CAD 等一系列、电子商务和电子政务软件系统，但其间 却往往缺少关联和通讯，导致这些组件成为了一个个“孤岛” ，但这些组件恰恰又是企 业不能放弃的重要投资。而 SOA 架构出现，则使在需要改变 IT 系统时的灵活性大为增 加。本论文的意义在于把 SOA 理论应用于轻量级 SOA 系统的实现上，将革命性地改变传 统的基于 C/S、B/S 结构的信息系统实现方式，使作为主体的人、作为客体的企业以及 经由网络传输的数字信息世界三

11、者无缝的结合起来，实现不受任何时间和空间局限的互 动，最终目的是根本性地改变人与数字世界、人与真实世界的交互方式，能够为任何信 息系统的实现、整合、跨平台服务提供新的模式1。 1.2 课题国内外现状 1.2.1 国外的研究进展 1996 年，Gartner 最早提出 SOA（Service-Oriented Architecture，面向服务架构） 的思想，2002 年 12 月，Gartner 提出 SOA 是“现代应用开发领域最重要的课题”,预计 到 2008 年，SOA 将成为占有绝对优势的软件工程实践方法。Gartner 为 SOA 描述的远景 目标是:在于让 IT 变得更有弹性，以更

12、快地响应业务单位的需求，实现实时企业 （Real-Time Enterprise） 。SOA 是在计算环境下设计、开发、应用、管理分散的逻辑 （服务）单元的一种规范。这个定义决定了 SOA 的广泛性。SOA 要求开发者从服务集成 的角度来设计应用软件。SOA 要求开发者超越应用软件来思考，并考虑复用现有的服务。 SOA 这个术语代表了一种模型，该模型中自动化逻辑被分解成了更小的独立逻辑单 元。聚集起来，这些单元就组成了一个较大的业务自动化逻辑块。目前，世界上大的软 件公司 Microsoft，IBM，SUN 等纷纷推出自己架构的基于 SOA 信息开发平台和解决方案， 使得这些公司走在 SOA

13、技术发展的最前沿。下面，就这些新的实现作功能分析： 1) Microsoft 的 Indigo 平台 Microsoft 用于构建基于 SOA 应用程序的 Indigo 平台，使得专门用于创建 SOA 应用 程序的技术得到广泛应用。Indigo 允许目前创建面向对象应用程序的开发人员采用.NET Framework 以相似的方式来创建面向服务的应用程序。同时为了让这些应用程序能够与 运行在 Windows 和其他平台上的软件有效地进行交互，Indigo 还实现了 SOAP 和其他 2 Web 服务技术，这样开发人员就可以创建可靠、安全且能够与运行在任何系统上的软件 实现互操作的事务型服务2。

14、Indigo 基于.NET Framework 2.0 并对其进行了扩展，提供了创建由客户端访问的 服务的基础，这一基础主要由一组运行于公共语言运行库(CLR)上的类来实现。客户端 与服务通过 Indigo 的内置协议 SOAP 进行交互。Indigo 采用了一些更新的 Web 服务技术， 这些技术统称为 WSDL 规范。这些文档定义了用于添加可靠消息传输、安全性、事务以 及更多基于 SOAP 的 Web 服务的多供应商方式。 2) IBM 的 ESB（Enterprise Services Bus，企业服务总线）平台 IBM 实现了基于 Web Sphere 产品族的 ESB 平台，构成了

15、IBM SOA 的基础架构，提供 了 ESB 的基本功能，如服务路由、消息转换、中介、传输协议、消息传递模式、服务集 成方式等，以及 ESB 的非功能属性的支持，如安全性、事物、性能、可靠性、服务的监 控和管理等3。通过不同模块可以支持您在复杂的企业 IT 环境中构建稳定、安全、可 靠的 ESB，为整个企业基础设施向 SOA 架构迁移提供支持。 3) SUN 的“SOA Path”(SOA 路径)服务导向架构 这一 SOA 实际执行方式与 Sun 提出的服务导向架构(SOA)解决方案计划组成完整的 体系。这一 SOA 实际执行方式在 SOA 技术的整个生命周期内-从概念论证、准备阶段， 到实际

16、执行-等各个关键时刻，采用 Sun 的 Java 平台和 SOA 执行经验。 1.2.2 国内的研究进展 目前，国内针对 SOA 的研究，主要体现在部分中间件产品上，而基于 SOA 的 ESB 整 体解决方案非常缺乏，更多的是一些中间件产品和协同软件产品。但是，有些公司已经 推出了一些与 SOA 密切相关的软件产品。如： 1)中和威推出了国内首个支持 SOA 架构的 ESB 产品InterBus，方便了企业级信 息系统的应用整合与服务。 2)北京点击公司开发的基于 SOA 的协同系统 GK-Star，已经在一些政府，军队，电 信的行业有了应用。 3)上海(复旦)协达软件科技有限公司也在今年年初

17、推出了基于 SOA 的协同软件和解 决方案。这些基于 SOA 的系统平台有些共同特性，都是基于原有的一些中间件产品，在 外围增加一些 Web 服务包装器，再把一些消息处理机制整合到原有的系统中，实现在面 向服务的开发中模块的松散耦合。 1.3 本文的主要工作 介绍了 SOA 在国内外研究状况，论文研究的意义、研究背景、研究内容等。对 SOA 体系结构做了全面的介绍，接着给出了 SOA 系统实现模型，分析现有的 Web 服务和 SOA 的区别、安全控制实现。给出了 SOA 在电力系统中应用的范围和电力企业应用集成(EP- EAI)的理论，结合电力企业的实际情况给出 Web Service 下电力

18、企业平台系统的总体结 构。应用 Web Service 完成了系统逻辑结构的设计，包括 4 个模块的设计，对 4 个模块 3 的设计思想以及具体的实现过程进行讲解。最后完成对该系统的开发和调试。 2 SOA 架构概述 2.1 体系结构 2.1.1 起源 1996 年，Gartner 最早提出 SOA（Service-Oriented Architecture，面向服务的体 系结构）的思想，2002 年 12 月，Gartner 提出 SOA 是“现代应用开发领域最重要的课 题” ，预计到 2008 年，SOA 将成为占有绝对优势的软件工程实践方法。Gartner 为 SOA 描述的远景目标是：

19、在于让 IT 变得更有弹性，以更快地响应业务单位的需求，实现实 时企业（Real-Time Enterprise）8。 研究 SOA，不能不关注软件构件技术，基于构件技术提供网络服务是 SOA 的重要思 想起源，做 SOA 研发的公司无不对构件技术有一定研究。在 SOA 架构中，流动的应该是 构件，而不是已经集成在一起的整个系统软件。一个用户选择了一款软件，一般都有定 制的要求，尤其是系统管理软件，如 ERP、CRM 等。构件化技术为不同用户的定制要求 提供了可能，把常用功能做成可供选择的构件，用户就有了更为灵活的选择。没有构件 化时，软件系统的各个部分是紧密结合在一起的，因而会牵一发而动全身

20、，采用了构件 化技术后，软件的各个功能模块就可以独立地实现、升级，而不会影响系统整体。 理论上，面向服务的体系结构这种思想，在其简易性上，十分吸引人。如果你能够 用定义很好的机构封装应用，就有可能将一个单一的应用加入到一个服务的集合中。封 装的过程创建了一个抽象的层，屏蔽了应用中复杂的细节（不用关心用的是哪一种编程 语言，什么操作系统，应用程序用的是什么数据库产品） 。唯一相关的就是服务所描述 的接口。 SOA 的优势在于高可复用性，灵活性，以及更好的扩展性和可用性。经过 20 年的软 件体系结构的创新，在一系列应用开发项目中，SOA 的优点得到了体现。 SOA 的首次尝试，只是用于新的业务逻

21、辑的开发，只提供有限的功能，而系统的主 体部分，并不采用面向服务的原理构建。另外，竞争和创新意味着多样的，不同的 SOA 实现方式使得集成没那么容易。 统一采用一种方案，共同获取这是不可能做到的。因此现实世界中，需要能够融合 各种差异。吸引早期的教训，各方供应商最终将聚在一起，为 SOA 提供一个更好的框架。 SOA 作为新一代的软件构架，在未来 510 年里将给软件产业带来革命性的变化。 在 SOA 时代，任何一个大的应用软件系统，都不再由一个软件开发商独立完成，而是由 不同厂商生产的基于基础标准和接口的中间件相互协作完成。到时会出现各种消息通信、 内容管理系统、工作流引擎、身份认证提供者、

22、整合应用和门户服务器等不同类型的中 间件厂商。 2.1.2 体系结构 4 SOA 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之 间定义良好的接口和契约联系起来7。接口是采用中立的方式进行定义的，它应该独立 于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务 可以以一种统一和通用的方式进行交互。 这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的 松耦合。松耦合系统的好处有两点，一点是它的灵活性；另一点是，当组成整个应用程 序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧 耦合意味着应用程序的不同

23、组件之间的接口与其功能和结构是紧密相连的，因而当需要 对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以 适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行 业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活 地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以 对完成或执行任务的方式进行必要的更改。 SOA 是一种企业架构，因此，它是从企业的需求开始的。但是，SOA 和其它企业架 构方法的不同之处在于 SOA 提供的业务敏捷

24、性。业务敏捷性是指企业对变更快速和有效 地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务 敏捷的架构意味着创建这样一个 IT 架构，它可以满足当前还未知的业务需求。要满足 这种业务敏捷性，SOA 的实践必须遵循以下原则： 业务驱动服务，服务驱动技术 从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一 方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面同样要理解服务 与提供这些服务的底层技术之间的关系。 业务敏捷是基本的业务需求 SOA 考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求” ，而不是 处理一些业务上的固定不变

25、的需求。从硬件系统而上的整个架构都必须满足业务敏捷的 需求，因为，在 SOA 中任何的瓶颈都会影响到整个 IT 环境的灵活性。 SOA 的体系结构提供了一种方法，通过这种方法，可以构建分布式系统来将应用程 序功能作为服务提供给终端用户。其组成元素可以分成功能元素和服务质量元素。图 2- 1 展示了 SOA 体系结构堆栈以及在一个面向服务的体系结构可能观察到的元素。 5 图 2-1 SOA 体系结构元素 SOA 堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一半集中 于体系结构的服务质量方面7。这些元素详细描述如下，功能性方面包括： 传输是一种机制，用于将来自服务使用者的服务请求传

26、送给服务提供者，并且将 来自服务提供者的响应传送给服务使用者。 服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服务使用者 可以就将要请求的内容和将要返回的内容进行沟通。 服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用服务以及 成功地调用服务需要什么数据。 服务描述实际可供使用的服务。 业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规则进行调 用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就产生了业务流程 可以由不同粒度的服务组成的观念。 服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服务注册中 心发布它们的服务，而服务使用

27、者可以通过服务注册中心发现或查找可用的服务。服务 注册中心可以给需要集中式存储库的服务提供其他的功能10。 服务质量方面包括： 策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可用于 使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能和服务 质量两个区中都有策略功能。 功能服务质量 服 务 注 册 业务处理 服务 传输 服务描述 服务通信协议 策 略 安 全 事 务 管 理 6 安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访问控 制。传输是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要使用一组 服务来完成一项业务功能，则所有的

28、服务必须都完成，或者没有一个完成。 管理是属性集，可以应用于管理提供的服务或使用的服务。 2.1.3 SOA 优越性 SOA 的优点： 编码灵活性 可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这些 都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务实现 方式本身也可以灵活使用。 明确开发人员角色 例如，熟悉 BES 的开发人员可以集中精力在重用访问层，协调层开发人员则无须特 别了解 BES 的实现，而将精力放在解决高价值的业务问题上。 支持多种客户类型 借助精确定义的服务接口和对 XML、Web 服务标准的支持，可以支持多种客户类型， 包括 PDA

29、、手机等新型访问渠道。 更易维护 服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。 更好的伸缩性 依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独 立调整，以满足服务需求。 更高的可用性 该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提 供者的实现细节，这样服务提供者就可以在 Web Logic 集群环境中灵活部署，使用者可 以被转接到可用的例程上。 2.2 SOA 系统的实现过程 SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实 现并以软件的形式存在的更加具体的观念和技术。此外，

30、它还需要安全性、策略管理、 可靠消息传递以及审计系统的支持，从而有效地工作。还可以通过分布式事务处理和分 布式软件状态管理来进一步地改善它。整个系统的实现要完全基于服务的理念去设计， 把 SOA 的原则应用到系统从设计到开发的每个环节。 2.2.1 系统协作 图 2-2 展示了 SOA 中的协作。这些流程遵循“查找、绑定和调用”范例，其中，服 务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹配的服务。如 7 果服务存在，注册中心就给使用者提供接口契约和服务的端点地址。下图展示了面向服 务的体系结构中协作支持“查找、绑定和调用”范例的实体。 图 2-2 SOA 中角色协作 SOA

31、 中的角色包括： 服务使用者：服务使用者是一个应用程序、一个软件模块或需要一个服务的另一 个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。 服务使用者根据接口契约来执行服务。 服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用 者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现 和访问该服务。 服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务的存储 库，并允许感兴趣的服务使用者查找服务提供者接口。 SOA 中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某一种 （或多种） 。SOA 中的操作

32、包括： 发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和调用它。 发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。 绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信息来 调用服务12。 SOA 中的构件包括： 服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。 服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务 发布 查找 服务注册 服务描述 服务消费 者 服务提供 者 服务 服务描述 绑定和 调用 8 的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和服务质量级别。 除了动态服务发现和服务接口

33、契约的定义之外，面向服务的体系结构还具有以下特 征： 服务是自包含和模块化的。 服务支持互操作性。 服务是松散耦合的。 服务是位置透明的。 服务是由组件组成的组合模块。 2.2.2 SOA 实现技术 实现 SOA 的核心技术 Web 服务。正如我们前面所讲的，服务是整个 SOA 实现的核心， Web 服务相关技术自然成为实现 SOA 的首选。 XML XML 1.0(可扩展标记语言，Extensible Markup Language)标准是一个基于文本的 World Wide Web 组织(W3C)规范的标记语言。与 HTML 使用标签来描述外观和数据不同， XML 严格地定义了可移植的结构

34、化数据。它可以作为定义数据描述语言的语言，如标记 语法或词汇、交换格式和通信协议。 SOAP 简单对象访问协议(Simple Object Access Protocol)是一个基于 XML 的，用于在 分布式环境下交换信息的轻量级协议。SOAP 在请求者和提供者对象之间定义了一个通信 协议，这样，在面向对象编程流行的环境中，该请求对象可以在提供的对象上执行远程 方法调用。因为 SOAP 是平台无关和厂商无关的标准，因此尽管 SOA 并不必须使用 SOAP，但在带有单独 IT 基础架构的合作伙伴之间的松耦合互操作中，SOAP 仍然是支持 服务调用的最好方法。 W3C SOAP 1.2 规范在服

35、务请求者和服务提供者之间定义使用 XML 格式的消息进行通 信。将应用程序请求(在 XML 中)放入 SOAP 信封中(也是 XML)，并从请求者到提供者发送 应用程序请求，提供者发回的响应也采用相同的形式。最近 SOAP 被称为面向服务的架 构协议(Services-Oriented Architecture Protocol)。SOAP 的优点在于它完全和厂商 无关，相对于平台、操作系统、目标模型和编程语言可以独立实现。另外，传输和语言 绑定以及数据编码的参数选择都是由实现决定的。 WSDL Web 服务描述语言 WSDL(Web Services Description Language

36、)是一个提供描述服 务 IDL 标准方法的 XML 词汇。Web 服务描述语言(WSDL)规范定义了一个 XML 词汇表，该 词汇表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。我们能 够将 Web 服务定义为软件，这个软件通过描述 SOAP 消息接口的 WSDL 文档来提供可重用 的应用程序功能，并使用标准的传输协议来进行传递。 9 WSDL 描述包含必要的细节,以便服务请求者能够使用特定服务: 请求消息格式 响应消息格式 向何处发送消息 WSDL 是基于 XML 的，因此 WSDL 文档是计算机可读的(machine-readable)。 这样开发环境使用 WSDL 将集

37、成服务的流程自动处理到请求者应用程序。例如 Web Sphere Studio 产生一个 Java 的代理对象，它能够像本地对象一样实现服务，但是实际 上代理对象仅仅处理请求的创建和响应消息的解析。不管服务是否用 Java、C#或者其他 的语言实现，生成的 Java 代理对象都能够从 WSDL 描述中调用任何的 Web 服务。实际上， WSDL 不能像编程语言那样描述实现细节。 UDDI 统一描述、发现和集成(Universal Description, Discovery and Integration)规 范提供了一组公用的 SOAPAPI，使得服务代理得以实现。UDDI 为发布服务的可用

38、性和发 现所需服务定义了一个标准接口(基于 SOAP 消息)。UDDI 实现将发布和发现服务的 SOAP 请求解释为用于基本数据存储的数据管理功能调用。 为了发布和发现其他 SOA 服务，UDDI 通过定义标准的 SOAP 消息来实现服务注册 (Service Registry)。注册是一种服务代理，它是在 UDDI 上需要发现服务的请求者和 发布服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开 发工具并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。SOA 不需 要使用 UDDI，但由于 UDDI 是建立在 SOA 上来完成自身工作的，所以 UDDI 是服

39、务发现的 一个好的解决方案。 相互复制 查询 注册 注册 Web 服务 UDDI 注册节点 Web 服务 UDDI 注册节点 Web 服务 图 2-3 UDDI 节点间的数据复制 2.2.3 实现 SOA 的方法学 10 SOA 强调松散耦合，强调跨平台集成，这与模型驱动的架构和开发不谋而合。模型 驱动的架构和开发(Model Driven Architecture,MDA 以及 Model DriveDevelopment,MDD)并没有把业务模型和平台无关模型分开来，而是把平台无关模 型做为起点。 MDA 由提出 CORBA 的 OMG 模型提出。MDA 认为架构设计师首先要对待创建的系统

40、有 一个形式化的 UML 的模型。MDA 首先给出一个平台无关的模型来表示系统的功能需求和 用例，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模 型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。 基于 MDA 的思想，利用 MDD 方式，我们可以对 SOA 进行建模，在此基础上，实现各 种形式的模型转换或扩展实现 SOA。 2.3 系统安全控制 通过修正和重建网络、计算机系统以及软件来增强安全性和可靠性可能在短期是必 要的，但是这些不足以满足整个国家的网络的安全要求，很难在已有复杂的系统中增加 安全性的要求。既使一切最好的防范措施都被充分地使用，如果对信

41、息安全没有本质上 的改变，我们仍将无止境地修补“堤坝上的漏洞” 。因此，全新安全模式的研发需要从 基础软件架构开始。通过对这些年来的软件安全问题进行计算模型上的分析，可以看出 原有的软件体系架构已经无法满足日益复杂软件系统对安全的要求，新的、更安全的软 件架构呼之欲出，SOA 就是新安全体系结构的代表。 传统的软件架构并没有在安全性方面进行系统级支持，这是由于在软件产业发展的 初期，人们更关心的是软件的功能和效率，而对软件的安全并不是很重视。随着计算机 和软件开发技术的普及，软件的安全隐患陆续暴露出来，从病毒、盗版、到蠕虫，软件 的安全性面临巨大的挑战。PKI 就是在这种背景下诞生的安全架构，

42、其部分解决对于信 息认证及反盗版方面的问题，但对于原有的软件体系架构自身的缺陷，PKI 仍不能全面 保护软件和信息的安全，这也是大量破解软件存在的主要原因之一。 SOA 架构为信息安全提供了新的支持平台。SOA 中所提供的服务必需通过权威的认 证机构的认证，才能对外发布。这就保证了服务本身的可靠性，当用户从权威服务提供 机构获得所需服务时，不必再次检测服务的可靠性，因为安全检测工作已经由服务提供 者完成，这是 SOA 对服务使用者提供保护。对于向服务器申请服务的用户来说，其也必 需通过相应的安全认证，只有合法的用户才能获得相应的服务，这样 SOA 对服务提供者 也提供保护。在 SOA 中，软件

43、的执行过程中不再像过去那样将要在本地安装所有的部分， 而是动态地从网上根据需要请求服务，软件的各个部分分散在 Internet 中，需要时进 行动态地组合。这种分散的软件结构，将安全责任由传统的软件使用者全部负担，转换 为由软件的使用者和提供者共同负担，因而明确了责任，降低了单个用户的安全风险。 对于一些不必在用户端执行的服务，可以在服务方执行，用户只要知道其结果就可以了， 从而进一步降低了安全隐患。总地看来，SOA 架构同时对服务提供者和服务使用者提供 11 保护，从安全性角度来说是必需的，当然这种保护是以牺牲自由度和效率为代价。 以构件化为主要特征的操作系统，在继承了 SOA 在信息安全方

44、面的优势的同时，又 结合 Application Domain 技术，提高了自由度和执行效率。Application Doma 是比较 新的技术，其在微软的新一代操作系统 Longhorn 中占有重要地位。Application Domain 可以根据需要设置域（Domain）中所执行程序的权限，这使得程序的执行必需符 合域中所授予的权限，以此达到保护系统的目的。在操作系统中，通过认证的构件可以 在权限较高的域中执行，如可以对文件系统进行访问。而对于没有通过认证的构件，可 以让其在权限较低的域中执行，如禁止其访问本地文件。这样通过域的权限设置，可以 将程序的执行控制在限定的范围内，避免对系统造

45、成危害。这样就解决了自由度和安全 性不能两全的问题。 总之，SOA 是一次信息系统架构上的较大变革，其在提供了强有力的计算资源的同 时，也为信息安全提供了系统级的支持。以软件构件化为基础的新的计算模型，将对 SOA 的深度开发与普及起促进作用。 华北电力大学本科毕业设计（论文） 13 3 基于 Web Service 的电力企业应用集成 随着信息技术的不断发展，电力企业中的信息系统应用越来越多。这些系统应用在 不同的部门，彼此之间存在信息和数据重复，没有畅通和完整的信息交流与共享，如一 个个的信息孤岛飘浮于企业信息海洋之中，这样就造成了电力企业经常出现的信息和数 据更新的不同步，业务处理的迟缓

46、，跟不上能源市场变化节奏，从而不能为电力市场提 供准确的信息数据，以及不能适应迅速增长的用电服务需求。 3.1 电力企业信息化建设中问题分析及应用集成的必要性 电力企业发展过程中已陆续应用了一定规模的信息系统，而这些信息系统、应用模 块是电力企业在不同时期，不同的发展阶段出资购买或引进技术进行开发的，由于开发 时期不一，开发公司不一，导致在电力企业的不断发展中这些系统和模块的彼此分割， 相互独立，企业不能对这些系统和应用模块产生的数据资料进行整体、有效的利用，从 而形成了信息孤岛。随着电力企业信息化的不断深入，ERP、CRM、SCM 等先进的企业信 息系统引入电力行业，但是由于上述问题的存在，

47、电力企业中所引入的一些信息系统无 法把信息数据以及分析结果及时的提供给其他相关信息系统进行信息共享，这样对于电 力企业来说，不能有效的彼此利用信息，这些系统并没有在很大程度上来降低工作的复 杂程度，一直许多该使用的信息系统不能有效的使用起来，更有甚者被搁置一旁不再使 用，图 3-1 列出了电力企业信息系统之间的复杂连接关系。 变电运行系 统 ERP 线路 GIS CRM财务系统 调度系统 数据库系 统 SCM 图 3-1 企业内部信息系统之间的关系 如图 3-1 所示，在各信息系统之间只能依靠彼此一对一的这种单一的方式进行互相 间的信息交换，每个应用系统部承受着巨大的负担，各个系统之间大量存在

48、着信息的重 复收集和重复分析，相关的信息不能及时有效的传递给相关系统，在这种状况下，电力 华北电力大学本科毕业设计（论文） 14 企业的信息交换与处理只能在提供信息的应用系统中处理完成之后，才能为需求信息的 应用系统用来进行分析处理，按乏实时性、同步性。而对于电力企业来说信息收集和处 理的有效和同步完成， 则是电力企业用来满足用户对质量和服务要求日益提高的重要 手段，是电力企业适应电力市场发展的手段。因此，为了加快电力企业及电力市场的发 展，更好地满足用户需求，迫切需要电力行业的一些相关专业信息系统进行集成 。 3.2 电力企业应用集成(EP-EAI)的提出 为了避免上述信息利用上存在的问题，

49、为了满足客户和商业伙伴对其业务处理反应 速度的要求，电力企业只能对其企业内的信息系统做出调整，把原来分散、独立的系统 及应用和数据库等进行一定的集成，以提高电力企业的运营效率，从而满足客户和商业 伙伴的需求。这种为适应市场竞争，依靠一定的 IT 技术来实现电力企业内部系统的集 成称为电力企业应用集成 EP-EAI(Electric power enterpriseEnterprise Application Integration)。 EPEAI 为电力企业内部分散的系统构建了一个进行集成的基础，将进程、软件、 标准和硬件联合起来，EP-EAI 通过对电力信息系统如调度系统、生计系统、变电运行系 统、线路 GIS、现场管理系统以及 ERP、CRM、SCM 和数据库等的双向互联来到达各个系 统之间的无缝共享，并且通过对系统的集成使得基于 IT 技术的应用和业务处理系统的 部署变得简便有效，如图 3-2 所示。 EP-EAI ERP 变电运行系 统 CRM 调度系统 SCM 线路 GIP 财务系统 数据库系统 图 3-2 进行集成的系统及应用之间的关系 EPEAI 为电力企业信息系统构建的集成基础，对原来分散的系统和应用在一定的 技术支持下进行集成