管理
客户-服务器时代终结的一个重要原因在于相关分发的大量维护成本的增加,以及跨工作站应用逻辑的维护。因为每一个客户装载有应用代码,每一次应用更新都要对所有的工作站重新分发软件。在较大型的环境中,这造成了高度繁重的管理流程。
维护问题跨越了用户端和服务器端。客户工作站受特定环境问题的支配,因为不同的工作站会安装不同的软件程序,或者可能购买不同的硬件厂商。更有甚者,还增加了对服务器端数据库的要求,特别是当客户-服务器应用拓展到更大的用户基础时。
因为面向服务的解决方案会有不同的请求者,它们还要受到来自客户端维护的挑战。同时其分布式后端要适应应用及数据库服务器的扩展性,会引入新的管理需求。例如,一旦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的比较中讨论的问题。
文章来源于领测软件测试网 https://www.ltesting.net/