DL／T 1080.100-2018  电力企业应用集成 配电管理系统接口 第100部分：实现框架

一个在其整个生命周期内创建和使用业务流程的计算机系统架构形式，这些业务流程被封装成服务 (service）。SOA还定义和规定IT基础设施，用来让不同的应用程序交换数据以及参与业务流程。这些功 能和应用程序底层的操作系统及编程语言都是无关的。SOA将功能分隔成不同的单元（服务），这些单 元可以在网络中分布，并可以组合和重复使用，以创建业务应用。这些服务通过在服务间传递数据实现 通信，或者通过协调两个或多个服务间的活动实现通信。通常认为，SOA的概念是建立在老的分布式计 算和模块化编程的概念之上，并在此基础上不断衍化而来的。

一种软件架构模式，促进了事件的生产、检测和消费活动。事件是任何可能引起兴趣的状态变化。 在EDA中，事件在松耦合的软件组件和服务之间传递，通常使用发布/订阅的消息传送模式。EDA补充 了SOA，在某种程度上，SOA2.0也被称为事件驱动SOA。EDA是包括复杂事件处理模式在内的多种 商业智能模式的基础。

简单对象访问协议simpleobjectaccessprotocol；SOAF

义XML消息格式的标准。SOAP可以作为WebService协议栈的基础层，同时也通常在JMS中 见的SOAP的传输载体包括HTTP、HTTPS和JMS专有的传输协议。SOAP现在有时也用来指什 务的体系结构协议给排水图纸，同时也是W3C推荐的协议。 AP1.1和SOAP1.2是常用的两个版本。在新的集成或接口应用时应采用SOAP1.2。

Web服务描述语言WebServicesdefinitionlanguage：WSD

一种基于XML的语言，用于描述WebService。WSDL通常与SOAP和XML模式一起使用，通过 因特网（或企业内部网）提供WebService。WSDL为W3C推荐使用的标准。 WSDL1.1和WSDL2.0为常用的两个WSDL版本。WSDL2.0能更好地支持Java和.Net实现之间 的互操作性。

XML模式XMLschema:XSD

作为W3C推荐标准，于2001年5月发布，是若干XML结构语言中的一种。它是第一个满足W3G 推荐标准的独立的XML结构语言。 与其他所有的XML结构语言相似，XMLschema可用于表达一种模式：一组规则，XML文件只有 遵守了这组规则才会被判定为有效。但是，不同于其他的模式语言，设计XMLschema时，有意使对文 当的有效性的判定能生成一批附着有特定数据类型的信息。XML模式（XSD）就是一个XMLschema实 例，XML模式定义文档后缀名通常为“.xsd”。在有些非正式情况下，用XSD来代表此语言本身。 有必要指出，DL/T1080消息体是用XML模式来定义的，这一点很重要。这些XML模式为使用本 标准传输的应用消息体提供标准规范

表述性状态转移representationalstatetransfer

基于SOAP的WebService的替代物。REST使用HTTP，每一个URL代表某一个对象。接口可以依 照请求和应答的XML消息体定义。使用REST时不需要WSDL。另外，虽然使用XSD的XML文档很 常见，但无须使用XSD定义用于请求和响应的XML文件。 在REST内部，用HTTPGET可获取一个对象。在实践中，HTTPPOST用于新建或者修改一个对象 REST可以很容易地使用本文件描述的DL/T1080消息封装来定义请求和响应消息。本文件描述的 任何的WebService交互也都可通过独立于SOAP或WSDL定义的REST实现。

种结构，很多通信产品都采用队列用来保证数据的可靠传输。JMS提供的标准API包括基于队 传递模型。AMQP为基于队列的消息定义了一个开放协议。

种消息结构，很多消息产品都使 税兑消息传送模式，这种模式下，一不发 到指定主题的消息可能会有多个消费者。 JMS直接支持这种方式

消息目的地messagedestination

查询query 请求的一种类型，该类型请求期望目标端把信息返回到请求的源端。用于查询的请求消息将会使用 动词“get”。这通常是使用请求/应答模式实现。 3.3.17 事务transaction 请求的一种类型，目标端通常会修改它所管理的信息。事务请求将会使用动词如“create”“change “delete”“cancel”“close”或“execute”。事务请求可以通过很多不同的消息模式实现。如果使用请求 应答以外的模式，应该由传输层提供消息可靠传输。

的目的是通过几个用例来描述一组应用系统内部组件间的交互，以支撑相关的业务流程。有必 例是从系统集成的角度设计的，而不是最终使用的应用程序级的用例。本节描述的用例的参与 人下部分：

本节的目的是通过几个用例来描述一组应用系统内部组件间的交互，以支撑相关的业务流程。有必 要指出用例是从系统集成的角度设计的，而不是最终使用的应用程序级的用例。本节描述的用例的参与 者包括以下部分： 一客户端； 一服务端； ESB； 一适配器。 与消息传递相关的三个重要的术语包括请求、应答和事件。在DL/T1080的术语内，这三个术语都 反映在定义具体信息流的动词术语上。

与消息传递相关的三个重要的术语包括请求、应答和事件。在DL/T1080的术语内，这三个 映在定义具体信息流的动词术语上。

第一个用例是客户端和服务端之间的简单请求和应答。这是请求和响应的同义词。发起请求的是客 占端，处理请求的是服务端。此过程非常简单，以至于无须使用ESB。此用例涉及以下两种场景： a）客户端发起一个查询请求到服务端，服务端将会根据一些过滤条件返回一组对象到客户端； b）客户端发起一个事务请求到服务端，服务端将会通过某种方式创建或者修改一组对象。 这两种场景在图2中都进行了描述。

4.3使用ESB请求/应答

的请求/应答用例也可以扩展到使用ESB来实现。在ESB内部，许多动作都可以根据需要由 行以方便实现组件的集成和解耦，例如转换和路由， ，图3为采用中间件的请求/应答过程

图3采用中间件的请求/应答

这个用例的一个重要特征就是实现客户端和服务端的解耦，因此客户端无须知道服务端的确 者遵守服务端使用的准确接口。路由和映射可以在集成层实现。 推荐采用无状态的ESB中间件，可以简化负载均衡和高可用性的实现

使用WebService的监听者需要在一个URL上暴露接口，由中间件获知，以便消息被适当地分发。 当需要可靠传递时，也必须定义重试处理的规则 消息排序的影响同样需要考虑

事务用例的典型情况是客户端和服务端之间请求/应答交换和后续的发布事件的组合。此用例的 重要特征就是客户端和服务端可以使用不同的传输机制，例如一个客户端可能使用WebService而另一个 客户端使用JMS。ESB内部中间组件可以提供必要的路由功能。 事务通常采用请求/应答模式来实现，但是也可以采用点对点或单向模式实现，如图5所示。单向模 式可以使用动词现在时处理事务，或动词过去式处理事件和需要具体实现的需求。

图5点对点（单向）模式

单向模式应用于当一个记录的系统想要转发事务到一个同样需要应用该事务的对等系统中时。如果 在目标端检测到错误，则应当被记录在目标系统中以便解决。图6给出了一个事务产生事件并传播到关 注的订阅者的示例。 DL/T1080要求，与事务相关的请求使用动词“create”"change""delete"“cancel""close”和“execute”。 与事件相关的动词使用过去式。如6.10节描述，使用execute动词意味着处理复杂的事务和使用 Payload.OperationSet元素。

调是一个消息交换的异步处理机制。它是由两个请求/应答（初始的和最终的）同步调用组成。 应答通过某种方式相互关联，每一方都可以明确地识别到回调的初始请求。在这种情况下，发选 个初始请求消息到接收方，称为InitialRequest。一旦接收方接收到这条消息，它会返回一个应 此时，初始消息事务完成，发送方应用被释放。接着，接收方系统会使用一个请求消息来发起

请求/响应调用，这个消息称为FinalRequest。在发送方响应最终的请求后，整个回调处理过程 7是一个回调时序图。

回调过程中，初始消息的发送方必须通知初始消息的接收方最终消息应答的位置，经常是一 I调地址的URL。这个信息可以包含在初始请求消息内。6.3.2节讨论用于控制这类对话的具 素。

有些情况下系统不能直接连接到ESB，适配器可以用来解决系统和ESB之间阻抗不匹配的问是 情况下，系统可以是数据库或文件目录。在图8中，适配器被用于连接一个服务端到ESB。

器可以执行多种功能，并可代表系统操作，例如在成功完成事务后产生作为结果的事件。最常 是实现数据在应用程序模型和企业规范模型之间的转换

某些用例可能需要更加复杂的消息传 有时会使用到这样的用例，一个请求可 很多异步应答来返回信息作为结果， 件的形式返回给客户端，如图9所

上述用例常见于多种应用，例如计量系统在断开连接或者负荷控制时，会花费大量的时间获取结果， 这时系统可能会发送一个EndDeviceControls消息，但是结果可能会延迟一段时间才会通过 EndDeviceEvents消息报告到计量系统。 有必要指出复杂消息传输是回调模式的变化形式。初始请求可以是一个查询，其结果异步返回；或 者是一个事务，其结果是产生一个或多个事件

现范不包括与业务流程协作和编排的相关的用例以及长期或短期的分布式事务。本规范描述的集 可以在解决这些需求的更复杂的集成中被实现

在前面部分描述的用例可作为最终用途的应用层用例，具体示例如图10所示，以（ 的形式，用DL/T1080动词和名词定义消息。相比通用类型的参与者，具体（或有代表性的）的系统将 被标识出来。

图10应用层用例实位

本章阐述了一组基本的服务集成模式， 文所述的用例。事实上通过使用企业服务总线中 的中间件，或者利用一个应用程序作为中间件，还能够组成更加复杂的集成模式，

5.2客户端和服务端视角

从客户端和服务端的角度，本文描述了几种基本的集成模式。这些集成模式包括但不限于： 同步请求/应答： 通过输入输出消息操作的WebService实现； 通过队列来实现消息交换的JMS实现。 异步请求/应答： 通过分离的请求和回调应答消息操作的WebService实现； 通过队列来实现消息交换的JMS实现。 发布/订阅，潜在地有多个且标在监听消息：

WebService实现，意味着一个客户端监听特定URL来获取消息，这个消息是由ESB中间件发 送给多个目标的： JMS实现，意味着多个目标在一个主题上监听消息。 从单个客户端或单个服务端的角度来看，只要他们选择使用相同的传输机制，则无论客户端与服务 端是直接通信还是通过中间件通信都是无关紧要的。ESB的价值在于它能够提供一个集成构架，在这个 构架里，一个客户端可以选择使用WebService、队列和主题中的任何方式，同时任何一个目标服务也可 以使用WebService、队列和主题中的任何方式，与其他任何客户端选择何种方式无关。这种方式可以用 来隔离企业中各种应用的技术选择，这样使用任何桥接技术都不会对单独的应用程序造成影响，这种影 响会限制应用迁移时的选择。

5.2.2基本的WebService模式

图11说明了采用WebService的一个基本的请求/应答模式

VebService的基本请求/

5.2.3基本的JMS请求/应答模式

12描述了一个基本的请求/应答模式，这个模式中，客户端向主题（或者队列）发送了一个JM 在这个模式中应答消息是可选的，某些情况可能没有应答消息。

图12采用JMS的基本请求/应答方式

一个集成模式是进程会监听可能被发出的事件。在许多案例中，一个服务会发布事件消息，很

呈会潜在地对这些消息感兴趣。 图13所示，事件应通常以主题（而不是队列）的方式发布，同时事件通常有许多消费者。监听器 J一个或多个潜在感兴趣的JMS主题。当消息不应该丢失时，一些监听器可能使用持久化订阅。 的发送和消费是异步的。没有任何类型的确认消息返回至服务。

图13使用JMS的事件监听器

5.2.5异步请求/应答模式

异步请求/应答充许一个或多个应答异步地返回一个请求客户端。这是一个复杂的集成模式，使用 VebSerVices来实现比用JMs实现精微复杂一点。 如图14所示，在这个模式中，一个客户端向一个服务提出一个请求。服务可能不能直接处理和/或 响应客户端想要的信息，服务会立刻对该请求响应一个简单的确认信号。当处理过程能够产生并且/或者 期望的信息被获取之后，服务能够产生一个或多个异步应答，通过特定的URL、主题或队列发送到客户 端。用来控制这个交换的关键元素（见第6章）如下： Header.CorrelationID用来在逻辑上将所有消息联系在一起。CorrelationID在客户端的初始请求 中提供，服务应该在所有相关应答和事件消息上包含它。 Header.AsyncReplyFlag在初始请求中设置为“true”。 Header.ReplyAddress在初始请求中设置，用来标识应答的目的地。 Reply.Result用于应答，“PARTIAL”表示预计应有更多期待的应答，或者“OK”表示处理完成， 并且不应有更多期待的应答。“FAILED”值表示一个错误状态

图14异步请求/应答模式

这个模式的一个应用是获取计量读取，一个计量系统前置应当从一个或多个表计中 信息。

客户端和服务端既能直接通信，也能通过中间件通信。企业服务总线（ESB）用来做中间件的管理。 SB的使用使得通信模式有许多变化。不过，在客户端看来ESB与服务端并没有什么不同。同样地，在 报务看来，ESB与客户端也并没有什么不同。理由如下： 一任何实现DL/T1080接口的客户端或者服务端都不需要ESB。 一不需要强调ESB产品附加在任何DL/T1080接口上，除了使用JMS消息的地方需要一个JMS 服务。 一个使用DL/T1080的项目实现可以使用一个ESB，并且自由实施适合于该项目和相关集成的 集成模式。 考虑到一个DL/T1080接口的实现并不需要一个ESB，5.3.2～5.3.6仅作为推荐来描述，作为 个资料性材料提供。

5.3.2使用JMS的ESB消息模式

L采用JMS的ESB消息模式引入了请求路由的选项。这有助于进一步解耦客户端和服务端，这里总 线通过使用路由逻辑，通常被称作“基于内容的路由”集成模式（EIP）】可以做出有关于请求处理的决 定，如图15所示。 当一个客户端发起一个请求至一个主题（或者队列），总线上的路由能决定将消息转送至另一个主题 （或者队列）。路由的决定将考虑以下几个方面： 一消息头的内容； 一消息体的内容（尽管这应当被避免）； 一目标服务实例状态； 一负载均衡所需。 有必要指出本部分描述的松耦合方法的一个优点是，路由组件不依赖于特

ath表达式来配置，用以识别消息内容以决定当

3.3基于WebService服务请求的ESB消息模

图15ESB实现基于内容的路由

图16对前述的模式进行了扩展，它允许一个WcbService客户端或一个JMS客户端发起请

图16含智能代理和基于内容路由的ESB

代理［有时称为智能代理集成模式（EIP）］组件用于在ESB上暴露一个WebService（由V 义）。智能代理能决定请求分派和应答关联。将通过WSDL表达的信息简单转换为JMS信息，然 合适的路由传送，

5.3.4ESB请求处理WebServices

图17对前述的模式进行了扩展，允许一个服务作为WebServices暴露其接口，并具有适 WSDL

地基标准规范范本5.3.5通过适配器的ESB请求处理

图17含代理、路由器和适配器的ESB

图18是前述集成模式的一个变种，其中服务端使用一个与本部分描述的接口子集不兼容的接口。这 表明，通过在ESB内使用适配器，DL/T1080兼容接口可以和与DL/T1080不兼容的服务端、数据库、 文件系统或其他的信源或信宿集成。适配器也可以独立于ESB。

图18ESB集成不规范资源

对于适配器和不兼容的接口之间的集成，可以根据具体ESB产品的能力使用多种集成机制进行集 成。这些机制包括但不限于： JMS； Web Services; HTTP; Java数据库连接（JDBC）： 文件传输协议（FTP） 文件读写； 私有数据库访问。 JMS和JDBC的规范意味着使用JEE框架，但并不是强制要求。大多数支持JDBC的数据库，可通 过开放数据库连接（ODBC）直接访问或通过桥间接访问，很多支持JMS的ESB产品也有相应的API， 可使用Java以外的其他语言（如C、C++）来发送和接收JMS消息。然而，有必要指出使用JEE框架对 平台的独立性提升了一个高度，

5.3.6定制的集成模式

通常一个集成项目将涉及各种定制集成模式的实现。5.3.15.3.5介绍了一些可能的模式及其用法， 这些模式利用ESB中的中间过程来实现的，可能包括但不限于下列模式（EIP）： 一基于内容的路由，通常基于消息内容使用XPath表达式的传送消息。 一智能代理，消息可能被重新分发给特定的目标服务，从服务接收到应答，然后传回到客户端。 一提取单，通常适用于非常大的文件，该文件作为文档来维护供其他进程使用，文档的当前状态 被跟踪设备设计图纸，但文档本身通常是不通过消息机制来传输。 一转换，转换通常由XSL来定义，用于转换消息内容的格式。 一桥，一个发布在主题或者队列中的消息可能发送至或者接收自另一个消息传递架构（这种模式 有时可以用第三方产品或仅仅通过配置来实现）。 然而，有必要指出本部分并不要求任何具体的定制化集成模式的实现或使用，同样有必要指出集成 模式实现时的两个主要理念： a）模式按照一个单独的过程定义来实现，可以通过一次或多次实例化来支持可能的多个信息流 并且没有类型限制； b）模式模板化，模板是用于实现一个支持特定信息流的流程，这导致一个特定类型的实现。 以上两个理念之间有个重大权衡，本规范的焦点在于推荐第一项，通过公共消息信封的使用，这种 信封易于支持促使特定集成模式的一般实现，而不是一个给定集成模式的具体类型实例。

每个服务接口都用于接收一条包含一个动词和一个名词的消息，名词标识了可能提供在请求、应答 事件消息消息体的类型，允许接口是松散耦合的。 服务接口由下面的一条或两条来定义： 1）Web服务描述语言（WSDL），为一个或多个操作定义了请求、应答和错误消息。 2）JMS消息定义。所有情况下，都是用XML模式（XSDs）来定义消息信封的结构，大部分情况 下，用XSDs来描述消息体的结构，消息体的内容在第7章讨论。

每个服务接口都用于接收一条包含一个动词和一个名词的消息，名词标识了可能提供在请求、应答 事件消息消息体的类型，允许接口是松散耦合的。 服务接口由下面的一条或两条来定义： 1）Web服务描述语言（WSDL），为一个或多个操作定义了请求、应答和错误消息。 2）JMS消息定义。所有情况下，都是用XML模式（XSDs）来定义消息信封的结构，大部分情况 下，用XSDs来描述消息体的结构，消息体的内容在第7章讨论。