Re: Architecture ideas for n-tier app with diff backends

From: Doug Hutcheson <Doug.Hutcheson_at_dnr.qld.gov.au.no.ham.spam.thank.you.mam>
Date: Thu, 17 Jun 1999 10:40:34 +1000
Message-ID: <7k9g5q$fhv5@inet6.citec.com.au>

The most elegant solution to the n-tier problem, for me anyway, has been deploying Tuxedo transaction manager on the Unix back end and the corresponding Tuxedo client on the front end PC. The application then talks to the Tuxedo client, which in turn talks to the Tuxedo back end, which talks to the RDBMS, which talks to the database itself. In this model, all UI is handled by the client, which can be anything - VB, VC++, Access etc - while all business rules are encapsulated in the Tuxedo services on the Unix box.
In this way:

• ODBC is eliminated
• the Data layer can be replaced with an equivalent DB, without affecting the UI layers
• the UI layer can be replaced without affecting the DB
• multiple, disparate DBs can be accessed in a single Tuxedo transaction, simplifying processing at the client. In other words, you can build a Business Object via the Tuxedo services, which accesses data from almost anywhere and presents it to the client layer as a single, homogenous, data stream.

Just my $0.02
Cheers,
Doug

--
Having fun with Access...
but then, I'm on medication...

Dev Ashish's site & FAQ: http://home.att.net/~dashish Microsoft support: http://support.microsoft.com/support News archive: www.deja.com.

---

---

The surest sign for the existence of intelligent life in the universe is that we have not been contacted.

---

---

Alexander Nickolsky wrote in message <01beb7d5$d0ad7be0$0a00a8c0_at_nickol>...
>The most seroius problem with n-tier architecture that some
>existing end-user tools (MS Access for example, or Oracle
>data mining tool) are developed to be connected to the certain
>tier in your design (to say, to directly use the actual data via
>ODBC). So, the design of the whole system becomes more
>complicated. The most common solution is to allow read-only
>access for the underlying levels.
>
>Peter Daniels <peterd_at_snapsystems.com> wrote in article
><3766A024.B4962E4E_at_snapsystems.com>...
>> We are in the proccess of converting our MS Access 97 based application
>> to a 3+ tiered app that will be able to use either an Access 97, Access
>> 2000, SQLServer7, or Oracle 8.0.5 backend. I would like to open a
>> discussion about the caveats, tricks, and tips involved in such an
>> architecture. Currently, we are only concerned with the data tier. I
>> have a few ideas to fuel the fire:
>>
>> 1) separating the tiers into presentaion, business rules, data access,
>> dbms
>
>I'll assume presentation - business rules - object model - data access -
>dbms.
>At object model level you can do some generalisation of data and
>provide the better multi-user capabilities.
>
>> 2) breaking the data access tier into a single interface for the
>> presentation layer and possible multiple child interfaces for actually
>> talking to the different dbms.
>
>Those child interfaces usually turn into specific SQL statements
>for different dbms'es. In this case your data access level should
>provide necessary transaction control. Anyway, it can do it better
>than dbms.
>
>> 3) The compromise between leveraging dbms specific functionality and
>> maintaining easy revision control for conceptually similar data access.
>
>For just SQL scripts it is easy. The automated testing is also possible
>(load the same data - get the same responce), but you will need
>very detailed description of the stored procedures for developers.
>
>> 4) (a continuation of 3) using straight ANSI SQL in data tier components
>> vs dbms specific stored procedure languages.
>
>There ain't such thing as an ANSI SQL.
>
>> I hope this thread will provide insight for the armys of developers
>> required to design for multiple dbms.
>>
>Alexander
>
Received on Wed Jun 16 1999 - 19:40:34 CDT