RDIFramework.NET framework
SOA solution (integrated Windows service, WinForm form and IIS form release) - distributed application
RDIFramework.NET, a .NET-based rapid information system development and integration framework, provides users and developers with the best .Net framework deployment solution. The framework takes the SOA paradigm as the guiding ideology, and provides a feasible solution for the integration and interoperability of heterogeneous systems and distributed applications.
1. Introduction to SOA Platform
1.1. Overview
SOA (service-oriented architecture, also called service-oriented architecture or service-oriented architecture) refers to a software system architecture realized by connecting independent functional entities that can complete specific tasks in order to solve the needs of business integration in the Internet environment. SOA is a component model that links different functional units of an application (called services) through well-defined interfaces and contracts between those services. An interface is defined in a neutral way, and it should be independent of the hardware platform, operating system, and programming language that implements the service. This allows services built into various such systems to interact in a unified and common way.
The traditional Web (HTML/HTTP) technology effectively solves the problem of interaction and communication between people and information systems, and greatly promotes the development of the B2C model. WEB service (XML/SOAP/WSDL) technology is to effectively solve the problem of interaction and communication between information systems and promote the development of B2B/EAI/CB2C. SOA (Service-Oriented Architecture) uses service-oriented business modeling technology and WEB service technology to achieve loose coupling between systems and achieve integration and collaboration between systems. The essential idea of WEB service and SOA is to make the individual information system work together on the basis of being able to communicate.
SOA is a revolution for distributed computing based on the request/response pattern for synchronous and asynchronous applications. An application's business logic or some individual functionality is modularized and presented to consumers or clients as services. The key to these services is their loosely coupled nature. For example, the interface and implementation of a service are independent. Application developers or system integrators can build applications by combining one or more services without understanding the underlying implementation of the services. For example, a service can be used. NET or J2EE, and the applications that use this service can be on different platforms and use different languages.
1.2, the basic characteristics of SOA
SOA implementations have several distinct fundamental characteristics. The key goal of implementing SOA is to maximize the role of enterprise IT assets. To achieve this, keep the following characteristics in mind when implementing SOA:
Accessible from outside the enterprise
ready to use
Coarse-grained service interface classification
loosely coupled
reusable service
Service interface design management
Standardized service interface
Supports various message modes
Precisely defined service contracts
1.3. Why choose SOA
Different kinds of operating systems, application software, system software and application infrastructure are intertwined, and this is the current state of IT enterprises. Some existing applications are used to handle current business processes, so building a new infrastructure from scratch is not possible. Enterprises should be able to respond quickly to business changes, leverage investments in existing applications and application infrastructure to address new business needs, and provide new channels of interaction for customers, business partners, and suppliers , and present a framework that can support organic business. SOA, by virtue of its loose coupling characteristics, enables enterprises to add new services or update existing services in a modular manner to solve new business needs, provide choices so that services can be provided through different channels, and can integrate existing enterprise existing or existing applications as a service, thereby protecting existing IT infrastructure investments.
2. Definition of service
2.1. Overview
Regarding the definition of SOA platform services, there are generally two forms at present, one is to define a standard interface, and the other is to define the implementation of a service in the form of a standard 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模式的客户端与服务端的正确配置以及绑定的方法，可以参考相关文章，在我们框架的配置文件中也进行了详细的说明。
3.1、服务端以Windows服务寄存运行
要想我们的框架以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服务为寄存宿主）。
3.2、服务端以WinForm形式寄存运行
我们的框架不仅可以寄存在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”添加了对用户服务的测试调用。
3.3、服务端以IIS形式寄存运行
我们的框架不仅可以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: [email protected] QQ 交流：406590790 ：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 联系我，非常感谢。
