Physical 3-tier -- is it all it's cracked up to be?

[Matthew Cromer]

I am about to make a terrible admission. We've been writing a number of systems
very successfully -- using a physical 2 tier model. We have more or less
total control of the database schema, and create our business objects as
tables in the database. We do have a few server applications which run on
the database machine (although they don't have to) to process data, purge
logs, etc. The clients connect directly via SQL*NET to the (Oracle) database.

On the client side, there is a logical tiering between the GUI and an in-process
database layer. In fact, there are quite a few layers, including a messaging
tier, a GUI tier, a DB tier, etc. But they all run in the clients process
(yes, Matilda, the clients do use quite a bit of memory). The database objects
are driven by database tables and use a generic framework to work with any
and all new tables.

Now I know that this is utterly politically incorrect and heinous, and that
all good programmers use physical 3-tier and clients never talk directly
to databases. And my stuff is all stateful as can be and caches DB values
and it slices, dices, and julienne fries.

I'm trying to figure out what benefits we would get with a more politically
correct system where clients only talked to the physical middle tier (using
DCOM or COM or IIOP or the like) and the middle tier was the only one who
spoke to the database. Keep in mind that we have complete control of the
database schema and are basically able to use DB Stored Procedures, triggers,
embedded Java code and the like to enforce business rule restrictions. The
downside that I see is that physical 3-tier is complex as far as having to
integrate more transport layers, it's more work for us to have to write middle-tier
code (right now to add business objects we basically just create tables in
the database using ER/Studio and can assemble a fully-featured client w/o
writing any code using prebuilt custom components.

Is everyone using the "standard" 3-tier physical approach absolutely thrilled
with it? Do you run into performance bottlenecks with your clients? Are
your clients responsive?

Matthew Cromer

[Richard Dalton .]

I've never been to an AA meeting, but I'm sure this is
what it feels like.

I'm in the position where I was building software in a way
that sounds very similar to yours. Then I got the job of
building a Framework for future projects and since that
included intranet and internet apps I decided 3-tier, windows
DNA etc, etc, was the way to go.

One thing is clear, my old way of writing software can't work
in a web environment, because you simply can't put lot's of
code into the client. And simply moving the code to the server
doesn't work, because it won't scale. You need a new way of
developing software.

The question was, could the n-tier concept work for my existing
apps. The ones where I can put a VB app on the client machine.
The theory said yes of course. Build your business objects,
build your data layers, and stick a nice thin VB app on the
client and it will work. And in the future if you want to
webify it it will be a breeze.

In short, I'm not overly impressed. I think if you are going to
develop web apps then you need to go n-tier, that's not even
in question. But if you want to keep building apps like you
have been, and you won't be going web based, then do not change
anything. It's rare to find people who are happy with the
way they build software, if that's you then don't change.

I am now looking at how to support a software company that
needs to develop both types of apps. Sure n-tier can be used
for web or non-web apps, but my question is, is it worth it?

Is there a case for building web based and non web based on
completely different frameworks?

I don't know the answer. Yet.

-Richard






"Matthew Cromer" <matthew@sdaconsulting.com> wrote:
>
>I am about to make a terrible admission. We've been writing a
>number of systems very successfully -- using a physical 2 tier
>model.

<snip>

>Now I know that this is utterly politically incorrect and
>heinous, and that all good programmers use physical 3-tier and
>clients never talk directly to databases. And my stuff is all
>stateful as can be and caches DB values and it slices, dices,
>and julienne fries.

<snip>

>Is everyone using the "standard" 3-tier physical approach >absolutely thrilled
with it? Do you run into performance >bottlenecks with your clients? Are
your clients responsive?

[Dennis]

I think Richard summed it up nicely, it really depends on the application
and how it's going to be used. We did some basic load testing on our app,
which is currently a two-tier web app with ASP pagest hitting the database
directly. It only took testing 5 simultaneous users to max out the web
server on a basic ASP page. We then took the same ASP page and had it use a
component on another box to hit database, and we load tested 50 simultaneous
users without maxing out either the web server or the component server.

So there are definite scalability gains to be had by going to the n-tier
architecture. But if you are getting all the performance you need and from
your current system, there's no reason to change just to be "politically
correct."

Dennis


"Matthew Cromer" <matthew@sdaconsulting.com> wrote in message
news:3a4c1f12$1@news.devx.com...
>
> I am about to make a terrible admission. We've been writing a number of
systems
> very successfully -- using a physical 2 tier model. We have more or less
> total control of the database schema, and create our business objects as
> tables in the database. We do have a few server applications which run on
> the database machine (although they don't have to) to process data, purge
> logs, etc. The clients connect directly via SQL*NET to the (Oracle)
database.
>
> On the client side, there is a logical tiering between the GUI and an
in-process
> database layer. In fact, there are quite a few layers, including a
messaging
> tier, a GUI tier, a DB tier, etc. But they all run in the clients process
> (yes, Matilda, the clients do use quite a bit of memory). The database
objects
> are driven by database tables and use a generic framework to work with any
> and all new tables.
>
> Now I know that this is utterly politically incorrect and heinous, and
that
> all good programmers use physical 3-tier and clients never talk directly
> to databases. And my stuff is all stateful as can be and caches DB values
> and it slices, dices, and julienne fries.
>
> I'm trying to figure out what benefits we would get with a more
politically
> correct system where clients only talked to the physical middle tier
(using
> DCOM or COM or IIOP or the like) and the middle tier was the only one who
> spoke to the database. Keep in mind that we have complete control of the
> database schema and are basically able to use DB Stored Procedures,
triggers,
> embedded Java code and the like to enforce business rule restrictions.
The
> downside that I see is that physical 3-tier is complex as far as having to
> integrate more transport layers, it's more work for us to have to write
middle-tier
> code (right now to add business objects we basically just create tables in
> the database using ER/Studio and can assemble a fully-featured client w/o
> writing any code using prebuilt custom components.
>
> Is everyone using the "standard" 3-tier physical approach absolutely
thrilled
> with it? Do you run into performance bottlenecks with your clients? Are
> your clients responsive?
>
> Matthew Cromer

[Kevin Downs]

I think there is still a lot of confusion regarding n-tier design. The main
misconception is that the tiers *must* be physically separate. They do not.
Most of the applications that I am supporting are 3 logical tier / 2 physical
tier, with the business tier either on the client or the db server machine. In
my experience, the only apps that really need the 3 physical tier model are
those running as web apps with large numbers of concurrent users.

The n-tier design gives you the *flexibility* to deploy as you feel fit,
though there are alway trade-offs between programming-ease,
administrative-ease, and scalability.

All that being said, I've never seriously regretted moving my mind-set to
n-tier design. ( though there have been days when DCOM security has driven me
almost insane<bg>)
--
Regards,
Kevin

"Matthew Cromer" <matthew@sdaconsulting.com> wrote in message
news:3a4c1f12$1@news.devx.com...
>
> I am about to make a terrible admission. We've been writing a number of
systems
> very successfully -- using a physical 2 tier model. We have more or less
> total control of the database schema, and create our business objects as
> tables in the database. We do have a few server applications which run on
> the database machine (although they don't have to) to process data, purge
> logs, etc. The clients connect directly via SQL*NET to the (Oracle)
database.
>
> On the client side, there is a logical tiering between the GUI and an
in-process
> database layer. In fact, there are quite a few layers, including a
messaging
> tier, a GUI tier, a DB tier, etc. But they all run in the clients process
> (yes, Matilda, the clients do use quite a bit of memory). The database
objects
> are driven by database tables and use a generic framework to work with any
> and all new tables.
>
> Now I know that this is utterly politically incorrect and heinous, and that
> all good programmers use physical 3-tier and clients never talk directly
> to databases. And my stuff is all stateful as can be and caches DB values
> and it slices, dices, and julienne fries.
>
> I'm trying to figure out what benefits we would get with a more politically
> correct system where clients only talked to the physical middle tier (using
> DCOM or COM or IIOP or the like) and the middle tier was the only one who
> spoke to the database. Keep in mind that we have complete control of the
> database schema and are basically able to use DB Stored Procedures,
triggers,
> embedded Java code and the like to enforce business rule restrictions. The
> downside that I see is that physical 3-tier is complex as far as having to
> integrate more transport layers, it's more work for us to have to write
middle-tier
> code (right now to add business objects we basically just create tables in
> the database using ER/Studio and can assemble a fully-featured client w/o
> writing any code using prebuilt custom components.
>
> Is everyone using the "standard" 3-tier physical approach absolutely
thrilled
> with it? Do you run into performance bottlenecks with your clients? Are
> your clients responsive?
>
> Matthew Cromer

[Richard Dalton .]

"Kevin Downs" <kdowns@nospam.optushome.com.au> wrote:

>The n-tier design gives you the *flexibility* to deploy as you >feel fit,
though there are alway trade-offs between programming->ease, administrative-ease,
and scalability.

True. And you're also correct to point out that tiers are
often located on the same physical machine.

Of course to have the flexibility of deploying as you see fit,
you have to code the tiers as if the were physically separate.
The issue of marchalling is of course the best example.

If you know that the tiers will always be physically running
in the same process then of course you can get speed by directly
referencing objects in one tier from another, setting properties, and calling
methods at will.

But that performance comes at a cost. You can't separate
these tiers easily. I call these Siamese Tiers.

If you want to retain the flexability you have to do all the
work of marshalling between tiers, even if you are pretty
sure that they'll run in the some process for the time being.

>All that being said, I've never seriously regretted moving my >mind-set
to n-tier design.

I would say that whether you are building Amazon.com or a tiny
admin tool in VB for one user, a tiered mentality is you biggest
friend.

It's a little know fact that John Lennon was originaly a
software architect. He wrote a song called
"All you need is abstraction", but it's wasn't
catchy enough. Even with the French national anthem. So they
changed it to "All you need is Love"

True story. Honest.


>(though there have been days when DCOM security has driven me
>almost insane<bg>)

Some would say that you must be insane to use it in the first
place. I wouldn't of course.

-Richard

[Richard Dalton .]

"Richard Dalton" . wrote:

I've just re-read that last mail and seen how many typo's
I made. Normally I'd let it go, but woah this was bad.

I guess typing at 1am after 5 cans of cola, isn't such a
good idea. (see how I didn't mention the brand.
I'm reading Naomi Klein's book)

Apologies all round.

-Richard

[Kevin Downs]

I've just got up after a mammoth coding session from 7pm till 5am.

I didn't even notice the typos.... <g>

bad luck on the Naomi Klein by the way - you'll need a case of "JOLT"
just to say awake... (irony intended)

--
Regards,
Kevin

<Richard Dalton .> wrote in message news:3a527a3e$1@news.devx.com...
>
> "Richard Dalton" . wrote:
>
> I've just re-read that last mail and seen how many typo's
> I made. Normally I'd let it go, but woah this was bad.
>
> I guess typing at 1am after 5 cans of cola, isn't such a
> good idea. (see how I didn't mention the brand.
> I'm reading Naomi Klein's book)
>
> Apologies all round.
>
> -Richard

[Richard Dalton .]

"Kevin Downs" <kdowns@nospam.optushome.com.au> wrote:
>bad luck on the Naomi Klein by the way - you'll need a case >of "JOLT" just
to say awake... (irony intended)

With irony like that, you can't be American.

Actually your words were slightly prophetic.
I ended up reading the **** thing until 4:30am

maybe it was the coke.

-Richard

"Coca Coma - You Can't Feel the Beating"

[Vain Freeman]

"Richard Dalton" . wrote:
>
>
>"Kevin Downs" <kdowns@nospam.optushome.com.au> wrote:
>
>>The n-tier design gives you the *flexibility* to deploy as you >feel fit,
>though there are alway trade-offs between programming->ease, administrative-ease,
>and scalability.
>
>True. And you're also correct to point out that tiers are
>often located on the same physical machine.
>
>Of course to have the flexibility of deploying as you see fit,
>you have to code the tiers as if the were physically separate.
>The issue of marchalling is of course the best example.
>
>If you know that the tiers will always be physically running
>in the same process then of course you can get speed by directly
>referencing objects in one tier from another, setting properties, and calling
>methods at will.
>
>But that performance comes at a cost. You can't separate
>these tiers easily. I call these Siamese Tiers.
>
>If you want to retain the flexability you have to do all the
>work of marshalling between tiers, even if you are pretty
>sure that they'll run in the some process for the time being.
>
>>All that being said, I've never seriously regretted moving my >mind-set
>to n-tier design.
>
>I would say that whether you are building Amazon.com or a tiny
>admin tool in VB for one user, a tiered mentality is you biggest
>friend.
>
>It's a little know fact that John Lennon was originaly a
>software architect. He wrote a song called
>"All you need is abstraction", but it's wasn't
>catchy enough. Even with the French national anthem. So they
>changed it to "All you need is Love"
>
>True story. Honest.
>
>
>>(though there have been days when DCOM security has driven me
>>almost insane<bg>)
>
>Some would say that you must be insane to use it in the first
>place. I wouldn't of course.
>
>-Richard


Great discusssion. I agree with Richard - to me the use of the 3 tier or
n-tier approach provides a great degree of flexibility. The main reason I
use this approach is to encapsulate each tier from specifics in other tiers.
My presentation or client apps simply rely on my business (middletier) for
business rule enforcement with out caring how it is accomplished, the same
for my middle-tier they can communicate with data services without needed
to know or care what the actual data store is. If I was to change my back-end
datasource, I can simply modify my dataservice component without any changes
in my client, or middle-tier modules.

[Phil Weber]

> I've just re-read that last mail and seen how many typo's
> I made. Normally I'd let it go, but woah this was bad.

Richard: There's no apostrophe in "typos." And "woah" (sic) is spelled
"whoa." ;-)

Thank you, by the way, for suggesting this group. It seems to have gotten
off to a good start, and I've enjoyed reading it.
---
Phil Weber
DevX.com, Inc.

[Richard Dalton .]

"Phil Weber" <pweber@devx.com> wrote:
> > I've just re-read that last mail and seen how many typo's
> > I made. Normally I'd let it go, but woah this was bad.
>
>Richard: There's no apostrophe in "typos." And "woah" (sic) is spelled
>"whoa." ;-)

Go on Phil, kick a man while he's down.
Have you no scruples?

-Richard