Jun 4, 2001, 3:51 AM
Post #4 of 5
More complex doesn't necessarily mean superior - on the contrary. :)
Re: mutiple-tier design and structure of a web app
[In reply to]
The reason you might have more than 3 tiers is mostly pragmatic. For instance, you already have some other application or busines logic that you want to rely on in your own environment, so from your own 'business logic tier', you call another business logic tier, which itself relies on a separate data tier, and you end up with a 4-tier application.
Or you might need to go through some application gateway to reach the other application first, so you end up with a 5-tier application.
Or you have some common request broker already (with 3 or more tiers of its own), and you want to access it from your own (interface+logic) application, and you end up with a 5-tier architecture again.
That's the kind of architecture you can end up with if you have lots of existing applications working in different environments, and you want to start linking them together for your own application.
Solving stability or performance problems in this kind of environments can be quite challenging because you easily end up with 'domino effects', where a glitch in one sub-component can have totally unexpected side-effects on other components 2 or 3 tiers away.
And that's where some common middleware (distributed transaction processing, message queuing, object request broker, whatever) linking all the pieces together becomes essential - typically an N-tier architecture.
But that goes a bit beyond the scope of Perl :)