Distributed Systems Annex, data sharing between programs

Shark8,

> Could you give examples of what sorts of tasks are better-suited/easier in DSA and YAMI4?

with Ada.Containers.Vectors;
package Flt_Vector is new (Positive, Float);
pragma Remote_Types (Flt_Vector);

with Flt_Vector; use Flt_Vector;

package A is
pragma Remote_Call_Interface;

procedure Call (V : in Flt_Vector);
end A;


Then using this from another partition across the network:

with A;
with Flt_Vector;

procedure Main is
V : Flt_Vector.Vector;
begin
V.Append (1.0);
V.Append (4.5);
A.Call (V);
end Main;

That is the vector is passed across the network and this just looks like
a procedure call in Ada. This is possible because the distributed
support is directly in Ada. With "foreign" distributed support (MPI for
example) you'll only get support for basic types. And of course, what is
done with Ada.Containers.Vectors is not magic, you can define your own
type and have serialization by specifying the 'Write and 'Read attribute
for the type.

Another very good point with the DSA is that the application can be
partitioned differently. With the same code base, just provides multiple
partitioning (different xyz.cfg passed to po_gnatdist). Where the
partition communication are hard coded into MPI you can in minute create
a new way to partition your DSA application and rebuild everything
without changing a line of code.

And if the code actually is on the same partition there is nothing
serialized, the call is direct as for non distributed application. This
gives the best performance in any partitioning.

Frankly I have used the DSA (I have also used MPI and RMI) and the Ada
solution is way better than any alternative I have used.

Note finally that AdaCore DSA support is done via PolyORB. This means
that you can communicate with your DSA application with CORBA or SOAP
for example. So you are not stuck on a proprietary protocol if you need
to open your application to other languages.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

On 2012-06-06 15:17, Simon Wright wrote:

>> http://msgpack.org/
>>
>> It is not complete in the sense that it covers only the serialization
>> part (and even there has many limitations), but for a number of
>> problems seems like a nice and easy, off-hand solution. Yes, the Ada
>> binding is missing there.
>
> I'm thinking I need a project; would anyone be interested in an Ada
> binding?

One middleware system I've used before is Ice (http://www.zeroc.com).
I'd love to see an Ada binding to it.

Peter

"Peter C. Chapin" <PChapin@vtc.vsc.edu> writes:

> On 2012-06-06 15:17, Simon Wright wrote:
>
>>> http://msgpack.org/
>>>
>>> It is not complete in the sense that it covers only the serialization
>>> part (and even there has many limitations), but for a number of
>>> problems seems like a nice and easy, off-hand solution. Yes, the Ada
>>> binding is missing there.
>>
>> I'm thinking I need a project; would anyone be interested in an Ada
>> binding?
>
> One middleware system I've used before is Ice
> (http://www.zeroc.com). I'd love to see an Ada binding to it.

That looks like a large-ish project. As of Feb 2011 there was no
documentation on how to approach such a project[1].

MessagePack seems to be similarly lacking. There's a singular lack of
comments in the source, I guess it's all obvious if you're a Ruby
guru. But at least the object format is defined!

[1] http://www.zeroc.com/forums/projects...-bindings.html

On 8 Cze, 04:11, Shark8 <onewingedsh...@gmail.com> wrote:

> Could you give examples of what sorts of tasks are better-suited/easier in DSA and YAMI4?

Pascal already provided example where DSA is attractive due to its
integration with the language. Note the pattern: Ada is a synchronous
sequential[*] language, so if your distributed problem is of the same
nature, then the DSA solution will look natural.
[*] this means that your problem can be described as a sequence of
steps where each step has to finish before the next step begins.

Now, the contrary example.

You have a system with several thousand machines and you want to send
them new configuration or something. You know the locations of those
systems, but the little problem is that with this scale some of them
are not working at all, some are hanging and some are overloaded and
therefore process everything very slowly. And you cannot do much about
it. And you have to send them the new data within very short time
frame. How short? Let's say several seconds.
The synchronous-sequental solution has a loop over the targets and a
remote call of the kind that Pascal has shown. This does not work. It
would not work even if all the targets were in a perfect shape.
A naive extension of this solution involves creating some tasks to
make things go in parallel. This is bad design, as the parallelism
already exists in huge amounts - remember, there are thousands of
machines over there, right? So why do we have to create tasks locally,
if the parallel resources are elsewhere? OK, let's shove this
conceptual issue under the carpet, but then - how many tasks should we
create? This is where DSA (or CORBA or ICE or similar solutions from
the same paradigm) proves to be actually very low-level instead of
high-level and forces us to think in terms that are very distant from
the actual problem at hand.

The solution is to stop thinking in terms of RPC (remote procesure
calls), and start thinking in terms of messages. If you lift the
concept of the message to the level of a design entity (yes,
distribution is *not* transparent and it *cannot* be an afterthought),
then some cool things are possible - just create thousands of messages
and let them go. No need to create additional tasks and no need to
wait for consecutive steps, as everything can happen in parallel
naturally. The original problem becomes feasible even in the presence
of partial failures, because separate message do not have to see their
delays and their individual communication problems.

Another example of this paradigm shift is a trading system, where you
want to inform all interested participants about a price change. Say,
there is a new price of the IBM share and you want to send it to
everybody. The difference from the above example is that this time you
don't really care (and therefore don't need to know) who is
interested. But you still have to publish this data somehow.
The DSA (CORBA/ICE/etc.) solution is lots of coding. Lots of low-level
code that has very little connection to the original, high-level
problem ("publish new price").
The messaging system allows to solve it differently, exactly thanks to
the fact that a message becomes a design-level entity. Create a new
message and give it to the broker - he will take care of it.
Hey, if the message is a first-class entity, then you might try to do
even more funny things with it - why not store it? Why not "record"
the stream of messages and "replay" them later? Why not attach some
security-related stuff to it, like digital signatures or access
control lists? Or maybe route tracing? This is just the tip of the
iceberg.

YAMI4 is a messaging system, where the programmer deals with messages.
This is the fundamental difference from DSA, where the programmer
deals with calls. Ironically, the lack of language integration is both
a disadvantage and a big advantage of messaging systems - the
advantage being that if there is no integration, then the language
rules do not limit what you can do.

More here:

http://www.inspirel.com/articles/RPC_vs_Messaging.html

Also, in the last section titled "Message-oriented middleware":

http://www.inspirel.com/articles/Typ...iddleware.html

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

>The solution is to stop thinking in terms of RPC (remote procesure
>calls), and start thinking in terms of messages.
How about asynchronous remote procedure calls. They just
fire-and-forget the parameters/message to a remote procedure. Or in the
example of possibly dead targets, use synchronous RPC that handles
Communication_Error.
But setting up the partition mapping for thousands of partitions might
indeed be inappropriate.

On Fri, 8 Jun 2012 14:26:55 -0700 (PDT), Maciej Sobczak wrote:

> Now, the contrary example.
>
> You have a system with several thousand machines and you want to send
> them new configuration or something. You know the locations of those
> systems, but the little problem is that with this scale some of them
> are not working at all, some are hanging and some are overloaded and
> therefore process everything very slowly.

In our case the locations are unknown. The middleware supports discovery
and identification.

Another typical case in process automations is when there are many
thousands of process variables distributed over not so many hosts. The
variables are not well known in advance, some may be unavailable at time.
Others are optional and created dynamically on request.

Anyway, synchronous communication is not an option in any realistic process
automation setup, even if real-time. Not worth to consider. Especially
because some data distribution layers are logically and physically
unidirectional, various 1-to-N schemes.

Our middleware supports synchronous calls, but they are implemented on top
of an asynchronous layer as send/request + wait.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Maciej,

> The solution is to stop thinking in terms of RPC (remote procesure

Right.

> calls), and start thinking in terms of messages. If you lift the
> concept of the message to the level of a design entity (yes,
> distribution is *not* transparent and it *cannot* be an afterthought),
> then some cool things are possible - just create thousands of messages
> and let them go. No need to create additional tasks and no need to
> wait for consecutive steps, as everything can happen in parallel
> naturally. The original problem becomes feasible even in the presence
> of partial failures, because separate message do not have to see their
> delays and their individual communication problems.

I don't agree, I've done that.

One partition keeps a list of "job" (what you call message) in a
protected object.

package Job is
pragma Remote_Types;

type Object is tagged...

package Job_Queue is
pragma Remote_Call_Interface;

function Get return Job.Object;

...


And then each remote partition get a new job when needed. This ensure
proper use of the resources as it naturally give good load balance. The
speed of the remote machine or network is not an issue in this design.

Again, I find Ada solution really good.

The only point is that the Job above must be large grained ones. But
this is true for every distributed applications where the cost of the
network transfer must not negate the computing speed up.

Also note that with the design above you don't need to go distributed
only. You can also create some tasks on a single application to get
multiple jobs on the same machine which is surely multicore, this also
ease the debugging.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

On 9 Cze, 03:10, tmo...@acm.org wrote:
> >The solution is to stop thinking in terms of RPC (remote procesure
> >calls), and start thinking in terms of messages.
>
> * How about asynchronous remote procedure calls. *They just
> fire-and-forget

Exactly. The difference is that with messages you do not have to
*forget*.
Firing and forgetting is easy - but firing and getting results later
on or just checking what has succeeded and what has not is an entirely
different use case. Messaging provides a valid solution to this
problem, while RPC not so much.

>*Or in the
> example of possibly dead targets, use synchronous RPC that handles
> Communication_Error.

That can take several hundred milliseconds (or even many seconds) for
a failing call. Remember - you have *thousands* of targets.

> * But setting up the partition mapping for thousands of partitions might
> indeed be inappropriate. *

Yep. The point is - this is no longer a single program. Just as our
communication here is not between separate partitions of a single
human entity, but rather between separate and autonomous entities.
Look, we don't even need to be awake at the same time for this
communication to happen. Why? How would you do that with "calls"
instead of "messages"?
Our posts here are messages, not calls.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Maciej,

> Yep. The point is - this is no longer a single program. Just as our
> communication here is not between separate partitions of a single
> human entity, but rather between separate and autonomous entities.
> Look, we don't even need to be awake at the same time for this
> communication to happen. Why? How would you do that with "calls"
> instead of "messages"?

As said in my previous message. With a queue. I have used this scheme,
it works perfectly well. You can even launch new message consumers
dynamically or stop some. You can also start new message producers, and
of course to avoid bottleneck you can have multiple queue on the network.

All this is just easy with Ada DSA, and safe as for all other Ada features.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> Now, the contrary example.
>
> You have a system with several thousand machines and you want to send
> them new configuration or something.

Do you know about pragma Asynchronous (aspect Asynchronous in Ada 2012)?
It causes an "RPC" to behave like a message rather than a call
(so it's not really an "RPC" anymore).

So with DSA, you can loop through those thousand machines,
and do an asynchronous "call" to each. This just sends
a thousand messages -- no waiting for replies, no dealing
with failed nodes, etc.

- Bob

On 9 Cze, 14:25, Pascal Obry <pas...@obry.net> wrote:

> > How would you do that with "calls"
> > instead of "messages"?
>
> As said in my previous message. With a queue. I have used this scheme,
> it works perfectly well.

Yes - you have just implemented a message-oriented middleware on top
of some low-level primitives known as "calls". If you have a queue,
then you have some items in there - these are exactly the messages
lifted to the level of design entities, as I've described earlier. A
push-pull queue was easy to implement on top of RPC, but what about
push-push queues? What about N:M publish-subscribe? This is where
messaging appears to be a higher-level concept.

Actually, I'm pretty convinced that RPC and messaging are
complementary and can be used to implement one another. As Dmitry
said, RPC can be achieved by send+wait on a message and as you say,
passing messages around is actually executing possibly remote calls on
some intermediary entities like queues or brokers. The question is -
when you will have to do more coding (and have more impedance
mismatch) to get from one paradigm to another.

> You can even launch new message consumers
> dynamically or stop some.

Uhm... remember the original post in this thread, by Adam? It is not
actually clear whether this is kosher or not. ;-)

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

> Our middleware supports synchronous calls, but they are implemented on top
> of an asynchronous layer as send/request + wait. (Kasakov)

(Secret technology?)

This thread is fascinating.

Make RPC based on messages (Kasakov and others) or vice versa (Obry and others)?

FWIW, I tend towards the latter. It's clearly the Ada way:

Ada offers asyncronous control already. Chapter 9. So it's just a matter ofwrapping the RPC with the desired asyncronous logic (a task, the time out idiom, ATC...)

Distribution and synchronicity are orthogonal dimensions. Probably Ada has been designed with this in mind. Distribution => Annex E. Synchronicity => chapter 9.

Yes, an implementation of Annex E may be based on messages e.g. sockets, and therefore asynchrounous RPCs in Ada (let the oximoron pass this time) will compile to an asynchronous-synchronous-asynchronous tower. Maybe there isa performance penalty here. Maybe for some projects climbing this tower would take too long, and so they use a message protocol directly for the message abstration. I cannot think of any other reason to depart from the Ada way.

(Is it really true that Polyorb is the only Annex E implementation that exists? Or just the only libre one?)

On Wed, 13 Jun 2012 03:55:47 -0700 (PDT), Marius Amado-Alves wrote:

>> Our middleware supports synchronous calls, but they are implemented on top
>> of an asynchronous layer as send/request + wait. (Kasakov)
>
> (Secret technology?)

Just proprietary

> This thread is fascinating.
>
> Make RPC based on messages (Kasakov and others) or vice versa (Obry and others)?

No, our middleware is not message-oriented and generally not client-server.
it uses process variables instead and has the topology of a bus. (Messaging
could be a transport)

> FWIW, I tend towards the latter. It's clearly the Ada way:
>
> Ada offers asyncronous control already.

(which most likely does not work a naive reader would expect)

> Distribution and synchronicity are orthogonal dimensions.

Yes.

With distribution come issues like quality of data and other attributes of
values missing or handled differently in monolithic coherent applications.
There you would simply handle poor quality as exceptional (or even a bug),
raising Data_Error or Constraint_Error. In a distributed application you
usually have competing sources of data and errors related to the
availability of these sources. You rather store quality, timestamp etc as
additional attributes instead of raising exceptions, which cannot be
handled meaningfully right now and here. It is a different mindset.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

> (Is it really true that Polyorb is the only Annex E implementation that exi=
> sts? Or just the only libre one?)
Several years ago I made, for a project, a Package body System.RPC and
some text processing tools to create stubs, etc. But without specific
compiler support, that approach leaves a lot to be done manually.