Replicative Partitions

Replicative Partitions

[Nick Roberts]

I would appreciate views on the following.

Annex E (of the RM95) seems to make the assumption that each partition will
only be in execution solitarily, rather than there being several instances
of one partition executing concurrently. Indeed, it describes things on the
assumption (or at least from the viewpoint) of there being just one
'program' running. The rationale does not add anything to this.

This viewpoint may be sensible for a typical embedded system. However, in a
system (any system?) which supports the dynamic initiation of the execution
of partitions, several instances of one partition executing concurrently
seems to be at least a possibility. Furthermore, it may be very useful, or
even vitally necessary that this is supported.

For one thing, I suggest the wording of the RM95 should be changed (in the
next revision) to explicitly reflect the possibility of the multiple
execution of a partition, which I shall term a "replicative partition". A
rule would be required, I suspect, that a partition is only permitted to be
replicative if it has no shared passive library units nor RCI bodies
assigned to it.

For another, if the Partition_ID attribute only statically identifies a
partition (the best interpretation to my mind), I suggest it would be
extremely useful to have a means of identifying instances of replicative
partitions, and for the next revision to specify this means.

One possibility is a new language-defined package:

   package System.RPC.Replication is

      type Instance_ID is private;

      Null_Instance: constant Instance_ID;

      function "=" (Left, Right: in Instance_ID) return Boolean;
      -- also "<", "<=", ">", and ">=" ?

      function Image (Instance: in Instance_ID) return String;

      -- possibly other operations of Instance_ID?

      function Current_Instance return Instance_ID;

      function Is_Terminated (Instance: in Instance_ID) return Boolean; -- ?
      function Is_Callable (Instance: in Instance_ID) return Boolean; -- ?

   private
      -- implementation defined
   end;

Each executional instance of any partition, regardless of which node in the
network it is executing on, has a unique identifying value, of type
Instance_ID, called its 'instance identifier'. The function Current_Instance
would return the instance identifier of the instance calling it.

In addition, each remote subprogram (declared in a RCI) would have an
attribute Remote_Caller, which would yield the instance identifier of the
calling instance, within the body of that subprogram (and would be illegal
elsewhere).

This would provide the basis for servers to service multiple instances of a
replicative partition separately, and, provided a caller could not 'fake'
its instance identifier to the server it was calling, it would provide the
basis for any security scheme the server wished to impose.

Needless to say, this is (roughly) the scheme I intend to implement for
AdaOS.

I believe the word 'program' in the RM95 is used inconsistently, and that
its use is unnecessary and confusing. It would be better to leave the
informal meaning in 10.2 (2) and remove all other references to the word or
concept of 'program' throughout the remainder of the RM95 (and simply talk
about the execution of partitions instead).

(a) Am I totally getting hold of the wrong end of the stick on this issue
(as I often do ;-) ?

(b) Is this a matter that has been usefully discussed before? On c.l.a?

(c) Would the scheme I propose be worth inclusion in the next revision of
the language, or is it a bit too esoteric (or poorly formed)?

(d) Are there any further points related to this issue of which I should be
aware?

Many thanks,

--
Nick Roberts

Re: Replicative Partitions

[Francisco Javier Loma Daza]

On Sat, 27 Oct 2001, Nick Roberts wrote:
> Subject: Replicative Partitions
> 
> I would appreciate views on the following.
> 
> Annex E (of the RM95) seems to make the assumption that each partition
> will
> only be in execution solitarily, rather than there being several
> instances
> of one partition executing concurrently. Indeed, it describes things on
> the
> assumption (or at least from the viewpoint) of there being just one
> 'program' running. The rationale does not add anything to this.
> 
> This viewpoint may be sensible for a typical embedded system. However, in
> a
> system (any system?) which supports the dynamic initiation of the
> execution
> of partitions, several instances of one partition executing concurrently
> seems to be at least a possibility. Furthermore, it may be very useful,
> or
> even vitally necessary that this is supported.
> 
> For one thing, I suggest the wording of the RM95 should be changed (in
> the
> next revision) to explicitly reflect the possibility of the multiple
> execution of a partition, which I shall term a "replicative partition". A
> rule would be required, I suspect, that a partition is only permitted to
> be
> replicative if it has no shared passive library units nor RCI bodies
> assigned to it.
> 
> For another, if the Partition_ID attribute only statically identifies a
> partition (the best interpretation to my mind), I suggest it would be
> extremely useful to have a means of identifying instances of replicative
> partitions, and for the next revision to specify this means.
> 
> One possibility is a new language-defined package:
> 
>    package System.RPC.Replication is
> 
>       type Instance_ID is private;
> 
>       Null_Instance: constant Instance_ID;
> 
>       function "=" (Left, Right: in Instance_ID) return Boolean;
>       -- also "<", "<=", ">", and ">=" ?
> 
>       function Image (Instance: in Instance_ID) return String;
> 
>       -- possibly other operations of Instance_ID?
> 
>       function Current_Instance return Instance_ID;
> 
>       function Is_Terminated (Instance: in Instance_ID) return Boolean;
> -- ?
>       function Is_Callable (Instance: in Instance_ID) return Boolean; --
> ?
> 
>    private
>       -- implementation defined
>    end;
> 
> Each executional instance of any partition, regardless of which node in
> the
> network it is executing on, has a unique identifying value, of type
> Instance_ID, called its 'instance identifier'. The function
> Current_Instance
> would return the instance identifier of the instance calling it.
> 
> In addition, each remote subprogram (declared in a RCI) would have an
> attribute Remote_Caller, which would yield the instance identifier of the
> calling instance, within the body of that subprogram (and would be
> illegal
> elsewhere).
> 
> This would provide the basis for servers to service multiple instances of
> a
> replicative partition separately, and, provided a caller could not 'fake'
> its instance identifier to the server it was calling, it would provide
> the
> basis for any security scheme the server wished to impose.
> 
> Needless to say, this is (roughly) the scheme I intend to implement for
> AdaOS.
> 
> I believe the word 'program' in the RM95 is used inconsistently, and that
> its use is unnecessary and confusing. It would be better to leave the
> informal meaning in 10.2 (2) and remove all other references to the word
> or
> concept of 'program' throughout the remainder of the RM95 (and simply
> talk
> about the execution of partitions instead).
> 
> (a) Am I totally getting hold of the wrong end of the stick on this issue
> (as I often do ;-) ?
> 
> (b) Is this a matter that has been usefully discussed before? On c.l.a?
> 
> (c) Would the scheme I propose be worth inclusion in the next revision of
> the language, or is it a bit too esoteric (or poorly formed)?
> 
> (d) Are there any further points related to this issue of which I should
> be
> aware?


    Well, I assume that your extension to Annex E is for making possible to

have a client-server architecture, based only on packages/partition:
    - A server partition with the requiered RCIs/Shared_Passive packages
    - *Several* partitions acceding the server partition

When I first looked at Annex E, I have the same question. If Partition_ID
is unique
along the distribuited program, I can't have several instantiantions of
client partitions. I agree with you :)

In practice, you can manage to do client-server, using a server partition
on which 
client object get registered. On registration time, you can pass a
password. An
example

package Abstract_Client is

    type Object is abstract limited null record;

    function Get_Password(this: Object) return String is abstract;

end Client


with Abstract_Client;
package The_Server is


    procedure Register(client: access Abstract_Client.Object'Class);

    No_Grants: Exception;

end The_Server;


    You can then run several clients to register. This way you do not need
replication partition, just several objects, and you identify each one by a
password.

Re: Replicative Partitions

[Nick Roberts]

It so happens that AI95-273 touches on this issue. I'd like to get involved
in the development of a putative specification of a new, more flexible PCS,
possibly for inclusion in the next revision of the Ada language. (It
wouldn't replace the current PCS, but be an option additional to it.)

If this idea were a flag, would anyone be saluting it?

--
Nick Roberts