Re: Three-Tier Client Server

>From: ramirez_at_iastate.edu (Richard G Ramirez)
>Newsgroups: comp.databases.oracle
>Date: 1 Jun 1995 15:58:47 GMT
>Organization: Iowa State University, Ames, Iowa USA
>Lines: 36
>References: <3piv9k$8db_at_niven.ksc.nasa.gov> <3plhp9$c04_at_newsbf02.news.aol.com> <3qb2pi$280_at_news.intacc.net>
>NNTP-Posting-Host: pv34c2.vincent.iastate.edu
>Originator: ramirez_at_pv34c2.vincent.iastate.edu
>
>
>|>
>|> Oracle calls this either a "three tier client/server environment",
>|> "client/server/server", or more usually a "co-operative server
>|> environment".
>

we also call it "client/agent/server," especially if you implement it with our Oracle Mobile Agents product. claimer: i'm on the development team for OMA, so beware of my inherent biases, that i have made no attempt to smooth over...

>|> A client can simply connect to one database and that database can then
>|> connect to anything else required through the use of database links,
>|> views, synonyms, etc. Oracle's Transparent Gateways are all built on
>|> this type of an architecture. Actually, pretty much anything you do with
>|> Oracle supports this type of connectivity nicely.
>|>
>
>Can someone provide specific examples? I understand the concept but
>I don't know how to translate it into application code.
>
>From the above message I understand an implementation using
>
> 1 - Powerbuilder on the client (or Visual Basic or Access)
> 2 - an Oracle server with procedures and perhaps some triggers,
> it also stores user passwords
> 3 - one or more Oracle servers having the actual databases,
> possibly containing procedures and triggers that are local
> to that database
>

OMA provides an asynchronous, connectionless, message-based architecture in contrast to standard network protocols (including SQL*Net) which are synchronous, connection-oriented, and stream-based.

this provides a system which has many interesting properties, which i won't go into here. if you are familiar with tp-monitors, that's a start of a way of thinking about OMA apps, but it's not the complete picture.

an OMA system looks like the following:
1 - a client application written in Forms, Power Objects, C++,

     Powerbuilder, Visual Basic, whatever..  communicating with the OMA
     Message Manager
2  - an agent, written in C or C++, using the OMA Agent Event Manager
     library.  an OMA agent is event-based, with the events being
     messages sent by clients, other agents, etc.  all you write is
     the message handlers.
3  - one or more Oracle servers, as above, and/or one or more other
     non-oracle (possibly non-rdbms) data sources.

>An alternative is to use C++ (or another language) in 2 as the
>intermediate step. Of course this alternative is much harder.
>
>Please clarify for me.
>
>Thanks
>
>--
>Richard G. Ramirez, Ph. D.
>Assistant Professor of MIS
>Iowa State University

hope this helps.

--
This opinion will self destruct in 5 seconds.
Danny van der Rijn--dvanderr_at_oracle.com   || Take my advice ---
                                          || *I'm* certainly not using it.
(415) 506-3142                            ||