框架以 SOA 服务作为指导思想，作为异质系统整合与互操作性、分布式应用提供了可行的解决方案。

SOA 平台简介

概述

SOA（service-oriented architecture，也叫面向服务的体系结构或面向服务架构）是指为了解决在 Internet 环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

传统的 Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了 B2C 模式的发展。WEB 服务(XML/SOAP/WSDL/JSON）技术则是要有效的解决信息系统之间的交互和沟通问题，促进 B2B/EAI/CB2C 的发展。SOA（面向服务的体系)则是采用面向服务的商业建模技术和 WEB 服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB 服务和 SOA 的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。

对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA 是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用.NET 或 J2EE 来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

SOA 基本特征

SOA 的实施具有几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标，就要在实施 SOA 的过程中牢记以下特征：

• 可从企业外部访问

• 随时可用

• 粗粒度的服务接口分级

• 松散耦合

• 可重用的服务

• 服务接口设计管理

• 标准化的服务接口

• 支持各种消息模式

• 精确定义的服务契约

为什么选择 SOA

不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是 IT 企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA 凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务，从而保护了现有的 IT 基础建设投资。

概述

关于 SOA 平台服务的定义，目前来说一般有两种形式，一种是定义标准 Web 接口的形式，一种是以标准的 WebService 的形式来下定义服务的实现。

在上图中是以接口的形式来定义 SOA 平台服务的，SOA 实现也是采用这种方式。具体的实现方式是以.NET 的 WCF 技术或 WebAPI 技术来实现的。

SOA 服务设计原则

一、SOA 要求一致性

有很多可用于创建、发布、发现和调用服务的候选技术。SOA 应提供一个参考体系结构，以指定服务提供者和使用者将使用的特定机制；我们应以在 SOA 所有参与者间实现一致性为目标。此类一致性可以减少开发、集成和维护工作。

如果需要使用参考体系结构之外的元素，我们推荐使用补充性方法。例如，假如我们为服务发布和发现选择的机制是 UDDI，但某个特定的开发团队已在使用一个基于其他存储库技术的开发流程，此时该如何处理呢？我们将选择投入精力将该团队的服务同时发布到两个存储库。这样，现有的服务使用者就可以使用其熟悉（但可能并不标准）的存储库了。而运行于公共 SOA 基础结构上的使用者则可以为所有服务使用标准存储库------例如 UDDI。

二、SOA 简化开发

我们希望任何企业级的 SOA 基础结构都具有可伸缩性和弹性；还应包含行业级的企业服务总线（Enterprise Service Bus，ESB）和安全技术。或者，换种说法，以 SOA 为目标的服务和流程的开发人员可利用成熟的中间件，依赖 SOA 基础结构提供问题的解决方案，如身份验证、消息转换和可靠消息交付。

这些中间件功能的提供应以一个重要的原则为基础：服务和流程开发人员应远离中间件实现的复杂细节。我们的理想目标是，在我们的 SOA 环境中工作的开发人员应只需要业务领域的相关知识和基本的编程技巧。

服务具有标准的、经过正式定义的可由计算机处理的接口了解了工具和代码生成在 SOA 实现中可扮演重要角色之后，我们现在要强调使用可由计算机处理的接口的重要性。当使用定义良好的可由计算机处理的语言描述了接口时，实际上就为各种工具支持功能提供了支持。我们希望改善分离状况，因此我们强烈建议使用 WSDL 之类正式定义的开放标准语言，而不要使用专用格式。

可由计算机处理的方法的概念应该从服务接口描述（如 WSDL）扩展到所有其他形式的声明信息或元数据。只有同时强调声明技术和可由计算机处理的元数据，才能将其相关的复杂性从业务应用程序开发人员转移到基于标准的中间件中。新兴的 WS-Policy 之类的技术在支持此方法方面充当着重要的角色。

三、服务应设计为可重用

服务设计人员应该记住，他们所开发的任何服务都可能成为可重用资产。设计人员不应只关注服务的最初使用者的需求，而应该进行更为广泛的业务分析，以确定更全面的需求。我们建议，设计人员应考虑服务可能的发展方向：

• 设计必须能适应不断增加的吞吐量；如果服务在使用服务的数量增加的情况下仍可成功运行，那么使用率也会成级数递增。

• 如果使用服务的数量增加，则数据量和并发数据访问模式可能会与最初投入使用时的情况大为不同。

• 我们必须对服务请求的未来增长进行预计；新使用者可能需要其他的功能，或者需要对现有功能进行更改

四、服务应具有精心选择的粒度

在选择服务粒度时，我们可能需要在多个因素间进行折衷，如可维护性、可操作性和易用性。任何给定的 SOA 都应向服务设计人员提供指南，以便确定此类折衷方案。

五、服务应是内聚而完整的

既然认识到了在确定服务粒度时需要考虑周全，那么在确定哪些操作应组成服务时有什么注意事项呢？我们认为有两个对象设计概念很有用：内聚性和完整性。

六、服务应对实现细节进行封装

我们封装服务实现的细节------所用的算法和资源------的动机在于增加服务使用者和提供者之间的分离，从而为将来扩展提供灵活性。

七、操作设计应考虑并发性

框架以 SOA 服务部署

框架不仅支持以直连的方式运行，还支持以服务方式来运行。服务方式运行又支持两种服务模式：WCF 与 WebAPI。

不管是直连、WCF 方式还是 WebAPI 方式，只需修改配置文件对应配置项，做到一键切换，无缝衔接，非常方便。

其实中 WCF 方式又可通过以下三种方式进行寄存（发布）：

Windows 服务方式寄存，WinForm 形式寄存、IIS 形式寄存。

要想框架以服务模式运行，首先必须配置框架的配置文件"config.xml"，找到"服务访问方式"项，其取值有三种：

RDIFramework.ServiceDirect、RDIFramework.ServiceWCF、RDIFramework.ServiceAPI

系统默认为RDIFramework.ServiceDirect，即传统直连数据访问方式（逻辑上的三层结构），要想系统以服务模式运行，必须设置其值为：RDIFramework.ServiceWCF 或 RDIFramework.ServiceAPI。

RDIFramework.ServiceDirect：以直连数据库方式来运行。

RDIFramework.ServiceWCF：以 WCF 服务来运行。

RDIFramework.ServiceAPI：以 WebAPI 服务来运行。

通过这样的设置，再简单部署一下，以服务模式运行本程序。config.xml文件配置如下图所示。

如果配置 ServiceAccessMode 为：RDIFramework.ServiceWCF，则：WebHostUrl 地址应该配置为 WCF 服务地址。

如果配置 ServiceAccessMode 为：RDIFramework.ServiceAPI，则：WebHostUrl 地址应该配置为 WebAPI 服务地址。

当然了，对于服务模式的客户端与服务端的正确配置以及绑定的方法，可以参考相关文章，在我们框架的配置文件中也进行了详细的说明。

框架以 WCF 方式运行

配置文件配置项 ServiceAccessMode 为：RDIFramework.ServiceWCF

WCF 服务端以 Windows 服务寄存运行

要想我们的框架以 Windows 服务寄存，必须部署框架的 WCF 服务"RDIFramework.WinService"目录包含的内容即为我们的框架以 Windows 服务进行寄存所必须的文件，如下图所示。图中含有两个批处理文件可以很好的帮助我们安装与卸载框架的 Windows 服务，他们分别是：

[Install RDIFrameworkService.bat：用于安装框架的 WCF 服务以寄存到 Windows 服务上。

[Uninstall RDIFrameworkService.bat：用于卸载已经安装好框架 WCF 服务。

双击[Install RDIFrameworkService.bat文件进行服务的安装，如下图所示，输入:y，即可对服务进行安装。

安装成功会出现如下图所示的字样。

到 Windows 服务管理器中，可以看到我们框架的服务已经安装成功，首次安装成功默认没有启动，就请手动启动即可，如下图所示。

对于安装成功的服务，我们也可以对他进行卸载，卸载服务使用Uninstall RDIFrameworkService.bat文件，双击此文件，输入"y"即可对已成功安装的框架服务进行卸载，如下图所示。

或者用 InstallUtil.exe 命令卸载框架服务也可以，如下图所示。

框架以服务模式运行的效果如下图所示，可以看到其与传统的方式运行效果完全一样。

因为我们开启了 WCF 的日志功能，我们可以通过 VS 自带的"服务跟踪查看器"查看 WCF 的调用过程，当然建议在系统投入正常使用后，关闭 WCF 的日志记录功能，以免影响整个框架的效率，在此仅做测试使用，要打开 VS 的服务跟踪查看器，到开始菜单 VS 的安装菜单名下，找到"服务跟踪查看器"，即可打开，如下图所示。

通过"服务跟踪查看器"我们可以很清楚的看到我们框架是如何调用 WCF 服务的，整个过程都详细的进行了记录，如下图所示。对于"服务跟踪查看器"的使用方法可以参考相关文档，也可以查看其自带的帮助文件。

以上就是我们框架的分布式架构部署方案（以 Windows 服务为寄存宿主）。

WCF 服务端以 WinForm 形式寄存运行

我们的框架不仅可以寄存在 Windows 服务程序中，还可以以 WinForm 形式寄存，使用方式与 Windows 服务寄存类似。以 Winform 形式寄存意思是说，服务端以窗体界面形式来启动，这种方式比较简单易懂，用户可以把启动框架服务的窗体主程序放在 Windows 自启动菜单，让开机时自动启动我们的框架服务。RDIFramework.NET 服务端以 WinForm 形式寄存运行目录：Bin\FrameworkService\RDIFramework.ServiceHost.exe，如下图所示。

开启后的效果如下图所示。

服务端已经开启，现在运行 RDIFrmework.NET 客户端，效果与 Windows 服务方式一至。要测试我们启动的服务，我们可以使用"WCF 测试客户端"来进行测试。wcftestclient.exe 是一个 GUI 的工具用于测试 WCF，只需在 Visualstudio command line 窗口中键入wcftestclient，就启动这个程序。如下图：

可以右键"我的服务项目"选择"添加服务（A）..."来添加 WCF 服务，在上图中，我们输入"net.tcp://127.0.0.1:8888/RDIFramework.ServiceAdapter/UserService/mex"添加了对用户服务的测试调用。

WCF 服务端以 IIS 形式寄存运行

框架 WCF 服务寄存方式不仅可以 Windows 服务、WinForm 界面形式寄存，还可以使用 IIS 的 Web 服务形式来寄存。

要以 IIS 方式来寄存框架的 WCF 服务，首先我们需要把"RDIFramework.WCFService"项目发布到 IIS 下，发布的方法与常规的 Web 发布方式一样，可以参照相关的文章，RDIFramework.WCFService 项目如下图所示。

发布到 IIS 后的效果如下图所示。

在这儿需要说明的时，框架的服务发布到 IIS 下后，对应的应用程序池的.NET Framework 版本要选择.NET Framework V4.8 版本，如下图所示。

至此，我们可以用浏览器来浏览我们发布的服务，测试发布的服务是否成功，如下图所示，我们测试 StaffService 服务。

我们也可以用"WCF 测试客户端"来测试我们发布到 IIS 下的 WCF 服务，如下图所示。

以上面三种方式发布 WCF 服务端，来进行分布式应用的部署，都可以成功运行我们框架的客户端，用户在使用过程中，可以根据实际情况做出自己的选择。

框架以 WebAPI 方式运行

随着互联网技术的发展，WebAPI 作为一种轻量级的服务选择，被广泛应用于各种互联网应用中。WebAPI 的优点在于其简单、易用、性能高等特点。通过 WebAPI 方式，可以实现快速、可靠的数据读取和写入操作，减少客户端与数据库直接交互的频次，优化网络性能。WebAPI 作为中间层，能够高效处理数据请求和响应，从而显著提升应用程序的整体性能，同时还可以作为与第三方应用进行数据交互的中介。

config.xml 配置文件配置项 ServiceAccessMode 为：RDIFramework.ServiceAPI

启动框架的 WebAPI 服务，如下图所示。

查看 WebAPI Swagger

框架以 WebAPI 方式运行如下图所示。