[Simca-developers] (**) simca and corba (fwd)

[Artem B. <ar...@v2...>]

resending due to ml problems

---------- Forwarded message ----------
Date: Tue, 08 Apr 2003 17:27:27 +0200
From: Artem Baguinski <ar...@v2...>
To: sim...@li...
Subject: (**) simca and corba

hi simca-dev

here's my thoughts about corba, name-servers etc.

first of all, i'm introducing tech level sterretjes. they are like stars 
in tv guide, but represent tech-details level of the mail (or it's 
part). (*) - isn't technical at all, (**) is technical but can be read 
and understood by everybody in this list, (***) - more details, read if 
you wanna know more about v2_jam software, (****) - only read if you're 
artm or simon, (*****) - low level tech documents with program listings 
and comments in russian :)

the symbols should appear in the subject line, although (*) and (**) can 
be omitted (because everybody should read those mails generally). if 
subject line contains tech-details-code, but then in letter body there's 
other code, it means there's end of too-tech section below, and you can 
skip there if you're not interested in details. this trick should be 
used by programmers to attract attention of others to some conclusions, 
like in this mail. end of section is (/*), (/**) etc. there shouldn't be 
more then one detailed section per file though, otherwise the whole 
thing becomes too serious :)

(****)

if you're not simon skip through to the (/****)

the evil of the current approach (name-server is a thread of one of the 
servers) is that if that server dies (e.g. client did something very 
wrong and server couldn't recover) then name server dies as well. all 
other servers will be inaccessible then.

why not implement the following strategy:
- simca-name-server isn't simca-server, it only implements the corba 
naming service and the IOR server.
- simca-server implements the actual simca stuff and registers itself in 
a name server. which name server can be specified on command line:
   * default: localhost:<simca-port> (we should decide which port)
   * --ns-ior <ior> - use name server by ior, exit if no such server
   * --ns-ior-file <file>|- - read name server IOR from file or stdin
   * --ns-host <host>[:<port>] - use name server by host and probably 
port (default for port is simca-port of course).

this approach allows, for example, easily create a setup with 
centralized name-server (all simca servers start with --ns-host 
simca-hq:9999).

now, about server names. several servers can run on the same host (so 
that when one falls others remain running). this means that every server 
should be registered with distinguishable name. server name should be 
command line parameter, and there shouldn't be default - one must be 
provided.

corba naming service allows tree (or even graph, they say) of names to 
be created, similar to dns or filesystem. components of this tree 
contain not only names but also "kinds". kind describes what for 
name-component we have here, if i'm not mistaken we can come up with our 
own kinds.

the convention (from name-client):
  - components of name are delimited by '/'
  - id and kind of those components are delimited by '.'

examples of a name:

/presentation.folder/servers.folder/audio.server
/presentation.folder/servers.folder/video.server
/presentation.folder/servers.folder/audio.server/in.page
/presentation.folder/servers.folder/audio.server/out.page

i don't know actually if the same name can designate object and
context like i've shown.

although, centralized approach isn't good for iternet based sporadic 
jams or travelling jam artists who want to start up jam quickly not 
changing much in their usual setup. i'll think about this more.

(/****)

this allows the following scenario of using v2_jam for creating portable 
distributed installations:

   * the description of the installation consists of two parts:

     * jam pipeline. pipeline consists of virtual named servers, which 
in turn contain pages, and those are made up of connected objects.

     * jam map. jam map contains information about where the virtual 
servers run. (i.e. maps server names to network addresses)

   * whenever author wants to recreate his work in different network 
environement he only needs to change the map, and not touch the pipeline.

pipeline/map can be represented either by passive documents (e.g. XML 
based) or by active scripts, or by combination of the two.