Apache Etch: Efficient and feature-rich network services
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 64 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45913 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 201136 / 64
3
7
10
11
17
19
21
28
33
34
35
37
40
44
48
49
52
55
57
59
62
63
64
00:00
Service-oriented architectureComputer networkSoftwareCodeFunctional programmingService-oriented architectureSoftwareSoftware engineeringSoftware frameworkCartesian coordinate systemStaff (military)Computer animationXMLLecture/Conference
00:51
Computer networkSoftware frameworkService-oriented architectureBuildingSymmetric matrixError messageConstraint (mathematics)Server (computing)ArchitectureFormal languageConvex hullTelecommunicationBellman equationPrimitive (album)Interactive televisionDifferent (Kate Ryan album)ResultantFunctional programmingCartesian coordinate systemClient (computing)Web 2.0Software frameworkSoftwareServer (computing)Axiom of choiceError messageJava appletKey (cryptography)Direction (geometry)Independence (probability theory)Scaling (geometry)Service-oriented architectureGoodness of fitSystem callException handlingAreaQuicksortMultiplication signFormal languageFront and back endsWritingIdeal (ethics)Library (computing)Dependent and independent variablesThread (computing)Descriptive statisticsString (computer science)ArchitectureCommunications protocolCASE <Informatik>TelecommunicationConnected spaceSynchronizationProgramming language2 (number)Constraint (mathematics)Mobile appSlide ruleMessage passingProcess (computing)Web serviceDigitale VideotechnikSymmetric matrixComputer animationLecture/Conference
06:09
Information and communications technologyError messagePhysical systemIndependence (probability theory)Formal languageDemonCodierung <Programmierung>Binary fileAdditionJava appletAmicable numbersSharewareFunctional programmingException handlingString (computer science)Multiplication signPlug-in (computing)Programming paradigmObject-oriented programmingPairwise comparisonDescriptive statisticsCompilerNormal (geometry)Software frameworkOptical disc driveMereologyDivisorLevel (video gaming)Cartesian coordinate systemCodeProgramming languageAdditionSoftwareLibrary (computing)Revision controlState of matterCommunications protocolSoftware developerAlpha (investment)File formatStreaming mediaData modelClient (computing)Server (computing)Constraint (mathematics)Go <Programmiersprache>Java appletMessage passingBinary fileGreen computingImplementationWeb serviceSystem callDifferent (Kate Ryan album)Keyboard shortcutDependent and independent variablesPhysical systemDirection (geometry)Service-oriented architectureComputer chessCategory of beingInheritance (object-oriented programming)Data structureGoodness of fitNumberDefault (computer science)Web browserCASE <Informatik>Interpreter (computing)INTEGRALParameter (computer programming)2 (number)Error messageBinary codeGoogolComputer animationLecture/Conference
11:26
Binary fileCodierung <Programmierung>System callGroup actionArchitectureSanitary sewerDescriptive statisticsCommunications protocolRemote procedure callClient (computing)CompilerServer (computing)ArchitectureSystem callMessage passingCartesian coordinate systemStack (abstract data type)Identical particlesImplementationSerial portData managementInterface (computing)ThetafunktionService-oriented architectureSoftwareCodeLecture/ConferenceComputer animation
13:15
Message passingUDP <Protokoll>Integrated development environmentSerial portGamma functionWebsitePredictabilityElectronic mailing listSystem callService-oriented architectureTelecommunicationWebsiteElectronic mailing listEmailIntegrated development environmentOpen sourceSoftware developerLattice (order)Transportation theory (mathematics)Online helpMoment (mathematics)Drop (liquid)Programming languageImplementationDirection (geometry)Information securityAdditionLevel (video gaming)Keyboard shortcutBuildingAreaJava appletProjective planeAxiom of choiceInternet service providerSoftware frameworkWeb serviceInternetworkingComputer animationLecture/Conference
15:59
Computer animationXML
Transcript: English(auto-generated)
00:08
Well, first of all, hi everybody, and first of all, thanks a lot to all the Fostom staff for organizing this great conference, I think it's really good work that you're doing. Well, I'm a software engineer at BMW Carity, and I want to tell you today about a piece
00:23
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 the features are and how you can use it in your application to make your code very easily network service-ready,
00:44
so you can use your functions and your functionality just as a network service in a very easy way. So what is Edge? 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
01:03
again implement the framework for building network services? There are dozens of that out there, so probably all of you know CARBA, probably all of you know web services, and there are many others, but Edge is, at least for our use case, which is making
01:20
efficient, transport-independent network services based on a 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 back-end 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.
01:43
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. In Edge it's symmetric, so you open up a connection, and after that,
02:02
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
02:23
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
02:45
regular stalls, but only also throw exceptions. Then you have pretty good timing-constrained features in Edge. You can specify methods with certain timing assumptions. You can say, I want this method to return a value in under one second, for example, otherwise I will
03:03
get an exception. Of course, because it's a network service description, it's a network service framework, you have a language for describing your network services, sort of an ideal. 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 an application server or whatever
03:24
in the backend. It's just one single library that you can use, transport and language independent on all your devices. You can use it in phones, you can use it in backend servers, and they will always be compatible via Edge. It has a modular architecture, and as I said, it tries to be language and transport independent. I will get more
03:42
into detail about all those features that I've showed you in a more concrete way. 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
04:05
and returns a string, and you probably guess what's happening on the wire, so you have nodes 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
04:21
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? You can define services in your IDL, and you can annotate them by
04:44
using direction primitives. 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
05:04
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, but this is really symmetric and makes it really
05:20
convenient and easy to use. It's especially very good if you're having interactive applications, 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. For example, what I've shown you before is that you have
05:43
synchronous calls which are blocking, which are waiting for the result of the function, and 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
06:03
function to return. It just sends out a message, forgets it, fire and forget, and then on the server it is processed, and sometimes, because this is direction client method, that howdy as a response to hello, the server will answer asynchronously, and the client will process that answer also asynchronously.
06:21
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. 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
06:44
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
07:01
here, which the user is supplied as a parameter. But you can also define exceptions. As I said, you can define exceptions just like normal data, so you say exception, use a random exception also, provide a string for the exception message, and then you annotate your function here with a normal
07:22
throws 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
07:40
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 an exception, another exception, timeout exception, if this bound is over it. So this is generally what Edge does on the
08:01
network description layer, and as I said, this is compiled by the Edge compiler, and you get code 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
08:24
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
08:41
JavaScript, Python is under development, and Google Go are available in the alpha state, which implements the basic protocol functionality. Edge is transport 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
09:01
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 or function calls on the wire using a binary encoding, which makes it
09:22
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 the 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 wedge,
09:45
then of course this binary encoding is probably the 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,
10:02
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 XPS plugins for making writing the network service description easier and running the compiler and all that stuff. Then we
10:25
come to efficiency. It's quite important. I haven't the time in these 15 minutes to make a big comparison with 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
10:44
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
11:04
factor 10 to 100 slower, just to give you an impression. Even with the blocking calls, we end up with 15k calls per second. This is really meant to be used in performance-critical, for example, embedded applications,
11:21
but also in higher-scaled networks. You can choose. It's up to you. The nice thing about Edge is when it goes to implementation, we have a layered architecture. 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
11:41
between client and server very much. You have the exactly same architecture running on the client, running on the server, and you have layers which you can very easily exchange. 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
12:04
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
12:22
binary, plug it in, plug it out. And then you have the mailbox manager, which handles the asynchronously in the whole thing. So you have the concept 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
12:44
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 stubs and remotes, are generated from the network service description that you've written, all the other
13:03
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 in our roadmap? Where do we want to go? Of course, most
13:22
important is always getting more languages, more transports, so making this thing really broadly 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
13:40
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. You will come up pretty fast with something that you want, an aiming service, for example. You want discovery
14:01
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 built in, but you
14:24
probably want more. You want better ID support, and you can think of various other features that are on the roadmap. What I can say, this is a project which is in the Apache incubator, which is a staging area, you could say, for new projects to enter Apache. We are still in a choice of
14:43
what we want for the future to be developed. 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. This is really under development features. If you want to
15:03
find out more, there is a website, which is that, and there are mailing lists, which are our primary source of development and communication. If you are interested in Edge, drop a mail on Edge Dev or Edge user, whatever you are interested in, and you will get whatever help that you
15:23
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,
15:40
for example. There is a community of people that are working on that, and if you want to get in contact, direct me on the mailing list, and thanks a lot.