 And someone came up with what SOA actually means, so there was state-of-the-art, one option, Sir Baner's Oxley Act, State of Alaska, Yubecha, Sexwheel, Overdragbar, Andoening, and Sega of America. I mean, who here knows what SOA actually means? Take a hand up if you know this. Right. I mean, a few. It should be really well known because it's the internet. I mean, you know, service-oriented architecture. You put stuff somewhere, you find it. It's like you want to buy a pizza, so you call someone and say, Where's the best pizza shop? And someone says, I'll put you through. And they put you through, and a pizza arrives. Except it's all digital. So it should be really easy to do because there's no pizza. It's just like, you know, a package of data. And pizza shops can come and go anytime. And since internet is all about information and communication, it's a real shame that messaging, which is the core of this, is so poorly understood and so poorly made. It's really, really expensive. In most cases, it's mostly proprietary and closed and locked down. There are some open source projects, and mostly they're kind of blech. And there are some protocols, and they're kind of blech. And it really is like the last big, boring, complex, and painful area of computer science. I think we solved databases about 10 years ago, and now everyone can do SQL, and it's a child's play. No problem. So messaging is in that stage of moving from enterprise technology to something that anyone can use. And today, if you can't connect pieces together across the internet, you're an incompetent developer. You can't actually make big applications. This is what our job is. It's connecting pieces in interesting ways. So I think big companies actually like it to be complex and painful and boring. It's actually in their interest. It keeps you a competition. It lets you lock in customers. It lets you charge profits. You have web services architecture, and you have 55 protocols to learn, and they're all complex, and they're all really huge, and of course it's expensive. But open source doesn't work that way. Open source works by making things simple, and open, and cheap, and reusable, and generic, and everywhere. It doesn't work by making things complicated. So this is the thing. How do you make things simple? Simplicity is very hard. It's a common idea people have that you start simple and you end up complex. It's actually all the way around. You start complex, and if you're very lucky, after years of work you end up very simple. And look at SQL. It's a good example. SQL systems from the 90s were big, complex. You have Oracle, which is a nightmare. Today it's SQLib. It's a plug-in library which you just call. It just works. That's what technology should do. It takes a long time though. So messaging is something that every single project invents. In my company we do custom projects for a long time, and we find ourselves every time reinventing messaging. There's a factory receiving orders from an SAP system. Well, there's some software that exports orders from SAP and then sends the factory and then processes them and sends back confirmations within messaging all the time. And every team does this, I think, and we all do it badly. That's the funny thing. It's a very easy problem to try to explain. The question is very simple. I want piece A to talk to piece B. And piece C and piece D. That's easy. But actually doing it is very, very hard. Doing it properly is very hard. And it's hard because you've got to get the addressing right. Where is piece A? Where is piece B? What if they move? What are they called? You've got to get the queuing right. What if piece B is gone temporarily? What happens to its messages? What if I have several piece Bs? How do they share the work? And the answers take time to develop. Reliability, transport systems. What protocol do I use? Is it TCP? Is it SETP? Is it multicast? What do I use to connect the pieces at the lower level? So the right answers are hard to get. And in fact, until recently, no one had the right answers. That's my theory. Lots of wrong answers. Big, expensive wrong answers. Fantastic. So a few years ago, I think because people got really fed up by this and by people, I mean large companies, users of middleware messaging, actually began to push develop a new standard called AMQP. And AMQP is very interesting. It's worth studying. I think it's the first open standard that actually tries to address the generic problem of messaging. And it's a very generic solution. You could use this for anything almost. It is a general answer to addressing, a general answer to queuing, a general answer to naming pieces. It's portable. It has no hang-ups about what language to use or what data format it's... Blobs move from A to B to C. I guess I was the first author of AMQP, so I kind of love it. But I think it was really an interesting protocol. And it's been adopted by several companies. There are, I think, five or six implementations now. And they're being used in anger, in real, in large deployments. One of our customers is Dow Jones Company, which now moved their industrial average onto AMQP backbone, which is quite impressive. They're doing something like... I think it's 100,000 messages a second, and that's constant the whole time. Full time. On and on and on and on. So they pull in data from Reuters, from NASDAQ, from Chicago Options Exchange, and it goes through a server, which filters it, selects it, and then it gets published out to different clients, which then bring it down, and it computes, amongst other things, these averages. So you have a protocol designed by users in small IT firms, which is very good. It makes it quite reasonably nice. The website is amqp.org. The website's kind of disappointing, as you'll see. Now OpenAMQ, which is what this talk is going to be about, but that's a very small part of the whole thing, is our AMQP server and client. We began making this together with AMQP about four years ago. It's, I would say, industrial quality software, very serious stuff. It's easy to use, but it's also reasonably painful to build large build system, multi-threaded, designed for big use. But yeah, download, build, compile, run, fairly straightforward. It's fast. It could be much faster, but AMQP has issues there. And it's reliable. Like I say, it runs and runs and runs, and we spent something like three or four years just making that work. Very hard to make reliable software. You get memory leaks, you get little race conditions. If it's multi-threading, it's horribly difficult, but we got that. We have a whole toolkit, in fact. We had this crazy idea of writing it in C. C is the worst possible language for serious programming. It's really a terrible language. I love it, in fact, but it's really terrible. It's very simple. It's not like Pearl. Pearl, you learn Pearl, you write your program, you forget Pearl, and you go through this learn and write and forget cycle every time, and it's really painful. C, you remember C. It's very simple. But when you write C, every line of code is really painful to write. To write huge amounts of code. I think that the size of open AMQ in lines of C code is approaching one million. And that's a lot of code for a small team to maintain. So we use a toolkit, which is a meta-programming toolkit, which is really funky. Meta-programming means that you actually write code that then writes code. And what we do is we write code that writes code that writes code that writes code that writes code that writes code. It gets really crazy. But it does actually produce a lot of code very cheaply. The actual, so a million lines of code for open AMQ, the meta-code is about 150,000 lines of code. And of that, I think only about 70,000 is really written by hand and half is generated. And then that produces all the C code. Meta-programming is a way to write very, very large systems which have a kind of a, you know, guaranteed level of reliability. When you generate code, you know what's in there. There's still handmade code in there, so there's still issues, of course, but they can be fixed. So that's on www.openamq.org. Now, we built an AMQP for Geoffrey Morgan. We then built Open AMQ for several clients. We delivered that, and then we looked at this for a while, and then we said, this is still too complex. People aren't adopting it. It's look at AMQP.org, look at AMQ, look at Open AMQ, try it. You'll find it too complex. Try to write a client that speaks AMQP. It's a protocol. It's written, it's documented. It takes months. That's not good. I don't like that. For me, the target audience for technology and products isn't the guy sitting in a bank with a year and a half to write a product, you know, to write an application. That's not fun. My target audience are people like me, open-source developers who have no time who want to download, try it, and it works the same day or else they give up. And for me, if you don't get AMQP and stuff like it and this way of doing messaging into the hands of, you know, developers without an enterprise, you know, financial system to back them, but just their own time and effort, then it won't work. And we will see the domination of messaging by proprietary products and by really second-class answers. So, I've been working with some guys since August on making AMQP simpler, simpler, simpler, simpler, which is quite a fun project. There are other problems with AMQP. It has some flaws, but we were still learning when we made this, you know, it's not perfect. We discovered something called REST. Now, REST is fun. REST is something which has become very fashionable in the last year or so. But in fact, it's the underpinning of HTTP. It's a very straightforward way of working with resources. What REST does is it says, look, we have a server with stuff and clients, and the clients can use create, read, update, delete patterns to work with the server resources. It's very simple. It's not complicated. The state is very clear. You know where things are at any point. You can redo, if you're not sure, you can try again. Delete, okay, delete again, no problem. So, it's a very robust protocol, whereas most protocols are very fragile. If you get it wrong, it breaks. REST is very tough. And it's a pattern which works over large scales and which is easy to use by people who don't have much time for the fine stuff. I quote from a user who was comparing REST to SOAP and XMLRPC, and he said, moving to pure HTTP allowed us to throw away the code for the XMLRPC service in brackets. I love throwing away old code. And so, I was saying, look, let's try and make AMQP work over HTTP. It's obvious. I mean, the patterns don't quite fit, but HTTP has, you know, everyone can program HTTP. I go in Perl, I say, I pull down WP and I say, you know, do a request, click response, and I get something, and I do it in five minutes. So, okay, this was the challenge. Getting AMQP working with HTTP. It took us some time. It's now there. It's called REST-MS. And what this is, it's a very clean REST, RESTful implementation of a messaging protocol which actually maps purely onto AMQP. So, your clients, your applications, speak REST-MS, which is HTTP, put, get certain resources, which I'll explain in a second. And it's just HTTP. It's just a web client. It could be in JavaScript, it could be in Perl, it could be in Python, Ruby, whatever. And it speaks to a server, which then maps that onto AMQP and it speaks to an AMQP server. And back and forth. So, it's like a proxy between AMQP and HTTP. What this means is that you can basically get from bare metal, well, bare programming language metal, if you like, onto working messaging application in a matter of a few hours. It's less. That's on www.restms.org. That's an open protocol spec which anyone can contribute to. You know, some things with AMQP I don't like is that the protocol is managed by a small group of people. It's very exclusive. If you want to contribute to it, you can't forget it. They want to accept contributions. I don't even know what's happening in version 1.0. It's happening behind the scenes. This is kind of annoying. If it's an open protocol, it should be open for anyone to contribute. So, with rest as the way it is, if you want to have an opinion on it, come with fixes, it's all there, it's all online. I was going to show an example, but very small. Basically, it's six lines. I'll read it at you, because who does not know HTTP in a modest sense. Okay, no hands, that's good. So, it starts and it says post. You know what post is, right? So, it says post slash restms slash domain slash default. This is saying, speak to my default domain object and make it create something. So, the default domain is like the factory for other objects. Content type, application slash restms.xml. That's just saying, I'm going to send you an XML document, hang on a second. Then it gives a slug. A slug is like a name, it's a slug, two points fortune. That's the header, three lines of header. And then comes in an XML document, which has brackets restms. Feed type equals service, close brackets restms, that's it. So, it's a little XML document being sent to a factory, which is a domain. I'll explain these words in a second. This tells an object on the server to create a new object. So, the server does the creation of objects and then it comes back with an HTTP 201 created with the location, which is the address of the object, to the URI. And now the client application takes a URI, does stuff with it. When it's finished, it says delete on that object. So, it can do read, update, delete on that object that just got created. So, the whole structure is self-navigating, created dynamically and navigated through URIs. This is very, very, very nice. It means that you can completely partition work between applications without any kind of notion of security or, you know, training. If you know your URI, you can access it. If you don't, you can't access it. You can have public and private resources and clients don't have to invent anything. Clients get information from the server, they use it and they give it away. Okay, now I'll explain very briefly how they work with MQP and REST-MS as architectures, how they work. It's actually quite simple. You have a board and you have chalk. So, the problem is you have applications here that want some kind of a service. They want to get pizza and you've got restaurants here that have pizza. They all have pizza. It's digital pizza, so there's no real pizza. And there's someone in the middle who can actually tell you where the restaurants are and how to get the pizza back as in forwards. So, you kind of say like, okay, I want a pizza. That's like your address. And someone here says like, yes, we have pizza. And in the middle, the request and someone's statement of we have pizza get matched up and the request for pizza comes through and it's pepperoni and then that gets sent back a pepperoni pizza. So, if you instance later this pizza restaurant burns down in a ball of fire because the guy left the stove on too long and his wife was shouting at him. And this one is now visible or it was visible before but didn't pay attention to. So, the thing about services is that they come and go completely randomly. Certainly, as a user here, you have no idea who you're talking to. It's indirect. It's abstract. This is very, very important. It's easy to make architectures. The problem is, things change. And in all IT, it's change which is the big enemy. Stability is not an issue. Anyone can write a program or compile it for correct code but change happens a lot. Here you can change stuff completely arbitrarily and that's the magic of messaging. You can add and remove pieces and they find each other dynamically. They do their work and that's it. No state necessarily shared between them. And there are different patterns. For example, in this pattern the message goes back through the central router but in fact that's not necessary. You can actually do very nice peer-to-peer messaging where you use the central point for address lookup and then they talk directly and if you know something like SIP which is the voice over IP application it works like that. A central registrar for who's online and where they are and then peer-to-peer communications. And we do this in some of our products. There's one called ZeroMQ which works like this. It's very nice. Much, much faster than MQP but MQP insists on everything going through one single central point. Now, the key concepts that MQP I think introduced and which work very, very well are the key concepts of an addressing thing here which we call an exchange and queues which connect to exchanges through bindings is a queues. I don't know how many ease here. Okay, that sounds about right. So Q binding exchange lets you create a queue that takes care of the asynchronous aspect. If there's no pizza restaurants for a second it'll wait in a queue. When one comes it'll get its work. It'll go to any kind of a robust system. And the exchange lets you then have a fixed point to talk to but which then will handle the things that come and go. So you talk to a fixed point. You say, look, I want these and these messages when they arrive. You get them in a queue. Does this make sense? Okay, this certainly works very well but in MQP there's a few gotchas in there. For example, we have different kinds of queues. We have queues which are shared queues where you basically say, look, all my pizza orders will come in this queue. I get them one by one. I share them to different pizza restaurants. They're big, important queues. We also have little private queues like I am subscribing to all the gold price. I want these prices in some little private queue for me. They're in the same space which is kind of messy. There are a few other problems with that as well. But okay. RESTMS works in a very similar fashion but we use different names just to be annoying. We call these feeds and we call these pipes and we call these joins. So a pipe is like a UNIX pipe. You create pipes, you consume from pipes. It's a very simple metaphor. They have names but the server generates the names. You say, I want a pipe. Server gives you a URI as we saw on the RESTful example. You then say get which gives you a message. You say delete which deletes the pipe. You get a message, message content so you can access the pipe and what it has. The feed is where you send stuff. So feed would be for publishing information, for sending requests for pizza, anything. And then you connect the pipes to feeds. It's a very simple metaphor and it works. And it actually maps onto AMQP in a kind of a nice way. It's not quite one-to-one because in some of the feeds are exchanges and some actually are queues. And that's where AMQP got it wrong, things which have the same basic semantics in two different places. It separates them out. Okay. Enough of the lecture on that. It gets very detailed. We made a implementation of RESTMS called Xire. So if you were online, I would say look at Xire.com now but you can't. But I'm sure you will when you go home. Xire.com has a... Xire is the messaging server. It's open source, of course. We began this last year together with RESTMS. And it's basically a proxy for... I'll show you how it works. Typically you have an AMQP network with a big broker in the middle and applications hanging off it all around doing heavy stuff. And then you have an internet network on the outside, public internet network. You have clients here that want to access something in that network. Xire sits here. Speaks AMQP. And here speaks HTTP. Post Get Delete. So basically you can use Xire in several ways. You can use it to create a web frontend for an existing AMQP application. Which is unlikely to interest anyone here because I doubt any of you do that. More interestingly is just completely ignore this part and just use it as a messaging server. And just pretend it doesn't know. There's an AMQP engine at the back not relevant. It's basically a very simple, accessible messaging system which speaks HTTP. That's all. I think the... It's also do with the cost. The cost of learning AMQP writing an AMQP application it's weeks and months. This is a big improvement over previous systems already. Which used to be six months to a year. Getting, you know, JMS. Reasonably good still. Very, very complex. Doesn't do much more basically. AMQP is good but it's still too complex. In REST-MS you pick it up. You should be up and running in a few hours. If you're using one of the libraries that we have less time, a few minutes. And that's really the goal. The goal is to get this to be really, really accessible really easy to use and still deliver the same functionality. We lose a few things here and there. Some things we chop off. Not interesting. Maybe they come back later when we actually need them. Xire is actually built on something called X5 which is a redesign of an old thing that we made years ago called Shitami which is a web server. A very popular tough little web server I once saw on Slashdot a guy who had a Windows 95 machine with 26 hard drives and he had this site running on Slashdot. It was being Slashdot-ed and running Shitami and it was just taking it. Very tough. This was one of our early experiments in multi-threading in code. It's now been rewritten to use our new engine and that's doing the HTTP work for Xire in fact. So we'll also make a new web server which has a kind of a side product. To give you some examples of how big this is actually about three and a half lines of code. Meta lines of code if you like. Xire is about the same. They're tiny in terms of actual code work. The metaprogramming is very, very efficient. So then we were saying well that's fine. We have this software it's still a bit complex to install. We don't yet have nice binary packaging because my friend Benjamin has been working for like six months. Where's Benjamin? He's not there yet. To try and get a deviant packaging working it's very difficult. It's all fud's work and it takes time and stuff. So we still deliver source code. It's annoying for many people especially on Windows where with Microsoft compilers they're just so bad. So we made a live site. This is fun. It's called Live Xire com. And again if you had Wi-Fi you could go and try it right away but you can't. So just imagine it. Basically it's a running RESTMS server. It's running online. You can access it. It's an open server. You can use it to publish stuff, receive stuff. And I had some demo programs which you can see if you go to Xire.com. You can look at them and try them. And there is a seven line Perl script basically. And it's doing micro blogging. So you publish to a feed with your name and a comment and you can receive from a feed and you can basically just do micro blogging like that. And it's really, really simple to do. So you're probably asking by now what's actually different here? We know a lot of stuff. We have RSS, we have Atom, Pub. What's different? What am I getting if I try this out? So I'll try some sales. I don't usually do sales. I'm usually a programmer. But okay. I think the biggest thing is that stuff's happening here. Interesting stuff. Useful stuff happening on the server on your behalf. The most interesting is queuing. Now if you look at RSS, RSS basically says here's a feed. And then every now and then you go and look at your feed again. You pull and you say where's my feed? It's very slow. And you can maybe get 10 or 15 or 20 items and then the things hang. And it's horribly slow. For a little amount of data it's like, it's incredible. And it's all pulling. So you have to pull, pull, pull, pull. And you're asking the server, has something changed? Has something changed? Has something changed? You couldn't imagine a less efficient way of doing messaging. It's the worst possible design. Atom, Pub is better. It's definitely got better pattern. It's very restful. If you look at Atom, Pub, the spec, how they work, it's very nice in terms of rest. But it's still pulling. You're still saying here's my feed, get my feed, look at my feed. Okay, fine. You have to go and ask them when do they arrive. This is a really bad way of making any kind of system. So systems should be asynchronous. You should be event-driven. That means that it arrived. Thanks. And most time you're waiting on stuff. So you say, I wait. When it arrives, I continue. What we do in REST MS is we have what's called a long pull. A long pull says get a message. It's not there yet. When it arrives, I get it. So the get action, the get method actually can be an asynchronous get. It's kind of weird. The URI exists before the object exists. It works very nicely. So you can have queues which are sitting on the server waiting for you, private queues. And then when you're at your leisure, you collect your messages. It's really like a mailbox. A little bit like email. But much simpler than email. Much, much simpler. Addressing. So again, protocols like Atom, Pub are very nice, but there's no abstraction. There's no addressing. You publish to a feed, you read from a feed. Well, it's better than publishing to a directly point-to-point. But it's still very tightly coupled. With REST MS you can say, look, I have a pipe and my pipe collects data from these and these and these feeds with these conditions. I get my stuff in my pipe and I read it when I want. So the pipe is actually doing a little bit like searching on feeds of data in real time. And whatever it's matching, it picks up and puts aside and then you can pick up in your application. So you can imagine new ways of doing information processing. Let's say you want to monitor IRC channels on FreeNet, which is by the way not allowed. I tried it and they're like, you can't do that. Okay, fine. Whatever. And you want to see when they mention your product or your name. You have all these channels talking. Maybe they're talking about you. It's a great paranoid tool. So you can search, of course. IRC logs. You can index them and you can search them. That's useless. You want to get in on the chat. You want to come in when they're talking about you and say, yeah, that's true. That's great. He's a great guy. I know him personally. Or yeah, that's a great product. Or no, no, it's all lies. It's all lies. But you want to be there in real time. Information when it's old is useless. This is really the way it goes. Information, the value decays really quickly. So you want to be able to monitor the whole of FreeNet in real time. Well, you take and you subscribe to all of the channels. Don't do this. This is by the not allowed, but this is what you would do if it was allowed. Subscribe to all the channels. Publish all of the content of the channels onto a feed on LiveZire.com. Create a pipe and say on this pipe, I want to match on these and these and these words. Read your pipe. That's it. That's simple. Conclusions. Messaging can be fun. And it should be fun. It's communication. It's what we like doing best of all. So the internet is all about. It's communicating. Making pieces of work together. The fact that it's really boring and complex and painful is because it's been done by big companies who are basically incompetent or greedy or stupid or all three. We have new open protocols that change the game. They really change the game. The messaging has been dominated by products, first of all. APIs, secondly. And protocols, really, it's a very recent phenomena. APIs are useless. That's ODBC. You know, it didn't get us anywhere. You want standard protocols. Anyone can compete. You want open source products. Anyone can improve. You want competition. You want freedom from lock-in. You want the programmers actually fighting to make a better product. So, for example, with OpenAMQ and MQP. You know, we find it was too slow. So we have some guys in Slovakia friends of ours. FastAMQ. We start with zero MQ. Which is basically doing a lot of this work with no broker and they're hitting four million messages a second with latency of about 10 microseconds just in software. Really extraordinary. This is competition. People saying, I can do better. And it's all open source. So you get the input from, you know, the input from Intel, from other people helping us with that. MQP is good. It's still too complex for me. It's failed in its mission of being simple and accessible. It's enterprise technology, which is really no good. All that means is that it's a problem. You want it to be web technology for me. So, my advice is to try, have a look at RESTMS. Try it out. If you're a Perl programmer, you're lucky because I made Perl classes which wrap up the basic objects in Perl. If you're a Python or a Ruby or a Lua programmer and you feel like it, then, you know, rewrite my Perl class and contribute as a class in other languages, go for it. Try that. Tell us what you think. It should, in theory, be simpler to use an XML RPC, much, much simpler than SOAP. And it should be very close to production ready. We're talking about code that's been, you know, there's three and a half K lines of code that is new. And it's running on an MQP backbone which has been running for years and years in production. So it's very close to production ready, the whole thing. That's it. I'll take questions now. It's a good question. The way I see it, so there's different points of view in this. My point of view is standards is work of the community and that it's a matter of selection, as in natural selection. In other words, standards for me should develop by an organic process where people propose small improvements and the good ones get adopted and the bad ones get thrown away. So for me, the best approach to standards I've seen ever in IT is the RFC model where there are lots and lots and lots and lots of small standards. And interoperability is a matter of that one, that one, that one, that one, that one, and that one. You know, I implement RFC 1-1-8, I implement RFC this and this and they're all very formal, they're all easy to verify because the standard is a small piece of specification. That's my view. MQP doesn't really do that. MQP is getting very big monolithic standard, so interoperability with MQP as it stands is a difficult thing to even prove, let alone achieve. What I've been working on, apart from software, is a process around MQP to encourage community-driven standards development and RESTMS is part of that. There are a bunch of other standards that we've been developing small standards which I call supporting specifications and there's a wiki site Gorilla, Gorilla standards development. It's had to do it without a top-down structure, without committees, without meetings, without that and it's based on what we did in other organizations like DigiStand how to make good, simple, accessible open standards. If you're doing any kind of standards work, it's fun to look at that and that's interoperability. It's based on people trying specs implementing them saying it's good, it's not good and if it's good and you get two or three companies implementing it, teams implementing it, you have interoperability. You don't interoperate with products only with standards. Otherwise you get this business where my product is doing this I'll change mine to make work with yours. That's crap. You interoperate with written specifications and if they're not simple and small you can't do that and therefore you don't get interoperability. Next question. Regular developers. Can you repeat the question? The question was, is the messaging for regular developers or for enterprise? Roughly. Well, there's no contradiction. The thing is that enterprises and enterprises, we mean big companies with many staff have a very high tolerance for pain. They don't mind using really complicated technologies to take a long time to learn. They don't mind paying a specialist full time just to learn what the heck SOPA is. They don't mind that. Little companies do mind that. So little companies need it to be very cheap, very simple and very effective, very quickly. Actually they're quite small to be honest. They're well-known but they're actually the team there is like four or five people and they're very, very good and they actually push us to make things a lot simpler. Which is interesting. Exceptional. That's very unusual in large businesses of that good team but they were in fact a team that used to work at a small internet start-up called MarketWatch which was bought and so they're very competent people. It's unusual. Most big companies are filled with very incompetent people. I don't want to be unkind but that's the truth. And they don't really want they want things to be comfortably difficult. It makes everyone's life in a certain way easy. Big budgets, big projects, not necessary. So my goal is to really make this easy for people like me who are basically lazy. I don't like having to be really concentrated to understand something. I want it to be simple, to work automatically, to be, you know, full-proof. It's more fun and it's also part of the art. If you make software that good that it works for anybody. You know. That's an achievement. Next question? Right. So there are the volumes that we talk about, they go from one message a second up to five million messages a second. That's the volumes we talk about in real-life use that we see. If you're doing a if you're picking stories from the BBC, it's one per second. If you're lucky, if they're working really hard. If you are processing orders on the Chicago options exchange, it's five million per second. So obviously there are trade-offs in different ways of doing things. This guy here aims at that level. So if you want to see how to make stuff if you want to see how to make stuff that can process millions per second look at zero MQ. It takes a different approach. There's no broker, it's basically a library which you plug into your application and you have to write applications very, very, very carefully because if you make mistakes in applications it slows everything down. And then the other end, I have REST-MS which I don't think it's one a second I think it's probably about a hundred or five hundred a second but it's very chatty, REST-MS and REST is very chatty. It's get my message delete my message. One by one. Now you can batch it. So I'm not really worried about it if I have a hundred a second I can make it ten thousand per second by batching messages which we do a lot also in MQP. So the trick is you make it simple you make it work you find out where it's too slow you make it better you don't start by making it fantastic start making it simple and making it work. And then when people say look it's too slow for me make it better. MQP it's somewhere here it can do something like a hundred thousand to about five hundred thousand a second depending on the implementation which is more than anyone needs outside of certain large companies. You mean like choreography? Does curing a message distribution also stores later so you can stop? I would say not my problem the thing is that we work in layers and this layer is about shoving blobs of data around the network between peers. We're doing addressing, we're doing queuing we're doing simple APIs we're doing simple patterns for reliability that's it. On top of that you can build all kinds of services including right no what I was going to say was it'll come so when you have layers that work and are trusted people will build on that. Companies like Tipco need to always raise the bar because they're selling stuff open source we don't care we can stay quite happily at one level make it better and better but it'll happen people using Tipco will say well why am I paying ten thousand per core per year for this and I can make it myself on top of OpenAMQ okay go make it at the back a question no at the front no and there are many many messaging products many thousands but and there are many open source products the trick is what are you actually buying and this is this is the thing it is we have product we have API we have protocol and again you compare to SQL you can be buying Oracle you're buying a product well if you're comparing Oracle to side based on formics you're not winning anything you're just choosing which lock in you know you're going to get now open source it's better but it's still a product you're still locked in okay you have APIs APIs are better but APIs don't actually guarantee you very much because APIs are always extended modified and changed ODBC again a good example now so you want a standard SQL 92 this is the way a select statement works if you stick to that it's going to be portable and now you're suddenly you're free and now you can take Oracle put in my SQL and if you stick to that SQL statement it'll work so actually when you when you're buying technology solutions if you're buying products you're just choosing a way to be locked in unfortunately APIs is better but it's still not enough this is the problem in Java is Java is all APIs you have GMS messaging it's an API and every single provider is different in all different ways so you're just choosing different kind of lock in so it's about standards and it's a very important DDS it's a protocol it's patented and it's not well documented and okay what can I say I'm not a fan of DDS not a fan of patents indeed how long do we have still did anyone get Wi-Fi working in the meantime no you mean did you get Wi-Fi working no sorry okay then you're in trouble no I'm just joking brokers fail there are different answers to that question the one I like best is the broker shouldn't fail and in fact we put our effort into making the broker that doesn't fail which is more fun than making a solution for when the broker does fail so it's like you know I have a car what happens if my car breaks well what we'll do is we'll sell you two cars and then we'll drive behind you in the second car all the time the first car breaks you jump in the second car you carry on it's fantastic this is what they do I'm serious okay this is called the backup broker and you actually have two brokers running and two big machines and the one that's going and this one dies so then you switch off the backup broker and then you hope it all works now useless this is what enterprise likes but it's useless it's really a bad way of making reliability yes machine could break down so backup machine possibly a good idea possibly two machines you're worried about your machines but today machines don't break down anymore again machines are very reliable they have failsafe power supplies they have failsafe disks okay your data center could burn down okay your building could explode sure it could it's really a matter of how paranoid you are what we discovered in the end was that you can actually make the software completely not really reliable within the parameters of your application now you can always crash it doing different things we have stuff that runs day and night in company A and some other guy says look I do this and it dies like wow that's something new he does software is never reliable without limit but within the limit of a particular environment it can be 100% reliable at that point it never crashes and then after six months or a year the customer says wow it never crashes and if it does crash it restarts really quickly and if you take an example like Dow Jones they don't mind if it crashes in fact as long as they get the data back within one minute as long as they get no duplicates they don't mind if they lose data in fact but they hate getting data twice imagine that the stock price of Microsoft is going up and suddenly you know they would be crazy so a gap is fine data later in the wrong order or double is really bad so companies have also different requirements there are different answers to that question and my answer is make it really reliable and you know try not to make it crash try to stop it crashing unfortunately we've been doing this for something like 15 years now we have our own tools for that we have co-generators we have one called GSL I mean it gets really really complex I don't want to talk about it too much because it's this is not simple but as a co-generator we have frameworks again a modeling tool and if you look at imatics.com you'll find some reference to this co-generation is unfortunately very it's very leveraged so it gets very abstract very quickly and that's a bit of a shame it means that people don't understand what we do in fact when we write when we write software we invent new languages, meta languages modeling languages which describe protocols, describe state machines we generate from that we generate the generators it lets us work very quickly but also means if you look at the code you'll be like what the fuck this is impossibly complicated code the generator code is really really complex and the meta code is very abstract so it's a bit of a difficulty for participation it does that as right very good software very quickly it's open source it's open source yes all open source it's all all the meta code is GPL GSD ok hands up who hears for the next speech not my speech just to see ok thanks guys