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服务与面向服务原则)。
3.2. 比较SOA与客户-服务器架构
几乎在任何环境中，只要有一段软件从另一个请求或接收信息，都能够被称为“客户-服务器。”几乎每一个不同的应用架构都曾存在(包括 SOA)一种客户-服务器的交互元素。然而，行业术语“客户-服务器架构”通常是指特殊的前一代环境，期间客户端与服务器扮演了特定的角色，并有清晰的实现特征。
客户-服务器架构简史
初期庞大的主机授予组织严格的计算方式，通常被视作是客户-服务器架构稚形。这些环境，其中庞大的主机后端伺服瘦客户端，被看作单层客户-服务器架构(图2)。
图2. 一个典型的单层客户端服务器架构
主机系统天然支持同步及异步通信。后一种方法主要用于让服务器连续不断地接收来自终端的字符，以响应个别的击键事件。只在某种条件下服务器才会响应。
虽然它仍有残留痕迹，但是当两层客户-服务器的变化设计在80年代后期出现时，主机作为最初的统治计算平台开始衰退。
这个新方法引入了委派逻辑、以及处理职责下发到单个工作站的概念，导致了胖客户的诞生。受图形用户界面(GUI)创新的进一步支持，两层客户-服务器被认为是前进了一大步，并在90年早期持续统治了IT界数年之久。
这个架构的通常配置包含多个胖客户端，每一个都有自己到中心数据库服务器连接。客户端软件执行大量处理，包括所有的展现相关及多数的数据访问逻辑(图3)。一个或多个服务器通过累积可扩展的关系型数据库管理系统，促进了这些客户端。
图3. 典型的两层客户-服务器架构
让我们通过单独地和将它们与SOA的相应部分作比较两种方式，来看一看两层客户-服务器架构的主要特征。
应用逻辑
客户-服务器环境将大多数应用逻辑放到客户端软件中。这导致庞大的程序连同后端资源来一起来控制用户体验。分布式业务规则是一个例外。一个流行趋势是将嵌入的和维护的业务规则与数据关联，放入数据库的存储过程与触发器之内。这略微抽象了一组来自客户端的业务逻辑，并简化了数据访问编程。尽管如此，客户端还是承担着所有的展示任务。
当代面向服务解决方案中的展现层会有所不同。任何软件片段若有能力依照所需的服务契约进行SOAP消息交换，都可归为服务请求者。同时通常也期望请求者能提供服务，展现层的设计完全开放并对应特定的解决方案需求。
在服务器环境内，存在关于应用逻辑如何驻留与分布的选择权。这些选择权不排除数据库触发器和存储过程。同时，面向服务设计的原则开始起作用，通常指导划分自治处理逻辑的单元。这促进了特定设计品质，比如服务无状态化及协同性，还有可组合性及复用性。
另外，常有这些处理逻辑单元在SOA内不属于任何解决方案的情形。这也支持了促进复用以及跨越应用边界的松散耦合这一终极目标。
文章来源于领测软件测试网 https://www.ltesting.net/
