[Gnue-dev] Halloween 5: Appserver Architecture

[Reinhard Mueller]

This is the last of the Halloween mails and outlines the planned
internal architecture of Appserver.

(Please view with fixed font width)

                                          +--------------------+
                                          |                    |
                                          V                    |
                             +---------------------------+     |
                             |                           |     |
                             |    Language Interface     |     |
                             |                           |     |
   Forms         Reports     +---------------------------+     |
      |              |                    |                    |
      |              |                    |                    |
      |              |                    |                    |
      V              V                    V                    |
+------------------------[ RPC API ]---------------------+     |
|                                                        |     |
|                       Object Server                    |     |
|                                                        |     |
+--------------------------------------------------------+     |
      |              |              |              |           |
      |              |              |              |           |
      |              |              |              |           |
      V              V              V              V           |
+-----------+  +-----------+  +-----------+  +-----------+     |
|           |  |           |  |           |  |           |     |
|   Data    |  |   Code    |  |   Class   |  | Authentif.|     |
| Interface |  | Interface |  | Repository|  | Interface |     |
|           |  |           |  |           |  |           |     |
+-----------+  +-----------+  +-----------+  +-----------+     |
      |              |              |              |           |
      |              |              |              |           |
      |              |              +--------------+-----------+
      V              V                                         |
   Database      Procedures                                    |
                     |                                         |
                     +-----------------------------------------+


The Object Server provides the API described in Halloween 4. Forms and
Reports access business objects via that API over RPC, while the
Language Interface translates this API into native language (e.g.
Python) constructs.

That means that code using the Python Language Interface will see
business objects as if they were Python objects.

The Data Interface abstracts database access. This is a part of GNUe
Common.

The Code Interface manages the calling of procedure code. This includes
handling of separate process environments where the procedure code can
run (so that faulty code can't kill the server process), and in case of
ever implemented language flexibility the selection of the appropriate
interpreter for a given piece of code.

Note that the Data Interface doesn't deal with the loading of
definitions from the class repository, as well as the Code Interface
doesn't load the method code from anywhere. The Object Server loads
those definitions and then calls the Data Interface and the Code
Interface appropriately.

The procedure code called by the Code Interface can also access arbitary
business objects other than the automatically passed "self" parameter,
by using the Language Interface.

The Class Repository handles the class definitions. This includes the
definitions of Properties of a class, the handling of modules, and the
implementation of procedures.

All Class Definitions are stored in the database and are accessible like
normal business objects.

For example, like there is a class "customer" with the properties
"name", "street", "city", "open_invoices" etc., there is a class "class"
with the properties "name", "properties", "methods". These classes will
reside in a module called "system".

When the Class Repository is asked for a specific class definition, it
will decide:
* class definitions for the system module are hardcoded in the Class
Repository Code and returned immediately.
* class definitions for all other modules are read from the system
objects using the Language Interface.

Of course, not only the class repository can access the system objects
(holding the class definitions), but also Forms, Reports, and arbitary
procedures.
So it will be easily possible to write a form in which class definitions
can be maintained, or to write a report that lists up all properties of
all classes.

The Authentification Adapter can authentificate users against several
authorities. It could use PAM to check whether a username/password is
valid, or it could look up the username in an LDAP database, or it could
use an internal business object to store all valid users and their
passwords. In the latter case, it would use the Language Interface to
access these internal objects.

We have also talked about the definition of "views", that is the
possibility of creating different "masks" that are puts over the
business objects depending on the user. Like:
* User joe sees all customers with all their properties
* All users from sales see all products, but they don't see any purchase
related properties of the product objects
* Users from the sales department only see the customers of the region
they are responsible for
* Every department leader can see all employee objects, but the wage
property is only writeable for the employees in his department.

-----------------------------------------

Now, that's most of it.


We are looking forward for feedback.


The next steps we agreed upon are
* update the current documentation (README, doc/api, doc/whitepaper)
* define the system classes for the class repository
* define the interface between object server and class repository
* implement the class repository
* define/document the interface between the object server and the data
interface and the code interface
* implement the code interface
* define the interface between the object server and the
authentification interface

(these steps are in no special order and will probably be done by
different persons in parallel)

Thanks,
-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil