从孙子兵法论SOA孙子兵法

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、 *** 作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/WebService技术之后的自然延伸。

SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

《孙子兵法》有：“上兵伐谋，其次伐交，其次伐兵，其下攻城”。演化到IT系统的建设，“伐谋”也首当其中，一种先进的理念、一个领先的平台直接关乎整个战局；良好的合作关系是项目成功的基础，企图单靠做客户关系，只能缓解一时，但却难以长久；如果选择在研发上投入大量人力、物力、财力进行平台的研发，则很可能会使公司在平台与项目投入之间面临进退两难的选择；企图通过大规模的人海战术常驻客户现场，那更是下下之策。

在当前阶段来看，关于SOA的实施，呼声比谁都高，雨点却比谁都小。究其原因主要有三：

第一，对SOA的理解存在较大的差异，SOA是面向服务的，服务的定义非常广泛，可以是一个功能模块、可以是某个业务、也可以是一个系统，所以直接导致项目实施缺乏明确一致的目标，客户更多的是希望从业务角度来解决问题，但实际的情况更多的是从纯技术的角度来出发的。

第二，来自传统IT部门的阻力，SOA的实施巅覆了现有的IT架构，使得原本IT的变革继而引发组织的变革、人员的变革和技术的变革，“人”的因素成为SOA的实施巨大的阻碍。

第三，业务竞争加剧，使得项目实施的周期越来越短。目前各厂商并不缺乏实施“SOA”的理论基础，但缺乏行之有效的开发平台与项目监管工具，导致无法有效控制项目周期，降低开发难度，控制项目成本。往往只是为了SOA而SOA，最后仅仅只解决了部分异构系统的整合与互联，却没有真正意义上体现出实施SOA之后带给客户所期望的价值。

了解了这些原因，再去探求解决的办法。对于前面两点大多是非技术因素所致，本文将从技术的层面来看待SOA的实施。

上：谋攻篇

SOA的实施对任何企业来说本身是一项具有战略高度和指导意义的事情，实施SOA的目的是实现以业务为核心，提高IT系统扩展的灵活性以及IT资产的复用，达到业务灵活组合的状态。

然而就当前IT的现状来看，企业往往存在大量的异构系统，为了保护现有的投资，于是有了EAI、BPM，有了ESB这样一些理念与技术，通过它来解决异构系统间整合与复用的问题。从客户角度来说，他们希望实施SOA后就可以使他们快速的应对市场的变化，但是当前的方式并不能很好的达到客户预期的效果，因为它没能从根本上解决客户关心的问题，业务的问题还是需要借助于业务系统来解决，而这恰恰就是关键问题所在!因此，仅仅靠解决异构系统的复用是远远不够的，所以才使得实施SOA后得到的结果和预期效果相差甚远!

ESB解决了“如何提供服务”、“如何提供灵活的框架”，但没能解决“如何定义服务”和“如何重组服务”的问题。

SOA服务的来源一般有两种：一种是对原有系统的支持，把它拆分重新封装成服务；第二种采用全新的平台去构造服务。那么有没有办法从本质上来解决SOA的面临的问题呢从SOA的面向角度来说分为：面向企业异构系统和面向企业内部业务系统两个方面，前者的角度称为Inter-SOA，后者称之为Intra-SOA。但目前实施SOA面临的主要问题就是Intra-SOA得不到有效的解决，当前业务系统的构建多是采用三层或多层的系统架构模型来解决的。也有不少企业将应用做了进一步的分离，建立了Framework的概念，将底层技术、通用业务模块独立出来，构建自己的业务平台，从而达到一种松耦合、可重用的业务环境。

从设计的思想上来说，我们的应用系统在十年前就具备了SOA的理念原型，很多开发商在项目实施的过程中也逐步提炼出通用的模块和底层的技术，从而形成了自己的业务开发平台，但在当时的环境下，Frame-work本身在早期设计时多数是出于项目考虑的，使得它的设计存在先天的缺陷。在随后功能完善的过程中，又逐步破坏了原有的系统结构从而失去了原有的d性。

现在系统越来越庞大、业务底层所关注的环节也越来越多，业务平台本身的易用性、可靠性、性能、以及平台的管理都面临巨大的挑战，因此现在业务平台维护升级就变得异常困难，使得开发商面临选择或放弃平台的艰难选择。

Framework灵活性的缺失直接导致业务平台失去灵活性，也无法快速响应业务的变化。事实上，很多企业当前并不缺乏Framework，但缺少真正具有商业价值的Framework。

IT系统的复杂程度对Frame-work提出了极高的要求：灵活性、易用性、高可靠性、可管理性，同时也要具有生产力，具有更高的商业价值!从客户的角度来说，它需要具备技术的前瞻性、领先性、平台的通用性及稳定性，以确保用户的投人至少5-10年内不被淘汰。

传统业务平台供应用商大多是在项目实施过程中逐步提炼出来的，很显然满足不了IT发展的要求，传统的IT系统更加不能适应这种变化；对开发商来说，Framework本身要具有极高的灵活性、能有效降低开发难度，快速交付业务，并能有效的缩短项目实施的周期，能减少整体项目的投入，使Frame-work更具备商业化的价值。

刘备三分天下，也非他一人之力所能为也。一个系统的架构是由若干部分所组成的，因此早期系统架构的设计、人员的分工就显得尤为重要，系统层次清晰的划分，使得项目面对业务需求“进可攻，退可守”，灵活度得到极大提高，即使开发人员的水平参差不齐，但也仍然能做到“形散神聚”。而这就要求我们的系统具备很好的灵活性、扩展性，能快速的交付业务需求，并且确保系统能高效稳定运行，而又不至于一套系统刚开发完，就可能面临技术淘汰的尴尬境地。

在一个大型的项目中，客户的需求不断的变化时，项目的风险系数就逐步增加了，为了适应客户的需求，业务模块不得不重新进行调整，而且很有可能因为客户的一个需求，我们需要改变众多的应用模块，甚至要改变底层的系统架构，从而使项目陷入窘境，因此架构的灵活性和前瞻性就显的非常必要!纵观目前市场上的SOA解决方案供应商众多，而且解决问题的角度也不相同，如果从解决Inter-SOA的角度出发，我们的选择非常多，但能从Inter-SOA和In-tra-SOA两个角度来解决问题的却寥寥可数。因此选择一个优秀的平台就是“上兵伐谋”实施SOA最重要的第一步。

中：作战篇

《孙子兵法》有：“兵贵胜，不贵久”。一个项目经历长时间的鏖战，必日久力衰。高质量、快速交付是确保SOA实施的重点。“工欲善其事，必先利其器”，因此选择一个好的作战平台，就能扬长避短，更有利于项目的快速交付。 目前从Inter-SOA的解决方案众多，大小异同，基本是采用ESB的理念，这里不再细述，本文关注业务领域的Intra-SOA解决方案如何来做到如何来实施才能确保项目的成功其所倡导的ProFrame是基于Intra-SOA的集成应用框架解决方案，如图2所示是ProFrame以银行业务为例的应用架构图，展示了ProFrame基于SOA的设计理念，以下我们以ProFrame为例来说明平台在项目实施中的作用。

ProFrame把应用划分成三个层次，业务规则服务层、公共服务层、框架服务层。业务位于最上层，对于通用业务模块位于公共服务层，而底层则是应用中面临的通用底层技术细节。

比如开发银行中一个转账的交易，以转账、存款取款三个服务模块为例。如图3展示了开发一个转账模块的开发过程，ProFrame提供了可视化的开发工具，对于业务逻辑的定义，以所见即所得的方式即可定义服务流，转账模块实际上是对应存款和取款两个模块的复用，因此ProFrame提供了EMB(Enterprise Module Bus)，以企业模块总线的方式来组织和管理业务模块，确保开发的业务具备高可重用性，而与数据库交互的部分则独立由DBIO来实现。

对于以上业务的开发我们并没有处理交易时日志的处理、交易失败时异常处理的机制、事务的回滚以或是批处理的控制等等，这些实际上都是我们在业务中必须需要考虑的事情，而且它与业务的关联性并不大，那么它是否可以独立出来，由平台来提供呢

这一切使得我们只需关注于具体业务的实现，不需要考虑业务以外的事情，并且提供了一个可视化的开发环境，因此开发难度和效率大大提高，为项目的快速实施提供了高保障，并且由所设计的业务模块的逻辑非常清晰，即使业务人员也能一目了然。这实际上是很多的开发商所追求的目标。

下：势篇

如果我们说中间件采用的B/S的模式解决了分布式应用中开发的问题，那么Framework则解放了开发商在应用底层技术细节的开发，使开发者不需关注技术本身，从而更加关注应用的实现。所有的技术的产生，终将是为应用服务的，因此，在早期的时候，有了JDBC，我们不需要去自已实现与数据库的驱动，有了Hibernate不需关注DataBase连接与处理的细节了，那么有了Framework我们也无需处理用于支撑业务运行的底层技术细节了。

当你看到一种新的技术感到抑制不住的兴奋、但同时又焦虑不安时，那意味着一个具有革命性、颠覆性的新时代即将来临。当我们回首中间件的发展历程时，不难发现，当传统的C/S结构向B/S结构转变时，人们的心情是什么样的当中间件诞生时，如果你接纳了他，那意味着，企业的核心平台框架要被彻底改变，传统的IT结构会做调整，企业的业务会发生变化，以前靠传统C/S模式进行开发的应用和集成商掌握的技术要彻底的更新，数以万计的企业、开发者都会被卷入到其中，上游的变化，必然会引起IT产业链中下游的变化，人们的担心和忧虑就可想而知了。

任何一个新旧事物的交替，任何一个新时代来临时，都会让你兴奋而又充满恐惧。传统的业务技术平台目前已到了一个分水岭，要么消亡，要么重生。替代、发展，新旧事物的更替，却是亘古不变的真理。而新的商业化Framework的崛起，将会成为实现Intra-SOA提供最佳的平台和孵化器，从而引领SOA新的潮流。

关于SOA的解决方案五花八门，但检验SOA的实施的标准却只有一个，那就是得到用户的认可。因此从根本上去理解SOA的内涵，并选择合理的平台，能同时从IT和业务两者的角度去解决企业所面临的问题，才是SOA实施的关键。

以上就是关于B/S架构 C/S架构 SOA架构 分别是什么呀全部的内容，包括:B/S架构 C/S架构 SOA架构 分别是什么呀、什么是SOA（面向服务的体系结构）、什么是SOA技术等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！