/[papo]/gnue/appserver/doc/whitepaper/whitepaper.texi
ViewVC logotype

Diff of /gnue/appserver/doc/whitepaper/whitepaper.texi

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.1 by charlie, Fri Jun 28 19:43:49 2002 UTC revision 1.1.4.1 by anthonyl, Tue Mar 4 22:03:53 2003 UTC
# Line 30  Free Documentation License''. Line 30  Free Documentation License''.
30  @author Reinhard M@"uller  @author Reinhard M@"uller
31  @page  @page
32  @vskip 0pt plus 1filll  @vskip 0pt plus 1filll
33  Copyright @copyright{} 2002 Free Software Foundation  Copyright @copyright{} 2002-2003 Free Software Foundation
34    
35  Permission is granted to copy, distribute and/or modify this document  Permission is granted to copy, distribute and/or modify this document
36  under the terms of the GNU Free Documentation License, Version 1.1  under the terms of the GNU Free Documentation License, Version 1.1
# Line 49  Free Documentation License''. Line 49  Free Documentation License''.
49  @menu  @menu
50  * Introduction::  * Introduction::
51  * Features::  * Features::
52  * Implementation::  * Architecture::
53  * FDL:: Free Documentation License  * FDL:: Free Documentation License
54  @end menu  @end menu
55    
# Line 76  The following list is sorted by priority Line 76  The following list is sorted by priority
76    
77  @table @emph  @table @emph
78  @item Freedom  @item Freedom
79  GEAS must be GPL and must be built with truly free tools.  GNUe Appserver must be GPL and must be built with truly free tools.
80    
81  @item Stability  @item Stability
82  GEAS must be reasonable stable. For a mission-critical application in a  GNUe Appserver must be reasonably stable. For a mission-critical
83  business, reasonable stable means very stable.  application in a business environment, reasonably stable means very stable.
84    
85  @item Security  @item Security
86  GEAS must be reasonable secure.  GNUe Appserver must be reasonably secure.
87    
88  @item Maintainability  @item Maintainability
89  The code base of GEAS itself must be and remain maintainable by the GEAS  The code base of GNUe Appserver itself must be and remain maintainable
90  development team, and the code must be clear enough to allow interested  by the development team, and the code must be clear enough to allow
91  programmers to adapt it, fix bugs or even take over maintenance of a part  interested programmers to adapt it, fix bugs, or even take over maintenance
92  of GEAS.  of a part of Appserver.
93    
94  @item Configurability  @item Configurability
95  GEAS must be configurable and reconfigurable dynamically, centrally,  GNUe Appserver must be configurable and reconfigurable dynamically, centrally,
96  without programming skills, without downtime, and in seperate "layers"  without programming skills, without downtime, and in separate "layers"
97  for various levels of specification.  for various levels of specification.
98    
99  @item Performance  @item Performance
100  GEAS must perform reasonably with large quantities of users and/or data.  GNUe Appserver must perform reasonably well with large quantities of users
101    and/or data.
102    
103  @item Database Independence  @item Database Independence
104  GEAS must be able to use a number of database systems as backend.  GNUe Appserver must be able to use a number of database systems as backend.
105    
106  @item Portability  @item Portability
107  GEAS must run on multiple operating systems and architectures.  GNUe Appserver must run on multiple operating systems and architectures.
108    
109  @item Communication Independence  @item Communication Independence
110  GEAS must be able to use a number of communication means to communicate  GNUe Appserver must be able to use a number of communication means to
111  with the front end (CORBA, XML-RPC...).  communicate with the front end (CORBA, XML-RPC...).
112    
113  @item Language Independence  @item Language Independence
114  GEAS must be able to deal with business methods written in different  GNUe Appserver must be able to deal with business methods written in different
115  languages.  languages.
116  @end table  @end table
117    
118  @c ============================================================================  @c ============================================================================
119  @node Features,                               Implementation, Introduction, Top  @node Features,                                 Architecture, Introduction, Top
120  @c ============================================================================  @c ============================================================================
121    
122  @chapter Features  @chapter Features
123    
124  @section Business Objects  @section Business Objects
125    
126  GEAS allows definition of data entities (for example name and address of a  GNUe Appserver allows definition of data entities (for example, name and
127  customer) and of program code to perform on such entities (for example how to  address of a customer) and of program code to perform on such entities
128  build the address line from country, zipcode and city).  (for example, how to build the address line from country, zipcode, and city).
129    
130  The combination of a data entity with all code functions that can be performed  The combination of a data entity with all code functions that can be performed
131  on the entity is called a @dfn{business object}.  on the entity is called a @dfn{business object}.
132    
133  GEAS lets the user define @dfn{classes} of business objects. The class  Appserver lets the user define @dfn{classes} of business objects. The class
134  definitions describe both the data elements (called @dfn{attributes}) and the  definitions describe both the data elements (called @dfn{properties}) and the
135  available functions (called @dfn{methods}) of the business object.  available functions (called @dfn{procedures}) of the business object.
136    
137  The specific incarnation of a business object (for example a specific customer)  Procedures may also be bound to a specific event, that is, they are called
138  is called a business object @dfn{instance}.  automatically as soon as the event happens. These procedures are called
139    @dfn{bound procedures}.
140    
141  @section Attributes  @section Properties
142    
143  GEAS will provide the following attribute types:  GNUe Appserver will provide the following property types:
144    
145  @table @dfn  @table @dfn
146  @item Basic attributes  @item Basic property
147  contain most of the actual information, in the basic attribute types  contain most of the actual information, in the basic property types
148  @dfn{string}, @dfn{number}, @dfn{datetime}, and @dfn{boolean}. Examples  @dfn{string}, @dfn{number}, @dfn{datetime}, and @dfn{boolean}. Examples
149  could contain customer name, item price, invoice date, and invoice payment  could contain customer name, item price, invoice date, and invoice payment
150  status.  status.
151    
152  @item Compound attributes  @item Compound properties
153  are a means for combining attributes that logically belong together and appear  are a means for combining properties that logically belong together and appear
154  repeatedly in the same combination. Compound attributes can be built from  repeatedly in the same combination. Compound properties can be built from
155  attributes of any type, not only of basic attributes. An example could be a  properties of any type, not only of basic properties. An example could be a
156  monetary value consisting of the amount and the currency.  monetary value consisting of the amount and the currency.
157    
158  @item Reference attributes  @item Reference properties
159  point to another object and declare a relation between two objects. The value  point to another object and declare a relation between two objects. The value
160  of a reference attribut is another object. Examples include the customer of an  of a reference property is another object. Examples include the customer of an
161  invoice or the preferred vendor of an item.  invoice or the preferred vendor of an item.
162    
163  @item List attributes  @item List properties
164  point to lists of objects and declare a relation between these objects. The  point to lists of objects and declare a relation between these objects. The
165  value of a list attributes is a list of objects of a defined class, where all  value of a list properties is a list of objects of a defined class, where all
166  objects in the list will be of the same class. Examples include all line items  objects in the list will be of the same class. Lists are actually nothing more
167  of an invoice, or all contact persons of a customer.  than a shortcut for frequently used filters. Examples include all line items
168    of an invoice, or all line items of all invoices containing a specific stock
169  @item Calculated attributes  item, or all invoices of a customer.
170  contain information that is generated by GEAS out of other attributes.  
171  Calculated attributes are generally read-only. An example could be the total  @item Calculated properties
172    contain information that is generated by Appserver out of other properties.
173    Calculated properties are generally read-only. An example could be the total
174  value of an invoice item (calculated from price * pieces) or the total value  value of an invoice item (calculated from price * pieces) or the total value
175  of an invoice (calculated from all total item values).  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.  
176  @end table  @end table
177    
178  @section Methods  @section Procedures
179    
180  A method is code performed on an object. Methods can have parameters of any  A procedure is code performed on an object. Procedures can have parameters
181  attribute type (string, number, reference, etc.). Every method has the paramter  of any attribute type (string, number, reference, etc.). Every method is passed
182  @dfn{self}, that is the object instance to operate on, as a parameter.  a parameter, @dfn{self}, that identifies the object to operate on.
183    
184  @section Modules  @section Modules
185    
186  Modules define namespaces for classes, attributes, and methods. When module A  Modules define namespaces for classes, properties, and procedures. When
187  defines a class and some attribute and methods for the class, module B can  module A defines a class with various properties and procedures,
188  extend the class with new attributes. Another module C can independently  module B can extend the class with new properties. Another module, C, can
189  extend the class, without taking care about not using the same attribute names  independently extend the same class, without fear of conflicting with module B.
190  as module B, because all modules have their own namespace.  All modules have their own namespace.
191    
192  @section Qualified class, attribute and method names  @section Qualified class, property and procedure names
193    
194  @emph{Note: This section is absolutely subject to discussion. We are looking for  Class, property, and procedure names can be preceded by a module name to
195  a good and understandable syntax for fully qualified names.}  override the current module context. In this case, the module name is
196    separated by an underscore (_). This results in the rule that neither
197  Class, attribute and method names can be preceded by a module name to override  a module name nor a class, property or procedure name may contain an
198  the current module context. In this case, the module name is separated by a  underscore.
 colon (:).  
   
 Compound attribute names can be followed with a dot (.) and a member name of the  
 compound.  
199    
200  Reference attribute names can be followed with a dot (.) and a attribute name  Property and procedure names are separated from the object references by
201  of the referenced object to form an indirect attribute.  a dot (.).
202    
203  Example:  Example:
204    
205  Module "cust" defines a class "customer". Module "sales" defines a class  Module "cust" defines a class "customer". Module "sales" defines a class
206  "invoice_head" and a class "invoice_item". Module "base" defines a class  "invoiceHead" and a class "invoiceItem". Module "base" defines a class
207  "item".  "item".
208    
209  Then, @code{cust:customer} is the fully referenced class name for the  Then, @code{cust_customer} is the fully referenced class name for the
210  customer class, and @code{sales:invoice_head} is the fully referenced class  customer class, and @code{sales_invoiceHead} is the fully referenced class
211  name for the invoice_head class.  name for the invoiceHead class.
212    
213  Now, let module "cust" define the attributes "name" and "address" for the  Now, let module "cust" define the properties "name" and "address" for the
214  customer class, where address is a compound attribute consisting of "street"  customer class, where address is a compound property consisting of "street"
215  and "city".  and "city".
216    
217  The following are now valid attribute references of a customer object:  The following are now valid property references of a customer object:
218    
219  @code{name} or @code{cust:name} is a base attribute.  @code{name} or @code{cust_name} is a base property.
220    
221  @code{address} or @code{cust:address} is a compound attribute.  @code{address} or @code{cust_address} is a compound property.
222    
223  @code{address.street} or @code{cust:address.street} is a compound member  @code{address.street} or @code{cust_address.street} is a compound member
224  attribute.  property.
225    
226  Now, the module "sales" extends the customer class by a attribute "last_invoice"  Now, the module "sales" extends the customer class by a property "lastInvoice"
227  which is a reference to an invoice_head object.  which is a reference to an invoiceHead object.
228    
229  @code{sales:last_invoice} is a reference containing an invoice_head object.  @code{sales_lastInvoice} is a reference containing an invoice_head object.
230    
231  If module "sales" defines the attribute "number" and "items" in  If module "sales" defines the attribute "number" and "items" in
232  "invoice_header", then  "invoiceHeader", then
233    
234  @code{sales:last_invoice.number} is an indirect attribute and  @code{sales_lastInvoice.number} is the number of the last invoice of the
235    customer. We could call that an @dfn{indirect property}.
236    
237  @code{sales:last_invoice.items} is an indirect attribute, which is a list  @code{sales_lastInvoice.items} is an indirect list property.
 attribute.  
238    
239  And if yet another module "acct" extends the invoice_header class by a  And if yet another module, "acct", extends the invoice_header class by a
240  attribute "paid", then  property "paid", then
241    
242  @code{sales:last_invoice.acct:paid} could be a boolean attribute that tells you  @code{sales_lastInvoice.acct_paid} could be a boolean property that tells you
243  whether the customer has paid his last invoice or not, and you would access  whether the customer has paid his last invoice or not, and you would access
244  it just as easy as the "name" attribute. However, this attribute would only be  it just as easy as the "name" attribute. However, this attribute would only be
245  available if all three modules "cust", "sales", and "acct" are installed.  available if all three modules "cust", "sales", and "acct" are installed.
246    
247  @section Triggers  @section Bound Procedures
248    
249  @dfn{Triggers} are methods that are automatically called upon occurance of  @dfn{Bound procedures} are procedures that are automatically called upon
250  defined @dfn{events}, for example on every change of a specific attribute,  occurance of defined @dfn{events}; for example, on every change of a
251  or before a commit of a changed object.  specific property or before a commit of a changed object.
252    
253  Triggers are always methods of the object where the event occurs. Because  Bound procedures are always procedures of the object where the event occurs.
254  every module can extend any class with a method of arbitary name, calling  Because every module can extend any class with a procedure of arbitary name,
255  of triggers could be automated by method name.  calling of bound procedures could be automated by method name.
256    
257  Example:  Example:
258    
259  The cust module, which defines the customer object, defines a method  The cust module, which defines the customer class, defines a procedure
260  "OnChangeName", whose fully qualified name is of course  "OnChangeName", whose fully qualified name is of course
261  @code{cust:OnChangeName}.  @code{cust_OnChangeName}.
262    
263  The sales module could extend the customer class by a method and also call  The sales module could extend the customer class by a procedure and also call
264  this method "OnChangeName", because the fully qualified name of this method  this it "OnChangeName", because the fully qualified name of this procedure
265  will be @code{sales:OnChangeName} and therefore different from the other  will be @code{sales_OnChangeName} and therefore different from the other
266  method.  procedure.
267    
268  If the attribute "Name" is changed in a customer object, GEAS would call both  If the property "Name" is changed in a customer object, Appserver would call
269  methods because both are named "OnChangeName". The order of the method calls  both procedures because both are named "OnChangeName". The order of the
270  would be unpredictable.  calls would be unpredictable.
271    
272  @c ============================================================================  @c ============================================================================
273  @node Implementation,                            Building Blocks, Features, Top  @node Architecture,                                     Overview, Features, Top
274  @c ============================================================================  @c ============================================================================
275    
276  @chapter Implementation  @chapter Architecture
277    
278  @menu  @menu
279  * Building Blocks::  * Overview::
280  * Data Interface::  * Data Interface::
281  * Methods Adapter::  * Code Interface::
282  * Object Repository::  * Class Repository::
283  * Object Access Translator::  * Authentication Interface::
284  * Security Adapter::  * Object Server::
285  * Remote Protocol Adapter::  * RPC Interface::
286    * Language Interface::
287  @end menu  @end menu
288    
289  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
290  @node Building Blocks,           Data Interface, Implementation, Implementation  @node Overview,                      Data Interface, Architecture, Architecture
291  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
292    
293  @section The basic building blocks  @section Overview
294    
295    @image{AppserverArch}
296    
297  @table @dfn  @table @dfn
298    
299  @item Data Interface:  @item Data Interface:
300  abstracts database access from a specific database API and from SQL.  abstracts database access from a specific database API and from SQL.
301    
302  @item Methods Adapter:  @item Code Interface:
303  abstracts calls to methods from the language and the specific API.  abstracts calls to methods from the language and the specific API.
304    
305  @item Object Repository:  @item Class Repository:
306  holds and provides the definition of objects.  holds and provides the definition of classes.
307    
308  @item Object Access Translator:  @item Authentication Interface:
309    provides a way to authenticate a user and define his access rights.
310    
311    @item Object Server:
312  translates all requests to the business objects into appropriate database  translates all requests to the business objects into appropriate database
313  transactions and method calls, by using the other building blocks.  transactions and method calls, by using the other building blocks.
314    
315  @item Security Adapter:  @item Remote Protocol Interface:
316  handles security  provides the Appserver API to a remote client via various RPC mechanisms.
317    
318  @item Remote Protocol Adapter:  @item Language Interface:
319    provides easy access to business objects for procedure code and for internal
320    use by Appserver
321  @end table  @end table
322    
323  @section Theory of Operation  @section Theory of Operation
# Line 326  will provide data: Line 328  will provide data:
328  @enumerate  @enumerate
329  @item  @item
330  The client requests an object from the app server through the Remote Protocol  The client requests an object from the app server through the Remote Protocol
331  Adapter.  Interface.
332    
333  @item  @item
334  The Application Server checks if the requested class name is  The Object Server checks if the requested class name is
335  valid (according to the given definitions, i.e. via XML)  valid by looking up the class definition in the Object Repository.
 by looking up the class definition in the Object Repository.  
336    
337  @item  @item
338  If it's valid, the Object Access Translator translates a class name  If the class name is valid, then the Object Server uses the Authentication
339  into a table name. This will include adding a prefix to enable different  Interface to check whether the connected user may access this class.
 application modules to have their own namespace.  
340    
341  @item  @item
342  Then the Application Server passes the database request to the Data Interface  If both are OK, the Object Server translates the class name into a table name.
343    This will include adding a prefix to enable different application modules
344    to have their own namespace.
345    
346    @item
347    Then the Object Server passes the database request to the Data Interface
348  to actually get the data.  to actually get the data.
349  @end enumerate  @end enumerate
350    
351  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
352  @node Data Interface,          Methods Adapter, Building Blocks, Implementation  @node Data Interface,                    Code Interface, Overview, Architecture
353  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
354    
355  @section GNU Enterprise Data Interface (GEDI)  @section Data Interface
356    
357    The Data Interface provides an API that allows creation and extension of
358    tables, reading of data and updating, adding and deleting of records in
359    a table, all without SQL.
360    
361  GEDI will provide an API that allows creation and extension of tables,  Eventually, the Data Interface will support creating and extending tables
362  reading of data and updating, adding and deleting of records in a table,  "on the fly", which means that reading a recordset with attributes that
363  all without SQL.  don't exist in the database will automagically add the missing columns to
364    the table.  This will, of course, be an optional feature that can be turned
365    off.
366    
367  Eventually, GEDI will support creating and extending tables "on the fly",  The Data Interface operates strictly on a table/row interface and doesn't
368  which means that reading a recordset with attributes that don't exist in the  know anything about objects, properties and procedures.
 database will automagically add the missing columns to the table.  This  
 will of course be parameterized.  
369    
370  GEDI operates strictly on a table/row interface and doesn't know anything  The Data Interface used in GNUe Appserver is part of GNUe Common.
 about object, attributes and methods.  
371    
372  GEDI actually consists of two mostly independent parts, the Database Adapter  @c ----------------------------------------------------------------------------
373  and the SQL generator.  @node Code Interface,            Class Repository, Data Interface, Architecture
374    @c ----------------------------------------------------------------------------
375    
376  The Database Adapter is completely backend dependent and provides an  @section Code Interface
 abstraction of the different APIs of the various database systems.  
377    
378  The SQL generator generates valid SQL statements from requests that come  The Code Adapter will abstract the calls to business methods written in
379  in through the table/row interface.  As most SQL databases share a major  the different languages.
380  part of the SQL syntax, this module can be mostly backend independent,  
381  which means that the drivers for the different databases share a lot of  Python will be the only language supported for the near future.
382  code.  However, there are differences in SQL syntax, and so parts of this  
383  code has to be backend specific.  An object oriented programming language  The Code Adapter, or at least parts of it, will reside in GNUe Common.
 that provides inheritance could be very helpful in implementing this.  
384    
385  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
386  @node Methods Adapter,        Object Repository, Data Interface, Implementation  @node Class Repository,  Authentication Interface, Code Interface, Architecture
387  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
388    
389  @section GNU Enterprise Methods Adapter (GEMA)  @section Class Repository
390    
391  GEMA will abstract the calls to business methods written in the different  The Class Repository will hold all the business object definitions:
392  languages.  what properties the object consists of, what procedures exist, which
393    bound procedures should be called on what event, and so on.
394    
395  Python will be the only language to support here for probably a long time,  The class definitions will be stored in the database and be accessible
396  so in the first versions, GEMA will be more of a stub than of a real module.  like normal business objects. Consequently, the Class Repository will
397    access the definitions via the Python Language Interface.
398    
399  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
400  @node Object Repository,Object Access Translator,Methods Adapter,Implementation  @node Authentication Interface,   Object Server, Class Repository, Architecture
401  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
402    
403  @section GNU Enterprise Object Repository (GEOR)  @section Authentication Interface
   
 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.  
404    
405  The object definitions could be stored in @code{.gcd} files, in XML files,  The Authentication Interface will provide a means to authenticate a user
406  or in the database.  on connection to the Appserver, and to check access rights for an already
407    connected user.
408    
409  It should be possible to change object definitions and bring them into  For the sake of flexibility and independence from operating system and
410  effect without restarting the server. This might be very hard to achieve  database backend, access rights per user will probably be stored in the
411  for ways of storage other than database.  database and be accessible via system business objects.
412    
413  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
414  @node Object Access Translator,Security Adapter,Object Repository,Implementation  @node Object Server,      RPC Interface, Authentication Interface, Architecture
415  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
416    
417  @section GNUe Object Access Translator (GOAT)  @section Object Server
418    
419  This is the main part of the Application Server.  This is the central part of the Application Server.
420    
421  GOAT uses GEDI and GEMA to fulfill requests directed at business objects,  The Object Server uses the Data Interface and the Code Interface to fulfill
422  after it has checked the validity of the request against GEOR.  requests directed at business objects, after it has checked the validity
423    of the request against the Class Repository and the Authentication Interface.
 Security will be implemented here, as a request can simply be rejected if  
 the user doesn't have the necessary permissions.  
424    
425  Security implementation will also select or reject based on the users  Security implementation will also select or reject based on the users
426  authorizations to any regular query.  authorizations to any regular query.
427    
428  Example:  if the division president uses a form to request all sales  Example:  if the division president uses a form to request all sales
429  orders, GOAT will query the database and return only the object data  orders, Appserver will query the database and return only the object data
430  that represents the divisions sales orders.  that represents the divisions sales orders.
431    
432  Form level (view) security will not be enforced by GOAT.  Form level (view) security will not be enforced by Appserver.
433    
434  GOAT will also provide object transparency.  Meaning that there will  The Object Server will also provide object transparency.  Meaning that
435  not necessarily be a direct relationship between business objects and  there will not necessarily be a direct relationship between business
436  tables.  objects and tables.
437    
438  While accessing data from the database (via GEDI), GOAT will also  While accessing data from the database via the Data Interface, the Object
439  automagically check for defined trigger methods, and call them (via GEMA).  Server will also automagically check for defined bound procedures, and call
440    them via the Code Interface.
441    
442  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
443  @node Security Adapter,Remote Protocol Adapter,Object Access Translator,Implementation  @node RPC Interface,            Language Interface, Object Server, Architecture
444  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
445    
446  @section Security Adapter  @section Remote Protocol Interface
447    
448  To be defined  The Remote Protocol Interface is used to export the functionality of the
449    Application Server over the net, using a variety of RPC mechanisms.
450    
451  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
452  @node Remote Protocol Adapter,            FDL, Security Adapter, Implementation  @node Language Interface,                      FDL, RPC Interface, Architecture
453  @c ----------------------------------------------------------------------------  @c ----------------------------------------------------------------------------
454    
455  @section Remote Protocol Adapter  @section Language Interface
456    
457  The Remote Protocol Adapter is used to export the functionality of the  The Language Interface will make business objects easily accessible for code
458  Application Server over the net, using a variety of RPC mechanisms.  written in supported languages. Each language will have it's own Language
459    Interface.
460    
461    For example, the Python Language Interface (which will be the first one
462    implemented) lets you access business objects as if they are
463    normal Python objects.  Procedures written in Python will use this
464    interface to access business objects in a rather straightforward way.
465    Other parts of the Application Server also use the Language Interface to
466    access system objects like the ones defining classes or access rights
467    
468  @raisesections  @raisesections
469    
470  @c ============================================================================  @c ============================================================================
471  @node FDL,                                 (null), Remote Protocol Adapter, Top  @node FDL,                                      (null), Language Interface, Top
472  @c ============================================================================  @c ============================================================================
473    
474  @include fdl.texi  @include fdl.texi

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.1.4.1

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26