Re: Replicative Partitions

[Francisco Javier Loma Daza <Francisco.Loma@isotrol.com>]

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.