 Well, first of all, hi everybody, and first of all, thanks a lot to all the FOSTA and stuff for organizing this great conference, I think it's really good work that you're doing. Well, I'm a software engineer at BMW Karate, and I want to tell you today about a piece of software that we have come about in the last two years, which is Apache Edge, which is a framework for building up network services in a RPC style fashion. And I want to tell you today what Edge is. I want to give you a basic introduction on what features are and how you can use it in your application to make your code very easily network service ready. So you can use your functions and your functionality just as a network service in a very easy way. So what is Edge? And first of all, it's a framework for building network services. And if you think about that, you've probably come to the question, why on earth should anybody, again, implement the framework for building network services? There are dozens of that out there. So probably all of you know Corba or probably all of you know web services, and there are many others. But Edge is, at least for our use case, which is making efficient, transport-independent network services based on the binary efficient protocol. It is the choice that we made, and it worked out really pretty well for us, and it scales from phones to backend servers, and it has features that I want to show you today, which distinguish it in its whole from other service frameworks that you probably know. So what is Edge? First of all, the key feature of Edge is that it's being symmetric. So in traditional service frameworks, you have a client and you have a server, and you open up a connection, then the client asks the server, it calls functions and stuff and gets responses. And Edge is symmetric. So you open up a connection, and after that the client and the server have no specific role. They can talk to each other in both directions. Then you can choose whether you want synchronous one-way, synchronous two-way or asynchronous one-way calls, which has a big impact on the efficiency and the performance of your application. I will come to that later on. In Edge you can choose whether you want the one or the other, just what is your application demand. Then you have pretty good support for error handling, which is based on the idea of exceptions, which you know from Java or other languages. And this really makes the idea of exceptions transform to the area of network services. So you have services which can not only return regular results, but also throw exceptions. Then you have pretty good timing-constrained features in Edge. You can specify methods for certain timing assumptions. You can say, I want this method to return a value in under one second, for example. Otherwise I will get an exception. And of course, because it's a network service description, it's a network service framework, you have a language for describing your network services, because sort of an IDL. I will show that later on. It's fast and efficient, as I said. And that's the nice thing. It doesn't require you to install a application server or whatever in the backend. It's just one single library that you can use, transport and language independent. All your devices, you can use it in phones. You can use it in backend servers. And they always be compatible via Edge. It has a modular architecture. And as I said, it's trying to be language and transport independent. So I will get more into detail about all those features that I've showed you in a more concrete way. So the very basic thing that you can do in Edge is what you see at the very top of this slide. You can write network service descriptions. In this case, you just have a service which is called Hello World here. And it has a method which is called Hello. Passes a string and returns a string. And you probably guess what's happening on the wire. So you have notes in your network. And here is, for example, TCP IP communication and our service framework. And what happens on the wire is that you say hello to your server. Your server response thread processes the request and tells you hello, client. Well, this is probably what all of you know from various RPC-based frameworks. You can do this in Edge too. But there is more that you can do. First of all, I told you Edge is symmetric. What does that mean? So you can define services in your IDL. And you can annotate them by using direction primitives. So you can say this hello method is something that I can send to the server. And this ask something method is something that I can send to the client. So here you see that in Edge, it doesn't make a difference who is the server, who is the client. You just communicate on the wire. And then in the end, this will look up on the wire. You have here the client and here the server. And you say hello to the server. It says hello to the client. And in a completely different thread, for example, you could say ask something to the client. And exactly the same things are happening on the client side. So this is really symmetric and makes it really convenient and easy to use. It's especially very good if you're having interactive application, interactive functionality, interactive applications that require that you communicate in both ways. Then you can say, I want to choose how my function calls are delivered. So for example, if you, what I've shown you before is that you have synchronous calls which are blocking and which are waiting for the result of the function. And as you can choose whether you want those functions to be blocking or not. If you don't want them to be blocking, you just annotate the function with one way. And then what happens on the wire is that you have asynchronous function calls here. And you see here, it doesn't wait for your function to return. It just sends out a message, forgets it, fire and forget. And then on the server it is processed and sometime because this is direction client method that howdy as a response to hello, the server will answer as synchronously and the client will process that answer also synchronously. And in Edge you can choose whatever you want, what fits your application best you can choose and you get your code generated from that service description here. So another feature that Edge has is data modeling and error handling which I want to show you now. First of all, data modeling. Data modeling is inspired by object-oriented languages so you can define structs but you can also use all the object-oriented features like inheritance and all that stuff. Here to make a simple example, we have a struct which is called user and that user is a property which is his name and you have that hello method here which the user is supplied as a parameter. Okay, but you can also define exceptions. As I said, you can define exceptions just like normal data. So you say exception, user unknown exception, also provide a string for the exception message and then you annotate your function here with a normal source declaration just as you know it from Java and on the wire it's possible that you say hello to the server and of course this one can then say, I don't know you, this is a user unknown exception. So you can really use that paradigm of object-oriented exception handling in a network service. You can also annotate your services with timing constraints so you can say, I want this hello method to answer within the time bound of 500 milliseconds for example and this will also throw another exception, time out exception if this bound is over it. So this is generally what edge does on the network description layer and as I said, this is compiled by the edge compiler and you get co-generated for various languages. For example, for C-sharp, for Java, for Google Go and we have also parts of implementations ready which are in a very early stage for Python and other things. So this is what I wanted to say here. Google Go is the earliest addition to our binding library. The other three here, Java, C-sharp and C are stable versions which you can use for whatever you want. They work, they are stable and those things here, JavaScript, Python is under development and Google Go are available in an alpha state which implements the basic protocol functionality. Edge is transparent independent so what I've showed you before is based on TCP. I explained it on TCP but it doesn't necessarily have to be TCP. It just has to be a stream protocol in some way. You could do this on a serial wire, you could do this on Bluetooth, you could do this on TCP. It is also independent from the concrete transport format. So what we do by default is encoding our data, our function calls on the wire using a binary encoding which makes it small, which makes it efficient, which gives you good performance numbers but you could have a different use case which requires you to use XML. There is an XML binding available, for example, implemented in a JavaScript and C sharp bindings because of course in the browser scenario this would fit better than binary encodings but for example, if you go embedded, which you can with Edge, then of course this binary encoding is probably a thing that you want. So you can really choose and the technology as itself is independent from that very basic requirements. We have tooling available, so if you want to debug, for example, what's happening on my TCP transport in my application, you have Wireshark support, you can put in the network description and you will get an interpretation of the traffic that is going on with the wire using Wireshark. We have basic Maven integration. We are currently working on providing nice accepts plugins for making writing the network services description easier and running the compiler and all that stuff. Then we come to efficiency, it's quite important. I haven't the time in these 15 minutes to make a big comparison of all the other frameworks that are out there. There is data on the website regarding that but just to give you an impression, we have different ways of calling functions as I said. For example, if you have asynchronous one-way calls where you just one after the other call the functions and fire and forget them, we come on a normal desktop system to around 40K function calls per second. If you compare this to, for example, an HTTP-based XML-based web service framework, you will end up with a factor of 10 to 100 slower, just to give you an impression. And even with the blocking calls, we end up with 15K calls per second. So this is really meant to be used in performance critical, for example, embedded applications but also in higher-scaled networks. Just you can choose, it's up to you. The nice thing about Edge is, when it goes to implementation, we have a layered architecture. So what you see here is the protocol stack on the server and on the client side and they are both symmetric. As I said, Edge doesn't distinguish between client and server very much. So you have the exactly same architecture running on the client, running on the server. And you have layers which you can very easily exchange. So for example, if you want another transport, you just take out the TCP stuff and plug in another transport, which has a very good defined interface. You can just implement a few methods that you need and then you take this out and put Bluetooth or whatever in, so you can choose here. And then it goes up via the packetizer which is responsible for making chunks of data. Then the messageizer which is responsible for serialization and here you can also choose if you want XML, if you want binary, plug it in, plug it out. And then you have the mailbox manager which handles the as-in-chronycy in the whole thing. So you have the constant of mailboxes and what you do is when you have your application which issues a call to the server, then this goes over the remote into the delivery service and then it spawns a mailbox. And this one just waits until someone on the other side will process that request and then the answer will come back and will be delivered to that very specific mailbox and the answer will be delivered back to the application. And this is fully symmetric in both ways and those layers here, the stops and remotes are generated from the network service description that you've written. All the other things are dependent on the protocol stack that you're currently using. So you can choose whatever you want and you get that nice code here up in the upper layers generated by the edge compiler. What is going on on our roadmap? Where do we want to go? Of course, most important is always getting more languages, more transports. So making this thing really broad and available. At the moment, it's pretty good implemented using Java, TCP, C, C sharp. So you can choose, but it's TCP. We would want to have a serial implementation. We want to have a UDP implementation. For example, also we will want more languages. As I said, there are first steps for JavaScript and Python. And you can even think of what you want in addition on top of that framework. So you will come up pretty fast with something that you want, an aiming service, for example. You want discovery of your services. We have ideas of implementing the discovery of the services with Edge itself, for example. When you have a UDP multicast binding at the very lower level, then you could implement the discovery with the technology itself, which would be pretty nice. You want web service, gateway, you want more security. There is some basic security building, but you probably want more. You want better ideas apart. And you can think of various other features that are on the roadmap. And what I can say, this is a project which is in the Apache Incupator, which is a staging area, you could say, for new projects to enter Apache. And we are still in a choice of what we want for the future to be developed. So if you like Edge and if you want something here, we are pretty happy to get in contact with you. You just join the mailing lists, join Edge Dev, look at the website and contact us. So this is really under development features. So if you want to find out more, there's a website, which is that. And there are mailing lists, which are our primary source of development communication. So if you're interested in Edge, drop a mail on Edge Dev for Edge user, whatever you're interested in, and you will get whatever help that you need on these lists. There are contributors. The initial development of Edge was done at Cisco. At BMW, we used it, for example, for connecting phones to cars, which is a very specific requirement. We can also use it for connecting embedded devices to internet services, for example. Yeah, so there is a community of people that are working on that, and if you want to get in contact, directly me are the mailing lists, and thanks a lot.