＋设为首页 ＋添加到收藏夹
two tier vs n-tier
client/server applications, and even java applications that call a database directly, represent the original, two-tiered application architecture. this architecture fits many needs, but often there is a penalty - the need to redevelop or copy code from one application to another as it is developed. more importantly, although java is certainly a significant language for development, its a recently developed one, and much of the logic that we need to use is written in other languages. distributed applications, be they web applets or standalone applications, also have a need to centralize logic, both to minimize the maintenance of the client, and to keep download time and response times reasonable.
most of these issues have existed for years now, and the concept of externalizing and centralizing business logic from application logic developed into what is usually called a three-tiered or n-tiered architecture. cics was arguably one of the first middle-tier solutions developed. tuxedo from bea has been available for many years as well. the concept is simple - remove common business logic from application code and place it in a central repository, where any application might call it. and one of the first things this middle-tier became charged with was handling transaction management. a transaction is a set of one or more database statements that must be treated as a unit of work. simpler applications have no real need of transaction management, but applications that access multiple databases on different machines, perhaps in different locations, have a strong need for transaction management. this provides answers to the problem of two-phased commit, and o... 下一页