【电力行业标准(DL)】 能量管理系统应用程序接口(EMS-API)第1部分：导则和一般要求

ICS27.100
备案号：22290-2008
中华人民共和国电行业标准
DL/T 890.1 — 2007 / IEC 61970 - 1: 2005能量管理系统应用程序接口（EMS-API）第1部分：导则和一般要求　
Energy management system application program interface (EMS-API) -Part 1: Guidelines and general requirements(IEC61970-1:2005,IDT)
2007-12-03发布
2008-06-01实施
中华人民共和国国家发展和改革委员会发布
DL/T890.1—2007
本部分是根据《国家发展改革委办公厅关于印发2006年行业标准项目计划的通知》（发改办工业【2006］1093号）的安排制定的：DL890标准是采用IEC61970国际标准《能量管理系统应用程序接口（EMS-API）》制定的，主要包括公共信息模型（CIM）和组件接口规范（CIS）两方面内容，由以下部分组成：DL/T890.1能量管理系统应用程序接口（EMS-API）第1部分：导则和一般要求；DL/T890.2能量管理系统应用程序接口（EMS-API）第2部分：术语；DL/T890.301能量管理系统应用程序接口（EMS-API）第301部分：公共信息模型（CIM）基础；IEC61970-302能量管理系统应用程序接口（EMS-API）第302部分：公共信息模型（CIM）财务、能量计划和备用；
DLZ890.401
IEC61970-402
能量管理系统应用程序接只（EMS-API）第401部分：组件接口规范（CIS）框架能量管理系统应用程序接口（EMS-API）第402部分：组件接口规范（CIS）-公共服.IEC61970-403.能量管理系统应用程序接口（EMS-API）第403部分：组件接口规范（CIS）-通用数据访问；
IEC61970-404
据访问；
IEC61970-405
件和订阅；
IEC61970-407
列数据访问；
能量管理系统应用程序接口（EMS-API）第404部分：组件接口规范（CIS）-高速数能量管理系统应用程序接口（EMS-API）第405部分：组件接口规范（CIS）-通用事能量管理系统应用程序接口（EMS-API）第407部分：组件接口规范（CIS）-时间序能量管理系统应用程序接口（EMS-API）第453部分：组件接口规范（CIS）-图表定IEC61970-4531
义交换（公共图形交换)；
DL/T890.501能量管理系统应用程序接口（EMS-API）第501部分：组件接口规范（CIS）-公共信息模型的资源描述框架（CIMRDF）模式。本部分等同采用IEC61970-1：2005《Energymanagement system application program interface（EMS-API）-Part1：Guidelinesandgeneralrequirements》。它提供了应用EMS-API接口标准所需要的一组指导原则和一般的基础设施能力。本部分描述了一个参考模型，为EMS-API标准其他部分的应用提供一个框架。
本部分的附录A、附录B、附录C、附录D是资料性附录。本部分由中国电力企业联合会提出。本部分由全国电力系统管理及其信息交换标准化技术委员会归口并负责解释。本部分起草单位：国网电力科学研究院、山东大学、中国电力科学研究院、国家电力调度通信中心。本部分主要起草人：曹阳、许慕、云昌钦、潘毅、李毅松、王康元、李晓露。引言
DL/T890.1—2007
DL890标准采用EC61970国际标准。EC61970标准定义了能量管理系统（EMS）的应用程序接口（API)，目的在于便于集成来自不同厂家的EMS内部的各种应用，便于将EMS与调度中心内部其他系统互联，以及便于实现不同调度中心EMS之间的模型交换。将该国际标准转化为我国标准并贯彻执行，对于实现异构环境下软件产品的即插即用，使EMS与其他系统能互联、互通、互操作显然会有很好的作用。
本部分提供了应用EMS-API接口标准所需要的一组指导原则和一般的基础设施能力。本部分描述一个参考模型，为EMS-API标准其他部分的应用提供一个框架。这一参考模型是基于组件体系结构的，使得本标准的重点集中在一个控制中心环境中各种应用之间交换信息用的组件接口上。本模型也可以应用于控制中心各个应用系统和该控制中心环境之外的各个系统，如其他控制中心、独立系统运营机构（ISOs）、区域输电机构（RTOs）以及配电管理系统（DMS）之间类似的信息交换。本部分还包括集成基础设施的一般能力，这一基础设施虽然不是本标准的组成部分，但所提供的支持EMS-API接口标准的某些服务是必不可少的。1范围
能量管理系统应用程序接口（EMS-API）第1部分：导则和一般要求
DL/T890.1-2007
DL890的本部分提供应用EMS-API接口标准所需要的一组指导原则和一般的基础设施能力。本部分描述了应用这些标准的一些典型的集成场景和要集成的应用类型。本标准定义了一个参考模型，这个模型为应用EMS-API标准中的其他部分提供了一个框架。这一基于组件架构的参考模型使得本标准的重点集中于控制中心环境内各种应用之间交换信息的组件接口上。虽然EMS-API的首要目的是支持控制中心内各个应用的集成，但这个参考模型也可以应用于控制中心各个应用系统和该控制中心环境之外系统之间的信息交换，例如与其他控制中心、ISO、RTO以及配电系统之间的信息交换。本部分描述了本标准其他部分的作用，包括DL890中的公共信息模型（CIM）部分、DL890中的组件接口规范（CIS）部分和DL890中的技术映射部分。本部分还包括集成基础设施所需要的一般能力，该集成基础设施有利于通过CIS规定的组件接口交换信息。虽然集成基础设施本身并不是本标准的组成部分，但它所提供的支持EMS-API接口标准的某些基本服务是必不可少的。在第6章中列举了这些服务。本部分不规定特定的实现或产品，也不限制计算机系统应用内的信息表示。本部分规定了为支持不同广商提供的各种产品的互操作性所必需的外部可见接口，包括语义和语法。2规范性引用文件
下列文件中的条款通过本部分的引用而构成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。DL/T890.2能量管理系统应用程序接口（EMS-API）第2部分：术语DL/T890.301能量管理系统应用程序接口（EMS-API）第301部分：公共信息模型（CIM）基础3术语和定义
DL/T890.2中的术语和定义适用于本部分。4系统集成
4.1集成场景
能量管理系统是各种软件子系统（SCADA、发电控制、负荷预报等）的一个集合，为此领域（或部分为此领域）而形成的指导原则适用于一些不同的集成场景。这项工作认为具有独特接口的现有系统需要逐渐过渡到使用此标准中定义的接口。以下设想了不同类型的集成情况。虽然这是一些典型的场景，但也只是各种可能范例的一个子集。a）不同供应商开发的应用集成到一个同构系统中：在这一场景中，独立开发的应用组件［如最优潮流（OPF)】都集成到一个系统中（该系统包含支撑基础设施）。这允许系统集成商更容易地将单个组件集成到任何系统中，无论是已有系统或是新开发的系统。
b）独立系统间的在线数据交换：1
DL/T890.1—2007
控制中心需要与公司内部或企业间的其他独立系统进行通信。需要用松耦合的集成方案来交换信息。这样的例子包括与DMS、公司结算系统以及其他EMS之间的信息交换。企业集成场景通常属于这一范畴。
共享某些工程数据的独立系统的集成：c
这对应于来自不同厂商的应用包使用部分重叠的工程模型数据（例如线路阻抗）的情况。不同系统的相同应用之间串行化数据的交换：d)
使用文件传输技术可以实现有限的集成，在这种类型的导出/导入交换中使用约定的格式。这种场景的一个例子就是在电力系统模型交换时使用文件传输协议（FTP）和基于可扩展标记语言（XML）格式的文件（或文档）。e）·在一个同构系统中开发新的应用：厂商或电力企业在开发新应用并集成入他们现有的系统（不同于集成到其他系统）时在应用接口中使用这些标准。
4.2集成考虑
4.2.1概述
这些标准所要支持的集成范围分为以下两个粗略定义的范畴a）实现EMS或类似系统，软件组件的集成；b）独立系统的集成。
为了实现正确的交互，软件组件和系统都需要一个公共信息模型（CIM）来为被交换或访问的信息提供一个公共的、一致的含义（即语义）。例如，为了交换变压器阻抗信息，需要有变压器的设备分类以及阻抗值的属性名。有了这些信息，变压器的一个特定实例就与其对应的阻抗紧密联系起来。CIM（参见6.2）提供了这些现实世界对象的语义名（以及它们的属性、描述和与其他现实世界对象的关联）。然而，在其他方面，集成的这两个范畴，如下面章节中讨论的，有一些稍许不同的需求。EMS-API标准的意图是对两个范畴都进行处理，而且它们都以组件接口的形式呈现。4.2.2.系统内软件组件的集成
4.2.2.1概述
为了把独立开发的软件组件集成到一个系统中，需要处理几个问题。a）软件组件的交互：
为了使系统能够正常运行，软件组件需要以一种合作的方式来交互。这种交互可以采用性质访问、方法调用和事件处理的方式。为了支持软件组件的集成，应该确定包含性质、方法和事件的公共接口，并且规定有关使用它们的规范。只要在系统中存在相似的交互场景，一致接口模式的规范就可以简化系统的集成和维护。b）
初始化公共的工程模型数据：
实际电力系统以及相关信息由CIM所表达的工程数据模拟。各种软件组件共享这些工程数据的各个方面以实现其功能。当软件组件启动时，它需要用被仿真的实际系统的一个一致和精确的模型来进行初始化。用于访问这些公共、共享数据的公共接口为软件组件提供了初始化其内部模型的一个一致的机制。一旦初始化了，软件组件的交互机制就可以用来保持其工程模型为最新。
c）部署打包：
为了打包和交付给系统集成，软件组件需要以特定的形式来实现。当今软件行业所存在的几种主流技术框架各自有其打包格式。本标准规范应该提高实现可能性方面的灵活性，同时促进独立开发软件的集成。为了实现这一目标，软件组件交互应该以一种能够兼容特殊技术和语言的抽象形式来规定。
为支持这种类型的集成场景，组件接口使用的属性、方法和事件以及信息交换的数据内容都需要标2
准化。
4.2.2.2应用类别
DL/T890.1—2007
EMS-API标准的范围包括那些通常可以在控制中心环境见到的所有应用，以及支持实时运行所需要的与外部系统间的接口。可是，由于EMS-API标准的意图是定义接口标准，而不是定义标准应用，因此考虑EMS-API标准所支持的这个应用类别列表能够最好地理解本系列标准的范围。把CIS中规定的组件接口实际打包到应用中的工作将留给应用提供商完成；因此，任何试图根据名字来定义一系列单个应用的做法，都会对提供商造成不必要的限制。表B.1中给出了本标准所支持的应用类别和典型应用列表。下面是这一列表的摘要：监视控制和数据采集（SCADA）；告警处理；
拓扑处理；
网络应用；
负荷管理；
发电控制；
负荷预报；
电能量/输电计划；
会计结算；
维护计划；
-历史信息存档：
数据工程；
通用用户接口；
动态仿真；
调度员培训仿真；
-外部系统（例如：DMS、天气、售电力市场等）。4.2.3系统间的集成
在异构系统的集成中，运行环境和所施加的控制很可能没有相似之处，重点主要是在支持松耦合的异步“文档”交换上。在这一上下文中，“文档”可被看作一种大而丰富的数据结构，例如XML文档。文档交换意味着所交换的数据是复杂的、结构化的和自描述的。这种交换更可能涉及单个的、原子的信息传送，这里涉及如何处理该信息和/或在传输中所需操作的全部信息是自包含的，而不像多步事务中信息传送的处理可能视前面的信息传送或事件而定。4.3基于组件的接口
EMS-API标准的一个目的是通过开发组件接口标准来鼓励独立开发可重用的软件组件并促进它们在建设各种控制中心系统中的集成。软件行业，包括主要的能量管理系统（EMS）厂商和EMS应用程序供应者，都经历了从基于自顶向下的模块化软件设计的软件工程概念到面向对象方法以及最新精化的使用基于组件的体系结构的发展过程。由公共对象请求代理体系结构（CORBA）1)、Sun2”的EnterpriseJavaBeans（EJB）和Microsoft3）的分布式公共对象模型（DCOM）所倡导的组件模型是这一趋势的最好的例证（这三种组件模型在附录A中描述）。这些基于组件的方法也促进了不同来源的软件和完整系统的集成。对于这类任意对任意的集成，XMLWeb服务提供了另一种基于互联网的集成模型。XMLWeb服务允许应用利用早期被称为“文档交1）CORBA是OMG提供的产品的商标。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该产品的意思。如果其他等价产品能够证明可以得到相同的结果，也是可以使用的。2）Sun是美国Sun微系统公司的缩写。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该公司的意思。3）Microsoft是美国微软公司的缩写。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该公司的意思。3
DL/T890.1-—2007
换”的信息交换类型通过互联网来交换和共享数据，并不关心操作系统和编程语言。这些服务提供了一种在企业对企业（B2B）信息交换中更为普遍的组件执行环境的一个例子。（参见附录A中的XMLWeb服务描述）
基于组件的接口对EMS-API的影响是把焦点转移到开发交换和访问公共信息的软件组件接口标准上，而不是对提供这些能力的集成框架服务进行标准化。预期的前景是支持这些标准的应用能够独立地，交付并重用于多个系统。虽然在实际的系统中可能还需要其他基础设施服务，如目录服务和安全性，但这并不是本标准的目的。实际上，它们是系统集成者或系统提供者所需要考虑的领域（即作为EMS系统平台的一部分，而不是可重用的即插即用组件）更为恰当。EMS-API标准的目的不是开发中间件的标准接口。实际上，目的正相反一—要不依赖于任何一组特定的中间件服务。这使得集成者可以为每一个系统选择恰当类型和规模的基础设施。它使得各种服务设计都可以发展和创新，同时简化了组件的开发。这也意味着软件开发者不必直接和这些服务打交道。系统集成者提供“胶水”来把这些组件插入到系统环境中。这给集成者更多的自由来配置组件和选择最适合所实现系统需求（如性能、可用性等）的服务。
下面的两个例子阐明了组件的这种独立性：CORBA组件并不特别强调使用CORBA通知（或任何一种特殊的服务）作为其事件系统。无论所部署的环境是否有分布事务处理协调器（DTC）和/或微软消息队列（MSMQ），COM+组件都用完全相同的方式来编写。表1列出了这种基于组件的接口标准方法的一些优点。表1基于组件接口的优点
明确致力于EMS-API项目中软件即插即用的目标对整个系统的设计和各个服务的选择与设计都不作规定与整个软件行业的方向相吻合，可以使用主流工具来开发组件和配置系统使EMS-API项目不必为“即插即用”软件的许多问题去重新发现和重复发明解决方案提供一个包括打包（装载在组件光盘CD上）、文档、版本等重要方面的更为完整的解决方案不需要设计和/或规定中间件服务，特别是事件、命名和事务服务，而是允许使用商业化的产品来提供这些服务为基于本项目开发的电力公司专用标准提供一种规范形式，使得开发者能够把接口定义直接机器翻译成他们首选的接口语言：对象管理组织（OMG）/国际标准化组织（ISO）接口定义语言（IDL）、Java1\接口语法或MicrosoftIDL允许EMS-API项目集中为电力企业应用设计接口和事件，不必等待所有的中间件问题都得到解决。这使得厂商可以在他们应用产品中用符合EMS-API的接口来更快地进入市场4.4‘与IEC61968标准的关系
EC61968标准处理配电管理系统的系统接口。这些标准在很大程度上与IEC61970（DL890）类似，不仅是在范围上重叠，而且IEC61968标准也是基于CIM的。EC61968标准建立在IEC61970-301（DL/T890.301）中所规定的CIM基础之上，尽可能通过扩展它来包含已有类的新的子类，同时也增加一组全新的类对配电问题域中发现的对象进行建模。因此，要理解：CIM的整个范围，需要同时查看涉及CIM的IEC61970（DL890）和IEC61968两个标准。类似于IEC61970-4××（DL890.4××）标准，EC61968标准也关注配电业务功能之间的信息交换，但并不试图定义应用程序接口（例如，要由组件实现的服务），而是预想在IEC61968标准中定义1）Java是Sun微系统公司提供的产品的商标。提供这一信息是为了方便本国际标准的用户，并没有IEC认可该产品的意思。如果其他等价产品能够证明可以得到相同的结果，也是可以使用的。A
的标准消息可以通过IEC61970（DL890）标准中定义的API传输。5EMS-API参考模型
5.1概述
DL/T890.1—2007
EMS-API参考模型是一个抽象体系结构，提供所处理的问题空间的一个直观显示，提供描述和讨论解决方案的一种语言，定义术语，并提供有助于使用EMS-API标准来解决问题以达成共识的其他类似的帮助。
这个参考模型不是一个设计，也不试图描述各个软件层，尽管隐含的分层方法是难以避免的。参考模型的主要功能是清楚地展示问题空间的哪些部分是EMS-API标准的主题，哪些部分在EMS-API项目范围之外及其原因。它还试图展示本标准的不同部分之间的相互关系。图1是这个参考模型的一个图解，阴影区域代表在参考模型中本部分是本标准的主题。非阴影区域代表一个系统中对于创建可重用应用组件框架是不可或缺的那些部分。这个模型的每一部分都将在本文件中讨论。
应用信息交换和数据访问软件
应用1
组件A
应用和组件
模型编码
及解码
组件A
组件B
模型编码
及解码
组件B
组件适配器
组件执行系统
组件容器API
组件容器
中间件服务
通信协议子集
永久存储
应用2
遗留应用
遗留应用API
遗留封套
组件接口
组件适配器
图1EMS-API参考模型
5.2控制中心环境
公共信息模型(CIM)
61970-3××系列
组件接口规范(CIS)
61970-4××系列wwW.bzxz.Net
组件执行服务：
·命名：
-事件：
-事务处理：
-持久性；
-安全。
这个参考模型是专门应用于控制中心环境的。控制中心环境通常由通过局域网（LAN)，有时还通过广域网（WAN）连接起来的计算机网络构成。一个控制中心可能包含多种系统以支持电力系统运行，包括EMS、DMS以及ISO和RTO业务功能所需的其他系统。它支持一定数量的不同用户群体和机构功能，包括值班操作人员、运行管理人员、操作员培训、运行计划、数据库维护和软件开发。在一个EMS中，许多应用都在多个这样的应用上下文中使用，因此重要的是一个应用可以容易地配置（最好是自动地配置）以用于不同的应用上下文。这是通过使用和每一个组件接口关联的性质（properties）而不是修改组件的内部代码来实现的。
DL/T890.1—2007
5.3应用上下文
一个应用上下文（application context）1）包含了作为一个组织单元一起工作以实现某个高层次目的的一组应用。一个应用上下文定义一个时间范围和一个执行环境。表2包含EMS应用上下文的一些例子：表2EMS应用上下文举例
运行研究
扩展规划研究
电力系统在线控制
执行网络应用程序以研究和/或分析运行实践（短期）执行网络和/或仿真研究以评价各种选择方案（未来/长期）为操作员提供培训环境，需要仿真和分析应用虽然在参考模型中没有明确说明，大家都理解几个上下文可以同时存在，每一个上下文都有可能在不同的数据交换中涉及同样一些应用。此外，还可能有一个特定上下文的多个实例共存的情况。例如，在运行研究上下文中可能会为两个操作员同时运行两个或多个研究，同时同样的这些应用还在实时上下文中运行。
5.4应用
一个应用由在一个给定领域内完成某些业务功能的一个或多个组件组成，它由领域专家设计和编写。组成该应用的各个组件的粒度由设计者选择。应用的构建者可以组合来自不同开发者或厂商的组件以构成一个应用。
应用的开发者应能无须接触组件的源代码就可以充分使用该组件。组件可以通过一组外部性质值来定制以适合应用的特殊需要。例如，按钮组件有一个规定出现在该按钮上的名字的性质。当然，允许定制的数量取决于该组件的开发者提供足够的外部性质值的远见。这有点像程序设计中的一个早期概念，即通过指定适当的配置参数值而不是必须修改源代码来定制程序。附录B.1中是应用类别、抽象名和所执行功能的列表。5.5组件
组件是一种可重用的软件构建块。它是预先构建的一段封装起来的应用代码，可以和其他一些组件及手写代码组合在一起快速生成一个定制应用。要成为一个合格的组件，应用代码必须提供一个标准的接口，使得该应用的其他部分能够调用其功能并访问和操作该组件内部的数据。这种接口的结构由组件模型定义。各种组件的粒度是不一样的。一个组件可以很小，例如一个简单的图形用户接口（GUI）部件（例如，个按钮），也可以大到能够实现整个复杂的应用，例如状态估计应用。在后一种情况下，该应用可以作为一个单一的组件从头设计，也可以由被封装起来以符合组件接口标准的一个遗留应用组成（参见下面对遗留应用的讨论)。
可以把组件放在一个可传送的介质中，如一张CD，以便在提供组件容器的系统中使用。各种组件一般都通过一个集成基础设施来公开展露其方法、性质和“事件”。其中要特别关注的是事件，因为正是这些事件使得集成各种独立开发的组件成为可能。通过使用标准的事件集，组件A不需要知道组件B接口的任何其他细节，甚至不需要知道组件B是否存在。这里的关键是：被标准化的是组件的接口，而不是集成基础设施。5.6遗留应用和封套
遗留应用与前面给出的应用的定义差别很大。遗留应用可以是电力企业在为集成目的而建立任何组1）“上下文”这个术语在这里的用法和在讨论组件模型EJB与CORBA时的用法是不同的。在讨论组件模型时，上下文用来说明组件容器为组件实现提供对组件容器所实现的运行时服务的访问。这些服务包括事务、安全、事件和持久性。
DL/T890.12007
件模型之前所购买或自行开发的执行某一业务功能的单个应用，也可以是作为其他一些系统所需要/发布的数据的源/宿的一个完整系统，这些系统需要集成在一起以促进信息交换。例子包括：
一用FORTRAN实现的未考虑组件接口的机组经济组合应用；个完整的EMS，没有开放、发布接口给配电系统提供SCADA数据，没有从检修管理系统接收其电力系统模型更新信息。
遗留应用封套用来封装不符合组件接口标准的遗留应用或系统。它把遗留程序的输入/输出变换为一个或多个组件接口，使其能够在一个基于组件的系统体系结构中参与信息交换。这样，使用遗留应用封套的意图就是使遗留应用或系统可以像即插即用组件那样，能够通过公用基础设施或框架来和其他组件交换信息。遗留应用封套可以由开发或拥有遗留应用或系统的领域专家（例如，EMS厂商）设计和实现，然后提供这种封套以便在使用组件技术的多系统装置中使用。另外一种情况是，遗留程序是独一无二的定制“企业”应用，系统集成者可能得编写所需要的封套，而且只用于该系统中。5.7组件模型
组件模型定义组件的基本体系结构，规定组件接口的结构和该组件与组件容器及其他组件交互的各种机制。这种组件模型提供创建和实现组件的导则，这些组件能够一起工作以形成一个更大的应用。
组件构建者不必在每一个组件中实现多线程、并发控制、资源池（resource-pooling）、安全保证和事务管理。而且，如果在每一个组件中实现这些服务，要达到真正的即插即用式的应用装配将是非常困难的。组件模型使这些服务的使用标准化和自动化。现在软件行业内部广泛接受的有四种主要的组件模型。这些组件模型在附录A中描述。软件行业已经决定，正如在所有这四种组件模型中所规定的那样，从组件中消除对特定组件容器或基础设施的依赖是迈向可以独立开发、组装和部署组件的境界的一个主要步骤。但是，由于有四个独立的模型，组件厂商可能要为每一个模型各提供一个稍微不同的组件版本以方便使用底层组件容器和执行系统的所有可能特性，还能够继承其固有的一些性能优势。但这并不是必须的。在组件厂商约束其组件设计以确保在这四个模型的任意一个中能够正确运行的时候，这些差别就可以通过组件适配器来弥补，组件适配器由被选定的在特定系统实现中使用特定组件技术的系统集成者提供。系统集成者也可以选择组合多种组件技术和使用桥接技术来实现不同技术之间的互操作（例如，CORBA执行系统与MicrosoftDCOM执行系统互操作)。
5.8组件容器
组件在一个容器内执行。容器为一个或多个组件提供一个上下文并为这些组件提供管理和控制服务。在实际的系统中，容器提供一个操作系统进程或线程来执行组件。它把该组件和运行时平台相隔离。当一个客户程序调用一个服务器组件时，这个容器就自动分配一个进程或线程并初始化该组件。容器管理组件所使用的所有资源，还管理该组件和各个外部系统之间的所有交互。典型情况下组件容器由系统提供者提供，作为组件执行系统的一部分。为组件提供的典型服务是命名、事件、事务、安全和持久性。电力企业实时应用所需要的所有服务可能并没有作为软件供应商供给的标准容器服务的一部分来提供。附录C描述在一个实际的实现中这些服务是如何提供的。5.9组件适配器
一个容器的操作和行为由其组件模型定义和支配。组件模型提供一个约定，规定如何提供容器服务和接口。这样，为一类执行系统或环境开发的组件通常不能够直接移植到任何一个其他类型的执行环境。因此，为了实现组件在多执行系统中的重用，除了组件设计时基于的那个执行系统外，其他任何执行系统都需要有一个组件适配器。可供选择的另外一种办法是，组件接口可以根据某个中立的标准定义，这样对所有的容器都需要一个组件适配器来把这种标准接口映射到该容器所提供的接口。这有点像Java7
DL/T890.1—2007
企业平台中的“可移植层”，该平台是EJB的组件执行系统。组件适配器定义为处于应用（或组件）·和组件容器及集成基础设施之间的软件，它提供基本的组件支持服务（例如，发布/订阅、消息队列、命名等）。如果需要，这种适配器可以处理协议差异、数据变换和数据翻译。如果组件执行环境本身没有提供安全、事务和持久性等服务；适配器也可以另外提供对这些服务的组件支持（至少从应用程序以外的角度看是如此）。组件适配器既处理（a）组件接口和所选择的执行系统环境及容器技术之间的差别，也处理（b）一个组件接口和用在系统其他部分的各个组件接口之间的差别。这包括事件定义的差别。出现这些差别的原因是：系统是由独立开发的一些组件构成的，这些组件的接口没有预先协调（即没有标准化，这可能是普遍的情况)；
一系统包含一些部分标准化的组件，但是没有标准化的部分是不兼容的；一由于标准化的各个部分反映的是标准的不同版本，所以还是不兼容的。依据组件容器所提供的环境和工具，组件适配器还可以把组件的事件入口连接到适当的事件主题并找到正确的相关组件（如果存在）的位置。组件适配器还可以实现组件在前面确定的各种EMS上下文运行所需要的电力企业专用服务，这是现成的组件执行系统所不能提供的。组件适配器通常由系统集成商或组件执行系统供应商提供。它们通常由这样的代码组成，这些代码用来：①把该组件所期望的事件类型、数据类型和服务与正在实施的特定系统中其他组件所期望的事件类型、数据类型和服务匹配起来。②为组件配置系统信息流。因此，组件适配器是由系统集成商针对每一个系统和每一个组件手工定制的。5.10组件执行系统
服务器组件在由应用或组件执行系统提供的环境中执行。组件执行系统这个术语包含了参考模型中从容器层往下的所有内容，包括组件容器、中间件服务和通信协议子集。它还包括其他一些没有展现的常规平台所提供的服务，包括操作系统、持久性存储等。这些也称为容器系统，因为容器为接口标准提供了主要接口，而接口标准是本标准的主题。容器系统包括已有的一些遵守该系统所采用的组件模型的容器约定和策略的中间件产品。任何为支持组件而遵守容器约定的执行系统框架都是合格的。例如，EMS供应商可以把EMS应用执行系统设计成能够支持容器，从而可以使用内部开发的或从其他组件供应商购买的各种组件。附录D中列举了其他一些商用例子。
组件执行系统通常由系统供应商提供。5.11中间件
中间件这个术语用来描述各种实现集成、变换和/或翻译层作用的一组软件产品。中间件为事件、消息传输、数据访问、事务等提供一些通用接口。中间件厂商提供带专有接口的产品来支持这些通用服务的某种组合。尽管中间件厂商通常都为一些广泛使用的应用，如PeopleSoft\、SAP等提供转换器，但是他们一般都不针对一个特定的行业。他们也许提供，也许不提供电力企业实时运行环境所需要的所有服务。作为建立公司标准的企业范围信息技术决策的一个结果，每一个电力企业都可能选择一个不同的中间件厂商，这个选择是不容易改变的。因此，必须把EMS-API组件接口标准编写成能够用各种中间件产品来部署。
中间件产品还在不断地发展。EMS-API.组件接口标准应该不排除在进行集成化工作时使用那些最好的可用产品。附录D列举了中间件产品的一些例子。1）PeopleSoft是Oracle提供的一个产品的商标。给出这一信息是为了方便本国际标准的用户，并不包含EC对所提产品的任何认可。任何能够证明可以导致相同结果的等同的产品都是可以使用的。8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。