diff --git a/README.md b/README.md index f34376b47..46d3d3d1f 100644 --- a/README.md +++ b/README.md @@ -32,7 +32,7 @@ In order to achieve these goals, the Serverless WG must describe: - One or more common architectures that are in active use today or planned to be built by WG members - How events are transported from source to action via at least one protocol -- Authorization model(s) that control access and execution permissions +- Identify and resolve whatever else is needed for interoperability ### Non-Goals of this specification The following non-goals will not be part of the specification: diff --git a/spec.md b/spec.md index 38d8cb06d..4ec2312d4 100644 --- a/spec.md +++ b/spec.md @@ -30,57 +30,25 @@ platforms and beyond. # Design Goals CloudEvents are typically used in a distributed system to allow for services to -be loosely coupled during development, then may be configured with -tight-coupling for specific applications or dynamically configured at runtime. +be loosely coupled during development, deployed independently, and later +can be connected to create new applications. The goal of the CloudEvents specification is to define interoperability of event -systems that allow cloud providers, third-party tools and services to provide: -- new event sources -- new event consumers -- observability, such as monitoring, debugging and visualization, -- developer tools and libraries - -## Key properties of the system: -- Source & action may be developed and deployed independently -- Trigger configuration allows for actions to be invoked based on a condition -(e.g. for a specific event type generated by a source, optionally filtered by -specific attribute values, such as a Function which is invoked when an image is -uploaded to a specific bucket in an object store). -- Events are uniquely identified to facilitate developer velocity and tooling: - - a unique identifier allows for idempotency for reliable implementation - - structured event definitions allow the consumer to rely on a specific format -- Common metadata attributes allow for observability via tools without -knowledge of the specific implementation of an event system and also can provide -value without detailed handling of the specifics of the unique event data -- CloudEvents may be transported from source to action with different protocols. - -In order to achieve the above goals and desired system properties, the -Serverless WG must agree on a common vocabulary with precise definitions -describing the key elements of the system including: -- [Source](../spec.md#source) -- Action: An action consumes an event, producing a behavior or effect which was -triggered by a specific *occurrence* from a specific *source*. While the -details of how events are delivered to an action is outside of the scope of the -specification, the purpose of generating an *event* is typically to allow other -systems to easily react to changes in a source that they do not control. The -*source* and action are often built by different developers. - -Examples: -- the *source* is a managed service and the *action* is custom code in a -serverless Function. -- the *source* is an IoT device and the *event* is transmitted through an API -Gateway to the *action*, a service provided by a different developer. - -The events system provides a way for the developer to specify which *event* -should be delivered to which *action*. The specific mechanism is outside the -scope of the specification, yet the following definitions facilitate an -understanding of how CloudEvents are typically used in context: -- Trigger: the condition that causes an event to be transmitted from source to -action -- Rule: the association of trigger + action - -Systems which generate events can have independent mechanisms for how triggers -are specified and how rules are stored and evaluated. +systems that allow services to produce or consume events, where the producer and +consumer can be developed and deployed independently. A producer must be able +to generate events before a consumer is listening, and a consumer must be able +to express an interest in an event or class of events that is not yet being +produced. + +To this end, the specification will include common metadata attributes of an +event that facilitate interoperability, where the event does not contain any +details about the consumer or transport that might be use to send the event. + +## Non-Goals +The following will not be part of the specification: +Function build and invocation process +Language-specific runtime APIs +Selecting a single identity/access control system ## Status At this time the specification is focused on the following scope: