Open duglin opened 3 months ago
An example:
{
"specversion": 1.0",
"id": "myregistry",
"endpoints": {
"myinput": {
"id": "myinput",
"usage": "producer",
"format": "", # same as missing, means none
"protocol": "HTTP/1.1",
"channel": "myadapter",
"endpoints": [{"uri": "https://example.com"}]
"config": {
"method": "POST"
},
"messagegroups": [ "/messagegroups/mymsgs/messages/mymessage" ]
},
"myoutput": {
"id": "myoutput",
"usage": "consumer",
"format": "CloudEvents/1.0",
"protocol": "Kafka",
"channel": "myadapter",
"endpoints": [{"uri": "https://server.com"}]
"config": {
"topic": "serviceA/{topic}",
"consumergroup": "mygroup"
},
"messagegroups": [ "/messagegroups/mymsgs/messages/mymessage" ]
}
},
"messagegroups": {
"mymsgs": {
"id": "mymsgs",
"messages": {
"mymessage": {
"id": "mymessage",
"content": {
"jsonSchema": {
"schemaurl": "...url to popped event schema..."
}
},
"format": {
"CloudEvents/1.0": {
"metadata": {
"type": { "value": "popped" },
...
}
}
},
"protocol": {
"HTTP/1.1": {
"headers": [
{ "name": "action", "value": "popped" }
]
},
"Kafka": {
"topic": "serviceA/mytopic", # Optional
"key": "{key}"
}
}
}
}
}
}
}
Today, Endpoints, with Message inlined, looks like this:
One issue with this is that often times messages/events are sent over different protocol, with different "envelopes" and even different formats (json vs xml). In order to represent that the SAME bit of content(data) has these alternatives many different instances of a Message needs to be created. It is then up to the Registry maintainer to find a way to correlate all of these Messages together and to keep them all in-sync if changes are needed.
If we view the content as the central piece of data of interest, we then have an hourglass type of structure around it - with the content being the middle of the hourglass. For example, abstractly we have:
Endpoints -> Messages -> Envelopes -> CONTENT -> schemes
Notice that all of those entities can have multiple instances of them except CONTENT - hence the (sort of) hourglass idea.
The proposal is to allow for a single definition of CONTENT to be associated with multiple entities above and below it in the above abstract model:
The Endpoints
format
andprotocol
attributes become selectors for the Message - this is how the Endpoint indicates which one it supports.Do we need a "content" selector for which schema it'll use? Mainly when it's a producer of messages.
While there are questions in the Endpoint section, this issue is really about changing the Message entity.