RDIFramework.NET框架SOA解决方案（集Windows服务、WinForm形式与IIS形式发布）-分布式应用
RDIFramework.NET，基于.NET的快速信息化系统开发、整合框架，给用户和开发者最佳的.Net框架部署方案。该框架以SOA范式作为指导思想，作为异质系统整合与互操作性、分布式应用提供了可行的解决方案。
SOA（service-oriented architecture，也叫面向服务的体系结构或面向服务架构）是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
传统的Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。WEB服务(XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA（面向服务的体系)则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。
对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。
SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化作用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：
可从企业外部访问
随时可用
粗粒度的服务接口分级
松散耦合
可重用的服务
服务接口设计管理
标准化的服务接口
支持各种消息模式
精确定义的服务契约
不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。
关于SOA平台服务的定义，目前来说一般有两种形式，一种是定义标准接口的形式，一种是以标准的WebService的形式来下定义服务的实现。
在上图中是以接口的形式来定义SOA平台服务的，RDIFramework.NET的SOA实现也是采用这种方式。具体的实现是以.NET技术的WCF来实现的，服务可以以以下几种方式寄存（发布）：Windows服务模式（常用）、WinForm界面模式、IIS服务模式等等。在后面的文章我们会分别介绍。
一、SOA要求一致性
有很多可用于创建、发布、发现和调用服务的候选技术。SOA 应提供一个参考体系结构，以指定服务提供者和使用者将使用的特定机制；我们应以在 SAO 所有参与者间实现一致性为目标。此类一致性可以减少开发、集成和维护工作。
如果需要使用参考体系结构之外的元素，我们推荐使用补充性方法。例如，假如我们为服务发布和发现选择的机制是 UDDI，但某个特定的开发团队已在使用一个基于其他存储库技术的开发流程，此时该如何处理呢？我们将选择投入精力将该团队的服务同时发布到两个存储库。这样，现有的服务使用者就可以使用其熟悉（但可能并不标准）的存储库了。而运行于公共 SOA 基础结构上的使用者则可以为所有服务使用标准存储库——例如 UDDI。
二、SOA 简化开发
我们希望任何企业级的 SOA 基础结构都具有可伸缩性和弹性；还应包含行业级的企业服务总线（Enterprise Service Bus，ESB）和安全技术。或者，换种说法，以 SOA 为目标的服务和流程的开发人员可利用成熟的中间件，依赖 SOA 基础结构提供问题的解决方案，如身份验证、消息转换和可靠消息交付。
这些中间件功能的提供应以一个重要的原则为基础：服务和流程开发人员应远离中间件实现的复杂细节。我们的理想目标是，在我们的 SOA 环境中工作的开发人员应只需要业务领域的相关知识和基本的编程技巧。
服务具有标准的、经过正式定义的可由计算机处理的接口
了解了工具和代码生成在 SOA 实现中可扮演重要角色之后，我们现在要强调使用可由计算机处理的接口的重要性。当使用定义良好的可由计算机处理的语言描述了接口时，实际上就为各种工具支持功能提供了支持。我们希望改善分离状况，因此我们强烈建议使用 WSDL 之类正式定义的开放标准语言，而不要使用专用格式。
可由计算机处理的方法的概念应该从服务接口描述（如 WSDL）扩展到所有其他形式的声明信息或元数据。只有同时强调声明技术和可由计算机处理的元数据，才能将其相关的复杂性从业务应用程序开发人员转移到基于标准的中间件中。新兴的 WS-Policy 之类的技术在支持此方法方面充当着重要的角色。
三、服务应设计为可重用
服务设计人员应该记住，他们所开发的任何服务都可能成为可重用资产。设计人员不应只关注服务的最初使用者的需求，而应该进行更为广泛的业务分析，以确定更全面的需求。我们建议，设计人员应考虑服务可能的发展方向：
设计必须能适应不断增加的吞吐量；如果服务在使用服务的数量增加的情况下仍可成功运行，那么使用率也会成级数递增。
如果使用服务的数量增加，则数据量和并发数据访问模式可能会与最初投入使用时的情况大为不同。
我们必须对服务请求的未来增长进行预计；新使用者可能需要其他的功能，或者需要对现有功能进行更改
四、服务应具有精心选择的粒度
在选择服务粒度时，我们可能需要在多个因素间进行折衷，如可维护性、可操作性和易用性。任何给定的 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模式的客户端与服务端的正确配置以及绑定的方法，可以参考相关文章，在我们框架的配置文件中也进行了详细的说明。
要想我们的框架以Windows服务寄存，必须部署框架的WCF服务“RDIFramework.WinService”目录包含的内容即为我们的框架以Windows服务进行寄存所必须的文件，如图7.3.1所示。图中含有两个批处理文件可以很好的帮助我们安装与卸载框架的Windows服务，他们分别是：
Install RDIFrameworkService.bat：用于安装框架的WCF服务以寄存到Windows服务上。
Uninstall RDIFrameworkService.bat：用于卸载已经安装好框架WCF服务。
如下图：RDIFramework.NET以Windows服务进行寄存所需文件所示。
双击Install RDIFrameworkService.bat文件进行服务的安装，如图7.3.2所示，输入:y，即可对服务进行安装。如下图所示：
安装成功会出现下图所示的字样。
到Windows服务管理器中，可以看到我们框架的服务已经安装成功，首次安装成功默认没有启动，就请手动启动即可，如下图所示。
对于安装成功的服务，我们也可以对他进行卸载，卸载服务使用Uninstall RDIFrameworkService.bat文件，双击此文件，输入”y”即可对已成功安装的框架服务进行卸载，如下图所示。
或者用InstallUtil.exe命令卸载框架服务也可以，如下图所示：
框架以WCF模式运行的效果如下图所示，可以看到其与传统的方式运行效果完全一样。
因为我们开启了WCF的日志功能，我们可以通过VS2010自带的“服务跟踪查看器”查看WCF的调用过程，当然建议在系统投入正常使用后，关闭WCF的日志记录功能，以免影响整个框架的效率，在此仅做测试使用，要打开VS的服务跟踪查看器，到开始菜单VS的安装菜单名下，找到“服务跟踪查看器”，即可打开，如下图所示。
通过“服务跟踪查看器”我们可以很清楚的看到我们框架是如何调用WCF服务的，整个过程都详细的进行了记录，如下图所示。对于“服务跟踪查看器”的使用方法可以参考相关文档，也可以查看其自带的帮助文件。
以上就是我们框架的分布式架构部署方案（以Windows服务为寄存宿主）。
我们的框架不仅可以寄存在Windows服务程序中，还可以以WinForm形式寄存，使用方式与Windows服务寄存类似。以Winform形式寄存意思是说，服务端以窗体界面形式来启动，这种方式比较简单易懂，用户可以把启动框架服务的窗体主程序放在Windows自启动菜单，让开机时自动启动我们的框架服务。RDIFramework.NET服务端以WinForm形式寄存运行目录：Bin\FrameworkService\RDIFramework.ServiceHost.exe即可，开启后的效果如下图所示：
服务端已经开启，现在运行RDIFrmework.NET客户端，效果与Windows服务方式一至。要测试我们启动的服务，我们可以使用“WCF测试客户端”来进行测试。wcftestclient.exe是一个GUI的工具用于测试WCF，只需在Visual studio command line 窗口中键入wcftestclient，就启动这个程序。如下图：
可以右键“我的服务项目”选择“添加服务（A）…”来添加WCF服务，在上图中，我们输入“net.tcp://127.0.0.1:8888/RDIFramework.ServiceAdapter/UserService/mex”添加了对用户服务的测试调用。
我们的框架不仅可以Windows服务、WinForm界面形式寄存，还可以使用IIS的Web服务形式来寄存。
要以IIS方式来寄存框架的WCF服务，首先我们需要把“RDIFramework.WCFService”项目发布到IIS下，发布的方法与常规的Web发布方式一样，可以参照相关的文章，RDIFramework.WCFService项目如下图所示：
发布到IIS后的效果如下图所示：
在这儿需要说明的时，框架的服务发布到IIS下后，对应的应用程序池的.NET Framework版本要选择.NET Framework V4.0以上版本。如下图所示：
至此，我们可以用浏览器来浏览我们发布的服务，测试发布的服务是否成功，如下图所示，我们测试StaffService服务。
我们也可以用“WCF测试客户端”来测试我们发布到IIS下的WCF服务，如下图所示：
以上面三种方式发布WCF服务端，来进行分布式应用的部署，都可以成功运行我们框架的客户端，用户在使用过程中，可以根据实际情况做出自己的选择。
作者： EricHu 出处： http://www.cnblogs.com/huyong 微博： 腾讯 Email: 406590790@qq.com QQ 交流：406590790 QQ群：16653241 平台博客： 【CSDN】http://blog.csdn.net/chinahuyong 【CNBLOGS】http://www.cnblogs.com/huyong 关于作者：高级工程师、信息系统项目管理师、DBA。专注于微软平台项目架构、管理和企业解决方案，多年项目开发与管理经验，曾多次组织并开发多个大型项目，精通DotNet，DB（SqlServer、Oracle等）技术。熟悉Java、Delhpi及Linux操作系统，有扎实的网络知识。在面向对象、面向服务以及数据库领域有一定的造诣。现从事DB管理与开发、WinForm、WCF、WebService、网页数据抓取以及ASP.NET等项目管理、开发、架构等工作。 如有问题或建议，请多多赐教！ 本文版权归作者和CNBLOGS博客共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，如有问题，可以通过邮箱或QQ 联系我，非常感谢。
本文出自 “.NET快速开发框架” 博客，请务必保留此出处http://yonghu.blog.51cto.com/8166136/1406130
RDIFramework.NET框架SOA解决方案（集Windows服务、WinForm形式与IIS形式发布）-分布式应用,布布扣,bubuko.com
RDIFramework.NET框架SOA解决方案（集Windows服务、WinForm形式与IIS形式发布）-分布式应用
原文：http://yonghu.blog.51cto.com/8166136/1406130