Distributed Systems Annex, data sharing between programs

I haven't had much need to look at the Distributed Systems Annex until recently. I'm finding that the answer to a simple question is eluding me: Can the execution of a single partition be part of the executions of two or more Ada program executions (whether executions of the same program, or of different programs)? To explain further: Suppose a program P WITH's a Remote_Call_Interface package R, and R has global data in its body, and R providesoperations that modify and retrieve this data. Suppose that R (and everything it needs) is put into its own partition, while the rest of P is put into another partition. Now, if the partition containing R is run just once, and the other partition is executed multiple times, do they share the same data in R's body? That is, if one execution of P calls a routine that modifies the global data, and another execution calls a routine that retrieves it, will the second execution retrieve the data that was set by the first execution? Similarly, suppose that two different programs WITH R, but the partition containing R is executed just once; do the two programs share the data in R's body?

My first impression is that the answer is "no". The introduction to Annex E talks about "multiple partitions working cooperatively as part of a single Ada program" and other similar wording, which seems to preclude the possibility of partitions being part of more than one program. Also, the note in E(7) says that the resulting execution is semantically equivalent if the program is partitioned differently; and since two executions of the same program obviously can't share data like this if the entire program is put into one partition, it wouldn't be semantically equivalent if they shared datawhen R is put in its own partition. Still, 10.2 is somewhat vague about the different ways partitions can be executed, and I'm confused by examples such as
http://www.adacore.com/adaanswers/ge...ed-name-server
that appears to be set up so that multiple executions of the same "client" partition cause data to accumulate in a server partition. This strikes me as being outside of the paradigm defined by the RM--but is it, or am I just confused?

If my understanding is correct, my next question is: is there any language-defined support for sharing data between programs (besides file I/O), or does this require using an outside library for (say) socket communication or memory sharing?

-- thanks, Adam

On 4 Cze, 20:49, Adam Beneschan <a...@irvine.com> wrote:

> I haven't had much need to look at the Distributed Systems Annex until recently.
[...]

These are very interesting observations.
I would like to add my two cents to them, as they are related in
particular to this:

> Also, the note in E(7) says that the resulting execution is semantically equivalent if the program is partitioned differently;

DSA is intended to provide transparent "distributability", where
transparent means that the physicality of distribution is as hidden as
possible (ideally it should be undetectable). The problem that I see
is that Ada distinguishes potentially blocking operations from those
that never block and allows to use only the latter in protected bodies
- now, if we repartition the program in such a way that a given
operation (Do_Something_For_Me) ends up in a separate partition, it
might become potentially blocking by virtue of the hidden physicality
of remote call. In short, it might become a I/O operation even though
it is not visible anywhere. If such operation is used within a
protected body, then the program can be legal or illegal depending on
the partitioning scheme, which is not expressed in code.

That's just against what I understand as Ada spirit.

Things like this lead me to conclusion that DSA is essentially broken
and is not a proper way to handle distribution in the system.

> I'm confused by examples such as http://www.adacore.com/...

A worse observation is that AdaCore might be confused, too. Which only
confirms that DSA is broken.

> If my understanding is correct, my next question is: is there any language-defined support for sharing data between programs

Do you expect it to be language-defined? Why? Ada is not the only
language (not even the only ISO-stamped one) and heterogeneity is a
natural property of systems composed of multiple programs. Defining
data sharing between programs written in the same language would be a
wasted effort (better spent elsewhere in the standard). Instead, allow
others (third-parties) to define it so that programs written in
different languages will be able to share data - this will have much
bigger benefits.

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

On Tuesday, June 5, 2012 12:36:01 AM UTC-7, Maciej Sobczak wrote:

> > If my understanding is correct, my next question is: is there any language-defined support for sharing data between programs
>
> Do you expect it to be language-defined? Why? Ada is not the only
> language (not even the only ISO-stamped one) and heterogeneity is a
> natural property of systems composed of multiple programs. Defining
> data sharing between programs written in the same language would be a
> wasted effort (better spent elsewhere in the standard). Instead, allow
> others (third-parties) to define it so that programs written in
> different languages will be able to share data - this will have much
> bigger benefits.

My reasoning here is that the DSA requires mechanisms to pass objects of Ada types between partitions (of the same program?) transparently, and also to share data in Shared_Passive partitions transparently, without users having to worry about the representation. So it would seem like a natural extension to provide this sort of communication between "programs". The mechanisms would already exist. On the other hand, you have a point that writinga server that uses a feature like this would limit the programs that coulduse the service to those written in Ada. I still think this would be useful in some situations--for example, if the server and clients were expectedto be used within one company (or one division of a company), so that it might be reasonable to expect that all programs be written in a common language.

-- Adam

> .. between partitions (of the same program?) transparently, and also to share
> data in Shared_Passive partitions transparently, without users having to
> worry about the representation. So it would seem like a natural extension
> to provide this sort of communication between "programs". The mechanisms
> would already exist.

If program A consists of Procedure Main_A and a separate partition
Server, while program B is Procedure Main_B and also a separate Server,
you can write a small program AB which simply starts up two tasks. One of
those tasks calls Main_A and the other Main_B and there you have
effectively the two programs running as a single, multitasking, program.
Separate it into partitions and you have the original two programs running
as a distributed program. (Server would of course have to be re-entrant
whether it's called by two tasks in a traditional single physical
partition, or by two different active partitions.)

> On the other hand, you have a point that writing a server that uses a
> feature like this would limit the programs that could use the service to
> those written in Ada.
Or any program with the needed Ada interface layer.

> .. now, if we repartition the program in such a way that a given
> operation (Do_Something_For_Me) ends up in a separate partition, it
> might become potentially blocking by virtue of the hidden physicality
> of remote call. In short, it might become a I/O operation even though
> it is not visible anywhere. If such operation is used within a
> protected body, then the program can be legal or illegal depending on
> the partitioning scheme, which is not expressed in code.
"All forms of remote subprogram calls are potentially blocking
operations." So the final physical partitioning may decide whether a
particular call is actually blocking, but if it's a remote subprogram
call, even if the whole program is physically in one partition, then
the call is "potentially blocking" and thus illegal from a protected type.

Adam Beneschan wrote:

> [...] On the other hand, you have a point that writing a server that
> uses a feature like this would limit the programs that could use the
> service to those written in Ada.

.... and compiled with the same version of the same Ada compiler.

Greetings,

Jacob
--
"It is very easy to get ridiculously confused about the
tenses of time travel, but most things can be resolved
by a sufficiently large ego."

On 5 Cze, 18:02, Adam Beneschan <a...@irvine.com> wrote:

>*I still think this would be useful in some situations--for example, if the server and clients were expected to be used within one company (or one division of a company), so that it might be reasonable to expect that all programs be written in a common language.

I'm afraid not even then. My work consists mostly of implementing
middleware solutions for multi-language (mostly C++/Java) systems that
are developed within the same division of a single company. I seem to
see this pattern more and more often, wherever I go.

Interestingly, even if you focus on programs written by the same
person (you cannot get more control than that, right?), there is still
no guarantee that they will be written in the same language, as
different languages have different features and tradeoffs that justify
their use in different contexts. Java-based GUI displays for Ada-based
backends that are configured by Python-based scripts, all using C++-
based databases? Better get used to that.

This is what makes single-language-distributed-systems solutions kind
of pointless.

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

On Wed, 6 Jun 2012 00:39:18 -0700 (PDT), Maciej Sobczak wrote:

> This is what makes single-language-distributed-systems solutions kind
> of pointless.

True. The common denominator must be the middleware itself. The language
should provide an equivalent of the pragma Convention for objects and
operations living in the middleware. The interfaces of these things should
be publicly protected.

I agree with your assertion that DSA concept is wrong. But it would be very
difficult to improve that because things are quite unsettled. Interfacing
states of distributed objects is just a tip of the iceberg of the services
a middleware provides.

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

On 12-06-06 09:39 , Maciej Sobczak wrote:
> On 5 Cze, 18:02, Adam Beneschan<a...@irvine.com> wrote:
>
>> I still think this would be useful in some situations--for example, if the server and clients were expected to be used within one company (or one division of a company), so that it might be reasonable to expect that all programs be written in a common language.
>
> I'm afraid not even then. My work consists mostly of implementing
> middleware solutions for multi-language (mostly C++/Java) systems that
> are developed within the same division of a single company. I seem to
> see this pattern more and more often, wherever I go.
>
> Interestingly, even if you focus on programs written by the same
> person (you cannot get more control than that, right?), there is still
> no guarantee that they will be written in the same language, as
> different languages have different features and tradeoffs that justify
> their use in different contexts. Java-based GUI displays for Ada-based
> backends that are configured by Python-based scripts, all using C++-
> based databases? Better get used to that.
>
> This is what makes single-language-distributed-systems solutions kind
> of pointless.

The fact that *some* distributed systems are multi-language does not
mean that a single-language solution is pointless. Insufficient, perhaps.

Multi-language distributed systems tend to be built with
language-independent middleware. There is not much to discuss about
them, from a language-centered point of view (as in c.l.a.).
Language-specific bindings to IDLs come closest. In your experience, are
IDLs like CORBA used today? Or just sockets with ad-hoc protocols?

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

On 6 Cze, 12:09, Niklas Holsti <niklas.hol...@tidorum.invalid> wrote:

> > This is what makes single-language-distributed-systems solutions kind
> > of pointless.
>
> The fact that *some* distributed systems are multi-language does not
> mean that a single-language solution is pointless. Insufficient, perhaps.

Single-language systems (A) are a subset of multi-language systems
(B). This means that if you need the B solution anyway (and you really
need it) and it solve problem A as well, then having a separate A
solution is pointless.

You might still ask for it for performance reasons (it is easier to
achieve good performance if you are not constrained by artificial
common denominators), but this is a luxury that can be afforded only
when you have other burning problems sorted out already.
Unfortunately, this is not the case for Ada and that is why I argue
that this is an effort that is better spent elsewhere.

> In your experience, are
> IDLs like CORBA used today? Or just sockets with ad-hoc protocols?

I think that plain sockets are not very widely used by mature
development teams and instead some ready protocols are adopted with
varying degrees of completeness. CORBA is complete but huge and it
seems to be less and less popular, but there are plenty of other
solutions somewhere in this spectrum.
One of the small, but potentially useful things I have found recently
is this:

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.

And of course, I will benefit from the opportunity to shamelessly
mention this:

http://inspirel.com/yami4/

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

On Wed, 6 Jun 2012 04:40:41 -0700 (PDT), Maciej Sobczak wrote:

> On 6 Cze, 12:09, Niklas Holsti <niklas.hol...@tidorum.invalid> wrote:
>
>>> This is what makes single-language-distributed-systems solutions kind
>>> of pointless.
>>
>> The fact that *some* distributed systems are multi-language does not
>> mean that a single-language solution is pointless. Insufficient, perhaps.
>
> Single-language systems (A) are a subset of multi-language systems
> (B).

Code distribution is only one role of the middleware, at least in process
automation. Integration of components and devices is usually more
important. It is not even B, the other side might be not a programmable
system and almost always just a black box.

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

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

> One of the small, but potentially useful things I have found recently
> is this:
>
> 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?

On 12-06-06 13:40 , Maciej Sobczak wrote:
> On 6 Cze, 12:09, Niklas Holsti<niklas.hol...@tidorum.invalid> wrote:
>
>>> This is what makes single-language-distributed-systems solutions kind
>>> of pointless.
>>
>> The fact that *some* distributed systems are multi-language does not
>> mean that a single-language solution is pointless. Insufficient, perhaps.
>
> Single-language systems (A) are a subset of multi-language systems
> (B). This means that if you need the B solution anyway (and you really
> need it) and it solve problem A as well, then having a separate A
> solution is pointless.

They don't solve the "same" problem, or not equally well. A
single-language solution can offer better integration, more compile-time
checks, and less effort on middleware tools (less effort by the
application developer, at least).

I don't agree that the Ada DSA is "pointless", although it is not used
in as many applications as the multi-language interfaces.

> You might still ask for it for performance reasons (it is easier to
> achieve good performance if you are not constrained by artificial
> common denominators),

It can also offer better degree of integration, safety, logical consistency.

> but this is a luxury that can be afforded only
> when you have other burning problems sorted out already.
> Unfortunately, this is not the case for Ada and that is why I argue
> that this is an effort that is better spent elsewhere.

Is a lot of effort (still) needed for the DSA? Perhaps it is, since only
AdaCore support it -- or are there others?

>> In your experience, are
>> IDLs like CORBA used today? Or just sockets with ad-hoc protocols?
>
> I think that plain sockets are not very widely used by mature
> development teams and instead some ready protocols are adopted with
> varying degrees of completeness. CORBA is complete but huge and it
> seems to be less and less popular, but there are plenty of other
> solutions somewhere in this spectrum.
> One of the small, but potentially useful things I have found recently
> is this:
>
> 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.

MessagePack looks potentially useful, but I also think it illustrates
the drawbacks of a multi-language middleware compared to the Ada DSA,
such as a limitation to low-level "physical" types.

> And of course, I will benefit from the opportunity to shamelessly
> mention this:
>
> http://inspirel.com/yami4/

Nice tutorial video. But here, too, I get the impression of working one
layer below the DSA level, mostly. Usable, and good for cross-language
work, but still missing some of the high-level integrity of the DSA level.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

On 06/06/2012 07:40 AM, Maciej Sobczak wrote:
> On 6 Cze, 12:09, Niklas Holsti<niklas.hol...@tidorum.invalid> wrote:
>
>>> This is what makes single-language-distributed-systems solutions kind
>>> of pointless.
>>
>> The fact that *some* distributed systems are multi-language does not
>> mean that a single-language solution is pointless. Insufficient, perhaps.
>
> Single-language systems (A) are a subset of multi-language systems
> (B). This means that if you need the B solution anyway (and you really
> need it) and it solve problem A as well, then having a separate A
> solution is pointless.
>
> You might still ask for it for performance reasons...

You might also ask for it for other reasons, since there are other
reasons behind Ada, such as maintainability.

--
---
BrianG
000
@[Google's email domain]
..com

On 6 Cze, 22:02, Niklas Holsti <niklas.hol...@tidorum.invalid> wrote:

> MessagePack looks potentially useful, but I also think it illustrates
> the drawbacks of a multi-language middleware compared to the Ada DSA,
> such as a limitation to low-level "physical" types.

There is no limitation to low-level types, as MessagePack supports
user-defined types as well. Of course, they have to all based on some
set of fundamental types, but this is also true in Ada.
I can imagine a ASIS->MessagePack serializer generator.

> >http://inspirel.com/yami4/
>
> Nice tutorial video. But here, too, I get the impression of working one
> layer below the DSA level, mostly.

No, it is neither below nor above. YAMI4 is an asynchronous messaging
system and as such has no direct analogies in synchronous RPC system
as DSA. At the very high conceptual level both can be used to
"communicate" (and this is where they compete), but from the paradigm
point of view they offer different set of patterns and idioms (and
this is where they don't compete).
In other words, some problems have very direct solutions with DSA, due
to its synchronous nature and integration with the language, but some
other problems have easier solutions with YAMI4. This means that they
cannot be compared in terms of being higher- or lower-level.

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

On Thursday, June 7, 2012 5:37:43 AM UTC-5, Maciej Sobczak wrote:
> In other words, some problems have very direct solutions with DSA, due
> to its synchronous nature and integration with the language, but some
> other problems have easier solutions with YAMI4.

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