 I think we can start now. First of all, thank you. I know it's been a long conference, a lot of very interesting talks. And that at that time of the Friday afternoon, you still can spare that time and mental energy to follow this talk. I really appreciate that. So my name is Klaus Dysnei. I work for SAP. And I'm a member of the serverless working group at SAP at CNCF. And we are working on the Cloud Events Project. And our most recent initiative is X Registry. And this talk is mostly about this one. But I'll start with a general intro of the group. And what we've been doing over the past years, introduced a sample scenario I made up for this talk. I'd explain a bit what we understand, what we think, what we say discovery, the core concepts of X Registry. And of course, as usual, I guess, I will close with a summary and a bit of an outlook of things we might look at when working on X Registry. So Cloud Events, first of all, was started in late 2017 when in the serverless working group was decided that this could be an interesting field to standardize to do something open source in the field of serverless. And it quickly became a project on its own. So at KubeCon in Copenhagen, then it was announced that it reached the sandbox level. And fast forward, one and a half years later, the version 1.0 was reached. So the core specification at that point became stable. And we then met and discussed what to do next. And those two things we decided to work on were discovery and subscriptions, event subscriptions. But of course, just because those within new fields doesn't mean that the other fields were already settled. I mean, just because it's a 1.0, work doesn't stop. Actually, I had the impression that for many it just started. The SDKs needed to be built and extended. And also a lot of people just had to, yeah, I would say, digest even Cloud Events first. And it took some time before people could free up their mind and get to that point when they started to get more interested in discovery. Yeah, so SDK work I mentioned, we have also some other draft specs that emerged over the time. We have been working on subscriptions as well. There is a draft specification for that. It has been stable for a while, so not really touched. As a side effect of the other specifications, we also have a spec for pagination because that is a frequent problem in the few deal with API specifications. And we have a SQL dialect that emerged as part of the subscription API that we defined really a complete little secret dialect for filtering on Cloud Event attributes. Okay, actually I have to admit this is the slide already showed last year in Amsterdam. Still, it's not the case that nothing happened. We have been really active on X registry and of course, yay, we graduated just in the beginning of this year. So that was a long way. And actually also behind the graduation, I think there's a lot of this, what I call digesting Cloud Events because it really needed to be incorporated in many ways. So, but now let's go to discovery and let's look at a scenario you might find familiar as you are here. I thought of booking a conference and travel to the conference as maybe one example. It's for sure the way I designed it, not certainly very realistic, but nevertheless, as a sample, I thought it would be better than the usual hello world or blob store events we usually have when we discuss Cloud Events on some samples. So, in this scenario, you have some people who book a conference. If you look at them, they might not be typical Cubecoin attendees with the business outfits, but nevertheless, so conference attendees, they register for a conference and here then you could think of certain providers that offer the management, the booking and those things for conferences. So that's what I mean when I talk about conference management service. On the other hand, you have travel service providers that hotels, airlines, et cetera, and booking platforms that provide access to those providers. So, if a new conference is planned, so someone orders one of those services to manage a conference, then it sends out a conference planned event and the service providers and also the booking platform get to know about it and the service providers can then decide to offer discounts. That's what is usually also listed when you're on that homepage, when you're booking a Cubecoin. And then they can send out again events that they're offering discounts and when someone actually makes use of it, then it's a discount granted event, et cetera. You have changes on conferences. You can have updates or sadly enough, I mean, you can also have a conference canceled and the booking platform here is just a consumer of events because it just wants to be up to date about what is going on with conferences and who supports it. And yes, so cloud events for interoperability. This is a cloud event, how I could imagine to have it for this, it's, if you look at the top, part I marked in yellow, there are the typical hopefully known suspects by now, the event type, where you'll see that this is a conference planned event. Maybe I can also switch on my laser pointer thingy. So the conference planned event, the event source I of course made up, but you see here that would be the host name maybe of the conference management service and in the end here I put CNCF for the organizer of that particular conference. In the subject that has some relevance for the next slides also, I put in something that uniquely identifies the conference. So it's a combination of the conference management service here, it's just example conferences, CNCF and acronym for this conference. And the payload just briefly, I mean there's also similar data, a lot of things you would expect like the venue and the name of the conference and the bottom you see max attendees that could be a hint for those service providers how much discount they wanna offer, what's the capacity they could offer. So let's, yeah, the conference key is again this combination of those three values and let's now discuss what discovery would be in this case. So discovery can be three things. First of all, you would like to know what events are there, what is available. That's essentially what you saw in this diagram in the beginning about the scenario and also how the cloud event attributes are set, how they are used. But once you have found about this, it's about the implementations and then data structures matter. So that's the schema registry, that's about the payload formats usually. And in the end then you, it's also about discovering specific endpoints. So where can I send my events or what can I, where can I subscribe to events? And yes, so that's something new. Since last year we have a logo, a real logo this time. So that was also created just a few weeks ago. And, but again, back to our scenario. So now we have a new service provider in town. This little guy here opened up a new hotel, the Cloudian. And he has the goal, I mean, it's a new hotel. He wants to get in business. So why not offer some discounts? And yeah, so those are again the steps. That's the steps I explained before. You have, you wanna find out about the relevant event definitions. You need to implement consumers and producers that again includes the schemas and set up your own endpoints. And then for consumption also subscribe them to events. So now to the event definitions. And a definition for that event I showed in the beginning could be like this one here. Again, this definition also gets the, I gave it the identifier conference planned. It mentions here the format cloud events. So that might suggest that there's not just cloud events and I'll come to that later. But the typical things for cloud events then is in this metadata section where you then have descriptions or further constraints actually of the cloud event context for that event. So for type it's clear in that context here that this is always a fixed value. This is this conference planned type event type. Subject is interesting because here it's not set to a specific value. I mean, it's clearly dynamic depends on the conference but it's said that this is required. So the core specification of cloud events subject is just an optional attribute but for this event definition then it's said that it is required. And yeah, finally, then in the bottom here in this case there is a link to the event, to the schema definition for this payload of this event. We can also have a look at the right direction. Yes. So I hope that is, that is visible. There is, I prepared also really a full registry file in the first place for this talk. At some point, I will probably also upload this to the, as a sample to the x-versions repository. I'm not sure when it will happen. What we have here is those sections. So this is a registry in a file. We also have, and that also come later in API. But first this file structure, it's good to understand what we are doing here. We have the message groups and here you can then find the definition. Also the one that was shown on the slide, that one is under conference management. Here you again have the conference planned event. There are also the other two events and you see here also that it is in groups. So there's the provider group and the management group provider are those two discount events that are then supposed to be sent out by the service providers. And in addition to message groups, we have here the schema groups. So there was that link to the schema. In this case is the JSON schema because that's the one I'm most familiar with. But we would also support other schema languages. We are not, it's not specific to JSON schema. That's also why we have here this format field. So schemas can be versioned. So that's also a concept of the registry. And sorry, in the bottom there are the end points and we will come to those then a bit later. So the general concept of X registry and the X it stands for extensible is that you have this general structure of a registry that contains groups of resources. The groups again can contain multiple types of resources and those again can have versions. And on each level you can define additional metadata attributes. There are also already some we have defined in the core specification. And now maybe to the API. We have this API, I guess for this hierarchical structure it's quite straightforward that the rest API makes sense. There are a few special things but first you can list groups, look at the specific group. You can list resources and again do all those typical things you do in rest APIs. But we also have this question mark meta and that will also play a role later on when we look at schemas. I have hopefully one experimental implementation of an API up and running and can try to show some rest calls maybe. It's running locally on a mini cube and it is really experimental. It's not even yet in our repository. It's an implementation done by Doug Davis, our co-chair. If you see this Doug later on maybe, thank you for all the support. So this what I just called as a gets on the group of provider messages and let's see at the result. So here you then get again this what you saw already in the registry JSON that file version I showed you before. Something you might observe when looking a bit closer. Maybe I also make a bit bigger. There are a few more attributes in here. You have now the epoch which we use for consistency checks. If updates are done on the API, there's this versions count, those count values. There are additional URLs mentioned in here that are just added by the server. These are attributes that are just set by the server. It would be partially impossible and partially also very annoying if you had to set those values when you're writing this by hand into a file. So that's an important aspect here as well. We have of course also other ways to access this. Let me see. So there are also update operations possible. Of course I'm doing, I can also do a put here. In this case, the put updates the definition of this provider messages message group and adds a label. So labels are also a concept we have in the metadata. In this case, it just adds a label about the management service that in this kind, this group belongs to the example conferences. So just to have some example for the labeling and I can hopefully run this and it worked. Yes, so here as well, you see now after the update the epoch is set to two now. And we also should see the labels, right? And this can then also later be used to filter when you're accessing that API. So what else? Let's maybe go back to this. Ah, yeah, one more thing. The registry is self-describing. So we had that was also in the slide before the very first one. We have this model slash model call and then you really get a description of the schema of the registry you could say. It's actually some, you could say our own schema dialect that was a long discussion and there were a lot of experiments with the JSON schema and open API. And finally we decided to have this on our own. It's a more simplified. It's not a general purpose schema language, I would say, but for all purposes it is more simple. We will also have a feature that you can do the self description also in other schema languages. So it will be defined using this language but you could then also retrieve it probably in JSON schema or whatever the server supports. So just to show you this one as well, for the model endpoint, I think I have that call somewhere. It is a bit difficult to look at the screen from up here, here. So this is quite a lot. What gets returned here, a lot of attributes and especially for the message groups that's quite a bit or the messages, it's quite a bit of definition you have in here because we have parts here for different protocols and I will come to that also later on. But that's why this is actually quite a bit this model. But back to messages and to Captain Cube and his hotel. So it is of course nice that you can define a message and then also have that exposed, for example, over HTTP. So that's what you see on top. We separate the abstract cloud event definition from the protocol specifics and our definitions. And that's why in these message groups I showed in the beginning, you didn't see anything about HTTP because those were just about cloud events. In the endpoint definitions, I later on I put then a binding and have my example is HTTP, but you can also have all the other cloud event bindings, of course, an interesting feature here is that we also introduced something we call the base message URL. So you can define an abstract message that just is a cloud event format and doesn't have a binding. And then later on you can define specific messages that then refer to this abstract message and in addition then add the protocol specifics like the HTTP method paths headers, those things that are not really not covered by the cloud event specification, but that are up to the implementation to decide on. And this brings me back to the model and why it was so long in the example before. We have something that is called if values and this is a bit similar to what you might know from OpenAPI there are discriminators and actually I think I was not part of this, but I think that's something people tried to use before but didn't really work out for us. But yes, that's the if value. So the example I have here is the binding and there you can then, depending on what the binding parameter holds, you can then have different attributes defined in those if values. And this is again in this model, let's see. So here we have already the binding for A and QP for example. So here's the first of all the binding property defined. It has a name, a type of course. And then there comes this if models, if values section. And here you see if I collapsed those sections a bit, you see that there are the bindings for the different protocols. And especially A and QP has quite rich possibilities here. You have the application properties, you have delivery annotations, sorry, footer properties and so on. And that is something that varies for each protocol and that's why it's quite nice to have this binding and to have it work that way. In my example, I had that endpoint definition. So the endpoints exactly. And here it's the same endpoints. I essentially special message groups that carry in addition some information about an endpoint. But below they also have messages and our grouping mechanism for messages as well. And here are again those discount offered, discount granted messages. But you see also that they are pointing to a base message and that they have this binding. And just for the example, I just added that in this case, for this endpoint, because it is a producer endpoint, here usage producer, this is about, so this is a post method that would be used. So you would post events to that producer endpoint and use the path discounts. And yeah, finally the schema registry and this one is a bit different because in this schema description for X registry, we can also state if a resource actually carries a document or if it just consists of metadata that is defined in X registry. And that's what we have here. So if for schema, that's exactly one example where there is a document, the message definition was so lengthy that schema because everything was defined, all the metadata was defined in X registry. And here we just say that this contains a document. And that also has some effects, of course. We can look at a schema group. I hope I fed that into the server before. Yes, so I had to restart that demo a few times. So what you see here is the schema group. And one thing I could do is it says, for example, that there is one schema in there and it's just metadata about the schema group. Let's just say, yeah, it's actually all schema groups but in this case, there's just one schema group in the schema registry. That's okay. You could also say inline then it would already put in also the schema. But it is still only the metadata of the schema. If you wanna really access the schema itself, you can do so by accessing it directly. That's what I have here. Then you really get the schema data. Again, if you are interested in the metadata, by the way, that metadata is also there but in this case it is in the header. So here you see all those X registry headers. And that is a very similar concept to what we have in cloud events in the core specification where we can in binary encoding also transport metadata in header attributes. We use this actually here as well. If you wanna have that metadata and not the document, you can also add the question mark meta where I already said we would see this later on. So then you get just the metadata. That can be handy also if you wanna do update operations because then you can also do the update operations with all the data in the body, which is much easier. So back to Captain Cube. He has found his events and the subscriber endpoint for subscribing to those management events where the conference planned event and those events are omitted. You can subscribe his endpoint to this and there's the producer endpoint where he can send discount events too. And to support this, we have some experimental implementation of a generator tool that was created by another member of the group Clemens Fasters. He also showed parts of this last year in Amsterdam. So what you can do, so of course I did that before so you can see that there are already some generated output, which is here in the test directory. But what I do now is I call this again and put it into the out directory. So you might see then that this shows up there, hopefully. And yes, so there's now the out directory. You can see that some Java stuff has been generated, not that fluent with Java anymore these days, but still what you can see is there are those structures generated. This is just for the producer, so it's just about discount granted and discount offered. There's are those classes generated that contain data that is derived from the schema definition here, the conference key for example. And on the other hand, there's also already a producer generated that contains some methods to send out those events already. So here's the send discount offered event. And you can see here that the type is already set as a constant. And we can do the same also for async API. So actually there is a generator that generates from x registry async API descriptions. And now also in that output out directory, something else should have shown up. I think it is this one. It's a YAML version of async API for those of you who are familiar with it. You see here again the server description with a sample URL I added in the file. You see, what else do you see? You see that there is a channel. It's a webhook. It's always this one direction where it's sent. And you see that there is those two messages already referenced from here. And those message definitions again correspond to those events we saw in x registry before. And again, you already the cloud event attributes as part of those message definitions. In the bottom also the schemas are available. So that brings me to the summary. X registry manages metadata about resources. That sounds very generic and it is generic, but we also defined domain-specific extensions for messages and points and schemas. It is well possible to define your own definitions. Essentially, you could also store open API or async API documents in there. You could also use it as a registry for that. You can also use file-based format and just write things into a file. It's not yet stable, so that was also a challenge for me preparing this. The spec currently still changes on a weekly base. We are still meeting every week and discuss changes that are proposed. And so, but nevertheless, it's progressing. And I think since last year we got some progress and some ideas that got much more clear. One thing that needs some work is if we think of cases where we might replicate registries where you have, say, a registry in a private subnet that would mirror a registry from the open internet and how you would do these things. You would probably not replicate this over those REST APIs I showed you before that increase the epoch value and all those things that might require different mechanisms. So that might be one field to look at. Another thing is we might define actually, yeah, cloud events that would then notify about changes to the registry, so that we would use our own specification for notification events. And yeah, it's still a good time to join us, by the way. If you're interested, we have weekly calls. We have Slack channels, we have GitHub mailing lists. I perceived the serverless working group as a very welcoming community. So it's really very pleasant conversations you can have there. So with that, I would say I'm open to questions. Thanks for the talk. Very interesting. I've never heard of Xreka Suite before today. When do you expect this back to be stable when you, because you said there are changes weekly, basically? That's always a hard question. I know, I know. I don't really know. It really depends on people who participate and bring in interesting use cases. I will also, just by preparing this talk with the sample scenario, that already brought me some new ideas I want to discuss with the others next week. Yeah, I can't really say, really, sorry. Thank you. Hello, thank you for the talk. I have almost same question, but I'll phrase it in different way. Which parts is stable and which ones are more in movement or in trouble? So to know, it's not a when, but what can I rather stably or safely use today and which one is more open to movements and changes? So X registry is completely open still. The only really stable part of the cloud events core specification and the SDKs. I have a question about the X registry. So is it standard or there will be actual physical implementation as well that we can use and deploy? I know you've got a sample there, but... Yes. Yeah, it's a good question. I don't know yet. I could imagine that, so the way I have opened them, let me see. So I took the implementations from these two web pages. So one is the CLI that is currently in Claims Vastas personal repository and the API implementation that is currently done by Doug Davis. I could imagine that we moved some of this over, but I don't know when and of course it depends on those two when we do this and if we do this. Hey, thanks for the talk. One of the main event registry out there is event catalog.dev, I believe. Are you talking with them to maybe fit based on these cases and existing like experience or whatever or in any case? But short answers, no, I'm not sure. I think I heard about them one or two weeks ago for the first time, but I'm not sure if I'm confusing it. Are those the ones who generate documentation for events essentially? Is it that? In some way, yeah. Okay. Yeah, I learned about this. I found it quite interesting, but I just recently learned that it exists and then we have to discuss. Thanks, thank you. Okay, then again, thank you for spending that time on the Friday afternoon with me. Have a safe trip back home. And yeah, also au revoir et bon voyage et à la prochaine. Yeah.