在上文中，我介绍了Internet技术，WEB服务在家够方面给了我们更多的选择，但软件设计中采用何种架构仍然是件令人头痛的事情。
两层系统（图12）允许用户界面和应用程序代码直接访问数据库和网络存储的API。应用程序使用数据库中存储的数据模型，但是不需要在该模型之上建立逻辑模型。当开发中的系统是一个原型系统或者已经知道其生命周期较短，期间API不会发生变化的时候，两层应用程序是理想的。典型情形下，这种方式用于小型的应用程序，它们的开发成本和时间都很少。
图12.两层架构
此外，两层系统对于面向组件的开发环境也有意义，这种方式用在特定组件的实现之中。组件接口提供了一个隔离层，与这种方式的后果相反。使用脚本语言建立的多数应用程序都属于这一类，因为这种情况下多架构层的开发可能非常麻烦，不切实际。
最后，两层的方式将提供更好的性能，并减少控制资源锁定的机制的需求。尽管两层模型在处理多个并发用户使用应用程序方面的能力有些欠缺，但是它的简单性可能远远优于其它的选择。此外，通过向数据库应用程序添加通用的数据处理程序，常常能用数据存储过程来消除一些简单的共享数据的问题。
随着数据库的发展，三层（Three-tier）应用程序已经很普通了。三层系统（图13）满足了执行的隔离的需求。它基本上对于存储/数据库层可能被修改的任何应用系统都是理想的。但是，这种技术的隔离并不仅限于数据库。它能够，并且应该用在任何不要求应用程序开发者，或更重要的应用程序维护人员对于最低层有详细的了解就能共享代码的环境。
图13.三层架构
相当频繁的重复使用是一个主要的设计考虑因素，在这种情形下需要建立应用程序模型以允许它的一部分被多个用户界面查看组件重复使用。它有一个指导方针是，在应用程序需要相同数据的多个视图的任何时候，开发者应该考虑使用三层方式代替两层方式。
从两层模型迁移到三层模型需要考虑的主要问题包括适当的网络资源的可用性和管理并发数据访问的加锁方案。
作为越来越强调网络计算的结果，最近出现了一种新的趋势，就是四层系统（图14）。当应用程序层需要支持高级行为的时候，可以考虑四层系统。四层模型与三层模型相似，但是其应用程序层被分解为表现层和对话层。表现层呈现了应用程序模型的视图部分，以及被特定视图的操作所约束的应用程序逻辑。对话层处理表现组件之间的资源共享的问题，包括与潜在的分布式业务对象模型通讯。
当表现组件之间需要大量的协调，并且需要在它们之间共享很多资源的时候就需要四层开发方式。例如，由于性能问题的缘故，缓冲是必要的。对话层允许很多不同的表现组件利用缓冲提供的性能优势。 同样，如果某个客户端被迫作出多个、潜在的复杂的分布式结论，就可以考虑把这种逻辑封装到应用程序的一个对话层中。
很多因素表明考虑四层开发方式的需求为数众多。很明显，任何四层系统预期的生命周期很长。已有的组件和子系统的重复使用对于引发与四层系统相关的费用来说通常都是足够充分的理由。同样，预计个别组件会频繁改变设计的目标的环境需要把系统的主要部分与组件实现中的变化隔离开来。四层方式提供了对随技术的发展（包括传统的和新的技术）组件和子系统不断地移植的支持。此外，四层系统比三层系统更容易升级。
其它一些考虑因素包括组件的可靠性是未知的或可变的系统。在间歇性的组件失败中，四层系统可以轻易地合并运行时发现机制（runtime discovery mechanisms）以切换到不同的组件实现上。有四个或多个层次的很多复杂系统最少提供了发现新能力（例如，涉及到新的Web服务实现时，它们就实现了UDDI记录）的一些能力。如果环境利用了多个、潜在地冲突的技术，四层系统提供了用于管理对话管理层（session management layer）或业务域对象层中的差异的机制。同样，如果客户端有多种不同的应用模型，而这些模型都需要共享共同的数据资源，那么四层模型也可能是理想的。经常地，在其它的应用程序组件不希望阻塞并等待资源，不得不在对话层中管理客户端的访问的环境中，应用程序组件允许业务域组件处理资源管理的问题并能够经受得住等待大多数资源。
对等（peer-to-peer，P2P）架构方式对于多数需要高度可升级的系统是理想的。同样，当分布式组件需要协调完成某种事务并且通讯以及其它组件的可靠性可能变化的时候，它们也是有用的。在开发P2P系统的时候操作环境很容易被理解是非常重要的，因为不好的习惯可能导致重大的灾难。同样，当使用P2P技术的时候，接口的标准化和不允许修改也是很重要的。被迫应付多个P2P网络的不兼容的版本简直是个梦魇。
N层和/或这些方式的组合（图15）应该仅仅用于十分复杂的、由多个软件生命周期不同的子系统和组件构成的系统。这对于大多数大型的不同种类的企业系统是真实的，在这种情况下，在任何时候组件都在升级、更换或添加。对于这种系统，考虑的事项必须通知系统组件的管理部门。
图15.N层和对等架构的组合
哪些特性值得使用复杂的N层系统呢？通常，它包括管理用于增强用户体验的大量数据的系统。其需求可能包括记载了用户的概要信息、允许用户设置参数控制Web页面和应用程序、管理复杂的安全需求（例如用于控制资源的访问控制列表）、允许用户要求后端应用程序中的存储管理和规则执行的进行改变等一些Web站点和应用程序。
有了N层应用程序，应用程序的功能被分解为大量的逻辑层，它们可以分开维护和配置。每个层次的功能没有三层应用程序那么标准，并且经常把很多层合并成一组来提供表现、应用和/或业务逻辑和存储管理功能。支持多个层次的主要优点是更容易修改某个层次而不需要改变很多层次（在大多数情形中不需要改变其它任何层次）。此外，通过变更一个或多个层次的分布或载入，应用程序能够被扩大为处理大量的用户负载和/或数据。通常这种缩放对于其它层次是透明的，在很多情况下还是自动的。实际上，多层架构被设想为跨多个计算机和处理器分布程序，而不是在某个应用程序中定义软件的边界。
两层系统（图12）允许用户界面和应用程序代码直接访问数据库和网络存储的API。应用程序使用数据库中存储的数据模型，但是不需要在该模型之上建立逻辑模型。当开发中的系统是一个原型系统或者已经知道其生命周期较短，期间API不会发生变化的时候，两层应用程序是理想的。典型情形下，这种方式用于小型的应用程序，它们的开发成本和时间都很少。
此外，两层系统对于面向组件的开发环境也有意义，这种方式用在特定组件的实现之中。组件接口提供了一个隔离层，与这种方式的后果相反。使用脚本语言建立的多数应用程序都属于这一类，因为这种情况下多架构层的开发可能非常麻烦，不切实际。
最后，两层的方式将提供更好的性能，并减少控制资源锁定的机制的需求。尽管两层模型在处理多个并发用户使用应用程序方面的能力有些欠缺，但是它的简单性可能远远优于其它的选择。此外，通过向数据库应用程序添加通用的数据处理程序，常常能用数据存储过程来消除一些简单的共享数据的问题。
随着数据库的发展，三层（Three-tier）应用程序已经很普通了。三层系统（图13）满足了执行的隔离的需求。它基本上对于存储/数据库层可能被修改的任何应用系统都是理想的。但是，这种技术的隔离并不仅限于数据库。它能够，并且应该用在任何不要求应用程序开发者，或更重要的应用程序维护人员对于最低层有详细的了解就能共享代码的环境。
相当频繁的重复使用是一个主要的设计考虑因素，在这种情形下需要建立应用程序模型以允许它的一部分被多个用户界面查看组件重复使用。它有一个指导方针是，在应用程序需要相同数据的多个视图的任何时候，开发者应该考虑使用三层方式代替两层方式。
从两层模型迁移到三层模型需要考虑的主要问题包括适当的网络资源的可用性和管理并发数据访问的加锁方案。
作为越来越强调网络计算的结果，最近出现了一种新的趋势，就是四层系统（图14）。当应用程序层需要支持高级行为的时候，可以考虑四层系统。四层模型与三层模型相似，但是其应用程序层被分解为表现层和对话层。表现层呈现了应用程序模型的视图部分，以及被特定视图的操作所约束的应用程序逻辑。对话层处理表现组件之间的资源共享的问题，包括与潜在的分布式业务对象模型通讯。
当表现组件之间需要大量的协调，并且需要在它们之间共享很多资源的时候就需要四层开发方式。例如，由于性能问题的缘故，缓冲是必要的。对话层允许很多不同的表现组件利用缓冲提供的性能优势。 同样，如果某个客户端被迫作出多个、潜在的复杂的分布式结论，就可以考虑把这种逻辑封装到应用程序的一个对话层中。
很多因素表明考虑四层开发方式的需求为数众多。很明显，任何四层系统预期的生命周期很长。已有的组件和子系统的重复使用对于引发与四层系统相关的费用来说通常都是足够充分的理由。同样，预计个别组件会频繁改变设计的目标的环境需要把系统的主要部分与组件实现中的变化隔离开来。四层方式提供了对随技术的发展（包括传统的和新的技术）组件和子系统不断地移植的支持。此外，四层系统比三层系统更容易升级。
其它一些考虑因素包括组件的可靠性是未知的或可变的系统。在间歇性的组件失败中，四层系统可以轻易地合并运行时发现机制（runtime discovery mechanisms）以切换到不同的组件实现上。有四个或多个层次的很多复杂系统最少提供了发现新能力（例如，涉及到新的Web服务实现时，它们就实现了UDDI记录）的一些能力。如果环境利用了多个、潜在地冲突的技术，四层系统提供了用于管理对话管理层（session management layer）或业务域对象层中的差异的机制。同样，如果客户端有多种不同的应用模型，而这些模型都需要共享共同的数据资源，那么四层模型也可能是理想的。经常地，在其它的应用程序组件不希望阻塞并等待资源，不得不在对话层中管理客户端的访问的环境中，应用程序组件允许业务域组件处理资源管理的问题并能够经受得住等待大多数资源。
对等（peer-to-peer，P2P）架构方式对于多数需要高度可升级的系统是理想的。同样，当分布式组件需要协调完成某种事务并且通讯以及其它组件的可靠性可能变化的时候，它们也是有用的。在开发P2P系统的时候操作环境很容易被理解是非常重要的，因为不好的习惯可能导致重大的灾难。同样，当使用P2P技术的时候，接口的标准化和不允许修改也是很重要的。被迫应付多个P2P网络的不兼容的版本简直是个梦魇。
N层和/或这些方式的组合（图15）应该仅仅用于十分复杂的、由多个软件生命周期不同的子系统和组件构成的系统。这对于大多数大型的不同种类的企业系统是真实的，在这种情况下，在任何时候组件都在升级、更换或添加。对于这种系统，考虑的事项必须通知系统组件的管理部门。
哪些特性值得使用复杂的N层系统呢？通常，它包括管理用于增强用户体验的大量数据的系统。其需求可能包括记载了用户的概要信息、允许用户设置参数控制Web页面和应用程序、管理复杂的安全需求（例如用于控制资源的访问控制列表）、允许用户要求后端应用程序中的存储管理和规则执行的进行改变等一些Web站点和应用程序。
有了N层应用程序，应用程序的功能被分解为大量的逻辑层，它们可以分开维护和配置。每个层次的功能没有三层应用程序那么标准，并且经常把很多层合并成一组来提供表现、应用和/或业务逻辑和存储管理功能。支持多个层次的主要优点是更容易修改某个层次而不需要改变很多层次（在大多数情形中不需要改变其它任何层次）。此外，通过变更一个或多个层次的分布或载入，应用程序能够被扩大为处理大量的用户负载和/或数据。通常这种缩放对于其它层次是透明的，在很多情况下还是自动的。实际上，多层架构被设想为跨多个计算机和处理器分布程序，而不是在某个应用程序中定义软件的边界。
