英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料

基于Spring的服务组成验证框架

基于抽象面向服务体系结构（SOA）的应用程序由于其灵活性、可维护性和模块性而被广泛接受。然而，这种松耦合系统的安全性和可靠性完全取决于服务描述的精度。因此，任何隐含的假设或不可预见的使用场景都可能导致灾难性的失败。业务流程执行语言（BusinessProcessExecutionLanguage，BPEL）中的重叠结构和不一致性进一步加剧了这种情况，BPEL实际上是服务组合的行业标准。本文扩展了Spring框架，设计了一种用于服务组合的验证框架，其中每个BPEL活动由Java bean表示。该框架实例化与BPEL规范中的活动对应的bean，并注入依赖项以生成beanFactory。此后，用于XML绑定的Java体系结构（JAXB）2 API用于将Bean工厂转换为基于XML的形式化模型（例如有色Petri网（CPN））或交换格式（例如Petri网标记语言（PNML））用于仿真和验证。除了自动化验证过程外，所提出的框架还有助于打击现有解决方案的即席性质。结果表明，该框架的平均转换时间为0.7秒。

关键词bpel，spring framework，verification，cpn

一、引言

基于SOA的应用程序是作为现有Web服务的集合构建的，这些Web服务是基于底层业务逻辑以某种顺序调用的。它的组件Web服务可以跨越多个组织边界，并具有任何底层实现。这种状况需要一种工具来协调业务工作流程。在所有提出的领域特定语言中，Web服务的业务流程执行语言[1]是Web服务组合的事实上的行业标准。

基于SOA的应用程序提供代码移动、跨客户机支持、代码重用、更好的可伸缩性和应用程序层的独特分区。然而，考虑到这些系统的松散耦合性质，任何隐含的假设或不可预见的使用场景都可能导致不希望的交互形式，如死锁或竞争条件[2]。

考虑到正式方法在认可系统可靠性方面的前所未有的能力，以及它们在软件工程中的广泛应用，应该采用它们来验证基于SOA的应用程序。这将有助于识别BPEL规范中的细微错误，而这些错误通常不需要传统的模拟和测试技术。

不幸的是，BPEL中的重叠结构[3]和缺乏健全的形式或数学语义[4]，[5]不允许将形式方法应用到其文本规范中。这些不一致是两种概念上相互对比的语言（IBM的Web服务流语言（WSFL）[6]和

微软）合并成BPEL[5]。因此，在进行正式验证之前，需要将BPEL的文本规范转换为正式规范。BPEL规范本质上是一系列活动，上述转换涉及到这些活动的形式化。

大多数现有的解决方案都将BPEL活动的临时映射纳入正式模型[8]、[9]、[10]、[11]、[12]。用户需要扫描一个BPEL规范，并用相应的形式模型替换每个活动。除了是一个繁琐的过程外，这种练习还容易出错，而且耗时。本文希望通过引入将BPEL活动映射到JavaBean以呈现bean工厂的验证框架来自动化这些技术。此后，JAXB2编译器使用现有解决方案的XML模式或文档类型定义（DTD）将bean工厂转换为基于XML的正式模型或交换格式。后者充当一个中介，可以转换为一系列正式模型。例如，PNML[13]可以生成不同版本的Petri网。

我们的贡献可以概括为：

1）我们引入了一个基于Spring的验证框架，将各个BPEL活动映射到Java bean中。这比现有的将BPEL活动映射成正式模型的技术具有若干优点：（a）转换是自动的B）JavaBean是通用的中间层，可以产生一系列形式模型C），该框架显著地减少了转换所需的时间。

2）我们引入了一个对象模型来简化BPEL活动到Java bean的映射。

3）我们在框架中引入了一个基于JAXB2的组件，将bean工厂转换为一个基于XML的正式模型。框架是开放的，可以通过附加组件进行扩展，以将bean工厂转换为非XML形式的模型。

论文的其余部分组织如下。第二节介绍Spring框架和JAXB2 API。此后，框架在第三节中介绍，在第四节中进行了评估。我们讨论了第五节中的结果，并将其与第六节中的现有解决方案进行了比较。最后，我们在第七节中得出结论。

二、背景

本节提供了对Spring框架和用于呈现基于XML的正式模型的JAXB2 API的深入了解。作为验证的先决条件，系统需要使用许多可用的建模语言（例如，automata、promela、petri nets或其扩展）中的一种正式表示。尽管并非所有这些语言都是基于XML的，但已经提出了几种基于XML的交换格式，它们可以充当中间模型[14]、[15]、[13]。因此，框架只呈现基于XML的正式模型。

a.弹簧框架

Spring是为解决企业应用程序开发的复杂性而创建的开源框架。它是轻量级的，具有可忽略的处理开销，并使用Java bean。基于Spring的应用程序是松散耦合的，其中它们的依赖项列在配置文件中，并由框架注入。它是由依赖注入和面向方面编程的基础上构建的几个定义良好的模块。这些模块是功能打包的，提供编写企业应用程序所需的一切。

JAXB 2 API

JAXB提供了一组API来自动化Java对象和XML文档之间的映射。它由两个基本组件组成：1）绑定编译器（即XJC），它将XML模式或DTD转换为Java类的集合2）绑定运行时框架，允许编组（将Java对象转换成XML文档的过程）和解除编组（将XML文档转换成相应的Java O集）的过程。Box）。编译器生成的类具有特殊的JAXB注释，运行时使用这些注释将它们映射到XML文档中。此外，它们符合XML模式中定义的结构。

三、拟议的核查框架

本节介绍Web服务组合的自动正式验证框架。如图1所示，框架有两个基本组件。第一个组件（图1中的组件-a）是Spring框架的扩展，它实例化了相应的bean

lt;partnerLink name='PL1' lt;bean id='PL1' class='PartnerLink'gt; partnerRole='PR1' lt;property name='partnerRole' value='PR1'/gt; partnerLinkType='PLT1'/gt;lt;property name='partnerLinkType' value='PLT1'/gt;

lt;variable name='V1' lt;/beangt;

messageType='MT1'/gt; lt;bean id='V1' class='Variable'gt; lt;variable name='V2' lt;property name='messageType' value='MT1'/gt; messageType='MT2'/gt; lt;/beangt;

lt;invoke name='I1' lt;bean id='V2' class='Variable'gt; partnerLink='PL1' lt;property name='messageType' value='MT2'/gt; portType='PT1' lt;/beangt; operation='OP1' lt;bean id='I1' class='Invoke'gt; inputVariable='V1' lt;property name='partnerLink' ref='PL1'/gt; outputVariable='V2'/gt; lt;property name='portType' value='PT1'/gt;

lt;property name='operation' value='OP1'/gt;

BPEL

lt;property name='inputVariable' ref='V1'/gt;

Spring lt;property name='outputVariable' ref='V2'/gt;

lt;/beangt;

图2.BPEL规范的弹簧配置。

并呈现bean工厂。它也是框架的核心组件。另一个组件（图1中的组件-B）将Java bean转换为基于DTD或XML模式的基于XML的模型。可以用转换所需的其他组件替换或补充此组件。

图1还强调了转换中涉及的四个步骤。前两个步骤涉及组件A，其余两个步骤涉及组件B。以下章节将进一步讨论每个步骤的作用及其在组件中的突出地位。

A.组件-A

这是使bean工厂脱离BPEL规范的框架的核心组件。它基于Spring框架，因此提供了所有的好处（例如松耦合和依赖注入）。

BPEL规范和Spring配置文件之间的相似性构成了这个组件的基础。虽然结构上不相同，但它们都包含必要的信息来实例化和初始化Java bean。因此，Spring框架已经被扩展以解析BPEL规范，1）识别BPEL活动2）获取与活动3相关联的所有信息）实例化并初始化适当的Java bean。如图2所示，其中已为BPEL规范制定了等效弹簧配置。扩展的Spring框架与XML文件相同，并呈现相同的JavaBean。图3突出显示了为实现此功能而修改的类。分析XML配置文件的默认逻辑是在DefaultBeanDefinitionDocumentReader类的RegisterBeanDefinitions方法中实现的。我们扩展了默认逻辑以允许解析BPEL规范。现在将讨论与此组件相关的两个步骤。

1）步骤1。实例化：第一步涉及解析BPEL规范并实例化适当的JavaBean。在分析BPEL规范时，扩展的

Figure 3. The class modified for underlying extension.

框架最初获取其中的所有XML元素。然后，它查找与这些元素中的每个元素对应的类。考虑到每个BPEL活动映射到JavaBean，框架应该为每个元素找到一个合适的类。类名基本上与映射的活动名相同（大写的第一个字符除外）。通常，JavaBean每个对应属性的属性都有一个属性。框架使用“setter”方法用适当的值初始化这些属性。但是，BPEL结构化活动的JavaBean具有附加属性来存储对底层子活动的引用。例如，如图4所示，bean for flow活动将存储对其所有子活动的引用。

我们不使用手动创建Java bean，而是使用Eclipse建模框架（EMF）自动生成它们（16）。框架提供了一个图形界面来创建用于生成类的对象模型。图5说明了用于创建所提议的验证框架的Java bean的对象模型。已经尝试将层次结构引入到对象模型中。考虑到大量的BPEL活动具有相同的属性，这就允许使用子类

Figure 4. Bean for structured activities store reference to child activities.

重用其父类的属性。

在层次结构的顶部是构成任何BPEL文档根的流程的类。它包含对GlobalScope的引用，表示BPEL流程中的顶级范围。对于每个二级作用域，类globalscope依次具有对localscope的引用。考虑到BPEL规范中的作用域可以具有任意深度的嵌套作用域，类localscope具有自引用以标识父作用域。

类活动构成了所有BPEL活动的超类。它引用了GlobalScope和LocalScope，后者存储了活动的顶级范围和封闭范围。它有两个子类，结构活动和其他活动。顾名思义，前者是BPEL中所有结构化活动的超类，而其余活动则扩展到后者。