应用处理

因为大部分客户-服务器应用逻辑驻留于客户端，客户端工作站负责了大量的处理。80/20比率常被作为一个经验法则，按此法则数据库服务器承担了20%的工作量。尽管如此，数据还是常常成为这些环境中的性能瓶颈。

有大用户量的两层客户-服务器解决方案，通常需要每一客户建立其自身的数据库连接。通信可预期是异步的，而且这些连接是永久的(意味着它们需要通过用户登录并保持活动直至其退出应用)。专有数据库连接是昂贵的，并且资源需求经常压垮数据库服务器，给所有用户以可观的反应时间。

另外，假定客户被分配以主要的处理职责，他们常要求重要的资源。客户端执行完全是有状态的，并要消耗大量的固定PC内存。用户工作站因此经常需要专门运行客户端程序，以便所有可用资源能够提供给应用。

SOA中的处理是高度分布式的，每一服务都有一个清晰的功能边界和相关的资源需求。在面向服务架构建模技术中，对于如何能够定位及部署服务你有很多的选择。

企业解决方案包含多个服务器时，每一个都装有Web服务并支持中间件。因此，对于SOA而言没有固定的比率。服务可根据需要分布，而且在决定物理部署配置时，性能需求是要考虑的因素之一。

服务与请求者间的通信可以是同步的或是异步的。这一灵活性允许进一步改进处理，特别是使用异步的消息模式时。另外，通过在消息中放入更多的智能，可获得消息层面的语境管理选择。这促进了无状态的及自治的服务本性，并进一步经历减少对状态信息缓存的需要。

技术

客户-服务器应用的出现促进了第四代4GL编程语言的使用，比如Visual Basic与PowerBuilder。这些开发环境充分利用了Windows操作系统所提供的能力，来创建更美观丰富、更具交互性的用户界面。尽管如此，传统的第三代语言，比如C++，仍在使用，特别是对于有更严格的性能需求的解决方案。在后端，主流的数据库厂商，象Oracle、Informix、IBM、Sybase与微软，提供了强健的关系型数据库管理系统，能够管理多连接，同时提供了灵活的数据存储及数据管理特性。

SOA所用的技术集实际上并不象它所延展的那么多。旧版本的程序语言的更新版本，象Visual Basic，依旧能够用于创建Web服务，且依旧可以使用传统数据库。尽管如此，SOA的技术版图已经变得日渐不同。除了Web技术的标准集(HTML、CSS、HTTP等等)，当代SOA一并带来了建立XML数据表达架构的绝对需求，还有SOAP通讯框架，以及服务架构所包含的永远扩展的Web服务平台。

安全

除了数据的存储与管理以及嵌入存储过程和触发器中的业务规则，安全是经常在客户-服务器架构的服务器层面集中处理的另一个部分。数据库十分复杂，足以管理用户帐户及用户组长，并将其分配到物理数据模型的个别部分。

安全也能够客户程序中控制，特别是当它与特定应用逻辑执行的业务规则相关联时(譬如挑选用户对部分用户界面进行限制访问)。另外，与操作系统级的安全协作可实现单点登录，此时应用直接继承操作系统的登录账户信息。

尽管有人夸耀SOA的优势，许多架构师却羡慕客户-服务器的安全性。企业数据经由单点鉴权而受到保护，建立了客户端与服务器间的单一连接。在SOA的分布世界中，这是不可能的。安全变成一个重要而复杂的问题，与必需的安全措施程度直接相关。牵扯到许多典型技术，大多数包含在WS-安全框架中。

管理

客户-服务器时代终结的一个重要原因在于相关分发的大量维护成本的增加，以及跨工作站应用逻辑的维护。因为每一个客户装载有应用代码，每一次应用更新都要对所有的工作站重新分发软件。在较大型的环境中，这造成了高度繁重的管理流程。

维护问题跨越了用户端和服务器端。客户工作站受特定环境问题的支配，因为不同的工作站会安装不同的软件程序，或者可能购买不同的硬件厂商。更有甚者，还增加了对服务器端数据库的要求，特别是当客户-服务器应用拓展到更大的用户基础时。

因为面向服务的解决方案会有不同的请求者，它们还要受到来自客户端维护的挑战。同时其分布式后端要适应应用及数据库服务器的扩展性，会引入新的管理需求。例如，一旦SOA发展为服务复用并成为多服务组合的一部分，服务器资源与服务接口的管理会需要强大的管理工具，包括私用注册的使用。

3.3. 比较SOA与分布式互联网架构

这似乎有点自相矛盾，如果SOA可被视作分布式互联网架构的一种形式，同时我们初期建立早先类型的分布式架构也可被设计为SOA。尽管如此，且尽管现在的分布式环境可能已经深深地受到了面向服务原则的影响，SOA这样的变化仍旧是罕见的。故而在此所提供的比较是将传统的分布式互联网架构作为其最常被设计的风格出现。

分布式互联网架构简史

为了对付两层客户服务器架构相关的成本与限制问题，构建基于构件应用的概念成为主流。多层客户-服务器架构浮出水面，将单独的客户程序分解成构件设计，成为符合面向对象的不同扩展。

在构件中不同的分布式应用逻辑(一些仍驻留在客户端，其他在服务器上)，减少了大量逻辑都集中部署在服务器端的令人头痛的问题。服务器端构件，现在集中于应用服务器，从而可共享数据库连接管理池，减轻数据库并发访问的负担(图4)。一个单连接就可轻易满足多用户要求。

　 图4. 典型的多层客户-服务器架构。

获取这些效益的代价是复杂性的增加，并且最终转换为从部署问题到开发和管理过程的费用和努力。构建多样化处理能力的构件，并发请求比直接为单个用户开发一个可执行程序更困难，而且问题多多。

另外，替代客户-服务器数据库连接的是客户-服务器远程程序调用(RPC)连接。象CORBA与DCOM这样的RPC技术，准许客户工作站与服务器构件间进行远程通信。出现了类似客户-服务器架构的问题，包括资源及永久连接。增加这个新的维护是由于引入了中间件层。比如，在大型环境中对于应用服务器及事务监控需要特别关注。

随着万维网在90年代中后期成为一个计算技术的可用媒介，多层客户-服务器环境开始组成互联网技术。最重要的成就是软件构件被浏览器所替代。这个变化不仅从根本上改变(且限制)了用户界面设计，实际上还把100%的应用逻辑移到了服务器端 (图5)。

图5. 典型的分布式互联网架构

分布式互联网架构也引入了一个新的物理层，Web服务器。这导致HTTP替代了专有的RPC协议而用于工作站与服务器间的通信。RPC的角色被限制到促成远程Web与应用服务器间的通信。

从90年代后期2000年中期，分布式互联网架构对于定制开发的企业解决方案而言，代表了事实上的计算平台。基于构件的日常编程技术及日益复杂的中间件，最终减少了一些整体复杂性。

那么，这个熟悉而又相似的架构该如何与SOA相比较呢?且看分布式互联网架构与SOA特征部分。

注意：

尽管多层客户-服务器在其所有权内是一个独特的架构，我们不提供它与SOA之间的比较。大多数在客户-服务器及分布式互联网架构的比较中升级的问题，掩盖了将在多层客户-服务器与SOA的比较中讨论的问题。