gnue/appserver/doc/whitepaper .cvsignore Makefi...

[Reinhard Mueller]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Reinhard Mueller <address@hidden>       02/11/23 15:53:40

Modified files:
        appserver/doc/whitepaper: .cvsignore Makefile version.texi 
                                  whitepaper.texi 
Added files:
        appserver/doc/whitepaper: AppserverArch.txt 

Log message:
        Updated whitepaper to reflect the results of the Halloween meeting.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/AppserverArch.txt?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/.cvsignore.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/Makefile.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/version.texi.diff?tr1=1.5&tr2=1.6&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/whitepaper.texi.diff?tr1=1.5&tr2=1.6&r1=text&r2=text

Patches:
Index: gnue/appserver/doc/whitepaper/.cvsignore
diff -c gnue/appserver/doc/whitepaper/.cvsignore:1.1 
gnue/appserver/doc/whitepaper/.cvsignore:1.2
*** gnue/appserver/doc/whitepaper/.cvsignore:1.1        Tue May  7 03:47:08 2002
--- gnue/appserver/doc/whitepaper/.cvsignore    Sat Nov 23 15:53:40 2002
***************
*** 1,3 ****
--- 1,4 ----
+ AppserverArch.pdf
  whitepaper.dvi
  whitepaper.html
  whitepaper.pdf
Index: gnue/appserver/doc/whitepaper/Makefile
diff -c gnue/appserver/doc/whitepaper/Makefile:1.4 
gnue/appserver/doc/whitepaper/Makefile:1.5
*** gnue/appserver/doc/whitepaper/Makefile:1.4  Mon May 20 13:29:06 2002
--- gnue/appserver/doc/whitepaper/Makefile      Sat Nov 23 15:53:40 2002
***************
*** 1,22 ****
  all: dvi txt html pdf ps aux-clean
  
! dvi:
!       texi2dvi whitepaper.texi
  
! txt:
        makeinfo --no-headers --output=whitepaper.txt whitepaper.texi
  
! html:
        makeinfo --html --no-split whitepaper.texi
  
! pdf:
        texi2pdf whitepaper.texi
  
  ps: whitepaper.dvi
        dvips whitepaper -o whitepaper.ps
  
  aux-clean:
!       rm -f *.aux *.cp *.fn *.ky *.log *.pg *.toc *.tp *.vr *.??s
  
  clean: aux-clean
!       rm -f *.dvi *.txt *.html *.pdf *.ps
--- 1,36 ----
  all: dvi txt html pdf ps aux-clean
  
! # I have problems with dia, therefore I commented these out and committed
! # the .eps and the .png to CVS. Once we've sorted out the problems with dia,
! # both AppserverArch.eps and AppserverArch.png can be removed from CVS.
! #       -- Reinhard
! #
! # AppserverArch.eps: AppserverArch.dia
! #     dia --export=AppserverArch.eps --nosplash AppserverArch.dia
! #
! # AppserverArch.png: AppserverArch.dia
! #     dia --export=AppserverArch.png --nosplash AppserverArch.dia
! 
! AppserverArch.pdf: AppserverArch.eps
!       epstopdf AppserverArch.eps
  
! txt: *.texi AppserverArch.txt
        makeinfo --no-headers --output=whitepaper.txt whitepaper.texi
  
! html: *.texi AppserverArch.png
        makeinfo --html --no-split whitepaper.texi
  
! dvi: *.texi texinfo.tex AppserverArch.eps
!       texi2dvi whitepaper.texi
! 
! pdf: *.texi texinfo.tex AppserverArch.pdf
        texi2pdf whitepaper.texi
  
  ps: whitepaper.dvi
        dvips whitepaper -o whitepaper.ps
  
  aux-clean:
!       rm -f *.aux *.cp *.fn *.ky *.log *.pg *.toc *.tp *.vr *.cps
  
  clean: aux-clean
!       rm -f *.txt *.html *.dvi *.pdf *.ps # *.eps *.png
Index: gnue/appserver/doc/whitepaper/version.texi
diff -c gnue/appserver/doc/whitepaper/version.texi:1.5 
gnue/appserver/doc/whitepaper/version.texi:1.6
*** gnue/appserver/doc/whitepaper/version.texi:1.5      Mon Jun  3 05:44:11 2002
--- gnue/appserver/doc/whitepaper/version.texi  Sat Nov 23 15:53:40 2002
***************
*** 1,2 ****
! @set UPDATED 2002-06-03
! @set EDITION 0.0.7
--- 1,2 ----
! @set UPDATED 2002-11-23
! @set EDITION 0.0.8
Index: gnue/appserver/doc/whitepaper/whitepaper.texi
diff -c gnue/appserver/doc/whitepaper/whitepaper.texi:1.5 
gnue/appserver/doc/whitepaper/whitepaper.texi:1.6
*** gnue/appserver/doc/whitepaper/whitepaper.texi:1.5   Mon Jun  3 05:44:11 2002
--- gnue/appserver/doc/whitepaper/whitepaper.texi       Sat Nov 23 15:53:40 2002
***************
*** 49,55 ****
  @menu
  * Introduction::
  * Features::
! * Implementation::
  * FDL:: Free Documentation License
  @end menu
  
--- 49,55 ----
  @menu
  * Introduction::
  * Features::
! * Architecture::
  * FDL:: Free Documentation License
  @end menu
  
***************
*** 76,321 ****
  
  @table @emph
  @item Freedom
! GEAS must be GPL and must be built with truly free tools.
  
  @item Stability
! GEAS must be reasonable stable. For a mission-critical application in a
! business, reasonable stable means very stable.
  
  @item Security
! GEAS must be reasonable secure.
  
  @item Maintainability
! The code base of GEAS itself must be and remain maintainable by the GEAS
! development team, and the code must be clear enough to allow interested
! programmers to adapt it, fix bugs or even take over maintenance of a part
! of GEAS.
  
  @item Configurability
! GEAS must be configurable and reconfigurable dynamically, centrally,
  without programming skills, without downtime, and in seperate "layers"
  for various levels of specification.
  
  @item Performance
! GEAS must perform reasonably with large quantities of users and/or data.
  
  @item Database Independence
! GEAS must be able to use a number of database systems as backend.
  
  @item Portability
! GEAS must run on multiple operating systems and architectures.
  
  @item Communication Independence
! GEAS must be able to use a number of communication means to communicate
! with the front end (CORBA, XML-RPC...).
  
  @item Language Independence
! GEAS must be able to deal with business methods written in different
  languages.
  @end table
  
  @c 
============================================================================
! @node Features,                               Implementation, Introduction, 
Top
  @c 
============================================================================
  
  @chapter Features
  
  @section Business Objects
  
! GEAS allows definition of data entities (for example name and address of a
! customer) and of program code to perform on such entities (for example how to
! build the address line from country, zipcode and city).
  
  The combination of a data entity with all code functions that can be performed
  on the entity is called a @dfn{business object}.
  
! GEAS lets the user define @dfn{classes} of business objects. The class
! definitions describe both the data elements (called @dfn{attributes}) and the
! available functions (called @dfn{methods}) of the business object.
  
! The specific incarnation of a business object (for example a specific 
customer)
! is called a business object @dfn{instance}.
  
! @section Attributes
  
! GEAS will provide the following attribute types:
  
  @table @dfn
! @item Basic attributes
! contain most of the actual information, in the basic attribute types
  @dfn{string}, @dfn{number}, @dfn{datetime}, and @dfn{boolean}. Examples
  could contain customer name, item price, invoice date, and invoice payment
  status.
  
! @item Compound attributes
! are a means for combining attributes that logically belong together and appear
! repeatedly in the same combination. Compound attributes can be built from
! attributes of any type, not only of basic attributes. An example could be a
  monetary value consisting of the amount and the currency.
  
! @item Reference attributes
  point to another object and declare a relation between two objects. The value
! of a reference attribut is another object. Examples include the customer of an
  invoice or the preferred vendor of an item.
  
! @item List attributes
  point to lists of objects and declare a relation between these objects. The
! value of a list attributes is a list of objects of a defined class, where all
  objects in the list will be of the same class. Examples include all line items
! of an invoice, or all contact persons of a customer.
  
! @item Calculated attributes
! contain information that is generated by GEAS out of other attributes.
! Calculated attributes are generally read-only. An example could be the total
  value of an invoice item (calculated from price * pieces) or the total value
  of an invoice (calculated from all total item values).
- 
- @item Indirect attributes
- are attributes of a referenced object and can be accessed as if they were
- attributes of the current object. Examples could include the name of the
- customer of the invoice, or the name of the preferred vendor of the item of
- an invoice line item.
  @end table
  
! @section Methods
  
! A method is code performed on an object. Methods can have parameters of any
! attribute type (string, number, reference, etc.). Every method has the 
paramter
! @dfn{self}, that is the object instance to operate on, as a parameter.
  
  @section Modules
  
! Modules define namespaces for classes, attributes, and methods. When module A
! defines a class and some attribute and methods for the class, module B can
! extend the class with new attributes. Another module C can independently
! extend the class, without taking care about not using the same attribute names
! as module B, because all modules have their own namespace.
! 
! @section Qualified class, attribute and method names
! 
! @emph{Note: This section is absolutely subject to discussion. We are looking 
for
! a good and understandable syntax for fully qualified names.}
! 
! Class, attribute and method names can be preceded by a module name to override
! the current module context. In this case, the module name is separated by a
! colon (:).
! 
! Compound attribute names can be followed with a dot (.) and a member name of 
the
! compound.
  
! Reference attribute names can be followed with a dot (.) and a attribute name
! of the referenced object to form an indirect attribute.
  
  Example:
  
  Module "cust" defines a class "customer". Module "sales" defines a class
! "invoice_head" and a class "invoice_item". Module "base" defines a class
  "item".
  
! Then, @code{cust:customer} is the fully referenced class name for the
! customer class, and @code{sales:invoice_head} is the fully referenced class
! name for the invoice_head class.
  
! Now, let module "cust" define the attributes "name" and "address" for the
! customer class, where address is a compound attribute consisting of "street"
  and "city".
  
! The following are now valid attribute references of a customer object:
  
! @code{name} or @code{cust:name} is a base attribute.
  
! @code{address} or @code{cust:address} is a compound attribute.
  
! @code{address.street} or @code{cust:address.street} is a compound member
! attribute.
  
! Now, the module "sales" extends the customer class by a attribute 
"last_invoice"
! which is a reference to an invoice_head object.
  
! @code{sales:last_invoice} is a reference containing an invoice_head object.
  
  If module "sales" defines the attribute "number" and "items" in
! "invoice_header", then
  
! @code{sales:last_invoice.number} is an indirect attribute and
  
! @code{sales:last_invoice.items} is an indirect attribute, which is a list
! attribute.
  
  And if yet another module "acct" extends the invoice_header class by a
! attribute "paid", then
  
! @code{sales:last_invoice.acct:paid} could be a boolean attribute that tells 
you
  whether the customer has paid his last invoice or not, and you would access
  it just as easy as the "name" attribute. However, this attribute would only be
  available if all three modules "cust", "sales", and "acct" are installed.
  
! @section Triggers
  
! @dfn{Triggers} are methods that are automatically called upon occurance of
! defined @dfn{events}, for example on every change of a specific attribute,
! or before a commit of a changed object.
! 
! Triggers are always methods of the object where the event occurs. Because
! every module can extend any class with a method of arbitary name, calling
! of triggers could be automated by method name.
  
  Example:
  
! The cust module, which defines the customer object, defines a method
  "OnChangeName", whose fully qualified name is of course
! @code{cust:OnChangeName}.
  
! The sales module could extend the customer class by a method and also call
! this method "OnChangeName", because the fully qualified name of this method
! will be @code{sales:OnChangeName} and therefore different from the other
! method.
! 
! If the attribute "Name" is changed in a customer object, GEAS would call both
! methods because both are named "OnChangeName". The order of the method calls
! would be unpredictable.
  
  @c 
============================================================================
! @node Implementation,                            Building Blocks, Features, 
Top
  @c 
============================================================================
  
! @chapter Implementation
  
  @menu
! * Building Blocks::
  * Data Interface::
! * Methods Adapter::
! * Object Repository::
! * Object Access Translator::
! * Security Adapter::
! * Remote Protocol Adapter::
  @end menu
  
  @c 
----------------------------------------------------------------------------
! @node Building Blocks,           Data Interface, Implementation, 
Implementation
  @c 
----------------------------------------------------------------------------
  
! @section The basic building blocks
  
  @table @dfn
  
  @item Data Interface:
  abstracts database access from a specific database API and from SQL.
  
! @item Methods Adapter:
  abstracts calls to methods from the language and the specific API.
  
! @item Object Repository:
! holds and provides the definition of objects.
  
! @item Object Access Translator:
  translates all requests to the business objects into appropriate database
  transactions and method calls, by using the other building blocks.
  
! @item Security Adapter:
! handles security
  
! @item Remote Protocol Adapter:
  @end table
  
  @section Theory of Operation
--- 76,322 ----
  
  @table @emph
  @item Freedom
! GNUe Appserver must be GPL and must be built with truly free tools.
  
  @item Stability
! GNUe Appserver must be reasonable stable. For a mission-critical
! application in a business, reasonable stable means very stable.
  
  @item Security
! GNUe Appserver must be reasonable secure.
  
  @item Maintainability
! The code base of GNUe Appserver itself must be and remain maintainable
! by the development team, and the code must be clear enough to allow
! interested programmers to adapt it, fix bugs or even take over maintenance
! of a part of Appserver.
  
  @item Configurability
! GNUe Appserver must be configurable and reconfigurable dynamically, centrally,
  without programming skills, without downtime, and in seperate "layers"
  for various levels of specification.
  
  @item Performance
! GNUe Appserver must perform reasonably with large quantities of users
! and/or data.
  
  @item Database Independence
! GNUe Appserver must be able to use a number of database systems as backend.
  
  @item Portability
! GNUe Appserver must run on multiple operating systems and architectures.
  
  @item Communication Independence
! GNUe Appserver must be able to use a number of communication means to
! communicate with the front end (CORBA, XML-RPC...).
  
  @item Language Independence
! GNUe Appserver must be able to deal with business methods written in different
  languages.
  @end table
  
  @c 
============================================================================
! @node Features,                                 Architecture, Introduction, 
Top
  @c 
============================================================================
  
  @chapter Features
  
  @section Business Objects
  
! GNUe Appserver allows definition of data entities (for example name and
! address of a customer) and of program code to perform on such entities
! (for example how to build the address line from country, zipcode and city).
  
  The combination of a data entity with all code functions that can be performed
  on the entity is called a @dfn{business object}.
  
! Appserver lets the user define @dfn{classes} of business objects. The class
! definitions describe both the data elements (called @dfn{properties}) and the
! available functions (called @dfn{procedures}) of the business object.
  
! Procedures may also be bound to a specific event, that is, they are called
! automatically as soon as the event happens. These procedures are called
! @dfn{bound procedures}.
  
! @section Properties
  
! GNUe Appserver will provide the following property types:
  
  @table @dfn
! @item Basic property
! contain most of the actual information, in the basic property types
  @dfn{string}, @dfn{number}, @dfn{datetime}, and @dfn{boolean}. Examples
  could contain customer name, item price, invoice date, and invoice payment
  status.
  
! @item Compound properties
! are a means for combining properties that logically belong together and appear
! repeatedly in the same combination. Compound properties can be built from
! properties of any type, not only of basic properties. An example could be a
  monetary value consisting of the amount and the currency.
  
! @item Reference properties
  point to another object and declare a relation between two objects. The value
! of a reference property is another object. Examples include the customer of an
  invoice or the preferred vendor of an item.
  
! @item List properties
  point to lists of objects and declare a relation between these objects. The
! value of a list properties is a list of objects of a defined class, where all
  objects in the list will be of the same class. Examples include all line items
! of an invoice, or all invoices of a customer.
  
! @item Calculated properties
! contain information that is generated by Appserver out of other properties.
! Calculated properties are generally read-only. An example could be the total
  value of an invoice item (calculated from price * pieces) or the total value
  of an invoice (calculated from all total item values).
  @end table
  
! @section Procedures
  
! A procedure is code performed on an object. Procedures can have parameters
! of any attribute type (string, number, reference, etc.). Every method has
! the paramter @dfn{self}, that is the object to operate on, as a parameter.
  
  @section Modules
  
! Modules define namespaces for classes, properties, and procedures. When
! module A defines a class and some properties and procedures for the class,
! module B can extend the class with new properties. Another module C can
! independently extend the class, without taking care about not using the
! same property names as module B, because all modules have their own namespace.
! 
! @section Qualified class, property and procedure names
! 
! Class, property and procedure names can be preceded by a module name to
! override the current module context. In this case, the module name is
! separated by an underscore (_). This results in the rule that neither
! a module name nor a class, property or procedure name may contain an
! underscore.
  
! Property and procedure names are separated from the object references by
! a dot (.).
  
  Example:
  
  Module "cust" defines a class "customer". Module "sales" defines a class
! "invoiceHead" and a class "invoiceItem". Module "base" defines a class
  "item".
  
! Then, @code{cust_customer} is the fully referenced class name for the
! customer class, and @code{sales_invoiceHead} is the fully referenced class
! name for the invoiceHead class.
  
! Now, let module "cust" define the properties "name" and "address" for the
! customer class, where address is a compound property consisting of "street"
  and "city".
  
! The following are now valid property references of a customer object:
  
! @code{name} or @code{cust_name} is a base property.
  
! @code{address} or @code{cust_address} is a compound property.
  
! @code{address.street} or @code{cust_address.street} is a compound member
! property.
  
! Now, the module "sales" extends the customer class by a property "lastInvoice"
! which is a reference to an invoiceHead object.
  
! @code{sales_lastInvoice} is a reference containing an invoice_head object.
  
  If module "sales" defines the attribute "number" and "items" in
! "invoiceHeader", then
  
! @code{sales_lastInvoice.number} is the number of the last invoice of the
! customer. We could call that an @dfn{indirect property}.
  
! @code{sales_lastInvoice.items} is an indirect property, which is a list
! property.
  
  And if yet another module "acct" extends the invoice_header class by a
! property "paid", then
  
! @code{sales_lastInvoice.acct_paid} could be a boolean property that tells you
  whether the customer has paid his last invoice or not, and you would access
  it just as easy as the "name" attribute. However, this attribute would only be
  available if all three modules "cust", "sales", and "acct" are installed.
  
! @section Bound Procedures
  
! @dfn{Bound procedures} are procedures that are automatically called upon
! occurance of defined @dfn{events}, for example on every change of a
! specific property, or before a commit of a changed object.
! 
! Bound procedures are always procedures of the object where the event occurs.
! Because every module can extend any class with a procedure of arbitary name,
! calling of bound procedures could be automated by method name.
  
  Example:
  
! The cust module, which defines the customer class, defines a procedure
  "OnChangeName", whose fully qualified name is of course
! @code{cust_OnChangeName}.
  
! The sales module could extend the customer class by a procedure and also call
! this it "OnChangeName", because the fully qualified name of this procedure
! will be @code{sales_OnChangeName} and therefore different from the other
! procedure.
! 
! If the property "Name" is changed in a customer object, Appserver would call
! both procedures because both are named "OnChangeName". The order of the
! calls would be unpredictable.
  
  @c 
============================================================================
! @node Architecture,                                     Overview, Features, 
Top
  @c 
============================================================================
  
! @chapter Architecture
  
  @menu
! * Overview::
  * Data Interface::
! * Code Interface::
! * Class Repository::
! * Authentication Interface::
! * Object Server::
! * RPC Interface::
! * Language Interface::
  @end menu
  
  @c 
----------------------------------------------------------------------------
! @node Overview,                      Data Interface, Architecture, 
Architecture
  @c 
----------------------------------------------------------------------------
  
! @section Overview
! 
! @image{AppserverArch}
  
  @table @dfn
  
  @item Data Interface:
  abstracts database access from a specific database API and from SQL.
  
! @item Code Interface:
  abstracts calls to methods from the language and the specific API.
  
! @item Class Repository:
! holds and provides the definition of classes.
! 
! @item Authentication Interface:
! provides a way to authenticate a user and define his access rights.
  
! @item Object Server:
  translates all requests to the business objects into appropriate database
  transactions and method calls, by using the other building blocks.
  
! @item Remote Protocol Interface:
! provides the Appserver API to a remote client via various RPC mechanisms.
  
! @item Language Interface:
! provides easy access to business objects for procedure code and for internal
! use by Appserver
  @end table
  
  @section Theory of Operation
***************
*** 326,460 ****
  @enumerate
  @item
  The client requests an object from the app server through the Remote Protocol
! Adapter.
  
  @item
! The Application Server checks if the requested class name is
! valid (according to the given definitions, i.e. via XML) 
! by looking up the class definition in the Object Repository.
  
  @item
! If it's valid, the Object Access Translator translates a class name
! into a table name. This will include adding a prefix to enable different
! application modules to have their own namespace.
  
  @item
! Then the Application Server passes the database request to the Data Interface
  to actually get the data.
  @end enumerate
  
  @c 
----------------------------------------------------------------------------
! @node Data Interface,          Methods Adapter, Building Blocks, 
Implementation
  @c 
----------------------------------------------------------------------------
  
! @section GNU Enterprise Data Interface (GEDI)
  
! GEDI will provide an API that allows creation and extension of tables,
! reading of data and updating, adding and deleting of records in a table,
! all without SQL.
  
! Eventually, GEDI will support creating and extending tables "on the fly",
! which means that reading a recordset with attributes that don't exist in the
! database will automagically add the missing columns to the table.  This
! will of course be parameterized.
  
! GEDI operates strictly on a table/row interface and doesn't know anything
! about object, attributes and methods.
  
! GEDI actually consists of two mostly independent parts, the Database Adapter
! and the SQL generator.
  
! The Database Adapter is completely backend dependent and provides an
! abstraction of the different APIs of the various database systems.
  
! The SQL generator generates valid SQL statements from requests that come
! in through the table/row interface.  As most SQL databases share a major
! part of the SQL syntax, this module can be mostly backend independent,
! which means that the drivers for the different databases share a lot of
! code.  However, there are differences in SQL syntax, and so parts of this
! code has to be backend specific.  An object oriented programming language
! that provides inheritance could be very helpful in implementing this.
  
  @c 
----------------------------------------------------------------------------
! @node Methods Adapter,        Object Repository, Data Interface, 
Implementation
  @c 
----------------------------------------------------------------------------
  
! @section GNU Enterprise Methods Adapter (GEMA)
  
! GEMA will abstract the calls to business methods written in the different
! languages.
  
! Python will be the only language to support here for probably a long time,
! so in the first versions, GEMA will be more of a stub than of a real module.
  
  @c 
----------------------------------------------------------------------------
! @node Object Repository,Object Access Translator,Methods 
Adapter,Implementation
  @c 
----------------------------------------------------------------------------
  
! @section GNU Enterprise Object Repository (GEOR)
  
! GEOR will hold all the business object definitions: what attributes the object
! consists of, what methods exist, which triggers should be called on what
! event, and so on.
  
! The object definitions could be stored in @code{.gcd} files, in XML files,
! or in the database.
! 
! It should be possible to change object definitions and bring them into
! effect without restarting the server. This might be very hard to achieve
! for ways of storage other than database.
  
  @c 
----------------------------------------------------------------------------
! @node Object Access Translator,Security Adapter,Object 
Repository,Implementation
  @c 
----------------------------------------------------------------------------
  
! @section GNUe Object Access Translator (GOAT)
! 
! This is the main part of the Application Server.
  
! GOAT uses GEDI and GEMA to fulfill requests directed at business objects,
! after it has checked the validity of the request against GEOR.
  
! Security will be implemented here, as a request can simply be rejected if
! the user doesn't have the necessary permissions.
  
  Security implementation will also select or reject based on the users
  authorizations to any regular query.
  
  Example:  if the division president uses a form to request all sales 
! orders, GOAT will query the database and return only the object data 
  that represents the divisions sales orders.
  
! Form level (view) security will not be enforced by GOAT.
  
! GOAT will also provide object transparency.  Meaning that there will 
! not necessarily be a direct relationship between business objects and 
! tables.
  
! While accessing data from the database (via GEDI), GOAT will also
! automagically check for defined trigger methods, and call them (via GEMA).
  
  @c 
----------------------------------------------------------------------------
! @node Security Adapter,Remote Protocol Adapter,Object Access 
Translator,Implementation
  @c 
----------------------------------------------------------------------------
  
! @section Security Adapter
  
! To be defined
  
  @c 
----------------------------------------------------------------------------
! @node Remote Protocol Adapter,            FDL, Security Adapter, 
Implementation
  @c 
----------------------------------------------------------------------------
  
! @section Remote Protocol Adapter
  
! The Remote Protocol Adapter is used to export the functionality of the
! Application Server over the net, using a variety of RPC mechanisms.
  
  @raisesections
  
  @c 
============================================================================
! @node FDL,                                 (null), Remote Protocol Adapter, 
Top
  @c 
============================================================================
  
  @include fdl.texi
--- 327,473 ----
  @enumerate
  @item
  The client requests an object from the app server through the Remote Protocol
! Interface.
  
  @item
! The Object Server checks if the requested class name is
! valid by looking up the class definition in the Object Repository.
  
  @item
! If the class name is valid, then the Object Server uses the Authentication
! Interface to check whether the connected user may access this class.
  
  @item
! If both is OK, the Object Server translates a class name into a table name.
! This will include adding a prefix to enable different application modules
! to have their own namespace.
! 
! @item
! Then the Object Server passes the database request to the Data Interface
  to actually get the data.
  @end enumerate
  
  @c 
----------------------------------------------------------------------------
! @node Data Interface,                    Code Interface, Overview, 
Architecture
  @c 
----------------------------------------------------------------------------
  
! @section Data Interface
! 
! The Data Interface provides an API that allows creation and extension of
! tables, reading of data and updating, adding and deleting of records in
! a table, all without SQL.
! 
! Eventually, the Data Interface will support creating and extending tables
! "on the fly", which means that reading a recordset with attributes that
! don't exist in the database will automagically add the missing columns to
! the table.  This will of course be parameterized.
  
! The Data Interface operates strictly on a table/row interface and doesn't
! know anything about objects, properties and procedures.
  
! The Data Interface used in GNUe Appserver is part of GNUe Common.
  
! @c 
----------------------------------------------------------------------------
! @node Code Interface,            Class Repository, Data Interface, 
Architecture
! @c 
----------------------------------------------------------------------------
  
! @section Code Interface
  
! The Code Adapter will abstract the calls to business methods written in
! the different languages.
  
! Python will be the only language to support here for probably a long time.
! 
! The Code Adapter, or at least parts of it, will reside in GNUe Common.
  
  @c 
----------------------------------------------------------------------------
! @node Class Repository,  Authentication Interface, Code Interface, 
Architecture
  @c 
----------------------------------------------------------------------------
  
! @section Class Repository
  
! The Class Repository will hold all the business object definitions:
! what properties the object consists of, what procedures exist, which
! bound procedures should be called on what event, and so on.
  
! The class definitions will be stored in the database and be accessible
! like normal business objects. Consequently, the Class Repository will
! access the definitions via the Python Language Interface.
  
  @c 
----------------------------------------------------------------------------
! @node Authentication Interface,   Object Server, Class Repository, 
Architecture
  @c 
----------------------------------------------------------------------------
  
! @section Authentication Interface
  
! The Authentication Interface will provide a means to authenticate a user
! on connection to the Appserver, and to check access rights for an already
! connected user.
  
! For the sake of flexibility and independence from operating system and
! database backend, access rights per user will probably be stored in the
! database and be accessible via system business objects.
  
  @c 
----------------------------------------------------------------------------
! @node Object Server,      RPC Interface, Authentication Interface, 
Architecture
  @c 
----------------------------------------------------------------------------
  
! @section Object Server
  
! This is the central part of the Application Server.
  
! The Object Server uses the Data Interface and the Code Interface to fulfill
! requests directed at business objects, after it has checked the validity
! of the request against the Class Repository and the Authentication Interface.
  
  Security implementation will also select or reject based on the users
  authorizations to any regular query.
  
  Example:  if the division president uses a form to request all sales 
! orders, Appserver will query the database and return only the object data 
  that represents the divisions sales orders.
  
! Form level (view) security will not be enforced by Appserver.
  
! The Object Server will also provide object transparency.  Meaning that
! there will not necessarily be a direct relationship between business
! objects and tables.
  
! While accessing data from the database via the Data Interface, the Object
! Server will also automagically check for defined bound procedures, and call
! them via the Code Interface.
  
  @c 
----------------------------------------------------------------------------
! @node RPC Interface,            Language Interface, Object Server, 
Architecture
  @c 
----------------------------------------------------------------------------
  
! @section Remote Protocol Interface
  
! The Remote Protocol Interface is used to export the functionality of the
! Application Server over the net, using a variety of RPC mechanisms.
  
  @c 
----------------------------------------------------------------------------
! @node Language Interface,                      FDL, RPC Interface, 
Architecture
  @c 
----------------------------------------------------------------------------
  
! @section Language Interface
  
! The Language Interface will make business objects easily accessible for code
! written in supported languages. Each language will have it's own Language
! Interface.
! 
! For example, the Python Language Interface (which will be the first one
! to be implemented) lets you access business objects just like they were
! normal Python objects.  Procedures written in Python will use this
! interface to access business objects in a rather straightforward way.
! But also other parts of the Application Server can use the Language Interface,
! if they want to access business objects, for example the system objects
! defining classes or access rights.
  
  @raisesections
  
  @c 
============================================================================
! @node FDL,                                      (null), Language Interface, 
Top
  @c 
============================================================================
  
  @include fdl.texi