 So thanks for spending the next hour or so with me and having a shorter lunch. I'm Hadrian. I've been involved in the integration space for more than 20 years. I'm a committer on a few projects at the Apaches of the Foundation, ActiveMQ, Camel being some of them, Brooklyn, Ode, others, TinkerPop. I'm a member of the foundation and until recently I was the VP for fundraising as well, so I'm involved in the foundation as well, not just the projects. I've been doing open source for more than 15 years, so if you have any questions for me, you know how to find me. So I'm going to talk about the project we started in the messaging space. It started about two years ago and the messaging space got very commoditized. Most of the messaging products were built between 2000-2005 when you got MSMQ from Microsoft, you got IBM and Oracle with their, well, it was BA I think at the time that started it, with their ESBs and messaging solutions and it got commoditized pretty fast. I'm going to talk more about it. So the question was what can you innovate now in 2015 at the time in the messaging space? And we were looking at, obviously the thing you look at is scalability, right? So most of the projects were scaling up actually and you had projects like Kafka and RevitMQ and Erlang, right? They were trying to use resources better, to be faster. Actually even ActiveMQ had a sub-project called Apollo that was much faster than the ActiveMQ core a few years ago. So a lot of people focused on scaling up and we thought there are some opportunities to scale out, meaning putting more brokers and serving more traffic by basically producing your broker configuration at scale. And when I say scaling out, I don't really mean just having more brokers because that's a feature that ActiveMQ supports for, I don't know, more than five years. It's called a network of brokers. What I mean mostly is supporting a large number of applications, messaging applications running in the same brokers. I should have started by asking how many of you are at least intermediate with messaging systems and ActiveMQ? Oh, so that's awesome. And this presentation was meant to be less technical, although we can make it technical if you have questions, and to be more sharing our experience, seeing many messaging deployments of what things work and what works less and what you have to do in order to have a scalable and robust messaging system. So I was thinking, if you have questions, because it's not a large audience, we can probably address them while you have them. I don't know. We're going to see how it goes. So that's how the journey began. And we thought that if you have a messaging system, what things really customers look at in production or, you know, massive users look at? And the first one is security. And ActiveMQ already had good security characteristics, so there was not a lot to innovate there. The question was how you use it, because ActiveMQ, like many other projects at Apache, are both a framework and a product. People see the brokers in ActiveMQ, for instance, and they take them the way they are, not realizing that actually a lot of things underneath can be rearranged in different ways, the elements of the framework to obtain brokers with different characteristics. And that's something I wanted to show you today as well. So in the security area, we actually had to constrain ActiveMQ, because ActiveMQ allows for anonymous connections, and we wanted to be secure, so we only support authenticated connections. So we enforced having a username and a password, which is what JMS requires for authentication. And then the other thing, this is probably the most interesting thing we did, is the multi-tenancy, which no MQ system that's Enterprise Glass does today. Sorry about that. Including the commercial ones. So I'm going to talk more about multi-tenancy because that's what we did. So for those of you who know ActiveMQ, which is most of you, what happens if you have two different messaging apps written by two different groups and they send messages to the same queue and use the same broker? Basically, messages can cross from one consumer of an app to another consumer of another app, right? So what do you do then? You basically have two options. One is to make the two groups who build the messaging applications to talk to each other to make sure that the names don't clash, right? But that doesn't scale because if you write 4, 5, 10, 20 applications, the risk for mistakes is growing. And the other thing that is quite common, which is even more costly, is to deploy different brokers for different messaging apps. And that becomes sort of a maintenance operational nightmare, right? So what we said is that something we can do to have the same network of brokers support multiple messaging applications and not really care that they are sending messages to the same queue and be able to partition somehow so that the messages don't clash. Is that clear what I'm saying? Should be. Okay. Another thing was scalability. We wanted to be able to add more brokers as there is more traffic and we're going to talk more about that. And then something around governance. And we did something interesting over there as well. Then we said, actually, we don't need to use ActiveMQ. We can use whatever. So we looked at ActiveMQ competitors. Some of them are from Apache itself. One is Kafka, which is very popular for streaming. It's very fast. Cupid. Rebit and Q started at Spring Source. I think it's a pivotal right now. Then there is DDF, which is used mostly in the government space. I'm not sure if you're aware of that. It's also a distribution kind of like service mix based on ActiveMQ, CXF, Karaf and ActiveMQ. Then there are some older ones that you may not be aware of anymore. WSO2, they were popular in the federal space a while ago, came out of IBM actually. Some people from IBM, ZeroMQ. There are the commercial ones, but because of licensing, we didn't even care about those. And all of these don't have multi-tenancy characteristics. The new ones, the cloud services, do have some sort of multi-tenancy characteristics, but they are only running in a specific cloud. They have proprietary APIs, which provides some lock-in. So again, not really a good fit, plus it wasn't really what we wanted to do. I didn't mention the Google Cloud Pub Sub. That's another important thing there. They are doing some really cool stuff as well. So in order to figure out what we want to do, we actually went back to the SOA principles. And back in the early 2000s, people were talking about SOA, like people talk about microservices today, right? It meant whatever people wanted to mean. And only around 2009 or so, some people came up with the SOA manifesto, where they tried to focus a definition of SOA around the business value and the agility and coping with change. And that's something that appealed very much to me, because in my experience, I keep saying this a lot. Code that is not in production is like one of these cruise ships here staying at the dock all the time, right? It's occupying real estate. It's not useful. It's more reliability than an asset, or planes are the terminal, right? So every business has an incentive to move the code they produce as quickly as possible in production to produce value and make money or help providing feedback for running the business or whatnot. So that part of SOA appealed very much to us, so we used that part. And you're probably very aware where I'm going to go quickly over this stuff about the course of concepts, like loose coupling and service contracts, basically APIs lately, composition. Camel is great in that area, by the way. And we wanted to look more at connectivity, which is one important part of SOA and the ESBs and all that stuff that are still in use. Talking about connectivity, there are two styles of connectivity, basically. It's the classic Bob talks to Ellie scenario, and you have the choice of synchronous communication or asynchronous communication. Synchronous doesn't scale very well. It has a lot of advantages. People are shaking heads here. We can talk about that. But asynchronous messages, when you send bulk messages, they scale much better. And we can take all sorts of examples, even from the real life sending regular mail, snail mail. The problem with the asynchronous messaging is that it's not very interactive, right? But it scales much better. So normally any company or any organization is going to use both and is going to use them for the benefits they provide in a specific context. So our focus is more around the asynchronous communication. And we had to choose some way to deploy that. So we looked at service mix, which is the Apache PSB, basically. You probably know about it. It's basically a combination of a Karaf container and an OSGI container, ActiveMQ for asynchronous communication, CXF for synchronous communication, STAC and Caml provides a mediation, routing, EIP-based sort of framework. Why we use OSGI, for a few reasons, a very robust platform. The security part, we got a lot out of the box. It was very appealing to us. The provisioning part, the logging, even management, the dynamic configuration. So we thought it provides a lot of the features we really needed. And even for ESB distros, based on the page service mix, there are quite a few. Talent has one. That's quite popular. I mentioned EDF before. It was mostly in the governance space in the U.S. And RedHead also has a very popular distribution. I think it's not called JVOS Fuse, but Fabric or Fabricate, something like that. RedHead people here in the audience will know better. But anyway, RedHead has a distribution. There are some older ESBs that probably nobody cares about, but anyway, they are open source as well. And you can do it yourself, which is kind of what we did by assembling the same projects I mentioned before. So that brings us to ActiveMQ, which is really the workhorse of the messaging platform. And ActiveMQ has a bunch of features that are very useful. It's based on JMS-11. It's been mature and robust for at least five, six years right now. I think it's mostly used in production, open source messaging platform. It has all sorts of goodies for, you know, even streaming, governance, stuff like that. On the availability side, I mentioned the support for multiple topologies. And that's something we really pay close attention to. Everything is pluggable. Persistence is pluggable. The transports are pluggable. So when transport became popular, ActiveMQ adopted them. ANQP is one of them. MQTT is even newer. There is also a stomp that's not mentioned here. So you can use that from your JavaScript apps in the browser. So anyway, a lot of good features in ActiveMQ. Another interesting thing for ActiveMQ is the fact that even though it's written in Java, it has client bindings in a lot of other languages. So you can have a JMS broker that's ActiveMQ, but your application could be written in Python, could be in .NET, could be in C++, JVM-based languages, of course. I mentioned JavaScript in the browser and so forth. That was a really cool reason, basically, to use ActiveMQ. And then I mentioned the topologies. So when you have a broker, no matter what, it's not going to scale infinitely, right? So your traffic at some point is going to exceed the capacity of your broker. So you're going to have to put multiple brokers for different reasons. Be it for resiliency if you want something like a master slave or some other configuration, or just the fact that the traffic is too high and you have to put other brokers. And in the way you configure your broker, basically, you can achieve one of these quite popular and known topologies from the fully connected mesh or hypercube hub and spoke was very popular. And they all have advantages and disadvantages. So don't believe that one is better than the other. I saw some users' large system in production who actually measure before they make decisions on how to do their technology. That's very smart. So anyway, I encourage you if you use ActiveMQ to kind of do the same, take a look at different topologies and decide what works for you. But the fact that you are able to build different topologies was something that was really good for us. So we decided to go down this path. And this being the introduction, but before I continue, I want to show you a bit of a demo and show you what we did. Unfortunately, the resolution is not going to cooperate very much. We have very low resolution. And that uncovered a few bugs with the GUI. But anyway, that's not going to work because I had to see this thing. So I mentioned multi-tenancy. And one thing we did was, okay, if you have a large number of applications, who's going to own them? What's going to happen there? So we said, let's use ownership identity management model that's similar to the one used by cloud-native applications today. So as an example, let's take GitHub, right, where you have a bunch of users over there. My mouse is sliding. That may belong to different organizations. And users and organizations can own resources, which in GitHub's case are repositories. In our case, they are messaging applications. And we came up with this GUI in which you can organize your... I mean, users get accounts, they create organizations, they add other people's organizations, they create projects and all that kind of stuff. And we came up with this organization that you cannot really see because on this side, this is going to be a bit of a nuisance. I'm really sorry. So somewhere here, we should see that the Galactic Empire is our current organization and I'm logged in as the Chancellor Palpatine, which is a fictitious sort of user. And I have two messaging apps called Text Aurora and Death Star. And I can go and take a look at these projects and get some metrics and stuff like that. I'm going to show you that in a second. But I also have a set of credentials that I'm going to talk about a little bit. So in the Text Aurora case, nothing has been sent recently. There were some messages early on and we can look at the other stats down there and you can see that there was some traffic over here. And if I look at the credential list, there are some credentials over here. I think this one is the one we look at, the AX something and the one starting with the capital C. I can actually create new credentials. Call it what? Miami. And I think this is going to be just a description. It's not the name of the credential. And it's going to create a new credential and this is going to be the user name and the password and I can copy it to the keyboard. Once I close this window, that user name at the top is going to be preserved and the password is gone. We don't keep it because we don't want to be hacked. We care about security and stuff like that. It's up to the user to keep this password and these credentials are going to be used in the JMS app as the connection credentials to authenticate with the brokers. Does it make sense? But we don't keep them. We have a SHA and the brokers can verify that the credentials are okay and they don't really keep the password. So once I do this, I'm going to have to keep the credential here. So I saved it. This is the credential I had before. And now what I'm going to do, so I'm going to send here 100 messages with this credential. The queue is going to be, I think, Miami. Hello Miami or something like that. I'll show you where it's coming from. And I'm just going to send these messages assuming the network works. I'm also going to receive, but let's not receive 100, let's receive only 70 messages or whatever the number. And let's use the credential I just used. So this is going to start consuming stuff and you're going to see that stuff over there doesn't really matter that much. What happens though, if I look here back in Pax Aurora, is the network operating? We see that there were 173 messages. I don't know, 177 we received that all the three others are from. And we can see them over here. We can zoom in, we can do stuff, analyze whatever makes sense, right? So if I look at the traffic, I can see the traffic per credential. This is the one that we used to send. Active credentials one. Oh, here we got 100 just in this time window, right? Looks like I'm going away from the microphone. Sorry about that. So I'm not sure if I'm not running out of time. So if I use another credential basically from the Death Star project, you're going to see that I'm going to use the same queue but it's going to go to the other project because we wrote some extra plugins for ActiveMQ that are not in the ActiveMQ distribution that do some namespacing. So based on the credential, ActiveMQ has a plugin that knows what project this credential belongs to and creates some sort of a namespace for the queues in that namespace. So because you use different credentials but with the same queue name, it's going to that queue in that namespace. So does it make sense? And here, actually, I have a small client. It's actually the same client that did run some traffic today. There are some 58,000 messages in the past hour and if you want to look in the past, I don't know, three hours or six hours, it's about one million and a quarter, just one client send messages in the past four or five hours. I think I'm running out of time because I want to leave some room for questions so I'm going to go back to the slides but I think you got the idea. So again, what we worked on is achieving this multi-tenancy that you kind of saw. The global governance, is there something odd that anybody noticed in the GUI? Nothing. There was no broker. We didn't talk about a broker at all. You don't know how many brokers are there and as a user, you don't care. You only care about your messaging app, how many messages you send, how many messages you receive. There is also a REST API that can give you some metrics. So all the administration of the messaging system is left to somebody else that you don't care about. You only want to see your messages. Another thing that doesn't exist in ActiveMQ and all the other messaging products you've seen before, we can show stats how many messages were sent and received per credential. So it is a good practice, for instance, to give different credentials to different apps. I didn't show you but you can also revoke credentials. There is kind of obvious, right? So if you don't like something, you can revoke just that credential. Or if you see that somebody is doing something odd, you can reroute traffic through some other brokers so you can investigate what's going on. But from a user point of view, from a user of the messaging system point of view, kind of like SQS and the other cloud services, you don't really know how it's operated, how many brokers they are, where they are distributed and so forth. So we took the same approach. There is a destination sharing feature that we started to implement a few months back that's very interesting as well, that is not present in all these messaging services, including the cloud ones, including things like SQS. We wanted to see, can I actually publish my message stream outside my application? I want other applications to be able to receive my messages, but I don't want to manage the credentials for them. I don't want to give them credentials and for them to ask me to revoke them and all that kind of stuff, and I don't want to give them access to my project either, right? I'll add them to my organization, for instance. So what we added is a feature to basically share a destination, kind of the way you share pictures in, I don't know, whatever application you use. And then they can be shared publicly with everybody. Let's say I have a very neat weather application. I want to share my weather events and I publish them to my destination, but then I share the destination with other people publicly, or I can share them with a particular tenant or a particular application. And other people basically say that if I can get messages in this destination that I can process them, right? So there is a configuration aspect now in the broker to adapt the two and say that this guy shared his destination and this other guy subscribed to this shared destination. So that's how you allow them to manage their own applications, but inside the broker, you can imagine a simple camera route, for instance, although there's no other way we do it, to adapt between the two applications. Does it make sense? That we thought was pretty neat. For identity management, we basically talked about the model, so I'm not going to spend too much time on that. For the broker topology, this is an interesting thing. So once we started to look at it, we realized that actually, I think all of the messaging deployments I've seen with one exception and that was a small exception, all the topologies were homogeneous, meaning that all the brokers looked alike. Even if it's a master slave, they look the same way. It's just that when the master died, the slave becomes the broker, but it's essentially the same thing, right? But it doesn't need to be the case. There's nothing in active MQ that says that all brokers have to be alike. So we came up with a heterogeneous topology in which some of the brokers don't carry client traffic if you want. They have other roles in the messaging system. For instance, we have this master broker that receives all the advisories from the other brokers. Do you know how advisories work? No? So in a network of brokers, when you have multiple brokers and your client connects over here and the producer and the consumer connects over there, how do they know the brokers to send the messages from here to there because that's where the consumer is? So what happens is every time there is an event inside the broker, like a connection gets created, a producer or consumer gets created, a destination gets used, stuff like that, they send messages to each other, which are called advisories. So then brokers know, aha, I don't know exactly who's listening to it, but I know that this broker that's connected to me wants that information, right? Because the advisory was propagated down through that topology links that you saw in the other slide. But anyway, we said that this is too chatty, just this we can talk about hours about. We said let's not do that. Let's have just one broker that receives all the advisories and creates a graph. We use the patchy tinker pop for that, which is a graph database, and it's the basis for IBM graph, for instance, and Neo4j uses it. So we said let's use all these advisories to create a map, a graph of everything that's going on the messaging system. All the brokers that are there, the connections that are attached to them, what credentials they are used, and stuff like that. And based on this graph, make decisions, reason, how to optimize our messaging service, okay? Then we got what we call the gateway brokers because they are the gateways to the messaging system. These are the brokers that receive messages or exchange messages with clients. The first thing they do, obviously, they take responsibility for the message. So they are persistent. That's hence the database thing there, or the persistence store. But if you have brokers coming up and down all the time, then what kind of URL are you going to give your clients? Because your broker can come up and down and you don't know if he's there. You have to have something that's kind of stable there that is used for the client to make a connection. And these are what we call the discovery brokers or de-brokers, use letters for them, which are brokers that are advertised in the DNS. They do not carry any traffic, but these are the brokers clients connect to. They authenticate. Based on the authentication, they use credentials, right? The discovery brokers ask the master broker, where should I route this guy? And right away, they force the connection to fail over to one of the gateway brokers that thing is assigned to. Is it crazy? Too complicated? No? Then you have the producer and consumers. We also have worker brokers, things that, let's say you want to do in-flight message validation or stuff like that, which is not really messaging, but value-added processing if you want, down the messaging chain. For instance, me as an application, I'm subscribing to a stream, but I don't want to get all the stream. I don't really care about it. I only want about some subset of it based on a filter that I can define. I want that filter to run in the messaging system and me only get the messages I care about, not get everything and do that filtering myself. Plus, you can use this kind of feature for transitioning from a version to another and the depth things in the messaging fabric, stuff like that. So these are different kinds of brokers. So as you can see, by leveraging the fact that you can have brokers with whatever capabilities you want, you can have a heterogeneous topology that I think serves you better. Then for the governance, I mentioned that already. So we don't really talk about the brokers from a user point of view. We talk about the messaging app and how many messages are in flight, how many were sent, received. Another thing I started to mention, I don't think I finished, we don't use JMS because JMS is kind of limited and it's also slow at scale. We basically import everything, the metrics in Elasticsearch and we have indexes and we have an API that basically makes queries on it and that's what we use for our metrics. So our governance, our management is done by a combination of the data in the graph database in TinkerPop and Elasticsearch basically. For administration, there is a different view. These are the guys who are in operations and they look at the graph. They see the brokers, as I said. So we're working on the rendering part. That's why you don't see the real thing right now. We did export the graph from TinkerPop but we use a tool called Jeffy which is a standalone tool to visualize it and present it this way. So it's not very pretty. We're still working on it. But again, what's important to note is that like SOA kind of expects us to have separation of concerns, administrators have a different view and they don't really care about how many apps are there and what not. They only care about the clients that are connected, right? It's an adaptive topology. So once we got the ability to deploy brokers on demand and remove them on demand, which we thought is pretty cool, we said then, why do you have to have long running brokers? Pretty much all the deployments I saw have long running brokers. Those of you who are active in Q is not the same, the same case. You have brokers running for days and months and what not. So we said that if we can have so many brokers then why not have a broker run every, I mean for only eight hours and then it goes away. And interestingly enough, it became sort of a security, sort of advantage in the sense that if one gets compromised who cares because it goes away eight hours regardless, right? I think I'm forgetting a lot of stuff that are cool about this topology. The layers, so we also realized, okay, to do all this kind of stuff we need a lot of other services. We needed first of all the machines to run on. We run, we have I think 11 bare metal big servers in Germany and a few in the U.S. So we have this infrastructure as a service and then we needed some tools to automate the deployment. We used Ansible, now we use Rancher. So I mentioned service mix. We have our own distro like service mix, which is the container in which Karaf runs. But actually what we do afterwards, and I'm going to show in the next slide, we re-package it into a Karaf container that we deploy and actually what gets deployed is the Karaf container that's, sorry, a Docker container that's already has the Karaf running inside configured and that gets deployed on one of the machines that are running bare metal machines that are running Docker. So we use, as I said, Ansible, Docker, Rancher, and we have some other tools. That's for the platform as a service layer. And then we have a number of services. We mentioned, for instance, the fact that we need to manage the credentials. So we have LDAP servers. We have elastic searches, as I said. We have, we use Greylog, databases. We have the GUI. Quite a few other systems, kind of like an infrastructure on which this messaging fabric works or relies on. Also, in order to deploy things fast, I mentioned in the beginning that everything that's not in production is actually a waste or a liability. We have multiple environments, development, staging, and production. Everything gets versioned, including the configuration. So you're able to come and figure out how the messaging system looked at the particular moment in time. Things get built. They end up in Archive. We don't use Nexus because we like Apache, right? We have Jenkins that does that. You could use GitLab or other tools for a continuous delivery pipeline. Things go in Archive. From there, as I said, they get repackaged into docker containers. We have docker registry, kind of like docker hub, but we host it in which you put the docker containers. Rancher has catalogs, sees them from there. We can update them from there and so forth. We first deploy them in our development environment to test. Then if everything works okay, we deploy them in a staging environment where more tests come in, and then it goes in production. Obviously, there are things that go just in production, which is just configuration for adapting the structure of the messaging system. So that's what it ended up being. And in conclusion, what's in the name? To have a robust messaging system is not just the product or the tool, the project that does the messaging active MQ in this case. In order to deploy something robust, you have to look at a lot of other aspects, and you end up building something more complex that looks like the stuff we built. The social implications of this are that you as engineers, integration engineers, should be familiar with a number of other projects and know how to use them to your advantage, and hopefully even contribute to them because, hey, we are a patchy. So that's pretty much what I had to say. And I wanted to leave some room for questions. I assume there are going to be quite a few, but if not, you can have a coffee break. So thank you very much. Either you got everything or yes. I'm not sure what the definition of broker scaling is. It's not really the brokers that scale. It's the number of brokers that grows or shrinks. And basically, if you know the... One thing I didn't mention. So you use ActiveMQ, you know the XB configuration, write the XML configuration, and everybody has a file that is in some location with that configuration. Who knows that there is a... I think runtime configuration plug-in, it's called, it's in ActiveMQ for at least five years, that once you change that file, it sees the new timestamp and reconfigures the broker at runtime. Who knew about that? Okay. I presented on that last year, by the way. So basically, you can reconfigure a broker at runtime. That's one. The second one is that you know the failover that allows you to move a client. There is also a plug-in for rebalancing clients as well. So the element that makes two brokers configure, work with each other, connect to each other, is the network configuration, right? So you can change the configuration at runtime or redeploy the broker with a different configuration of that network connectors. Does it make sense? So that's how you can edit the topology at runtime. Make sense? Another thing that I'm not sure you knew is that XB, which usually people don't put, just the file, but technically the URL, it's XB and call and that thing, that expects a URL to come after that, which is again usually a file, but it could be HTTP. So what we use, all these configurations are not stored as file locally with the broker. They are served via an HTTP server from one single location and it gets generated from data in that graph. So the configuration of the broker looks for us, XB and call an HTTP, our configuration service, and then is the name of the broker in there. They know how to look at it based on a convention. Did I answer? You had the question too. Oh, oh, oh, yes. It's a funny name. So we had to call it something because ActiveMQ is an Apache brand and this started pretty much like as a demo and we had to give it a name and we thought, well, it's a messaging fabric and we thought it's elegant and it's smooth and it's whatever and it ended up being SilkMQ. So we talked, we want to donate most of the code because it was built as open source to service mix. We already talked to them and I think it's going to happen soon. At one presentation where I had this kind of demo, people also said that it looks kind of expensive, you know, Silk, I'll say, yeah, maybe. So it's just a name. It is active and actually this is just a set of plugins that work with ActiveMQ. It can be deployed with the Telen-DSB, with the Red Hat thing, with DDF, with Savoar Tech has a thing called ATOS, I think or something like that because it's just basically a number of ActiveMQ plugins that are based on some conventions and some other services like LDAP and stuff like that which you have to wire in, which also makes it a bit complicated to test in an open source project because you rely on this infrastructure to exist. So, yes. You could use Kafka, actually I talked to Jay Krebs a couple of weeks back. Kafka is not GMS, first of all. Kafka doesn't support transactions. Kafka is very fast. So there are advantages and disadvantages. So you cannot use... So GMS has two domains, right? The point-to-point, the queues, and the PubSub, the topics, right? So, topics don't have... or PubSub doesn't have transactions. So you could use Kafka for that. But remember, what you see over here, you don't really care what's underneath. So when you connect to the messaging fabric, maybe some messages are going to go over Kafka. How do you know? They go over Tuxedo, maybe who knows? Maybe they go over Tuxedo at some point, hitting a legacy app and you get responses and you think it's a new, really cool app. Do you see what I'm... And that's the point of the messaging app, or messaging fabric, to adapt different messaging systems. I just talked to Kleber before these things. So, Red had just announced an AMQ that has a different take on the same problem by combining their messaging services, maybe he's going to talk more about that after me. But I'm not sure if I answered your question or good enough. Oh, absolutely, yes. And you can use it, too. I mean, you can steal from it as much as you want. Any other questions? Yes, no? Is that... Did you end up... Is this more configurable or easier to figure out why you don't want to wait? This is an interesting question. So, once we realize what we did, which kind of shocked me, to be honest, with the sharing and subscribing, then I realize that actually, it's not that if the guy shared and the guy subscribed, I can do a pass through of the message stream from here to there. I actually can put the business process in the middle. I can put the camera out, I can do whatever stuff. Who's going to do that? How do you attach it to that? Okay, you can use the same model to create some sort of a marketplace. So, people create their own business processes or camel routes or whatnot, and people would say, when I'm subscribing to this destination, I don't want you to just send to my internal destination. I want you to first apply a business process and then do that. So, there are a number of things you can start doing with it right now that we realize are possible that are not really possible with ActiveMQ out of the box. So, it's fun. Who knows where this is going to go? If you're going to see my presentations for the next two years because this is really fun, you kind of know what to expect. So, that's boring. I saw it before. I'm not going to go. Also, how does Artemis benefit from this? It gives you a lot of work. Ask Lemon. So, I hope I gave you some ideas. I don't know. So, there are also some other things that we can demonstrate with Disconnected because the other end could be not just a client, it could be another broker, another messaging system that's occasionally connected and stuff like that. So, anyway, thanks for stepping by.