RDIFramework.NET框架SOA解决方式（集Windows服务、WinForm形式与IIS形式公布）-分布式应用
RDIFramework.NET，基于.NET的高速信息化系统开发、整合框架，给用户和开发者最佳的.Net框架部署方案。
该框架以SOA范式作为指导思想，作为异质系统整合与互操作性、分布式应用提供了可行的解决方式。
1、SOA平台简单介绍
1.1、概述
SOA（service-oriented architecture，也叫面向服务的体系结构或面向服务架构）是指为了解决在Internet环境下业务集成的须要，通过连接能完毕特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是採用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这种系统中的服务能够以一种统一和通用的方式进行交互。
传统的Web（HTML/HTTP）技术有效的攻克了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。
WEB服务(XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA（面向服务的体系)则是採用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合。实现系统之间的整合与协同。
WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。
对于面向同步和异步应用的。基于请求/响应模式的分布式计算来说，SOA是一场革命。
一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或client。这些服务的关键是他们的松耦合特性。比如。服务的接口和实现相独立。应用开发者或者系统集成者能够通过组合一个或多个服务来构建应用。而无须理解服务的底层实现。
举例来说。一个服务能够用。
NET或J2EE来实现，而使用该服务的应用程序能够在不同的平台之上，使用的语言也能够不同。
1.2、SOA基本特征
SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化作用。
要实现这一目标。就要在实施SOA的过程中牢记下面特征：
可从企业外部訪问
随时可用
粗粒度的服务接口分级
松散耦合
可重用的服务
服务接口设计管理
标准化的服务接口
支持各种消息模式
精确定义的服务契约
1.3、为什么选择SOA
不同种类的操作系统。应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。
一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出高速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求。为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个能够支持有机业务（organic business）的构架。
SOA凭借其松耦合的特性，使得企业能够依照模块化的方式来加入新服务或更新现有服务，以解决新的业务须要，提供选择从而能够通过不同的渠道提供服务，并能够把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。
2、服务的定义
2.1、概述
关于SOA平台服务的定义。眼下来说一般有两种形式。一种是定义标准接口的形式。一种是以标准的WebService的形式来下定义服务的实现。
在上图中是以接口的形式来定义SOA平台服务的，RDIFramework.NET的SOA实现也是採用这种方式。
具体的实现是以.NET技术的WCF来实现的。服务能够以下面几种方式寄存（公布）：Windows服务模式（经常使用）、WinForm界面模式、IIS服务模式等等。在后面的文章我们会分别介绍。
2.2、SOA服务设计原则
一、SOA要求一致性
有非常多可用于创建、公布、发现和调用服务的候选技术。SOA 应提供一个參考体系结构。以指定服务提供者和使用者将使用的特定机制；我们应以在 SAO 全部參与者间实现一致性为目标。
此类一致性能够降低开发、集成和维护工作。
假设须要使用參考体系结构之外的元素，我们推荐使用补充性方法。比如，假如我们为服务公布和发现选择的机制是 UDDI。但某个特定的开发团队已在使用一个基于其它存储库技术的开发流程，此时该怎样处理呢？我们将选择投入精力将该团队的服务同一时候公布到两个存储库。这样，现有的服务使用者就能够使用其熟悉（但可能并不标准）的存储库了。而执行于公共 SOA 基础结构上的使用者则能够为全部服务使用标准存储库——比如 UDDI。
二、SOA 简化开发
我们希望不论什么企业级的 SOA 基础结构都具有可伸缩性和弹性。还应包括行业级的企业服务总线（Enterprise Service Bus。ESB）和安全技术。
或者，换种说法，以 SOA 为目标的服务和流程的开发者可利用成熟的中间件。依赖 SOA 基础结构提供问题的解决方式，如身份验证、消息转换和可靠消息交付。
这些中间件功能的提供应以一个重要的原则为基础：服务和流程开发者应远离中间件实现的复杂细节。我们的理想目标是。在我们的 SOA 环境中工作的开发者应仅仅须要业务领域的相关知识和主要的编程技巧。
服务具有标准的、经过正式定义的可由计算机处理的接口
了解了工具和代码生成在 SOA 实现中可扮演重要角色之后。我们如今要强调使用可由计算机处理的接口的重要性。当使用定义良好的可由计算机处理的语言描写叙述了接口时。实际上就为各种工具支持功能提供了支持。我们希望改善分离状况，因此我们强烈建议使用 WSDL 之类正式定义的开放标准语言，而不要使用专用格式。
可由计算机处理的方法的概念应该从服务接口描写叙述（如 WSDL）扩展到全部其它形式的声明信息或元数据。仅仅有同一时候强调声明技术和可由计算机处理的元数据，才干将其相关的复杂性从业务应用程序开发者转移到基于标准的中间件中。新兴的 WS-Policy 之类的技术在支持此方法方面充当着重要的角色。
三、服务应设计为可重用
服务设计人员应该记住，他们所开发的不论什么服务都可能成为可重用资产。设计人员不应仅仅关注服务的最初使用者的需求，而应该进行更为广泛的业务分析，以确定更全面的需求。我们建议。设计人员应考虑服务可能的发展方向：
设计必须能适应不断添加的吞吐量；假设服务在使用服务的数量添加的情况下仍可成功执行，那么使用率也会成级数递增。
假设使用服务的数量添加。则数据量和并发数据訪问模式可能会与最初投入使用时的情况大为不同。
我们必须对服务请求的未来增长进行估计。新使用者可能须要其它的功能。或者须要对现有功能进行更改
四、服务应具有精心选择的粒度
在选择服务粒度时，我们可能须要在多个因素间进行折衷。如可维护性、可操作性和易用性。
不论什么给定的 SOA 都应向服务设计人员提供指南，以便确定此类折衷方案。
五、服务应是内聚而完整的
既然认识到了在确定服务粒度时须要考虑周全，那么在确定哪些操作应组成服务时有什么注意事项呢？我们觉得有两个对象设计概念非常实用：内聚性和完整性。
六、服务应对实现细节进行封装
我们封装服务实现的细节——所用的算法和资源——的动机在于添加服务使用者和提供者之间的分离，从而为将来扩展提供灵活性。
七、操作设计应考虑并发性
3、框架SOA公布方式
RDIFramework.NET框架的SOA（WCF服务端）能够通过下面几种方式进行寄存（公布）： 以Windows服务方式寄存，以WinForm形式寄存和以IIS形式寄存。
要想框架以WCF模式执行，首先必须配置RDIFramework.NET框架可执行文件所在文件夹的“Config.xml”文件，找到“软件服务提供程序”项。其取值有两种：RDIFramework.ServiceAdapter与RDIFramework.ServiceClient
系统默觉得“RDIFramework.ServiceAdapter”，即传统数据訪问方式（逻辑上的三层结构）。要想系统以WCF模式执行。必须设置其值为：RDIFramework.ServiceClient
通过这种设置，再简单部署一下，即能够WCF模式执行本程序。WCF模式执行Config.xml文件配置例如以下图所看到的。
当然了，对于WCF模式的client与服务端的正确配置以及绑定的方法。能够參考相关文章，在我们框架的配置文件里也进行了具体的说明。