ORG, ROI, pem - Specification 03/16/93

[Francois-Rene Rideau]

(reply to Peter)
> Howdy! 
>  
> In this mail I will give you a first specification of remote object 
> invocation. There were no (zero!) responses to my previous mail. I get 
> a little confused, have I said something wrong? Don't you have enough 
> time to think it over? Well, I actually assume, that some of you have 
> not received my mail and I've sent out an acknowledgement request. 
(Hey ! I did answer your message; didn't you receive my reply ?)

> As I pointed out in previous mails, I'm an advocate of a strict separation 
> between design/specification and implementation. So, the specification only
 I guess we all are; if someone disagrees, let him tell it loud. This does
not mean we can't propose an efficient implementation together with some
specs.


> R e m o t e   O b j e c t   I n v o c a t i o n 

> Specification Release 0.00 (03/16/93) 

I'd call it only Meta-ROI; for you don't say anything about direct ROI, but
only about how to get to be able to do ROI.

> 1 Overview 
> ========== 

>    This specification will give an abstract view on how remote object 
> invocation is done in MOOSE. Remote object invocation (ROI) means to invoke 
> a method from an object, which is not sharing the invoker's address space. 
> Thus, `remote' in this context means still both invoker and invokee be 
> running on the same machine. (This restriction will disappear, when MOOSE 
> becomes a distributed OS. Then `remote' means not the same address space or 
> even on a remote machine.) 
 I totally agree; MOOSE should be able to adaptate to distributed systems
(won't even the Pentium have two CPU's ?).

> [...]

> 2 Design goals 
> ============== 
>  
>   The following points give an overview of desired characteristics for ROI.
> Thus, ROI should be: 
>  
>      1. general
>      2. object location transparent
>      3. very efficient regarding communication costs
>      4. user-friendly
ok.

> 2.1 Generality
> --------------

>    ROI must be provided for a variety of objects, which can be wide spreaded
> among different applications as well as different contexts or privilege
> levels.
 Yes, that's why some type checking must be available for objects to properly
connect. This checking may also allow type casting and/or conversion. Of
course, types won't have to be checked at each transmission; only at
connection time (upon call to the name server).


> 2.2 Object Location Transparency
> --------------------------------

>    Most objects within MOOSE are location independent; it is not definitely
> clear where the object exist at a given time. Additionally, objects are
> created dynamically in a non-deterministic fashion.
>
>    Mechanisms are needed which provide a mapping function from an object's
> description to its actual location. These mechanisms are provided by a
> special kind of server object, the NAME SERVER. Name servers know the
> absolute locations of their objects and make them transparently available
> to other objects. 
 The "name server" name takes into account only part of the various aspects
of this object. This object is also a client to memory, to any library/module/
object publishing to it, etc. And it's a very technical term. I prefer the
"dictionary" name, or something like that (well, after all, let's have this
name fight a minor issue; Dennis will ultimately decide).


> 2.3 Efficiency
> --------------

>   As one design goal of MOOSE is to provide a highly dynamic system, where 
> components are added on the fly, ROI will be a highly used communication 
> mechanism. Almost all traditional operating system services are provided by 
> independent objects.
 I couldn't agree more.

>   Therefore ROI must be very efficient to minimize the
> remote invocation overhead. This can only be reached if very efficient IPC
> mechanisms exist. Thus the kernel must provide very fast IPC (which is to be
> specified in another release).
 Well, to me, ROI & IPC ARE JUST THE SAME.


> 2.4 User-friendliness 
> --------------------- 

>   Users and their applications should not be aware of ROI. If an
> application needs to invoke methods of a remote server it should simply
> instance an appropriate client object. All necessary ROI stuff should be
> done by creation of the client, which then provides a transparent view to
> the servers' methods.
>   Surely there must exist mechanisms, which allow to interfere in the ROI
> process as much as the user want. Eg, it must be possible to ask a specific
> name server for a server object's location.


> 3. Object Identification
> ======================== 

>    To give access to a server's method the server must be known to all
> possible clients. Thus the client must have the functionality to identify
> the right server. Identifying can be done in several ways, eg.:

>      1. by name
>      2. by description
>      3. by value
absolutely agreed; you can ask the dictionary to find an object considering
restrictions on its name, its type, and/or its value. So that's not only a
NAME server, but it's an OBJECT server.

> This specification will only handle the first one, nameing.
Yes; to begin with, let's have only the name. We'll add other features in
next versions.

> 3.1 Nameing
> -----------

>  A server can be unambiguously identified by its name. A `name' is a unique
> identifier within a given context, its `scope'. Note that several scopes may
> coexist at the same time, eg. each application may have its own name scope.
> This facilitates that multiple objects with the same name may coexist, but
> each one must reside in its own scope.
 Well, I'd see it more like an structured object language symbol table:
the server returns (if it exists) the latest (with respect to structure
hierarchy) object fitting the name and typing restrictions.


>    A server is now an object, which can be seen as a tuple, combining a name
> with provided services. To make these services available, the server
> publishes its name within the desired scope by contacting the appropriate
> name server. This is illustrated in Fig. 1:
 I know you like figures; but you already explained that, and I already
agreed, so I won't quote you again, so you won't enjoy being quoted :-)

> 3.2 Name scopes 
> --------------- 

>   A scope is created whenever a name server is started. Thus all known names
> to a name server form the name server's scope. An application, which create
> a name server have the ability to build up its own scope, allowing it to
> redefine names as needed. Eg, it's possible to `overwrite' an existing file
> server to an application specific one, which always encrypt data on writing
> and decrypt it when reading. The application's file server can then be an
> inherited file server, which is specialized for encryption. Of course it can
> use methods from the `traditional' file server.
More generally, and as I previously posted, dictionaries are a virtual
recursive type, so that anyone can create a new kind of dictionary (example:
DOS partition dictionary; ZIP file dictionary; encrypted dictionary, etc),
and any object can use any dictionary as part of it's own dictionary.

>    One question arises: What is the first scope OR where is the location of
> the first name server?
No need for that; each object is provided a dictionary upon its creation.
The bootstrap's object dictionary recursively contains everything; it may
give part of it only to sub-objects.

>    As almost all traditional operating system services are done by objects,
> there's the need for an default name server (DNS). DNS is installed at
> system startup, providing the first name scope, which holds information
> about, for example, the file server, printer server or disk servers. DNS
> is the only object which must be installed at a well known location (or:
> the kernel must provide a service to get its location).
I always agree (whereas always not with the name. main/home/root library/
dictionary/directory would be as fine.)


>         +-------------+  client request or server registration 
>         | Application |----------+ 
>         +-------------+          v 
>                  |   ^        +-----+ 
>          ask for |   |        | DNS | 
>           DNS by |   |        +-----+ 
>          request |   |           | 
>                  |   | return    | bounded 
>                  |   | DNS       | location                User level 
>       ...........|...|...........|................................... 
>                  v   |           |                       Kernel level 
>                 +-------------+  | 
>                 |   Kernel    |--+ 
>                 | +---------+ | 
>                 | | Nucleus | | 
>                 +-+---------+-+ 
>  
> Fig. 3 

I don't agree ; here is my proposition:

>         +-------------+    Kernel   +----------------+
>         | An Object   |<----------->| its dictionary |
>         +-------------+    = ROI    +----------------+
> Fig. 3 b

>    A DNS location request solved by a kernel service is shown in Fig. 3. For
> simplicity only two privilege levels are shown, user and kernel level. 
My figure has no privilege levels. No such thing is needed. Kernel is ROI.

> application, wishing to use services of a remote server object or to install
> a new server in the default name scope, must first find out the DNS
> location. It initiates a request to the kernel, which returns the current
> DNS location. Then the application can contact the DNS as usual.
It will publish to its know dictionaries: its own, and those present inside
its own. Dictionaries are free to accept or refuse publication and possibly
to spread it.

>    Providing a kernel service have the advantage, that access to the DNS
> is location transparent. The system is free to place the DNS as it wishes.
> It has the disadvantage, that a kernel request must be additionally done to
> find out its location. But for flexibility the advantage outweights the
> disadvantage.

>    All necessary communication stuff for finding the DNS location should be 
> encapsulated in clients or servers, respectively. If no other attributes are
> specified the DNS should be used automatically. Of course, an application, 
> which creates its own name server can declare this server as its DNS. Then 
> this name server is used, if no further attributes are given. 
ok

> 3.3 Addressing 
> -------------- 

>    The name server is responsible to map a received name into an useful 
> object location. This can be done either direct or indirect. A direct mapping 
> function can calculate the location from the name, as shown in Fig. 4: 
>  
>  
>       +------+  Mapping function   +-------------------+ 
>       | Name |-------------------->| Object's Location | 
>       +------+                     +-------------------+ 
>  
> Fig. 4 
>  
>  
>    This is usually done by makeing the object's location part of the name. 
> This has one great disadvantage. Consider the case, where several clients 
> exist, which all want to use services of one server. Then all these clients 
> will use the same name. For some reason the server must be migrated to 
> another location. Then all names are invalid. 

>    A second approach is to map a name to an `address' which then can be 
> mapped to the object's location (Fig. 5). If the destination object migrates 
> only the address must be changed. All names will still be valid. 
>  
>  
>       +------+         +-------------------+ 
>       | Name |         | Object's location | 
>       +------+         +-------------------+ 
>          |                ^ 
>          |                | 
>          |   +---------+  | 
>          +-->| Address |--+ 
>              +---------+ 
>  
> Fig. 5 
>  
>  
>    With this approach a name can be very small. They only have to provide 
> all necessary information to indicate an address. 
>  
> ----- Cut here ----- 
>  
> To all of you, who want to see a more `implementation' oriented version 
> I will now present examples, how an user should be able to use ROI 
> in his/her application. All definitions are specified in a syntax similiar 
> to those of C++. Note: This is still a conceptual model! At the end I will 
> present problems which arise at this layer. 
 C++ is good, but it is unstructured (all data global or local), and allows
object handling only at compile time; no execute time handling is provided.

> Examples
> ========

> Problems 
> ======== 
>  
> What, when public methods of a server call private methods? 
> ----------------------------------------------------------- 
>  
>    Private methods are able to change the server's state. There must be 
> mechanisms which avoid an influence from one client to another client's 
> point of view to this state. Thus, each client must see it's own server 
> state. 
?
Each client manages its dictionary itself; but the dictionary is given
objects at the beginning.

> What, when a server chooses a name which is already occupied by another 
> server?
The older one is hidden by the newer; See Pascal and such structured
languages.

> ----------------------------------------------------------------------- 
  
>  This leads to a name conflict, which must be solved. The name server will
> deny the request and the server is not published. Thus, the provided
> services are not available. 
I prefer the previous solution; or you may choose between those two.
  
> What, when a client cannot locate an appropriate server? 
> -------------------------------------------------------- 
Then it cannot use it !

>    There are two reasons for this problem: First, there's no server 
> available. Then the client can simply create a new server instance. This
> instance will then publish itself to the name server, which was asked by the
> client. In this case the client knows the server's location. There's no need
> to ask the name server again. 
>  
>    Second, there's a server using the name, but which is not appropriate
> because it have the wrong type. There must be a mechanism which ensures
> that the returned server is useful for the asking client.
Well, you see there's a need for typing !

 To sum up my comments: I totally agree with what you wrote (whereas I stick
to the dictionary name for NAME SERVER; name server is too technical;
dictionary is just fine). HOWEVER, this just isn't enough, for names don't
suffice, and we have to define what a direct link is, and include typing into
it; for if we have no typing, there is no objects.
 So let's define objects, which are our main problem.
 I will next; but now I'm going to bed.

 Goodbye !

    ,
 Fare, 200% time MOOSE programmer.