Distributed Computing with Ada and CORBA using PolyORB
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.
Praca, Frédéric
Imagine you have a fantastic Ada program or library but you want more! You want it to be scalable and used by other developers with other languages. The goal of this presentation is to show you the way to achieve it without bending to fashion. :) As of today, we see distributed computing as Web services, mainly RESTful stuff. Some technologies exist since years and are working successfully in many systems. One of these is CORBA which allows Object-Oriented communication between applications in languages such as Ada or C++. In this presentation, the chosen middleware providing CORBA infrastructure is PolyORB. We will use it to make a distributed version of an existing piece of software, the Corporate Bullshit Generator (CBSG), and create client applications in C++ and Ada. This will allow us to put the power of Ada and PolyORB into a distributed system.
 So, here we go. Thank you for being here. I was not expecting such a crowd. I would have taken a tire. So that's me. Not really interesting. No, I want just to say that usually I code in Java and Python just because I'm obliged to and I would prefer to code in Ada but it's not the case in my company, even if I worked also in Europe and Ironautics company in the past. So the goal of this presentation is to show you how we can distribute some computing in Ada. And for this, I will first explain what is distribution. So according to Wikipedia, a distributed system is a system where each component are located on different computers on the networks and then they can coordinate and communicate using message passing. The problem is that with message passing is never defined and for this task we have several technologies. So different technologies appeared in the last 40 years and they will only take few. Soap. Soap. Yes, soap, like the soap, is in fact more a protocol, an XML protocol using a definition language, using Wizzdell as definition language. Wizzdell is an XML file which defines which types you can use, which may so you will be able to call, and so on. It usually, no, it runs over HTTP and was mostly used from 2000 and 2009, I think. Then we got something called REST. REST does not define anything. It's just you will use get, put, post, delete, and so on from HTTP. You don't know what you have to carry inside REST payload. It could be JSON, it could be XML, exactly like soap, it could be text, I've seen, text in the past, anything you want. Really, really good for someone coding in Ada. We will talk about this one later, and DSA. So DSA is the distributed system in X. It's an index for Ada, which is a part of the standard. A compiler doesn't have to provide a DSA layer, but it's Ada only, and you won't be able to talk to other program running something else in Ada. RMI, this is the part for Java. Java is remote method in vocation. It's Java only, just like DSA was for Ada only, it's Java only. So DSA is the distributed common object model, which is the distribution seen by Microsoft, where you will have some components inside the Microsoft world talking to other components inside the Microsoft world. As far as I remember, we were able to create D-com objects in wonderful languages, C++, but also visual basic, and many other things that are really, really related to Microsoft. But among others, you have a lot of different protocols and ways to communicate. Someone talked to me about Protobuf. Protobuf is protocol buffer, it's a kind of data formatting coming from Google. So several candidates are possible with Ada. Rest, easy, you have an Ada web server, AWS, you can do rest, because rest is only listening to HTTP verbs, and just providing a text in exchange, a text or XML or something else. Anyway, we will agree that it's not really something strict without strict typing, so for Adaist, it's not something that we will use. And note for Stefan, OpenAPI is not something to describe data correctly. From my point of view. Soap is supported by AWS, so you can use your Ada web server to provide some soap endpoints. But who wants to have XML on the wire, XML everywhere, describe everything in XML, and have a ratio between the payload and the tags, which is on the side of the tags. Compression. Yes, of course, who is good to him? DSA, OK, DSA is a real good candidate, but it's Ada only, and we know that Alas, the word is also with C++ and stuff like that. And finally, Corba, Corba is object-oriented, it uses an interface definition language. It's binary on the wire, the same way as protocol buffer. It appeared in 1991, so to compare to protocol buffer, which appeared in, I think it was in 2008 or something like that. So you can see that we are still keeping, reinventing everything. And there are some language mappings. So what does it mean? Corba is common object-request broker architecture. It's a standard from the UMG object management group, which is a consortium of computer companies. It was released in 1991 for the first version, but the last one was released in 2011 or 2012. It's object-oriented. It uses a definition language, a strict one, but I will show you. And it's language agnostic, but the standard mappings were defined in the standard. So you can have an IDL and map it to C++, JVAADA, C, Cobol, Lisp, P1, Object Pascal, Python, Ruby, and small talk. So you can talk to everybody, almost. No JavaScript. Sorry. Corba and Ada. Corba and Ada are not very trendy, but together they do a great job. So you know this is a quote from myself today, because I've never been quoted before, and I was really, really impatient to be. So nobody quoted me today, so that's it's done. Okay. There is some code already available since almost one week. Yes, but I've done it a long time ago. Suppose we have a program which is very useful. Yes. Easy to use and integrate, because it's Ada. But not designed for remote access, because the main developer decided to put it only at the beginning as a command line tool. Nezha for scalability. Yes. So what the program is, you will say it's obviously we need scalability for this. So distribution is the solution to our problem. The CBSG stands for Corporate Bullshit Generator. The aim of the project is to providing the user sentences built against a vast vocabulary and sentence constructions harvested during long boring meetings. It's another piece of software provided by Gauthier de Montmolo. So we had Zipada, Lib Zipada, and we had the Corporate Bullshit Generator. And obviously you have an online version. Let me show you this. Here is the website for the Corporate Bullshit Generator, which is using a brand new technology, CGI. And here you can see with some beautiful website and beautiful interface, where you can just, if I recall my mouse, a many, many efficient button, when you click, you get five new sentences. The category manager technically standardized our trends. No problem. I've been working in Airbus and I can tell you that I've heard some kind of sentences like this during the famous long boring meetings. Yes. And I'm pretty sure everybody has. So it's important to make it distributed, so we will use define or IDF or CBSG. So first let's take a look at the add-as specification for the Corporate Bullshit Generator. It's a generic package where you have to provide the characters that will be used to format your text. Then you will have four functions, sentence, gives you one sentence, workshop, I think it's 10, short workshop, which should be five, and financial report, 100 sentences. When you don't know what to do at night, you have to read this. So the idea. Ideal looks like C++, it's a standard from the UMG, I would say that UMG was mainly C++. So you will find the beautiful curly braces over there and several, I would say that code formatting looks like C++. Okay, not a great deal. What a module is. What it is, is the equivalent of a package. It's a namespace for C++, it's a package in Ada. You can define struct, struct are data that you can share from one object to another across the network. And then we define interface. Interface is the definition of the object that will share some functions with other computer. Unlike the struct, the struct can come across the network. An interface is an object which will stay on its server. You won't get a new object by getting a reference on this. It's really distributed. First this, we will use poly-orbe. Poly-orbe is a polymorphic reusable infrastructure for building object-oriented distributed systems. It provides several middlewares through what we call application properties, personalities. So with poly-orbe, you can do DSA, great, it's Ada, Cobra, and MoMA. MoMA is message-oriented middleware for Ada. That's it. And then protocol personalities. So you say how do you use the network to handle the three applications. GIOP is the one which we will use. GIOP is generic inter-orbe protocol and has implementations such as IOP, Internet Inter-Orbe Protocol, SSL-IOP, DIOP-MIOP. And the last one is SRP is a simple request protocol and it's based on HTTP. The standard use we, the standard is to use GIOP with IOP. Poly-orbe is maintained by AdaCore. It's available on GitHub. But yes, I put this one because compiling poly-orbe is not that easy and so I wanted to put this and to show you that when you configure your poly-orbe, you said which protocol you will use and which application you will use. And for Cobra, there's something else called the Cobra Services. The standard defines several existing distributed objects, naming, event, IR, notification, and time. For those who are interested in the GitHub, you will have the standard code for the distributed corporate bullshit generator. And you will have one using naming. Naming is in fact a kind of DNS for objects. We have poly-orbe, we have our IDL, we generate some code thanks to this command line. So what do we get? Ash, utilities, what we call skeleton, glue between the object request broker and the implementation, and the implementation itself. Yes, skeleton, I love it. So this is the Cobra architecture. We will be on this side, so we call always the object the servant, and the server will be the software that will show the servant to the network. So the only things that we have to change is the implementation. I just put the first one, which is quite simple. Instantiate your corporate bullshit with no marker, and then just provide the create sentence, which is a wrapper around the simple generator. And we are using Cobra, so we have to translate the Ada string to the Cobra string. Quite easy. So the server, the server needs to initialize the best called the ORB. We have something called the POA for portable object adapter, which is in fact the glue between the server and the server and the orb, and that will provide you several things such as instantiation, characteristics, and so on. Recreate the reference, we start the ORB. This is the code. I just create the implementation, get a reference on what we call the portable object, a reference, initialize all the machinery there, and use then, I will show you, but the servant to reference. I have my object, and I transform it into a Cobra object, and then print it on the screen. It will print what we call Cobra lock, which is a string, describing the object, providing a unique identifier of the object on the network. Client, okay, we will be on the left side. Quite easy. We generate the stub, init the orb, get the object, it's okay. We call the method, and that's all. The same way we have to get the code from the ideal ADAC compiler, and then provide the code for the server, which is initializing the orb, convert the first parameter, which will be the Cobra orb, test that it's not new, and then we get the message from the remote computer using the create sentence. For fun, if we can call this fun, I made a C++ client, so you do exactly the same. You generate a stub, you init the orb, get the object, and call the method, and that's all. So it's C++, I won't be talking about this. It's almost the same. Ah, the demo, yes. So here it is. Okay, I got the corbaloc. I'll copy it. That's the reason why you can use the naming server, because it's easier. Ha! Wrong. Great. Yes, the generits are answered, and the state or ANSTEPA captures, engage the intelligent cross-pollination. Thank you. And the last one is using the structure, so you can see the timestamp for this. Ha! Conclusion, why using IDI with Cobra? Because you're using your favorite language. That's one point. You will put safety and readiness of IDI into an heterogeneous system, using other components that will obviously fail, because they are not IDI. And you will be using polyob, which is in itself something interesting. And that's all. Here are the links for the further reading. You have 20 seconds for questions. And I'm pretty sure you won't have any more. Oh, no. Why did you recompile Polyob when you have the Debian package? Because I'm using the decor version of the compiler, and you have to compile Polyob with the same version of the compiler, as far as I remember. At least for DC. Yes, but you also have an ADAC compiler in Debian. Yes, but I don't have Debian. I just have a Ubuntu. And no, I won't switch to Debian. No. Stop it right now. Okay, we're running out of time. Yes, of course. Thank you again. You're welcome.
 So, here we go.  Thank you for being here. I was not expecting such a crowd.  I would have taken a tire.  So that's me. Not really interesting.  No, I want just to say that usually I code in Java and Python  just because I'm obliged to and I would prefer to code in Ada  but it's not the case in my company, even if I worked also in  Europe and Ironautics company in the past.  So the goal of this presentation is to show you how we can  distribute some computing in Ada.  And for this, I will first explain what is distribution.  So according to Wikipedia, a distributed system is a system  where each component are located on different computers on the  networks and then they can coordinate and communicate using  message passing.  The problem is that with message passing is never defined  and for this task we have several technologies.  So different technologies appeared in the last 40 years  and they will only take few.  Soap. Soap.  Yes, soap, like the soap, is in fact more a protocol,  an XML protocol using a definition language,  using Wizzdell as definition language.  Wizzdell is an XML file which defines which types you can use,  which may so you will be able to call, and so on.  It usually, no, it runs over HTTP and was mostly used  from 2000 and 2009, I think.  Then we got something called REST.  REST does not define anything.  It's just you will use get, put, post, delete, and so on from HTTP.  You don't know what you have to carry inside REST payload.  It could be JSON, it could be XML, exactly like soap,  it could be text, I've seen, text in the past, anything you want.  Really, really good for someone coding in Ada.  We will talk about this one later, and DSA.  So DSA is the distributed system in X.  It's an index for Ada, which is a part of the standard.  A compiler doesn't have to provide a DSA layer,  but it's Ada only, and you won't be able to talk to other program  running something else in Ada.  RMI, this is the part for Java.  Java is remote method in vocation.  It's Java only, just like DSA was for Ada only, it's Java only.  So DSA is the distributed common object model,  which is the distribution seen by Microsoft,  where you will have some components inside the Microsoft world  talking to other components inside the Microsoft world.  As far as I remember, we were able to create D-com objects  in wonderful languages, C++, but also visual basic,  and many other things that are really, really related to Microsoft.  But among others, you have a lot of different protocols  and ways to communicate.  Someone talked to me about Protobuf.  Protobuf is protocol buffer, it's a kind of data formatting  coming from Google.  So several candidates are possible with Ada.  Rest, easy, you have an Ada web server, AWS, you can do rest,  because rest is only listening to HTTP verbs,  and just providing a text in exchange, a text or XML or something else.  Anyway, we will agree that it's not really something strict  without strict typing, so for Adaist, it's not something that we will use.  And note for Stefan, OpenAPI is not something to describe data correctly.  From my point of view.  Soap is supported by AWS, so you can use your Ada web server  to provide some soap endpoints.  But who wants to have XML on the wire, XML everywhere,  describe everything in XML, and have a ratio between the payload  and the tags, which is on the side of the tags.  Compression.  Yes, of course, who is good to him?  DSA, OK, DSA is a real good candidate, but it's Ada only,  and we know that Alas, the word is also with C++ and stuff like that.  And finally, Corba, Corba is object-oriented, it uses an interface definition language.  It's binary on the wire, the same way as protocol buffer.  It appeared in 1991, so to compare to protocol buffer, which appeared in,  I think it was in 2008 or something like that.  So you can see that we are still keeping, reinventing everything.  And there are some language mappings.  So what does it mean?  Corba is common object-request broker architecture.  It's a standard from the UMG object management group,  which is a consortium of computer companies.  It was released in 1991 for the first version,  but the last one was released in 2011 or 2012.  It's object-oriented.  It uses a definition language, a strict one, but I will show you.  And it's language agnostic, but the standard mappings were defined in the standard.  So you can have an IDL and map it to C++, JVAADA, C, Cobol, Lisp, P1, Object Pascal,  Python, Ruby, and small talk.  So you can talk to everybody, almost.  No JavaScript.  Sorry.  Corba and Ada.  Corba and Ada are not very trendy, but together they do a great job.  So you know this is a quote from myself today,  because I've never been quoted before,  and I was really, really impatient to be.  So nobody quoted me today, so that's it's done.  Okay.  There is some code already available since almost one week.  Yes, but I've done it a long time ago.  Suppose we have a program which is very useful.  Yes.  Easy to use and integrate, because it's Ada.  But not designed for remote access,  because the main developer decided to put it only at the beginning as a command line tool.  Nezha for scalability.  Yes.  So what the program is, you will say it's obviously we need scalability for this.  So distribution is the solution to our problem.  The CBSG stands for Corporate Bullshit Generator.  The aim of the project is to providing the user sentences built against a vast vocabulary  and sentence constructions harvested during long boring meetings.  It's another piece of software provided by Gauthier de Montmolo.  So we had Zipada, Lib Zipada, and we had the Corporate Bullshit Generator.  And obviously you have an online version.  Let me show you this.  Here is the website for the Corporate Bullshit Generator,  which is using a brand new technology, CGI.  And here you can see with some beautiful website and beautiful interface,  where you can just, if I recall my mouse,  a many, many efficient button, when you click, you get five new sentences.  The category manager technically standardized our trends.  No problem.  I've been working in Airbus and I can tell you that I've heard some kind of sentences like this during the famous long boring meetings.  Yes.  And I'm pretty sure everybody has.  So it's important to make it distributed, so we will use define or IDF or CBSG.  So first let's take a look at the add-as specification for the Corporate Bullshit Generator.  It's a generic package where you have to provide the characters that will be used to format your text.  Then you will have four functions, sentence, gives you one sentence, workshop, I think it's 10,  short workshop, which should be five, and financial report, 100 sentences.  When you don't know what to do at night, you have to read this.  So the idea.  Ideal looks like C++, it's a standard from the UMG, I would say that UMG was mainly C++.  So you will find the beautiful curly braces over there and several, I would say that code formatting looks like C++.  Okay, not a great deal.  What a module is.  What it is, is the equivalent of a package.  It's a namespace for C++, it's a package in Ada.  You can define struct, struct are data that you can share from one object to another across the network.  And then we define interface.  Interface is the definition of the object that will share some functions with other computer.  Unlike the struct, the struct can come across the network.  An interface is an object which will stay on its server.  You won't get a new object by getting a reference on this.  It's really distributed.  First this, we will use poly-orbe.  Poly-orbe is a polymorphic reusable infrastructure for building object-oriented distributed systems.  It provides several middlewares through what we call application properties, personalities.  So with poly-orbe, you can do DSA, great, it's Ada, Cobra, and MoMA.  MoMA is message-oriented middleware for Ada.  That's it.  And then protocol personalities.  So you say how do you use the network to handle the three applications.  GIOP is the one which we will use. GIOP is generic inter-orbe protocol and has implementations such as IOP, Internet Inter-Orbe Protocol, SSL-IOP, DIOP-MIOP.  And the last one is SRP is a simple request protocol and it's based on HTTP.  The standard use we, the standard is to use GIOP with IOP.  Poly-orbe is maintained by AdaCore. It's available on GitHub.  But yes, I put this one because compiling poly-orbe is not that easy and so I wanted to put this and to show you that when you configure your poly-orbe,  you said which protocol you will use and which application you will use.  And for Cobra, there's something else called the Cobra Services.  The standard defines several existing distributed objects, naming, event, IR, notification, and time.  For those who are interested in the GitHub, you will have the standard code for the distributed corporate bullshit generator.  And you will have one using naming. Naming is in fact a kind of DNS for objects.  We have poly-orbe, we have our IDL, we generate some code thanks to this command line.  So what do we get? Ash, utilities, what we call skeleton, glue between the object request broker and the implementation,  and the implementation itself. Yes, skeleton, I love it.  So this is the Cobra architecture.  We will be on this side, so we call always the object the servant,  and the server will be the software that will show the servant to the network.  So the only things that we have to change is the implementation. I just put the first one, which is quite simple.  Instantiate your corporate bullshit with no marker, and then just provide the create sentence,  which is a wrapper around the simple generator.  And we are using Cobra, so we have to translate the Ada string to the Cobra string. Quite easy.  So the server, the server needs to initialize the best called the ORB.  We have something called the POA for portable object adapter, which is in fact the glue between the server and the server and the orb,  and that will provide you several things such as instantiation, characteristics, and so on.  Recreate the reference, we start the ORB.  This is the code. I just create the implementation,  get a reference on what we call the portable object, a reference, initialize all the machinery there,  and use then, I will show you, but the servant to reference.  I have my object, and I transform it into a Cobra object, and then print it on the screen.  It will print what we call Cobra lock, which is a string,  describing the object, providing a unique identifier of the object on the network.  Client, okay, we will be on the left side. Quite easy.  We generate the stub, init the orb, get the object, it's okay. We call the method, and that's all.  The same way we have to get the code from the ideal ADAC compiler,  and then provide the code for the server, which is initializing the orb,  convert the first parameter, which will be the Cobra orb, test that it's not new,  and then we get the message from the remote computer using the create sentence.  For fun, if we can call this fun, I made a C++ client, so you do exactly the same.  You generate a stub, you init the orb, get the object, and call the method, and that's all.  So it's C++, I won't be talking about this. It's almost the same.  Ah, the demo, yes.  So here it is.  Okay, I got the corbaloc.  I'll copy it.  That's the reason why you can use the naming server, because it's easier.  Ha! Wrong.  Great.  Yes, the generits are answered, and the state or ANSTEPA captures,  engage the intelligent cross-pollination. Thank you.  And the last one is using the structure, so you can see the timestamp for this.  Ha! Conclusion, why using IDI with Cobra?  Because you're using your favorite language.  That's one point.  You will put safety and readiness of IDI into an heterogeneous system,  using other components that will obviously fail, because they are not IDI.  And you will be using polyob, which is in itself something interesting.  And that's all. Here are the links for the further reading.  You have 20 seconds for questions.  And I'm pretty sure you won't have any more.  Oh, no.  Why did you recompile Polyob when you have the Debian package?  Because I'm using the decor version of the compiler,  and you have to compile Polyob with the same version of the compiler, as far as I remember.  At least for DC.  Yes, but you also have an ADAC compiler in Debian.  Yes, but I don't have Debian. I just have a Ubuntu.  And no, I won't switch to Debian.  No. Stop it right now.  Okay, we're running out of time.  Yes, of course.  Thank you again.  You're welcome.
Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_0_179.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_180_443.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_444_995.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_996_1295.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_1296_11867.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_11868_11963.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_11964_14771.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_14772_15431.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_15432_16079.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_16080_21083.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_21084_21263.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_21264_23039.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_23040_23147.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_23148_23627.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_23628_23699.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_23700_24311.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_24312_26075.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_26076_26147.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_26148_26567.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_26568_27023.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_27024_27575.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_27576_27635.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_27636_27695.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_27696_27755.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_27756_28451.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_28452_28667.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_28668_29075.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_29076_31391.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_31392_31439.png Distributed_Computing_with_Ada_and_CORBA_using_PolyORB_qdns5O6qyDY_31440_31592.png