|
本论文描述了SOA三角形架构下的组合服务质量描述与验证的若干问题。本论文已与2009年11月，收录于IEEE会议APSCC2009.
点击下载
论文介绍
组合服务质量的描述与验证
本系统提出了自己的一个QoS aware SOA architecture，改进了原经典的经典三角形架构。提出了一个WSQC服务质量属性的约束描述文件。这也是对传统SOA功能性匹配的一个突破和改进。
整个软件的系统架构如下图所示：
如图所示，当客户提出了自己的约束请求，发送到了Composition Manager。根据用户的功能性，和Services Registry的数据，由Selection Manager进行服务的组合。然后将组合结果发送到QoS Evalution模块，进行评价。如果此组服务满足约束，则成功；如果不满足，则送回Selection Manager进行重新组合，直到组合满足客户要求为止。
这个架构里的两个核心内容：User Requirement的表达和QoS Evaluation。下面将对这两部分分别进行介绍。
WSQC(组合服务性能约束描述文件)
WSQC(Web Service QoS Constraints)，即网络服务的质量属性约束文件。它是用来描述组合服务的质量属性约束的。WSQC是基于XML的形式化规范，它应用了一个基于OWL-Q的语义QoS定义，并支持了QoS分类以提高灵活性。
OWL-Q进行WS-QoS建模 随着web service成为企业集成的解决方案，web service的质量属性变得越发重要。但是由于WS-QoS具有动态、不可预测等特性，我们很难为服务消费者定义出所有需要的服务质量属性。所以我们需要一种灵活的机制，可以根据不同的业务linguistic，能动态的扩展质量属性。 此外，我们还希望能与服务的提供者，消费者，以及注册中心一起分享领域知识。因此，这个模型需要引入语义方面的内容。而Ontology正是为此诞生的。在近些年，对Ontology的应用越发广泛，这主要有2个原因：Ontology技术有很好的互操作性和强大的推理机能力。 Web Ontology Language(OWL)是一种基于XML的语言，用于使用了XML,RDF,和RDF Schema提供了更多的语言能力和正规的语义描述，OWL对于web内容有很好的互操作性。OWL-Q是一种基于OWL-S的web服务质量属性描述元模型，它是一种可扩展的模块化Ontology语言。OWL-Q遵循了10条WS-QoS属性建模原则来确保它的良构和可扩展性。 我们用OWL-Q作为元模型来描述来给出QoS属性一个形式化的定义。在此模型之下，我们可以扩展多个QoS属性。Protégé是由斯坦福大学开发的一款强大的OWL编辑器软件，我们使用它进行了OWL建模。 在这里，我们选用了w3c提出的对质量属性提出的一个提议并且给出了它在OWL-Q模型中的计算方法：
性能
吞吐量：在单位时间内的服务数据比特数
Tp(t)=BN(t)/TI
响应时间：由执行时间、延迟组成
RT(t)=ET(t)+DT(t)
可靠性：在一定的时间间隔内，有响应的服务调用数(包括非正常的调用)
Re(t)=RIi(t)/TI(t)
可用性：在一定的时间间隔内，有响应的服务调用数(不包括非正常的调用)
Av(t)=RIn(t)/TI(t)
容量
最大响应数：在一定的时间间隔内，服务器可相应最大服务数量。
SR(t)=MSRN(t)/TI
BPEL的WS-QOS约束
由于QoS在Web Service技术中，越发重要的地位，在服务提供者和消费者之间的契约就显得尤为重要。为了满足这个需求，SLA(Service Level Agreement)服务等级协议这种机制被开发出来。它的应用范围比较扩繁，在有服务提供和消费这样的2种角色的场景，都可以用上，这种契约。在2003年，IBM公布了一套基于XML的语言WSLA(Web Service Level agreement)网络服务等级协议。它是专为web service开发的一套等级协议。除此之外，还有很多QoS描述语言，例如WSML、WSOL等。 所有的这些Web Service发现机制，都面临着一个问题：它们都需要依赖于语法或语义的QoS属性描述。不同的规范出现大致有两个原因，1：对于相同概念的不同理解；2：不同系统对相同属性的读取。比如，花费这个概念在不同系统中的单位可能不同。而OWL-Q提供了一个标准的WS-QoS描述模型，我们可以来引用这些定义好的QoS属性。 现在，我们希望能尝试寻找一种解决方案来支持服务消费者对于组合服务的QoS约束。比如：词组服务的价格应小于10美元。为了使其比较容易理解，我们再次用BPEL来代替组合服务。下面是这个方案应该具备的几个关键点：
A) 应该以一种非侵入式的方式来描述BPEL的非功能性约束
B) 它应该提供以OWL-Q元模型定义的WS-QoS属性定义
C) 他应该支持 平均/严格 两种QoS属性约束类型
D) 可以支持QoS分类。
平均/严格 类型的意思是它将应用到平均或者是最坏的情况。举个例子：这个组服务的平均响应时间应该小于1秒或这个组合服务的响应时间应该严格小于1秒。后一种说法等同于：这个组合服务在最坏情况下的响应时间不能大于1秒。很明显，这两种情况是很不同的，应当区别处理。
QoS分类的目的是处理多种不同或者位置的QoS约束属性。我们将会在后边再具体讨论。
选择一种非侵入式的方式来表达BPEL QoS约束而不是扩展BEPL。这么做主要有2个原因：1：这个QoS约束可以在多个地方被重复引用。2：更好的兼容性。这种非侵入式的表达，在几十不支持QoS约束的系统里，BPEL仍然可以正常运行。
考虑到上边的众多约束。我们设计了一种XML Schema来描述用户的QoS约束。我们把它称为WSQC.它主要包含了3个部分：BEPL引用、属性定义和属性约束。
我们在XML Schema“wsqc:MetrciCatalog”种引用了WS-QoS OWL定义。“wsqc:MetricClassification”和“wsqc:MetricOperator”在schema里是可重用和可扩展的。
| 
