基于本体的云应用服务设计框架解析

### 基于本体的云应用服务设计框架解析 #### 1. 云平台分类 云平台可分为以下三类： - **第一类**：仅提供基本开发资源，如应用服务器和数据库，不提供额外的云平台服务或服务市场，例如 CloudBees。 - **第二类**：通过 API 提供额外服务，如电子邮件服务、图像操作服务和消息队列服务。这些服务可以由平台原生提供，如 Google App Engine；也可以通过市场提供，如 Heroku 的附加组件。 - **第三类**：采用原生应用开发范式，开发者需使用定制的可视化工具和图形界面创建应用。ISV 可通过市场提供额外服务，但这些服务与平台紧密集成，不暴露编程库或 Web 界面，例如 Zoho Creator。 在服务提供方面，第一类平台仅提供部署功能，无额外服务；第三类平台以专有开发工具和技术为特征，缺乏编程 API，难以抽象所提供的服务。因此，本文重点关注第二类平台，特别是服务暴露的专有 API 以及如何抽象这些 API 以实现对服务的统一透明访问。 #### 2. 相关工作 随着平台基本服务的不断增加，人们对利用多个云的服务的兴趣也在增长。相关工作可分为以下三类： | 类别 | 代表工作 | 特点 | 局限性 | | ---- | ---- | ---- | ---- | | 基于库的解决方案 | jclouds、LibCloud | 为访问特定云资源（如计算、存储和消息队列）提供抽象层 | 应用范围有限，难以重用以适应额外服务 | | 中间件平台 | mOSAIC | 作为中间层，将应用与专有技术解耦，能利用多个云平台环境，提供开源 API 以使用常见云资源 | - | | 模型驱动工程技术 | MODAClouds、PaaSage、MULTICLAPP 等 | 提供元模型，用于创建独立于云平台的应用，支持跨部署、监控和质量保证 | - | 这些解决方案主要致力于消除每个平台带来的技术限制，实现应用的多云部署，同时提供监控和质量保证功能以及创建弹性应用。而本文的愿景是促进无缝使用来自异构云的平台服务和具体提供商，为此设想创建一个框架，实现服务和具体提供商 API 的统一描述。 #### 3. 本体驱动框架 为了实现基于服务的云应用设计，提出了一种基于本体驱动的框架。该框架针对第二类云平台，接收服务功能描述，自动生成客户端适配器以映射到特定服务的抽象参考 API。以云电子邮件服务为例进行评估，该服务使云应用无需开发者设置和维护电子邮件服务器，通过 Web 界面由云提供商提供。 选择电子邮件服务的主要原因是为了使云应用能够利用多个云的服务。云应用平台和服务市场的出现提供了广泛的服务，因此探索本体作为特定供应商 API 抽象的推动者。具体提供商的 API 被捕获到本体中，然后映射到向云开发者暴露的抽象参考 API。 #### 4. 使用本体的好处 本体是该框架的新颖之处，用于实现平台基本服务的统一描述。根据定义，本体是共享领域的形式化知识，被特定群体标准化或普遍接受。使用本体有以下好处： - **清晰定义领域模型**：明确我们感兴趣的领域模型，即多个平台提供的云平台服务。本体作为服务的共享和普遍接受的描述，有助于服务的同质化，云供应商可基于此发布服务描述。 - **可重用和扩展**：描述平台基本服务的本体可基于现有本体构建，如 USDL。 - **一致性检查**：利用本体的推理能力进行服务描述的一致性检查。 - **成熟工具支持**：有成熟的工具用于创建和操作本体，如 Protégé、OWL API 和 Jena 框架。 虽然在云计算领域已有使用本体进行服务描述的先例，如 mOSAIC 本体用于服务发现和中介，但本文的本体侧重于服务的具体功能和 API。 #### 5. 本体驱动框架的架构 该框架由两部分组成：代表支持的平台基本服务的模型和框架的核心引擎。 ##### 5.1 平台服务模型 这些模型使用本体构建，分为三个层次，灵感来自元对象设施（MOF）标准： - **第 2 层本体（O2）**：包含抽象平台服务的描述，捕获定义平台基本服务的通用概念，包括服务的配置设置、认证机制以及描述 API 所需的操作和属性等概念。 - **第 1 层本体（O1）**：包含每个平台基本服务的具体描述，对应每个服务有一个专用本体，捕获服务暴露的功能信息，也称为模板本体。例如，云电子邮件服务的 O1 本体描述了发送、接收和操作电子邮件的功能。 - **第 0 层本体（O0）**：包含特定平台服务提供商的描述，对应每个服务提供商有一个专用本体，描述原生供应商特定的 API，也称为实例本体。用户可通过阅读服务提供商的 API 形