3.
SOA
的根源
(SOA
与过去架构的比较
)
我们现在实际地跳回时间轴看一看过去架构与
SOA
的差别。这是一项有趣的研究，
我们能够看出
SOA
许多当代特征的起源。
3.1.
什么是架构？
自打有计算机处理的自动化解决方案方案起，技术架构就已存在。然而，在较老的环境中，解决方案直接建构于抽象的任务上，并规定其架构很少被执行。
随着多层应用的崛起，应用交付的变异开始剧增。
IT
部门开始认识到需要定义标准化的基线应用，作为其他应用的模板。这个定义自然是抽象的，但明确地解释了所有解决方案以这个模板为基础，包括其技术、边界、规则、限制及设计特征。这就产生了应用架构。
应用架构
应用架构对于应用开发团队的意义，相当于蓝图对于建筑工团队的意义。不同的组织印证不同水平的应用架构。一些保持了高水平，提供技术蓝图的抽象的物理及逻辑表达。另一些则包括更多的细节，类似通用数据模型，通信流程图，应用范围的安全需求，以及基础设施方面。
对于一个组织而言有几个不同的应用架构的情况是不希奇的。一个架构文档典型地代表了不同的解决方案环境。例如，一个同时拥有
.NET
与
J2EE
解决方案的组织很有可能针对每一种有分别的应用架构规范。
任何应用级架构的关键部分在于它既要直接反映解决方案的需求，同样又要考虑长期的、策略性的
IT
目标。正由于这个缘故，组织内的应用架构会伴以企业架构，并与其中居统治地位的一个保持一致。
企业架构
在较大的
IT
环境，关键在于需要控制并指导
IT
基础设施。当有很多不同的应用架构共同存在的时候，且有时甚至要整合，底层的主机平台变会复杂而繁重。因此，通常会创建一个控制规范，为企业内存在的所有异质形态的提供高层概述，同时给出支持基础设施的定义。
继续我们前一个类推，对于组织而言，企业架构规范相当于一个城市的城市规划。因此，城市规划与建筑蓝图间的关系，可与企业与应用架构规范间的关系相类比。
典型地，企业架构的变化直接影响应用架构，这是为什么架构规范通常由同一组人来维护。而且，企业架构经常包含组织长期技术和环境发展规划。例如，阶段性的目标有可能是要立足于这个规范来逐步淘汰过时的技术平台。
最后，也可能会定义技术与策略背后的企业级安全度量。然而，这经常会被作为单独的安全架构规范。
面向服务架构
简单而言，面向服务架构跨越了企业与应用架构两个领域。当被用于跨多解决方案的环境时，
SOA
所提供的潜在效益才能真正释放。这个是对可复用和可协同服务的投资，并且充分利用基于厂商中立的通信平台。这并不意味着企业必须变成面向服务。
SOA
所引入的特性及特征大部分都属于这一范畴。
注意术语“
SOA
”并不意味着一个特殊的架构范围。
SOA
可以是指一个应用架构，或是用于跨企业的技术架构的标准化方法。因为
SOA
天生的可组合性（意味着单个的应用层架构可由不同的扩展及技术组成），完全适用于超越
SOA
的组织。
请注意，如同前一章所解释的，
Web
服务平台提供了众多实现
SOA
形式中的一个。它是本书专门研究的一种方法，但是还存在其他方法，比如由传统的分布式平台所提供的这些。术语方面有一点很重要，就是在后面章节中及整本书中所用的术语“
SOA
”是指在第
3章
所建立的当代
SOA
模型（基于
Web
服务与面向服务原则）。
几乎在任何环境中，只要有一段软件从另一个请求或接收信息，都能够被称为“客户
-
服务器。”几乎每一个不同的应用架构都曾存在（包括
SOA
）一种客户
-
服务器的交互元素。然而，行业术语“客户
-
服务器架构”通常是指特殊的前一代环境，期间客户端与服务器扮演了特定的角色，并有清晰的实现特征。
客户
-
服务器架构简史
初期庞大的主机授予组织严格的计算方式，通常被视作是客户
-
服务器架构稚形。这些环境，其中庞大的主机后端伺服瘦客户端，被看作单层客户
-
服务器架构（
图
2
）。
图
2.
一
个典型的单层客户端服务器架构
主机系统天然支持同步及异步通信。后一种方法主要用于让服务器连续不断地接收来自终端的字符，以响应个别的击键事件。只在某种条件下服务器才会响应。
虽然它仍有残留痕迹，但是当两层客户
-
服务器的变化设计在
80
年代后期出现时，主机作为最初的统治计算平台开始衰退。
这个新方法引入了委派逻辑、以及处理职责下发到单个工作站的概念，导致了胖客户的诞生。受图形用户界面（
GUI
）创新的进一步支持，两层客户
-
服务器被认为是前进了一大步，并在
90
年早期持续统治了
IT
界数年之久。
这个架构的通常配置包含多个胖客户端，每一个都有自己到中心数据库服务器连接。客户端软件执行大量处理，包括所有的展现相关及多数的数据访问逻辑（
图
3
）。一个或多个服务器通过累积可扩展的关系型数据库管理系统，促进了这些客户端。
图
3.
典型的两层客户
-
服务器架构
让我们通过单独地和将它们与
SOA
的相应部分作比较两种方式，来看一看两层客户
-
服务器架构的主要特征。
应用逻辑
客户
-
服务器环境将大多数应用逻辑放到客户端软件中。这导致庞大的程序连同后端资源来一起来控制用户体验。分布式业务规则是一个例外。一个流行趋势是将嵌入的和维护的业务规则与数据关联，放入数据库的存储过程与触发器之内。这略微抽象了一组来自客户端的业务逻辑，并简化了数据访问编程。尽管如此，客户端还是承担着所有的展示任务。
当代面向服务解决方案中的展现层会有所不同。任何软件片段若有能力依照所需的服务契约进行
SOA
P
消息交换，都可归为服务请求者。同时通常也期望请求者能提供服务，展现层的设计完全开放并对应特定的解决方案需求。
在服务器环境内，存在关于应用逻辑如何驻留与分布的选择权。这些选择权不排除数据库触发器和存储过程。同时，面向服务设计的原则开始起作用，通常指导划分自治处理逻辑的单元。这促进了特定设计品质，比如服务无状态化及协同性，还有可组合性及复用性。
另外，常有这些处理逻辑单元在
SOA
内不属于任何解决方案的情形。这也支持了促进复用以及跨越应用边界的松散耦合这一终极目标。
应用处理
因为大部分客户
-
服务器应用逻辑驻留于客户端，客户端工作站负责了大量的处理。
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
数据表达架构的绝对需求，还有
SOA
P
通讯框架，以及服务架构所包含的永远扩展的
Web
服务平台。
安全
除了数据的存储与管理以及嵌入存储过程和触发器中的业务规则，安全是经常在客户
-
服务器架构的服务器层面集中处理的另一个部分。数据库十分复杂，足以管理用户帐户及用户组长，并将其分配到物理数据模型的个别部分。
安全也能够客户程序中控制，特别是当它与特定应用逻辑执行的业务规则相关联时（譬如挑选用户对部分用户界面进行限制访问）。另外，与操作系统级的安全协作可实现单点登录，此时应用直接继承操作系统的登录账户信息。
尽管有人夸耀
SOA
的优势，许多架构师却羡慕客户
-
服务器的安全性。企业数据经由单点鉴权而受到保护，建立了客户端与服务器间的单一连接。在
SOA
的分布世界中，这是不可能的。安全变成一个重要而复杂的问题，与必需的安全措施程度直接相关。牵扯到许多典型技术，大多数包含在
WS-
安全框架中
。
管理
客户
-
服务器时代终结的一个重要原因在于相关分发的大量维护成本的增加，以及跨工作站应用逻辑的维护。因为每一个客户装载有应用代码，每一次应用更新都要对所有的工作站重新分发软件。在较大型的环境中，这造成了高度繁重的管理流程。
维护问题跨越了用户端和服务器端。客户工作站受特定环境问题的支配，因为不同的工作站会安装不同的软件程序，或者可能购买不同的硬件厂商。更有甚者，还增加了对服务器端数据库的要求，特别是当客户
-
服务器应用拓展到更大的用户基础时。
因为面向服务的解决方案会有不同的请求者，它们还要受到来自客户端维护的挑战。同时其分布式后端要适应应用及数据库服务器的扩展性，会引入新的管理需求。例如，一旦
SOA
发展为服务复用并成为多服务组合的一部分，服务器资源与服务接口的管理会需要强大的管理工具，包括私用注册的使用。