I am developing a complex web application and a fellow developer on the project has proposed the following architecture. I am wondering if any one has developed a CF app in this way and if any one has any interesting suggestions on how to include this type of tiered/segmented approach to application development. The details are below. <!---- suggested architecture ---> Tier 1) Have a lot of less powerful front-end boxes running the web servers and pushing the presentation materials back to the users. Because the number of users is high, you need a lot of boxes to handle all of the concurrent connections (open sockets) and track the user's session. These front end presentation web logic should then gather the information, such as extracting out the fields from the HTTP request, and call on a service to handle the request. This tier then takes the response back from the second tier and formats it appropriately for a web user (XML+XSL, HTML, voice response unit, WML/WAP, etc.). Tier 2) Have fewer, but bigger, highly scalable, clustered, fault tolerant service providing computers contain the main business logic. There is often a good reason to split this "tier" into two parts: a) a set of services that are tightly coupled with the front-end that can aggregate information across multiple web pages, for example, before handing off to the "generic" service that contains the main business logic. Some people (me included), will include this part in the first tier, though. b) the generic business services that no nothing about web pages. Tier 3) Put the database server in another tier. This is where databases like DB2 and Oracle tend to shine because they can have huge tables spread across multiple machines (physical partitioning). I'm not sure if SQL Server can do this or not. In practice this means that a request is sent from a user (browser, pda, phone, fedex back-end system) to the first tier that understands how to communicate with the device/system the user is on. It then extracts the important information included in the request and passes it to the second tier that is generally ignorant of the method used by the user. It performs the business logic, updates the database in tier 3 as needed, and returns the results back to the tier 1. Tier 1 then examines the response and formats an appropriate reply back to the user. This is a generic three tier architecture for the web. When tier 1 is mixed with tier 2, or tier 1 goes straight to tier 3, you end up with many problems architecturally, mostly to do with scalability and maintainability, though great for RAD. While fast up front, this is short-sighted and doesn't buy you enough benefit. You don't want business logic spread out over too many areas; presentation programmers have a different set of skills required than the services people -- since programming for a web, pda, cell/voice response, work engine, third-party application, etc. are all different. Database control is complicated by having access to it from too many places, including updates when schemas change and issues related to the number of concurrent db connections, security of the servers, etc. The database schemas often change because of performance reasons (tables are normalized or denormalized or partitioned, etc. to handle loads and volumes), and you don't want more than business logic to have to deal with it. If too many programs have their fingers directly in the db, then they all have to be updated to be correct. That's a recipe for a nightmare as a system grows. Lastly, if someone hacks into a web server (the device they see and must be accessible through the firewall), you don't want that box to know about database passwords, etc. since it will be used to hack into the rest of the system. ------------------------------------------------------------------------------ Archives: http://www.eGroups.com/list/cf-talk To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
