The requirements of using provenance in e-Science experiments（论文阅读）

论文背景

在电子科学实验中，记录实验过程供以后使用是至关重要的，例如：解释结果，验证正确的过程发生或者跟踪数据来自哪里，导致一些数据的过程被称为数据起源，起源体系结果是系统的软件体系结构，必将提供必要的功能来源记录，存储和使用过程文档来确定数据的起源

论文贡献

在本文中，从当前生物学，化学，物理学和计算机科学的实验中提出了起源体系结构的用例，并分析这些用例确定时通用的，技术和应用独立的体系结构的技术需求，我们提出了一个满足这些需求的架构，分析了它与其他方法的区别，并通过尝试实现两个用例来评估初步实现。
1、一系列关于科学实验，尤其是电子科学实验的信息记录，查询和使用的用例
2、分析实现这些用例所满足的技术需求
3、解决这些技术要求的建议设计以及一般分析，通过实现两个用例初步评估。

关键字

电子科学，网格，起源，需求，用例，工作流

起源体系结构

是一个系统的软件体系结构，它提供了各种各样的应用程序中记录，存储和使用过程文档的额必要功能，在www.pasoa.org项目中，我们的目标是开发出一个出处架构，因此，我们必须了解过程文档的使用范围。

面向服务的架构

面向服务的体系结构是电子商务和电子科学中常见的分布式系统技术的基础，通常，一个服务只能通过一个接口来获得，这个接口标识了与服务的所有可能的交互，并以某种标准格式来表示。

SOA

SOA提供了几个好处，首先，他们将实现隐藏在接口后面，允许实现细节改变，而不影响服务的用户，其次，服务的松散耦合特性允许他们在多个应用程序中重用，这些特性使得SOA特别适合构建大规模分布式系统，多个服务结合使用，提供比每个服务单独提供的功能更广泛的功能。

Provence的起源

起源的思想

先前的研究是用审计跟踪，沿袭，数据集依赖，和执行跟踪，我们将两个具有潜在不同的重要概念区分。
数据项的起源是产生该数据的过程，将过程文档定义为过程的记录文档，过程文档是相当于过程记录的，在这篇文章中 ，谈到一些分别是提供和管理起源相关功能的系统和领域。
透明结果缓存(TREC)原型使用Solaris UNIX proc系统来拦截各种UNIX系统调用，以便构建依赖关系图，并使用该图捕获程序执行的跟踪。范围更广的类似系统是PASS（平台即服务？） ，它在共享存储系统级别运行，自动记录执行的程序、所有输入、远程传入的数据和作为输出创建的文件的新版本，以便可以查询存储数据的出处并重新生成数据。子下推算法用于记录数组操作语言中的数组操作过程。一个更全面的系统是为S语言设计的审计工具，用于统计分析，其中用户命令的结果自动记录在审计文件中。这些系统在单个本地系统上工作
许多有关记录过程文档都是在特定背景下进行的

起源方面的初步研究

初步研究是在地理信息领域，兰特开发了两个系统，用于跟踪地理系统中结果的来源，一个元数据库用于跟踪工作流的过程，一个用于从带命令行的图形用户界面跟踪Arc/info地理信息系统的操作，，另一个包括过程的系统是Geo-Opera,这是COOSE的扩展，使用数据属性来指向数据转换的最新输入/输出，以程序或脚本实现。在化学方面，CMCS项目基于科学应用中间件项目，开发了一个在多尺度化学协作管理元数据的系统，另一个正在开发起源工具的领域是生物信息学，****myGrid项目已经实现了一个系统，用于在表示为聚合服务网络服务的工作流的计算机实验环境中记录过程的文档，并与科学家可能感兴趣的其他元数据一起存储在用户的个人库中，myGrid的重点是个性化向用户呈现来源的方式，从本质来说，特定领域的起源体系结构必须为每个新领域重新开发，记录过程文档是许多领域的共同话题，所以开发一个记录过程的通用系统是必要的的。
数据库系统的起源集中在数据谱系问题上，这个问题可以概括为跟定一个数据项，确定用于产生该项的源数据。Wooduff使用弱反演技术来解决这个问题，后来用它来提高数据库可视化，数据谱系问题已经正式化，并且开发了 在关系数据库生成谱系数据的算法，Buneman等人主张用基于时间戳的归档机制来用于变更跟踪，开发了基于关系数据库可扩展的标记语言数据库。

开发系统

已经开发了几个系统为应用程序提供中间件支持，这些系统提供一种通用机制，记录过程文档和查询结果的出处，以便在多个应用程序中跨域使用，并且不受本地机器的限制，建立在WebDav
标准上的科学应用中间件SAM，SAM可以提供存储和管理记录，元数据，和语义关系的数据，通过向存储在SAM存储库中的文件添加元数据来提供对起源的支持。
Chimera虚拟数据系统包含一个虚拟数据目录，由虚拟数据模式定义，并通过查询语言访问，该模式分为三个部分，转换，派生和数据对象，一个转换代表一个可执行文件，一个数据对象是一个派生文件的输入或输出，由chimera提供虚拟数据语言用于描述模式元素和查询数据目录，使用虚拟数据语言，用户可以查询目录来检索导致结果的转换，使用通用描述语言的好处就是在不理解底层数据的情况下，提取实体之间的关系，
Szomszor主张为在网络中记录过程文档提供基础设施支持，提供实验系统，该系统提供在过程文档被记录后被处理过程文档的几种机制，基于一个工作流执行引擎，引擎是将数据提交给源服务，提交的数据是关于由执行工作流脚本的各种web服务调用的信息。

小结

上面的系统中没有将记录，存储，和使用过程文档的独立于应用程序的先进方法，本文用起源架构实现了这一点。

用例

生物学

用例一：内含子复杂性实验

内含子复杂性实验(ICE)是一项生物信息学实验，旨在确定内含子和外显子的相对Kolmogorov复杂性，以及两者复杂性之间的关系。外显子是编码蛋白质的染色体子序列，内含子是分隔染色体外显子的子序列。这个实验使用了许多服务，有些是外部提供的，有些是由生物学家编写的，这些服务分析从公众可访问的数据库中提取的数据，如基因银行[17]。当发现一个潜在的有趣结果时，生物学家用不同的配置参数重新运行工作流的各个部分，试图确定为什么会产生这个结果。

用例二：候选基因实验

ThemyGrid 项目试图为生物信息学家提供一个工作环境，特别是提供可被多方使用的门户和中间件。实验过程通过将它们编码为工作流并在工作流执行引擎中执行来实现自动化或部分自动化。我的网格一直致力于一些生物信息学实验，这些实验属于一个名为候选基因实验(CGE)的类别。这些实验旨在从现有的数据来源中发现尽可能多的关于基因(候选基因)的信息，以确定它是否参与导致遗传疾病。

用例三：蛋白质鉴定实验

蛋白质组学是对蛋白质组的研究，蛋白质组被定义为单个生物产生的所有蛋白质。蛋白质鉴定实验(PIE)用于鉴定给定样品中的蛋白质，例如，确定哪些蛋白质仅存在于患有某种疾病的人身上。为此，蛋白质片段的特征可以为蛋白质的鉴定提供证据。这需要首先在明确的点，即在给定的氨基酸上破坏蛋白质，产生肽链。用质谱仪检查这些肽，以确定它们的质荷比。为了获得更准确的结果，然后通过用带电气体轰击肽，肽在随机点被进一步片段化，这些片段再次被馈送到光谱仪。先前分析结果的数据库用于将肽特征与可能的蛋白质相匹配，以及提供关于蛋白质的进一步信息，例如它们所属的功能组。

物理学

用例一：粒子探测实验

在高能物理(HEP)实验中，大量数据从探测器中收集并存储，准备由专业物理学家小组(物理工作组(PWG))以不同方式进行分析，以识别高能粒子碰撞产生的粒子痕迹。粒子探测实验(PDE)的实验过程是复杂的，数据提供者欧洲粒子物理研究所(CERN)对原始数据进行一些处理，然后在世界各地进行进一步的分析。将数据作为一个整体进行管理的工作组，以及提供资源的每个人，被称为本实验的协作组。

化学

二次谐波产生实验

二次谐波产生实验(SHGE)通过反射激光并测量激光束偏振发生的变化来分析液体的特性。

计算机科学

服务可靠性实验

电子需求项目试图通过检查服务的相对可靠性和质量，使面向服务的网格更加可靠，并更好地适应使用它们的人。在服务可靠性实验(SRE)中，几个服务使用不同的算法实现相同的功能。对服务返回的结果进行比较，以增加结果有效的保证。

安全测试实验

语义防火墙项目旨在处理支持服务提供商和客户之间复杂的动态关系的安全影响，这些服务提供商和客户在不同的域中运行，在这些域中可能存在不同的安全策略和不同的安全功能。在安全测试实验(STE)中，客户希望将他们对数据的访问委托给另一个服务，因此服务之间的复杂交互对于确保满足安全要求是必要的。语义防火墙将推理多种安全策略，并允许在此基础上进行不同的操作。推理可以依赖于与现有安全基础设施交互的实体和其他上下文信息。语义防火墙可以被看作是引导交互方通过推理的基础，确保交互遵循各个域的安全策略。

用例分析

上面的实验为我们提供了一些用例，包括捕获和使用过程文档。在这一节中，我们介绍了用例提出的每个问题，并介绍了每个最能说明问题的用例。所识别的问题被表达为一般的技术需求，以便可以做出关于合适的起源体系结构的设计决策。在每种情况下，我们都以声明的形式给出了技术要求，“PASOA应提供……”参考系统的特定行为，其中PASOA指的是我们希望设计的起源架构。每一个声明都没有暗示架构如何实现需求，这样其他人就可以使用它们来开发PASOA的替代方案。
给定项目目标，我们遵循下面的方法从每个用户收集用例。
我们对我们的目标进行了广泛的描述，表明我们打算设计一个体系结构来帮助记录实验过程中发生的事情。因为我们的目标是发现用户当前无法执行的任务，所以我们向每个后续用户展示了从以前的用户那里收集的一些用例作为灵感。
我们对用户已经考虑过的与出处相关的用例进行了编目，并考虑了从可用的过程文档中可能获得的其他好处，即功能需求。
此外，我们向用户询问了我们可能提供的任何软件的非功能性需求。我们从访谈中提取了具体的功能性和非功能性用例，确定了涉及的参与者和他们执行的操作，并以一致的形式编写了它们。在这种情况下，参与者是用例中执行某些操作的组件，可能是服务、人、机器等。我们向用户展示了书面用例，以确认它们是正确的，并让他们纠正不正确的地方。

功能需求

在这一节中，我们将展示那些为起源架构提供功能需求的用例。本节中的每个用例都是根据相关参与者及其执行的操作来定义的。每个用例的最后一句话是一个起源问题:一个可以通过处理记录的过程文档来实现的动作。起源问题对起源体系结构提出了明确的要求，因此隐含了一般的技术要求。为了便于识别，每个用例中的出处问题都用斜体表示。所有的实验都会产生一些数据，所以一个实验的记录就是一个或多个数据项的出处。当一个问题被问及由起源体系结构记录的信息时，我们的意思是它被问及由实验产生的一个或多个数据项的起源。

用例一

(ICE)生物信息学家A，B，从GenBank下载一条人类染色体的序列数据，进行实验。B后来对同一条染色体的数据进行了同样的实验，同样是从GenBank下载的。比较两个实验结果，注意到一个差异。确定这种差异是由实验过程或配置改变引起的，还是由染色体数据不同(或两者都有)引起的。
首先，这个用例需要实验执行的记录，即发生的服务之间的交互，包括它们之间传递的数据。同一个用例提供了另一种过程文档的例子，即在实验运行时参与实验的任何服务的状态的额外信息。每个服务通常依赖于一个算法，该算法可能会随着时间的推移而修改，并且很可能只有运行该算法的服务才能访问它。如果B可以确定算法在实验运行之间是否发生了变化，B也可以确定结果是否是由于这种变化。

用例二

(CGE)生物信息学专家B使用工作流制定引擎制定实验工作流，W. W处理源数据以产生中间数据，然后处理中间数据以产生结果数据。检索结果数据。然后检查用于产生结果数据的源数据和中间数据。用例2展示了对第三种过程文档的渴望:过程中数据项之间的关系，例如，将结果与产生它的过程中的中间数据相关联。我们可以将过程文档的类型总结如下。
交互:记录服务之间发生的交互，包括它们之间传递的数据。
行动者状态:实验运行时参与实验的服务的额外信息。
关系:关于过程中一个数据项如何与另一个数据项相关联的信息
技术要求1。PASOA应该提供交互、参与者状态和关系的记录和查询。

数据的结构和身份

演员以消息的形式交换数据。消息可以指定客户端希望服务执行的操作，以及要分析和/或用于配置分析的一组结构化数据。

用例3

生物信息学专家B在一组染色体数据上进行实验，从中提取外显子和内含子序列。作为该实验的结果，乙确定了一个高度压缩的内含子序列。b识别内含子最初来自哪条染色体。2在用例3中，需要一致地识别服务之间交换的消息中的数据元素。我们不能保证数据本身的内容提供了唯一的标识，因此标识可能必须与数据相关联。为了满足关于数据元素的问题，它的标识符应该可以在关于过程文档的查询中使用。最后，要将标识符与过程文档中记录的消息元素相关联，必须有一种方法来引用该元素。

用例四

一位物理学家，P，从一个大型数据集中提取数据的一个子集，归合作组织所有，并在一段时间内对该子集进行实验。协作稍后用新数据更新数据集。p根据新的数据集决定是否应该重新运行实验。
用例4。一位物理学家，P，从一个大型数据集中提取数据的一个子集，归合作组织所有，并在一段时间内对该子集进行实验。协作稍后用新数据更新数据集。p根据新的数据集决定是否应该重新运行实验。
**技术要求2。PASOA应提供标识符与数据的关联，以便在查询中以及通过将实验链接在一起的数据源来引用它。
**
技术要求3。pasoard应该提供包含在流程文档中记录的消息体中的单个数据元素的引用。

元数据和上下文

用户希望询问的问题通常是将关于特定实验的过程文档与其他信息汇总在一起。例如，在候选基因实验中，诸如基因本体[18]之类的本体中的每个数据项的语义类型之类的信息可以被生物信息学家用来提供相信候选基因参与遗传疾病的进一步理由。同样，给定数据项的生产者工作的实验室和项目可以用来帮助确定其准确性的可能性。

用例5。

为了符合健康和安全要求，化学家C在进行实验之前计划了一项实验。该计划是高层次的，例如，包括混合和分析材料的步骤，但不包括测量材料等隐含步骤。c执行实验。后来，另一位化学家R决定进行的实验是否符合计划。2在用例5中，实验的预定义计划不一定与实际执行的步骤完全匹配。如图1所示，单个计划活动可能映射到一个或多个实际活动。正如用例中所描述的那样，计划是在任何过程文档被记录之前产生的，但是被用于与过程文档进行比较。它是过程元数据的一个例子:独立于过程文档但与过程文档结合使用的数据。考虑到过程元数据具有任意广泛的范围，任何支持使用起源的框架都必须考虑到将随过程文档一起查询的元数据存储。

用例6。

(PIE)生物学家B在进行实验确定肽的质荷比之前，设置质谱仪的电压。后来另一位生物学家R判断实验结果，认为特别准确。r确定实验中使用的电压，以便在未来的实验中可以将其设置为相同的电压来测量相同蛋白质的肽。

图1。在二次谐波生成实验中，计划的活动并不完全对应于已执行的活动，因为几个活动可以组成一个计划的活动。图中的箭头显示了活动之间的一些时间或其他依赖关系，这些依赖关系可能记录在流程文档中。

一种特殊类型的元数据是实验中涉及的实体的语义描述。例如，下面的用例需要关于实验中服务之间交换的数据的语义元数据。

用例7。

生物信息学专家B在编码核苷酸序列的FASTA序列上进行实验。后来，评审员R确定该序列是否实际上是由实际上只处理有意义的蛋白质序列的服务处理的。用例7不仅要求提供一个生物数据类型的本体，还要求过程文档可以用来自该本体的语义描述进行注释。然而，这并不要求语义描述与数据存储在同一个地方。
技术要求4。PASOA应该在不同的存储中提供过程文档和相关的元数据，以便在提供查询答案时进行集成

小结

我们发现许多用例将一个实验的运行与另一个进行比较，要求关于浙西二实验的记录包括一个实验与另一个实验的界限，在面向服务的体系结构中，这意味着我们需要将一组服务交互与另一组服务交互区分开来，我们将会话定义为一组服务交互。

用例8。

(SRE)计算机科学家C调用服务X，该服务将两个数字的平均值计算为(a/2)+(b/2)。然后c用同样的两个数字呼叫服务Y，其中Y计算平均值为(a+b)/2。C不知道X和Y是否可靠，所以通过从两者获得结果，C可以比较它们，如果它们相同，就更确定有正确的结果(因为相同的值是由两个不同的服务产生的)。然而，X和Y可以在后台使用公共的第三服务Z，例如执行除法运算。如果Z是错误的，那么来自X和Y的结果可能是一致的，但是是错误的。为了获得额外的保证，C确定X和Y实际上是否使用了公共的第三方服务。

e-Demand中使用相同公共服务的会话:客户端不知道两个服务，A和B使用不同的算法执行相同的功能，依赖于一个公共服务c。

用例8

为了回答起源问题，必须区分两个会话。第一个会话是X及其所有依赖项的执行，第二个是Y及其所有依赖项的执行。该场景如图2所示。起源问题可以表达为:在两个会话中使用了相同的服务吗？同样，生物信息学用例1要求我们比较两个实验，记录为两个会话，并显示差异。
技术要求5。PASOA应提供一种机制，通过该机制将记录的过程文档分组到一个会话中，并允许在会话之间进行比较。

提问

提问出处问题的参与者并不总是事先知道他们的问题所针对的具体实验或数据。例如，在用例9中，我们不知道我们在预先寻找哪些实验，只知道哪些源材料被用作它们的输入，也许还有情境信息，比如实验者。

用例9。

一个实验室收到一批化学药品，样品被分发给该实验室的化学家。化学家C进行了一项实验，但随后检查了结果，发现结果令人怀疑。c确定实验中使用的源材料，然后确定最近哪些实验使用了同一批次的材料。检查这些实验的结果，以确定该批次是否已经被污染，因此应该被丢弃。2在许多实验过程中，我们期望记录大量的过程文档，因此需要一种搜索机制来回答用例9的起源问题。一个实验的数据可以通过过滤中间数据来提高未来结果的质量，如下所示。

用例10。

(PIE)一位生物学家B，随着时间的推移，进行了许多实验来发现肽段的特征。这些片段被用作分析材料中含有肽的证据。通常需要发现几个片段才能确定一个肽，但有些片段是独一无二的，足以单独使用。b确定在分析特定肽的大多数时候会产生具有特定特征的片段，而当该肽不存在时很少或从不产生。2为了理解所需查询的范围，我们可以展示帮助实现上述一些用例所需的查询。为了实现用例1，用户需要两个实验记录的全部内容，以便进行比较。为了实现用例2，用户要求一个给定数据项作为其输出的交互。为了实现用例8，用户需要两个给定实验中使用的所有服务。为了实现用例5，用户要求使用给定的数据项作为输入的所有实验。为了实现用例10，用户要求在先前的蛋白质鉴定实验中输出所有肽作为中间数据。
技术要求6。PASOA应提供在记录时指定的组中返回的过程文档，或根据上下文标准进行搜索。

处理和可视化

在大多数用例中，为了回答起源问题，实验的完整过程文档不会呈现给用户。首先必须对其进行分析，然后以一种能让出处问题的答案变得清晰的形式呈现出来。
技术要求7。PASOA应提供一个框架，使用各种方法引入第4.2.1节中讨论的所有三种类型的过程文档处理(交互、参与者状态和关系)，然后可视化处理结果

不可否认性

在某些情况下，例如，当实验结果证明一种新药的疗效时，出处不仅需要验证实验是否按规定进行，还需要证明。为了帮助实现这一点，实验中的所有参与者可以从他们自己的角度记录过程文档，然后可以比较这些角度。连同其他措施6为了防止串通或篡改工艺文件，联合工艺文件提供了不能否认或否定的实验证据。一个需要多方独立记录过程文档的用例是，实验者的知识产权可能与他们在实验中使用的服务相冲突，如现在所描述的。

用例14

生物信息学专家B进行了一项实验，他们据此开发了一种新药。试图给这种药物申请专利。专利审查员R检查了该实验没有使用只对非商业用途免费的数据库，如Ecoli数据库。2除了能够证明在实验中使用了特定的服务，我们可能还需要能够证明完成的时间，这样研究人员就可以(或不能)声称他们比公布的实验进行得更早。

用例15。

化学家C在特定的时间完成一项实验。D后来进行了同样的实验，并将结果和导致结果的过程提交给专利官员R。C向R声称，他们在D。R确定C是否正确之前进行了实验。2
技术要求8。PASOA应提供一种机制，以不可修改的方式记录适当的过程文件，使结果不可否认。

重复使用实验过程

过程文档可以用来决定将来应该发生什么。进行实验是为了达到某种目的，例如验证一个假设。过程文档可用于识别过程和重复过程。

用例16。

(CGE)生物信息学专家乙用数据库最新版本中的特定人类染色体作为输入数据进行实验。后来，另一位生物信息学专家D更新了染色体数据。乙用最新版本的染色体数据重新进行了同样的实验。

用例17。

生物学家进行一项实验来鉴定样品中的肽。通过将肽及其片段的特征与数据库中已知的匹配进行比较来进行鉴定。在电子科学实验中使用出处的要求17实验中，一些肽被识别，其他的不能被识别。后来，在进行了其他实验后，数据库包含了更多的信息。系统会自动重新对那些未被识别的肽段进行分析。

在用例16中，科学家可以使用过程文档来重现实验。重新设定甚至可以是自动的，因为数据库中的变化可以与使用这些数据库的实验相匹配。为了重新进行实验，需要以下信息:在实验的每个阶段调用的服务以及给每个服务的输入。关于先前实验的过程文档可以以不太自动化的方式用于确定未来实验将如何运行。事实上，有几种不同的方法可以重复使用实验过程。再现是指执行相同的实验，但使用当代数据和服务，而重复是指使用与以前相同的数据和服务执行相同的实验，例如测试结果是否可以再现。此外，与其再次进行整个实验，科学家可能希望只进行到中间结果不同的阶段，以检测差异在哪里。
技术要求9。pasoad应该提供过程文档的使用，以使用相同的过程但是新的输入来重新进行实验，并且用相同的过程和输入来再现实验

聚合服务信息

过程文档提供了实验中使用的服务以及实验本身的信息。结合几个跟踪的信息允许科学家聚集关于在多个实验中使用的单个服务的数据，如下一个用例所示。

用例18。

(CGE)几个生物信息学家使用服务X进行实验。另一个生物信息学家B构建了一个使用X的工作流。B可以根据X以前完成任务所需的平均时间来估计实验可能需要的时间。
技术要求10。PASOA应该通过多个实验的过程文档，提供关于服务的聚合行为和属性的查询。

非功能性需求

其他用例为我们提供了非功能性需求，关于架构应该如何运行。由于所展示的用例强调了对过程文档的记录、存储和使用方式的要求，因此在每种情况下都不存在起源问题，也就是说，并不总是存在由起源架构实现的新功能。

存储

所有出处用例都需要一些可靠的过程文档存储机制；然而，一些国家需要长期储存出处以满足其需求，而另一些国家则需要保存数据，并且只能在短期内获取。前一种用例的例子如下。

用例19。

一个叫C的化学家在做实验。然后c在网上公布他们的结果。另一位化学家R在几年后发现了公布的结果。r通过检查实验过程来确定结果是否有效。2为了使过程文档可以作为出版物的一部分进行访问，它应该在出版物中持续存在，最好是永久存在。另一方面，对于许多用例，过程文档可能只在几个小时、几个月或几年内保持其相关性。
技术要求11。PASOA应规定管理过程文件的存储期限，包括无限期保存数据或在给定期限后删除数据。

还有其他特性不在这里一一列举了

小结

在要求用户提供特定于他们的应用程序的起源用例时，我们经常展示我们从其他应用程序中得到的用例，以提供灵感和对我们感兴趣的问题的理解。这只是一种有效的技术，因为相同的用例以稍微不同的形式出现在应用程序中。从用例的分析来看，我们认为功能起源用例(用例1到18)可以跨领域应用**，因为它们只是提出复杂过程的问题，这些问题存在于我们工作适用的所有领域中**。例如，用例2中候选基因实验所描述的对过程中使用的源数据和中间数据的渴望，在所有被调查的生物学、物理学和化学应用中被认为是重要的，因为它提供了一种解释实验结果的方法。同样，虽然我们介绍了用例11，其中科学家确认实验符合预定义的计划，但在二次谐波产生实验的背景下，它也适用于蛋白质鉴定实验以及我们调查的其他非电子科学应用，如医疗程序和业务流程。因此，我们分析的一个方面是从功能用例中抽象出不太具体的、独立于应用程序的任务，这是一个起源架构应该帮助完成的。

提议的架构

我们的目标是提供一个能够处理所呈现的用例的框架架构。我们的分析导致了许多建筑设计决策，我们在本节中对此进行了概述。然后我们描述我们的起源架构。

设计决策

关注点分离

这个框架不仅可以满足上面的用例，还可以满足出现的新用例。应当指出的是，技术要求中表达的关切很少能普遍和统一地适用于所有应用；一般只需要记录、查询和处理过程文档。由于查询要求以可查询的形式记录数据，而处理要求可以使用预定义的机制来查询数据，因此记录是所有其他人都依赖的起源体系结构的一部分。我们还注意到，记录需要在应用程序之间保持一致，以满足我们对可重用的开放系统查询和过程文档处理的目标。因此，我们定义了一个三层的分层体系结构，每一层都建立在前面的基础上:(1)记录和访问的基础，(2)查询，和(3)处理。在可能的情况下，应该将应用程序特定性提升到这三层，以便将一般问题与特定于应用程序的问题分开。

作为断言的文档

我们注意到多个参与者可以提交关于同一过程的不同文档。起源体系结构依赖于参与者来记录关于发生了什么的准确的过程文档，以便回答起源问题。当参与者出错或恶意记录错误信息时，过程文档可能不准确。因此，起源架构不应该要求那些问起源问题的人相信提供给他们的所有过程文档:他们可以根据他们对提交每个过程文档的参与者的意见来判断可能的准确性。因此，我们认为过程文档是由参与过程的参与者对已经发生的过程的一系列断言组成的。一个p断言是一个由一个参与者做出的断言，并且与一个过程有关，过程文档是一组p断言。

基于交互的文档结构

我们已经确定至少有三种类型的过程文档:交互、参与者状态和关系。因此，我们的架构必须支持对所有这些类型数据的记录和使用断言。我们认为，任何p-断言都可以被视为与交互有关，如下所示。交互p-断言声明交互中参与者之间交换了什么信息。参与者状态p-断言是记录交互的元数据，因为它们描述了交互发生时参与者的状态。数据之间的关系可以记录为交换数据的交互之间的关系。所以我们的架构应该是p基于演员之间的交互的记录，并且允许关于每个交互的元数据被另外关联地记录。

交互特定或非起源元数据

给定交互的基础，我们可以进一步分离关注点。特定于交互的元数据，包括参与者的状态或交换的数据，必须明确与交互直接相关，因此应在我们的记录流程文档程序中得到认可。其他元数据可以存储在其他地方，并引用流程文档来明确关联。然后，在执行查询或处理时，将一起使用元数据。

商店中元素的引用

为了在交互中将元数据与参与者和数据相关联，必须有一种方法来引用这些实体。首先，我们可以提供一种方法来引用记录的交互和在这些交互中传递的消息。然后，虽然实验中使用的数据结构会有很大差异，但我们可以在查询级别引用数据元素时提供一定的一致性。

用于划分会话的跟踪程序

我们确定了在应用程序执行中划分独立进程或会话的需要。我们可以这样做的一种方法是在一个会话中发送的所有应用程序消息中引入标识符，称为跟踪者。任何接收到包含跟踪程序的消息的参与者都应该将其延续到参与者在同一会话中发送的所有后续消息中:这样，跟踪程序就像事务系统中的动态上下文一样。通过向起源系统查询所有包含跟踪器的交互p-断言，我们可以在一个会话中检索所有(记录的)交互。

可扩展的查询架构

因为数据有多种形式和结构因为在某些情况下，我们应该尝试适应现有的标准和软件，并且因为关于过去实验的问题在应用程序之间有很大的不同，所以我们不能也不应该为它们提供一个单一的查询接口。然而，我们可以采取分层的方法，在过程文档上提供一些通用的搜索机制，目的是简化特定于应用程序的查询引擎的开发。如果在没有这些查询机制的情况下搜索结果更容易，就不应该强制使用这些查询机制。
。。。。。

具体实现

我们已经创建了该架构的第一个基本实现，包括一个可从www.pasoa.org下载的出处存储网络服务，并开始评估它在满足用例方面的有效性。为了说明如何将架构应用于实现起源用例，我们现在描述两个不同的用例实现，一个用于内含子复杂性实验，另一个用于服务可靠性实验。选择这些特定的问题是因为它们说明了两个完全不同的应用程序和用例。对于每一个，我们描述实现，并将涉及的物理组件映射到逻辑架构如图3所示。这些描述旨在说明如何将架构应用于实现特定的起源用例。每个实现的细节超出了本文的范围，但在其他出版物中有完整的介绍[21，36]。其他用例正在与各自的应用科学家合作实施。