Re: multi-tier architecture

The entire SAP system is three tier. It supports many backend databases (Oracle, Informix, MS SQL Server, DB2,,,). The middle tier has a database-specific interface. This allows the applications to be written in a lowest-common- denominator version of SQL.

The middle tier interpretivly executes programs written in their ABAP/4 language. This language is totally machine independent. It can run on AIX, HPUX, Solaris, NT,,,,. Maybe Sun got the idea of the virtual JAVA machine from SAP? Scalability is achieved by adding machines to the middle tier. It is even possible to mix machine vendors in the middle tier!

The middle tier also supports numerous services. For example, business units of work that span multiple database transactions. Since all database locks are lost with each commit, SAP provides a middle tier locking scheme that persists for the duration of the business unit of work.

The middle tier provides user authentication, authorization, etc. No user ever logs in to the database directly. (Well, the DBA's do, but we don't count!)

The middle tier provides EDI communication with suppliers and customers, network printing and many other system services.

The SAPGUI presentation tier runs under windows or nt. TCP/IP connects SAPGUI to the middle tier. SAPGUI is a thin client with no application logic on the PC.

I am not selling SAP here. I just want you to know how another 3 tier package has been built. If you can get hold of their documentation CD, you'll have a great outline of your project needs.

HTH Judy Morris wrote:

> We are beginning (or preparing to begin) a project moving our software to a
> three-tier architecture. The main reason is that we need to support
> multiple databases (the application is currently written in Oracle). We
> know we're going to use Java for the middle layer and we're probably going
> to use COM. I don't know much about it - I'm just beginning to read up on
> the subject. Because we're supporting multiple databases, we do not want
> to use a database-specific product like Oracle Application Server.
>
> I have several questions/requests:
>
> 1. Can anyone recommend some good books or articles on design
> considerations for this type of architecture?
>
> 2. Can anyone recommend some good third-party components for security,
> connection, load-balancing, etc?
>
> 3. Does anyone have any advice, rules-of-thumb, etc. for which application
> logic we should move into the application server layer and which we can
> leave in the database? I'm thinking that basic "database rules" (as
> opposed to business rules) would remain in the database: maintaining
> denormalized fields, complex constraints, that sort of thing. Although
> I'll have to simplify my multiple-trigger row-level triggers in Oracle to
> the statement-level-only-one-per-type triggers in Sybase and SQL-Server.
> (I'm not looking forward to that - I love my Oracle triggers.)
>
> 4. How does executing Java components from triggers compare to triggers
> calling database packages/procedures in terms of speed, memory-use, etc?
>
> 5. How does sending multiple instructions to the database from Java
> compare to sending only a single instruction to the database and letting
> the db handle all of the remaining processing?
>
> Obviously, we're struggling with the eternal flexibility vs. speed
> tradeoff.
>
> Thanks,
> Judy Morris
Received on Sat Mar 06 1999 - 16:54:33 CST