软件项目实训及课程设计指导——如何实现面向服务的系统架构设计
1、什么是基于SOA的软件系统架构
（1）什么是面向服务的软件系统体系架构
所谓的SOA（Service-OrientedArchitecture，面向服务的软件系统体系架构）其实就是一种新型的软件应用系统的系统体系架构设计形式，在基于SOA架构设计思想所开发实现的企业级软件应用系统中，软件应用系统中的各个业务功能的程序模块是由一些松散耦合并且具有统一接口定义的服务组件相互组合而构建的。
（2）面向服务的软件系统体系架构所体现出的主要特点
在这种架构体系下，它强制软件应用系统的设计人员应该以“服务”为中心，并要求把应用系统分为具有明确定义接口的各个功能模块，每个模块都可以提供独立的功能，不同场景下通过结合需要的模块来提供不同的服务。这样的软件应用系统的系统体系架构设计方案，不仅可以使得服务的提供方和服务的使用方相互分离和松散耦合，而且可以根据服务的使用方的应用要求调整所提供的功能服务。
正是由于服务的提供方和服务的使用方相互分离和松散耦合，并且各自可以采用完全不同的技术实现和运行在不同的系统平台之上，但彼此却能够相互访问和通讯、相互交互、对外互为一体。
此外，面向服务的软件系统体系架构和其它形式的企业架构的不同之处就在于面向服务的软件系统体系架构能够提供业务的灵活性和可拔插性，因此能够比较好地满足企业异构应用环境下的企业应用系统之间的集成和整合。
2、面向服务的软件系统体系架构的主要优点
（1）降低软件应用系统开发费用和整合维护中的成本
软件应用系统开发方在构建软件应用系统的过程中，对于一些通用功能的模块组件可以不再需要自行开发实现，而可以购买其它更专业的软件企业所提供的该功能组件或者直接使用其提供的功能服务，减少了既费时、又费力但最后的应用效果却不理想的开发工作。组件之间由于是松散藕合，当其中的某个功能模块组件不再能够满足应用的需要时，可以替换该功能模块而不会影响到软件应用系统中的其它功能模块。
（2）能够更好地适应和满足多变的企业业务需求， 增长企业应变业务变化的敏捷性
企业的业务需求是多变和不断地变化的，这也就要求企业信息化应用系统本身具有良好的自适应性。软件应用系统的开发人员可以通过代理、适配器和中介等设计模式完善现有的基于面向服务的软件系统体系架构的企业信息化应用系统。
另外，实现面向服务的软件系统体系架构的Web服务组件之间是通过松散耦合的基于消息通信模型进行相互交互。所有的这些技术特征也都能够满足企业应用环境下对信息化应用系统“按需操作”的应用要求。
面向服务的软件应用系统的系统体系架构能够提供灵活的业务处理功能实现，而业务功能实现的灵活性一方面能够保证软件应用系统可以对业务变更快速和有效地进行响应。这个特性对于许多企业来说，可以提高企业的竞争力；另一方面，软件应用系统的系统架构设计师能够创建一个业务灵活的系统架构——该系统架构是一个既可以满足当前的业务需要，也还能够满足未来的业务需求的体系结构。
（3）能够更好地重用企业现有的各种软件应用系统软件
对于金融、邮政和电力、通讯等行业的企业，由于其业务的具体要求，在企业信息化方面的起步比较早，有许多比较成熟和稳定的软件应用系统。这些软件应用系统目前也能够满足一部分的业务需要，企业如果废弃这些稳定又可靠的应用系统对企业本身是一种浪费！因此，在构建新的企业应用系统时，使用方企业也都强烈地希望能够重用现有的软件应用系统。
基于面向服务的软件系统体系架构设计和开发实现的软件应用系统通常都是在现有的系统架构的基础上扩展的，它可以通过利用当前软件应用系统已有的各种资源（包括开发人员、技术平台和支持系统等）来重复利用现有的系统和各种资源，这将大大地降低了企业信息化过程中的成本。
（4）能够满足异构环境下的各个应用系统之间的互联和整合的要求
J2EE系统平台倡导开放、VS.Net系统平台走向孤立，导致J2EE与VS.Net两个系统平台之间的企业软件应用系统直接互访问性比较差！而实现面向服务的软件系统体系架构的主要实现技术Web服务（WebService）是采用简单对象访问协议（SOAP，SimpleObjectAccessProtocol）实现数据通讯，而简单对象访问协议SOAP是采用可扩展的标记语言XML进行数据交换——XML是平台无关的数据交换语言。
因此，采用面向服务的软件系统体系架构的软件应用系统能够满足异构环境下的各个软件应用系统之间的互联和整合的要求。
3、为什么要应用面向服务的软件系统体系架构构建企业应用系统
（1）异构环境下的企业应用系统需要相互整合和集成的客观原因
企业应用系统不仅需要相互集成整合，而且业务访问的形式也有可能要求是分布式。传统的实现分布式的软件应用系统开发实现的技术在J2EE技术平台中是采用J2EEEJB（EnterpriseJavaBeans，企业级JavaBeans）组件技术——因为J2EE技术规范的两大特征体现在“分层”与“分布”两方面，但J2EEEJB组件技术的重量级形式的分布式技术实现方案只能够应用在J2EE技术平台中，而无法实现直接与微软VS.Net技术平台下的软件应用系统互连。
（2）企业的信息化建设也是分阶段和逐步实现的、并且希望各个阶段的应用系统能够兼容
企业的发展和业务的扩展不可能一开始就很庞大和完善，随着企业业务经营活动和运营的深入，支撑企业经营及业务活动的信息化系统也需要不断地改进和丰富完善。
（3）各个子系统之间希望能够独立、但又能够相互通讯和协作
下图所示为范例项目银行账户信息管理系统中的各个功能模块的关系图，但银行账户管理系统本身也不是孤立存在的，网上商城系统和在线网校系统需要与其互联，为这些软件应用系统提供在线支付功能——网上商城系统中的商品购买和在线网校系统的用户交费。
而面向对象的架构设计和面向切面的架构设计所倡导的“封装”和“隔离”都是针对单一软件应用系统本身的设计方法，而软件应用系统之间如何能够“封装”、同时又能够“协作”？
这可以将银行账户管理系统（它们此时将成为Web服务的服务提供端）中的某个业务功能组件类设计为Web服务组件，并根据Web服务的使用者网上商城系统和在线网校系统（它们此时将成为Web服务的客户端）的应用需要提供对应的账户功能服务。
Web服务的服务提供者和Web服务的服务使用者之间采用简单对象访问协议（SOAP）进行通讯，请见下图所示。
这样的软件应用系统的系统架构设计结果，不仅允许各个软件应用系统本身采用不同的技术平台实现（如银行账户信息管理系统采用J2EE平台，而在线网校系统可以为VS.Net平台，网上商城系统采用J2EE平台），而且也提高了各个软件应用系统本身的安全性，不需要直接进行数据操作、而是业务方法协作——而业务方法是可控制的，但如果公开银行账户管理系统中的数据库表结构或者直接公开其数据库系统本身、或者授权访问数据库表中的数据等方式都是不安全的。
如下示图为本示例项目银行账户信息管理系统和在线网校系统之间的互联互通的工作原理示图的局部截图，对于银行账户信息管理系统和网上商城系统之间的互联互通的工作原理也类似，作者在此不再给出示例图。
（4）面向服务的软件系统体系架构SOA最主要的应用场合
依据基于SOA架构的软件应用系统所具有的上述技术特性，此类架构的企业应用系统更多的表现为处于Internet环境中的异构系统之间的互联互通，从而解决在Internet环境下的不同企业应用系统之间的业务集成问题（如银行账户信息管理系统、在线网校系统和网上商城系统都是目前Internet环境下的典型企业应用系统）。
之所以能够满足Internet环境中的异构系统之间的互联互通的应用要求，是因为因特网Internet的应用环境有别于企业内部网络Intranet的应用环境，主要的区别和特点如下：
大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同——类似于地球上的全人类中的人，不同的民族、不同的肤色、不同的语言、不同的生活习俗等差异，如何能够直接沟通交流？
读者也必须要思考的问题是，正是由于基于SOA架构的软件应用系统更多地表现为Intranet的应用环境，因此在应用SOA架构设计思想具体完成软件应用系统设计时，必须要充分考虑系统的安全性、系统响应性能、数据访问的事务处理和对外提供服务的“粒度”等技术问题如何合理地解决。
当然，并不是说基于SOA架构的软件应用系统只适用于Intranet的应用环境，同样在企业内部网络Intranet的应用环境下也可以应用SOA架构。因此，面向服务的软件系统体系架构设计方法目前还广泛地应用于企业内部的ERP（EnterpriseResourcePlanning，企业资源计划）、CRM（CustomerRelationshipManagement，客户关系管理）、SCM（SupplychainManagement，供应链管理）和HRM（HumanResourceManagement，人力资源管理）等类型的企业应用系统的开发实现中。
4、如何正确地应用SOA的基本思想构建出松散藕合的企业应用系统
为了构建基于SOA架构的企业应用系统时，系统设计人员需要遵守基于SOA的系统构建的一些如下的基本要求：首先，SOA基于定义明确的接口，促进多个软件应用系统之间的松散耦合交互；其次，各个服务的实现是相互独立的，且不依赖于上下文信息以及其它服务的工作状态；再次，服务之间的数据交换主要基于文本类型的格式，使用基于标准的消息模型；最后，服务自身并不知道服务提供者和服务消费者之间传输级的通讯交互。
（1）应用系统中的各个主要的功能组件应该设计为Web服务（WebService）组件
由于面向服务的软件系统体系架构更多的是一种设计思想或者开发的理念、开发的方法等，目前有许多方式能够具体地实现SOA——也就是真正将SOA落地实施。当然，其中主流的方式是采用Web服务（遵守WS标准的WebService）技术实现——这主要得益于WebService技术本身独立于各个系统平台的主要技术特性，而且目前的J2EE系统平台和VS.Net系统平台都提供了对WebService的全面技术支持。
（2）明确定义各个服务组件所应该遵守的对外接口
在支持面向对象编程技术的各种语言（如Java）中都提供有类方法（该类对外所提供的服务）的定义语法规则，在定义和声明一个类方法时，一般要提供如下方面的“接口”信息：方法的名称（对外提供的服务名称）、方法的各种参数（必需的输入数据）、方法期望的输出结果的数据类型和可能会出现什么类型的异常。
而描述这样的“接口”信息的主要的手段是应用某种编程语言所提供的类中成员方法的定义语法。请见下面代码中的黑体部分的代码示例——Java类成员方法的定义语法示例。
publicclassSomeOneClass{
publicObjectsomeOneMethod(StringsomeString){
//方法体的实现代码，在此省略
}
//其他方法定义声明
}
面向服务的软件系统体系架构下的各个服务组件接口的定义则进一步完善了其内涵，包括：服务的名称、服务在触发时所需要的各种输入参数和期望的输出结果、先决条件（服务激活前存在的输入或者应用程序的状态）、后置条件（请求被处理以后服务的状态）、错误处理和服务品质保证（如：性能、多线程、容错之类问题的描述）等。
而对于Web服务组件的接口信息描述的主要手段目前是应用Web服务描述语言（WSDL，WebServiceDescriptionLanguage），该语言将Web服务定义成一个能交换消息的通信端点集。由于WSDL文件的表示法仍然采用XML标准，这意味着它与Web服务功能组件的编程实现的语言无关——开发人员可以应用C++、C#和Java等编程语言开发实现Web服务功能组件，降低了开发人员的学习成本。
因此，WSDL能够描述不同平台和以不同编程语言（C++、C#和Java等编程语言）实现的各个Web服务的接口定义。下图所示例图为某个软件应用系统中的Web服务组件的接口描述的WSDL代码示例的局部截图。
（3）Web服务组件的对外接口必须是平台无关的
面向服务的软件应用系统体系架构下的各个Web服务组件的接口必须是采用中立的方式和独立于实现服务的具体硬件平台、操作系统和编程开发的语言平台——这也就是W3C组织为什么要采用XML作为Web服务组件技术实现中的描述语言。也只有这样的“独立接口”才有可能使得构建在这种体系架构下的各个功能服务组件可以以一种统一和通用的方式进行交互和通讯——而Web服务描述语言（WSDL）能够满足这样的技术应用要求。
但读者要注意的是，正是由于在Web服务的技术实现中采用了XML作为描述语言（SOAP、WSDL等都是采用XML作为描述语言），而XML是文本格式的，从而导致通信协议机制较笨重，依赖ESB（EnterpriseServiceBus，企业服务总线）总线的支撑，降低了软件应用系统的性能，增大了系统开销。读者在应用Web服务组件时需要权衡利弊，合理选择和应用。
（4）Java技术平台中提供JAX-WS和JAX-RS的WebServices技术实现支持
对于Java及J2EE技术平台下的应用系统可以采用JAX-WS和JAX-RS两种不同风格的WebServices技术实现方式，读者可以阅读作者在本系列文章中已经发表的文章《软件项目实训及课程设计指导--为什么要应用和实现面向服务的系统架构设计》，作者在该文章中详细地介绍了如何应用MyEclipse开发工具在软件应用系统项目中应用JAX-WS或者JAX-RS开发WebServices组件。
