Re: [Gnue-dev] Halloween 5: Appserver Architecture

[Derek Neighbors]

On Sun, 2002-11-03 at 16:24, Jan Ischebeck wrote:
> On Sun, Nov 03, 2002 at 09:01:04AM -0700, Derek Neighbors wrote:
> > What I am not seeing here is that really method code should be the same
> > as 2 tier trigger code.  I am highly concerned that this is pushed into
> > appserver instead of into common in what currently is called triggers.
> 
> 1. It is an important aim to write code once and have it working in both
> 2-tier and 3-tier setups. We should try to make it possible.

Correct.

> 2. If code can be reused it should. But the code in appserver to make
> methods work and the code in common for the trigger system have
> different design criteria. As I stated before I will try to reuse and
> enhance the common trigger code, but I'm not shure if its possible.

Before we deem things not possible or extend/implement trigger stuff,
really the appserver developers and forms developers should be
exchanging ideas.  To help eliminate frustrations, not to 'debate'
things to death. A fine line at some times I know. ;)

> > I hope we plan on using the authentication stuff that forms uses?  I
> > think Jason created a 'plugin' of sorts that is in common.  If not the
> > security wrapper should be the same for forms/reports/designer/appserver
> > and part of common as to not 'redo' workd.
> > 
> The "job" of both "plugins" are quite different.
> The authentification plugin in common FETCHES (f.e. from the user) 
> authentification information to provide it to databases/middleware etc. for
> authentification. The auth. plugin of appserver gets some information
> (f.e. information, which was collected by the first plugin used by
> forms, reports etc.) and validates it. 

I think it all needs to be in common.  How its factored as to what
elements do what, is of lesser concern from the 500ft view.

> I really like the idea of having common, but I don't think that
> everything has to be moved into common at once. I would prefer to first
> implement the appserver auth plugin in appserver and wait till any other
> application needs stuff like that before moving it into common.

I am not sure I agree with this.  As I think all applications could
benefit from better security/data restriction and being forced to make
more than one tool support it from the beginning will only better raise
the issues sooner.  Certainly the appserver, forms, reports teams need
to discuss this in some fashion before proceding. I think the output of
those discussions would dictate whether to start it in common or just
move it there later.

> > > We have also talked about the definition of "views", that is the
> > > possibility of creating different "masks" that are puts over the
> > > business objects depending on the user. Like:
> > > * User joe sees all customers with all their properties
> > > * All users from sales see all products, but they don't see any purchase
> > > related properties of the product objects
> > > * Users from the sales department only see the customers of the region
> > > they are responsible for
> > > * Every department leader can see all employee objects, but the wage
> > > property is only writeable for the employees in his department.
> > 
> > Role Based Access Control or Access Control Lists should also be
> > addressed probably in common as ALL tools will need it.
> > 
> First priority is to implement it, so that appserver can use it. If forms,
> reports etc. can use it too, its a nice side effect. But forms, reports
> needs a much different and more advanced security structure, so IMHO it isn't
> worth the effort. It could even make common work slower.
> (I don't think that the user of reports would like that)

I think I disagree with this very much.  This is the view that I feared,
that supporting things in the other tools would be an after thought
instead of a forethought.  Again I think the developers of the tools
need to discuss some before implementation and they can as a collective
decide what to implement where.

> > > We are looking forward for feedback.
> > 
> > I skimmed VERY briefly so am only giving initial feedback.  Again my
> > worry here is that all this stuff looks good, but basically seems to
> > completely forget that the rest of GNUe exists.  
> 
> Please look into the Halloween 2 mail. To use appserver for anything,
> you allways will need the rest of gnue. 

That isnt my largest fear, but if appserver needs anything but common
that is troublesome.  My fear is that to use anything in GNUe you will
need appserver.  Putting things like security and triggers in appserver
only means that you woudl have to use appserver to get at those
features.  This is not acceptable according to our mission of 'all tools
can be used independently or together'.

> > Please before doing any implementation lets make sure all of the core
> > agrees.  Many of the concepts here are going directly against prior
> > mission statements.  I am not saying that means they are not valid or
> > that our mission may not have changed, but I'd rather get some concenus
> 
> I really like the idea of forms and of having a multifunctional fat client in 
> a two tier setup, but there is a need for having a three tier setup too.
> Please give us some air to breath, some ideas to implement WITHOUT
> having to port them to forms directly. I think that a 2-tier and a
> 3-tier setup will be used in different situtations, and that many
> features just make sense for a 3-tier setup as, are many which just make
> sense in a 2-tier setup. 

The problem is we cant dictate this.  It is purely a developers
decision.  Many developers think there is a highly limited need for
n-tier in any situation and even in extremely large situations 2 tier is
more than enough.  Certainly at my place of employment we process about
2.5 billion dollars in transactions and cut pay checks for just over
15,000 individuals all using 2 tier. (I am not saying I dont value
n-tier, just stating that 2 tier is not a size limitation but rather an
opinion of preference)

> I really want to get some hints about how you would like appserver to do 
> things, what appserver should do and what not. But I don't like to just hear a
> "MOVE IT INTO COMMON". I don't think appserver == common, as I don't
> need a orcale database coded into forms.

I think anything that more than one tool needs, should be in common.  I
dont think that takes a 'debate' on the implementation.  I speaking from
an architectural standpoint not an implementation standpoint.  Certainly
at one time we had an agreed upon list of appserver functionality. (see
below)  Personally I loathe Oracle, so Im not askign one be coded into
forms.



===============================================
Goals
-----
 1. Must be GPL and built with truly free tools.
 2. Allow methods (logic) to execute on appserver instead of on client
and/or database.
 3. Must be reasonably stable.
 4. Must be reasonably secure.
 5. Must be easily maintained.
 6. Must be usable by business class users (not just programmers).
 7. Must perform reasonably with large quantities of users and/or data.
 8. Must be easy to configure and adaptable without downtime.
 9. Communicate with an number of backend datastorage.
10. Must run on multiple OSes and Architectures.
11. Communitate via a multitude of different tranportaion methods.
12. Methods support a number of different languages. (lesser goal)

must be configurable dynamically, centrally, w/o programming skills,
without downtime, and in seperate "layers"
           for various levels of specialization

<reinhard> 1. we will do new implementation of geas in python
<reinhard> 2. jamest and jcater will document common
<reinhard> 3. we will look at common and see what we can use there
and/or what has to be changed
<reinhard> 4. we will implement a prototype that is possibly limited


<reinhard> ******************************************
<reinhard> next steps:
<reinhard> jamest/jcater: document common
<reinhard> dneighbo: write down the result of this discussion
<reinhard> reinhard: prepare proposal for GEASv2 API against front end
<reinhard> all: comment on this API
<reinhard> ******************************************

========================================================
 
-- 
Derek Neighbors
GNU Enterprise
http://www.gnuenterprise.org
address@hidden

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=dneighbo

signature.asc
Description: This is a digitally signed message part