Traditionally, web application has a two-layer architecture.

• Presentation Layer. This layer could be taken as a mixture of the browser plus web sever. Here I only focus on server side, so this is the web server, the layer that talks to your browser.
• Data Access Layer. This layer accesses database. It is a collection of DCO's (Data Container Object) and DAO's (Data Access Object). It gets DCO from Presentation Layer, and insert/update database thru DAO's, or queries database, form DCO and send to Presentatin Layer.

Today more and more companies are turning their enterprise systems into web applications, and this kind of web application is usually more complex than traditional web application such as online shopping etc., as the business logics it represents are much more complex.

In my recent redesign of the supply chain system of my company, a group of people including myself, realized the need of adding a middle layer, which we called Proxy Layer in between Presentation Layer and Data Access Layer.

We used the Proxy Layer for:

• Security. Now Presentation Layer no longer forms DCO's directly. Instead the Proxy Layer checks various attributes of user input, determines level of data access and authorization, and reformats user input into DCO's.
• Load Balancing. For enterprise application, databases, database schemas and database tables are usually shared by multiple applications, for the purpose of "keep one version of the truth". Our database is shared by supply chain, merchandising, finance blah blah... Proxy layer controls the number of instances of each application (sub system) that is allowed to access database at a given time. By doing this, critical pathes of our system rarely being pushed back from timely execution due to resource issues.
• Further hiding database structure from browser. Now your web server no longer needs to know the physical database design of your system. Instead it only knows Business Data Entities. Business Data Entity groups data in a view makes sense to business users, but does not care technical terms like normalization etc. Another benefit we gain is, in the future, if we have to redesign our database, the chance we have to modify our front-end gets largely reduced, thus code is more reusable.
• Business Logic. This is the most logical place to handle complex business logics, and allows multiple user to work together to get the business processes done. Also business logics only talk thru business data entity, not databse tables, rows, columns. This makes it possible to analyze and describe business data in a more clear way.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.