Skip to main content
added 44 characters in body
Source Link

There is a distinction between "Logical Architecture" and "Physical Architecture", you can have the same code base and yet deploy it on a Web Tier and Middle Tier, or just strictly on the Web Tier.

What you decide is based on a myriad of factors. Keep in mind, if If your Web Tier is merely a pass through to call more or less mirror services on the Middle Tier, then it would appear to me that the Middle Tier is pointless. Such an unnecessary physical architecture adds to Hardware Cost since most Enterprise level applications require redundandantredundant servers at all tiers. Also complicates Deployment and Maintenance, keep in. Keep the End Goal in mind, you can build the greatest App, but if complex deployment and maintenance eats away from your Development Time, then is it worth it? That middle tier Server would be better served as another Load Balanced server on the Web Tier. Keep in mind also thatAlso network latency overhead is the slowest and most unreliable between tiers, whereas if you call in memory JARS or DLLS without crossing process boundaries, or remoting via network, then obviously processing and response time would be the fastest for highhigher traffic scenarios.

However keep in mind its not a one size fits all to every solution. For certain functionality within the Application you may need Message Queues or Backend Services or Chron Services or Windows Services. Such as for disconnected workflows, or long running intensive processing. Which may indeed be considered a Middle Tier or "another" tier outside of the Web Tier for other Business Services.

The best rule of thumb is to never over-complicate over-engineer what is necessary for the business. Simple works, complex fails.

There is a distinction between "Logical Architecture" and "Physical Architecture", you can have the same code base and yet deploy it on a Web Tier and Middle Tier, or just strictly on the Web Tier.

What you decide is based on a myriad of factors. Keep in mind, if your Web Tier is merely a pass through to call more or less mirror services on the Middle Tier, then it would appear to me that the Middle Tier is pointless. Such an unnecessary physical architecture adds to Hardware Cost since most Enterprise level applications require redundandant servers at all tiers. Also complicates Deployment and Maintenance, keep in the End Goal in mind, you can build the greatest App, but if complex deployment and maintenance eats away from your Development, then is it worth it? That middle tier Server would be better served as another Load Balanced server on the Web Tier. Keep in mind also that network overhead is the slowest and most unreliable between tiers, whereas if you call in memory JARS or DLLS without crossing process boundaries, or remoting via network, then obviously processing and response time would be the fastest for high traffic scenarios.

However keep in mind its not a one size fits all to every solution. For certain functionality within the Application you may need Message Queues or Backend Services or Chron Services or Windows Services. Which may indeed be considered a Middle Tier or "another" tier outside of the Web Tier for other Business Services.

The best rule of thumb is to never over-complicate over-engineer what is necessary for the business. Simple works, complex fails.

There is a distinction between "Logical Architecture" and "Physical Architecture", you can have the same code base and yet deploy it on a Web Tier and Middle Tier, or just strictly on the Web Tier.

What you decide is based on a myriad of factors. If your Web Tier is merely a pass through to call more or less mirror services on the Middle Tier, then it would appear to me that the Middle Tier is pointless. Such an unnecessary physical architecture adds to Hardware Cost since most Enterprise level applications require redundant servers at all tiers. Also complicates Deployment and Maintenance. Keep the End Goal in mind, you can build the greatest App, but if complex deployment and maintenance eats away from your Development Time, then is it worth it? That middle tier Server would be better served as another Load Balanced server on the Web Tier. Also network latency overhead is the slowest and most unreliable between tiers, whereas if you call in memory JARS or DLLS without crossing process boundaries, or remoting via network, then obviously processing and response time would be the fastest for higher traffic scenarios.

However its not a one size fits all to every solution. For certain functionality within the Application you may need Message Queues or Backend Services or Chron Services or Windows Services. Such as for disconnected workflows, or long running intensive processing. Which may indeed be considered a Middle Tier or "another" tier outside of the Web Tier for other Business Services.

The best rule of thumb is to never over-complicate over-engineer what is necessary for the business. Simple works, complex fails.

Source Link

There is a distinction between "Logical Architecture" and "Physical Architecture", you can have the same code base and yet deploy it on a Web Tier and Middle Tier, or just strictly on the Web Tier.

What you decide is based on a myriad of factors. Keep in mind, if your Web Tier is merely a pass through to call more or less mirror services on the Middle Tier, then it would appear to me that the Middle Tier is pointless. Such an unnecessary physical architecture adds to Hardware Cost since most Enterprise level applications require redundandant servers at all tiers. Also complicates Deployment and Maintenance, keep in the End Goal in mind, you can build the greatest App, but if complex deployment and maintenance eats away from your Development, then is it worth it? That middle tier Server would be better served as another Load Balanced server on the Web Tier. Keep in mind also that network overhead is the slowest and most unreliable between tiers, whereas if you call in memory JARS or DLLS without crossing process boundaries, or remoting via network, then obviously processing and response time would be the fastest for high traffic scenarios.

However keep in mind its not a one size fits all to every solution. For certain functionality within the Application you may need Message Queues or Backend Services or Chron Services or Windows Services. Which may indeed be considered a Middle Tier or "another" tier outside of the Web Tier for other Business Services.

The best rule of thumb is to never over-complicate over-engineer what is necessary for the business. Simple works, complex fails.