Event Driven Communications (EDC) Objects
This package contains the basic objects of the EDC protocol, the JSON schemas, & a validator.
What is The Event Driven Communications (EDC) Protocol?
Is a JSON based communications protocol that allows for the communication of events while enabling the sharing of common data between a chain of events.
The concept that one event is the cause of a new event is a first class citizen in the EDC protocol. This allows for the logical grouping of events based on the cause-effect chain by tying together UUIDs. In addition, a chain of events logically share data that is common to each event in the chain. This allows the detail of the events to live seperate from the shared chain data.
Event Chain |-----------------------------------------| | shared data | | |event-1|-->|event-2|-->|event-3| | | | | | |-->|event-N| | |-----------------------------------------|
Event with types
// 'event' will inherit the 'Shared' property from 'cause'// 'event' will inherit the 'Shared' property from 'cause'
Table of Contents
- Event Driven Communications (EDC) Objects
- EDC-WS Server/Clients
- What is The Event Driven Communications (EDC) Protocol?
- Table of Contents
- Event Driven Communications (EDC) Components
- Acknowledge and Flow
- Generic Events
Event Driven Communications (EDC) Components
An Event is a JSON object defined as
Error Event Details
"details" of the error event MUST include
"cn"the common name of the error
"code"the number for the error
"message"the message to help understand the error
"failed"the string form of the failed event
"data"this field is allowed for any additional information about the error.
The version of the EDC protocol
The type field represent the event type. It can be any string except
"acknowledgement" which are reserved.
The id field is a UUID and MUST be unique for all events
The trigger is set to the event that triggered the new event.
new event.trigger = cause.id
The concept is meant to build a chain of events with
events becoming the
new events. An
event is not limited to causing only a linear chain. It is possible for one
cause to trigger multiple
cause --> event1 & event2
If an event is sent with the
"acknowledge": true flag then the recieving system MUST reply with an
acknowledgement with the
trigger field set to the
id of the sent event. Multiple replies of different events is allowed.
A --> B
B --> AAck Event
-- Or --
-- Or --
The details is any JSON object and would hold the details for the OCCURING event. It is not intended to be used for
shared properties that relate to the chain of events.
The shared property is any JSON object. It is intended to be used as a property that a
chain of events share in common.
When an event is
triggered by a
cause then it SHOULD set the
trigger to the
cause.id and copy the
cause.shared data to the
new event.shared. The shared data is not immutable and can evolve.
Examples would include a connection-Id that events share incommon, a call-Id for a phone call, a survey-Id, or a start time for a
chain of events.
A --> B
B --> A// Note the shared data is copied
A --> B// Note that the shared.step was increased
Is only used with the
"type": "error" event. It MUST be a string copy of the event that triggered the error
Acknowledge and Flow
The requirement that
"acknowledge": true event MUST have a reply leads to two thrown errors
TimeoutError. In addition,
"acknowledge": false events are asynchronous even if
await is used. This is because the promise will resolve instantly on the
Multiple Synchronous Events
Acknowledge is key in sending multiple synchronous events in which the order of receival matters. If event
A must be before event
B, then event
A should be sent with
"acknowledge": true this would guarantee an acknowledging reply that
A was received and that
B could now be sent. This would be true for any length of synchronous dependent events.
[A, B, C, D, ...]
T represents the type that
details is. While the type
K represents the type that the
shared property is.
T for the ErrorEvent represents the type of