text: [导读]在SOA体系架构设计中，服务是最核心的抽象方法，业务可以划分成一系列粗粒度的服务和流程。而各组件化业务服务相对独立、自包含、可重用，由一个或者多个分布的系统来实现和组装。
  SOA是一种进行企业级系统开发的新的体系架构，在基于SOA体系架构的系统中，应用程序的具体功能是由一些松耦合和具有统一接口定义方式的组件(也就是webservice,xml)等组合而建立起来的。因此，基于SOA的架构体系也一定是从企业的具体需求开始构建的。但是，SOA和其它企业体系架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更做快速进行响应和处理,通过利用这种便利来提高竞争优势的能力。对企业级架构设计师来说，即创建一个灵活的业务体系架构意味着可以满足当前还不清晰的业务需求的IT架构。
  而在SOA体系架构设计中，服务是最核心的抽象方法，业务可以划分(组件化)成一系列粗粒度的服务和流程。而各组件化业务服务相对独立、自包含、可重用，由一个或者多个分布的系统来实现和组装。
  一个"服务"定义了一个与业务功能或业务数据相关的一组接口，以及约束这个接口的契约描述，如服务质量指标要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标(KeyPerformanceIndicator，KPI)等。契约描述和接口采用中立、基于标准的方式进行定义，它独立于编程语言、操作系统和硬件平台等来实现服务。这使得构建在不同操作系统中的业务服务可以以一种统一的和通用的方式进行交互、相互理解。除了这种不依赖于特定技术的服务特性，通过注册服务加上企业服务总线的方式来支持中介(Mediation)、定位、动态查询、路由和转发的能力，使得业务服务之间的交互是动态的，位置是透明的。
  技术和位置的透明性，使得服务的请求者和提供者之间能够构成一种松耦合。而这种松耦合平台的构成有两点好处：一点是它适应变化的灵活性;另一点是当某个业务服务的内部结构和实现方式逐步发生改变时，不影响其他服务。而紧耦合则是指应用程序之间的不同组件的接口与其功能和结构是紧密相连的，因而当每块发生变化时，而相关部分的也要随着各种紧耦合的关系进行部分甚至整个应用程序的调整，这样的体系架构就非常的脆弱了。
  SOA体系架构带来的主要观点是业务驱动IT，即业务驱动和业务更加紧密地联系在一起。以粗粒度的业务服务作为基础来对公司业务进行建模，这样就可以产生简洁的业务和系统视图;以业务服务为基础来实现的IT系统更灵活、更易于重用、也更快地应对企业业务需求的变化;以业务服务为基础，通过显式地方式来定义、描述、实现和管理业务层次的粗粒度服务(包括业务流程)，提供了业务服务模型和相关IT业务之间提供了更好的"可追溯性"，缩小了它们之间的差距，使得业务服务的变化更容易传递到IT。下面是个人对SOA的优点理解：
  业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。
  该特点是在于服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节。
  SOA体系架构将能够帮助我们的开发人员站在一个新的高度去理解企业级架构中的各种组件的开发与部署的实现，来帮助企业级架构的设计者们以更迅速、更可靠、更具重用性架构整个业务系统。较之以前，以SOA为架构的系统平台能够更加从容地面对新的业务的急剧变化。
  SOA其实并不是一种新架构，国际SOA架构组织在很多年前就已经成功地建立并实施SOA应用系统。大约2005年左右，大多数中国企业还不知道什么叫SOA，那时候本人就开始在自己单位项目中开始了SOA的初步尝试。到了2007年以后，很多企业开始从为什么要上SOA转变到如何上SOA时方向的思考，本人就尝试了一些基于SOA体系架构的项目应用，并还取得了一定意义上的市场效果。
  当时我设计的SOA项目的业务服务平台主要包括企业服务总线、企业门户、协同安全管理、业务流程管理、基础支撑平台等几个部分。其中，基础支撑平台是底层支持服务集，提供相关配置管理、服务管理水平、监控预警等系统级服务。
  业务流程管理：为实现提供了可视化的流程管理服务。
  1：传统的应用集成实现方式有点对点集成、企业消息总线或中间件的集成(EAI)、基于业务流程的集成。而这些集成有的都很复杂、昂贵，并且不灵活。而这些集成方式却都难于快速适应企业现代业务变化和不断产生的新的需求。基于面向服务架构的应用开发与集成可以非常容易地解决其中的许多复杂的问题。
  2：SOA定义了一整套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了一系列机制用于描述业务服务、通知及发现服务与服务进行通信。
  3：与传统的应用集成方法相比，SOA服务是围绕所有基于标准的技术模式来实现的。大部分的通信中间件系统，如DCE/RPC,CORBA,DCOM,MTS/COM+,JavaRMI,JavaEJB，也同样如此。可它们的实现过程都不是很完美的，在交互性和标准定制方面的可接受性是存在很大的问题。SOA体系架构试图排除这些缺陷。因为差不多所有的通信中间件系统都有固定的处理模式，如DCE/RPC的功能、CORBA的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象或者应用等等。这使得SOA体系架构可适应于任何现有系统，并使得这些系统在集成时不必刻意遵循其它任何特殊技术来单独定制。