We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Live Demo of Ada's Distribution Features

00:00

Formal Metadata

Title
Live Demo of Ada's Distribution Features
Title of Series
Number of Parts
490
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Ada incorporates in its standard a model for distributed execution. It is an abstract model that does not depend on a particular kind of network or any other communication mean, and that preserves full typing control across partitions. This presentation briefly exposes the principles of Ada's distribution model, then shows the possibilities with life demos across different machines and operating systems
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
Computer programComputer programmingComputer animation
Representation (politics)Operations researchComputer programmingSystem programmingImplementationFreewareProgrammer (hardware)Read-only memoryComputer programIndependence (probability theory)Computer networkInterface (computing)Partition (number theory)Plane (geometry)WhiteboardCoprocessorLocal area networkComputerPhysical systemDistribution (mathematics)Regular graphComputer programPartition (number theory)Representation (politics)Position operatorNumberSet (mathematics)Stress (mechanics)Table (information)Context awarenessLevel (video gaming)Thread (computing)Process (computing)Goodness of fitPointer (computer programming)Morley's categoricity theoremMachine visionSemiconductor memoryDegree (graph theory)AdditionAddress spaceImplementationTask (computing)Model theoryRemote procedure callPiForestSlide rulePrice indexMultiplication signObject (grammar)Natural numberCompilation albumProcedural programmingCategory of beingType theoryFlow separationCodeChainPlastikkarteNeuroinformatikDifferent (Kate Ryan album)CompilerVirtual machineWhiteboardPattern languageComputer hardwareLocal area networkExecution unitPhysical systemFormal languageComputer fileMappingBefehlsprozessorOcean currentCoprocessorSingle-precision floating-point formatReal numberSoftwareJava appletDistribution (mathematics)ConcentricShared memoryIP addressClassical physicsLocal ring1 (number)AreaSystem callComputer animation
Representation (politics)Distribution (mathematics)Regular graphIndependence (probability theory)Type theoryOperations researchSystem callSemantics (computer science)Pointer (computer programming)Exception handlingClient (computing)Distribution (mathematics)Remote procedure callServer (computing)Object (grammar)CompilerData transmissionFunction (mathematics)Mechanism designNormal (geometry)Category of beingError messageCodierung <Programmierung>PasswordEncryptionPhysical systemCartesian coordinate systemSocial classPointer (computer programming)Object (grammar)Partition (number theory)CodeServer (computing)ConsistencyDisk read-and-write headRepresentation (politics)Type theoryTerm (mathematics)Virtual machineConfiguration spaceComputer programStreaming mediaInterface (computing)CompilerPasswordGoodness of fitSemantics (computer science)System callException handlingRemote procedure callDistribution (mathematics)SoftwareNeuroinformatikSharewareData typeMathematicsMultiplication signDifferent (Kate Ryan album)Level (video gaming)QuicksortTransformation (genetics)Dependent and independent variablesSpeech synthesisTwitterFamilyUtility softwareDatabaseVideo gameHypermediaQueue (abstract data type)Table (information)Game theoryShared memoryInheritance (object-oriented programming)Software protection dongleCausalityDemosceneComputer animation
Distribution (mathematics)Expected valueLetterpress printingMultiplication signComputer programVideo game consoleClient (computing)TorusDifferent (Kate Ryan album)Right angleTerm (mathematics)MathematicsMessage passingMoment (mathematics)Category of beingComa BerenicesNumberCASE <Informatik>System callInterface (computing)Function (mathematics)Remote procedure callMorley's categoricity theoremServer (computing)BitCountingComputer animationLecture/Conference
Video game consolePoint (geometry)NumberClient (computing)Message passingProgrammschleifeTorus2 (number)Term (mathematics)Partition (number theory)Letterpress printingMoment (mathematics)Computer animation
Hand fanServer (computing)Client (computing)WindowInterface (computing)MiddlewarePartition (number theory)Physical systemMessage passingSharewareLevel (video gaming)Remote procedure callMultiplication signSystem callCountingDirectory serviceBitLetterpress printingCompilerStructural loadConfiguration spaceVirtual machineComputer fileMathematicsCompilerVideo game consoleGastropod shellInternetworkingDistribution (mathematics)Execution unitData storage deviceResultantFreewareComputer clusterBoiling pointArithmetic meanProcedural programmingScripting languageSingle-precision floating-point formatTerm (mathematics)DemosceneKey (cryptography)HypermediaPublic domainComputer animation
CompilerPhysical systemMessage passingConfiguration spaceVirtual machineComputer programServer (computing)Partition (number theory)MereologyLine (geometry)Letterpress printingStructural loadComputer fileTorusHeegaard splittingDistribution (mathematics)Scalable Coherent InterfaceArithmetic meanChainFigurate numberSoftwareComputer clusterComputer animation
Directory servicePhysical systemComputer fileNumberCompilerEnterprise architectureCoordinate systemComputer animation
WritingDistribution (mathematics)Musical ensembleReading (process)AbstractionInstance (computer science)Tape driveLaceData bufferNeuroinformatikServer (computing)Type theoryArithmetic meanBit rateSoftwareCategory of beingState of matterSound effectInstance (computer science)Computer-assisted translationPointer (computer programming)Tape driveRemote procedure callSystem callInterface (computing)Object (grammar)ImplementationDegree (graph theory)Table (information)Computer clusterNetwork topologyClient (computing)Distribution (mathematics)Computer programProjective planeDevice driverPoint (geometry)Level (video gaming)CrosswindExtreme programmingProcedural programmingWordAreaSharewareWritingBitConfiguration spaceRegular graphMorley's categoricity theorem.NET FrameworkComputer animation
Goodness of fitBitModal logicMultiplication signHypermediaAirfoilComputer animationLecture/Conference
NeuroinformatikPartition (number theory)HypermediaWindowIntegrated development environmentAreaLine (geometry)AirfoilTorusSoftwareBitMiddlewareFirewall (computing)SharewareBootingOffice suiteString (computer science)Near-ringVirtuelles privates NetzwerkComputer animation
IP addressPartition (number theory)Core dumpObject (grammar)MetreGoodness of fitMultiplication signHypermediaRule of inferenceCoefficient of determinationThermal expansionSoftwareKey (cryptography)PreconditionerCompilerImplementationTransportation theory (mathematics)TelecommunicationWordDistribution (mathematics)Computer simulationDifferent (Kate Ryan album)Communications protocolView (database)FreewareSystem callException handlingPhysical systemComputer networkMiddlewareInterface (computing)Server (computing)Right angleTranslation (relic)
Formal languageShared memoryObject (grammar)Computer clusterCartesian coordinate systemComputer animation
Heegaard splittingFlow separationComputer programType theorySingle-precision floating-point formatPartition (number theory)Cartesian coordinate systemRepresentation (politics)Different (Kate Ryan album)Object (grammar)Core dump
Point cloudFacebookOpen source
Transcript: English(auto-generated)
Okay, so our next speaker is, once again, myself, Jean-Pierre Rosin, about distributed
programming. So, this was announced as a live demo, which is always frightening because you never know
if it will work. So I'll try to go relatively fast on the slides, then we'll make the demo, and if we have some spare time, I'll show you another example, or maybe we can just come back to some of what I said.
So, this is defined in the reference manual in an annex, in the distributed systems annex. So it means that it's not required from every compiler to implement that. In practice, only Gmat did implement that, and I'm a bit sorry about that because it's
a real nice feature of Ada, and it would be nice if we had other compilers to implement it. So, to understand what it means, it's about having one program distributed over several machines. You know, distributed systems that work well with several, in general, executions
concurrently may have different levels of coupling. You have tasking, when it's inside a single program with shared memory. Then you have the distributed systems annex, where it is a single program which is split
over several computers, okay? And then you may have different programs communicating over the network. So here, it's a single program, so we'll see it keeps all strong typing and all the
checks that you can have, but still running on several machines. And the goal of the annex is to make the programmer concentrate on the problem and be freed from all the nasty details of networking, communication, differences in representation,
and all those programs that plague distributed programs. So an Ada program is made of several partitions. So, it's a very abstract definition, but to be honest, it's several executables, okay?
You have several executables. You run them together, and together they build the whole program. You have active partitions that can run any program, also passive partitions that can contain code and data, but no task, nothing that's active.
You can even have several main programs. The language requires only at least one main program in one of the partitions, but you may have several main programs, including one in each partition.
So this maps to different patterns. For example, if you imagine hardware boards plugged in a backplane, so an active partition will be a processor board with a CPU and whatever, but a passive partition will be a
memory board. You can have RAM for variables, RAM where you have the code of your subprograms, but nothing that can run directly on the board. On a local area network, while it's a classical stuff with computers, you may wonder how
you could make passive partitions. Actually, Ignat manages to be able to have passive partitions. Each variable is modeled as a file over NFS. Not very efficient, but it works, and it provides you with persistence by the same token, so it can be quite interesting if you don't abuse it.
And even at the level of an operating system, while you could view the active partition as the process level, tasking is about the threads level, and that would be about the process level, and for example, a set of subprograms that is shared between several
executables, that would map to a DLL. So I'm not saying that the current Ignat implementation does all that, but I want just to stress that the model is not linked to a particular model.
It has always been intended to be implementable in several contexts. What I mean is if you take, for example, Java's remote method invocation, you designate a remote object through its IP address.
So it's purely internet, there's nothing else you can do with it. Here it has been carefully made independent of any particular network. So of course, not all data can circulate on a network.
A task, a pointer would be hard to, if you exchange them, that would not be possible or it would be meaningless. So you need to have some restrictions. So the idea is you have a number of aspects that define how a package will behave regarding
distribution. I won't go into too many details, but just to mention, you have a regular package that has no categorization. These are called categorization aspects.
Without categorization, the packages are duplicated, so they are independent. If you have a variable in a package in a partition, that variable is not related to the same variable, while with the same name, in another partition. Your shared-passive packages are used to manage the data that's directly shared, so
it's a common memory between the different partitions. Remote types allow the definition of types that can be exchanged between the partitions.
And remote call packages are the most interesting ones, the ones that can make RPCs, RCP, remote procedure calls, where you can, from a node, from a partition, call something that physically resides in another partition.
And for each kind of categorization, of course, there are a number of restrictions about what you can do. Those restrictions are very complicated. You don't need to understand how it works. You put the categorization, you compile, and the compiler will tell you what's allowed
and what's not allowed. In Ada, we trust the compiler, you know? And since all the consistency of the program is guaranteed at program level, it means that all the data representations are guaranteed to be consistent over all the partitions.
So you get a remote call. When you call a subprogram that's something in another partition, directly by calling what is called a remote subprogram, so a subprogram with the aspect remote call interface,
so classical RPC, of course, you have to know the name of the package. If you call a subprogram, you have to know the name of the package. So in terms of distribution, it means you know the server.
You have a certain special kind of pointer that allows you to designate a subprogram in another package. So it's a typical callback where you can call back a subprogram through a pointer in
another partition. But then you have to get the pointer from somewhere, so you have to have some kind of name server that will provide you with the pointer to the subprogram being called.
And you can also have remote objects, the famous remote access to class Y types. So basically you can have a pointer to an object in the sense of a tag type, and you can invoke methods of objects that are located in a remote node.
So you can have distributed objects and directly call the methods of the object. Once again, since you need to first get the pointer to the object, then you need some
name server. And the whole semantics of Ada is preserved. So if a remote call raises an exception, you'll get the exception. All typing are checks to be consistent, and so on. So distribution is completely transparent, at least for the client, for the caller.
When you transmit data over the network, the interface is designed in such a way that it uses the streams mechanism. In Ada we have streams inspired, without any shame, from C++ streams, and you have standard
streams provided by the compiler, and you can redefine the streams. So the marshaling operation, transforming your high-level data type into a stream of
bytes, is performed automatically by the compiler using the stream that you can redefine. So for example, if you have a type name, for example, password, you can redefine a marshaling function so that this type is always scripted, and that your own
redefinition will be used by the compiler, and therefore you are guaranteed that never to have a clear password over the network. So it means that strong typing is totally preserved.
You don't send bytes. You send, you exchange, through the normal mechanism, high-level data. So how would you write, in general, a distributed application? First of all, very important, you don't care about distribution.
It's very tempting when you know that you have something that will work on several computers to think first, oh, what am I going to put on that computer and that? If you do that, any change will require a total redesign of your application, and it
will be extremely costly. Now, the best way to design a distributed application is first to design your program on your own machine. It works, and you debug it, and you design it as a regular application.
Then you categorize. You look at what you've done. You said, well, these are some casual utilities, I don't need anything special. Here I have a centralized database, so it must be shared if it's ever distributed.
Here are the types that are used to exchange data with that database, and so on. So you just drop those little aspects on your code. You recompile, and you bow your head because, in general, there will be some restriction
that's not obeyed, so you need to change things here or there to make sure that it corresponds to your intent. That's quite often, for example, you take off some type definition from a package to make a special remote types package or some changes like that.
Then you decide on the distribution. You decide that you will make three partitions, and, well, the only shared package are the remote call interface packages and, of course, the shared passive. So these are to be attached to some explicit partitions.
This is done thanks to a configuration file, and I'll give you an example shortly. Okay? You recompile, the compiler will care about everything, and you will get as many
executables as you have defined partitions, and then it's up to you to start your partitions where you want, maybe on the same computer, maybe on a different computer. Okay? So that looks like a miracle.
Are there some people who ever wrote distributed applications here? Yeah. Okay, good. So you appreciate the demo. Okay. I'll turn now to this.
Okay, it's a very simple program, and here I just have all the printing is done through that console package. So console, can you read it or it's a bit too small?
Okay, sorry. Okay, that's better. So it's just a package, and we print by, for the moment, it's a regular package, no categorization.
Okay? Then I have a server. This is a remote call interface package. You see, there is a primary remote call interface.
And what it does, it registered clients. So when a client comes, it calls register. It keeps account of the number of registered clients. And when that count reaches the expected number, in that case three, then I have a function
must terminate that tells that now everybody has arrived. So I can show you quickly the body if you want. Come on. Okay, I'll do it this way.
So you see, I just have a global counter. But it's to show you that that counter must be shared between the different partitions, of course. And then the client, a very simple also, we'll see, ah, just not, okay.
So the client just registers, it prints a message by printing message, well, it keeps the time, and why not must terminate, why not everybody there, it loops saying it waits for a certain number of seconds, delays one second, and when terminate, must terminate
becomes true, it just prints that it's terminated, okay? So for the moment, the interesting point is the console that prints the message.
Now it's a regular package. It will be duplicated in each partition. So I prepared everything so we don't waste time, but believe me, I didn't cheat, so if you want me to recompile in front of you, I'll be happy to do it, okay? But we are not here to watch compilation time.
So if I start partition one, it should start shortening. Oh, I forgot to mention the server itself, the server package prints when a new client
arrives. So you have seen that. Can you see that? Excuse me? Oh, yes, sure. That's better. Okay, a bit small, but I think you can see, so it prints in its own window, and
I start the second partition, which is printing. You see the server print on the left, and here it prints on its own window, okay? If I start a third client, then everybody terminates, the count has been reached, and
everybody terminates, okay? Now let's have some fun. I change to another directory where I prepare the second step of the demo.
Okay, so now, oh, I forgot to show you something important, sorry, the configuration.
So this is the file that defines the distribution, the configuration. Here you see I just declared three partitions, and I have only one remote call interface package, the server, so I said that the partition one contains the server.
Client is my main procedure, and well, in that system there is a kind of main main procedure, you know? So this one is in partition one, and there is a secondary main in partition two and partition three.
That pragma starter here, because I need to start all this in three different windows, I start them by hand. But you can have the compiler generate automatically a starter that will run every partition in, you can tell on which machine and so on.
And the funny thing is that starter can be written either in Ada and automatically compiled or generated as a shell script. So if you want to see what happens, and that's generated automatically.
Okay, so we move to step two. What did I change here? Very few. I just added in my console pragma remote call interface.
I didn't change anything else, but now, in a sense, I have a printer server. Instead of each partition printing in its own domain, I have a shared printer server.
And at the level of the configuration, you see I just added console, since now it's a remote call interface package, it has to be assigned to a certain partition.
So I assign it to partition one, and the rest is the same. And then you recompile, and I start partition one.
There is a kind of middleware in behind. If I have some time, maybe I told you. For now, it seems like before, but if now I start partition two, all messages for partition two are printed in the same window, because that's the first window is where
the printer server resides. Okay, and of course, if I start my third partition, we'll see a new client, and then everybody terminates.
Okay, now imagine that I made some insufficient design about the load of my server, and that first server is really too heavily loaded. Okay, that happens quite often on distributed systems.
It's hard to foresee what the actual load will be. So I decide I'll put a fourth machine that will just hold the message server, the console. Fine, step three here.
I didn't change anything in the eta. I just changed the configuration file.
I define a fourth partition here where I put the console. Okay, that's all I did. I didn't change the software at all. Recompile.
Okay, it's here. So let's start partition one. Nothing happens. Of course, it's printing in partition two, in partition four. Okay, let's start it now. And you see all the messages are now moving to that dedicated partition for printing.
Okay, of course, if I now start partition three up, everybody terminates nicely. So this is just a small program to demonstrate it.
But think about it. I first started with no centralized server. Each part of the program used its own local server. Then I decided to have one centralized server to do everything.
I added one pragma, changed the configuration file, and recompiled. That's all I had to do. And then I decided to change the way the load is split on my different server. I had a new machine with a new server.
I changed one line in my configuration file. I didn't change my eta software, and I had my new configuration. Okay, so generally people who never had to cope with distributed systems find that very nice.
Those who had to cope with distributed systems are absolutely stunned by this, because all the hard work — yes, I have some spare minutes, I can show you something — is done by the compiler.
When you compile something with the distribution, you see here a little directory that appears with the name DSA. That means distributed systems architecture. And if you look at that, you'll see the partitions, and you'll see all the files.
You'll see a number of eta files here that are all automatically generated by the systems and compiled by the system that ensure the whole of the data transmission, the coordination, finding the name server,
and all those things that you need when you are doing a distributed system, all generated automatically. Okay, fine.
So, well, since we have some more — oh, we started. So now I'll show you another example how to make distributed objects.
So it's not a live demo because it would be a bit long today. Imagine you have a tips — well, nowadays, of course, you don't use tips anymore. But it could be any server. Do you?
Well, for archiving, well, when you see the amount of data you can put on a microSD card, it's very impressive. Anyway, so imagine I have one computer here, here, here, that manages tapes, okay? So first I define an abstract data type, tape,
with pure means it's another categorization package. That means that there is no side effect. And, well, the basic operation, rewind, read, and write. Okay.
If I want to access a distributed object, I mention that I need a name server. On a different partition, I have that name server here. So it's a remote call interface, so you know where it is.
And it defines a pointer to that tapes.instance tick class. So it's a class-wide type, a type that encloses all dissonance. And since it's a regular name server,
you register a pointer to a tape under a certain name. You can find from a name the pointer, the corresponding pointer, and you can unregister it if you want. Now you have an implementation of that object.
So a tape driver. And so you define your own tape if you want the driver, the concrete implementation of a tape drive, and so you redefine the procedure, rewind, read, and write.
By the way, the overriding keyword here makes sure that you are actually redefining a method and not due to some typo or anything else, defining something new. You declare two tape objects here,
and you register those tapes under a certain name to the name server. So you send to the remote name server a pointer that, through the network, designates your two tape drives.
And then the client, which is a normal program without any categorization, can declare two objects of that pointer. It will ask the name server to give the pointer
that through the network designates those tape drives, and use that as usual. Now, maybe you didn't notice that. But there is nothing in that example that refers to distribution
except some pragmas here or there. You just write it as a normal software, and then you write your configuration to tell which computer you want your tapes, on which computer you want the name server. And normally, you build your program by calling
netmake or gprbuild on your project file. All you have to do is call pognetdist on the configuration file,
and it will recompile everything, and that's all you need. Okay, oh, I've been even a bit earlier. We have five minutes for questions.
Wow, so impressed. Yes, please. Go ahead. Okay, well, there is, of course,
oh yes, so the question was about the communication, and the necessity of a firewall, and problems with firewalls, and so on. Of course, you need some middleware, and I was afraid of being a bit short in time, so I didn't put the slide,
but there is middleware that's provided. I won't cheat, I'll show you. Here, in that window, you have the middleware running, okay? And when the middleware starts, it gives you a magical string that's somewhere here.
Okay, polyorb, koba, name service, blah, blah, blah, blah, and you have to set some environment variable to that magical string so that you have to boot from something, from somewhere, of course.
Now, of course, that middleware must be accessible from your partitions. So, of course, if you have firewalls in the middle, actually, I intended to make the demo a bit more impressive
by having one of the partitions running on my computer at Isilé Mulino near Paris, okay? And through, of course, a VPN. But it happens that the Wi-Fi here, there is a firewall that does not let the VPNs.
Okay, so I had to make it local, okay? Normally, it would have been even better because, well, trust me, I'm sorry you've come to my office in Isilé Mulino. I can show you that it's exactly the same thing
if one of the partitions is running Linux inside of Windows, okay? It works exactly the same. But, of course, you don't get rid of all the problems inherent with networks. Other questions?
Okay, if it's not available when you start, you have an exception and the partition doesn't start.
If you lose it, well, actually, the middle, maybe the data core people could answer that better, but the middleware allows you to exchange the IP addresses of the various partitions. I'm not sure that it plays a role once it's completely started.
No, okay. Well, it's a very specialized domain, so you have two or three guys at IDACOR that know the answer and the others trust them. There is an exception that's intended for communication problems in the network interface.
Yes, I can mention that now. All communications have to go through a dedicated package called system.RCI, and the implementation of that package
is in charge of the transportation layer. And the standard makes it very explicit that you are allowed to provide your own implementation in that package.
It means that if your compiler supports that annex, and you have some proprietary networks, safety critical, whatever, then you just have to rewrite the body of that package to handle all the communication. But the compiler does not know about the transportation layer,
so you can use various networking solutions with that. Okay, something else, yeah?
No, no, it's special to the polyorb implementation. Oh yes, I was talking about that and I wondered somewhere else, but here the middleware I use is called polyorb.
It's something that's provided by IDACOR also, and it's called a schizophrenic middleware, because it has several personalities in the same person at the same time. So it is a middleware for the distributed system annex,
but at the same time, it's a COBA server and an MME or something like that server, some other protocol, and it allows the simultaneous views of the same object. So you can declare a distributed object in Ada as a tag type,
and from your C++ application, it will be viewed as a COBA class. Okay, so you can exchange data with different protocols and the middleware, that's the translation between the different views,
the different personalities of the middleware. Anything else? Okay, I think I'm right in time. Yeah, okay, with pleasure.
Now, in COBA, you declare the types,
and it's intended for different applications that communicate through shared objects, and you hope that the idea is the same on the various applications. Idea is the COBA language for defining the shared objects,
but there is no cross checks, for example, that the various applications use the same definition of your COBA object. In Ada, it's all compiled together with all the type controls that we are used to with Ada.
So there is a guarantee that the data representation and the objects will be the same in all your partitions, but it's a single program split over several partitions. With COBA, it's more a way of having different programs that communicate through objects. So there is a difference.
Okay, thank you for your attention.