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 |
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 |
|
|
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 |
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 |