ACM通信gydF4y2Ba

贡献的文章gydF4y2Ba

方法包括:使用通用工作流语言标准化计算重用和可移植性gydF4y2Ba

作者:Michael R. Crusoe, Sanne Abeln, Alexandru Iosup, Peter Amstutz, John Chilton, Nebojša Tijanić， Hervé Ménager, Stian Soiland-Reyes, Bogdan Gavrilović， Carole Goble, CWL社区gydF4y2Ba
ACM通信，2022年6月，第65卷第6期，54-63页gydF4y2Ba
10.1145 / 3486897gydF4y2Ba
评论gydF4y2Ba

计算工作流被广泛应用于数据分析，为现代社会的创新和决策提供了便利。但它们越来越受欢迎也是令人担忧的一个原因。除非我们将计算重用和可移植性标准化，否则工作流的使用可能最终会阻碍协作。我们如何才能享受计算工作流的共同好处并消除此类风险?gydF4y2Ba

回到顶部gydF4y2Ba

关键的见解gydF4y2Ba

为了回答这个普遍的问题，在这项工作中，我们提倡将工作流思维作为一种跨所有领域和从业者的共享推理方法，引入通用工作流语言(CWL)作为描述和共享计算工作流的实用标准集，并讨论这些标准已经成为科学和工程中多个领域的用户的不同社区的核心的原则。本文主要介绍CWL标准和CWL项目的概况，并辅以CWL标准中提供的技术细节。gydF4y2Ba^{一个gydF4y2Ba}

工作流思维是“将流程概念化为配方和协议，用计算步骤构建为数据流[或工作流]图，然后开发工具和方法来形式化、分析和交流这些流程描述”的一种形式。gydF4y2Ba^14gydF4y2Ba它引入了工作流，这是一种有助于将特定领域(例如特定科学或工程领域)的专家知识与计算专家知识分离的抽象概念。源于工作流思维，agydF4y2Ba计算工作流gydF4y2Ba描述用于计算的流程，其中流程的不同部分(任务)是相互依赖的—例如，任务可以在它的前任(部分)完成之后开始处理，任务之间的数据流动也在此进行。gydF4y2Ba

目前，存在许多支持简单工作流执行的竞争系统(gydF4y2Ba工作流的跑步者gydF4y2Ba)或提供全面的工作流程和数据管理(gydF4y2Ba工作流管理系统gydF4y2Ba)．每种方法都有自己的语法或方法来描述工作流和基础设施需求，这可能会限制计算重用和可移植性。尽管数据流正变得越来越复杂，但大多数工作流抽象并不支持明确的数据流规范，这大大增加了第三方重用和移植工作流的成本。gydF4y2Ba

因此，我们在广泛而实际地采用工作流思维时发现了一个重要的问题:尽管社区需要gydF4y2Ba写的工作流gydF4y2Ba(执行用多种不同计算机语言编写的工具的工作流程)和gydF4y2Ba多党工作流gydF4y2Ba，采用和管理不同的工作流程系统既费钱又困难。在这项工作中，我们建议通过一个通用的抽象来驯服这种复杂性，这个抽象涵盖了实践中使用的大多数特性，并且在许多工作流系统中已经(或可以)实现。gydF4y2Ba

中所描述的计算工作流gydF4y2Ba图1gydF4y2Ba，实践者通过采用CWL标准解决了这一问题。在这项工作中，我们假设CWL标准提供了共同的抽象，可以帮助克服机构和用户之间共享工作流的主要障碍。CWL通过提供一种声明性语言来实现这一点，该语言允许表达从不同的软件工具构建的计算工作流——每个工具都通过它们的命令行界面执行，每个工具的输入和输出都明确指定，输入可能来自其他工具的执行。我们还着手引入CWL标准，重点包括三个方面:gydF4y2Ba

图1。摘自一个大型微生物组生物信息学CWL工作流程。gydF4y2Ba^27gydF4y2Ba，*gydF4y2Ba

1. CWL标准关注于维护工具和工作流的描述和执行之间的关注点分离，提出了一种只包含跨多个实践社区常用操作的语言。gydF4y2Ba
2. CWL标准支持工作流自动化、可伸缩性、抽象、来源、可移植性和可重用性。gydF4y2Ba
3. 为了实现这些结果，CWL项目采取了有原则的、社区优先的开源和开放标准的方法。gydF4y2Ba

CWL标准是一个开放和免费的标准制定社区的产物。虽然CWL项目开始于生物信息学领域，但它的许多贡献者塑造了这些标准，使之在任何面临“由许多方面用许多编程语言编写的许多工具”问题的领域都有用。自2016年批准第一版以来，CWL标准已被用于其他领域，包括水文、射电天文学、地理空间分析、gydF4y2Ba^{13gydF4y2Ba，gydF4y2Ba23gydF4y2Ba，gydF4y2Ba32gydF4y2Ba}高能物理,gydF4y2Ba^4gydF4y2Ba除了快速增长的生物信息学领域，如宏基因组学gydF4y2Ba^27gydF4y2Ba和癌症的研究。gydF4y2Ba^24gydF4y2BaCWL标准收录在IEEE 2791-2020标准中，由美国FDA发起并采用，gydF4y2Ba^16gydF4y2Ba以及荷兰国家开放科学计划。gydF4y2Ba^34gydF4y2Ba表中列出了CWL标准的免费和开源实现。Curii (Arvados)、DNAnexus、IBM (IBM®Spectrum LSF)、Illumina (Illumina Connected Analytics)和Seven Bridges等供应商也提供了多种商业支持的系统，这些系统遵循CWL标准来执行工作流程。CWL标准的灵活性使我们能够在COVID-19公共数据库和分析资源上进行快速协作并建立原型。gydF4y2Ba^15gydF4y2Ba

CWL标准所建议的关注点分离使不同的项目得以实施，也可使工程和大型工业项目受益。同样地，Docker或其他分发分析工具的软件容器技术的用户可以仅利用CWL命令行工具标准来访问一个结构化的、独立于工作流的描述，包括如何在容器中运行他们的工具，必须向容器提供什么数据，预期结果，以及在哪里找到它们。gydF4y2Ba

回到顶部gydF4y2Ba

工作流程和工作流程标准的背景知识gydF4y2Ba

工作流程及其基于标准的描述具有解决许多科学和工程领域关键问题的潜力。gydF4y2Ba

为什么工作流?gydF4y2Ba在许多领域中，工作流包括终端用户和第三方用多种不同的计算机语言编写的各种分析组件。在生物信息学、图像分析和射电天文学等数据密集型领域，这种多语言和多方工作流程已经很常见或占主导地位。我们设想它们可以为许多其他领域带来重要的好处。gydF4y2Ba

为了让数据通过分析工具传递，生物信息学家等领域专家使用专门的命令行界面，gydF4y2Ba^{12gydF4y2Ba，gydF4y2Ba31gydF4y2Ba}而其他领域的专家则使用专有的、定制的框架。gydF4y2Ba^{2gydF4y2Ba，gydF4y2Ba5gydF4y2Ba}工作流引擎还有助于有效地管理用于运行科学工作负载的资源。gydF4y2Ba^{7gydF4y2Ba，gydF4y2Ba10gydF4y2Ba}

工作流方法帮助构建这些命令行分析工具的整个应用程序:开发人员构建如何运行这些命令行工具的图形或文本描述，科学家和工程师连接他们的输入和输出，以便数据流动。复杂工作流问题的一个例子是宏基因组分析gydF4y2Ba图1gydF4y2Ba说明一个子集(agydF4y2Basub-workflowgydF4y2Ba)．gydF4y2Ba

在实践中，许多研究和工程小组使用的工作流程的类型描述gydF4y2Ba图1gydF4y2Ba．然而，正如最近发表在《技术工具箱》的一篇文章中强调的那样gydF4y2Ba自然,gydF4y2Ba^29gydF4y2Ba这些团队通常缺乏跨机构和基础设施共享和协作的能力，而不需要昂贵的人工翻译他们的工作流程。gydF4y2Ba

使用工作流技术，尤其是数字分析过程，已经变得相当流行，而且似乎没有放缓的迹象。一个工作流管理系统，银河出版图书馆，最近庆祝了它的第10000次引用，并且有309多个计算数据分析工作流系统已知存在。gydF4y2Ba^bgydF4y2Ba一个过程，无论是数字化的还是其他形式的，可能会发展到如此复杂的程度，以至于它的作者和用户很难理解它的结构、扩展和管理它，以及跟踪过去发生的事情。流程依赖项可能是无文档化的、模糊化的，或者以其他方式有效地不可见。如果缺少通用的框架或词汇表，外来者或新人可能会发现即使是大量文档化的过程也很难理解。更频繁地运行流程或使用更大的输入不太可能由初始实体(即脚本或运行流程的人)实现。曾经看似合理的手动步骤——在这里运行这个命令，在那里粘贴结果，然后向这个人请求许可——将在移植和重用的压力下成为瓶颈。非正式日志(如果有的话)很快就不适合帮助组织了解发生了什么、什么时候发生的、由谁进行的以及使用哪些数据。gydF4y2Ba

工作流技术旨在通过提供抽象、可伸缩性、自动化和来源(ASAP)特性来解决这些问题。gydF4y2Ba^8gydF4y2Ba工作流构造支持对组件、它们之间的关系以及组件的输入和输出进行清晰的抽象，将它们转化为具有文档化期望的、标记良好的工具。这种抽象支持:gydF4y2Ba

• 缩放:gydF4y2Ba执行可以并行化和分布式。gydF4y2Ba
• 自动化:gydF4y2Ba工作流引擎可以使用抽象来跟踪、计划和管理任务执行。gydF4y2Ba
• 起源跟踪:gydF4y2Ba任务、执行器、输入和输出的描述(带有时间戳、标识符(唯一名称)和其他日志)可以相互存储，以便稍后回答结构化查询。gydF4y2Ba

为什么工作流标准?gydF4y2Ba虽然工作流非常流行，但在CWL标准之前，所有工作流系统彼此不兼容。这意味着不使用CWL标准的用户每次使用另一个工作流系统时都需要以不同的方式表达他们的计算工作流，导致本地成功但全局不可移植性。gydF4y2Ba

工作流的成功现在是他们最大的缺点。用户被锁定在特定的供应商、项目和特定的硬件设置上，阻碍了共享和重用。即使是非学术机构也会遇到这种情况，因为缺乏标准或采用标准，阻碍了公司内部和公司之间在计算方法上的有效合作。同样，这种不可携带性也影响到公共/私人伙伴关系以及公共研究人员的技术转让潜力。gydF4y2Ba

第二个重要的问题是，当学术研究中报道计算分析时，不完整的方法描述是常见的。gydF4y2Ba^17gydF4y2Ba复制、重用和复制gydF4y2Ba^11gydF4y2Ba在这些数字化方法中，需要完整地描述使用了哪些计算机应用程序，它们是如何使用的，以及它们如何相互连接的。为了精确和互操作性，这个描述也应该采用适当的、标准化的、机器可读的格式。gydF4y2Ba

共享和重用工作流的标准可以为描述可移植的、可重用的工作流提供解决方案，同时也可以是工作流引擎和供应商中立的。gydF4y2Ba

基于标准的工作流描述共享还解决了第二个问题:共享时工作流描述的可用性提供了所需的信息，而结构化的、基于标准的方法所提供的描述的质量远远高于当前科学报告中随意的、非结构化的、几乎总是不完整的描述的方法。此外，描述的操作部分可以由工作流管理系统自动化，而不是由领域专家自动化。gydF4y2Ba

虽然(数据)标准被普遍采用，并已成为知识表示领域资助项目的期望，但工作流和工作流引擎还不能这样说。gydF4y2Ba

回到顶部gydF4y2Ba

通用工作流程语言标准的特点gydF4y2Ba

通用工作流语言标准旨在涵盖用户的共同需求以及工作流运行器或平台的共同实现特性。本节的其余部分将概述CWL的特性，如何将它们转换为CWL格式的执行工作流，以及CWL标准在哪些地方没有帮助。gydF4y2Ba

CWL标准支持多语言和多方工作流程，从而实现了计算的重用和可移植性。为此，CWL标准的每个版本都有两个版本gydF4y2Ba^cgydF4y2Ba主要组成部分:(1)描述命令行工具的标准;(2)描述组成这种工具描述的工作流的标准。的目标gydF4y2BaCWL命令行工具说明标准gydF4y2Ba是描述一个特定的命令行工具是如何工作的:输入和参数及其类型是什么?如何向命令行调用添加正确的标志和开关?在哪里可以找到输出文件?gydF4y2Ba

CWL标准定义了一个gydF4y2Ba显式的语言gydF4y2Ba，无论是在语法上，还是在数据和执行模型上。它的文本语法派生自YAML，gydF4y2Ba^dgydF4y2Ba不限制细节的数量。例如,gydF4y2Ba图2一个gydF4y2Ba描述一个具有稀疏细节的简单示例gydF4y2BaFigure2bgydF4y2Ba描述了相同的示例，但在执行过程中增加了更多细节。工具的每个输入都有一个名称和一个类型—例如，File(请参见gydF4y2Ba图2 bgydF4y2Ba工具描述作者被鼓励包含所有组件的文档和标签(如gydF4y2Ba图2 bgydF4y2Ba)，以便为任何给定的CWL描述自动生成有用的可视化描述，甚至图形用户界面(gui)。关于工具描述作者的元数据鼓励对他们的工作进行归因。所示gydF4y2Ba图2 bgydF4y2Ba，项目3，这些工具描述可以包含定义良好的提示或强制要求，例如使用哪个软件容器或所需计算资源的数量:内存、CPU核的数量、磁盘空间的数量，和/或完成步骤或整个工作流的最大时间或截止日期。gydF4y2Ba

图2。CWL语法和渐进增强的示例。gydF4y2Ba

CWL执行模型是显式的。gydF4y2Ba每个工具的运行时环境都是显式的，任何必需的元素都必须由CWL工具描述作者指定(与提示相反，提示是可选的)。gydF4y2Ba^egydF4y2Ba每个工具调用都使用一个单独的工作目录，该目录根据CWL工具描述填充—例如，使用工作流作者显式指定的输入文件。一些应用程序需要特定的文件名、目录布局和环境变量，CWL命令行工具标准中有额外的结构来满足它们的需要。gydF4y2Ba

显式运行时模型支持可移植性gydF4y2Ba，通过显式地显示数据位置。作为gydF4y2Ba图3gydF4y2Ba表示，这允许在CWL标准的各种实现所提供的不同环境中执行CWL工作流:作者-科学家的本地环境(例如，单个桌面计算机、笔记本电脑或工作站)、远程批处理生产环境(例如，集群、整个数据中心，甚至全球多数据中心基础设施)和按需云环境。gydF4y2Ba

图3。CWL可移植性的例子。gydF4y2Ba

CWL标准明确支持使用gydF4y2Ba软件容器gydF4y2BaDocker和Singularity等技术，以支持底层分析工具的可移植性。gydF4y2Ba图2 bgydF4y2Ba， Item 2说明了从码头拉出Docker容器映像的过程。io注册;然后，工作流引擎自动在容器中挂载文件和文件夹。图中所示的容器是由值得信赖的作者开发的，在生物信息学领域常用，期望其结果具有可重复性。事实上，容器的使用可以被视为确认工具的执行是可复制的，当只使用它显式声明的运行时环境时。同样的,当gydF4y2Ba分布式执行gydF4y2Ba，则不需要更改CWL工具描述。文件或目录输入已经在CWL描述中显式定义，因此(分布式)工作流运行器可以处理计算节点之间的作业安置和数据路由，而无需额外配置。gydF4y2Ba

通过这两个特性——数据路径的特殊处理和可选但推荐使用的软件容器——CWL标准实现了可移植性(执行“无需更改”)。虽然可移植性可能受到软件容器技术无法控制的各种因素的影响(例如，底层操作系统内核或处理器结果的变化)，但实际上，完全相同的软件容器和数据输入无需用户进一步调整就可以实现可移植性。gydF4y2Ba

为了支持CWL标准中没有的特性，这些标准定义了gydF4y2Ba扩展点gydF4y2Ba这允许以显式定义的方式提供名称间隔的、特定于供应商的特性。如果这些扩展没有从根本上改变工具的操作方式，那么它们将被添加到提示列表中，其他兼容cwl的引擎可以忽略它们。但是，如果需要使用扩展来正确地运行所描述的工具(例如，由于需要一些专门的硬件)，则在需求项下列出该扩展，而与CWL兼容的引擎可以识别并显式声明它们无法执行该CWL描述。gydF4y2Ba

CWL工作流程描述标准gydF4y2Ba建立在CWL命令行工具标准之上。它具有相同的YAML或json风格的语法，具有显式的工作流级输入、输出和文档(gydF4y2Ba图2 cgydF4y2Ba)．工作流描述由一系列步骤组成，包括CWL命令行工具或CWL子工作流，每个步骤都重新暴露其工具所需的输入。每个步骤的输入都通过引用公共项的名称来连接gydF4y2Ba工作流程的输入gydF4y2Ba或其他步骤的输出。的gydF4y2Ba工作流程输出gydF4y2Ba公开工作流步骤的选定输出，明确将从工作流返回哪个中间步骤输出。所有连接都包括标识符，CWL文档的作者鼓励对标识符进行有意义的命名——例如，“reference_genome”而不是“input7”。gydF4y2Ba

CWL工作流形成明确的数据流，这是特定计算分析所需要的。步骤之间的连接性定义了部分执行顺序。当多个步骤的所有输入都满足时，就允许并鼓励并行执行步骤。例如,在gydF4y2Ba图1gydF4y2Ba， "find_16S_matches"和"find_S5_matches"处于相同的数据依赖级别，可以并发执行，也可以按任意顺序顺序执行。此外,一个gydF4y2Ba散射gydF4y2Ba构造允许重复执行CWL步骤(可能在时间上重叠，这取决于可用资源)，其中大多数输入都是相同的，除了一个或多个输入是不同的。这无需修改底层工具描述即可完成。从CWL 1.2版本开始，工作流还可以根据指定的中间输入或自定义布尔值计算，有条件地跳过步骤(工具或工作流)的执行。结合这些特性可以实现灵活的gydF4y2Ba分支gydF4y2Ba机制，它允许工作流引擎在工作流启动之前计算数据依赖关系，从而保持数据流范式的可预测性。gydF4y2Ba

与依赖于特定于每个工作流的隐式文件路径的硬编码方法相比，CWL工作流更灵活、可重用和可移植，从而支持可伸缩性。CWL标准中使用显式运行时环境，结合显式输入/输出形成数据流，支持步骤重新排序和显式处理迭代。这些特性支持可伸缩的远程执行，更普遍地说，支持灵活使用运行时环境。此外，来自多个工作流的单个工具定义可以在任何新的工作流中重用。gydF4y2Ba

CWL工作流描述也是未来的证明。CWL文档的前向兼容性是有保证的，因为每个CWL文档都声明了它是为哪个版本的标准编写的，而且小版本不会改变大版本所需的特性。一个独立的升级程序可以自动将CWL文档从一个版本升级到下一个版本，而且许多支持CWL的平台会在运行时内部更新用户提交的文档。gydF4y2Ba

执行CWL格式的工作流程。gydF4y2BaCWL是一套标准，而不是要安装、购买或租用的特定软件产品。CWL标准需要得到实施才能发挥作用;CWL标准的一些实现列表在gydF4y2Ba表格gydF4y2Ba．声称符合CWL标准的工作流/工具运行器在如何以及在何处执行用户的CWL文档方面被允许有很大的灵活性，只要他们满足了这些文档中写的需求。例如，允许(并鼓励)在所有能够满足用户指定的资源需求的可用计算机上分发工作流的执行。CWL标准没有定义的执行方面包括用于工作流执行和实时监控的Web api。gydF4y2Ba

表格选定的实现CWL标准的F/OSS工作流运行器和平台。gydF4y2Ba

例如，在CWL工作流描述标准的第4节中有关于一个步骤何时应该被认为可以执行的详细信息，但是一旦所有的输入都可用，准确的时间取决于工作流引擎本身。gydF4y2Ba

步骤执行可能会导致临时或永久失败，如CWL工作流描述标准第4节所定义的那样。工作流引擎必须控制任何自动故障恢复尝试—例如，重新执行工作流步骤。大多数实现CWL标准的工作流引擎都具有在报告永久故障之前尝试多次重新执行(由用户设置)的功能。gydF4y2Ba

CWL社区开发了以下优化方案，而不需要用户改写他们的工作流程:gydF4y2Ba

• 自动流数据输入和输出，而不是等待所有数据被下载或上传(这些数据输入或输出被标记为“streamable: true”)。gydF4y2Ba
• 基于数据位置的工作流步骤放置，gydF4y2Ba^18gydF4y2Ba资源需求和/或数据传输成本。gydF4y2Ba^19gydF4y2Ba
• 重用以前计算步骤的结果，即使来自不同的工作流，只要输入是相同的。这可以由用户通过CWL工作流标准中的“WorkReuse”指令来控制。gydF4y2Ba

真实世界的大规模使用。gydF4y2BaCWL用户和供应商经常报告说，他们在一个工作流执行中分析了5000个全基因组序列。一个商业供应商的客户报告了一个成功的工作流运行，其中包含8000宽的步骤;整个工作流执行了25000个容器。根据设计，CWL标准对处理的文件大小或并行运行的任务数量没有任何技术限制。主要的可伸缩性瓶颈是与硬件相关的—没有足够的机器具有足够的内存、计算能力或磁盘空间来处理更大规模的不断增长的数据。随着未来技术的进步，这些边界将不断扩大，CWL标准应该能够跟上，而不是成为一种限制。gydF4y2Ba

CWL什么时候没用了?gydF4y2BaCWL标准是为一种特殊风格的命令行、基于工具的数据分析而设计的。因此，以下情况超出范围，不适合(或可能)描述使用CWL语法:gydF4y2Ba

• 与有状态(web)服务的安全交互。gydF4y2Ba
• 工作流步骤之间的实时通信。gydF4y2Ba
• 与命令行工具的交互包括:1)构建命令行并提供可用的文件输入(包括用户提供的和在执行之前从其他输入合成的);2)一旦执行完成，使用工具的输出，以创建/更改的文件、POSIX标准输出和错误流以及工具的POSIX退出代码的形式。gydF4y2Ba
• 超越条件步骤的先进控制流技术。gydF4y2Ba
• 运行时工作流图操作:在工作流执行期间动态添加或删除新步骤，超出了原始工作流描述中任何预定义的条件步骤执行测试。gydF4y2Ba
• 包含循环的工作流:“重复此步骤或子工作流特定次数”或“重复此步骤或子工作流直到满足条件”。gydF4y2Ba^fgydF4y2Ba
• 需要在特定日期或特定时间运行特定步骤的工作流。gydF4y2Ba

回到顶部gydF4y2Ba

开源、开放标准、开放社区gydF4y2Ba

鉴于潜在用户、实现者和其他涉众数量众多且种类多样，我们假设像CWL这样的项目需要代码、标准和社区的联合开发。事实上，这些需求是CWL基本设计原则的一部分;从长远来看，这些原则促进了自由和开源软件的发展gydF4y2Ba侧边栏gydF4y2Ba“CWL项目和免费/开源软件”)和一个充满活力和活跃的生态系统。gydF4y2Ba

CWL原则。gydF4y2BaCWL项目基于五项原则:gydF4y2Ba

• 原则1:gydF4y2Ba项目的核心是关心其目标的社区。gydF4y2Ba
• 原则2:gydF4y2Ba为了达到最好的可能结果，参与的障碍应该很少，如果有的话。具体来说，为了吸引具有不同经历和观点的人，必须不花钱参与。gydF4y2Ba
• 原则3:gydF4y2Ba为了实现最佳结果，项目输出应该在人们认为合适的时候使用。因此，标准本身必须获得重用许可，而不需要购买价格。gydF4y2Ba
• 原则4:gydF4y2Ba这个项目不应该偏袒任何一个公司或团体，但也不应该试图对所有人都适用。社区决定。gydF4y2Ba
• 原则5:gydF4y2Ba概念和想法必须经常被检验。测试和功能代码是评估提案的开始，而不是结束。gydF4y2Ba

随着时间的推移，CWL项目成员了解到这种方法是OpenStand原则的超集，OpenStand原则是由IAB、IEEE、IETF、互联网协会和W3C共同推动的“现代标准范式”。OpenStand原则中增加的CWL项目是1)免费参与，2)所有文本、一致性测试和参考实现都明确选择Apache License 2.0。gydF4y2Ba

必要和充分的。gydF4y2Ba所有这些原则已被证明对CWL项目至关重要。例如，原则2和原则3使CWL标准的许多实现成为可能，其中几个实现重用了CWL标准参考实现的不同部分(gydF4y2Ba参考跑步gydF4y2Ba)．根据原则1，社区优先的原则导致参与者创建了几个CWL标准之外的项目;最重要的贡献已经回到了项目中(原则4)。gydF4y2Ba

作为原则5的一部分，CWL项目的贡献者已经为CWL标准的每个版本开发了一套一致性测试。这些公开的测试对CWL项目的成功至关重要:它们帮助评估CWL标准的参考实现，它们为早期采用者提供具体的示例，它们使CWL标准的产品实现的开发人员和用户能够确认其准确性。gydF4y2Ba

CWL生态系统。gydF4y2Ba除了在过去六年中发布的经过批准的初始和更新的CWL标准外，CWL社区还开发了许多工具、软件库和连接规范，并共享了流行工具的CWL描述。例如，有针对Python和Java的软件开发工具包(sdk)，它们是根据CWL模式自动生成的。这允许程序员使用直接对应于标准本身的面向对象模型来加载、修改和保存CWL文档。其他语言的CWL sdk可以通过扩展代码生成例程来实现。gydF4y2Ba^ggydF4y2Ba(见gydF4y2Ba侧边栏gydF4y2Ba: CWL项目和免费/开源软件的实际细节。)gydF4y2Ba

CWL标准为重用(以及相应的共享)工作流执行、创作和来源方面的信息的迫切需求提供了强有力的支持。的gydF4y2BaCWLPROVgydF4y2Ba创建Prototype是为了展示现有标准gydF4y2Ba^{3.gydF4y2Ba，gydF4y2Ba22gydF4y2Ba，gydF4y2Ba26gydF4y2Ba}可以组合起来表示CWL工作流的特定执行的起源。gydF4y2Ba^20.gydF4y2Ba尽管到目前为止，CWLProv只在CWL参考运行器中实现，但人们对进一步开发和实现的兴趣很高。gydF4y2Ba

回到顶部gydF4y2Ba

结论gydF4y2Ba

标准化计算重用问题的重要性和影响只会越来越大。为了解决这个问题，科学、工程和商业中的各个领域已经开始迁移到工作流中，但是专注于可移植性甚至工作流定义的工作仍然分散。在这项工作中，我们提高了对这一问题的认识，并提出了由社区驱动的解决方案。gydF4y2Ba

CWL是用于描述命令行工具和由这些工具形成的工作流的一系列标准。它包括许多与社区协作开发的特性:支持软件容器、资源需求、工作流级别的条件分支，等等。CWL项目以五项指导原则为基础，提供开放标准、开放源代码和开放社区。gydF4y2Ba

---

根据设计，CWL标准对处理的文件大小或并行运行的任务数量没有任何技术限制。gydF4y2Ba

---

在过去的6年里，CWL社区得到了有机的发展。希望编写、使用或资助基于命令行工具的数据分析工作流的组织应该采用或甚至要求CWL标准，因为它们提供了一组通用的、但减少了的功能，这些功能在实践中使用，并在许多流行的工作流系统中实现。CWL还可以通过其他方式提供价值:它得到大规模社区的支持，各种领域已经采用了它，而且它的采用正在迅速增长。具体地说:gydF4y2Ba

1. 由于减少了功能集，CWL标准限制了新用户在首次启动时和操作人员在实施过程中遇到的复杂性。来自社区的反馈表明这些是值得赞赏的。gydF4y2Ba
2. CWL使用声明式语法允许用户指定工作流，即使他们不知道工作流(以后)将在哪里运行。gydF4y2Ba
3. CWL项目以公共利益为原则，并产生可免费获得的开放标准。CWL项目本身并不是一个特定的工作流管理系统、工作流运行器或供应商。这允许潜在用户、运营商和供应商避免锁定，并在未来变得更加灵活。gydF4y2Ba
4. 通过提供标准，CWL项目脱颖而出，尤其是在科学和工程合作中出现的复杂互动。这些交互包括从许多不同的工具(或步骤)定义工作流，共享工作流，长期归档，满足监管机构的要求(例如，美国FDA)，以及使工作流执行可审计和可重现。这在合作环境中特别有用，在这种环境中，竞争的团队也需要合作，或者在科学论文中，如果分析是在CWL工作流中描述的，并且所有步骤都使用公开的软件容器，那么结果可以非常有效地重用。gydF4y2Ba
5. CWL标准已经实现、采用和使用，许多产品级的实现都是开源的，成本为零。因此，CWL标准的不同用户群体已经提供了大量的工作流程和工具描述。这类似于Python的共享库、代码和菜谱生态系统已经很有帮助了。gydF4y2Ba

这是在呼吁其他人拥抱工作流思维，加入CWL社区，创建和共享可移植的完整工作流描述。在CWL标准中，这些方法被包含在其中，并且可以随时(重用)使用。gydF4y2Ba

回到顶部gydF4y2Ba

致谢gydF4y2Ba

我们愿意承认的参与CWL项目的人员名单是广泛的。在线补充材料中有一个全面的列表:gydF4y2Bahttps://bit.ly/3MoOPfQgydF4y2Ba．gydF4y2Ba资金确认:gydF4y2Ba欧洲委员会批准BioExcel-2 (SSR) h2020 - in - frai -02-2018 823830, BioExcel (SSR) h2020 - einfracontrol -2015-1 675728, eosca - life (SSR) h2020 - in - fradev -2018-2 824087, EOSCPilot (MRC) H2020-IN-FRADEV-2016-2 739563, IBISBA 1.0 (SSR) h2020 - infria - 2017-1-2 -stage 730976, ELIXIR-EXCELERATE (SSR) h2020 - infrdev -1-2015-1 676559, ASTERICS (MRC) infrdev -4-2014-2015。ELIXIR生命科学数据研究基础设施，互操作性平台实施研究(MRC)。2018 - cwl。许多大学也共同赞助了这个项目。我们感谢荷兰阿姆斯特丹自由大学，在那里前三位作者有他们的主要从属关系。gydF4y2Ba

回到顶部gydF4y2Ba

回到顶部gydF4y2Ba

回到顶部gydF4y2Ba

回到顶部gydF4y2Ba

a. IPython Parallel (ipyparallel)是一个Python包和用于控制IPython进程集群的CLI脚本集合，构建在Jupyter协议上。看到gydF4y2Bahttps://pypi.org/project/ipyparallel/gydF4y2Ba．gydF4y2Ba

b. ctypes是Python的外部函数库。看到gydF4y2Bahttps://docs.python.org/3/library/ctypes.htmlgydF4y2Ba．gydF4y2Ba

回到顶部gydF4y2Ba

一。总结gydF4y2Bahttps://www.commonwl.org/tools/gydF4y2Ba．gydF4y2Ba

b。gydF4y2Bahttps://microsoft.github.io/language-server-protocol/gydF4y2Ba．gydF4y2Ba

c。由EMBOSS工具生成的“Ajax命令定义”:gydF4y2Bahttp://emboss.source-forge.net/developers/acd/gydF4y2Ba．gydF4y2Ba

d.基于xml的“常用工具描述符”gydF4y2Ba^9gydF4y2Ba源自OpenMS项目的:gydF4y2Bahttps://github.com/WorkflowConversion/CTDSchemagydF4y2Ba．gydF4y2Ba

数字图书馆是由计算机协会出版的。版权所有©2022 ACM股份有限公司gydF4y2Ba

---

没有发现记录gydF4y2Ba