diff --git a/.ci/validation/package.json b/.ci/validation/package.json index 64f29145..4357ce5e 100644 --- a/.ci/validation/package.json +++ b/.ci/validation/package.json @@ -13,7 +13,7 @@ "workflow", "specification" ], - "author": "CNCF Serverless Workflow Specification", + "author": "Open Workflow Specification", "license": "ISC", "devDependencies": { "@types/jest": "^29.5.12", diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 53acfa15..6423ec06 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,12 +1,12 @@ -# Serverless Workflow Project Governance +# Open Workflow Specification Project Governance As a CNCF member project, we abide by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). -For specific guidance on practical contribution steps for any Serverless Workflow sub-project please +For specific guidance on practical contribution steps for any Open Workflow Specification sub-project please see our [contributing guide](contributing.md). You can contact the project maintainers at any time by sending an email to the -[Serverless Workflow Specification Maintainers](mailto:cncf-serverlessws-maintainers@lists.cncf.io) +[Open Workflow Specification Maintainers](mailto:cncf-serverlessws-maintainers@lists.cncf.io) mailing list. ## Maintainership @@ -48,7 +48,7 @@ To transition a maintainer to an emeritus role, the process follows the same vot ## Subprojects -Serverless Workflow subprojects all culminate in officially supported and +Open Workflow Specification subprojects all culminate in officially supported and maintained releases of the specification. All subprojects must adhere to [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) @@ -56,14 +56,14 @@ as well as this governance document. ### Adding core subprojects -New subprojects can request to be added to the Serverless Workflow GitHub +New subprojects can request to be added to the Open Workflow Specification GitHub organization by submitting a GitHub issue in the specification repository. The existing maintainers are given fourteen business days to discuss the new project, raise objections and cast their vote. Projects must be approved by at least 66% of the current maintainers. -If a project is approved, a maintainer will add the project to the Serverless Workflow +If a project is approved, a maintainer will add the project to the Open Workflow Specification GitHub organization, and make an announcement on a public Slack channel. ## Stepping down policy @@ -98,7 +98,7 @@ by a pull request removing them. ## How are decisions made? -Serverless Workflow is an open-source project with an open design philosophy. This means +Open Workflow Specification is an open-source project with an open design philosophy. This means that the repository is the source of truth for EVERY aspect of the project, including its philosophy, design, road map, and APIs. *If it's part of the project, it's in the repository. If it's in the repository, it's part of the project.* @@ -113,7 +113,7 @@ Upon agreement, a pull request should be opened. We encourage not opening pull requests without a discussion first either in a new [issue](issues) or using the [discussion](discussions) tool. -All decisions affecting Serverless Workflow, big and small, follow the same 3 steps: +All decisions affecting Open Workflow Specification, big and small, follow the same 3 steps: * Step 1: Open a pull request. Anyone can do this. diff --git a/MAINTAINERS.md b/MAINTAINERS.md index e3d2a5e1..9d033392 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -1,9 +1,9 @@ -# Serverless Workflow Org Maintainers +# Open Workflow Specification Org Maintainers * [Charles d'Avernas](https://github.com/cdavernas) * [Ricardo Zanini](https://github.com/ricardozanini) -# Serverless Workflow Org Emeritus Maintainers +# Open Workflow Specification Org Emeritus Maintainers * [Antonio Mendoza Pérez](https://github.com/antmendoza) # Maintainers Mailing list diff --git a/README.md b/README.md index 86f63a1d..ac2d02ff 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,7 @@ [GitHub Release](https://github.com/serverlessworkflow/specification/releases/latest)
[](https://serverlessworkflow.io/) -[](https://cloud-native.slack.com/messages/serverless-workflow) +[](https://cloud-native.slack.com/messages/open-workflow) [](https://www.linkedin.com/company/serverless-workflow/) [](https://twitter.com/CNCFWorkflow) @@ -29,17 +29,17 @@ ## About -Serverless Workflow presents a vendor-neutral, open-source, and entirely community-driven ecosystem tailored for defining and executing DSL-based workflows in the realm of Serverless technology. +Open Workflow Specification presents a vendor-neutral, open-source, and entirely community-driven ecosystem for defining and executing DSL-based workflows. -The Serverless Workflow DSL is a high-level language that reshapes the terrain of workflow creation, boasting a design that is ubiquitous, intuitive, imperative, and fluent. +The Open Workflow DSL is a high-level language that reshapes the terrain of workflow creation, boasting a design that is ubiquitous, intuitive, imperative, and fluent. Bid farewell to convoluted coding and platform dependencies—now, crafting powerful workflows is effortlessly within reach for everyone! Key features: -- **Easy to Use**: Designed for universal understanding, Serverless Workflow DSL enables users to quickly grasp workflow concepts and create complex workflows effortlessly. +- **Easy to Use**: Designed for universal understanding, Open Workflow DSL enables users to quickly grasp workflow concepts and create complex workflows effortlessly. - **Event Driven**: Seamlessly integrate events into workflows with support for various formats, including CloudEvents, allowing for event-driven workflow architectures. -- **Service Oriented**: The Serverless Workflow DSL empowers developers to seamlessly integrate with service-oriented architectures, allowing them to define workflows that interact with various services over standard application protocols like HTTP, GRPC, OpenAPI, AxsyncAPI, and more. +- **Service Oriented**: The Open Workflow DSL empowers developers to seamlessly integrate with service-oriented architectures, allowing them to define workflows that interact with various services over standard application protocols like HTTP, GRPC, OpenAPI, AsyncAPI, and more. - **FaaS Centric**: Seamlessly invoke functions hosted on various platforms within workflows, promoting a function-as-a-service (FaaS) paradigm and enabling microservices architectures. - **Timely**: Define timeouts for workflows and tasks to manage execution duration effectively. - **Fault Tolerant**: Easily define error handling strategies to manage and recover from errors that may occur during workflow execution, ensuring robustness and reliability. @@ -50,26 +50,26 @@ Key features: ## Ecosystem -Serverless Workflow ecosystem is hosted by the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/) and was approved as a +Open Workflow Specification ecosystem is hosted by the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/) and was approved as a Cloud Native Sandbox level project on July 14, 2020. -It encompasses a comprehensive suite of components and tools designed to facilitate the creation, management, and execution of serverless workflows. +It encompasses a comprehensive suite of components and tools designed to facilitate the creation, management, and execution of workflows. -1. **[DSL](dsl.md) (Domain Specific Language)**: The core of the ecosystem, defining the fundamental syntax and semantics of Serverless Workflow specifications. +1. **[DSL](dsl.md) (Domain Specific Language)**: The core of the ecosystem, defining the fundamental syntax and semantics of the Open Workflow Specification. 2. **[CTK](/ctk/README.md) (Conformance Test Kit)**: A set of Gherkin features utilized for both conformance testing and Behavior Driven Design (BDD), ensuring compliance and facilitating testing across implementations. -3. **[SDKs](#sdks) (Software Development Kits)**: These enable developers to interact with serverless workflows in various programming languages, providing functionalities such as reading, writing, building, and validating workflows. +3. **[SDKs](#sdks) (Software Development Kits)**: These enable developers to interact with workflows in various programming languages, providing functionalities such as reading, writing, building, and validating workflows. -4. **[Runtimes](#runtimes)**: Dedicated environments for executing workflows defined using the Serverless Workflow DSL, ensuring seamless deployment and operation within diverse runtime environments. +4. **[Runtimes](#runtimes)**: Dedicated environments for executing workflows defined using the Open Workflow DSL, ensuring seamless deployment and operation within diverse runtime environments. -5. **[Tooling](#tooling)**: Additional utilities and resources tailored to enhance the development, debugging, and management of serverless workflows, streamlining the workflow lifecycle from creation to deployment and maintenance. +5. **[Tooling](#tooling)**: Additional utilities and resources tailored to enhance the development, debugging, and management of workflows, streamlining the workflow lifecycle from creation to deployment and maintenance. ### SDKs -The Serverless Workflow SDKs are essential tools designed to assist developers in consuming, parsing, validating, and testing their workflows utilizing the Serverless Workflow DSL. +The Open Workflow Specification SDKs are essential tools designed to assist developers in consuming, parsing, validating, and testing their workflows utilizing the Open Workflow DSL. -These SDKs empower developers to seamlessly integrate serverless workflows into their applications, providing robust support for various programming languages. By offering comprehensive functionality, they streamline the development process and enhance workflow management. +These SDKs empower developers to seamlessly integrate workflows into their applications, providing robust support for various programming languages. By offering comprehensive functionality, they streamline the development process and enhance workflow management. Explore our SDKs for different programming languages: @@ -92,17 +92,17 @@ No matter your preferred language, our SDKs provide the tools you need to levera | [Apache KIE SonataFlow](https://sonataflow.org) | Apache KIE SonataFlow is a tool for building cloud-native workflow applications. You can use it to do the services and events orchestration and choreography. | | [Java SDK reference implementation](https://github.com/serverlessworkflow/sdk-java/tree/main/impl) | Full compliant Java implementation of the specification | | [Lemline](https://github.com/lemline/lemline) | Lemline is a highly scalable runtime running on top of your existing messaging infrastructure. | -| [Synapse](https://github.com/serverlessworkflow/synapse) | Synapse is a scalable, cross-platform, fully customizable platform for managing and running Serverless Workflows. | +| [Synapse](https://github.com/serverlessworkflow/synapse) | Synapse is a scalable, cross-platform, fully customizable platform for managing and running workflows defined with Open Workflow Specification. | ### Tooling -In order to enhance developer experience with the Serverless Workflow DSL, we provide a [Visual Studio Code extension](https://marketplace.visualstudio.com/items?itemName=serverlessworkflow.serverless-workflow-vscode-extension). +In order to enhance developer experience with the Open Workflow DSL, we provide a [Visual Studio Code extension](https://marketplace.visualstudio.com/items?itemName=serverlessworkflow.serverless-workflow-vscode-extension). The sources of the extension can be found [here](https://github.com/serverlessworkflow/vscode-extension). ### CNCF Landscape -Serverless Workflow project falls under the [CNCF "App Definition and Development"](https://landscape.cncf.io/card-mode?category=app-definition-and-development&grouping=category) category. +Open Workflow Specification project falls under the [CNCF "App Definition and Development"](https://landscape.cncf.io/card-mode?category=app-definition-and-development&grouping=category) category. It is a member project of the [CNCF Serverless Working Group](https://github.com/cncf/wg-serverless). @@ -112,13 +112,13 @@ It is a member project of the [CNCF Serverless Working Group](https://github.com ## Documentation -The documentation for Serverless Workflow includes: +The documentation for Open Workflow Specification includes: -- [**DSL**](dsl.md): Documents the fundamentals aspects and concepts of the Serverless Workflow DSL. -- [**DSL Reference**](dsl-reference.md): References all the definitions used by the Serverless Workflow DSL. -- [**Comparison**](comparison.md): See how Serverless Workflow compares to other DSLs. -- [**Examples**](./examples/README.md): A collection of practical examples demonstrating specific features and functionalities of Serverless Workflow. -- [**Use Cases**](./use-cases/README.md): Detailed use cases illustrating how Serverless Workflow can be applied in various real-world scenarios. +- [**DSL**](dsl.md): Documents the fundamentals aspects and concepts of the Open Workflow DSL. +- [**DSL Reference**](dsl-reference.md): References all the definitions used by the Open Workflow DSL. +- [**Comparison**](comparison.md): See how Open Workflow Specification compares to other DSLs. +- [**Examples**](./examples/README.md): A collection of practical examples demonstrating specific features and functionalities of Open Workflow Specification. +- [**Use Cases**](./use-cases/README.md): Detailed use cases illustrating how Open Workflow Specification can be applied in various real-world scenarios. ## Community @@ -134,7 +134,7 @@ reference the [Ownership of Copyrights in CNCF Project Contributions](https://gi ### Communication -- Community Slack Channel: [https://slack.cncf.io/](https://slack.cncf.io/) - #serverless-workflow +- Community Slack Channel: [https://slack.cncf.io/](https://slack.cncf.io/) - #open-workflow - [Weekly project meetings](#weekly-meetings) - Project Maintainers Email: [cncf-serverlessws-maintainers](mailto:cncf-serverlessws-maintainers@lists.cncf.io) - Serverless WG Email: [cncf-wg-serverless](mailto:cncf-wg-serverless@lists.cncf.io) @@ -142,7 +142,7 @@ reference the [Ownership of Copyrights in CNCF Project Contributions](https://gi ### Governance -The Serverless Workflow Project Governance [document](governance.md) delineates the roles, procedures, and principles guiding the collaborative development and maintenance of the project. +The Open Workflow Specification Project Governance [document](GOVERNANCE.md) delineates the roles, procedures, and principles guiding the collaborative development and maintenance of the project. It emphasizes adherence to the CNCF Code of Conduct, defines the responsibilities of maintainers, reviewers, and emeritus maintainers, outlines procedures for their addition and removal, and establishes guidelines for subprojects' inclusion and compliance. @@ -150,7 +150,7 @@ Decision-making processes are consensus-driven, facilitated through structured p Overall, the document reflects the project's commitment to transparency, accountability, and inclusive collaboration, fostering an environment conducive to sustained growth and innovation. -See the project's Governance Model [here](governance.md). +See the project's Governance Model [here](GOVERNANCE.md). ### Code of Conduct @@ -168,9 +168,9 @@ See the project's Code of Conduct [here](code-of-conduct.md). ### Weekly Meetings -The Serverless Workflow team meets weekly, every Thursday at 9AM ET (USA Eastern Time). +The Open Workflow Specification team meets weekly, every Thursday at 9AM ET (USA Eastern Time). -To register for meetings please visit the [CNCF Community Calendar](https://tockify.com/cncf.public.events/monthly?search=serverless%20workflow). +To register for meetings please visit the [CNCF Community Calendar](https://tockify.com/cncf.public.events/monthly?search=open%20workflow). You can register for individual meetings or for the entire series. @@ -178,11 +178,11 @@ You can register for individual meetings or for the entire series. ### Adoption -If you're using Serverless Workflow in your projects and would like to showcase your adoption, become an Adopter! By joining our community of adopters, you'll have the opportunity to share your experiences, contribute feedback, and collaborate with like-minded individuals and organizations leveraging Serverless Workflow to power their workflows. +If you're using Open Workflow Specification in your projects and would like to showcase your adoption, become an Adopter! By joining our community of adopters, you'll have the opportunity to share your experiences, contribute feedback, and collaborate with like-minded individuals and organizations leveraging Open Workflow Specification to power their workflows. ### Sponsoring -As an open-source project, Serverless Workflow relies on the support of sponsors to sustain its development and growth. +As an open-source project, Open Workflow Specification relies on the support of sponsors to sustain its development and growth. By becoming a sponsor, you'll not only demonstrate your commitment to advancing serverless technologies but also gain visibility within our vibrant community. diff --git a/SECURITY.md b/SECURITY.md index 1c341b87..c868f44d 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -2,24 +2,24 @@ ## Reporting a Vulnerability -The Serverless Workflow team and community take security bugs very seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions. +The Open Workflow Specification team and community take security bugs very seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions. To report a security issue, please use the GitHub Security Advisory ["Report a Vulnerability"](https://github.com/serverlessworkflow/specification/security/advisories/new) tab. -The Serverless Workflow team will send a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. +The Open Workflow Specification team will send a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. ## Security Best Practices To help ensure the security of your workflows, we recommend the following best practices: -- **Keep Up to Date**: Always use the latest version of the Serverless Workflow DSL. +- **Keep Up to Date**: Always use the latest version of the Open Workflow DSL. - **Review Code**: Regularly review your workflows and code for potential security issues. - **Access Control**: Implement proper access controls to restrict who can create, modify, or execute workflows. - **Monitor and Audit**: Continuously monitor and audit workflows to detect and respond to any suspicious activities. - **Secure External Resources**: Ensure that any resources external to a workflow definition are always secured using modern authentication policies as defined in the DSL. -- **Use Trusted Containers and Scripts**: When relying on [run tasks](https://github.com/serverlessworkflow/specification/blob/main/dsl-reference.md#run), only use trusted container images, scripts, commands and workflows. -- **Custom Functions**: Only use custom functions from the [Serverless Workflow Catalog](https://github.com/serverlessworkflow/catalog) or from trusted sources to avoid introducing vulnerabilities. +- **Use Trusted Containers and Scripts**: When relying on [run tasks](dsl-reference.md#run), only use trusted container images, scripts, commands and workflows. +- **Custom Functions**: Only use custom functions from the [Open Workflow Catalog](https://github.com/serverlessworkflow/catalog) or from trusted sources to avoid introducing vulnerabilities. --- -Thank you for helping to keep the Serverless Workflow DSL secure! +Thank you for helping to keep the Open Workflow Specification secure! diff --git a/adr/v1.0-adr-migration-tool.md b/adr/v1.0-adr-migration-tool.md index ca3878a9..21d2545f 100644 --- a/adr/v1.0-adr-migration-tool.md +++ b/adr/v1.0-adr-migration-tool.md @@ -1,4 +1,4 @@ -# ADR: Serverless Workflow Migration Tool for 0.8/0.9 to 1.0.0 +# ADR: Open Workflow Migration Tool for 0.8/0.9 to 1.0.0 ## Status @@ -10,7 +10,7 @@ Proposed ## Context -The Serverless Workflow specification has undergone a significant architectural redesign between versions 0.8/0.9 and 1.0.0. The 0.8/0.9 versions used a **state-based model** with explicit state machines and transitions, while version 1.0.0 introduces a fundamentally different **task-based model** with implicit flow control and declarative task composition. +The Open Workflow specification has undergone a significant architectural redesign between versions 0.8/0.9 and 1.0.0. The 0.8/0.9 versions used a **state-based model** with explicit state machines and transitions, while version 1.0.0 introduces a fundamentally different **task-based model** with implicit flow control and declarative task composition. This architectural change creates a migration challenge for users who have existing workflows defined in 0.8 or 0.9 format and want to adopt the new 1.0.0 specification. Manual migration is: @@ -34,7 +34,7 @@ Currently, there is no official migration path or tooling to help users transiti ## Decision -We propose the development of an official **Serverless Workflow Migration Tool** written in Go to automate the migration of 0.8 and 0.9 workflow definitions to version 1.0.0. +We propose the development of an official **Open Workflow Migration Tool** written in Go to automate the migration of 0.8 and 0.9 workflow definitions to version 1.0.0. ### Tool Characteristics @@ -350,7 +350,7 @@ swf-migrate workflow.json --strict ## Licensing -- Apache 2.0 (consistent with Serverless Workflow specification) +- Apache 2.0 (consistent with Open Workflow specification) - All dependencies must be CNCF-compatible ## Governance @@ -362,7 +362,7 @@ swf-migrate workflow.json --strict ### Maintainers -- Initial maintainers from Serverless Workflow specification maintainers +- Initial maintainers from Open Workflow specification maintainers - Open to community contributions following spec governance model ### Release Strategy @@ -408,8 +408,8 @@ swf-migrate workflow.json --strict ## References -- [Serverless Workflow 0.8 Specification](https://github.com/serverlessworkflow/specification/tree/0.8.x) -- [Serverless Workflow 0.9 Specification](https://github.com/serverlessworkflow/specification/tree/0.9.x) -- [Serverless Workflow 1.0.0 Specification](https://github.com/serverlessworkflow/specification) +- [Open Workflow 0.8 Specification](https://github.com/serverlessworkflow/specification/tree/0.8.x) +- [Open Workflow 0.9 Specification](https://github.com/serverlessworkflow/specification/tree/0.9.x) +- [Open Workflow 1.0.0 Specification](https://github.com/serverlessworkflow/specification) - [JsonPath Specification](https://goessner.net/articles/JsonPath/) - [jq Manual](https://jqlang.github.io/jq/manual/) diff --git a/adr/v1.0-adr-shared-workflow-editor.md b/adr/v1.0-adr-shared-workflow-editor.md index 2a32f985..26e22156 100644 --- a/adr/v1.0-adr-shared-workflow-editor.md +++ b/adr/v1.0-adr-shared-workflow-editor.md @@ -1,4 +1,4 @@ -# ADR: Shared CNCF Workflow Specification Editor & Multi-Maintainer Collaboration Model +# ADR: Shared Open Workflow Specification Editor & Multi-Maintainer Collaboration Model ## Status @@ -6,22 +6,22 @@ Proposed ## Context -There is a need for a shared editor for the CNCF Serverless Workflow Specification that +There is a need for a shared editor for the Open Workflow Specification that can be used consistently by multiple implementations (e.g. Quarkus Flow, SonataFlow, Zigflow, Synapse, Lemline), as different tools provide inconsistent authoring and visualization experiences, leading to duplicated effort and fragmented tooling. Today we have: -- An existing (but aging) VS Code extension for Serverless Workflow +- An existing (but aging) VS Code extension for Open Workflow - Several product-specific editors embedded in consoles or IDEs - Fragmented UX and duplicated effort around: - YAML/JSON authoring - Visual diagramming - Validation against the spec schema -We want to converge on a single core editor stack driven by the CNCF -Serverless Workflow Specification, with a collaboration model that allows +We want to converge on a single core editor stack driven by the +Open Workflow Specification, with a collaboration model that allows multiple vendors/maintainers to contribute and embed it. This ADR formalizes the decision to build a shared editor, with a strictly @@ -51,12 +51,12 @@ vendor. ### Proposed model - Repository ownership - - New repo under the CNCF Serverless Workflow Specification org, e.g. `workflow-spec-editor` (name TBD). + - New repo under the Open Workflow Specification org, e.g. `workflow-spec-editor` (name TBD). - Maintainers - Initial maintainers: representatives from at least: - - CNCF Serverless Workflow Specification maintainers + - Open Workflow Specification maintainers - Quarkus Flow / SonataFlow - Other interested engine maintainers (e.g. Zigflow / Synapse / Lemline etc.). @@ -107,7 +107,7 @@ vendor. ### 3. Diagram Semantics & Representation -- Support all task types defined by the Serverless Workflow specification. +- Support all task types defined by the Open Workflow Specification. - Twelve task types represented visually. - Task types differentiated using icons, custom node shapes are avoided for MVP due to layout complexity. @@ -143,7 +143,7 @@ vendor. ### Positive - CNCF-aligned ownership -- Lowers the entry barrier to the CNCF Serverless Workflow Specification +- Lowers the entry barrier to the Open Workflow Specification - Encourages understanding and usage of workflow semantics - Reduces duplicated tooling effort across runtimes - Provides a shared, consistent user experience diff --git a/community/contributors.md b/community/contributors.md index 18a3e6d0..a799cdb0 100644 --- a/community/contributors.md +++ b/community/contributors.md @@ -1,6 +1,6 @@ # Community Contributors -This list acknowledges community contributors to the Serverless Workflow +This list acknowledges community contributors to the Open Workflow Specification project. We welcome everyone to join our community and contribute. diff --git a/comparison.md b/comparison.md index d438cf89..d043a158 100644 --- a/comparison.md +++ b/comparison.md @@ -1,6 +1,6 @@ # Workflow Comparison -This document provides a detailed comparison of various workflow orchestration platforms, including **Serverless Workflow**, **AWS Step Functions**, **Google Workflows**, **Argo Workflows**, **BPMN Workflows**, **Prefect**, and **Dagster**. The comparison highlights the key features, pricing models, and the data manipulation capabilities of each platform. This guide aims to help you understand the core strengths and limitations of each platform and assist you in selecting the best workflow engine based on your use case. +This document provides a detailed comparison of various workflow orchestration platforms, including **Open Workflow Specification**, **AWS Step Functions**, **Google Workflows**, **Argo Workflows**, **BPMN Workflows**, **Prefect**, and **Dagster**. The comparison highlights the key features, pricing models, and the data manipulation capabilities of each platform. This guide aims to help you understand the core strengths and limitations of each platform and assist you in selecting the best workflow engine based on your use case. This comparison is intended for general informational purposes only. While every effort has been made to ensure accuracy, each workflow technology has its own unique features and capabilities. The descriptions provided are based on **out-of-the-box features** as of the latest available documentation. Some features may require additional configuration, extensions, or integrations. Users should verify specific features with the official documentation of each platform to ensure compatibility with their use cases. @@ -10,7 +10,7 @@ This comparison is intended for general informational purposes only. While every In this section, we provide a high-level summary of each platform's key attributes, including core focus, definition language, ownership model, and pricing structure. This overview helps you understand the fundamental differences and similarities between the platforms, allowing you to evaluate which one best fits your needs and organizational requirements. -| Trait | Serverless Workflow | AWS Step Functions | Google Workflows | Argo Workflows | BPMN Workflows | Prefect | Dagster | +| Trait | **Open Workflow Specification** | AWS Step Functions | Google Workflows | Argo Workflows | BPMN Workflows | Prefect | Dagster | |----------------------------------|:-------------------:|:------------------:|:----------------:|:--------------:|:--------------:|:-------:|:-------:| | **Core Focus** | Event-driven & cloud-agnostic workflow orchestration | AWS service orchestration | Google Cloud service orchestration | Kubernetes-native workflow automation | Business process automation | Data pipeline orchestration | Data pipeline orchestration | | **Definition Language** | JSON/YAML | JSON | YAML | YAML | BPMN XML | Python | Python | @@ -31,7 +31,7 @@ In this section, we provide a high-level summary of each platform's key attribut This section compares the core features of each platform, including data handling, execution control, event processing, and integration capabilities. We evaluate how each platform supports critical workflow orchestration functionalities, helping you assess their suitability for various use cases. -| Feature | Serverless Workflow | AWS Step Functions | Google Workflows | Argo Workflows | BPMN Workflows | Prefect | Dagster | +| Feature | **Open Workflow Specification** | AWS Step Functions | Google Workflows | Argo Workflows | BPMN Workflows | Prefect | Dagster | |------------------------------|:-------------------:|:------------------:|:----------------:|:--------------:|:--------------:|:-------:|:-------:| | **Retries** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | **Timeouts** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | @@ -65,19 +65,19 @@ This section compares the core features of each platform, including data handlin ## Key Takeaways -- **Event-Driven & Cloud-Agnostic**: **Serverless Workflow** shines with its **cloud-agnostic** design, enabling seamless orchestration across multiple cloud providers and on-prem environments. Whether you're running workflows in AWS, GCP, or any other cloud, it adapts to your infrastructure. +- **Event-Driven & Cloud-Agnostic**: **Open Workflow Specification** shines with its **cloud-agnostic** design, enabling seamless orchestration across multiple cloud providers and on-prem environments. Whether you're running workflows in AWS, GCP, or any other cloud, it adapts to your infrastructure. -- **Advanced Event Handling**: **Serverless Workflow** excels in **event-driven orchestration**, supporting **event streaming**, **complex event processing**, and **event correlation**, out of the box. This makes it an ideal choice for dynamic, event-driven architectures, offering real-time data processing capabilities that many other platforms lack. +- **Advanced Event Handling**: **Open Workflow Specification** excels in **event-driven orchestration**, supporting **event streaming**, **complex event processing**, and **event correlation**, out of the box. This makes it an ideal choice for dynamic, event-driven architectures, offering real-time data processing capabilities that many other platforms lack. -- **Flexible Data Manipulation**: With full support for **runtime expressions**, **Serverless Workflow** enables advanced data filtering, mutation, and evaluation using expression languages like **JavaScript** and **jq**, giving you the power to manipulate and transform data directly within workflows. +- **Flexible Data Manipulation**: With full support for **runtime expressions**, **Open Workflow Specification** enables advanced data filtering, mutation, and evaluation using expression languages like **JavaScript** and **jq**, giving you the power to manipulate and transform data directly within workflows. -- **Scalability & Extensibility**: Built for scalability, **Serverless Workflow** integrates effortlessly into microservice architectures and supports custom execution units and extensions. You can define and extend workflows as per your needs, enabling customized workflows that grow with your business. +- **Scalability & Extensibility**: Built for scalability, **Open Workflow Specification** integrates effortlessly into microservice architectures and supports custom execution units and extensions. You can define and extend workflows as per your needs, enabling customized workflows that grow with your business. -- **No Vendor Lock-In**: Unlike proprietary services, **Serverless Workflow** is open-source and cloud-agnostic, ensuring **no vendor lock-in**. You have full control over deployment and execution, allowing you to avoid reliance on a single cloud provider. +- **No Vendor Lock-In**: Unlike proprietary services, **Open Workflow Specification** is open-source and cloud-agnostic, ensuring **no vendor lock-in**. You have full control over deployment and execution, allowing you to avoid reliance on a single cloud provider. -- **Robust Monitoring & Reporting**: With built-in **lifecycle reporting**, **Serverless Workflow** provides comprehensive insights into your workflow execution. Real-time monitoring, task-level metadata, and detailed logs help you maintain visibility and ensure smooth operations. +- **Robust Monitoring & Reporting**: With built-in **lifecycle reporting**, **Open Workflow Specification** provides comprehensive insights into your workflow execution. Real-time monitoring, task-level metadata, and detailed logs help you maintain visibility and ensure smooth operations. -**Serverless Workflow** stands out as the ideal solution for businesses seeking flexibility, scalability, and advanced event-driven processing without the constraints of proprietary platforms. Whether you are orchestrating complex workflows, integrating cloud services, or managing large-scale data transformations, **Serverless Workflow** is built to scale with your needs and help you stay ahead. +**Open Workflow Specification** stands out as the ideal solution for businesses seeking flexibility, scalability, and advanced event-driven processing without the constraints of proprietary platforms. Whether you are orchestrating complex workflows, integrating cloud services, or managing large-scale data transformations, **Open Workflow Specification** is built to scale with your needs and help you stay ahead. --- diff --git a/contributing.md b/contributing.md index 55347397..bea2ed1b 100644 --- a/contributing.md +++ b/contributing.md @@ -1,4 +1,4 @@ -# Contributing to Serverless Workflow +# Contributing to Open Workflow Specification This page contains information about reporting issues, how to suggest changes as well as the guidelines we follow for how our documents are formatted. @@ -57,7 +57,7 @@ first comment in the issue to include `Assigned to: @person` ## Versioning -The versioning strategy for the Serverless Workflow DSL is structured to accommodate different types of changes introduced through pull requests (PRs). +The versioning strategy for the Open Workflow DSL is structured to accommodate different types of changes introduced through pull requests (PRs). If a PR is labeled with `change: documentation`, indicating modifications related to improving or clarifying documentation, it does not trigger a version change. diff --git a/ctk/README.md b/ctk/README.md index a1db9817..5a640f3c 100644 --- a/ctk/README.md +++ b/ctk/README.md @@ -1,4 +1,4 @@ -# Serverless Workflow CTK +# Open Workflow CTK ## Table of Contents @@ -31,19 +31,19 @@ ## Introduction -The Serverless Workflow Conformance Test Kit (CTK) is a suite of automated tests designed to ensure that implementations of the Serverless Workflow specification conform to the standard. The CTK is composed of multiple Gherkin features, each representing various aspects of the Serverless Workflow DSL. +The Open Workflow Conformance Test Kit (CTK) is a suite of automated tests designed to ensure that implementations of the Open Workflow Specification conform to the standard. The CTK is composed of multiple Gherkin features, each representing various aspects of the Open Workflow DSL. Gherkin is a human-readable language used for writing structured tests, which can be understood by both non-technical stakeholders and automated test frameworks. It uses a Given-When-Then syntax to describe the preconditions, actions, and expected outcomes of a test scenario. ## Using the CTK -The Serverless Workflow CTK serves two primary purposes: conformance testing and Behavior-Driven Development (BDD). +The Open Workflow CTK serves two primary purposes: conformance testing and Behavior-Driven Development (BDD). ### Conformance Testing -Conformance testing is the process of verifying that an implementation adheres to a given specification. By running the CTK, developers can ensure that their implementations of the Serverless Workflow DSL behave as expected and meet the defined standards. This is crucial for maintaining interoperability and consistency across different implementations of the Serverless Workflow specification. +Conformance testing is the process of verifying that an implementation adheres to a given specification. By running the CTK, developers can ensure that their implementations of the Open Workflow DSL behave as expected and meet the defined standards. This is crucial for maintaining interoperability and consistency across different implementations of the Open Workflow Specification. -1. **Clone the Repository**: Start by cloning the Serverless Workflow CTK repository to your local machine. +1. **Clone the Repository**: Start by cloning the Open Workflow CTK repository to your local machine. ```sh git clone https://github.com/serverlessworkflow/specification.git @@ -53,7 +53,7 @@ git clone https://github.com/serverlessworkflow/specification.git 3. **Run the Tests**: Execute the Gherkin features using your preferred test runner. -4. **Review Results**: After running the tests, review the results to ensure that your implementation passes all the scenarios. Any failures indicate deviations from the Serverless Workflow specification. +4. **Review Results**: After running the tests, review the results to ensure that your implementation passes all the scenarios. Any failures indicate deviations from the Open Workflow Specification. ### Behavior-Driven Development (BDD) @@ -61,7 +61,7 @@ Behavior-Driven Development (BDD) is an agile software development process that By using the CTK for BDD, teams can: -**Define Behavior**: Write Gherkin scenarios that describe the expected behavior of the Serverless Workflow DSL. This helps in clearly specifying requirements and expected outcomes. +**Define Behavior**: Write Gherkin scenarios that describe the expected behavior of the Open Workflow DSL. This helps in clearly specifying requirements and expected outcomes. **Facilitate Collaboration**: Use the Gherkin scenarios to facilitate discussions and collaboration between technical and non-technical team members. This ensures that everyone has a shared understanding of the system's behavior. @@ -77,7 +77,7 @@ To use the CTK for BDD: ## Writing Features and Scenarios -To contribute new features or scenarios to the Serverless Workflow CTK, follow these guidelines: +To contribute new features or scenarios to the Open Workflow CTK, follow these guidelines: ### Feature File Structure @@ -98,7 +98,7 @@ Feature: ### Steps -For clarity, we've categorized the Gherkin steps used in the Serverless Workflow CTK into three main groups: Arrange, Act, and Assert. +For clarity, we've categorized the Gherkin steps used in the Open Workflow CTK into three main groups: Arrange, Act, and Assert. These divisions help clarify the purpose of each step and streamline scenario comprehension. diff --git a/dsl-reference.md b/dsl-reference.md index 2a63abe7..b18abcab 100644 --- a/dsl-reference.md +++ b/dsl-reference.md @@ -1,4 +1,4 @@ -# Serverless Workflow DSL - Reference +# Open Workflow DSL - Reference ## Table of Contents @@ -88,7 +88,7 @@ ## Abstract -This document provides comprehensive definitions and detailed property tables for all the concepts discussed in the Serverless Workflow DSL. It serves as a reference guide, explaining the structure, components, and configurations available within the DSL. By exploring this document, users will gain a thorough understanding of how to define, configure, and manage workflows, including task definitions, flow directives, and state transitions. This foundational knowledge will enable users to effectively utilize the DSL for orchestrating serverless functions and automating processes. +This document provides comprehensive definitions and detailed property tables for all the concepts discussed in the Open Workflow DSL. It serves as a reference guide, explaining the structure, components, and configurations available within the DSL. By exploring this document, users will gain a thorough understanding of how to define, configure, and manage workflows, including task definitions, flow directives, and state transitions. This foundational knowledge will enable users to effectively utilize the DSL for orchestrating functions and automating processes. ## Definitions @@ -262,7 +262,7 @@ It encapsulates a specific action or set of actions that need to be executed in By breaking down the [workflow](#workflow) into manageable [tasks](#task), organizations can effectively coordinate and track progress, enabling efficient collaboration and ensuring that work is completed in a structured and organized manner. -The Serverless Workflow DSL defines a list of [tasks](#task) that **must be** supported by all runtimes: +The Open Workflow DSL defines a list of [tasks](#task) that **must be** supported by all runtimes: - [Call](#call), used to call services and/or functions. - [Do](#do), used to define one or more subtasks to perform in sequence. @@ -316,7 +316,7 @@ do: endpoint: https://petstore.swagger.io/v2/pet/{petId} ``` -Serverless Workflow defines several default functions that **MUST** be supported by all implementations and runtimes: +Open Workflow Specification defines several default functions that **MUST** be supported by all implementations and runtimes: - [AsyncAPI](#asyncapi-call) - [gRPC](#grpc-call) @@ -965,7 +965,7 @@ do: > [!NOTE] > When a `container process` is executed, runtime implementations are recommended to follow a predictable naming convention for the container name. This can improve monitoring, logging, and container lifecycle management. > -> The Serverless Workflow specification recommends using the following convention: `{workflow.name}-{uuid}.{workflow.namespace}-{task.name}` +> The Open Workflow Specification recommends using the following convention: `{workflow.name}-{uuid}.{workflow.namespace}-{task.name}` ##### Script Process @@ -984,7 +984,7 @@ Enables the execution of custom scripts or code within a workflow, empowering wo > [!WARNING] -> To ensure cross-compatibility, Serverless Workflow strictly limits the versions of supported scripting languages. These versions may evolve with future releases. If you wish to use a different version of a language, you may do so by utilizing the [`container process`](#container-process). +> To ensure cross-compatibility, Open Workflow Specification strictly limits the versions of supported scripting languages. These versions may evolve with future releases. If you wish to use a different version of a language, you may do so by utilizing the [`container process`](#container-process). **Supported languages** | Language | Version | @@ -1964,7 +1964,7 @@ A **resource catalog** is an external collection of reusable components, such as Each catalog is defined by an `endpoint` property, specifying the root URL where the resources are hosted, enabling workflows to access external functions and services. For portability, catalogs must adhere to a specific file structure, as defined [here](https://github.com/serverlessworkflow/catalog?tab=readme-ov-file#structure). -For more information about catalogs, refer to the [Serverless Workflow DSL document](https://github.com/serverlessworkflow/specification/blob/main/dsl.md#catalogs). +For more information about catalogs, refer to the [Open Workflow DSL document](https://github.com/serverlessworkflow/specification/blob/main/dsl.md#catalogs). #### Properties @@ -2132,7 +2132,7 @@ Represents the configuration of an event consumption strategy. ### Event Properties -An event object typically includes details such as the event type, source, timestamp, and unique identifier along with any relevant data payload. The [Cloud Events specification](https://cloudevents.io/), favored by Serverless Workflow, standardizes this structure to ensure interoperability across different systems and services. +An event object typically includes details such as the event type, source, timestamp, and unique identifier along with any relevant data payload. The [CloudEvents specification](https://cloudevents.io/), favored by Open Workflow Specification, standardizes this structure to ensure interoperability across different systems and services. #### Properties @@ -2147,7 +2147,7 @@ An event object typically includes details such as the event type, source, times | dataschema | `string` | `no` | An URI formatted string, or [runtime expression](dsl.md#runtime-expressions), that identifies the schema that `data` adheres to. | | data | `any` | `no` | The event payload. | -*Additional properties can be supplied, see the Cloud Events specification [documentation](https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md#extension-context-attributes) for more info.* +*Additional properties can be supplied, see the CloudEvents specification [documentation](https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md#extension-context-attributes) for more info.* *When used in an [`eventFilter`](#event-filter), at least one property must be supplied.* @@ -2176,7 +2176,7 @@ A correlation is a link between events and data, established by mapping event at ### Retry -The Retry is a fundamental concept in the Serverless Workflow DSL, used to define the strategy for retrying a failed task when an error is encountered during execution. This policy provides developers with fine-grained control over how and when to retry failed tasks, enabling robust error handling and fault tolerance within workflows. +The Retry is a fundamental concept in the Open Workflow DSL, used to define the strategy for retrying a failed task when an error is encountered during execution. This policy provides developers with fine-grained control over how and when to retry failed tasks, enabling robust error handling and fault tolerance within workflows. #### Properties diff --git a/dsl.md b/dsl.md index ad479de6..2f5e2826 100644 --- a/dsl.md +++ b/dsl.md @@ -1,4 +1,4 @@ -# Serverless Workflow DSL +# Open Workflow DSL ## Table of Contents @@ -39,24 +39,24 @@ ## Abstract -This document proposes the creation of a Domain Specific Language (DSL) called Serverless Workflow, tailored for building platform agnostic workflows. +This document proposes the creation of a Domain Specific Language (DSL) for the Open Workflow Specification, designed for building platform agnostic workflows. -Serverless Workflow aims to simplify the orchestration of complex processes across diverse environments, providing developers with a unified syntax and set of tools for defining and executing serverless workflows. +Open Workflow Specification aims to simplify the orchestration of complex processes across diverse environments, providing developers with a unified syntax and set of tools for defining and executing workflows. ## Motivation -Serverless computing has gained popularity for its ability to abstract away infrastructure management tasks, enabling developers to focus on application logic. However, orchestrating serverless workflows across multiple environments often involves dealing with disparate tools and platforms, leading to complexity and inefficiency. +Modern cloud-native computing has gained popularity for its ability to abstract away infrastructure management tasks, enabling developers to focus on application logic. However, orchestrating workflows across multiple environments often involves dealing with disparate tools and platforms, leading to complexity and inefficiency. -Serverless Workflow addresses this challenge by providing a DSL specifically designed for serverless workflow orchestration. By abstracting away the underlying infrastructure complexities and offering a modular and extensible framework, Serverless Workflow aims to streamline the development, deployment, and management of serverless workflows. +Open Workflow Specification addresses this challenge by providing a DSL specifically designed for workflow orchestration. By abstracting away the underlying infrastructure complexities and offering a modular and extensible framework, Open Workflow Specification aims to streamline the development, deployment, and management of workflows. ## Priority of Constituencies -Inspired by the [Priority of Constituencies](https://www.w3.org/TR/2024/NOTE-design-principles-20240718/#priority-of-constituencies) principle from the W3C Design Principles, the Serverless Workflow DSL prioritizes the following constituencies (collectively referred to as "users"): +Inspired by the [Priority of Constituencies](https://www.w3.org/TR/2024/NOTE-design-principles-20240718/#priority-of-constituencies) principle from the W3C Design Principles, the Open Workflow DSL prioritizes the following constituencies (collectively referred to as "users"): - Authors: people authoring and reading workflows - Operators: people running and operating a runtime implementation of the specification - Implementors: people implementing a specification compliant runtime -- Specifications writers: people working on the specifications of Serverless Workflow +- Specifications writers: people working on the Open Workflow Specification If a trade-off needs to be made, always put author's needs above all. @@ -68,7 +68,7 @@ Like all principles, this isn’t absolute. Ease of operations affects the perce ## Design -The Serverless Workflow DSL is crafted with a design philosophy that prioritizes clarity, expressiveness, and ease of use. Its foundation lies in linguistic fluency, emphasizing readability and comprehension. By adopting a fluent style, the DSL promotes intuitive understanding through natural language constructs. Verbs are employed in the imperative tense to denote actions, enhancing clarity and directness in expressing workflow logic. This imperative approach empowers developers to articulate their intentions succinctly and effectively. +The Open Workflow DSL is crafted with a design philosophy that prioritizes clarity, expressiveness, and ease of use. Its foundation lies in linguistic fluency, emphasizing readability and comprehension. By adopting a fluent style, the DSL promotes intuitive understanding through natural language constructs. Verbs are employed in the imperative tense to denote actions, enhancing clarity and directness in expressing workflow logic. This imperative approach empowers developers to articulate their intentions succinctly and effectively. The DSL also embraces the principle of implicit default behaviors, sparing authors from unnecessary repetition and enhancing the conciseness of workflow definitions. For instance, default settings alleviate the burden of explicitly defining every detail, streamlining the workflow design process. Furthermore, the DSL allows both inline declaration of components or the creation of reusable elements, granting flexibility in workflow composition. This flexibility allows developers to seamlessly integrate inline task definitions without imposing rigid structural requirements. @@ -86,7 +86,7 @@ Moreover, the DSL eschews strong-typed enumerations wherever feasible, fostering ### Workflow -A Serverless Workflow is a sequence of specific [tasks](dsl-reference.md#tasks) that are executed in a defined order. By default, this order follows the declaration sequence within the workflow definition. Workflows are designed to automate processes and orchestrate various serverless functions and services. +A workflow defined using the Open Workflow Specification is a sequence of specific [tasks](dsl-reference.md#tasks) that are executed in a defined order. By default, this order follows the declaration sequence within the workflow definition. Workflows are designed to automate processes and orchestrate various functions and services. Workflows can be triggered in different ways: upon request, scheduled using CRON expressions, or initiated upon correlation with specific events. @@ -94,7 +94,7 @@ Additionally, workflows may optionally accept inputs and produce outputs, allowi #### Status Phases -Both workflows and tasks in the Serverless Workflow DSL can exist in several phases, each indicating the current state of the workflow/task execution. These phases include: +Both workflows and tasks in the Open Workflow DSL can exist in several phases, each indicating the current state of the workflow/task execution. These phases include: | Phase | Description | | --- | --- | @@ -152,7 +152,7 @@ Runtimes are expected to publish these events upon state changes. While using th #### Components -Serverless Workflow DSL allows for defining reusable components that can be referenced across the workflow. These include: +Open Workflow DSL allows for defining reusable components that can be referenced across the workflow. These include: - [Authentications](dsl-reference.md#authentication) - [Errors](dsl-reference.md#error) @@ -165,7 +165,7 @@ Serverless Workflow DSL allows for defining reusable components that can be refe [Tasks](dsl-reference.md#tasks) are the fundamental computing units of a workflow. They define the different types of actions that a workflow can perform, including the ability to mutate their input and output data. Tasks can also write to and modify the context data, enabling complex and dynamic workflow behaviors. -The Serverless Workflow DSL defines several default [task](dsl-reference.md#tasks) types that runtimes **must** implement: +The Open Workflow DSL defines several default [task](dsl-reference.md#tasks) types that runtimes **must** implement: - [Call](dsl-reference.md#call), used to call services and/or functions. - [Do](dsl-reference.md#do), used to define one or more subtasks to perform in sequence. @@ -232,7 +232,7 @@ Once the task has been executed, different things can happen: ### Data Flow -In Serverless Workflow DSL, data flow management is crucial to ensure that the right data is passed between tasks and to the workflow itself. +In Open Workflow DSL, data flow management is crucial to ensure that the right data is passed between tasks and to the workflow itself. Here's how data flows through a workflow based on various transformation stages: @@ -282,7 +282,7 @@ Finally, the overall workflow output can be transformed before it is returned to 11. **Validate Workflow Output** After `output.as` is evaluated, the transformed workflow output is validated against the `output.schema` property to ensure it conforms to the expected structure. The execution only proceeds if the output is valid. Otherwise, it will fault with a [ValidationError (https://serverlessworkflow.io/spec/1.0.0/errors/validation)](dsl-reference.md#error). -By applying transformations at these strategic points, Serverless Workflow DSL ensures that data flows through the workflow in a controlled and efficient manner, maintaining clarity and relevance at each execution stage. This approach helps manage complex workflows and ensures that each task operates with the precise data required, leading to more predictable and reliable workflow outcomes. +By applying transformations at these strategic points, Open Workflow DSL ensures that data flows through the workflow in a controlled and efficient manner, maintaining clarity and relevance at each execution stage. This approach helps manage complex workflows and ensures that each task operates with the precise data required, leading to more predictable and reliable workflow outcomes. Visually, this can be represented as follows: @@ -372,7 +372,7 @@ Runtime expressions allow for the incorporation of variables, functions, and ope One key aspect of runtime expressions is their ability to adapt to runtime data and context. This means that expressions can access and manipulate data generated during the execution of a workflow, enabling dynamic decision-making and behavior based on real-time information. -Runtime expressions in Serverless Workflow can be evaluated using either the default `strict` mode or the `loose` mode. In `strict` mode, all expressions must be properly identified with `${}` syntax. Conversely, in `loose` mode, expressions are evaluated more liberally, allowing for a wider range of input formats. While `strict` mode ensures strict adherence to syntax rules, `loose` mode offers flexibility, allowing evaluation even if the syntax is not perfectly formed. +Runtime expressions in Open Workflow Specification can be evaluated using either the default `strict` mode or the `loose` mode. In `strict` mode, all expressions must be properly identified with `${}` syntax. Conversely, in `loose` mode, expressions are evaluated more liberally, allowing for a wider range of input formats. While `strict` mode ensures strict adherence to syntax rules, `loose` mode offers flexibility, allowing evaluation even if the syntax is not perfectly formed. All runtimes **must** support the default runtime expression language, which is [`jq`](https://jqlang.github.io/jq/). @@ -460,13 +460,13 @@ The following table shows which arguments are available for each runtime express ### Fault Tolerance -Serverless Workflow is designed with resilience in mind, acknowledging that errors are an inevitable part of any system. The DSL provides robust mechanisms to identify, describe, and handle errors effectively, ensuring the workflow can recover gracefully from failures. +Open Workflow Specification is designed with resilience in mind, acknowledging that errors are an inevitable part of any system. The DSL provides robust mechanisms to identify, describe, and handle errors effectively, ensuring the workflow can recover gracefully from failures. -Overall, the fault tolerance features in Serverless Workflow enhance its robustness and reliability, making it capable of handling a wide range of failure scenarios gracefully and effectively. +Overall, the fault tolerance features in Open Workflow Specification enhance its robustness and reliability, making it capable of handling a wide range of failure scenarios gracefully and effectively. #### Errors -Errors in Serverless Workflow are described using the [Problem Details RFC](https://datatracker.ietf.org/doc/html/rfc7807). This specification helps to standardize the way errors are communicated, using the `instance` property as a [JSON Pointer](https://datatracker.ietf.org/doc/html/rfc6901) to identify the specific component of the workflow that has raised the error. By adhering to this standard, authors and runtimes can consistently describe and handle errors. +Errors in Open Workflow Specification are described using the [Problem Details RFC](https://datatracker.ietf.org/doc/html/rfc7807). This specification helps to standardize the way errors are communicated, using the `instance` property as a [JSON Pointer](https://datatracker.ietf.org/doc/html/rfc6901) to identify the specific component of the workflow that has raised the error. By adhering to this standard, authors and runtimes can consistently describe and handle errors. *Example error:* ```yaml @@ -477,7 +477,7 @@ detail: The service is currently unavailable. Please try again later. instance: /do/getPetById ``` -The Serverless Workflow specification defines several [standard error types](dsl-reference.md#standard-error-types) to describe commonly known errors, such as timeouts. Using these standard error types ensures that workflows behave consistently across different runtimes, and allows authors to rely on predictable error handling and recovery processes. +The Open Workflow Specification defines several [standard error types](dsl-reference.md#standard-error-types) to describe commonly known errors, such as timeouts. Using these standard error types ensures that workflows behave consistently across different runtimes, and allows authors to rely on predictable error handling and recovery processes. See the [DSL reference](dsl-reference.md#error) for more details about errors. @@ -588,7 +588,7 @@ do: ### Interoperability -Serverless Workflow DSL is designed to seamlessly interact with a variety of services, ensuring robust service interoperability. +Open Workflow DSL is designed to seamlessly interact with a variety of services, ensuring robust service interoperability. #### Supported Protocols @@ -608,7 +608,7 @@ For custom interactions, the workflow can define [tasks](dsl-reference.md#run) t ##### Creating a Custom Function -Serverless Workflow DSL supports the creation and publication of custom functions to extend the DSL capabilities. +Open Workflow DSL supports the creation and publication of custom functions to extend the DSL capabilities. Custom functions allow you to define specific tasks and interactions that are not covered by the default supported protocols. @@ -655,9 +655,9 @@ run: 4. Commit and push your function to your repository. -5. Optionally, submit your function to the [Serverless Workflow Catalog](https://github.com/serverlessworkflow/catalog), allowing users to find your function. +5. Optionally, submit your function to the [Open Workflow Catalog](https://github.com/serverlessworkflow/catalog), allowing users to find your function. -For more information about authoring a new custom function, visit the [Serverless Workflow Catalog](https://github.com/serverlessworkflow/catalog). +For more information about authoring a new custom function, visit the [Open Workflow Catalog](https://github.com/serverlessworkflow/catalog). ##### Using a Custom Function @@ -681,17 +681,17 @@ do: ##### Publishing a Custom Function -Consider submitting your function to the [Serverless Workflow Function Catalog](https://github.com/serverlessworkflow/catalog). +Consider submitting your function to the [Open Workflow Function Catalog](https://github.com/serverlessworkflow/catalog). -This optional step allows users to discover and utilize your function, enhancing its visibility and usability within the Serverless Workflow community. By registering your function, you contribute to a shared repository of resources that can streamline workflow development for others. +This optional step allows users to discover and utilize your function, enhancing its visibility and usability within the Open Workflow Specification community. By registering your function, you contribute to a shared repository of resources that can streamline workflow development for others. For detailed instructions on how to contribute your custom function, please refer to the [CONTRIBUTING.md](https://github.com/serverlessworkflow/catalog/blob/main/CONTRIBUTING.md) file. ### Events -Events play a crucial role in Serverless Workflow by facilitating communication and coordination between different components and services. They enable workflows to react to external stimuli, paving the way for event-driven architectures and real-time processing scenarios. Events are essentially messages that convey information about a specific occurrence or action, allowing workflows to respond dynamically to changes in their environment. +Events play a crucial role in Open Workflow Specification by facilitating communication and coordination between different components and services. They enable workflows to react to external stimuli, paving the way for event-driven architectures and real-time processing scenarios. Events are essentially messages that convey information about a specific occurrence or action, allowing workflows to respond dynamically to changes in their environment. -Events in Serverless Workflow adhere to the [Cloud Events specification](https://cloudevents.io/), ensuring interoperability and compatibility with event-driven systems. This standardization allows workflows to seamlessly interact with various event sources and consumers across different platforms and environments. +Events in Open Workflow Specification adhere to the [CloudEvents specification](https://cloudevents.io/), ensuring interoperability and compatibility with event-driven systems. This standardization allows workflows to seamlessly interact with various event sources and consumers across different platforms and environments. #### Emitting Events @@ -707,13 +707,13 @@ The Listen task provides a mechanism for workflows to await and react to externa This capability allows workflows to implement event-driven behavior, where they respond dynamically to changes in their environment. For instance, a workflow responsible for monitoring vital signs in a healthcare application might listen for temperature or heart rate measurements. Upon receiving such measurements, the workflow can perform actions like alerting medical staff or updating patient records. -In summary, events in Serverless Workflow serve as the foundation for building event-driven architectures and enable workflows to communicate, coordinate, and react to changes in their environment effectively. They empower workflows to operate in real-time, making them well-suited for scenarios requiring dynamic, responsive behavior. +In summary, events in Open Workflow serve as the foundation for building event-driven architectures and enable workflows to communicate, coordinate, and react to changes in their environment effectively. They empower workflows to operate in real-time, making them well-suited for scenarios requiring dynamic, responsive behavior. See the [DSL reference](dsl-reference.md#listen) for more details about listen tasks. ### Extensions -Extensions in Serverless Workflow offer a flexible way to extend the functionality of tasks within a workflow. They allow developers to inject custom logic, perform pre- or post-processing tasks, and modify task behavior dynamically based on runtime conditions. With extensions, developers can enhance workflow capabilities, promote code reuse, and maintain consistency across workflows. +Extensions in Open Workflow offer a flexible way to extend the functionality of tasks within a workflow. They allow developers to inject custom logic, perform pre- or post-processing tasks, and modify task behavior dynamically based on runtime conditions. With extensions, developers can enhance workflow capabilities, promote code reuse, and maintain consistency across workflows. For example, extensions can be used to: @@ -729,7 +729,7 @@ Extensions are defined with properties such as `extend`, `when`, `before`, and ` - **`before`**: Executes tasks before the extended task. - **`after`**: Executes tasks after the extended task completes. -Overall, extensions empower developers to build complex workflows with enhanced functionality and maintainability, making Serverless Workflow a powerful tool for orchestrating cloud-native applications. +Overall, extensions empower developers to build complex workflows with enhanced functionality and maintainability, making Open Workflow Specification a powerful tool for orchestrating cloud-native applications. See the [DSL reference](dsl-reference.md#extension) for more details about extensions. @@ -770,7 +770,7 @@ do: ### External Resources -External resources in Serverless Workflow allow you to define and access external assets or services required for workflow execution. +External resources in Open Workflow allow you to define and access external assets or services required for workflow execution. These resources can include APIs, databases, files, or any other external entities needed by the workflow. Each external resource can be identified by a unique name and is associated with a URI that specifies its location. @@ -780,11 +780,11 @@ By defining external resources within the workflow, you centralize resource mana ### Authentication -Authentication in Serverless Workflow specifies the method by which the workflow accesses protected resources or services. +Authentication in Open Workflow specifies the method by which the workflow accesses protected resources or services. -Amonst others, [external resources](dsl-reference.md#external-resource) and [calls](dsl-reference.md#call) may define authentication. +Among others, [external resources](dsl-reference.md#external-resource) and [calls](dsl-reference.md#call) may define authentication. -The Serverless Workflow DSL supports a suite of standard authentication mechanisms, amongst which are: +The Open Workflow DSL supports a suite of standard authentication mechanisms, amongst which are: - **Basic Authentication**: Utilizes a username-password pair for authentication. ```yaml diff --git a/examples/README.md b/examples/README.md index de9599a0..6cd493cd 100644 --- a/examples/README.md +++ b/examples/README.md @@ -1,11 +1,11 @@ # Examples -Welcome to the Serverless Workflow Examples directory! This section contains a collection of brief YAML files, each representing a single workflow definition. +Welcome to the Open Workflow Examples directory! This section contains a collection of brief YAML files, each representing a single workflow definition. -These examples are designed to demonstrate specific features and functionalities of the Serverless Workflow DSL. They serve as a practical reference to help you understand and implement different aspects of Serverless Workflows in your projects. +These examples are designed to demonstrate specific features and functionalities of the Open Workflow DSL. They serve as a practical reference to help you understand and implement different aspects of Open Workflows in your projects. ## Contributing -We welcome contributions! If you have an example demonstrating a unique feature or use case of Serverless Workflow, feel free to submit a pull request. +We welcome contributions! If you have an example demonstrating a unique feature or use case of Open Workflow, feel free to submit a pull request. -For more detailed information on contributing, including guidelines and best practices, please refer to our [Contributing Guide](./CONTRIBUTING.md). \ No newline at end of file +For more detailed information on contributing, including guidelines and best practices, please refer to our [Contributing Guide](../contributing.md). \ No newline at end of file diff --git a/schema/workflow.yaml b/schema/workflow.yaml index 0bd5cc42..3fcf8785 100644 --- a/schema/workflow.yaml +++ b/schema/workflow.yaml @@ -1,6 +1,6 @@ $id: https://serverlessworkflow.io/schemas/1.0.3/workflow.yaml $schema: https://json-schema.org/draft/2020-12/schema -description: Serverless Workflow DSL - Workflow Schema. +description: Open Workflow DSL - Workflow Schema. type: object required: [ document, do ] properties: diff --git a/use-cases/README.md b/use-cases/README.md index b4f0810c..760d9e6f 100644 --- a/use-cases/README.md +++ b/use-cases/README.md @@ -1,12 +1,12 @@ # Use Cases -This directory contains a collection of high-level use cases that demonstrate the capabilities and potential applications of the Serverless Workflow DSL. Each use case provides insights into how to effectively implement workflows in various scenarios, helping newcomers understand the framework's power and flexibility. +This directory contains a collection of high-level use cases that demonstrate the capabilities and potential applications of the Open Workflow DSL. Each use case provides insights into how to effectively implement workflows in various scenarios, helping newcomers understand the framework's power and flexibility. ## Purpose The primary purpose of these use cases is to: -- **Educate Newcomers:** Provide clear examples of utilizing Serverless Workflow DSL for real-world applications. +- **Educate Newcomers:** Provide clear examples of utilizing Open Workflow DSL for real-world applications. - **Inspire Innovation:** Showcase the diverse workflow automation and orchestration possibilities. - **Facilitate Best Practices:** Encourage consistent structure and documentation, making it easier to share knowledge and experiences within the community. @@ -37,14 +37,14 @@ Each use case in this directory MUST follow a specific structure to ensure clari - **Triggers:** Events that initiate the workflow. - **Flow Breakdown:** Detailed step-by-step workflow breakdown, including key actions and decisions made throughout the process. - **Visualization:** Optional diagrams or flowcharts that illustrate the workflow's structure and progression. -- **Example:** A YAML example of the workflow using Serverless Workflow DSL, demonstrating how the concepts discussed are implemented. +- **Example:** A YAML example of the workflow using Open Workflow DSL, demonstrating how the concepts discussed are implemented. #### Conclusion -- A summary of the benefits and insights gained from the use case, reinforcing why Serverless Workflow is a suitable choice for the described scenario. +- A summary of the benefits and insights gained from the use case, reinforcing why Open Workflow is a suitable choice for the described scenario. ## Contributing We invite everyone to submit their own use cases to enrich this directory and help others learn from their experiences. -If you would like to contribute, please refer to the [contributing.md](./contributing.md) for guidelines on how to contribute to the Serverless Workflow project. \ No newline at end of file +If you would like to contribute, please refer to the [contributing.md](../contributing.md) for guidelines on how to contribute to the Open Workflow Specification project. \ No newline at end of file diff --git a/use-cases/managing-github-issues/README.md b/use-cases/managing-github-issues/README.md index 565318fa..0b8212c5 100644 --- a/use-cases/managing-github-issues/README.md +++ b/use-cases/managing-github-issues/README.md @@ -4,7 +4,7 @@ ### System -The system is a GitHub-based issue management workflow designed to automate the lifecycle of an issue. It leverages Serverless Workflow (SW) DSL to handle various stages, from assignment and development to review and closure. +The system is a GitHub-based issue management workflow designed to automate the lifecycle of an issue. It leverages Open Workflow DSL to handle various stages, from assignment and development to review and closure. ### Actors @@ -259,4 +259,4 @@ do: ## Conclusion -This use case illustrates the powerful capabilities of Serverless Workflow in automating complex processes such as GitHub issue management. The workflow is flexible, scalable, and easy to maintain, making it an ideal choice for orchestrating tasks in modern development environments. By leveraging Serverless Workflow, teams can ensure efficient and consistent handling of issues, improving productivity and achieving better project outcomes. \ No newline at end of file +This use case illustrates the powerful capabilities of Open Workflow Specification in automating complex processes such as GitHub issue management. The workflow is flexible, scalable, and easy to maintain, making it an ideal choice for orchestrating tasks in modern development environments. By leveraging Open Workflow Specification, teams can ensure efficient and consistent handling of issues, improving productivity and achieving better project outcomes. \ No newline at end of file diff --git a/use-cases/multi-agent-ai-content-generation/README.md b/use-cases/multi-agent-ai-content-generation/README.md index 6c7a1ff4..9c2a5ad9 100644 --- a/use-cases/multi-agent-ai-content-generation/README.md +++ b/use-cases/multi-agent-ai-content-generation/README.md @@ -172,4 +172,4 @@ do: ## Conclusion -This use case demonstrates how multiple AI agents can collaborate efficiently to generate high-quality content. By leveraging the Serverless Workflow DSL, the system ensures that each agent’s output is evaluated and refined in a coordinated manner, leading to superior results. This approach allows for iterative improvements, making it an ideal solution for complex content generation tasks. \ No newline at end of file +This use case demonstrates how multiple AI agents can collaborate efficiently to generate high-quality content. By leveraging the Open Workflow DSL, the system ensures that each agent’s output is evaluated and refined in a coordinated manner, leading to superior results. This approach allows for iterative improvements, making it an ideal solution for complex content generation tasks. \ No newline at end of file