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.
