DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 11 of 11

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

  1. #1
    Matthew Cromer Guest

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


    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

  2. #2
    Richard Dalton . Guest

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



    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?


  3. #3
    Dennis Guest

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

    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




  4. #4
    Kevin Downs Guest

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

    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




  5. #5
    Richard Dalton . Guest

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



    "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

  6. #6
    Richard Dalton . Guest

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


    "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

  7. #7
    Kevin Downs Guest

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

    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




  8. #8
    Richard Dalton . Guest

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


    "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"

  9. #9
    Vain Freeman Guest

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


    "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.

  10. #10
    Phil Weber Guest

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

    > 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.



  11. #11
    Richard Dalton . Guest

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


    "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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center